Seymore wrote: "ActualIy, I am interested, and was since it [prefixing] made its first appearance on S/360, but unless you're writing DAT-OFF code you don't need to deal with it."
The association of DAT-off code and prefixing woke me up at 4am this morning, and it's been bugging me ever since. So, at the risk of being pedantic, a few words of clarification: Prefixing is the means by which multiple CPUs (i.e., threads) in a multiprocessor environment avoid stepping on each other's hardware-related environment such as interruption-old PSWs and interruption codes. During initialization, each CPU is assigned a separate 4 K-byte block of absolute storage to act as its own private real locations 0-4,095. A CPU's prefix register determines the location of this 4K block (and, through a clever trick called reverse prefixing, each CPU can access absolute zero). Prefixing is ALWAYS in effect, regardless of whether DAT is in effect. Dynamic address translation (DAT) is the means by which an OS can accomplish two separate — but equally important — functions: 1, Over-committing real storage (i.e., stuffing terabytes of data into a gigabyte bag) by means of paging to auxiliary storage. Historically, this is the more common understanding of DAT, since it was an attractive feature back in the 1970s when storage was expensive and SVS supported only a single address space. 2. Isolating the data of address spaces and data spaces from each other to improve reliability and security. This gets less ink in the PoO, but it is equally important with the first function (over-committing real storage). The OS can turn DAT on and off to suit its own processing needs. But, I agree with the original assertion that only 0.01% of programmers will ever care about prefixing.
