Peter, IBM may have made that decision about SYSABEND and SYSUDUMP 20 years ago, and perhaps z/OS systems programmers who pay attention have been aware of it since then, but as an application programmer during that entire time I never saw that decision communicated in any form from either IBM or from my employer's systems programming team.
So yes, there really are many application programmers out in the world who are not aware of that decision. And I suspect that many management teams are not aware of it as well. The digression concerning debuggers was in the sense of having an alternative to any need for dump reading in the first place. A competent interactive debugger can usually (though not always) substitute for post-abend dump reading, at least during development and unit testing. Production abend debugging is a different situation entirely of course. There are ISV solutions (Abend-Aid, Symdump, etc.) of varying levels of quality and usefulness, but I am not aware whether any of them supports storage above the bar, though of course they really should now that EntCOBOL V6.3 is available. Switching to SYSMDUMP for future 64-bit batch application dumps in production jobs will also involve the Storage and Operations teams at a company, since provision for storing (and perhaps keeping archives of) SYSMDUMP files for resolving hard-to-find errors will certainly require increased and perhaps even dedicated disk space and archival rules. Operations teams will need instruction and guidance from the Storage teams about what to do when / if SYSMDUMP disk space is filled up and the application team hasn't got a valid dump to interpret. These are not trivial (or cheap) processes and procedures to put into place in large organizations. And yes, application programmer training is needed, and that is not a trivial (or cheap) effort whether instructor-led or self-paced "learn it yourself" courses. At the very least a company has to provide its programmers on-the-job time to do the "self-paced" learning exercise and factor that time into already tight project schedules. IMHO, as IBM begins to provide and promote the use of 64-bit application programming it really ought to make a concerted effort to make customer management teams aware of these needs so that they do not come as a surprise. In my experience, management teams rarely appreciate technical surprises. Peter -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Peter Relson Sent: Friday, March 27, 2020 8:41 AM To: [email protected] Subject: Re: 64-bit application dump analysis [was: RE: Problems with ESTAEX invoked in AMODE 64 . . . ] EXTERNAL EMAIL As Tom Marchant in effect said, the z/OS answer to the question of what to use for dump analysis of application dumps is SYSMDUMP (or TDUMP). And it has been for a long time. And yes it takes IPCS to use it. The decision to leave SYSABEND and SYSUDUMP processing alone with respect to 64-bit storage was made 20 years ago. So why this is new news to you, I have no idea. I cannot speak with respect to shops that restrict necessary tools unnecessarily. A "debugger", however, is not typically thought of as a "dump reader/analyzer". Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
