Or what Skip says :) > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Skip Robinson > Sent: Friday, September 05, 2014 9:29 AM > To: [email protected] > Subject: Re: RSU APPLY ISSUE GIM23911E > > I would be VERY wary of restoring the SMPE environment. Unless it was > backed up exactly right with every single SMPE-related data set, > restoring over the current environment could result in a mess bigger > than the one that (seems to) exist now. Instead I would recommend a > 'fix forward' > approach. > > 1. Check and recheck that every DDDEF points to the correct data set. > This will take time. Don't shortcut. > 2. RESTORE all PTFs that were applied since the ZONE EDIT exercise > already noted. This will also take time. Crank through it. > 3. Pull the latest HOLD data. > 4. Reapply maintenance following the new and improved process: use only > BYPASS(HOLDSYS) and nothing else. > 5. Expect RC 8 on APPLY CHECK. Look at the CAUSER section. Missing > sysmods are OK; ignore them. Any other error must be dealt with. > 6. Expect RC 8 on the real APPLY. Once again check the CAUSER section. > You should see only the same 'missing sysmod' messages that you saw in > APPLY CHECK. Any other error must be dealt with. > > I agree with those who point out that conflicting LKED attributes are > not necessarily a run-time problem, but you should consult IBM via SR > to verify. The bigger problem here, as noted, is that your result > differs from others (including me) who applied (more or less) the same > PTFs. That fact is unsettling. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 626-302-7535 Office > 323-715-0595 Mobile > [email protected] > > > > From: Doug Henry <[email protected]> > To: [email protected], > Date: 09/05/2014 08:37 AM > Subject: Re: RSU APPLY ISSUE GIM23911E > Sent by: IBM Mainframe Discussion List <IBM- > [email protected]> > > > > On Fri, 5 Sep 2014 19:21:41 +0530, Mainframe Mainframe > <[email protected]> wrote: > > >Sorry, Please find correct output. > >>1 LISTLOAD DDN=SCEELKED,MEMBER=STRXFRM,OUTPUT=XREF > >00060001 > >1 ***** M O D U L E S U M M A R Y > ***** > >0 MEMBER NAME: EDC@@248 > > MAIN ENTRY POINT: 00000000 > >0 LIBRARY: SCEELKED > > AMODE OF MAIN ENTRY POINT: 31 > >0 ** ALIASES ** ENTRY POINT AMODE > > ** STRXFRM 00000000 31 > >---------------------------------------------------------------------- > --------------------------------------------------- > >0 **** ATTRIBUTES OF MODULE > **** > >0 ** BIT STATUS BIT STATUS BIT > STATUS > > BIT STATUS ** > >0 0 RENT 1 REUS 2 NOT- > OVLY > > 3 NOT-TEST > > 4 NOT-OL 5 BLOCK 6 EXEC > > 7 1-TXT > > 8 NOT-DC 9 ZERO-ORG 10 EP- > ZERO > > 11 NO-RLD > > 12 EDIT 13 NO-SYMS 14 F- > LEVEL > > 15 NOT-REFR > >0--------------------------------------------------------------------- > --------------------------------------------------- > > So the problem is caused by bit 15 being not-refr instead of the proper > setting for the module of bit 15 being refr. > I am not sure how you broke your system. I noticed that you improperly > bypass a lot of apars and that may be the source of the problem. I > suggest > you go back to the backup of your smpe/system environment and reapply > correctly. > > Doug > > > ---------------------------------------------------------------------- > 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
