Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
OK, I can see what you mean now, thanks.
I never like data that is difficult to recreate in the case of an error. You will entirely loose your "10" value, and it can only be recovered through calculation. If you are creating some type of "store header", why don't you keep the first detail record anyway?
How about using the Code tags? Six years you've been here. Do you want the output in smudgy. messed-about-number format (like "8") or would it be OK as "08"?
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Useit,
It is not at all clear what you are saying.
Is the only problem you have the "8" instead of "08"? You were specifically asked about this before, and said to go with "08".
If that is your problem, try a bit of code yourself. You would want something "left justified with leading zeros removed". See if you can find something similar (like with "space" being removed) and find out how to remove zeros instead of space.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
When defining your requirement, the more exactitude, the better the solution. You showed three records and always mentioned specific values, without describing that this was representative of data which could contain different values.
The Sort is reading your same input file twice. It is a common technique. You need to update a value on a record which in normal circumstances has already been written. This is a way to allow you to have the total before the record is written, so the update can work.
If you look at the JNF1CNTL and JNF2CNTL they are doing some processing. In the course of that processing the file is being extended within the processing so that the required information is available at the required time.
A JOINKEYS is being used on two input files. The first is to be treated as in sequence already and not to have sequence-checking done as it is processed.
The second file will be sorted as part of the JOINKEYS processing.
Positions 1 for a length of 7 and 9 for a length of 2 are required for your processing from the first JOINKEYS file, and 11 for a length of 2 is required from the second (it contains the total you want).
The output record-length is set to 7 (which is what you want). A particular value identifies which record needs to be updated with the total, and the update is made.
The output file is thren written with no further SORT (it is COPYd).
So, the "joinkeys" bit is about taking the total and putting it where you want.
The JNF2CNTL is the same as the JNF1CNTL except for the SUM. The purpose of the SUM is to get the total you want, which is then put in the position you want as described above.
This is the code doing the processing that you want to recalculate the values.
For each record the value at 6 for a length of 2 is copied to start position 11.
A GROUP is established on your key, and a sequence number (length of 2) is added at position 9 for each record in the group.
For records other than the first one, the value is recalcuated and then returned to the position of the value, taking into account your "next highest integer".
If you want to use the value from the record instead of the +6, you need to include a bit of extra code. The value you desire is on the record which is used when establishing the GROUP, so you can add to the PUSH a copy of that value to a new location which will then be available for the subsequent records.
Then, in the places where +6 is used, you use that PUSHed value instead.
