>And, to nit pick a bit more, PIC 0004 is a protection exception. That >is *not* the interrupt you normally see in the trace when accessing a >page in "first reference" state.
And, to explain a bit about the difference between PIC 4 and PIC 10/11 and some of the behavior of the system, let me try to explain a bit about the virtual storage concept. I intentionally leave away everything a standard user program does *not* need. It would be too much, otherwise. The CP fetches instructions from storage and the instruction access operands in storage. This is hardware, so the bits and bytes must be somewhere in hardware. Hardware storage is called "real storage" in MVS terminology (its called RAM on PCs). MVS implements virtual storage so that many programs can share the limited amount of installed real storage. Programs run in separate virtual constructs called "address spaces" AS and programs access storage by *virtual* addresses. This concept only works because the hardware provides a mechanism to translate a program's virtual address to a real address when an instruction accesses storage (or fetches the next instruction). This is called Dynamic Address Translation (DAT) and works behind the scene; the program is not aware of it (an has no need to be). This is all based on 4KB units, i.e. the real and virtual storage is dealt with in 4KB units. To make the following a bit easier to understand, let's ignore there is storage above the bar (2G) in z/OS; just let's assume this is 32bit OS/390 V2.10 (which did not support 64bit) so the address space is 2GB in size. The operating system (OS) maintains translation tables for the DAT hardware. To limit the size of the tables, the 2GB address space is divided into 1MB segments and each segment is divided into 4KB pages. There is one segment table for each address space and a page table for each of the 2048 segments of an AS (2048 * 1MB = 2GB). Each page table has an entry for each of the 256 pages in its segment (256 * 4KB = 1MB). Now, let's run some code (and let's ignore instruction fetching for the time being). The currently executed instruction accesses a storage operand by its virtual address. DAT then tries to map the virtual address to a real address using the segment and page tables and will eventually get the address or a 4KB real storage "frame". The bytes accessed by the instruction sit somewhere in that 4KB range (there are exceptions, I know). The instruction succeeded. However, virtual storage was invented to share the limited amount of real storage among many programs. Therefore, there are cases when no real frame is associated with a virtual address. In other words DAT cannot resolve the virtual address and the instruction may not succeed. In this case, DAT throws a program interruption, namely an address translation exception. There are two of them (well 5 in modern 64bit hardware): A segment translation exception (PIC 10) and a page translation exception (PIC 11). PIC 10 means DAT failed to find a valid pointer to the page table for the segment of the virtual address being translated. This means currently no single byte can be accessed in the whole 1MB range where the virtual address points to. PIC 11 means DAT finds an invalid pointer to a real frame associated with the virtual address being translated. This means, there is currently no real frame assigned. Both interruptions have to be dealt with by the operating system. The OS has to find out if the program is allowed to access that address or not. In other words, is this address pointing to some GETMAINed are or not. If it may, it has to find an unused real storage frame, associate it with the virtual address (well the 4BK area which the virtual address is part of), update the segment and/or page tables and finally as the hardware to try again (i.e. rerun the instruction). If the OS finds that the program is not allowed to access that address because it is not pointing to a GETMAINed area, it will abend the program. The system abend code will be S0C4 reason 10 it was a PIC 10 and S0C4 reason 11 if it was a PIC 11. There is one more case to consider: PIC 4, i.e. protection exception. A protection exception is not recognized as part of DAT processing but when an instruction is actually accessing a byte of real storage; if a PIC 4 happens, DAT had successfully translated the virtual address but the instruction was not successful accessing real storage because it didn't have sufficient rights to do so. The real storage might be marked "fetch protected" or "write protected" (using hardware storage key and other bits). In this case the hardware throws a PIC 4 and the OS will abend the program with S0C4 reason 4. If a program abends with S0C4-10/11 it was trying to access storage in an area where nothing was GETMAINed; if it abends with S0C4-4 it was trying to read from GETMAINed but fetch protected or to write to GETMAINed but write protected storage (i.e. its PSW key was not 0 and it did not match the real frame's storage key). Puhh... that became much longer than I intended. Hope it helps somewhat anyway. -- Peter Hunkeler Credit Suisse ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
