Peter, The field was ACEEGRPN ....see my note to Walt...we think we might know what caused it. Customer had defined our STCs, we use two as having a user of RACF...I have no idea why.. So all commands coming into our irrevx01 exit were master...instead if user address space commands. We are being resold via Oracle and the Oracle folks and I spent time on the trace and dump yesterday, I thought maybe the customer has a fix not applied..they have been no real forthright in sending information because of a language barrier. There is a PMR open
Scott ford www.identityforge.com On Jun 8, 2012, at 7:57 AM, Peter Relson <[email protected]> wrote: >> Issue was the ACEE and mode it was in when we tried >> to issue a MVC again a field in an ACEE that was >> deleted by IBM > > Scott, > > Could you be more specific about which field you think was deleted? > > We're usually pretty good about notifying ISVs via a "change notification" > and customers via release migration information about changes (including > deletions) to programming interfaces. > > There have been no fields deleted from the IHAACEE mapping in z/OS. > >> If the Getmain fails...what's the result ? Abend ? or bad rc ? > If GETMAIN with RU fails, you abend. > If it succeeds without CHECKZERO=YES, you get RC=0 > If it succeeds with CHECKZERO=YES, you get either RC=0 or RC=20. > > If you don't want to abend on such cases as "no storage available", then > consider using GETMAIN RC rather than GETMAIN RU. > >> ...the Getmain RU rc is barely useless, I am better >> of to code a Storage Obtain, correct ? > > Not correct. The behavior is identical (Storage Obtain of course uses > COND=NO instead of RU). > Note that Storage Obtain,Linkage=SVC *is* GETMAIN, as is Storage > Obtain,Linkage=BRANCH. > They produce the identical interface and use the same target module as > GETMAIN. > Storage Obtain,Linkage=System (the default) is the "different" one. > > Peter Relson > z/OS Core Technology Design
