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
 

 

Efficient Match and Merge COBOL programs

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
Shiva Danda

New User


Joined: 12 Nov 2008
Posts: 7
Location: Hyderabad

PostPosted: Wed Nov 19, 2008 5:07 pm    Post subject: Efficient Match and Merge COBOL programs
Reply with quote

Seems there are many match processes with GO TO's.. here are the programs to Match and/or Merge without GO TO's.
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 Nov 20, 2008 12:08 am    Post subject:
Reply with quote

Hello,

How much testing was done with these modules?

A quick look suggests they will both fail in some situations. . .

I have removed the attachment before more people download it.

Please post test results of both programs showing that they will work with "unbalanced" input files.

You can run a quite complete test with only 10 or 20 records in the input files and the "key" can be only 1 or 2 positions.
Back to top
View user's profile Send private message
Shiva Danda

New User


Joined: 12 Nov 2008
Posts: 7
Location: Hyderabad

PostPosted: Thu Nov 20, 2008 8:18 pm    Post subject: Programs running in prod for 3 years
Reply with quote

Both samples are working in production for the past 3 years without a single issue... the data is 300 Million (master) vs 20 Million (Tran) on daily basis. I cant post you the prod data... but surely will prepare the test data to clarify your concerns. Thanks.
Back to top
View user's profile Send private message
Shiva Danda

New User


Joined: 12 Nov 2008
Posts: 7
Location: Hyderabad

PostPosted: Thu Nov 20, 2008 8:25 pm    Post subject: There should not be duplicates in both the files..
Reply with quote

oops.. forgot to mention the imp info: There should not be duplicates in both the files.... icon_cool.gif icon_lol.gif
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 Nov 20, 2008 9:45 pm    Post subject:
Reply with quote

Hello,

What if there is duplicate info in one file - is this ok?

What prevents the code from reading past eof? There is only 1 eof indicator and it does not appear to be tested in the read code? What happens if the "other" file goes eof first.

Match/merge code needs to be able to handle all conditions. I believe this code works because of the specific relationship of the input files, but may have problems if used as a generic solution.
Back to top
View user's profile Send private message
Shiva Danda

New User


Joined: 12 Nov 2008
Posts: 7
Location: Hyderabad

PostPosted: Thu Nov 20, 2008 10:41 pm    Post subject: If there are duplicates###
Reply with quote

1. If there are duplicates, should go for Many to Many match.. I have one currently with me... will send you soon (need to make it as generic in the place of the user code).

2. To second point mentioned, driving till end of one file-1 is more than enough, because the other file-2 key will be moved HIGH-VALUES at the end using the reference, hence it will never read past End-Of-File-2.

FYI, There won't be any key greater than HIGH-VALUES.
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: Sun Nov 23, 2008 7:38 am    Post subject:
Reply with quote

Hello,

The first of the 2 programs (match) works in limited fashion. It appears to only write the key matches. . . . It is rare that "no-matches" should be discarded.

If there is a match, only one record is written to the output.

I have not tried the "merge" code, but i believe a good "model" will handle match and/or merge with very minor modifications. I agree that a generic match/merge model would not likely handle the possible wide variety of many-to-many situatons.

Quote:
the data is 300 Million (master) vs 20 Million (Tran) on daily basis. I cant post you the prod data...
The volume of records has little to do with the functionality of the code. This code will work for this rather specific requirement, but will not apply generically.

My initial concern about a possible read past eof-of-file did not happen with the "match" code.

Working, generic match/merge code without GO TO would probably be welcome to the people who work in organizations or have attended training that insists all GO TOs are bad.

[Personal rant]
GO TOs are quite proper when used properly. . . Some of the better structured code has GO TOs and some of the worst "spaghetti" i've seen has none. Developers can do very good or very bad things with or with out the GO TO. . .
[Personal rant off] icon_smile.gif

Before i forget - thank you Shiva for posting your code.
Back to top
View user's profile Send private message
Shiva Danda

New User


Joined: 12 Nov 2008
Posts: 7
Location: Hyderabad

PostPosted: Mon Nov 24, 2008 4:13 pm    Post subject: Reply to: Efficient Match and Merge COBOL programs
Reply with quote

Many to One (Effectively Many to Many) COBOL pgm:

Good Afternoon!

Attached is the sample prepared for Many to One (Many to Many). Have a look at it and let me know if you see anything fishy....

Thanks. Danda.
Back to top
View user's profile Send private message
Shiva Danda

New User


Joined: 12 Nov 2008
Posts: 7
Location: Hyderabad

PostPosted: Mon Nov 24, 2008 4:22 pm    Post subject: GO TO in COBOL
Reply with quote

GO TO is one of the best option available when needed.

But we always prefers to code a program without GO TO's and we strongly believe any code can be achieved without using GO TO's.

In review, it will be given non-compliance incase a GO TO stmt found, proper justification will suffice to make use of it.

Thanks.
Back to top
View user's profile Send private message
Marso

REXX Moderator


Joined: 13 Mar 2006
Posts: 1224
Location: Israel

PostPosted: Tue Nov 25, 2008 4:19 am    Post subject: Re: If there are duplicates###
Reply with quote

Shiva Danda wrote:
FYI, There won't be any key greater than HIGH-VALUES.
I hope most people are aware of that! icon_wink.gif
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: Tue Nov 25, 2008 7:01 am    Post subject:
Reply with quote

Hello,

Quote:
But we always prefers to code a program without GO TO's and we strongly believe any code can be achieved without using GO TO's.
Yup, preferences are just that - preferences. And standards are standards and should be followed (bad standards need to be replaced not violated). And i agree that code can be achieved without GO TOs.

That does not mean that it always should be. . .

If someone were starting a completely new information processing environment and had zero lines of code that was already running the business, i believe it would be acceptable/desirable to have the no GO TO standard. Most people will never work in a completely new environment - many not even a new application in an existing environment.

Last i read, somewhere between 80 and 95% of developer time on the mainframe is spent doing maintenance. There are millions and millions of lines of code that needs to be supported - almost all of them have GO TO in the code (some well done, some horrible - but no matter). It is very important that maintenance be performed in the style of the already running code (imho). Some of the worst experiences i've had is trying to bail out someone/group who have decided to force GO TOless maintenance on code that already works perfectly with the GO TOs.

One other consideration (that seems to mean much less these days) is performance. Code that always runs within several levels of nested performs used comsiderably more cpu time than code that basically works top-down (at least in the timing tests i was part of). Not so much an issue today, the nested performs often caused extreme paging - i haven't heard or read anything about this lately.

I haven't taken time to download the new code, but i would offer a caution that many/many sometimes requires working in sets rather than record by record (thank goodness for database icon_smile.gif ).

Thanks again.
Back to top
View user's profile Send private message
Shiva Danda

New User


Joined: 12 Nov 2008
Posts: 7
Location: Hyderabad

PostPosted: Tue Nov 25, 2008 10:30 pm    Post subject: Thanks!!!
Reply with quote

Thanks for the info. icon_cool.gif
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 -> COBOL Programming All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Executing OO COBOL program invoking J... Virendra Shambharkar COBOL Programming 2 Tue Jan 10, 2017 6:37 pm
No new posts OO COBOL compile error Virendra Shambharkar COBOL Programming 3 Tue Jan 10, 2017 6:05 pm
No new posts Need Suggestion on COBOL program vickey_dw COBOL Programming 5 Thu Jan 05, 2017 10:55 pm
This topic is locked: you cannot edit posts or make replies. RANDOM Function in COBOL swapnil781 COBOL Programming 2 Tue Nov 15, 2016 6:17 pm
No new posts Regarding COBOL Stored Procedure opti... selvamsrinivasan85 DB2 4 Fri Nov 04, 2016 8:57 pm


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