IBM Mainframe Forum

Hello,

Here's my understanding.

You are "missing" "User abends". System abends are Sxxx. User abends are Unnnn.

I mean, I used to hear several folks at my shop, treating a Program setting a bad return-code, as an "ABEND", atleast in common parlance(in English).

Many, many organizations use incorrect terminology - and this is increasing because new people are not being taught properly.

On the other hand, some User abends were treated as informational not show-stoppers. Which i personally also do not support. I suspect we all need to be flexible and use whatever is used in the local environment. It has gone too far to correct

Quasar wrote:The Program is Killed - ABEND
When a Program encounters an exceptional situation(error), which it is unable to handle, the OS has to intervene and KILL the Program. This is called an Abend. When an Abend occurs, the MVS OS is in a hurry to rush to the Abend-Exit door, and flushes out all "the remaining steps" in the Job. Every ABEND has ABEND Code.

I can't really agree with this. The program is not "encountering" an error it is "unable to handle". In Cobol, for definite, you have no way at all of "handling" or "trapping" an Abend. An Abend, by which I mean a System Abend, a four character message starting with S and having three hex-digits following, is when your program, through an error, attempts an instruction, at machine code level, that it is impossible to carry out. It is illogical in this case for anything other than program code constituting an Abend-exit and the sort of clean-up that Steve has already mentioned.

Quasar wrote:The Program terminates peacefully -
When a Program encounters an exception, which it was designed to detect and handle, it comes to an end peacefully, by executing STOP RUN. The Software Program complains about this error(exception) by setting a two-digit status code, called COND CODE or RETURN Code. Programs set different Return-codes, to indicate different things to the Outside-world, and raise an alarm. Such programs are said to be robust.

As Dick has pointed out, you don't mention User Abends at all. I assume here you are talking about "errors" from the original question. To me, the vast majority of "errors" in a program are those that the program gives no indication of. If you do a calculation where you are supposed to multiply by two, but instead, in error, you divide by two, nothing is going to do anything about setting a return code or anything remotely similar. The program will proceed quietly to the end (assuming no further errors which cause an Abend or setting of your return code...) and will complete, with the incorrect value stitting on your report/screen or having corrupted your output file/database.

A Cobol program, even a main program, doesn't have to use a STOP RUN. On the MVS/OS side of things anyway, it can use the RETURN/GOBACK just like a sub-program, because it has, for your purposes, been "called" by the operating system.

BillyBoyo wrote:... The program is not "encountering" an error it is "unable to handle" ... is when your program, through an error, attempts an instruction, at machine code level, that it is impossible to carry out.

This statement is partially true. It describes S0Cx type ABENDs, but there are hundreds of other Sxxx ABENDs. Many of them are related to problems when opening a dataset, and sometimes a program can do something about it. My shop, for example, used a CA product called Jars-SMF. We frequently had problems with Sx13 errors when it opened a tape for output. Us on-call people had a standard response for this to force the product to start a new tape rather than attempt to add a new file to an existing tape, which was OK once we could call in from home and fiddle with Jars. It took some persuasion but CA eventually put this response into the program.

There are possible programmer responses to some S0Cx ABENDs. In System/360 hardware this was impossible because Principles of Operation did not specify the status of output data after S0Cx ABENDs. Every machine was different. System/370 Principles of Operation explicitly defined this status and made possible a programmed response to some S0Cx errors that was valid for all System/370 and later machines. I don't know if anyone tried this idea. We got lazy in System/360 and never tried a programmed response because any programmed response was hardware dependent in System/360, and this attitude, though no longer correct, followed through to System/370.

I always appreciate your comments, Steve, they always make me think.

I had mentally stretched the point with things like S806 and Sx37s. At machine code level, things are working OK, but there is an unavoidable lack of resource in some way, which can't be handled. OK, also not quite true, but tricky if something else has just gobbled up all the space on the volume(s) your output datasets are using and you try to write a new block of data.

Also, thinking after your comments, I remember way back, on DOS/VS (actually we used a "souped-up" version called DOM/VS) that there were some jobs at our site which used "checkpoints". With long run-times, checkpoints were written to tape periodically. If an Abend occurred then if the offending data could be fixed or removed from the input files, then you could "go back" to the previous checkpoint and not loose the whole run. I have no idea whether "the OSs" had this concept, I certainly never heard of it again.

I'm talking about batch systems with no databases, all "flat" files. I'd expect online systems, and database updates, to support assorted methods of recovery from abends - but, as usual, recovery from plain "errors" can be much more problematic, if for no other reason than sometimes they are not discovered for an extended period of time, whereas if you get an Abend, I was told once by OPS, they may have been pulling my leg, that it even makes a warning noise on the system console, not much "discovery" is required.

Billyboyo's comment about recovering from infrequently encountered errors is very apt. I've often put in code to try to do this only to have the code fail when it encounters the error. My record was error recovery code written in early 1976 failed in 1990 when it encountered an error for the first time.

Hello,

I was told once by OPS, they may have been pulling my leg, that it even makes a warning noise on the system console, not much "discovery" is required.

On the s360, there was a "ringbell" "feature". In/near the console was a real bell. If the ringbell was successfully invoked, the console operator typically came out of the chair. . .

I seem to recall when we swapped out the 360s for 370s, there was a horn instead of the bell. We also disabled this in application programs. . .

Hello -

I just updated the contents on my website as follows -

When a Program completes successfully, it sets a Return Code or COND CODE=00, to mark-off its successful completion. On the other hand, when the COBOL Program detects an error, it sets a non-zero (bad) Return-Code or COND CODE, to raise an alarm, a warning-signal, and complains.

At times, a Program attempts to execute an instruction at the machine code level, which is logically impossible. The MVS OS has to abnormally terminate or kill the program. This program crash is called an Abend. Every Abend leaves behind a System Abend-Code Sxxxx-yyy.

Please let me know, if that's okay. My experience is a tiny speck, relative to the folks on this forum. But from whatever, I could grasp of the above discussion, I made it point to update my article on Job Abends.

Here's the link : http://www.mainframes360.com/2009/06/jcl-tutorial-06-exec-statement-part-ii_28.html

Thank you very much.

Hello,

When a Program completes successfully, it sets a Return Code or COND CODE=00, to mark-off its successful completion. On the other hand, when the COBOL Program detects an error, it sets a non-zero (bad) Return-Code or COND CODE, to raise an alarm, a warning-signal, and complains.

At times, a Program attempts to execute an instruction at the machine code level, which is logically impossible. The MVS OS has to abnormally terminate or kill the program. This program crash is called an Abend. Every Abend leaves behind a System Abend-Code Sxxxx-yyy.

Please let me know, if that's okay.

No this is not OK. Any return-code (even zero) can signify complete success, qualified success, or that something has failed.

Why do you believe you need to put things on your website that are fully/completely documented elsewhere. You should understand that this is one of the biggest sources of mis-information and incorrect terminology usage. People doing a search have no idea about the quality/usefulness of a bit of found info. I would recommend that you spend the time learning various things rather than posting bits and pieces of partially true understanding.

Hi dick -

I guess I'll have to learn more. If My body of work, for which I have put in couple of years - my website is just crass, truly its Time for me to pull up my socks.

Thank you very much.