Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
I can elaborate on the problem, at least. Sort of, because we are still short of answers....
You are matching two files.
If the records are identical, you ignore them.
If the keys are the same but the data not, you extract the "latest" with an indicator saying "Update".
If the keys do not match, and it is the "latest" you extract with an indicator saying "Insert".
The "data" part of your record is variable in length (making the who record variable in length).
Your first problem is what to do with the Update/Insert marker. You are putting it after the variable part of the record, either forcing the record to a maximum, or making you use a different method to ensure it is located after the existing data (and making your output record longer by two bytes).
To do your comparison, you must ensure that you only compare data that is actually within your record.
Easytrieve now supports variable-length fields. You'll have to look that up.
Easytrieve will also use the current record on a file, with the correct length, when you use the "filename" - like MOVE filename TO a data-name or another-filename. Or IF filename EQ another-filename.
Look at the manual for RECORD-LENGTH for how to set and extend your output lenghts for a variable-length record.
This will move current record of SORTF3 to record-area for OUTFIL2.
Code:
MOVE SORTF3 TO OUTFIL2
This will rest the entire record on SORTF3 against the entire record on SORTF4.
Code:
IF SORTF3 EQ SORFT4
For a variable output file you need to set the record-length.
Special thanks to you guys...When i am clu less BILL and Dick helped me a lot to complete this deliverable on the time. BILL patiently explained me. Hats off BILL.... You rock...
Thanks,
Thiru
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Thiru, I'm glad it helped.
Please take the time it has saved you to fully understand the code you have. Document as necessary. When one of your colleagues picks up the code next time, they need to know what is going on.
seagull wrote:
It looks to me like the best option is to put the SORT into a separate step ahead of the easytrieve, and then code the match logic yourself.
It would be possible, I'm sure, for the full solution to be done with a SORT/xxxTOOL.
With no duplicates on either file, the Easytrieve file matching is a simple process. The problem was in how to compare variable-length data.
Although I am one for KISS, and would not myself code an "internal SORT" in Cobol, Easytrieve handles things differently. Each SORT and JOB is a seperate entity, which can share file definitions and "working storage" definitions. The Easytrieve "Virtual File Manager" provides a convenient method of defining and using "temporary" files, and even tables for binary searches. If the VIRTUAL file can be fitted into memory, it will be. This means you can define a load of temporary files to simplify the processing without having to include them in the JCL.
The Easytrieve SORT just uses the installed SORT product. With no record selection, it will run fairly well, though I don't know who is handling the IO for the input file (for the VIRTUAL, it is obviously Easytrieve).
For the solution, either "as is" in Easytrieve, or one with SORT/xxxTOOL. If the input files are "big", I would do the sorts seperately for the Easytrieve.