The privileged PTLB (Purge TLB) instruction is common to most modern computers, even by that name. It informs the hardware that some part of the memory map that it might just now be remembering (in the TLB), has been changed in RAM and the hardware must forget the old value and look again if necessary to learn the new value. To use the old value would cause obscure system misbehavior that is hard to relate to the cause of the wrong map. Thus the design of software to manipulate the map is fraught with anxiety lest there be too few PTLBs. PTLBs are expensive. There are few bugs so hard to find. (See PTLB in this.)
IBM shipped sources for early versions of VM/370. Tymshare provided timsharing services on mid-range 370s and significantly modified these sources in support of our atypical requirements. One day we found a path thru the kernel that changed the memory map but failed to purge the TLB. It was fairly easy to fix and we did, but we felt obliged to tell IBM about the bug. I called IBM support, which was very good indeed. Our contact there, however, had not conceived of a customer finding a bug by reading source code. They wanted a crash, (record of memory at the point of failure.) We suspected that we had never crashed with such a failure, and if we had the crash would provide few clues. They wondered what we were complaining about.
There the matter stood for several weeks. I then ran into John Cocke from IBM in an airport. John had the ear of important people at IBM and carried considerable weight for his reputation of technical understanding. I told John about the PTLB and our standoff. When I got home a few hours later I had a telephone message from a VP of IBM asking me to please call with the PTLB bug info. They soon circulated a patch.