I wanted to ask if it is possible to concatenate multiple PDS Members with multiple PS files and write the data in the PS file. I have PDS Members like MEMBER1, MEMBER2 & MEMBER3 and 2 PS files - TEST.DUMMY.FILE1 & TEST.DUMMY.FILE2 . Please note that the Record Length of Members and Files are same.
I want to concatenate the data of these members and files like below :
MEMBER1
MEMBER2
TEST.DUMMY.FILE1
TEST.DUMMY.FILE2
MEMBER3
The data inside the Members and Files are as follows :
MEMBER1 :
Code:
This is row One.
This is row Two.
This is row Three.
MEMBER2 :
Code:
This is row Four.
This is row Five.
File1 - TEST.DUMMY.FILE1 :
Code:
This is row Six.
File2 - TEST.DUMMY.FILE2 :
Code:
This is row Seven.
MEMBER3 :
Code:
This is row Eight.
This is row Nine.
This is row Ten.
and OUTPUT File should have data like :
Code:
This is row One.
This is row Two.
This is row Three.
This is row Four.
This is row Five.
This is row Six.
This is row Seven.
This is row Eight.
This is row Nine.
This is row Ten.
Please let me know if anyone knows a way to achieve this in JCL using SORT or any other utility.
The reason for the VOL=REF=*.SYSUT1 in step D is when you "pass" a data set, like &&PDS, there is just one entry for the data set. The first reference used the entry; the VOL=REF, in essence, reused the entry. I will admit, though, it is awfully clumsy.
My original intention was to concatenate the data sets in the order &&SEQ1, &&PDS(M1), &&SEQ2, and &&PDS(M2), but that didn't work, and I couldn't use the VOL=REF trick.
My original intention was to concatenate the data sets in the order &&SEQ1, &&PDS(M1), &&SEQ2, and &&PDS(M2), but that didn't work, and I couldn't use the VOL=REF trick.
In my memory, temporary DSNAMEs are not accepted in multiple DDs of the same job step, even with VOL=REF= trick?
I cannot test it right now. Maybe, it depends on zOS version/settings? I was faced same problem years ago.
P.S.
The TS did not mention anything specifically about &&DSNAMEs; but with regular DSNAMEs this concatenation has no problem, except possible mismatch in DCB parameters:
1) All RECFM must match each other
2) For RECFM=FB - all LRECL must be equal, and the first BLKSIZE must be not less than any of subsequent BLKSIZEs
3) For RECFM=VB - both first LRECL and BLKSIZE must be not less than those of any of subsequent datasets.
Again: all said above has nothing to do with the "fix" found by TS - SORT FIELDS=COPY!
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
sergeyken wrote:
...
The TS did not mention anything specifically about &&DSNAMEs; but with regular DSNAMEs this concatenation has no problem, except possible mismatch in DCB parameters: ...
2) For RECFM=FB - all LRECL must be equal, and the first BLKSIZE must be not less than any of subsequent BLKSIZEs
3) For RECFM=VB - both first LRECL and BLKSIZE must be not less than those of any of subsequent datasets.
...
I used temporary data sets in my example to encapsulate everything into a single job, despite the slightly weird JCL in the last step.
In Sergeyken's point 2, the BLKSIZE rule has not been correct for many, many years. Data management automatically uses the largest BLKSIZE in the concatenation.
In point 3, I do not know about LRECL. I see no reason why LRECL in data set 1 must be greater than LRECL in data set 2. There is the question about the LRECL stored in the DCB: short of a direct test I do not know whether the largest LRECL in the concatenation goes to the DCB or the first LRECL in the concatenation goes to the DCB.
In this thread we have mostly discussed sequential concatenation, not PDS concatenation. Slightly different rules apply with PDS concatenation than with sequential concatenation.