MVSFORUMS.com

[Meg]

I have a NDM JCL to NDM a PDS from 1 region to another region. This NDM is run regularly and the PDS on the other region is in the SHR mode. But we face a problem after running this JCL a number of times. It abend with 0E37 as it runs out of space though the number of members remains the same always. This is because we are not compressing the dataset while NDMing everytime. Can anyone let me know if there is any way to accomplish compression of a PDS while NDM the dataset.
Thanks,
Meg

[superk]

I would:

1. Have a compression job that runs before your Connect:Direct (NDM) job starts.

2. Change the datasets from PDS to PDS/E and eliminate the need to compress at all.

3. Use a RUN JOB step in your C: D process to submit a compress job after a successful copy.

4. Use a RUN TASK step in your C: D process to call IEBCOPY and compress after a successful copy.

[Meg]

1. Have a compression job that runs before your Connect:Direct (NDM) job starts.
I don't think the above option will work in our case as we want a compressed dataset at the other region and not on the region from where the PDS is NDMed.
2. Change the datasets from PDS to PDS/E and eliminate the need to compress at all.
Could you please explain how the conversion will eliminate the need for compressing.
3 and 4 will not work I think as we have specific procs that have the copy step and we will not be tampering the proc. But if possible do eloborate on points 3 and 4.
Thanks,
Meg

[kolusu]

Meg,

Connect Direct formerly known as NDM has the capability of compressing the sending data. The parm COMPRESS specifies that the data is to be compressed, reducing the amount of data transmitted as the file is copied from one node to another. The file is automatically decompressed at its destination. The default subparameter for the COMPRESS parameter is PRIMEchar=X
_________________
Kolusu
www.linkedin.com/in/kolusu

[superk]

Meg, your response doesn't leave you with many options. I don't know the first option should pose any issues, but if you say so .....

For the second option, I don't want to elaborate too much on the differences between datasets allocated as PDS and those allocated as PDS/E(xtended). I would suggest that you talk this over with your storage management team, or that you do some more research on the differences between the two. One documented benefit is that PDS/E datasets manage their own unused space automatically, and hence do not require any type of compression. I've read some posts that indicate that there may be a trade-off as to the time required for the system to locate a member from the directory list and subsequently process the member, so that might have to be taken into account.

For the last two items:

A process can contain not only COPY statements but entire groups of logical operations and other statements such as RUN JOB or RUN TASK. The RUN JOB statement does as it says - it submits the indicated job, from the indicated library, directly to the Internal Reader, at either the primary (PNODE) or secondary (SNODE) side of the connection. The RUN TASK statement runs an executable program, which resides in the CONNECT:Direct linklist, with optional parameters. All of these statement can be grouped together logically, such as:

MYPROC PROCESS ...

COPY01 COPY FROM(PNODE DSN=..... -
TO(SNODE DSN=.....) COMPRESS EXTENDED

IF (COPY01 EQ 0) THEN
RUNJ01 RUN JOB (DSN=THE.PDS(THEMEMBER) SNODE)
ELSE
FAIL01 RUN TASK (PGM=SOMEPGM PARM=(SOMEPARM)) PNODE
EIF

[Meg]

Thanks Kolusu and SUPERK,
It was much simpler to use COMPRESS in the JCL for me but could know more from superk's inputs too.
Meg