I am not sure you have a problem. When you issued the FREE SPACE command against the PARMLIB data set, you only force it to go back to the primary space if it could. For instance, if your SYS1.PARMLIB had CYL 1,1 and had 5 extents, then the free would would have left it CYL 1,1 but maybe now down to 1 extent. It is not an issue unless something is looking for a member at the exact TTR location it was before.
I would first issue a D GRS,RES=(*,SYS1.PARMLIB) and see what has it in current allocation (yes there are other methods). Next I would review the allocation (option 3.2 or 3.4) and see what the FREE did. You maybe okay. The free does not reduce your secondary allocations or remove what was there. It is more like a Compress. F - Free unused space - not destroy data set. Lizette > > Hi all, > Ugh - Long days & short nights has taken it's toll on me. Instead of > viewing > our shared SYS1.PARMLIB with 'V' in ISPF, I instead freed it with 'F'. > Yeah I > know, F & V are not even on the same row on the keyboard. Now > SYS1.PARMLIB is 100% used. I've allocated 'SYS1.PARMLIB.SIZE' with the > original primary, 0 secondary. Would it be safe to: > > 1) IEBCOPY the freed SYS1.PARMLIB into the SYS1.PARMLIB.SIZE, > 2) rename the freed SYS1.PARMLIB to SYS1.PARMLIB.DONT.DELETE, > 3) finally rename SYS1.PARMLIB.SIZE to SYS1.PARMLIB? > > Searching the archives makes me think I'd be fine, what with all of the > topics > relating to compressing PARMLIB, but I'd rather ask outright about the > whole > rename/swap idea. > > I have system specific PARMLIBs concatenated before SYS1.PARMLIB, so any > required changes could be made there if D37 issues arise before the next > IPL. ---------------------------------------------------------------------- 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
