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
 

 

EOF Condition in Read statement

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

New User


Joined: 28 Oct 2008
Posts: 25
Location: hyderabad

PostPosted: Thu Oct 14, 2010 12:17 am    Post subject: EOF Condition in Read statement
Reply with quote

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

Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Thu Oct 14, 2010 12:34 am    Post subject:
Reply with quote

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

Active Member


Joined: 31 Oct 2006
Posts: 961
Location: Richmond, Virginia

PostPosted: Thu Oct 14, 2010 12:34 am    Post subject:
Reply with quote

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

New User


Joined: 28 Oct 2008
Posts: 25
Location: hyderabad

PostPosted: Thu Oct 14, 2010 1:27 pm    Post subject:
Reply with quote

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

New User


Joined: 01 Oct 2010
Posts: 4
Location: Mysore

PostPosted: Thu Oct 14, 2010 2:22 pm    Post subject:
Reply with quote

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

New User


Joined: 28 Oct 2008
Posts: 25
Location: hyderabad

PostPosted: Thu Oct 14, 2010 2:29 pm    Post subject: Reply to: EOF Condition in Read statement
Reply with quote

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

New User


Joined: 01 Oct 2010
Posts: 4
Location: Mysore

PostPosted: Thu Oct 14, 2010 2:55 pm    Post subject:
Reply with quote

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

Active User


Joined: 22 Oct 2009
Posts: 293
Location: U.S.A.

PostPosted: Thu Oct 14, 2010 6:58 pm    Post subject:
Reply with quote

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

Active Member


Joined: 31 Oct 2006
Posts: 961
Location: Richmond, Virginia

PostPosted: Thu Oct 14, 2010 7:04 pm    Post subject:
Reply with quote

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

New User


Joined: 28 Oct 2008
Posts: 25
Location: hyderabad

PostPosted: Thu Oct 14, 2010 7:37 pm    Post subject:
Reply with quote

Thanks all for clarifying

@Ronald Burr

I agree that mine code did not confirm anything.Sorry for that incorrect
statement
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Thu Oct 14, 2010 7:44 pm    Post subject:
Reply with quote

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

Senior Member


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

PostPosted: Thu Oct 14, 2010 8:03 pm    Post subject:
Reply with quote

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

Site Director


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

PostPosted: Thu Oct 14, 2010 8:35 pm    Post subject:
Reply with quote

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

Active Member


Joined: 31 Oct 2006
Posts: 961
Location: Richmond, Virginia

PostPosted: Thu Oct 14, 2010 8:49 pm    Post subject:
Reply with quote

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
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 -913/-911 Deadlock during UPDATE stat... NoSleep319 DB2 5 Fri Nov 18, 2016 12:37 am
This topic is locked: you cannot edit posts or make replies. How to pass the previous month date i... Suganya87 DFSORT/ICETOOL 5 Mon Oct 31, 2016 4:13 pm
No new posts CICS VSAM RLS READ akodakka CICS 3 Tue Oct 04, 2016 3:09 pm
No new posts COBOL DB2 - CALL statement - high CPU... TS70363 DB2 15 Sun Sep 11, 2016 6:07 am
No new posts Multi row fetch - "for read only... Nileshkul DB2 3 Sun Aug 14, 2016 12:52 am


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