|
View previous topic :: View next topic
|
| Author |
Message |
Amit Suri
New User
Joined: 28 Oct 2008
Posts: 25
Location: hyderabad
|
|
|
|
Hi All
When the Read EOF condition is sensed: What would be the latest record
available to process?
let's say we have 4 records to be processed and EOF is set when the
attempt is made to READ the 5th record AT that time if i want to use the
current record, will it be again the 4th one?
Regards
Amit |
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
When you hit EOF on a READ in COBOL, there is no "latest record" to process. From the COBOL Language Reference manual:
| Quote: |
6.2.28.9 READ statement notes:
* If the FILE-STATUS clause is specified in the file-control entry, the associated file status key is updated when the READ statement is executed.
* After unsuccessful READ statement execution, the contents of the associated record area and the value of the file position indicator are undefined. Attempts to access or move data into the record area after an unsuccessful read can result in a protection exception. |
If you attempt to use the "current record" after an EOF condition is raised, you can get a S0C4 abend. |
|
| Back to top |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006
Posts: 1049
Location: Richmond, Virginia
|
|
|
|
Depends on what you did with the 4th record when you had it.
If you used READ INTO, then it is in the variable after INTO.
Otherwise, after the 5th READ, the contents of the buffer are unpredictable. I think that if you forced single buffering, then it would still be there, but I'm not sure.
Here's an idea - try it and see. How hard can it be to really find out for yourself, rather than take my word for it? |
|
| Back to top |
|
|
Amit Suri
New User
Joined: 28 Oct 2008
Posts: 25
Location: hyderabad
|
|
|
|
Snippet of the code ( Logically incorrect , just to clarify the query )
Input file was having two records and when the job was executed
the 2nd record was processed twice :
PROCEDURE DIVISION.
THE-PARA-ONE.
OPEN INPUT FILE1.
PERFORM PROCESS-FILE UNTIL END-OF-FILE-SWITCH = 'Y'.
CLOSE FILE1.
STOP RUN.
PROCESS-FILE. ==> Performed even when all records were read.
READ FILE1 AT END MOVE 'Y' TO END-OF-FILE-SWITCH
END-READ. ===> EOF was sensed
MOVE INP-REC TO OUT-REC ===> Last Record is moved at EOF ( processed 2nd time)
DISPLAY 'NAME OF STU' OUT-NAME. |
|
| Back to top |
|
|
Kausar.S
New User
Joined: 01 Oct 2010
Posts: 4
Location: Mysore
|
|
|
|
Hi Amit,
Please try to change the code as below.. It will not process 2nd record twice.
Hope it works :-)
PROCEDURE DIVISION.
THE-PARA-ONE.
OPEN INPUT FILE1.
PERFORM 100-PROCESS-FILE THRU 100-EXIT
UNTIL END-OF-FILE-SWITCH = 'Y'.
CLOSE FILE1.
STOP RUN.
100-PROCESS-FILE.
READ FILE1
AT END
MOVE 'Y' TO END-OF-FILE-SWITCH
GO TO 100-EXIT
END-READ.
MOVE INP-REC TO OUT-REC
DISPLAY 'NAME OF STU' OUT-NAME.
100-EXIT.
EXIT. |
|
| Back to top |
|
|
Amit Suri
New User
Joined: 28 Oct 2008
Posts: 25
Location: hyderabad
|
|
|
|
Hello Kausar
Thanks for your response. But if you see the thread above, this is not
actually mine concerns, the code that i wrote above is deliberately
written wrong "
Snippet of the code ( Logically incorrect , just to clarify the query )
What i was actually trying to figure out is what happens to the Current
Record once the EOF condition is sensed: OR what would be in the record
buffer when the EOF is sensed: Mine above code confirms that the
last record will be present
Coming to the correction:
Above code can be simply be corrected by Putting the READ statement
ONCE Before the Perform Block and then at END of the Perform Block
" |
|
| Back to top |
|
|
Kausar.S
New User
Joined: 01 Oct 2010
Posts: 4
Location: Mysore
|
|
|
|
Hi Amit,
When end-of-file has been encountered then "No next logical record exists in the file".
I believe last record is stored in buffer.When you tried to read the record after EOF then last record will be processed as u told.
correct me if am wrong anywhere |
|
| Back to top |
|
|
Ronald Burr
Active User
Joined: 22 Oct 2009
Posts: 293
Location: U.S.A.
|
|
|
|
| Amit Suri wrote: |
| What i was actually trying to figure out is what happens to the Current Record once the EOF condition is sensed: OR what would be in the record buffer when the EOF is sensed: Mine above code confirms that the last record will be present |
Sorry, but you have not "confirmed" any such thing. All you have done is show that in the SPECIFIC test that you ran, the last record was present at the current buffer address following detection of EOF.
When the manual says that the value of the current buffer address following EOF is UNDEFINED, it means that the address MIGHT be pointing at the last record, or it MIGHT be pointing at the nth record, or it MIGHT be pointing somewhere else entirely.
To "confirm" that the last record will ALWAYS be present, you would have to run MANY, MANY tests with MANY, MANY variations of record formats (fixed/variable/undefined), record counts, blocking factors, and buffer counts (JCL BUFNO's), not to mention variations of RECORD CONTAINS and BLOCK CONTAINS values in the program source code.
I'm quite sure that IBM has ALREADY performed such testing and has found that in at least ONE such test (and probably more than one) the current buffer address following the detection of EOF did NOT point at the last record - and so were compelled to issue the caveat in the manual that the results would be UNDEFINED (meaning UNPREDICTABLE).
To IGNORE such caveats is foolish - especially since it is so easy to save a copy of input records in working storage so that you KNOW that you have (a copy of) the last record following detection of EOF. |
|
| Back to top |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006
Posts: 1049
Location: Richmond, Virginia
|
|
|
|
| UNDEFINED means in many cases that although IBM (in this case) knows what will happen, they do not want to lock themselves into that result until the end of time, so by specifying the result of a situation as UNDEFINED, they leave themselves room for alternate implementations in the future. |
|
| Back to top |
|
|
Amit Suri
New User
Joined: 28 Oct 2008
Posts: 25
Location: hyderabad
|
|
|
|
Thanks all for clarifying
@Ronald Burr
I agree that mine code did not confirm anything.Sorry for that incorrect
statement |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
Last year I had to debug a few programs where the read was with the workarea option,
but the code
(depending on which idiot had last updated the module)
which would mostly reference the workarea fields,
had a few references to the buffer area after the eof was found.
every week or so, they would experience a S0C4.
Changed the all the references to workarea,
then spent the next 3 days developing test data
that provided the right mix of record type and counts that would cause the S0C4.
(old module - new module test/comparision)
What was worse was trying to get people to understand the problem.
oh, it's been more than a year and no more S0C4's. |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India
|
|
|
|
| Quote: |
| What was worse was trying to get people to understand the problem. |
When that happens I feel as if I'm in IT and trying to explain the point to someone in Auto-Mobile company! I hate this! |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
What i was actually trying to figure out is what happens to the Current
Record once the EOF condition is sensed |
As IBM has said about many things:
"The results may be unpredictable"
What is not so often said is that when the next release of the compiler is implemented, the unpredictability may change (i.e. the code will act differently).
If the code did not actually read a record, the code should not "use" a record. . . |
|
| Back to top |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006
Posts: 1049
Location: Richmond, Virginia
|
|
|
|
And to append to my UNDEFINED comment above:
Even if you "know" what the result of an officially UNDEFINED action is, you have no business coding with that "knowledge" in mind, as "unpredictable" means not just various tests you may make today, but over time as well. |
|
| Back to top |
|
|
|
|
