|
View previous topic :: View next topic
|
| Author |
Message |
Poha Eater
New User
Joined: 31 Aug 2016
Posts: 74
Location: India
|
|
|
|
Hi All,
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 :
File2 - TEST.DUMMY.FILE2 :
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. |
|
| Back to top |
|
 |
Nic Clouston
Global Moderator
Joined: 10 May 2007
Posts: 2454
Location: Hampshire, UK
|
|
|
|
| Have you tried? If not why not? If you did - what happened? |
|
| Back to top |
|
|
Poha Eater
New User
Joined: 31 Aug 2016
Posts: 74
Location: India
|
|
|
|
Hi Nic,
Please delete this post from the forum as now i have realized the question was too basic. I achieve the expected result with just the
I dont know why i was under such misconception. |
|
| Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008
Posts: 2286
Location: USA
|
|
|
|
| Poha Eater wrote: |
| I dont know why i was under such misconception. |
The major misconception is: DD statements concatenation in JCL has nothing to do at all with the statement SORT FIELDS=COPY of a SORT utility...  |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
In my opinion, Nic is correct: Poha Eater really should have simply tried it using, perhaps using JCL like this -
| Code: |
//A EXEC PGM=IEBUPDTE,PARM=NEW
//SYSPRINT DD SYSOUT=*
//SYSUT2 DD DISP=(,PASS),UNIT=SYSDA,SPACE=(TRK,(1,1,1)),
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=800),DSN=&&PDS
//SYSIN DD *
./ ADD NAME=M1
M1 R1
M1 R2
./ ADD NAME=M2
M2 R1
M2 R2
//B EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD *
SEQ1 R1
SEQ1 R2
//SYSUT2 DD DISP=(,PASS),UNIT=SYSDA,SPACE=(TRK,(1,1)),
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=800),DSN=&&SEQ1
//SYSIN DD DUMMY
//C EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD *
SEQ2 R1
SEQ2 R2
//SYSUT2 DD DISP=(,PASS),UNIT=SYSDA,SPACE=(TRK,(1,1)),
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=800),DSN=&&SEQ2
//SYSIN DD DUMMY
//D EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DISP=OLD,DSN=&&PDS(M1)
// DD DISP=OLD,DSN=&&SEQ1
// DD DISP=OLD,DSN=&&SEQ2
// DD DISP=OLD,VOL=REF=*.SYSUT1,DSN=&&PDS(M2)
//SYSUT2 DD SYSOUT=*
//SYSIN DD DUMMY |
The SYSUT2 data set in step D contained this:
| Code: |
M1 R1
M1 R2
SEQ1 R1
SEQ1 R2
SEQ2 R1
SEQ2 R2
M2 R1
M2 R2 |
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. |
|
| Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008
Posts: 2286
Location: USA
|
|
|
|
| steve-myers wrote: |
| 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! |
|
| Back to top |
|
|
steve-myers
Active Member
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. |
|
| Back to top |
|
|
|
|
  |
All times are GMT + 6 Hours |
|
