As with anything that has storage requirements, there is a limit. That limit might be enforced or might be "until you run out of the necessary storage". LNKLST sets are no different. There is no enforcement. The storage in this case is ECSA.
Terminology correction: There is a *current* LNKLST set. There can be any number of *active* LNKLST sets. An active LNKLST was current at some point but is still in use by some address space, whether it is still current or not. Once the last user of a non-current LNKLST set ends, the LNKLST set becomes inactive. It is true that new jobs and new address spaces are associated with the current LNKLST set. That association remains for the life of the job or address space unless you do a LNKLST UPDATE. Doing a LNKLST UPDATE is unpredictably dangerous, and can range from having no down side to abends to a wait state. There is little to no sympathy to be given to those who encounter the adverse effects because they did it to themselves.. The only thing that is safe is to let the system do the LNKLST assignments as it intends to do. 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
