View previous topic :: View next topic
|
Author |
Message |
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
well, i am not an ezytrieve specialist,
but there is such a thing as JOB INPUT NULL
and a GET instruction.
you need two additional proc's. one to GET the O's and one to GET the R's.
you don't want to have a JOB INPUT statement that reads one record from both,
because you don't always want to read a record from both. |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
you (sorta) stipulated that reversals should eliminate matches on the other file.
what if you have an unmatched reversal?
PERFORM GET R
PERFORM GET O
PROCESS:
if R end-of-file Perform write rest of O's as clean
If O end-of-file Perform write rest of R's as unmatched
If R = O then PERFORM GET R, Perform GET O, goto process
If R < O then Perform write unmatched R, Perform GET R, goto process
IF R > O then PERFORM Write O as clean, Perform GET O, goto process
goto process. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Quote: |
The use of Easytrieve under these circumstances is the flaw. |
The only flaw was the code. OK, maybe the requirement. I'm with Dick on former and enrico on latter.
From the sample data you showed after your first post:
- The SFP was never going to do what you want
- The coder not only didn't know how to do the SFP, but neither the matching conditions
- The coder failed to test properly
- Every single tester down the line, of all stripes, failed
- Something that just would not work managed to get into production
To blame the language for the mal-use of an element of the language is absurd.
Code it out. Get it going how it should have been at first. Dbz has given a start. |
|
Back to top |
|
|
Michaelod Warnings : 1 New User
Joined: 02 Sep 2008 Posts: 49 Location: Edinburgh
|
|
|
|
Bill Woodger wrote: |
Quote: |
The use of Easytrieve under these circumstances is the flaw. |
The only flaw was the code. OK, maybe the requirement. I'm with Dick on former and enrico on latter.
From the sample data you showed after your first post:
- The SFP was never going to do what you want
- The coder not only didn't know how to do the SFP, but neither the matching conditions
- The coder failed to test properly
- Every single tester down the line, of all stripes, failed
- Something that just would not work managed to get into production
To blame the language for the mal-use of an element of the language is absurd.
Code it out. Get it going how it should have been at first. Dbz has given a start. |
It may have come across wrong but I'm not blaming the language.
What I'm blaming is the lack of knowledge of the person who coded the easytrieve i.e. not understanding how to use it properly. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Quote: |
What I'm blaming is the lack of knowledge of the person who coded the easytrieve i.e. not understanding how to use it properly. |
Yup, but that ship has sailed long ago.
Now a re-code/re-test is in order whether the original author is available or not.
Given thet the code "as is" many not ever be made to work, suggest you use the logic from the Sticky or the hints from DBZ. |
|
Back to top |
|
|
|