On Sat, 26 Jan 2019 16:37:09 -0800, Charles Mills wrote:
>Well I must be really contrary or else I got out of the wrong side of the
>bed this morning. @Peter and @Ed are of course two of the people I most
>admire in the field of assembler and MVS, but I totally disagree with almost
>everything they wrote.
>
Yes. I've found it incongruous that OPEN has no error status return, only an
ABEND (which, yes, can be trapped.) An anachronism from an era when:
o Batch processing reigned supreme, and a failure in OPEN was most probably
a flaw in process design, properly to be fixed in that layer.
o Storage was too costly to support much diagnosis/reporting/recovery.
Middleware designers and ISVs face a quandary: whether to validate input
against errors that the OS will detect but report obscurely.
I find converting error reports generally to be a bad idea. Rexx is a major
offender. I've had colleagues well-versed in MVS ask me:
"What is Rexx trying to tell me by RC(-196)?"
"That's Rexxish for S0C4."
"Why doesn't it just say that?"
Good question. It's hard for me to imagine a target audience to whom
RC(-196) is more intelligible than S0C4. Both must be looked up in M&C,
the former after a conversion step.
IBM fixed an SR for me where Rexx displayed a 32-bit RC in 8 decimal
digits, truncated. The fix was to *conditionally* expand the field. It would
have been better to show it in hex as it appears in M&C. Blame it on the
Rexx standard which specifies *decimal* status codes.
Babel. SYNADAF provides terse but correct information. strerror and
bpxmtext do likewise in incompatible fashions. And BPXWDYN("MSG(stem.)")
is another variant. Conway's Law at its worst. QuickRef unifies if you pay
for it. Many do.
And long ago, @Peter scolded me for being dissatisfied with the effect of:
//STEP EXEC PGM=IEWL
//SYSPRINT DD FILEDATA=BINARY,... /* (The default). */
...
produces trashy output despite that the Ref. requires FILEDATA=TEXT.
@Peter says that since I broke the rules I deserve whatever I get. I still
believe, rather, that I deserve an error message for breaking the rules.
>@Peter, I'm a grown-up. If I code an MVS macro with COND=YES I expect to
>have to deal with return codes (and if I don't, well, my gun, my bullet, my
>foot). No, I don't try to "correct" an xx0042yy on the fly, but I do have an
>error message that is specific to IARV64 errors, and a table of message text
>specific to reason codes, so that customers and level one don't have to look
>them up. I would rather present the customer with an error message than with
>an obscure ABEND, and I think that should be my prerogative, especially if
>the macro provides a COND=YES option. COND=NO is there for people with a
>different philosophy, and that is fine with me.
>
>You cannot totally save programmers from themselves. This was an error in
>the code that has been running without problem in the field for two or more
>years. Unit testing did not catch it, ABEND or not. (FWIW the error was that
>I had the guard amount in a register rather than in a word pointed to by the
>register, and since the value was very small and most of very low core is
>zero it always worked. I only caught the error because of a development LPAR
>where someone had hosed low core.)
>
>At the very least IBM should document that COND=YES is really COND=MAYBE and
>document the conditions or the reason codes for which MVS ignores the user's
>expressed specification.
>
>@Ed, really? Your programmers are too busy or too whatever to code LTR
>R15,R15 and deal with non-zero? I would never code an unconditional GETMAIN,
>except in the rare situation such as the initial entry to a reentrant
>routine where it is a small GETMAIN and it is pretty much impossible to
>proceed at all if it fails. You would really rather have your customers and
>support staff deal with an S80A and a dump rather than a nice error message
>that says "ABC1234E Unable to obtain storage for record work area"? We can't
>even get customers to send dumps anymore because they are worried about PII.
>Or they delete the dump before they call support! How the heck do you
>determine just which GETMAIN failed?
>
>-----Original Message-----
>From: Peter Relson
>Sent: Saturday, January 26, 2019 6:15 AM
>
>"why" -- it's for the reason that Steve Smith mentioned. It's to help you
>get rid of the things that you should get out in unit test.
>For things that you should not be writing code for such as "if I get
>xx0042yy then...".
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
