pattern for an error - cobol

In article <9v9r34li5gfth17dttv7mu7f62587uv7el@4ax.com>,
Howard Brazee <howard@brazee.net> wrote:
>On Wed, 28 May 2008 17:36:48 +0000 (UTC), docdwarf@panix.com () wrote:
>
>>> IF FILE-STATUS-OK
>>> CONTINUE
>>> ELSE
>>> GO TO BAD-FILE-STATUS
>>> END-IF.
>>
>>Wait a moment... how did IKFCBL00 compile that?
>
>I don't know what IKFCBL00 is, but my IBM compiler will compile it.

IKFCBL00 was the IBM mainframe's COBOL '74 compiler; scope delimiters did
not appear until the 1985 standard.

DD

Howard Brazee <howard@brazee.net> wrote in message
news:9v9r34li5gfth17dttv7mu7f62587uv7el@4ax.com...
> On Wed, 28 May 2008 17:36:48 +0000 (UTC), docdwarf@panix.com () wrote:
>
> >> IF FILE-STATUS-OK
> >> CONTINUE
> >> ELSE
> >> GO TO BAD-FILE-STATUS
> >> END-IF.
> >
> >Wait a moment... how did IKFCBL00 compile that?
>
> I don't know what IKFCBL00 is, but my IBM compiler will compile it.
> But the people who code with Go To are also the people who don't use
> END-IF.

A calumny, that, thou poltroon.

END-IF is too useful not to be used, even for the non-GOTO-challenged.

PL

To use product names (rather than the PGM= name from JCL).

For the "MVS" environment (including OS/390, z/OS - but not VSE),

Any compiler from VS COBOL II, R1 and later will allow END-IF. (VS COBOL II,
R1, R1.2, and R2 were '74 Standard compilers. VS COBOL II R3.0 and later
support eh '85 Standard). They also support - as an extension - NEXT SENTENCE
in an IF that ends with END-IF. Support for END-xxxx syntax is available even
when CMPR2 is used to emulate a '74 Standard compiler - sort-of.

Any compiler from OS/VS COBOL or earlier will NOT support END-IF (or any other
END-xxxx syntax).

***

Most (but certainly NOT ALL) code with
GO TO NNN-PARA-NAME-EXIT
syntax in it (especially if coded in all CAPS) was PROBABLY originally coded for
OS/VS COBOL or someone who was trained on OS/VS COBOL (or earlier). If that
is/was the case, then you will NOT see

GO TO NNN-PARA-NAME-EXIT

In an IF statement that is terminated by END-IF. If you see the combination of
that type of GO TO (especially in CAPS and END-IF), the changes are medium-good
that you are looking at code that has been maintained (in the last 20 years) but
never really "upgraded" to current coding techniques.

All of this is VAST generalizations and many exceptions do exist (on IBM
mainframes and elsewhere).

--
Bill Klein
wmklein <at> ix.netcom.com
"Howard Brazee" <howard@brazee.net> wrote in message
news:9v9r34li5gfth17dttv7mu7f62587uv7el@4ax.com...
> On Wed, 28 May 2008 17:36:48 +0000 (UTC), docdwarf@panix.com () wrote:
>
>>> IF FILE-STATUS-OK
>>> CONTINUE
>>> ELSE
>>> GO TO BAD-FILE-STATUS
>>> END-IF.
>>
>>Wait a moment... how did IKFCBL00 compile that?
>
> I don't know what IKFCBL00 is, but my IBM compiler will compile it.
> But the people who code with Go To are also the people who don't use
> END-IF.

In article <IKk%j.872839$Gl5.737087@fe02.news.easynews.com>,
William M. Klein <wmklein@nospam.netcom.com> wrote:

[snip]

>In an IF statement that is terminated by END-IF. If you see the combination of
>that type of GO TO (especially in CAPS and END-IF), the changes are medium-good
>that you are looking at code that has been maintained (in the last 20
>years) but
>never really "upgraded" to current coding techniques.

Where is it... ahhhhh, wonderful thing, this Web... DejaNews... errrr,
Google Groups shows something from almost half of the aforementioned 20
years ago. Posted 19 Mar 1999, found at
<http://groups.google.com/group/comp.lang.rexx/msg/29d1b77320d7bfc7?dmode=source<

--begin quoted text:

>Other may prefer programming languages with more modern
>constructs.

Others may, sure... but let them *try* to get some code past a review and
implemented into Prod!

'What is *this* stuff? EVALUATE TRUE WHEN cond-1 imperative statement...
you call this COBOL?!?'

'Oh, please, Mr Standards-and-Practises Reviewmeister, it is exactly what
is allowed by the ANSI '85 Standard.'

'ANSI '85? Crap, I *knew* things were goin' ta hell in a handbasket when
we allowed them fancy ANSI '74 constructs in a couple a' years back...
look, 1985 is only 14 years ago, we oughta wait until the technology is
Really Proven before we implement it. Go back and rewrite this in *real*
COBOL, then try again.'

--end quoted text

Hmmmmm... come to think of it, the references go fill circle. From that
same posting, a few paragraphs earlier:

--begin quoted text:

>You might mull things over before snipping yourself, DD. The TSO
>and Rexx overhead is only paid once. Take a look at the "Address"
>clause. Once we pass control to native S/390 object code, we run at
>native S/390 object code speeds.

TSO and Rexx overhead is one thing.. IO algorithms are another. SyncSort,
for example, does things *much* more efficiently than, say, MVS BASIC and
I am assuming - rightfully or wrongly - that such a thing is at work when
IKJEFT01 moves faster than a COBOL program does. Both are doing the same
thing - READ an inrec, INSERT it into a table-row, all IO, nothing more -
so I conclude that the IO subroutines included into the LM generated by
HEWL from the object code generated by IKFCBL00/IGYCRCTL are less
efficient than those used by IKJEFT01... if this assumption or conclusion,
based as both most obviously are, in conjecture, ignorance and overall
cogitative sloth, are incorrect, then be so kind as to point out where the
error was generated.

--end quoted text

(notice the fancy-pantsed and newfangled use of HEWL instead of IEWL,
too!)

DD

On May 28, 5:53 pm, mario <mmc_vw1...@hotmail.com> wrote:
> TKS for ur quick and helpful answers, i think i have to reexplain my
> problem
>
> forexample my big program is perform-ing a lot of deeper layer
> paragraphs, now my problem is that in one of those an error occurs,
> for example the Number was not found in Database or some user imput
> error ...
>
> the case now is that at this point there is a GoTo end = finish
> program
> what i need is now a design pattern to handle those errors so that the
> first layer paragraph knows that deep down something has gone wrong
> and stops executing
> for example
>
> start.
> perform prog_layer2.
>
> do some other things
> ...
> .
>
> prog_layer2
> perform prog_layer3
> keep doing other stuff
> .
>
> prog_layer3
> perform prog_layer4
> now here an error occurs!!!!
> .
>
> my program looks now like that:
>
> start.
> perform prog_layer2.
>
> do some other things
> ...
> .
>
> prog_layer2
> perform prog_layer3
> keep doing other stuff
> .
>
> prog_layer3
> perform prog_layer4
> now here an error occurs!!!! -> GOTO END
> .
>
> END
> exit program
> . (finished)
>
> my solution i am now working at is looking like that:
>
> start.
> perform prog_layer2.
> if error = 1
> exit program
> and dont do the other things
>
> do some other things
> ...
>
> goto end
> .
>
> prog_layer2
> perform prog_layer3
> if error = 1
> exit program
> and DONT do the other stuff below
>
> keep doing other stuff
> .
>
> prog_layer3
> perform prog_layer4
> now here an error occurs!!!! ->
> move 1 to error
> exit program
>
> END
> exit program
> . (finished)
>
> so far i think its not that clean that solution and if those lower
> layers get called often the hole thing gets VERY unclear and is full
> with "if error..."
> so is there any design pattern that u know for example like in java
> exception handling so that i can handle my errors in a clear program
> flow??
>
> i hope now my problem is more transparent to you
> and thank u all for helping me!!!
>
> mario

If you draw your program structure and architecture, you can see your
problem better.
I suggest you to:
1- separate layers in sections
2- in each section you can redesign the layer structure.
3- exception handling is nothing but a GO TO, you can not escape it.
just organize it as:
+ use declaratives for file exception handling.
+ use file status check and ON Overflow, AT End and ... for known
exceptions.
+ cluster your other exceptions(exit conditions) in each layer and
make different paragraphs to handle it(something like: exit-normal,
except-math, except-...)
+ also create a Data-Group for return status between layers, like:
01 Exception-Result
05 Code pic 9999.
05 Message pic X(50).
Initialize it at any function (paragraph) startup and check it after
call to handle exceptions between layers.

I used the mechanism like this to implement an exception handling in
my code.
I hope be useful and will appreciated for any idea.

On Sat, 31 May 2008 22:33:05 -0700 (PDT), amir <ahsharif@gmail.com> wrote:


>+ also create a Data-Group for return status between layers, like:
>01 Exception-Result
> 05 Code pic 9999.
> 05 Message pic X(50).

Use the Standard mechanism rather than inventing your own. Cobol calls it "return-code".

One of the nice things about return-code is that it cascades. For example, A calls B, B
calls C, C encounters an error, moves a non-zero to return-code and exits. B sees that
return-code is non-zero and simply exits. A gets the return-code set by C. When A exits,
the operating system/command shell gets the return-code set by C. If C is written in
another language, the return mechanism works the same way.

Embedded SQL does not follow the convention. You must 'move sqlcode to return-code.'

>Initialize it at any function (paragraph) startup and check it after
>call to handle exceptions between layers.

PERFORM does not pass parameters nor a return code; paragraphs cannot have private
variables (working-storage). It is Better to use CALL rather than PERFORM and nested
programs rather than paragraphs.

On Jun 1, 10:52 pm, Robert <n...@e.mail> wrote:
> On Sat, 31 May 2008 22:33:05 -0700 (PDT), amir <ahsha...@gmail.com> wrote:
> >+ also create a Data-Group for return status between layers, like:
> >01 Exception-Result
> >  05 Code   pic 9999.
> >  05 Message        pic X(50).
>
> Use the Standard mechanism rather than inventing your own. Cobol calls it "return-code".

It is _NOT_ a standard in Cobol-85. CALL ... RETURNING and EXIT
PROGRAM RETURNING are MF extensions in '85.

RETURN-CODE is an extension in Fujitsu Cobol, as is PROCEDURE
DIVISION .... RETURNING ...

If you have an '02 compiler then you should look up what that does.

> One of the nice things about return-code is that it cascades. For example,A calls B, B
> calls C, C encounters an error,  moves a non-zero to return-code and exits. B sees that
> return-code is non-zero and simply exits. A gets the return-code set by C.When A exits,
> the operating system/command shell gets the return-code set by C.  If C is written in
> another language, the return mechanism works the same way.
>
> Embedded SQL does not follow the convention. You must 'move sqlcode to return-code.'
>
> >Initialize it at any function (paragraph) startup and check it after
> >call to handle exceptions between layers.
>
> PERFORM does not pass parameters nor a return code; paragraphs cannot haveprivate
> variables (working-storage). It is Better to  use CALL rather than PERFORM and nested
> programs rather than paragraphs.

On Sun, 1 Jun 2008 18:19:41 -0700 (PDT), Richard <riplin@azonic.co.nz> wrote:

>On Jun 1, 10:52 pm, Robert <n...@e.mail> wrote:
>> On Sat, 31 May 2008 22:33:05 -0700 (PDT), amir <ahsha...@gmail.com> wrote:
>> >+ also create a Data-Group for return status between layers, like:
>> >01 Exception-Result
>> >  05 Code   pic 9999.
>> >  05 Message        pic X(50).
>>
>> Use the Standard mechanism rather than inventing your own. Cobol calls it "return-code".
>
>It is _NOT_ a standard in Cobol-85. CALL ... RETURNING and EXIT
>PROGRAM RETURNING are MF extensions in '85.
>
>RETURN-CODE is an extension in Fujitsu Cobol, as is PROCEDURE
>DIVISION .... RETURNING ...

RETURN-CODE began as an IBM extension to Cobol 74 in the days of OS/VS. It has been
supported by Micro Focus, Fujitsu and Realia for at least 20 years. It is a de facto
standard.

The traditional syntax is MOVE nnn TO RETURN-CODE followed by GOBACK, EXIT PROGRAM or STOP
RUN.

RETURNING used on EXIT PROGRAM, CALL and PROCEDURE DIVISION are relatively recent
additions.

Interestingly enough ....

Once MIGHT say that "Return-Code" is a COBOL Standard - if you mean the X/Open
rather than an ANSI or ISO Standard.

I also think it WELL pre-dates OS/VS COBOL for IBM mainframe compilers. I can
almost guarantee that it was in "ANS COBOL V2" which was a '68 ONLY compiler
(not '74 stuff). I also believe that it was in all the DOS/VS COBOL although
that included a COMREG which was never in OS/VS COBOL so I am not certain.

Personally, I think that the RETURNING (in one form or another) is much more
common in NEW programs, but the "return-code" fits in with the z/OS operating
system, so its use there is still meaningful in a "special way".

--
Bill Klein
wmklein <at> ix.netcom.com
"Robert" <no@e.mail> wrote in message
news:6bk644579pkvi4h5fq5lfdc862g22m0ilf@4ax.com...
> On Sun, 1 Jun 2008 18:19:41 -0700 (PDT), Richard <riplin@azonic.co.nz> wrote:
>
>>On Jun 1, 10:52 pm, Robert <n...@e.mail> wrote:
>>> On Sat, 31 May 2008 22:33:05 -0700 (PDT), amir <ahsha...@gmail.com> wrote:
>>> >+ also create a Data-Group for return status between layers, like:
>>> >01 Exception-Result
>>> > 05 Code pic 9999.
>>> > 05 Message pic X(50).
>>>
>>> Use the Standard mechanism rather than inventing your own. Cobol calls it
>>> "return-code".
>>
>>It is _NOT_ a standard in Cobol-85. CALL ... RETURNING and EXIT
>>PROGRAM RETURNING are MF extensions in '85.
>>
>>RETURN-CODE is an extension in Fujitsu Cobol, as is PROCEDURE
>>DIVISION .... RETURNING ...
>
> RETURN-CODE began as an IBM extension to Cobol 74 in the days of OS/VS. It has
> been
> supported by Micro Focus, Fujitsu and Realia for at least 20 years. It is a de
> facto
> standard.
>
> The traditional syntax is MOVE nnn TO RETURN-CODE followed by GOBACK, EXIT
> PROGRAM or STOP
> RUN.
>
> RETURNING used on EXIT PROGRAM, CALL and PROCEDURE DIVISION are relatively
> recent
> additions.
>