I have an input file which has data for add, change or delete transactions. The fields are Action Type (pos 1-3), Key (pos 5-8) and Maintenance Timestamp.
In case multiple occurences of the key is present, the one with the latest timestamp needs to be retained. But if we have ADD as the first occurence for a particular key and DEL as the last occurence, then all the records for the key needs to be removed. Currently we are doing this using 8 SORT steps. The final output looks like this.
Joined: 07 Dec 2007 Posts: 2205 Location: San Jose
remoonline,
It would take less than 8 passes of data if you have the latest PTF installed. You are behind on DFSORT functional PTFs. Ask your System Programmer to install z/OS DFSORT V1R10 PTF UK90025 or z/OS DFSORT V1R12 PTF UK90026.
I will work something to work on your DFSORT level , but what do you do in this scenario? It doesn't start with ADD , but ends with DEL.
CHG KEY9 2011-12-22-07.01.09.000000
DEL KEY9 2011-12-22-07.01.19.000000
ADD KEY9 2011-12-22-07.01.29.000000
DEL KEY9 2011-12-22-07.01.31.000000
CHG KEY9 2011-12-22-07.01.09.000000
DEL KEY9 2011-12-22-07.01.19.000000
ADD KEY9 2011-12-22-07.01.29.000000
DEL KEY9 2011-12-22-07.01.31.000000
the output will be
Code:
DEL KEY9 2011-12-22-07.01.31.000000
It is possible to have a ADD, then DEL and then again an ADD. The final file is a delta file used to keep other downstream systems in sync. So we don't need to keep recs which were created and deleted on same day.
Joined: 07 Dec 2007 Posts: 2205 Location: San Jose
remoonline,
I don't see a reason as to why you need an extra sort as the first pass. Also you are NOT sorting as the CTL1CNTL has Option COPY which would make it a copy operation.
Are you telling me that your input isn't sorted on the key (5,4,CH) as shown in your examples? The only time you would need an extra sort is when your input isn't sorted on the key.