0

I have a dataset with processed information, for 4 distinct departments, and I need to split it into one dataset per department. This is the general record structure:

XXXXXXX = irrelevant string

AAA = 3 letter alpha department ID

Record details are irrelevant, with variable amount of lines

000001 0000000000000000000000000000000000000XXXXXXXAAA171220150000              
000002 <irrelevant record details>
000003 <irrelevant record details>
000004 999999999999999999999999999999999999900000004000000000005700     
000005 0000000000000000000000000000000000000XXXXXXXBBB171220150000              
000006 <irrelevant record details>
000007 <irrelevant record details>
000008 <irrelevant record details>
000009 <irrelevant record details>
000010 <irrelevant record details>
000011 999999999999999999999999999999999999900000004000000000005700     
000012 0000000000000000000000000000000000000XXXXXXXCCC171220150000              
000013 <irrelevant record details>
000018 999999999999999999999999999999999999900000004000000000005700

How can I accomplish this using DFSORT and JCL?

kauedg
  • 827
  • 8
  • 20
  • 2
    We're here to assist you with problems with code. Look at WHEN=GROUP with BEGIN, END and PUSH an ID. Four OUTFILs, the first three working off the ID (INCLUDE=/OMIT=), the last using SAVE. – Bill Woodger Jan 05 '16 at 23:18
  • Note: OUTFIL will only work if you know in advance what the departments* are and code OUTFIL statements for each (with the output data set allocated to go with it). There is no "bucketing" in DFSORT in the sense of it discovering the department codes. * I use "department" here as that's what the questioner has as their key field. – Martin Packer Jan 06 '16 at 11:32
  • @BillWoodger I'm not very familiar with DFSORT and had a urgent task to accomplish, sorry about the question thing. – kauedg Jan 06 '16 at 18:54
  • @MartinPacker what would you call SAVE on OUTFIL, if not a "bucket"? – Bill Woodger Jan 06 '16 at 19:06
  • @MartinPacker I didn't mean to do "bucketing". The departments are previously known. – kauedg Jan 06 '16 at 19:30

1 Answers1

1

Here is a sample code for the solution using INREC WHEN=GROUP, for 2 departments:

//SRT0001    EXEC PGM=SORT
//SYSOUT     DD SYSOUT=*
//SORTIN     DD DSN=DATASET.IN,
//           DISP=SHR
//AAAOUT     DD DSN=DATASET.OUT.DEPAAA,
//           DISP=(,CATLG),AVGREC=U,SPACE=(150,(100,10),RLSE)
//BBBOUT     DD DSN=DATASET.OUT.DEPBBB,
//           DISP=(,CATLG),AVGREC=U,SPACE=(150,(100,10),RLSE)
//SYSIN      DD   *
 SORT FIELDS=COPY
   INREC IFTHEN=(WHEN=GROUP,
     BEGIN=(1,4,CH,EQ,C'0000'),
     END=(1,4,CH,EQ,C'9999'),
     PUSH=(151:45,3))
   OUTFIL FNAMES=AAAOUT,
     INCLUDE=(151,3,CH,EQ,C'AAA'),BUILD=(1,150)
   OUTFIL FNAMES=BBBOUT,
     INCLUDE=(151,3,CH,EQ,C'BBB'),BUILD=(1,150)
/*
kauedg
  • 827
  • 8
  • 20
  • 1
    That's not bad. Get rid of the second IFTHEN. Get rid of the AND in the first IFTHEN. If you know the names, and they can never be changed by the user, this would do. You can take the names out of the picture by PUSHing an ID instead of the name, then changing the INCLUDEs to look for zeros1 and zeros2. You use ID=N, where N is the length of the field and is long enough to contain your groups. If your description of the data is accurate, ID=1 would do. You could add another OUTFIL with SAVE and the BUILD, then all your input will appear on one of the OUTFILs somewhere. – Bill Woodger Jan 06 '16 at 19:35
  • @BillWoodger Very nice suggestion on the AND and IFTHEN statements. I'll edit with this improvement. I'm keeping the PUSH statement because it's numbering records from one department (eg. AAA) with different IDs (the department's records are not sequential). I don't know if I'm missing something here. – kauedg Jan 06 '16 at 21:38
  • 1
    Not necessarily missing something, it depends on the detail of your requirement. The problem with extracting on a "name" is that such things are prone to change, by a user. Something to watch for. You could look at using NULLOFL to set a Return Code/Condition Code of 4 for an empty OUTFIL dataset. For someone not very familiar with DFSORT, you seem to be picking it up quickly, which is good :-) – Bill Woodger Jan 06 '16 at 23:32
  • @BillWoodger there's no chance of this kind of user change to happen in the environment where this job will run. After sent to the mainframe it can only be changed by another IT analyst. I only knew the sorting basics, this was a hell of a challenge but thanks to the extensive IBM's documentation and your tips, it wasn't that hard. Thanks! – kauedg Jan 07 '16 at 16:26