[Default] On 27 Mar 2020 08:35:35 -0700, in bit.listserv.ibm-main [email protected] (Farley, Peter x23353) wrote:
>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. Is the a system way to equate SYSABEND and SYSUDUMP to SYSMDUMP such that JCL pointing to the first two automatically is changed internally to point to the latter. Obviously a JES2 exit 6 can do it. If this is done, can people read the SYSMDUMP as "easily" as SYSUDUMP? Clark Morris > >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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
