IBM Mainframe Discussion List <[email protected]> wrote on 11/25/2007 12:16:34 PM:
> In a message dated 11/25/2007 10:45:30 A.M. Central Standard Time, > [EMAIL PROTECTED] writes: > >No service that I know of tests for "possible ways". They always look for > the PSW. > > GETMAIN did ca. 1991. I was disabled via PSW swap and tried to get an > authorized-only subpool. It failed with B78-something. I > instruction stepped > through the code via VM until I found the problem. The first GETMAIN module > tested for all three possibilities (super bit, locks, and current > system mask). > The request was allowed to proceed if any of the three tests was successful. > My request passed this point because of my system mask. Then after a few > more instructions the first module branced to another module which repeated > the first two tests but not the third, thus causing my request to fail. > > >It is expected and assumed that authorized programs follow > expected conventions. > > I added an OI to turn on the IOS super bit and then my request succeeded. I > was following the documented requirements in the Authorized Assembler > Services Reference for GETMAIN (STORAGE, or whatever it was). The documented > requirement said authorized, key 0-7, or disabled (or something > like that). My > code was disabled only, and my request failed until I turned on thesuper bit > to prove to GETMAIN that I was seriously disabled. > > Maybe this behavior of GETMAIN has been changed since then to look only for > the PSW as you say. I don't know. I only get perturbed when the code's > behavior does not match the external documentation. My anecdote is > 16 years old, > and the doc and code may have been changed since then. Ca. 1991, STORAGE did not allow disabled callers at all (this was changed in SP 4.3.0 to allow STORAGE to be called disabled for common storage subpools). So your only choice would have been GETMAIN BRANCH=(YES,GLOBAL). IGVVSM31 (the first GETMAIN module, not counting the glue routine) checks the PSW for being disabled, but does not check super bits or locks. The second GETMAIN module, IGVSMVRT does not (and never did) check any such thing. There is nothing (and never was) in VSM that checks super bits. Since you called GETMAIN illegally disabled, when IGVVSM31 released the VSMFIX lock, the SETLOCK RELEASE would have enabled. If nothing else bad happened in the meantime due to being unexpectedly enabled, a subsequent GETMAIN or FREEMAIN with BRANCH=(YES,GLOBAL) would get a B78-40 abend due to being enabled. Setting the IOS super bit avoided these unpleasantries, since then the SETLOCK RELEASE for the VSMFIX lock did not enable. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY ---------------------------------------------------------------------- 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
