http://mzelden.com/mvsutil.html
On Thu, Nov 22, 2018 at 2:43 AM Sean Gleann <[email protected]> wrote: > > Thanks to all that have responded - we're back and running again, but not > due to any work on my part. > > > > My description of the failed system was not complete, for fear of confusing > the issue - it is a guest z/OS under z/VM that is supplied by a.n. other > party. I contacted them and the bad IEFUSI was renamed by a techie at their > end. > > > > Rob: thanks for the referral to cbttape. I wasn't aware of that particular > file there. I'll take a closer look later. I've had the comfort of a > recovery system in the past. Sadly, that wasn't an option for me in this > case. > > > > Peter: "...[54m value] has no meaning and will later be replaced..." Yes - > Overnight I began to understand that. > > No matter what I've done so far, that SMF30RGN value continues to report > '54M'. I 'new' thought for me in the course of this work is that SMF30RGN > is the REGION size that was _requested_ (as per the documentation). It is > not the size actually _given_ after IEFUSI/SMF/JES, etc have finished their > meddling. As far as I make out, there is no such 'after the fact' value > logged in any part of the type30 record (or any other). > > Which basically means that all this work has been a waste of time, based on > a misconception. > > > > Peter again: [paging space related to the problem]... sorry - my poor > description there. The alternate SYS1.IPLPARM(LOADxx) member leads to an > incomplete definition that does not specify any paging space, so it won't > IPL. > > > > Carmen and Peter: I simply did not think about the possibilities of SETPROG > EXIT..., My mind was chasing itself in circles at the time. And then the > supplier's technician fixed things up. > > > > > > I must re-visit my failed 'back-out' LOADPARM member and make sure it > brings up a minimal system - possibly with whatever I find on the cbttape. > > And abandon this line of effort - I'm pretty certain that SMF30RGN point > above is correct. > > > > Unfortunately, that leaves the cause of the original IEW4000I and CSV031I > messages unsolved. I will have to think of a different way to attack the > problem. > > > Regards > > Sean > > > On Wed, 21 Nov 2018 at 20:23, Peter Hunkeler <[email protected]> wrote: > > > Just recognized that the parameter STATE=INACTIVE was missing in my > > previous post > > > > SETPROG EXIT,MODIFY,EXITNAME=SYS.IEFUSI,MODNAME=IEFUSI,STATE=INACTIVE > > > > > > -- > > > > Peter Hunkeler > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
