|
View previous topic :: View next topic
|
| Author |
Message |
rmaruri
New User
Joined: 29 Jun 2005
Posts: 13
Location: USA
|
|
|
|
Hi,
In our environment, they are using easytrieve pgm to match the two files based on the key and creating the matched or unmatched files. I don't find any business logic involved in the easytrieve programs.
I have replaced few easytreve programs with SORT JOINS. I am looking for benifits to implement in the same in the environement.
Here are few of them.
1. Maintanence will be easy with SORT Join compared with Easytrieve components
2. Performance may improve. I am not 100% sure.
If you have done any such activity, please advice me. Apprecite your inputs.
Regards,
Ravi |
|
| Back to top |
|
 |
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
What do you mean specifically by "not finding any business loic"?
Why are you just "replacing" them and then looking for justification - are you supposed to be doing this? If so, the justification should already be there.
Not sure why you think maintenance will be easier, unless your sort-control cards are not managed properly like other program source, in which case, one day, you'll end up "loosing" something.
If you want to know about the performance, let 'em rip yourself and let us know.
The Easytrieve programs may pre-date the availability of JOINKEYS, or the knowledge of JOINKEYS at your site, or your knowledge of the standards at your site if you are jut wondering around changing things for no reason (as in specification of some type). |
|
| Back to top |
|
|
rmaruri
New User
Joined: 29 Jun 2005
Posts: 13
Location: USA
|
|
|
|
Dear Bill, Thanks for your reply.
Business logic means, matching the two files and apply business rules to process the data. Most of the programs are used to match the two files and write the output files on match or no match condition.
Deveopment team is using the easytrive programs for many years. They were not aware of the DFSORT SORT JOIN functionality. As we already have DFSORT installed in the environement, we can use the SORT JOIN instead of Easytrieve.
As per system standards, we will be coding the SORT cards as a part of JCL. So no need for us to have additional components.
Development of comparing the two files using SORT join will take less effort compared with easytrieve. So I would like to let the team knew about it and use the features available in DFSORT instead of Easytrieve.
So I am planning to put my idea of usage of SORT JOIN instead of easytrieve pgm for team discussion. before that I am collecting information.
let me know your thoughts. |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India
|
|
|
|
| rmaruri wrote: |
| Deveopment team is using the easytrive programs for many years. They were not aware of the DFSORT SORT JOIN functionality. As we already have DFSORT installed in the environement, we can use the SORT JOIN instead of Easytrieve. |
If you're talking about "new-development", yes, that can be a direction-of-choice. However, why do you want to replace easytrive codes? Are they CPU or/and I/O intensive? Or it is just one of those "innovative ideas"!
| Quote: |
As per system standards, we will be coding the SORT cards as a part of JCL. So no need for us to have additional components.
|
I think, it dpends. And it, by large, depnds on what kind of skilled man-power do you have at your shop. If they had been using easytrive, it's easy for them to understand/maintain it. Though, over the years Sort product has grown up with many english-like in-built functions. So it makes "easy" to understand them but this is not something for which you'd be charging your client, unless, as I said before - it's a new development and/or you're trying to fine tune someting which is not well in shape, at the moment. (Or you are in a position to replace a product.) |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
There are reasons that programs have strict procedures for implementing requirements.
You "make things easier" at your peril, potentially.
I don't think it a good idea to treat "control cards" as JCL, nor to leave JCL "unprotected" by implementation procedures.
Note that the more you separate them, the more likely you will be to "miss" something, when wanting problem determination or impact analysis or whatever.
I would expect performance improvements, but you need to do the tests with your files |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| As per system standards, we will be coding the SORT cards as a part of JCL. So no need for us to have additional components. |
Sorry, but this is nonsense . . .
If there are sort processes that support the business they are the same as code to provide that functionality and need to be documented, reviewed, and promoted just as any program would be.
Places that have lots of problems often take this kind of short-cut.
Easytrieve has been able to "match" files for many, many years while this is a fairly new feature in DFSORT.
Unless there is some compelling reason to change the currently running processes, suggest they be left alone. As was suggested, it would be rather trivial to run your own timing tests with the actual data and see if there is much of a difference. |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
| Quote: |
Easytrieve has been able to "match" files for many, many years while this is a fairly new feature in DFSORT.
|
Beside that the matching logic in EZT can have actions that could not be done with JOINKEYS or other exotic sort statements. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| OK, more than two files. What else Peter? |
|
| Back to top |
|
|
Skolusu
Senior Member
Joined: 07 Dec 2007
Posts: 2205
Location: San Jose
|
|
|
|
| PeterHolland wrote: |
| Quote: |
Easytrieve has been able to "match" files for many, many years while this is a fairly new feature in DFSORT.
|
Beside that the matching logic in EZT can have actions that could not be done with JOINKEYS or other exotic sort statements. |
Peterholland,
AFAIK easytrieve does NOT support Many-to-Many match. It only supports One-to-Many or Many-to-One match. Joinkeys Supports Many-to-Many match. The prerequisite for easytrieve matching is that the input files need to sorted prior to match which is not required for Joinkeys.
As for other reporting features of easytrieve, there might be a few that need an exit but majority of them can be easily converted to DFSORT statements. |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
| Bill Woodger wrote: |
| OK, more than two files. What else Peter? |
As far as i can remember EZT will/can handle more than 2 datasets for matching/merging (files is for pc adepts). And if that is working dont touch it, for to convert it to any sort package, is going to take a long time.
And then one has to document, train people to understand the sort control statements. I hope that happenend for the EZT program. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
Yes, Easytrieve can handle more than 2 files.
While Easytrieve needs the files to be in sequence before matching is done, the same sorting has to be done inside sort before the join can run.
From what i read (just peeked in the manual) many-to-many is supported but i suspect one should test carefully to make aure what one wants is indeed what they've asked Easytrieve to do.
As far as reporting, SORT can produce lots of things, but some of our processes create 10 or more reports on a single pass of hundreds of millions of records. Many of these also reference database tables or vsam files directly.
[motherhood statement]
As with many things, having a varitey of tools to choose from is most desirable. The same tool is not the best for every requirememt.
[/motherhood statement] |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Peter, when Easytrieve Plus has "DATASET" instead of "FILE" you may have a point :-)
It is only with more than two files where Easytrieve Plus wins out with file matching, and how often do you have to do that?
The power for data-manipulation of the JNFnCNTL files kills Easytrieve, requiring a further "formatting" pass of the data where this is needed - although you could write FILE EXITs if required for Easytrieve Plus, but that would only work either if the order remained the same (the key for the match) or with an "internal" sort (so back to DFSORT to do that).
My Easytrieve Plus manual is a little outdated, and although duplicates on both files can be processed, it didn't do a many-to-many match.
Going from Easytrieve Plus matched-file processing to JOINKEYS would be possible, with only a two-file match. Going the other way would depend on the complexity of the existing JOINKEYS and may require additional pass(es) of the data.
If we are talking of Easytrieve Plus just used for the file-matching, then that is about the end of the story, I think.
Easytrieve Plus vs DFSORT in a wider context is a different thing entirely.
Until(?) DFSORT can access additional files/databases for look-up data, Easytrieve Plus is more flexible.
As Dick says, they are different tools, and they both have their uses and specialities, and an amount of cross-over where more judgement is useful as to which to use for a particular task, taking into account wider things. |
|
| Back to top |
|
|
Skolusu
Senior Member
Joined: 07 Dec 2007
Posts: 2205
Location: San Jose
|
|
|
|
| dick scherrer wrote: |
From what i read (just peeked in the manual) many-to-many is supported but i suspect one should test carefully to make aure what one wants is indeed what they've asked Easytrieve to do. |
Do you happen to remember the version of EZT that supported Many-to-Many match? |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
For the many-to-many it would have to be something new. This is how it used to work:
| Code: |
A 1
A 2
B 1
A A
A B
A C
B A
|
Would get
| Code: |
A 1 - A A
A 1 - A B
A 1 - A C
A 2 - no current record
B 1 - B A |
You can tell with the Easytrieve match (Synchronised File Processing) that Key A is a duplicate on FILE 1, but you do not have the records from FILE 2 available (unless you make it so by storing them).
The many-to-many "match" should get
| Code: |
A 1 - A A
A 1 - A B
A 1 - A C
A 2 - A A
A 2 - A B
A 2 - A C
B 1 - B A
|
The SFP can't be just "upgraded" to do the many-to-many, for reasons of backwards-compatability.
Easytrieve Plus can handle duplicates on both files (since comparing to JOINKEYS, only the two files are relevant), but it does not do it in the same way. In JOINKEYS it is much simpler to handle, as each key on file 1 is presented alongside each matching key on file 2.
There may be some confusion over what is regarded as "many-to-many" in that both phrases may occur in respective manuals, but with practical differences in record availability between the two products. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Skolusu wrote: |
| Do you happen to remember the version of EZT that supported Many-to-Many match? |
The doc is trapped on a machine not available from the house.
I believe it is R12 that i reference.
Correction - it is R11
I'll check tomorrow and report back. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| I believe it is R12 that i reference |
Ooops . . . I lied 
The manual i looked is for release R11.
Sorry 'bout that . . .
Gotta get all these docs onto a flash drive.
d |
|
| Back to top |
|
|
|
|
