IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Issue in comparing files using EASYTRIEVE


IBM Mainframe Forums -> CA Products
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Wed Aug 10, 2011 4:59 pm
Reply with quote

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.

It is easier than it looks once you've done it.
Back to top
View user's profile Send private message
Thirumurgann

New User


Joined: 13 Feb 2008
Posts: 36
Location: India

PostPosted: Wed Aug 10, 2011 5:00 pm
Reply with quote

BILL,

Thank you so much. I will try out this...

Thanks,
Thiru
Back to top
View user's profile Send private message
Thirumurgann

New User


Joined: 13 Feb 2008
Posts: 36
Location: India

PostPosted: Wed Aug 10, 2011 7:27 pm
Reply with quote

Hi BILL/DICK

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
Back to top
View user's profile Send private message
seagull

New User


Joined: 28 May 2007
Posts: 24
Location: Dublin

PostPosted: Wed Aug 10, 2011 9:48 pm
Reply with quote

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.
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Thu Aug 11, 2011 5:00 am
Reply with quote

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.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> CA Products

 


Similar Topics
Topic Forum Replies
No new posts SFTP Issue - destination file record ... All Other Mainframe Topics 2
No new posts Write line by line from two files DFSORT/ICETOOL 7
No new posts Compare only first records of the fil... SYNCSORT 7
No new posts Merge two VSAM KSDS files into third ... JCL & VSAM 6
No new posts Joinkeys - 5 output files DFSORT/ICETOOL 7
Search our Forums:

Back to Top