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

Reply via email to