Oppolzer - Informatik / Blog

You are right, the

ON ERROR BEGIN;
ON ERROR GOTO ENDE;
...
END;

unit works as expected.

I tested it using a little test program which allocated buffer of 1 million
bytes in a loop (1000 times). After the 400-th iteration the error unit was
entered, following a STORAGE condition, which is reasonable, due to region size
etc. The iterations continued as expected, but because there was no STORAGE,
starting from then, the error unit was entered at every iteration.

Now the difference to the real thing is:

the storage is not allocated using PL/1-ALLOC, but the C++ math lib allocates
the storage; maybe there is even Xerces or other software packages involved
(some hundred modules, I don't know all of them). So I'm not sure if the
short-on-storage condition below is reflected by a PL/1 STORAGE condition (maybe
not). And: it could well be that there are additional error handlers below this
PL/1 level (maybe C++ try/catch logic).

My primary goal is: to understand, where this endless loop comes from, if this
PL/1 level is involved or if the endless loop happens to be completely below
this PL/1 level (in the C++ area). I have no traces at the moment, so I'm
starting from the top level and try to examine the modules at each level. I'm
trying to understand what happens, if the short-on-storage condition arises. The
co-workers add trace information at the various levels, so that we can retry the
process in the following days and get more trace information, hopefully.

Thank you so much for the moment

Bernd



Am 21.06.2012 10:44, schrieb R.:
> From: "Bernd Oppolzer" <bernd.oppolzer@T-ONLINE.DE>
> Sent: Thursday, 21 June 2012 5:57 PM
>
>
>> Thank you all for you suggestions so far.
>>
>> I would like to add that in the first error handler (which sets of
>> the ON ERROR GOTO ENDE)
>> there is a CALL to a function of the application which tries to do
>> some cleanup.
>>
>> While thinking some more time about the problem, I guess, that the
>> designer tried to accomplish
>> the following - well, let me first try to explain:
>>
>> in my opinion, there should only be one error handler in the main
>> routine. It should capture
>> the ERROR condition, write a dump, and terminate the process. This
>> should be normal behaviour in batch programs.
>
> Normal behaviour for batch programs is to continue wherever possible,
> rather than abort.
>
>> Now, in this case, my co-worker observed the short-on-storage
>> condition in the underlying
>> C++ math library and he tried to catch this by coding this ON ERROR
>> unit and continue with
>> the next input (I guess).
>>
>> ON ERROR BEGIN;
>> ON ERROR GOTO ENDE;
>> ...
>> here he called for example a function to get rid of some of the
>> storage !!
>> ...
>> END;
>>
>> CALL math_library;
>>
>> ENDE:
>>
>> ...
>>
>> Now my idea is: there are additional errors in the function which
>> tries to
>> free the storage, that is: inside the ON ERROR unit. If the ON ERROR
>> unit
>> is left using GOTO, I don't know how LE behaves. We resume NORMAL
>> PROCESSING
>> using GOTO, while in an ERROR handler. This does not seem sound to me.
>
> It is perfectly normal to leave an ON-unit via a GO TO.
> In point of fact, it it the only way to leave an ERROR ON-unit
> when continuation of processing is desired.
>
>> Furthermore, the short-on-storage condition will not be resolved,
>
> Why not? You haven't said how storage is taken (ALLOCATE?).
> However taken, storage can be released.
>
>> and if new inputs
>> are taken, new errors will occur. So the ERROR handlers will be
>> nested on and on ...
>
> ERROR handlers won't be nested on and on.
> As soon as GOTO exits an ERROR handler,
> that ERROR handler terminates.
> Recall that an ON-unit is like a procedure.
> When it terminates (even with GOTO),
> it terminates, full stop.
>
>> or do I get something wrong?
>>
>> Or precisely: if there is a GOTO in an ON ERROR unit, how does LE
>> handle this?
>
> The ON-unit terminates (presuming that the GOTO transfers control out
> of the
> ON-unit).
>
>> ON ERROR GOTO ENDE - in my opinion this means that the error is
>> ignored and
>> processing continues at label ENDE in case of an error.
>
> It's the second error that is processed. The ON-unit, namely, GOTO, is
> executed.
>
>> But if this is coded inside
>> an ERROR UNIT (or inside another block, specifying a label ENDE,
>> which is
>> non-local), there has additional work to be done.
>
> There is always additional work done when an ON-unit terminates.
> Recall that it's like a procedure.
>
>> In this special case, this means,
>> that in the case of an error TWO NESTED ERROR HANDLERS have to be
>> exited -
>> the one that handles the ON ERROR GOTO ENDE and the embedding one,
>> that contains the ON ERROR BEGIN; ON ERROR GOTO ENDE; ...
>
> That's perfectly normal.
>