I cannot tell you what would be the best process for your shop. I do not know your systems.
However, if it is reasonable to use a different SYSRES to IPL from at this point, I would investigate that. 1) were the two sysres volumes at the same level of maintenance/ 2) If the other sysres is at a lower level of maintenance, what fixes will you be missing? Would they be needed if you IPL from that system 3) Is this a test environment? Production environment? System Programmer Sand Box? If there is no impact to IPL'ing from a different sysres, and there is no impact to the system you got the SMPE error on. Then I would consider IPL'ing from a different SYSRES and continue the maintenance from the one the fixes were being applied. Had this error not happened, you would have needed to recover your active system SYSRES as the APPLY process links, re-links, and updates a lot of components that are in use by the active system. At some point, depending on the PTF, it is likely you would have lost your system (crashed). Also ensure your Unix files (system z/FS or HFS) files are from a /service directory and not the actual running directories. Also, review all of your datasets in the LINKLST. Make sure they only have PRIMARY allocation and a Secondary Allocation of 0 (zero). You can run into issues when there are secondary allocations in Linklst. And they can occur when you do not wish them to. >From the V1.12 Manual: MVS Initialization and Tuning Reference SA22-7592-21 Section PROGxx: When using PDSs and PDSEs, you can allocate LNKLST data sets with secondary extents. However, IBM suggests that PDSs in the LNKLST be allocated with only primary extents, for two reasons. First, this makes it easier to stay within the 255-extent limit for an active LNKLST concatenation. without having to reallocate data sets in fewer extents initially. Second, if a PDS will be updated while in the link list, it can be extended if it has been allocated using secondary space. This can cause members to be placed in extents that did not exist when the LNKLST concatenation was opened. Any attempt to access a member in a new extent causes the requesting program to abend with a logical I/O error. This recommendation does not apply to PDSEs. Lizette > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of venkat kulkarni > Sent: Sunday, January 12, 2014 9:24 AM > To: [email protected] > Subject: Re: z/OS 1.13 PTF apply Issue > > Yes, I already did LLA refresh. > > But I also accept this mistake that, I should have IPLed from another volume and > then apply maintenance on the RES volume where DDDEF is pointing to.. But to > correct this mistake now, I can try IPLing system from another RES volume and > then try running this apply job. > > Or do you suggest to run apply Job with the way I am doing now, we I am already in > half of way. > > > On Sun, Jan 12, 2014 at 9:44 PM, Lizette Koehler > <[email protected]>wrote: > > > Your SYS1.MIGLIB has secondary extents. If a dataset will be in the > > LINKLST > > - it is HIGHLY recommend to not have secondary extents. PRIMARY space > > allocation only - secondary space allocation of 0 (zero). > > > > You can try > > > > F LLA,REFRESH > > > > > > If that does not work > > > > IPL > > > > I would like to understand how you are applying fixes. > > > > It is never recommended to apply fixes to a SYSRES volume(s) you are > > running on (what you IPL'd from) > > > > Instead it is recommended to make a new set of SYSRES volume(s), point > > your SMPE to the new volumes, follow your maintenance procedures, then > > IPL the new SYSRES Volumes. > > > > If you apply to a live running system you are very likely to IPL. You > > may corrupt your live running systems when you have errors (like this one). > > > > Lizette > > > > > > > -----Original Message----- > > > From: IBM Mainframe Discussion List > > > [mailto:[email protected]] On Behalf Of venkat kulkarni > > > Sent: Sunday, January 12, 2014 8:09 AM > > > To: [email protected] > > > Subject: Re: z/OS 1.13 PTF apply Issue > > > > > > Yes, I checked Job log and errors starting from GIM44002S message > > > and the reason is GIMDRS module present in SYS1.MIGLIB, which is > > > part of LNKLST concatenation. > > > GIM44002S ** SYSTEM ABEND 106 OCCURRED WITH A REASON CODE > OF > > > '0000000F'X AFT > > > SMP/E CALLED THE GIMDRS UTILITY TO PROCESS THE > SYSUT1 > > > LIBRARY. > > > GIM30217I APPLY PROCESSING FAILED FOR SYSMOD UA68267. > > > RETRANSFORMATION > > > PROCESSING FAILED FOR AN ELEMENT IN UA68267. > > > > > > etc.... > > > > > > > > > SYS1.MIGLIB information is below. But It has used only one extant, > > > which > > is > > > normal. > > > Data Set Information Command ===> > > > > > > Data Set Name . . . : SYS1.MIGLIB > > > > > > General Data Current Allocation > > > Volume serial . . . : ZS1RS Allocated blocks . : 1,479 > > > Device type . . . . : 3390 Allocated extents . : 1 > > > Organization . . . : PO Maximum dir. blocks : 2000 > > > Record format . . . : U > > > Record length . . . : 0 > > > Block size . . . . : 32760 Current Utilization > > > 1st extent blocks . : 1479 Used blocks . . . . : 943 > > > Secondary blocks . : 947 Used extents . . . : 1 > > > Used dir. blocks . : 327 > > > Number of members . : 1,967 > > > > > > Dates > > > Creation date . . . : 2012/11/05 > > > Referenced date . . : 2014/01/12 > > > Expiration date . . : > > > ***None*** > > > > > > Yes, I am applying Maintenance to Live RES volume. But I have one > > > more > > RES > > > volume, So I can try switching to that RES volume and let DDDEF > > > point to > > the > > > current RES volume and then try running this apply Job . > > > > > > From one of the link on internet, I found below link. > > > https://communities.ca.com/web/mainframe-2.0-community/message-board > > > /- > > > > /message_boards/message/103509396;jsessionid=1BC4E0A3029C7C6E6F656B0 > > > C676C4189?p_p_auth=XO9hkQmC&#p_19 > > > > > > This link suggest to follow below steps to resolve this issue. > > > > > > Issue the following command to determine thename of the link list: > > > > > > D PROG,LNKLST,NAMES > > > > > > Should be LNKLST00in most cases. > > > > > > > > > Then issue: > > > > > > > > > a) SETPROG LNKLST,UNALLOCATE > > > b) P LLA > > > c) SETPROG LNKLST,DEFINE,NAME=LNKLST01,COPYFROM=CURRENT > > > d) SETPROG LNKLST,ACTIVATE,NAME=LNKLST01 > > > e) SETPROG LNKLST,UPDATE,JOB=* > > > f) S LLA,SUB=MSTR > > > g) SETPROG LNKLST,ALLOCATE > > > > > > So we no longer use LNKLST00 and use a new one called LNKLST01. > > > > > > Please suggest. > > > > > > > > > > > > > > > On Sun, Jan 12, 2014 at 5:19 PM, Lizette Koehler > > > <[email protected]>wrote: > > > > > > > Also. The *LINKLST* does not always mean SYS1.LINKLIB. > > > > > > > > It means that in the Linklst concatenation you may have a datasets > > > > in secondary extents. You need to see what library was being > > > > worked on at the time of the failure. > > > > > > > > In the output of your SMP/E job it will tell you what PTF it was > > > > working on at the time of the error. You can then look up that > > > > PTF and see what library it was going to update. > > > > > > > > Are you new to z/OS System Programming and SMP/E work? If so, it > > > > will help us to know that. > > > > > > > > The information you provide indicates this is may be a new > > > > function for you. > > > > > > > > Lizette > > > > > > > > > > > > > -----Original Message----- > > > > > From: IBM Mainframe Discussion List > > > > > [mailto:[email protected]] On Behalf Of Lizette Koehler > > > > > Sent: Sunday, January 12, 2014 4:41 AM > > > > > To: [email protected] > > > > > Subject: Re: z/OS 1.13 PTF apply Issue > > > > > > > > > > Some searches on the internet for IBM S106 > > 0F > > > > > brings up > > > > > > > > > > These messages and the ABENDS106-0F indicate that a link list ( > > > > > LNKLST ) > > > > library > > > > > has gone into additional extents. This could occur if SMP/E > > > > > maintenance > > > > was being > > > > > applied to the library > > > > > > > > > > So, if your LINKLST library is in EXTENTS (and LINKLST datasets > > > > > should > > > > not > > > > be > > > > > coded with Secondary Extents) then you will need to IPL. You > > > > > can use the > > > > TSO > > > > > function ISRDDN to see if the LINKLST is in extents. > > > > > > > > > > In ISPF on any command line issue TSO ISRDDN > > > > > > > > > > Then on the command line issue > > > > > LINKLIST > > > > > > > > > > It should highlight datasets in extents in your LINKLST > > concatenation. > > > > > > > > > > Another question. > > > > > > > > > > Is your SMP/E TLIBs your LIVE RUNNING datasets? If so, you > > > > > probably need > > > > to > > > > > change that. > > > > > > > > > > Applying maintenance to a live system can create problems. > > > > > > > > > > If you are running maintenance to a secondary SYSRES volume set. > > > > > Then > > > > make > > > > > sure your job is pointing to the correct volsers. > > > > > > > > > > Lizette > > > > ---------------------------------------------------------------------- > > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
