Saying that the problem of multiple extents applies only to LNKLST data sets is, I believe, incorrect. If the data set can be extended after it has been opened, whether the data set is in the LNKLST or some other concatenation, a fetch of a module that is now in the new extent will fail because the directory entry will point into the new extent and that extent will not be defined in the DEB.
For something other than the LNKLST, the program could close and re-open (or the job could be started and restarted), but it still would have encountered the problem. For the LNKLST, if the job encountering the problem can be restarted, then creating and activating a new LNKLST set will work. If the job was already running and must stay running, then the unpredictably dangerous LNKLST UPDATE could be used after creating and activating. IBM Health Checker for z/OS Check(IBMCSV,CSV_LNKLST_SPACE) alerts you when you have a data set with more than 1 extent. FWIW, the limit of extents for the LNKLST is 255. The limit is something like 119 for normal concatenations (the number depends on how many data sets contributed to the total number of extents). And if you're wondering why it's different for the LNKLST, in part it relates to DEBCHK. The DEB for things opened by OPEN must fit within 4K. But the LNKLST is not opened by OPEN (and would not pass DEBCHK if that were tried). For the LNKLST, the limit comes from the number of extents being represented by a 1-byte field. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
