Why anyone would want to do this, I have no idea. Extents do not cause problems. Adding to existing data sets resulting in new extents is what causes problems. That is why IBM recommends that you allocate your LNKLST PDSs so that they cannot have secondary extents. That just makes it so that you get alerted (by a failure) if your addition of a module would have caused a new extent -- it just indicates 'no room at all'.
If you had asked how to compress, or delete, a data set that is in the LNKLST, the process is the same, so let's proceed on that basis. Start from the realization that it is not OK to compress or delete a data set that someone has allocated. For those reasons, the system (in the XCFAS address space, but not XCF processing itself) allocates each LNKLST data set. And LLA does the same. So the key, overall, is to make it so that the system does not have the data set allocated (at which point you can do whatever you want with that data set). And the system will no longer have the data set allocated when that data set is not in any active LNKLST set and is not being managed by LLA. (This procedure, more or less, can be found in the documentation of the CSVDYNL macro, under the CHECKSYS1=NO operand) 1.LNKLST DEFINE NAME(PROD01) COPYFROM(CURRENT) 2.LNKLST DELETE NAME(PROD01) DSNAME(MODULE.NAME) 3.LNKLST ACTIVATE NAME(PROD01) 4.LNKLST UPDATE JOB(*) As always, I add the caution here that any UPDATE is unpredictably dangerous, but if the alternative is re-IPL, might be worth it. After the UPDATE, the only active LNKLST set is PROD01 which does not have MODULE.NAME so LNKLST processing does not have MODULE.NAME allocated. Now that only PROD01 is active, the system, knowing that any other LNKLST sets are inactive can close their DCBs which frees the DEB. BUT, note that this is not done for the IPL-time LNKLST set (whose DCB is pointed to by CVTLINK) for compatibility reasons, protecting against customer or vendor programs that might be looking at that DCB / DEB. 5.STOP LLA or (in CSVLLAxx) REMOVE(MODULE.NAME) and MODIFY LLA,UPDATE=xx. After this, LLA will no longer be managing MODULE.NAME so LLA will not have that data set allocated 6.Do whatever you want to MODULE.NAME (compress, copy to "old", allocate a new one with no secondary extents, copy from "old" back to the "new" 7.LNKLST ACTIVATE NAME(previous) The previous LNKLST set (the one that was "current" before you worked with PROD01 is perfectly usable. 8.LNKLST UPDATE JOB(*) You need this only if existing address spaces need to use MODULE.NAME. Otherwise, it can be omitted, since new address spaces will be assigned to the "previous" LNKLST. Since MODULE.NAME is now in an active LNKLST set, LNKLST processing will have allocated it. PROD01, no longer active, has its DCB closed (and as a result) DEB freed. 9.START LLA or (in CSVLLAxx) LIBRARIES(MODULE.NAME) and MODIFY LLA,UPDATE=xx Now LLA is once again managing MODULE.NAME. Note that it would be wholly incorrect to use the LNKLST UNALLOCATE function to get LNKLST processing to release its allocation. That function is intended only to allow you to manipulate uncataloged data sets of the same name as a data set in an active LNKLST set. >If the module is share across several systems do >F LLA,REFRESH I did not understand what this is for. If the data set is shared across several systems, the same process must be done on all those systems. If you are updating a data set that is allocated by some system, all bets are off. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
