Re: Best practice of reducing the extent of PDS defined in lnklst
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
Re: Best practice of reducing the extent of PDS defined in lnklst
On Thu, 2 Jun 2005 07:46:07 -0400, Peter Relson <[EMAIL PROTECTED]> wrote: >... >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. >... >1... >... >9... I'm way out of my area of expertise here - couldn't get much farther - so I may be way off base, but I think this is also the procedure needed to get space freed in a linklist PDSE. You just don't have to do anything between freeing it and reallocating it. But if you don't go through the procedure, freed space doesn't get reclaimed. At least that used to be the case. And I think "system" means "all systems in a Sysplex". Pat O'Keefe -- 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
Re: Best practice of reducing the extent of PDS defined in lnklst
On Thu, Jun 02, 2005 at 07:46:07AM -0400, Peter Relson ([EMAIL PROTECTED]) wrote: [...] > 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. Agreed. So, how do you do this? Specify a secondary allocation of 0? What about the following (incorrect but extremely common) JCL? // EXEC whateverCL //SYSLMOD DD DISP=SHR,DSN=some.linklist.dataset That seemingly-reasonable JCL will allow secondary extents to be allocated. Why? Because all of the IBM-supplied whateverCL procs have //SYSLMOD DD UNIT=something,DISP=(MOD,PASS),SPACE=(t,(p,s)) . Since, as touched on in another thread, the //SYSLMOD override doesn't nullify keywords in the proc which weren't on the override, the secondary quantity "s" is applied on a one-time basis and a secondary extent can be taken. The "fix" for this is to specify // EXEC whateverCL //SYSLMOD DD DISP=SHR,DSN=some.linklist.dataset,SPACE= Now, how many people do that? Even ignoring the linklist issue, this design problem wreaks all kinds of havoc. If the in-proc DD contains RLSE (because after all it was set up for a temporary dataset), then you end up with a bunch of tiny extents. And if the allocation type specifications are different, you can get track-allocated secondary extents in datasets which were allocated CYL or ROUND. I won't even mention what happens to libraries with blocksizes less than the maximum when the SYSLMOD in the proc contains a BLKSIZE= value larger than the dataset's original blocksize. (I don't know about now, but in the past, compressing such a dataset with IEBCOPY would destroy it because IEBCOPY would move members until it encountered a block larger than the blocksize, then it would bail without updating the directory for the already-moved members.) Personally, I think the quick fix for this would be to risk breaking poorly written JCL by completely removing SYSLMOD from all whateverCL procs. This is why I have used only my own custom-written whateverCL procs for the last 30 years. My personal rule of thumb: vendor supplied JCL is *always* wrong. /Leonard -- 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
Re: Best practice of reducing the extent of PDS defined in lnklst
A reason I did not mention PDSEs is that you cannot delete a PDSE that was in the IPL-time LNKLST regardless of whether it is no longer in any active LNKLST set. PDSEs do have extents (to my way of thinking) but for LNKLST purposes (DEB) they count only as one so the problem of expanding into a new extent does not exist for them. But it is quite possible that the problem of needing to free up now-unused space does exist. >And I think "system" means "all systems in a Sysplex". Not really true. The operations done on the data set are system-specific. You might have to do them on all systems in the sysplex that are sharing the data set. But releasing an allocation on "system A" has no bearing on the allocation that "system B" might have. 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
Re: Best practice of reducing the extent of PDS defined in lnklst
On Fri, 3 Jun 2005 07:56:08 -0400, Peter Relson <[EMAIL PROTECTED]> wrote: >A reason I did not mention PDSEs is that you cannot delete >a PDSE that was in the IPL-time LNKLST regardless of whether >it is no longer in any active LNKLST set. Thanks, I never knew that. Probably because I never tried it. :-) Is that documented anywhere?Ya learn something new every day! Mark -- Mark Zelden Sr. Software and Systems Architect mailto: [EMAIL PROTECTED] Systems Programming expert at http://Search390.com/ateExperts/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Re: Best practice of reducing the extent of PDS defined in lnklst
On Fri, 3 Jun 2005 07:56:08 -0400, Peter Relson <[EMAIL PROTECTED]> wrote: >... >>And I think "system" means "all systems in a Sysplex". >Not really true. The operations done on the data set are >system-specific. You might have to do them on all systems >in the sysplex that are sharing the data set. ... That was what I mean. You apparently failed to read my mind. You said "...So the key, overall, is to make it so that the system does not have the data set allocated ...". I was trying to say that should be "... make it so that all system in the sysplex do not have the data set allocated ...". Pat O'Keefe -- 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
