Yeah, I have too look at what has happened ....their trace was unreadable so I will try the same code on our test system with a gfs trace ..I just want to solve the mystery and make sure we don't have an issue
Scott ford www.identityforge.com from my IPAD 'Infinite wisdom through infinite means' On May 27, 2013, at 10:23 AM, "Shmuel Metz (Seymour J.)" <shmuel+...@patriot.net> wrote: > In <086801ce5a76$af711e70$0e535b50$@mcn.org>, on 05/26/2013 > at 06:08 PM, Charles Mills <charl...@mcn.org> said: > >>> you need to save the key prior to the MODESET KEY=ZERO invocations > >> Are you sure? > > Yes. > >> MODESET KEY=NZERO,... won't "remember" for you? > > The crystal ball on channel 3 is broken. From z/OS MVS Programming: > Authorized Assembler Services Reference, Volume 3 (LLA-SDU). > SA22-7611-11: > > KEY=NZERO > Specifies that the PSW key (bits 8-11) is to be either set to > zero > (ZERO) or set to the value in the caller's TCB (NZERO). > > If the code switches among multiple keys, MODESET has no information > on the preceding key. Now, there are options in the inline form to > save and restore, but Scott is using the SVC form. > > -- > Shmuel (Seymour J.) Metz, SysProg and JOAT > Atid/2 <http://patriot.net/~shmuel> > We don't care. We don't have to care, we're Congress. > (S877: The Shut up and Eat Your spam act of 2003) > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
