Hi Peter,

If by "this vendor" you mean z/XDC, we have been increasingly supporting 64-bit debugging starting pushing two decades ago, and several years ago, z/XDC (in step with z/OS) has reached full maturity. It is now quite comprehensive.

Also, we will soon be beta testing a "dump/XDC" that will be able to process against System dumps, //SYSMDUMP dumps, and stand-alone dumps.


Best,
Dave






At 3/26/2020 02:44 PM, Farley, Peter x23353 wrote:
Well, I will have to see what our ISV dump debugging product is capable of when (or if . . .) we move into EntCobol 6.3, where 64-bit is being introduced to COBOL programs for the first time. Of course, that move itself is another rotten can of worms entirely, not for this discussion. I'm not sanguine that this particular dump debugging vendor will meet our needs, but it remains to be seen. Maybe by the time we need 64-bit support this vendor will have caught up, or maybe by that time IBM will have finally understood how bad a mistake its XPLINK direction for 64-bit code really is and engineer something far easier to use and to integrate easily into non-ISV customer development and production support environments, but I'm not hopeful in either case. I suspect that in many cases of such restrictions some ancient historical decision (justified or not) is what determined the restriction, the decision makers have long departed the company, and no one has looked at the restrictions since.
ObSchiller indeed.  Thanks for the reference, and how very true.
Peter
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Seymour J Metz
Sent: Thursday, March 26, 2020 1:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 64-bit application dump analysis [was: RE: Problems with ESTAEX invoked in AMODE 64 . . . ] ObSchiller IPCS is part of z/OS. All dangerous facilities of IPCS are controlled by SAF. If your management capriciously prohibits you from using it, the responsibility is theirs. It's certainly their prerogative to ban, e.g., IEFBR14, but no outside company is obligated to rescue them from the consequences of their decision. Not all companies take essential tools away from their application developers.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Farley, Peter x23353 [peter.far...@broadridge.com]
Sent: Thursday, March 26, 2020 1:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 64-bit application dump analysis [was: RE: Problems with ESTAEX invoked in AMODE 64 . . . ]
Mike,
That's all well and good for an ISV such as yourself who has the freedom to use whatever debugging tools you choose to use, but what are programmers in non-ISV shops without application programmer access to IPCS supposed to do? z/XDC is a wonderful interactive debugging tool with which I am quite familiar, but it's not so helpful for ordinary HLL interactive debugging (other than Colesoft's very fine c/XDC, to which I do not have access) except in very complex debugging tasks not covered by ISV interactive products. I haven't touched TSO TEST in umpty-ump decades and probably wouldn't use it even if offered the opportunity. In my experience it was a real bear to use, especially compared to z/XDC today. FWIW, I had to debug a quite complex assembler / BTAM / multitasking application running under the MVS of the day using only TSO TEST at a client site in another country. Got the job done, but definitely not an experience I ever wish to repeat.
Peter
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Mike Shaw
Sent: Thursday, March 26, 2020 12:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 64-bit application dump analysis [was: RE: Problems with ESTAEX invoked in AMODE 64 . . . ]
On 3/26/2020 12:11 PM, Farley, Peter x23353 wrote:
> Peter,
>
> If SYSABEND and SYSUDUMP don't now and aren't likely to support 64-bit storage in the future, then what are application programmers coding 64-bit programs (well, 31-bit resident code that uses 64-bit storage areas, to be specific) supposed to use for abend debugging? IPCS? ISV products?
<snip>
Yes.
An ESTAE(X), IEATDUMP to dump the storage from the ESTAE(X) exit, and IPCS to analyze it. We have been doing that for our non-APF authorized application that runs AMODE(64) since z/OS V1R12. z/XDC or TSO/E TEST command for interactive debugging.
Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.
----------------------------------------------------------------------
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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to