On 1/27/2019 11:55 AM, Charles Mills wrote:
One of the side effects of developing in C++ is an end to reliance on dumps as a primary debugging tool.
We haven't used dumps as a primary debugging tool in decades. Generally speaking, I'm sure our developers would call z/XDC our primary debugging tool.
Our "mantra" for errors that occur in the field is FFDC (First-Failure Data Capture) -- meaning that errors occurring in the field should ideally ALWAYS be solvable without a recreate. If they're not, then we need to improve whatever it is we're capturing.
I just can't imagine any trace back or similar information -- no matter how detailed -- that can tell you everything you need to know to solve a storage-related issue. Knowing you ran out of storage is great, but that won't get you anywhere near to understanding the root cause i.e., if there's no space, then why not? What's using it up and why? Is it a looping storage acquisition problem? Or is it really just a failing conditional "freemain" issue? And, if a "freemain" fails, why is that? Wrong start address? Wrong length? Wrong TCB? Wrong key? The same storage being freed twice? Reasons such as EXECUTABLE=YES|NO and others?
I would be working with one (or maybe both) hand(s) tied behind my back trying to solve such issues without IPCS SYSTRACE, VSMDATA and RSMDATA. Accept no substitute. ;-)
-- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ -------------------------------------------------------------------------------- This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
