I hear you. I guess we may have to agree to disagree. I think the problem of reporting errors that occurred many layers deep is a general software design problem that has not been adequately solved. The low level component has no idea what the big picture is -- "what am I doing here from the user's point of view?" -- and on the other it is a challenge to pass a variety of different types of errors up the return of a call chain in a way that will lead to error message clarity.
Before anyone beats me up for what I am about to say, let me say first that I have been coding assembler since 1968, and it was my primary language for much of the period 1968 to 2008, so please don't accuse me of a lack of assembler knowledge or skills. For the past ten years I have been developing z/OS "system" software primarily in C++. I have become a big believer. I like the productivity -- I think I can write more end-user functionality in a day than an assembler programmer. I like the avoidance of low-level errors -- "oh crap, I forgot that routine needed R2." I like the incredibly optimized object code produced by the compiler. I like the design that emerges from object-oriented thinking. One of the side effects of developing in C++ is an end to reliance on dumps as a primary debugging tool. One, the machine code produced by the C++ compiler is often inscrutable. Two, any dumps tend to be humongous. Three, LE provides pretty good diagnostics and trace-back for ABENDs and similar errors. And four, it is really easy to generate very informative and detail-filled error messages. So I would much rather debug from a specific error message rather than from having to figure out from a dump just which system call failed. In some cases yes, I follow that error message with an ABEND or a throw (which is kind of the C++ equivalent of an ABEND with an ESTAE -- it jumps you from wherever you are to some higher level routine that said "notify me here of any big deal errors below -- kind of like ESTAE). But that is my choice. I wish that MVS would not deny me that choice by "ignoring" COND=YES. To your point about EXECUTABLE=YES, I have always thought that FREEMAIN required too many details. If MVS is to free the storage, what difference does it make if it is executable or not? The address is unique -- why must the subpool be specified? If I were designing FREEMAIN from scratch, I would drop the LENGTH and just always free the entire block. Yes, you would lose the ability to free half of a buffer -- but gain some simplicity of design, and eliminate the nasty bug where you free all but 8 bytes of some repeatedly-obtained area, and never notice it until some customer runs out of (contiguous) memory. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Saturday, January 26, 2019 9:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IARV64 - why ABEND rather than return with reason code? On 1/26/2019 4:37 PM, Charles Mills wrote: > ... 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"? Most conditional storage obtain/release failures occur in routines that are nested very deep. They return up to their caller, who returns to their caller and so forth. By the time you reach a routine that cares enough -- or has the ability -- to write a message, the actual failing scenario has been totally lost in translation. Even if a message is issued by the code requesting the storage service, keep in mind that a "Bad return code from FREEMAIN RC=xx" message tells you absolutely nothing about how to SOLVE the problem. You need to get a dump and issue VERBX VSMDATA/RSMDATA or reproduce under a debugger -- and that isn't always possible. In z/OS V2R4 JES2 is now using EXECUTABLE=NO storage for data areas. Did you know existing FREEMAINs will fail on such storage unless you also code EXECUTABLE=NO? It took quite a while, even with a dump and VSMDATA, to understand why one of our FREEMAINs was abending in that environment. This kind of problem is essentially unsolvable without a dump. Decades of experience won't help you when the rules change out from under you and no dump exists. The reality of what has happened since we removed our conditional storage requests is that we now detect nearly 100% of storage-related errors in-house through our normal testing and incidental usage of our own products before customers ever see them. Previously, messages might have appeared, but they weren't always seen or acted upon. Nothing gets people to take notice better than a dump! Occasionally, we get abends in the field and NOW -- because of the change from conditional to unconditional -- we have excellent FFDC (First-Failure Data Capture). The SDUMP tells everything anyone ever wanted to know to solve the issue and no recreate is ever needed. We don't seem to have issues with customers sending dumps. We support both SFTP and HTTPS credentialed/secure file transfers and we have an Information Security Policy (ISP) in place that protects and guarantees proper disposal of customer data when no longer needed. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
