Joined: 26 Nov 2002 Posts: 12375 Topics: 75 Location: San Jose
Posted: Thu Dec 26, 2002 7:13 am Post subject:
Himesh,
You can achieve the results in 1 single step instead of 2. You also don't need the sysprint statement in your jcl as well as the DCB parameter.
Code:
//STEP010 EXEC PGM=SORT
//*
//SYSOUT DD SYSOUT=*
//SORTIN DD DSN=YOUR INPUT FILE,
// DISP=SHR
//SORTOUT DD DSN=YOUR OUTPUT FILE,
// DISP=(NEW,CATLG,DELETE),
// UNIT=SYSDA,
// SPACE=(CYL,(X,Y),RLSE)
//SYSIN DD *
INREC FIELDS=(1,9,X'001C') $ TOTAL LRECL OF 9 + CONSTANT 1
SORT FIELDS=(1,9,CH,A) $ SORT ON LRECL
SUM FIELDS=(10,2,PD) $ SUM ON CONSTANT
OUTFIL INCLUDE=(10,2,PD,EQ,1), $ INCLUDE ONLY WHEN THE SUM IS 1
OUTREC=(1,9) $ REMOVE THE CONSTANT AT THE END
/*
Joined: 20 Dec 2002 Posts: 80 Topics: 21 Location: Chicago
Posted: Thu Dec 26, 2002 8:04 am Post subject:
Yes kolusu,
The 2 steps was an oversight.
By default i used to code SYSPRINT for all the utility PGMs!
instead of keeping track of, when to use them and when not....
But the DCB was deliberately used. I felt it is useful, when manipulating files (like varying the LRECL etc...). So better off remembering the same and using it everywhere.
Joined: 26 Nov 2002 Posts: 12375 Topics: 75 Location: San Jose
Posted: Thu Dec 26, 2002 8:14 am Post subject:
Himesh,
Sort products have a parm SDB(system-determined blocksize).The default is SDB=ON which means that the system will determine the best blocksize for new or previously allocated but unopened DASD output data sets except for
A BLKSIZE found in the JCL DCB specification
A BLKSIZE derived from an available tape label
A VSAM data set
So I would recommend that you DO Not code the DCB parm.Also the Lrecl of the output dataset is calcualted by the outrec fields. Unless you want to override it, you dont have to code the lrecl.
Joined: 26 Nov 2002 Posts: 12375 Topics: 75 Location: San Jose
Posted: Thu Dec 26, 2002 9:35 am Post subject:
Himesh,
you will have no problems whatsoever to read the file manipulated by jcl as long as the program has this line coded when defining the file
Code:
Block contains 0 records
Block contains 0 records indicates to the system that information about blocksize should be taken either from JCL or Label. This is done to avoid recompilation of the pgm any time the data set blocksize is changed.
Joined: 02 Dec 2002 Posts: 1618 Topics: 31 Location: San Jose
Posted: Thu Dec 26, 2002 11:09 am Post subject:
Kolusu is right that DFSORT will determine the output RECFM, LRECL and BLKSIZE automatically. So it's best not to specify them unless you want to set them differently then DFSORT would.
Note that if you specify the RECFM and/or LRECL, but not the BLKSIZE, DFSORT will still set the system determined BLKSIZE. However, if you specify the BLKSIZE, DFSORT will use that BLKSIZE instead of the system determined BLKSIZE.
For complete information on DFSORT's SDB options, use the following link and then do a find on "SDB=":
Lets take into consideration something else but similar.
Code:
File:
Field1 - 5
Field2 - 3
Field3 - 4
Field sizes are random. Thus we have something like
AAAA1 BB1 CCC1 (Spaces not there, given for clarity)
AAAA1 BB1 CCC1
AAAA1 BB2 CCC2
AAAA2 BB1 CCC2
AAAA2 BB1 CCC3
This file can have a lot of duplicates. The output file required is as below:
Code:
AAAA1 BB1 CCC1 (Spaces not there, given for clarity)
AAAA1 BB2 CCC2
What is happening is
1) All duplicates records are sent to output once. (Use option FIRST)
2) All single records are also sent to output.
3) All records with FIELD1 and FIELD2 matching but FIELD3 differing are eliminated altogether.
Can this be done through a JCL, and if so how? What I have thought is the first step would be to do the elimination using FIRST as previously mentioned. What about the next step. How would that have to be done? Can this be done in a single step?
Another question, do we have to sort the input file before running these JCL's or can the input file records be in any order.
Joined: 02 Dec 2002 Posts: 1618 Topics: 31 Location: San Jose
Posted: Mon Mar 03, 2003 11:12 am Post subject:
Monaj,
I'm not sure I fully understand what you want to do, but as for 1) and 2), FIRST will do both of them. FIRST keeps the first record with each value, so it keeps all "single records" (by which I think you mean records with unique keys) and the first record of each set of records with duplicate keys.
Note that the FIRSTDUP option of DFSORT's ICETOOL will do 1) without doing 2), that is, it keeps the first record of each set of records with duplicate keys, but does not keep unique records.
To answer your second question, SELECT does a sort using the ON fields as the key, so the input records can be in any order.
I think I got you a little confused on what I was trying to say.
Lets separate the 2 parts. For 1 and 2, the FIRST option works perfectly. Say we use the FIRST option on the input file and the output we now have is as follows (which we would use for input as the next step).
Thus, now we have all unique records. The next output would be as follows.
Code:
AAAA1 BB1 CCC1
AAAA4 BB4 CCC4
AAAA5 BB5 CCC5
Now, as I typed this out, I realised that if we do a select with NODUPS on the first 8 as the key, we would get the desired result, which i did get. Also that it could be done in 1 step. So, the prob is solved.
Joined: 07 Jan 2003 Posts: 1056 Topics: 91 Location: The Blue Planet
Posted: Thu Mar 25, 2004 1:13 am Post subject:
Can the following be done via SORT. (comparison of two files)
Code:
File: 1
AAAAA 111222333
BBBBB 444
CCCCC 111
File: 2
AAAAA 111333
BBBBB 555
CCCCC 222
Output:
AAAAA 222
BBBBB 444
BBBBB 555
CCCCC 111
CCCCC 222
There are two fields here, the first one of 5 bytes (AAAAA, BBBBB ...) and the 2nd field of 3 bytes which can repeat itself 10 times (max). (111222333....) i.e PIC X(3) OCCURS 10 TIMES DEPENDING ON WS-COUNT
The files should be compared on the entire record length. In case of first comparison b/w "AAAAA 111222333" and "AAAAA 111333", Since the field 2 with value 222 is not common between these two records the output should contain "AAAAA 222".
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum