Point-and-shoot SYSUDUMP debuggers like DumpMaster (from Macro4 I think) provide a lot of the capabilities an average programmer with a little knowledge of how application languages lay out and use storage can go a long way to substituting for IPCS, which has worlds more power and a correspondingly longer learning curve.
Would that more such point-and-shoot products were available, or even better were FOSS products. <*Sigh*> Not in this lifetime, I know. Folks have to earn a living after all. Has anyone thought to put together an IPCS "cookbook" with sets of commands to get information useful to an application programmer together in one place (like Barbara's "here's-the-traceback-from-your-transaction-dump" example)? People can educate themselves, but they do need guidance from expert users to help them get started. Peter -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Barbara Nitz Sent: Sunday, April 18, 2021 11:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Print a SYSMDUMP >I consider //SYSMDUMP DD SYSOUT=* to be the best way to manage batch >job dumps. We've done this for years with excellent results. Until you get burned really badly in a commercial installation: We had an address space (STC) where the job output went into the archive product. Someone had put sysmdump dd sysout=* in the JCL. That STC had its roots in OMVS and kept abending and terminating, writing a dump each time. The parent process kept restarting the address space. We got the messages that the spool of the archive product was full which in turn kept the job output including the dumps in JES2 spool. We weren't fast enough deleting the job output in JES2 spool. The archive product counted lines only, regardless of lrecl. Each sysmdump line was 4160 byte long, which wasn't readily recognizable und substantially longer than a 'regular' output line. It took a long time to determine what had filled the archive product's spool because the (long) lines weren't that many, the byte count was. And the byte count wasn't shown easily. As a result, sysmdumps (other than to a data set) were banned from JCL. >What is the 21st-Century rationale for not allowing everyone to use IPCS? Mostly ignorance, I would guess. We have allowed application programmers to use IPCS (I think), because I seem(ed) to be the only one capable of reading a transction dump and got tired of giving them the traceback. Despite that, I am not sure that anyone other than myself (in our installation) knows how to use IPCS. It is not just a question of knowing which command to use to produce results, it is a question of interpreting the command output. That knowledge seems to disappear at a fast rate. And products like z/OSMF dumb down the sysprogs even more. I am guessing that in 10 years nobody outside a z/OS software producing company will know how to use IPCS anymore. Barbara -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
