The following detail in the z/OS 1.13 announcement made me curious: "Language Environment is planned to support recovery from additional abends during output and close operations for C/C++ programs, and to return to C/C++ programs indicating that an I/O error has occurred rather than issuing an abend. This is intended to provide a more predictable recovery environment for C/C++ programs when I/O errors are encountered."
I don't know any specifics on what is being referred to here, nor do I have XL C/C++ to test anything. But it makes me wonder about others general philosophy on handling what I'll call "unexpected conditions". In my 15 years of application programming I've always hated the need to check 'status result' fields for conditions that, well, should not occur. Most (not all, of course!) of the time its going to be the case that the application is simply going to have some code to check for expected status conditions, and if the status is not expected print out an error message and exit (hopefully with a 'non-successful' exit code of some sort) or force an abend. So why not just allow the invoked routine to abend itself? I am actually working on some small subroutines to check for error conditions resulting from DL/I calls, DB2 calls, and COBOL file I/O. The routine will allow for one "expected unsuccessful" result (such as "no more data", "record not found", etc.), and in any other case it will use the LE CEESGL routine to signal an error with a useful error message. For batch I will then have a global USRHDLR that will query the operator as to what they want to do, with options such as "create a CEEDUMP", "percolate" the condition (in the end abending with U4038), continue processing (if the condition is I, W or E, but not S or C), etc. In CICS the handler will not give the user an option to do anything but percolate, but it will display the formatted reason to the screen (assuming invoked from a terminal, of course!). By doing all of this it seems to me the applications will need a lot less checking for errors from which the application cannot recover anyway. Like logic errors that should happen only when testing (trying to read from a file that is not open, or whatever). These are cases where obviously if you "expected" it it would not occur, because you will have the appropriate logic in place. I'm also going to change called subroutines to signal error conditions. Why should an application have to check to make sure that it called the routine with the proper data. The caller should always call a routine with valid data. If not it's pretty much a "logic error". Should not the subroutine signal an error, thus not requiring the caller to check for situations which "should never occur", and if they do occur must be fixed by fixing the code so that it is not calling with bad data? It looks like LE, to some degree, follows this same line of thought. In fact, when calling an LE routine you have the option of checking the result inline (by providing a "feedback code" area) or just having the routine signal the error and, generally, aborting the program (assuming it's not handled). Unless you're actually using the routine to not only act on your data as a data validator as well (which is reasonable in some cases), what point is there of having the routine return back to your code when all your code is going to do is say "unexpected error in call to xxx" and terminate/abend. CICS conditions are the same. NOHANDLE is both good and bad. It's good because HANDLE CONDITION is not locally scoped to a single EXEC CICS command, while NOHANDLE is. But it's bad in that you have to have a not of error checking for those unexpected conditions. Wouldn't it be better to, on an EXEC CICS tell CICS what conditions you'd like to handle programatically and have CICS do the proper abend for all other cases? Then if it turns out there is a case you should be handling but were not aware of at design time you can add it and handle it appropriately. I've actually submitted this very requirement to IBM as a result of their recent CICS "what do you want?" survey. In the end I know a lot of people will disagree with this philosophy right off. But I ask you, especially those who write application code, would this not make life simpler? And in most cases no less robust. Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 >>> The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
