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.
@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? Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Saturday, January 26, 2019 6:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IARV64 - why ABEND rather than return with reason code? "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...". Truly, you should think of COND(YES) on an obtain of storage as applying for the most part only to "is there enough storage". For that case, it can probably often meet the demanding criteria of Ed's team. <snip> I found this to be the most irritating aspect of working with 64 bit areas. </snip> My initial thought when I read that was "if that's the most irritating thing then you must not do much with 64 bit areas". ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
