Oppolzer - Informatik / Blog

Thank you for your contributions, but,

in my opinion you have a point of view where you have a single PL/1 program and
nothing else and total freedom to use all features of the language. Then you're
probably right.

But I'm talking of an IMS production environment, where there are 3000
concurrent users, and in case of an error throwing out an error message and some
variables to SYSPRINT (which region, who should look at it?) simply doesn't
help. And you have ASSEMBLER, C, DB2, MQS, and a myriad of other components
around the corner which all interact and produce their own errors. To handle
errors in this context in a coordinated manner and to address the error
protocols at the right place needs some planning. And you cannot allow every
single PL/1 procedure to do another special flavour of sophisticated error
handling, comprimising the error handling of the overall system, which relies on
the same techniques, that is, LE error handlers.

I don't see that this is 19th century. We are kind of proud to keep all this
going day by day. This is what mainframe is all about, IMO. And it's cost
effective, by the way.

Kind regards

Bernd




R. schrieb:
> From: "Bernd Oppolzer" <bernd.oppolzer@t-online.de>
> To: <ASSEMBLER-LIST@LISTSERV.UGA.EDU>
> Sent: Sunday, 28 March 2010 2:45 AM
>
>> Another difference: signal handling in C is part of the standard library
>> and not part of the
>> language, so the compiler has not to deal with it. Normal arithmetic
>> does not throw signals
>> in C (overflow and the such are normally ignored, which is questionable,
>> but it makes
>> powerful optimization possible, because normal arithmetic is not
>> interrupted by signals).
>
> There's no point in optimising a program in which overflow and the like
> are ignored.  You just get wrong results faster!
>
> Earlier you mentioned that you have your own debug tool ---
>
> ----- Original Message -----
> From: "Bernd Oppolzer" <bernd.oppolzer@t-online.de>
> To: <ASSEMBLER-LIST@LISTSERV.UGA.EDU>
> Sent: Saturday, 27 March 2010 6:27 AM
>
>> Regarding optimization: Mr G. asked, who today would want a compiler,
>> which does no optimization. In fact, we probably need OPT(0), because we
>> have a home grown debug tool, which needs the PL/1 statements to remain
>> contiguous blocks of machine code. So in some special cases a compiler which
>> does no optimization (that is: code rearrangement) could make some
>> sense.
>
> PL/I has its own debug tools built into the language,
> and does not need an external one.
>