View previous topic :: View next topic
|
Author |
Message |
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Yup, it is also quite handy for generic file compare (the files need to be in sequence by "the key") - user specifies lrecl, key length, number of mis-matches after which to stop, "highlight" the differences, how much of the records to show, etc.
The first i used this was about 20 years ago - i remember where i was, but not which level of operating system and cobol compiler
Jasorn - which language was used to write your copybook parser? |
|
Back to top |
|
|
jasorn Warnings : 1 Active User
Joined: 12 Jul 2006 Posts: 191 Location: USA
|
|
|
|
Dick,
I wrote the parser in cobol. Sometime in the 1990's. I was planning to use the cobol 2 eztrieve converter that comes with eztrieve somehow but never could get that to work well with redefines and occurs.
So I wrote my own. I recently modified it to also spit out a symnames file for dfsort after a couple hours of not being able to get the similar tool for that to work
Funny you should mention generic file compares because that's exactly why I wrote the parser. Two of the fields on it are key indicator and key sequence. The compare job builds a sort card based on those and sorts the files.
The compare program reads the parsed copybook into an array, uses records contains 0 and file compares are even easier than with eztrieve. I put in quite a few functions but never got around to implementing code to do some of the fancier things eztrieve compares can do such as first dup, last dup, no dup etc.
The nice part about my compare though is it matches on the key you define and then loops through the rest of the fields by looping through the parsed copybook and reports differences at the field level. I've yet to see another compare process do this.
And if you have a copybook for the file the coding is done.
Another nice thing is if you use the same field names you can compare two files with different layouts.
There are lots of other things I do with the parsed copybook and record contains 0. Basically since the code can be based on the fieldnames there is lots of potential. |
|
Back to top |
|
|
jasorn Warnings : 1 Active User
Joined: 12 Jul 2006 Posts: 191 Location: USA
|
|
|
|
dick, actually, it does program does that too . Since you created one for a client does that mean the one that comes with eztrieve is ;broken' and it's not just me? |
|
Back to top |
|
|
Douglas Wilder
Active User
Joined: 28 Nov 2006 Posts: 305 Location: Deerfield IL
|
|
|
|
It sound difficult in COBOL to parse a copybook like this. But it would be very useful. It would be great if you were willing to share this, but I understand completely if you do not wish to or cannot share this code. |
|
Back to top |
|
|
jasorn Warnings : 1 Active User
Joined: 12 Jul 2006 Posts: 191 Location: USA
|
|
|
|
Douglas Wilder wrote: |
It sound difficult in COBOL to parse a copybook like this. But it would be very useful. It would be great if you were willing to share this, but I understand completely if you do not wish to or cannot share this code. |
Actually, I've been meaning to share this with the hopes the community would contribute enhancements.
I'm not sure now how my company would feel about that. I could check. While I created this on my own time and computer for the pc a long time ago and I wouldn't share any enhancements I made on my company's dime I'd have to see if there are legal ramifications.
I did get a bonus for this from my current employer. Actually, this is the 3rd company that's given me some kind of award for it
But it really wasn't that hard. Just a little unusual. |
|
Back to top |
|
|
|