I have requirement to compare key information from two input files and write the matched records in third file and unmatched records in fourth file.
The key from 1st input file s in packed decimal format whereas in second input file it is present as numeric.
File 1:
Acnt num (1: 6) packed decimal.
acnt info (7: 100) char
Total logical rec length 100.
File 2:
Acnt num 1: 10 num
Acnt mon info 11:200
Total logical rec length 200.
DFSORT issues two types of user abends at run time:
If ABEND or ABSTP is in effect and DFSORT terminates with an error message, you receive a user abend. With installation option ABCODE=MSG (the supplied default), the user abend code is equal to the error message (for example, U0046 for message ICE046A). With installation option ABCODE=n, the user abend code is equal to n (for example, U0010 with ABCODE=10 for any error message). For user abend codes that are error message numbers (ABCODE=MSG), you can refer to the explanation for the corresponding message (for example, the ICE046A Explanation for U0046).
For a tape work data set sort or conventional merge, user abend 0 can be issued if DFSORT terminates with an error message and ABEND or ABSTP is in effect.
If you receive a user abend with a code from 1000 through 1599, DFSORT detected an error in its internal logic. The abend is issued in this case to prevent infinite loops and to aid diagnosis of the problem. Please report such problems to your IBM representative.
In some cases, you may be able to bypass a DFSORT user 1nnn abend by making more storage available to DFSORT; try adding 32 KB by changing the REGION parameter or the MAINSIZE or SIZE value. See z/OS DFSORT Application Programming Guide for ways to specify MAINSIZE and SIZE.
Thanks , keeping unlimited region worked very well.
The issue I am facing now is with joinkeys logic. None of the records are coming in OUT12 file. There is no match found between both input files. I am sure that there are matches present. the key positions are also correctly referred in control cards.
Code:
ICE421I 0 JOINED RECORDS: COUNT=5575277
ICE055I 0 INSERT 5575277, DELETE 0
ICE054I 0 RECORDS - IN: 0, OUT: 5575277
ICE227I 0 OUT12 : DELETED = 5575277, REPORT = 0, DATA = 0
ICE228I 0 OUT12 : TOTAL IN = 5575277, TOTAL OUT = 0
ICE227I 0 OUT1 : DELETED = 0, REPORT = 0, DATA = 5575277
ICE228I 0 OUT1 : TOTAL IN = 5575277, TOTAL OUT = 5575277
ICE174I 0 NO DATA RECORDS FOR AN OUTFIL DATA SET - RC=0
ICE052I 0 END OF DFSORT
Do you think of any other reason which might be holding the matching logic from working?[/quote]
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
You're thinking ZDF vs ZD sqlcode?
Presumably, Ian I, you ran it with some test data before hitting the five-and-three-quarter-million records. Check your test data against the real stuff as well.
Presumably, Ian I, you ran it with some test data before hitting the five-and-three-quarter-million records. Check your test data against the real stuff as well.
That is a possibility. However, I just wanted to look at a sample record.
Frank , really appreciated your help. The problem with my job was not converting account number from second input file from ZD to ZDF. Once I inserted this logic, the job worked like a charm.
Also I learned from sqlcode1's message that the position in overlays and joinkeys should be matching. I was not aware of this.
Ian I,
It is not that position in overlay and joinkeys should be same but joinkeys expects that each pair of keys for the F1 and F2 files must match with respect to length and order. Keys must be "normalized". However, they can start in different positions.
Refer to JOINKEYS for better understanding of JOINKEYS. Pay close attention to FIELDS under JOINKEYS Statements.
you guys rock.. 
