IBM Mainframe Forum

Hello,

i compress a pds whith the jcl :



But sometimes the PDS : VTW.AW.TR is still open even if the batch is ended...

And i don't know why...

Do you know this problem ?

Do you know an other way to compress a PDS ?.

Or may be, i have to add a step ( at the end of JCL) to free teh PDS ?

Thanks for you Help.

You are playing with dynamite with a lit cigarette in your mouth. If you are compressing a data set, you need to use DISP=OLD in the JCL. If you do not, there is a chance that the PDS will be unusable after your job runs. Specifically, the compress is changing the directory pointers and if another program is doing the same, the directory could wind up pointing to an invalid location.

Hello and thanks for the answer.

I can expalin you what it happened...

The job which has done the compress was terminated with a RC = 0.

But a few hours letter, an other batch (TWS in my case) wanted to use the PDS but there was the error :

213-30 :

IEC143I 213-30,IFG0194D,AXRSPPN2,S15,PDS,A476,VGRP01,ADS.BV.RTP

But i don't anderstand why... because the job which has done the compress was ended foor hours before whith a RC =0 and good compress....

the compress was ended foor hours before whith a RC =0 and good compress....

Your mistakes are (1) thinking a return code zero on this compress job means it worked, and (2) thinking the compress was good when you had DISP=SHR on the data set.

Doing a compress when other jobs may be accessing the data set may work -- but it may leave some members of the data set unusable, and it may be hours - days - weeks until you know for sure (unless you go in and access EVERY member of the data set immediately). There may be only one member of the PDS destroyed, but most of the members could be gone. With DISP=SHR on a compress, you simply won't know without accessing the members.

I have done a compress on a PDS that required DISP=SHR. However, before I did so I made sure that the other jobs that had the data set open were not actively accessing the data set at the time, and I closed and reopened the data set in the applications as soon as possible to ensure the directory addresses were updated.

If you have not done so, consult your site support group for assistance. You may have to restore the PDS from back up and do a proper compress with DISP=OLD to get it compressed and available.

Hello,

Did you look up the message? The IEC messages (and others) are here:
http://publibz.boulder.ibm.com/cgi-bin/ ... 1/CONTENTS

Probably something to bookmark. . . It will be used often. . .

Whether you intend to properly recover the dataset or not, you need to inform others that the dataset is potentially corrupt. It is one thing to break something - it is another to keep it secret.

Hello,

the PDS is used by TWS :



The PDS i want compress is : XXX.AA.SAUV and you can see the DISP=SHR


If, in my job (compress) i take teh PDS with DISP=OLD, it will not works because of Conention with TWS...

Talk to your site support group about the problem. I don't work with TWS so I don't know it's capabilities. There may be a way for the support group to deallocate the file from TWS for a compress, or they may schedule a down time for TWS to do the compress.

However, if the file is used by TWS on an ongoing basis, you especially would not want to compress it while TWS is accessing it as there is an even higher chance of data set corruption.

OK if i anderstand, to compress a PDS, we have to allocate it with DISP=OLD.

No, it is safest to compress with DISP=OLD. The whole point of a compress is to recover space in a PDS, which means you are moving members around physically in the file. This means you are changing the directory entries to point to the new location. If you use DISP=SHR for a compress, the PDS will be compressed. However, any other programs that have the PDS open may have incorrect locations for member names as a result of the directory being updated. This means if these other programs attempt to write -- OR READ -- members of the PDS, they may be pointing to the wrong locatio0n and could wind up writing or reading data that no longer belongs to the desired member. The consequences of this could include complete loss of the PDS, mandating a restore from the last good backup (i.e., before the compress). And in the case of something like TWS, the directory may have been read into memory when the data set was opened so TWS can use the cache instead of doing disk I/O every time the data set is accessed. Hence it could be a long time between the compress and TWS finding out that its access to the data set is no longer accurate.

OK thanks.