Processing
Whenever Field-1 is equal to Field-2 write to putput file. If Field-1 not equal to Field-2 then all
the matching Field-2 should be taken and Field-3 is the total of all these matching records.
For example
Joined: 26 Nov 2002 Posts: 12372 Topics: 75 Location: San Jose
Posted: Fri Apr 08, 2005 5:29 pm Post subject:
Ace,
The following DFSORT/ICETOOL JCL will give you the desired results. If your shop has syncsort then change the pgm name to synctool
A brief explanation of the job.
The first copy step will split the input file into 2 different files. T1 will contain all the records where field1 = field2
T2 will contain rest of the records ie. not equal records. Now we need to sum up these records. so we add a constant value of 'notequal' to all the records. where as for the equal records we will add a sequm which will serve as a unique key
Also your data has an imbedded decimal point which cannot be used to sum. so we will eliminate the decimal point.
The next step concatenates the above 2 files and sorts on the first 8 bytes and sums on field3.
While writting to the output file we once again expand the file to the desired format using outrec.
Joined: 02 Dec 2002 Posts: 1618 Topics: 31 Location: San Jose
Posted: Fri Apr 08, 2005 5:31 pm Post subject:
With z/OS DFSORT V1R5 PTF UQ95214 or DFSORT R14 PTF UQ95213 (Dec, 2004), you can use DFSORT's new IFTHEN, OVERLAY and larger fields support to do what you want in one pass. If you have DFSORT, but the Dec, 2004 PTF is not installed, ask your System Programmer to install it. For complete details on all of the new DFSORT and ICETOOL functions available with the Dec, 2004 PTF, see:
I assumed that your 30-byte CH field1 is in positions 1-30, your 30-byte CH field2 is in positions 31-60, your 17-byte ZD field is in positions 61-77 and your input file has RECFM=FB and LRECL=80. If not, the job can be changed appropriately. Here's the DFSORT job:
Code:
//S1 EXEC PGM=ICEMAN
//SYSOUT DD SYSOUT=*
//SORTIN DD *
11111 11111 10099
22222 33333 20010
44444 33333 30020
55555 33333 100000
66666 66666 9009000
66666 66666 1200000
/*
//SORTOUT DD SYSOUT=*
//SYSIN DD *
* If field1 eq field2, add seqnum (1, 2, etc) in 81-88.
INREC IFTHEN=(WHEN=(1,30,CH,EQ,31,30,CH),OVERLAY=(81:SEQNUM,8,ZD)),
* If field1 ne field2, add seqnum of 0 in 81-88.
IFTHEN=(WHEN=NONE,OVERLAY=(81:+0,TO=ZD,LENGTH=8))
* Sort on field2 and the seqnum.
SORT FIELDS=(31,30,CH,A,81,8,ZD,A)
* Sum on ZD field.
* Records with field1 eq field2 will NOT be summed because the
* seqnum is different in each record.
* Records with field1 ne field2 and the same field2 will be summed
* because seqnum is the same (0) in each record.
SUM FIELDS=(61,17,ZD)
* Keep field2 and edit the ZD field. Remove the seqnum.
OUTREC FIELDS=(31:31,30,61:61,17,ZD,EDIT=(IIIIIIIIIIIIIIT.TT),80:X)
/*
_________________ Frank Yaeger - DFSORT Development Team (IBM)
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
Last edited by Frank Yaeger on Fri Apr 08, 2005 5:42 pm; edited 1 time in total
Joined: 02 Dec 2002 Posts: 1618 Topics: 31 Location: San Jose
Posted: Fri Apr 08, 2005 5:39 pm Post subject:
Kolusu,
I see that you used:
SUM FIELDS=(39,17,ZD)
but then used:
39,15,ZD,EDIT=(IIIIIIIIIIIIIIT),
Ace asked for PIC 9(15).99 for the summed output field which would require 17 digits. I assume you split the ZD field into two parts because Syncsort, unlike DFSORT, cannot convert more than 15 ZD digits. Note that with DFSORT, we can convert the 17-byte ZD field without splitting it. Of course, with DFSORT, we can also use IFTHEN to do this in one pass. 8)
Also, you said "your data has an imbedded decimal point which cannot be used to sum. so we will eliminate the decimal point". Ace said his input field is PIC 9(15)V99 so it's really a 17-byte ZD field without the embedded decimal point. As you know, COBOL doesn't actually store the decimal point. _________________ Frank Yaeger - DFSORT Development Team (IBM)
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
Last edited by Frank Yaeger on Fri Apr 08, 2005 5:47 pm; edited 1 time in total
Joined: 26 Nov 2002 Posts: 12372 Topics: 75 Location: San Jose
Posted: Fri Apr 08, 2005 5:46 pm Post subject:
Quote:
but ace asked for PIC 9(15).99 for the summed output field which would require 17 digits. Did you just ignore that because Syncsort, unlike DFSORT, cannot convert more than 15 ZD digits?
Yes ! I used 17 digits to sum and took the first 15 digits and used the edit mask and hard coded the decimal point and the placed the 16 and 17 digit from the sum there by creating 17 digits.
Quote:
Also, you said "your data has an imbedded decimal point which cannot be used to sum. so we will eliminate the decimal point". Ace said his input field is PIC 9(15)V99 so it's really a 17-byte ZD field without the embedded decimal point. As you know, COBOL doesn't actually store the decimal point.
My mistake I actually did not read ace's cobol declaration but assumed it from his input that he had an imbedded decimal point.
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
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
