Forgive me if this ends up being a duplicate post. My workplace is experiencing Server Problems and from what I see there, there is no evidence that this made it to the Forum to be posted. So I will use a different method of posting.
I have a MERGE that keeps returning a U0065 ABEND. The indication is that the file in SORTIN02 is coming in unsorted. Such is not the case. Knowing full well it is rare that the System is wrong and usually it is the Programmer. I assure you however that both SORTIN01 and SORTIN02 are sequenced using identical Control Statements with an ALTSEQ and Identical Keys.
Contained in the attachment lies the Code and the SYSOUT Log. Thoughts???
do not post attachments, not everybody can see/download them,
doing so reduces the number of useful replies that You might get
Your attachment was inlined and deleted
The SORTIN01 as well as the SORTIN02 come in SORTED using Identical CONTROL CARDS with the Exception being SORT FIELDS=
What I am trying to accomplish is at position 33 starts a voucher number TP0, TPA, TPB, TPC, TPD, TPE, TPF or TPG followed by random 9 more numbers. For years they came inner-mixed. The Users now want them seperated through Control Breaking and they want the voucher to appear on the report as TP0s break then TPAs break then TPBs so on and so on. A pure Ascending sort will give you TPA, TPB, TPC….TP0 and a Descending Sort will give you TP0, TPG, TPF ….TPA. I realize this, of course, you know. The sequencing requirements are however TP0, TPA, TPB …. TPG. This can be accomplished by redefineing in a ALTSEQ
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
mheatherton wrote:
The SORTIN01 as well as the SORTIN02 come in SORTED using Identical CONTROL CARDS with the Exception being SORT FIELDS=
I just re-read this. That could be a pretty big "Exception" :-) Did you mean that?
The sorts have to be the same keys as for the merge, including the ALTSEQ. If the FIELDS= are different, then you have a high chance that the MERGE will feel, rightly, that the something is not in sequence.
As a sanity check, you could use those control statements with AIDMP.PA2779KS.FYTD(-1) as your SORTIN and a temporary file as your SORTOUT. Then use that temporary file as SORTIN02.
Also, if your input data set does not have any duplicates, you could compare AIDMP.PA2779KS.FYTD(-1) to the temporary file. This will tell you if SORTIN02 is really in the correct sequence or not (I'd guess not).
The only other way I could help you is if you sent IBM your input files via a PMR.
