Joseph, Programs executing in AMODE(31) can and often do store critical data in the high halves of registers, so I would always display the full 64-bit registers, and not make it a function of AMODE.
Tom Harper Phoenix Software International Sent from my iPhone > On Jan 23, 2024, at 8:03 AM, Joseph Reichman <reichman...@gmail.com> wrote: > > I had two main objectives in updating file 192 > > First in amode 64 display 64 gpr > > Second when a abend occurs in a IBM service > > Be it PC or SVC > > Report on where in the user program this occurred > > For SVC this would be in the RB > > For PC ( which are normally space switching as well as stacking ) > > In the linkage stack > > Sdwaec2 doesn’t have 64 bit gpr but they exist in the linkage stack > > Thanks > >>> On Jan 23, 2024, at 2:31 AM, Jon Perryman <jperr...@pacbell.net> wrote: >>> >>> On Thu, 18 Jan 2024 05:08:17 +0000, Peter Relson <rel...@us.ibm.com> wrote: >>> >>> <snip> >>> I chain backward as its the only way to do it wrapping around tcbrbp and >>> next rb had the registers in the prefix it had SVC 12 maybe SVC 42 issued >>> that >>> </snip> >>> >>> "Wrapping around tcbrbp" is a strange way to do much of anything. >> >> Hi Peter, >> >> Joseph is updating the abend recovery provided on the CBT available for >> public consumption. IBM abend does not always display abend module with >> offset. He is going to great lengths to obtain this information when not >> provided or when SDWAEC2 is different from SDWAEC1. >> >> I doubt that any vendor would do this because of possible risks. Having >> worked on critical software, the benefit never justified the risk of >> crippling a customer's system. >> >> I only mention this because you may have some tips for him. For instance, >> Wrapping around TCBRBP is his method for locating the module. Are there >> situations where the overhead could be problematic or worse yet a true >> multi-active task environment encountering problems such as an RB being >> removed. UNIX, CICS and OEM products. >> >> ---------------------------------------------------------------------- >> 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 -------------------------------------------------------------------------------- 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
