|
View previous topic :: View next topic
|
| Author |
Message |
Shiva Danda
New User
Joined: 12 Nov 2008
Posts: 7
Location: Hyderabad
|
|
|
|
| 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 |
|
 |
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
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 |
|
|
Shiva Danda
New User
Joined: 12 Nov 2008
Posts: 7
Location: Hyderabad
|
|
|
|
| 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 |
|
|
Shiva Danda
New User
Joined: 12 Nov 2008
Posts: 7
Location: Hyderabad
|
|
|
|
oops.. forgot to mention the imp info: There should not be duplicates in both the files....   |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
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 |
|
|
Shiva Danda
New User
Joined: 12 Nov 2008
Posts: 7
Location: Hyderabad
|
|
|
|
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 |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
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] 
Before i forget - thank you Shiva for posting your code. |
|
| Back to top |
|
|
Shiva Danda
New User
Joined: 12 Nov 2008
Posts: 7
Location: Hyderabad
|
|
|
|
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 |
|
|
Shiva Danda
New User
Joined: 12 Nov 2008
Posts: 7
Location: Hyderabad
|
|
|
|
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 |
|
|
Marso
REXX Moderator
Joined: 13 Mar 2006
Posts: 1353
Location: Israel
|
|
|
|
| Shiva Danda wrote: |
| FYI, There won't be any key greater than HIGH-VALUES. |
I hope most people are aware of that!  |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
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 ).
Thanks again. |
|
| Back to top |
|
|
Shiva Danda
New User
Joined: 12 Nov 2008
Posts: 7
Location: Hyderabad
|
|
|
|
| Thanks for the info. |
|
| Back to top |
|
|
|
|
