"64-bit" has not really been on application programmers' plates until COBOL 6.3.
And yes, debuggers and dumps certainly overlap. I would guess that Compuware would assert that Abend-AID plays in the debugger space, and it is very much an alternative to the 3700-page dump. +1 on the need for serious storage management for SYSMDUMPs. SYSUDUMPs on the other hand just fall into the JES spool space management world along with lots of other "printouts." Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Friday, March 27, 2020 8:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 64-bit application dump analysis [was: RE: Problems with ESTAEX invoked in AMODE 64 . . . ] 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. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
