Re: Why it’s important to take Seymour’s advice
Also, if he doesn't already know IPCS, learning it would be time well spent. From: IBM Mainframe Discussion List on behalf of Rob Scott Sent: Sunday, September 17, 2023 5:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Why it’s important to take Seymour’s advice Joe, Once again, can I strongly suggest that you pause your functionality development for a while and invest some time into : (O) A robust general purpose recovery routine that can be used in all modes (prob/sup and TCB/SRB). This routine should focus on grabbing diagnostic information into a structure that your mainline code can understand and also modify its behaviour based on the program that established it. You can design a structure that the establisher passes as a parm on the ESTAE/ARR or FRR. Make it as generic as possible so that you can reuse in other projects. This would include whether to retry , what regs to restore , whether to take SDUMP or TDUMP, whether to issue messages via WTO etc etc (O) A comprehensive internal trace facility that can help you diagnose program flow issues and remove a lot of guesswork when issues arise. Even in its simplest form, adding a footprint into an internal circular memory buffer can greatly enhance your ability to debug. A few days writing IPCS rexx to locate and print out your trace buffer contents could save you weeks of head-scratching down the road. Writing this stuff once and doing a good job on it can gain you years of benefit. Rob Scott Rocket Software. Sent from Outlook for Android<https://aka.ms/AAb9ysg> From: IBM Mainframe Discussion List on behalf of Joseph Reichman Sent: Friday, September 15, 2023 11:16:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Why it’s important to take Seymour’s advice EXTERNAL EMAIL Seymour First let me wish you a good year I did schedule the irb in the ikjeft01 TCB against Seymour’s advice for a return code of zero from schedirb However the TMP Estae issued an SDUMP I guess it didn’t like me scheduling an irb in its TCB Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Rocket Software, Inc. and subsidiaries ¦ 77 Fourth Avenue, Waltham MA 02451 ¦ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- 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
Re: Why it’s important to take Seymour’s advice
+1 Since you do not have z/XDC, taking this advice from Rob will save you hundreds of hours of debugging later, PLUS ensure that your final product is reliable and as error free as you can make it. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Sun, Sep 17, 2023 at 5:38 AM Rob Scott wrote: > Joe, > > Once again, can I strongly suggest that you pause your functionality > development for a while and invest some time into : > > (O) A robust general purpose recovery routine that can be used in all > modes (prob/sup and TCB/SRB). > This routine should focus on grabbing diagnostic information into a > structure that your mainline code can understand and also modify its > behaviour based on the program that established it. You can design a > structure that the establisher passes as a parm on the ESTAE/ARR or FRR. > Make it as generic as possible so that you can reuse in other projects. > This would include whether to retry , what regs to restore , whether to > take SDUMP or TDUMP, whether to issue messages via WTO etc etc > > (O) A comprehensive internal trace facility that can help you diagnose > program flow issues and remove a lot of guesswork when issues arise. Even > in its simplest form, adding a footprint into an internal circular memory > buffer can greatly enhance your ability to debug. A few days writing IPCS > rexx to locate and print out your trace buffer contents could save you > weeks of head-scratching down the road. > > Writing this stuff once and doing a good job on it can gain you years of > benefit. > > Rob Scott > Rocket Software. > > Sent from Outlook for Android<https://aka.ms/AAb9ysg> > > From: IBM Mainframe Discussion List on behalf > of Joseph Reichman > Sent: Friday, September 15, 2023 11:16:59 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Why it’s important to take Seymour’s advice > > EXTERNAL EMAIL > > > > > > Seymour > > First let me wish you a good year > > I did schedule the irb in the ikjeft01 TCB against Seymour’s advice for a > return code of zero from schedirb > > However the TMP Estae issued an SDUMP > > I guess it didn’t like me scheduling an irb in its TCB > > Thanks > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > Rocket Software, Inc. and subsidiaries ¦ 77 Fourth Avenue, Waltham MA > 02451 ¦ Main Office Toll Free Number: +1 855.577.4323 > Contact Customer Support: > https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport > Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - > http://www.rocketsoftware.com/manage-your-email-preferences > Privacy Policy - > http://www.rocketsoftware.com/company/legal/privacy-policy > > > This communication and any attachments may contain confidential > information of Rocket Software, Inc. All unauthorized use, disclosure or > distribution is prohibited. If you are not the intended recipient, please > notify Rocket Software immediately and destroy all copies of this > communication. Thank you. > > -- > 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
Re: Why it’s important to take Seymour’s advice
Joe, Once again, can I strongly suggest that you pause your functionality development for a while and invest some time into : (O) A robust general purpose recovery routine that can be used in all modes (prob/sup and TCB/SRB). This routine should focus on grabbing diagnostic information into a structure that your mainline code can understand and also modify its behaviour based on the program that established it. You can design a structure that the establisher passes as a parm on the ESTAE/ARR or FRR. Make it as generic as possible so that you can reuse in other projects. This would include whether to retry , what regs to restore , whether to take SDUMP or TDUMP, whether to issue messages via WTO etc etc (O) A comprehensive internal trace facility that can help you diagnose program flow issues and remove a lot of guesswork when issues arise. Even in its simplest form, adding a footprint into an internal circular memory buffer can greatly enhance your ability to debug. A few days writing IPCS rexx to locate and print out your trace buffer contents could save you weeks of head-scratching down the road. Writing this stuff once and doing a good job on it can gain you years of benefit. Rob Scott Rocket Software. Sent from Outlook for Android<https://aka.ms/AAb9ysg> From: IBM Mainframe Discussion List on behalf of Joseph Reichman Sent: Friday, September 15, 2023 11:16:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Why it’s important to take Seymour’s advice EXTERNAL EMAIL Seymour First let me wish you a good year I did schedule the irb in the ikjeft01 TCB against Seymour’s advice for a return code of zero from schedirb However the TMP Estae issued an SDUMP I guess it didn’t like me scheduling an irb in its TCB Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Rocket Software, Inc. and subsidiaries ¦ 77 Fourth Avenue, Waltham MA 02451 ¦ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Why it’s important to take Seymour’s advice
I would advise going into IPCS and looking at IKJEFT01'S RB chain. If you don't step on anything then the IRB itself won't cause a problem. But it's very easy to inadvertently step on things when you do processing in the IRB. From: IBM Mainframe Discussion List on behalf of Joseph Reichman Sent: Friday, September 15, 2023 6:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Why it’s important to take Seymour’s advice Seymour First let me wish you a good year I did schedule the irb in the ikjeft01 TCB against Seymour’s advice for a return code of zero from schedirb However the TMP Estae issued an SDUMP I guess it didn’t like me scheduling an irb in its TCB Thanks -- 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
Re: Why it’s important to take Seymour’s advice
I guess it didn’t like me scheduling an irb in its TCB I, on the other hand, guess that your IRB abended and that the TMP’s ESTAE got control and did not like that.. Look at the dump and figure out what you did wrong. Put in your own recovery so that you can capture your own diagnostic data and so that you can retry from a problem, in order to avoid adversely affecting the task. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Why it’s important to take Seymour’s advice
Seymour First let me wish you a good year I did schedule the irb in the ikjeft01 TCB against Seymour’s advice for a return code of zero from schedirb However the TMP Estae issued an SDUMP I guess it didn’t like me scheduling an irb in its TCB Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
