Only Record 3 has a date field which needs to be sorted in ascending order. Record 3 always comes between record 2 and 4. I only need to sort record 3 . Any other records should remain as they are. i.e the output should look like this,
If the record type '5' ( record number 14 ) is not the file trailer, I am not certain that the original sequence of "groups" will be maintained with the solution posted, since the '5' record will not fall between the BEGIN and END criteria (inclusive) and will, therefore, have no group id number in positions 301-304.
If the type '5' record is the highest record type OTHER than the trailer, I think that the END statement will need to be changed to
Code:
END=(1,1,SS,EQ,C'4,5'),PUSH=(301:ID=8))
Note: if the file contains other type records as well (other than the trailer, that is), it would be
Code:
END=(1,1,SS,EQ,C'4,5,?'),PUSH=(301:ID=8))
where ? represents another value; etc. if there are others
Please let me know if I am wrong. I was unable to perform any tests (could not connect to mainframe tonight for some unknown reason).
Is there any other way to do it as the synctool and syncsort version that we have doesn't recognise datasort, group and push functions.
Synctool version: 1.6.1 and syncsort version 1.3.1.0R
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Ronald,
I tend to give solutions based on the example the poster shows. Given how badly people present their requirements here, if I tried to guess what other variations there might be in the data that were not posted, I couldn't give any answers at all. If my solution doesn't work because the posted data was incomplete, then I expect the poster to tell me that, and give me a better example. I usually note my assumptions, but sometimes I get too busy to do that, as in this case.
Given the example posted, I think it was fair to assume that '1' is the header and '5' is the trailer and they only occur once. Of course, if the poster had come back and said "here's what the data really looks like", then I would given a new job based on that data. But in this case, it turns out the poster is using Syncsort, not DFSORT, and I don't respond to Syncsort questions.
So basically, the poster posted in the wrong Forum and showed a bad example, which to me, qualifies as "garbage in, garbage out".
I understand your point completely, Frank - in this case it appears that several folks wasted time attempting to provide a valid DFSORT solution to whatever "requirement" one inferred from what was posted.
As it is, I realized, after the fact, that the "solution" that I suggested would not produce the correct results for the situation I thought might be the case.
I'm not sure that there even IS a one-step Syncsort solution, though I have placed the problem on the back burner of my brain in case a solution pops into mind.
