Hello,
Yes, Both RES volume are on same Maintenance level. Yes, its
production system but I can request customer to provide downtime window and
IPL system from another RES volume and then try applying PTF again.
I think this will be safest way to do now. I will also check my all LNKLST
dataset for PRIMARY allocation and a Secondary Allocation of 0 (zero). I
also verified that only root file system getting affected by these PTF, So
I have mounted that to /Service for safer side.
On Sun, Jan 12, 2014 at 10:19 PM, Lizette Koehler
<[email protected]>wrote:
> 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
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
