View previous topic :: View next topic
|
Author |
Message |
mallik4u
New User
Joined: 17 Sep 2008 Posts: 75 Location: bangalore
|
|
|
|
Hi,
Request you to provide your valuable advise on the following query:
Would it be good to check FILE STATUS after READ/WRITE in program(having IF FILE STATUS = 00) or leaving it to Operating System to handle it is better.
Please share your thoughts.
Thanks,
Mallik |
|
Back to top |
|
|
singhju
New User
Joined: 01 Dec 2010 Posts: 25 Location: Gurgaon
|
|
|
|
It is always better to handle the return codes. For example, you might be doing some process after READ operation, what will happen if READ itself is not successful. In that case, you do not want to proceed further and will need some meaningful error logging. |
|
Back to top |
|
|
mallik4u
New User
Joined: 17 Sep 2008 Posts: 75 Location: bangalore
|
|
|
|
Hi,
Thanks for the quick reply.
If something goes wrong with the file read and if i am not handling explicitly in the program then OS will ABEND the program. It will not proceed further.
I feel following are the general file statuses expected during file read:
00 - Success
10 - end of file
any way we will not be expected to get record length mismatch etc in production environment.
We will not be able to handle file space errors (during WRITE - not enough space available etc) anyway . OS will ABEND the program.
The only advantage I am seeing having explicit FILE STATUS check is, we will be able to DISPLAY the record information or statistics of the program in the SPOOL. But how frequently we will get READ/WRITE errors in stable environment. My question is, are we wasting CPU time by checking the FILE-STATUS explicitly or are there any other advantages checking the FILE-STATUS. Imagine if my program is processing 1 million records then it will be checking FILE STATUS for 1 million times.
Thanks,
Mallik |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
A couple of million IF tests is not a lot. Try it.
If you specify FILE STATUS for the file, the OS will not trap any errors for that file which would lead to value being returned to you. If you use FILE STATUS, it is up to you to test the status, else errors will be ignored.
Can't get errors? You can. Or for sure you used to be able to. If your DSCB is somewhere which can be overwritten through error, then anything can happen to it. Which can lead to records not being read, or not being written, but the program continuing.
I always use the FILE STATUS, and always check its value after each I/O operation. I don't use the tortuous AT END or INVALID KEY and stuff like that.
I don't think you'll ever gain much in reduced CPU usage by removing checking of the FILE STATUS and you'll leave yourself open to horrible errors if the unexpected happens. |
|
Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
|
|
|
|
mallik4u wrote: |
... any way we will not be expected to get record length mismatch etc in production environment. |
Famous last words ...
Personal opinion. "Real" I/O errors, that is to say I/O errors that are more "complex" than wrong length record, are almost unheard of any more when using disk, though tape I/O errors are still with us.
Back in the 1990s I was rewriting an application that used EXCP to read disk data. I thought about trying to write "smart" code to recover from "real" disk errors. Once every decade or so earlier versions of the program had encountered a "real" I/O error, and the program's response had not been pretty. After spending much thought on the problem, I had two revelations.- How am I going to test this code? It's easy enough to fake an I/O error, but there are many possible I/O errors; will my faking accurately reflect the status left behind by a real I/O error? Especially since "smart" recovery would be using this status.
- Wait a second. We're rapidly switching to RAID DASD. Will this code ever get used?
I got my sanity back and stopped thinking about this. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
If you are using one of the recent IBM z platforms, one million IF tests in COBOL probably will run less than 1 second of CPU time. Considering the problems you avoid, one second of CPU time per run is not a lot of overhead. |
|
Back to top |
|
|
Terry Heinze
JCL Moderator
Joined: 14 Jul 2008 Posts: 1249 Location: Richfield, MN, USA
|
|
|
|
Quote: |
But how frequently we will get READ/WRITE errors in stable environment. |
There's no guarantee that what's stable today is going to be stable tomorrow. Whoever maintains your program after you're done with it will appreciate the fact that there are useful error messages due to a check for FILE STATUS. |
|
Back to top |
|
|
mallik4u
New User
Joined: 17 Sep 2008 Posts: 75 Location: bangalore
|
|
|
|
Thank you all. |
|
Back to top |
|
|
|