Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Easytrieve Vs SORT JOIN

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> DFSORT/ICETOOL
View previous topic :: :: View next topic  
Author Message
rmaruri

New User


Joined: 29 Jun 2005
Posts: 13
Location: USA

PostPosted: Wed Aug 22, 2012 12:28 pm    Post subject: Easytrieve Vs SORT JOIN
Reply with quote

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

Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7241

PostPosted: Wed Aug 22, 2012 12:40 pm    Post subject: Re: Easytrieve Vs SORT JOIN
Reply with quote

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
View user's profile Send private message
rmaruri

New User


Joined: 29 Jun 2005
Posts: 13
Location: USA

PostPosted: Wed Aug 22, 2012 1:08 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Anuj Dhawan

Senior Member


Joined: 22 Apr 2006
Posts: 6258
Location: Mumbai, India

PostPosted: Wed Aug 22, 2012 2:24 pm    Post subject:
Reply with quote

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

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7241

PostPosted: Wed Aug 22, 2012 3:21 pm    Post subject:
Reply with quote

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
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Wed Aug 22, 2012 6:59 pm    Post subject:
Reply with quote

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
View user's profile Send private message
PeterHolland

Global Moderator


Joined: 27 Oct 2009
Posts: 2422
Location: Netherlands, Amstelveen

PostPosted: Wed Aug 22, 2012 10:07 pm    Post subject:
Reply with quote

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

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7241

PostPosted: Wed Aug 22, 2012 10:09 pm    Post subject: Reply to: Easytrieve Vs SORT JOIN
Reply with quote

OK, more than two files. What else Peter?
Back to top
View user's profile Send private message
Skolusu

Senior Member


Joined: 07 Dec 2007
Posts: 2205
Location: San Jose

PostPosted: Wed Aug 22, 2012 10:14 pm    Post subject:
Reply with quote

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
View user's profile Send private message
PeterHolland

Global Moderator


Joined: 27 Oct 2009
Posts: 2422
Location: Netherlands, Amstelveen

PostPosted: Wed Aug 22, 2012 10:15 pm    Post subject: Re: Reply to: Easytrieve Vs SORT JOIN
Reply with quote

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
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Wed Aug 22, 2012 11:43 pm    Post subject:
Reply with quote

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

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7241

PostPosted: Thu Aug 23, 2012 1:39 am    Post subject: Reply to: Easytrieve Vs SORT JOIN
Reply with quote

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
View user's profile Send private message
Skolusu

Senior Member


Joined: 07 Dec 2007
Posts: 2205
Location: San Jose

PostPosted: Thu Aug 23, 2012 2:59 am    Post subject:
Reply with quote

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

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7241

PostPosted: Thu Aug 23, 2012 5:47 am    Post subject: Reply to: Easytrieve Vs SORT JOIN
Reply with quote

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
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Thu Aug 23, 2012 8:41 am    Post subject:
Reply with quote

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
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Thu Aug 23, 2012 11:31 pm    Post subject: Reply to: Easytrieve Vs SORT JOIN
Reply with quote

Hello,

Quote:
I believe it is R12 that i reference
Ooops . . . I lied icon_redface.gif

The manual i looked is for release R11.

Sorry 'bout that . . .

Gotta get all these docs onto a flash drive.

d
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> DFSORT/ICETOOL All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Limit duplicate records in the SORT pshongal SYNCSORT 6 Mon Nov 21, 2016 12:54 pm
No new posts How to convert the VBM file to VB or... Sulabh Agrawal JCL & VSAM 4 Fri Nov 18, 2016 1:04 pm
No new posts Sort records based on numeric field. Alks SYNCSORT 2 Wed Oct 19, 2016 10:14 pm
No new posts How to delete second instance from Fl... Gunapala CN DFSORT/ICETOOL 6 Tue Oct 18, 2016 11:42 pm
No new posts abend sort based on count records in ... anatol DFSORT/ICETOOL 5 Mon Oct 17, 2016 10:10 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us