IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

FILE STATUS check


IBM Mainframe Forums -> COBOL Programming
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
mallik4u

New User


Joined: 17 Sep 2008
Posts: 75
Location: bangalore

PostPosted: Thu Jun 26, 2014 2:50 pm
Reply with quote

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

New User


Joined: 01 Dec 2010
Posts: 25
Location: Gurgaon

PostPosted: Thu Jun 26, 2014 3:03 pm
Reply with quote

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

New User


Joined: 17 Sep 2008
Posts: 75
Location: bangalore

PostPosted: Thu Jun 26, 2014 4:23 pm
Reply with quote

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

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Thu Jun 26, 2014 5:00 pm
Reply with quote

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

Active Member


Joined: 30 Nov 2013
Posts: 917
Location: The Universe

PostPosted: Thu Jun 26, 2014 5:14 pm
Reply with quote

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

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Thu Jun 26, 2014 6:05 pm
Reply with quote

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

JCL Moderator


Joined: 14 Jul 2008
Posts: 1249
Location: Richfield, MN, USA

PostPosted: Thu Jun 26, 2014 6:51 pm
Reply with quote

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

New User


Joined: 17 Sep 2008
Posts: 75
Location: bangalore

PostPosted: Fri Jun 27, 2014 11:28 am
Reply with quote

Thank you all.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> COBOL Programming

 


Similar Topics
Topic Forum Replies
No new posts Extracting Variable decimal numbers f... DFSORT/ICETOOL 17
No new posts SFTP Issue - destination file record ... All Other Mainframe Topics 2
No new posts Access to non cataloged VSAM file JCL & VSAM 18
No new posts Need help for File Aid JCL to extract... Compuware & Other Tools 23
No new posts Job completes in JES, but the status ... IBM Tools 1
Search our Forums:

Back to Top