You might want to create, e.g., a dump, a logrec record, a trace record.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Binyamin Dissen <[email protected]> Sent: Wednesday, October 10, 2018 4:47 AM To: [email protected] Subject: Re: Cross-memory POST ERRET and return codes On Mon, 8 Oct 2018 15:40:40 -0700 Charles Mills <[email protected]> wrote: :>Pursuant to a recent thread here I am converting a cross-memory POST to use :>IEAMSXMP instead. However ... I still need to support older systems without :>IEAMSXMP support, so I will be dual-pathing the existing POST. I got to :>looking at code that I have not examined in several years, and I am trying :>to determine exactly what is or should be going on. It runs without apparent :>errors, so this is kind of a theoretical question, not "please help me with :>this error." Here's the POST :>POST (R3),LINKAGE=BRANCH,ASCB=(R2),ERRET=POSTERR,MEMREL=NO :>The questions are these :>- Given that code, will POSTERR indeed get control on an error? :>- The POST documentation documents two error codes, 4 and 8. Will they get :>passed to POSTERR? Where? :>Yes, I have RTFM but the FM is showing the effects of years of somewhat :>piecemeal revisions. I have never truly coded a post error routine (always use CVTBRET). Consider what must be done if a POST failed, which requires determining the reasons why the POST failed. In the vast majority of cases I would be running primary=target and will attempt a quick post first. 1. The target memory terminated Nothing to do. The RESMGR routines will clean it up. 2. The address is invalid or in the wrong key The quickpost will catch it. Also, one must consider the case which posterr will not catch, that is the storage is reallocated. Either way, the issues remains - what will you do if the post fails? -- Binyamin Dissen <[email protected]> http://secure-web.cisco.com/12ynt5-AyJzto-9-K3Ok8ZRBGSnzPTp-BL4luptrhxENqlBFwW8G7Pit_KsZ7yKArf6mPnT9EKxi33eq2HHMBgMnWMW5nxN7QmjSdoxDsaiVv443xXIDdhUp3_hYYZLpQMqn6e37TD2dq_zxS8HnnSYaJs5GLVlm6gYwzlaR5OdI1Gd6KSiN2xt6uhqHADhgIXzSgMNhi_edNo4bX2VPvSyJfMnjb3MBYJyPpKsvSqSfTtpf5Zw42MRfiQoe5mmcKRBzewDbFey-vkghZcykQRC7yf2JCX99dsTRbycHMnvZhnfmkguS_c7dokeDFJi_AT4HaP1XylfDmljb_Z9zIv-kFpTs7oXQDMoEmr4rNJj_xFW1orHCdKsBYkFp3fFw8YXjyxN7czYexe_pmKaJJVHIf-oyNn18rcm8Xt-bOhd7pBApUv5SjEJohxfJWiLUR/http%3A%2F%2Fwww.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. ---------------------------------------------------------------------- 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
