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 is 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.
If an LNKLST PDS has expanded into a secondary extent since the most recent IPL, a program can use either of the following methods to access a member in the secondary extent:
OR
SETPROG LNKLST,DEFINE,NAME=new,COPYFROM=CURRENT
SETPROG LNKLST,ACTIVATE,NAME=new
Now all address spaces that start while this new LNKLST set is current can able to access modules in the new extent. Address spaces that existed prior to this new LNKLST set becoming current will still not be able to access modules in the new extent.
SETPROG LNKLST,UPDATE,JOB=*
There is some risk associated with this command (ABEND106 errors could result) and therefore it is recommended that this command be used only when necessary to prevent an IPL. Please see the SETPROG command in z/OS MVS System Commands for more important information about this option.