> -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of James Cotter > Sent: Wednesday, January 24, 2007 11:23 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Cross Memory and AR ASC Mode > > For a space-switching PC routine (PC-ss), I am aware of the requirement > for the service providers' address space to be non-swappable. However, > when in AR ASC mode and accessing data via an AR, is there any requirement > for the target address space to be non-swappable? I have looked through > the z/OS Extended Addressability Guide but I can't see any (obvious) > reference to this. > > James Cotter Greetings,
If the current unit of work has primary or secondary addressability to an address space that gets swapped out, the unit of work will abend upon the next reference to that space or upon attempted dispatch of the unit of work when its addressability is restored with the LASP instruction. Accessing a swapped-out address space through an access list entry token will also cause an access exception program check. There are products out there that violate system integrity rules and use an authorization index (AX) of 1 to peek at other arbitrary address spaces. This practice is frowned upon and z/OS 1.8 apparently will use the ASN-LX-REUSE-FACILITY (ALRF) to save additional information in the XSB and other places to verify that target space is the same space that was initially bound to the unit of work. The linkage stack also saves ALRF information for use by the Program Return (PR) instruction when popping a PC state entry, to be sure that addressability is being restored to the correct primary and secondary spaces. In the olden days, only the ASN of the primary and secondary spaces was saved upon suspension. Upon resumption, there was no way to know whether restoring the ASN via the LASP instruction was restoring addressability to original space or to some other space that reused the ASN. Unless the unit of work held the global CMS lock to defer space creation/termination, it was possible to use secondary mode to perform 2 LOAD (L) instructions for the same virtual address and get data from two different address spaces. This is why the rules are designed for a unit of work "to look back" at where it's been, rather than look at arbitrary spaces. It gets even worse when the unit of work is in cross memory mode and its primary ASN is reassigned to another space. The unit of work could get redispatched into another space. This is why an address space with connected space-switch tables will not get its ASN reassigned until all other spaces that were connected to it are terminated. The home space is always swapped in when the unit of work is dispatched. Any other spaces in its chain of space-switching must be nonswappable and must stay alive for the duration of the home space bind to those spaces. Jeffrey D. Smith Principal Product Architect Farsight Systems Corporation 700 KEN PRATT BLVD. #204-159 LONGMONT, CO 80501-6452 303-774-9381 direct 303-484-6170 FAX http://www.farsight-systems.com/ see my résumé at my website (yes, I am looking for employment) ---------------------------------------------------------------------- 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
