EDITED to add code tags, and also fixed a typo in the sample data. The propagated key for the second group was also '1234'. Corrected to '5678'. Use code tags and pay attention to the details before posting.
The info requested by expat is needed at the latest stage of this project's implementation. Before actual coding one needs to understand the overall logic, or algorithm, required to get the given result. At this primary stage none of the mentioned details are used. At this moment it even doesn't matter what tool exactly is used (DFSORT, or another one), to say nothing about its version.
So, the order must be as follows:
1) design an algorithm
2) choose the more convenient/available tool for implementation of this task
3) prepare the actual code keeping in mind the specifics of particular tool finally chosen
4) test and debug the code using specific limited test data, instead of real production data
5) finally run the fixed code with actual production data.
For stage #1 I suggest the following logic. Since no value from the third line of any group can be propagated under any circumstances into preceeding records of the same dataset, then it is obvious for myself that two steps of processing are necessary.
Step 1: run SORT utility to process the original file and add sequential group number, and record number within this group to each record
Here is an example that does not need multiple steps or a JOIN operation. The idea is to save record-1 and record-2 in each group starting with a '+' onto the record-3, then recreate it in the OUTFIL.
The below example assumes input and output to be of FB/LRECL=80 and that you always have 3 records in a group, you could modify it as per your actual definitions.
Like expat has mentioned above, it would always help if you post all the requested information in the very first post, especially the things that only you know. If something does not work for you, please include ALL the relevant information in your next post. Good luck.
Yes, in specific simple cases this approach will work. But in many cases of real life it will not:
2) LRECL= huge value
3) required record number is much greater than 3, let's say 300
4) desired record number can vary for different files
My solution was based on OP's specific mention about record-3. There is no need to waste resources by JOINing data sets in cases where only a single pass solution is sufficient.
If someone has a requirement to propagate the key at nth record (something >>3), still a JOIN with a copy operation would do. Here in the below example, the 3rd record is forced to match the first record of each group.