Posted: Fri Mar 10, 2006 5:33 am Post subject: Compressing a PS file in batch
Hello,
We are in the process of testing 100+ jobs where in we have to run JOBs with the production data. We are facing problems due to lack of space as there are almost 1300+ output files involved/created by different JOBS. We need to have all the datasets under the same HLQs (like MYID.PROD.RUN.*). Based on the HLQs, the volumes are alloted. Upon raising this issue to the support people, we were told to compress the datasets. I am looking for a batch utility where in I can compress all these 1300+ files. I tried using IEBCOPY, but looks like this is only for compressing PDS. The following is the error message I got:-
IEB120I A VALIDATION ERROR
IEB178I NOT AN IEBCOPY UNLOADED DATA SET - 1ST PHYSICAL RECORD NOT 64 BYTES LONG
IEB1030I DDNAME A REFERS TO PDSU DATA SET ON VOLUME ADT103 NAMED ADT.TSTF.L4D.SYST.POLF.DATA.MERGED.RED01
IEB1096I NO MEMBERS MOVED IN DATA SET REFERENCED BY B
IEB151I JOB HAS TERMINATED WITH ERROR(S)
IEB147I END OF JOB - 8 WAS HIGHEST SEVERITY CODE
Alternatively you can do all this in two other automatic ways, rather than yours:
Option 1.- Get all the HLQs from an IDCAMS listcat output, Then Generate and execute the compress JOB. ICETOOL/DFSORT/SYNCSORT can be an alternative to generate the Compress job
Option 2.- Let Rexx do all the JOB, that is searching for all the HLQ (Look for LISTDSI Instruction, and .. LM* Ispf services ), and using your compresss criteria, just inoke IEBCOPY "in the fly" _________________ Best wishes,
Joined: 03 Jan 2003 Posts: 1014 Topics: 13 Location: Atlantis
Posted: Fri Mar 10, 2006 11:37 am Post subject:
What exactly do you mean by "compress"? Compressing a PDS is not the same as using data compression. Do you mean just releasing free space or do you actually want to alter the data in the files so they take up less space?
Also I have a doubt. All these files have been created with the RLSE parameter. Won't this release unused space when the JOB is over? But then 1300+ files is huge? Please correct me if I am wrong.
Assuming they're sequential files, IEBCOPY won't do a thing for you. And if, as you say, they're being allocated with the RLSE parameter, any unused space you're allocating should become available to you.
I would be interested to see whether the space issue is because you can't allocate enough in the first extent, or you're using up the volume entirely. If, for example, your files are 64kB each, but you've allocated 1MB in the first extent, then you'll continue producing output until you have less than 1MB available in a single extent... whereas, if you had your allocation parameters set to 64kB, you'd get another 16 datasets done in that space.
But assuming that this isn't the case, and you're actually running out of DASD, you could:
1) Add more volumes to the SMS storage group.
2) Send them instead to TMM, if you're using it, or direct to tape if you're not.
As posted previously, compress is meant to be in partitioned datasets ONLY, it doesn't make sense nor is possible to do it in PS.
Data is PS is stored SEQUENTIALLY, while in partitioned datasets, it is true only at the beggining. If you happen to update any member, an update copy of it will be generated at the end of it, the previously used space remains there and you won't be able to use it anymore (unless you had an alias of course). The compress preccess just reclaims those unused spaces in your dataset.
The question you should answer is why do you need to do something like this? Do you think that your PS has too much space and you do not need that much? Also you foresee a zero growth rate for your dataset? In those cases what you need is to FREE the extra space, as opposed to compress the PS Dataset.
Answering those questions may bring you back to one of my original suggestion, again with Rexx (and that is not the only way to do it!) you can determine the recfm of the dataset, and build the appropiate jobsted, whether this is a IEBCOPY compress or a space free step is another thing. _________________ Best wishes,
The VOLSER is what we creating datasets on. Does this give you any insight of what the problem could be?
Note: I am not able to paste the table properly. Read the %values (like 10%,7%) as the 'free space' in the volser. The column just left to it is the free space in MB. The last column (129MB,23MB) as the 'largest free xtent' available for the VOLSER.
German,
Yes. Going by the suitability, REXX would be the best option to do. (Sorry I do not know REXX so that I can create a utility thru it. I have been using only those which are readily avaiable ones. ) But I do not have access to add my own utilities to the library .
Ok Let's give it a try, this solution isn't fully tested AND there are limitations, I will point them out at the end of this post.
First of all, choose your way to..., and feel free to change my selection:
a) Compress a PDS ==> I choose IEBCOPY
b) Free unused space os PS ==> I choose ADRDSSU
I am gonna make a skel and a rexx, you may do it all from inside one rexx cmd, however using skeletons seems to be easier IMO. Having said so, the Skel will work based in TWO temp tables (built inside the rexx exec), one for PDSs and another one for PS, namely PDSs and PSs respectivelly. So my Skel (MYSKEL) looks like:
Address ISPEXEC
"lmdinit listid(id) level("||hlq||")"
If rc \= 0 then return
dsvar = ' '
retrc = 0
"TBOPEN PDSs nowrite share"
Select
When Rc = 0 Then nop
When Rc = 8 Then Do
"TBCREATE PDSs Names(Dsvar)"
If rc /= 0 Then Do ,
Say "Problem defining Pdss table"
Exit 04
End /* rc /= 0 */
End /* Rc = 8 */
Otherwise Do
Say "Problem Opening Pdss table"
Exit 04
End /*Otherwise */
End
"TBOPEN PSs nowrite share"
Select
When Rc = 0 Then nop
When Rc = 8 Then Do
"TBCREATE PSs Names(Dsvar)"
If rc /= 0 Then Do ,
Say "Problem defining Pss table"
Exit 04
End /* rc /= 0 */
End /* Rc = 8 */
Otherwise Do
Say "Problem Opening Pss table"
Exit 04
End /*Otherwise */
End
A word of caution here, when building JCLs, you should check for the number of DDnames in a Step, I am not checking it out, but if you have the amount of datasets you mentioned you should add that simple check or build the jcl, and split it out.
Also, since you plan to do it masivelly you should have some sort of back up just in case anything goes wrong.
Last but not least, take a look at the service guide manual, under LMDLIST, there are several other pool variables set by this service, which may be of some help to your endeavors (hint: There is even one for FREE USED SPACE) _________________ Best wishes,
Joined: 03 Jan 2003 Posts: 1014 Topics: 13 Location: Atlantis
Posted: Wed Mar 15, 2006 7:34 pm Post subject:
I'm confused. Was the original question about PDSes or PS (sequential) data sets?
Sequentials can be stored in a compressed format using ISPF's Packed format (see the ISPF manual for services that can do this; LMCOPY, or EDIT come to mind), but then you need to use ISPF to unpack them or at least to browse or edit them.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum