There are service to get the load address. Getting the csect address is harder.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ________________________________________ From: IBM Mainframe Discussion List on behalf of Bernd Oppolzer Sent: Tuesday, May 6, 2025 2:25 AM To: [email protected] Subject: Re: Detecting the call chain of 3GL programs from main to current External Message: Use Caution BTW: there are two sorts of offsets: EPA offsets, which relate to the entry point. These offsets are easily computed by subtracting the return address (or in case of the current function, the PSW address) from the EPA of the function, retrieved from the save area one level higher. LPA offsets, which relate to the load point of the module. To compute these offsets, you have to check what module the given return address or PSW address falls into (by examining the CDE/XTLST queue). If you find the module, you can subtract the load point (in XTLST) from the given address. Unfortunately, it is not clear, if a given offset, reported by a dump tool, is an EPA offset or an LPA offset. That's why I report (in my tool) both offsets, and write something like this (in German): Offset from load point: xxxxxxxx - Module Name (8 characters) Offset from Entry Point: xxxxxxxx - Entry Point Name (may be longer) In PL/1, for example, you will see the name of the Program Unit in the first line and the name of the PL/1 procedure in the second line. Same for C etc. In ASSEMBLER, you see the name of the Load Module in the first line, and the EP eyecatcher at the EPA position (if there is a eyecatcher, length at EPA + 4 and text from EPA + 5 - which all our homegrown ASSEMBLER modules do, because of a standard startup macro). Kind regards Bernd Am 06.05.2025 um 08:08 schrieb Bernd Oppolzer: > I show both; the addresses as derived from the save areas and the > (computed) offsets. > > Certain LE routines store the return addresses at a different place in > the DSA (not at the place of register 14); > offset X'6E', IIRC. Knowing this, I can compute correct offsets in > this case, too. > > There are some other hidden pitfalls; our homegrown ASSEMBLER routines > add one to the return address > in the save area, if it has been used, that is, if the return did > already occur. Such save areas are of minor interest, > because they are below the current save area. Anyway this information > is interesting and has to be handled > and probably reported ... > > The whole system is part of an IMS and batch framework, which has its > origin in the early 1970s and runs until > today, and it is full of clever ideas. I work for this client (with > some breaks) since 1988. > > The end of this system is scheduled for end 2027. But I don't yet > believe this gonna happen. It was already scheduled > for 2009 the first time :-) > > Kind regards > > Bernd > > > Am 06.05.2025 um 03:28 schrieb Seymour J Metz: >> Do you convert the return and entry point addresses to offsets? >> >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> עַם יִשְׂרָאֵל חַי >> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר >> >> >> >> ________________________________________ >> From: IBM Mainframe Discussion List on behalf of Bernd Oppolzer >> Sent: Monday, May 5, 2025 10:02 AM >> To: [email protected] >> Subject: Re: Detecting the call chain of 3GL programs from main to >> current >> >> >> External Message: Use Caution >> >> >> no, there is no such table. >> >> Others have already commented most interesting parts of this topic. I >> would like to add my personal experience: >> >> I had to write a dump analysis tool for a customer of mine which is >> acitivated at the time of the error and should >> produce a readable dump in (most of) all circumstances. I did the >> following: >> >> first I tried to walk back from the current DSA (from register 13) to >> TCBFSA (first save area, recorded in the TCB). >> If this works, you have the whole chain and all is good. If not, the >> chain is corrupt at some place, which is usually >> an error in an non-XPLINK environment. I then try to go forward from >> TCBFSA, which usually does not lead us far, >> because LE and some of the languages (like PL/1) don't fill the forward >> pointers. But: if the first levels are >> (in our case) homegrown ASSEMBLER programs, we may have luck. At every >> step, I check, if the new found save area is, >> by any chance, already present in the previous chain found by stepping >> backward. If so, I match the two parts, >> and again, all is good. >> >> Before accessing a "spurious" pointer, I check the address, if it is >> valid, using VSMLOC (IIRC). >> >> If I cannot produce the complete chain, I report the parts, at least. >> >> For every entry point found in the chain, I report the name of the >> function or procedure, and, if possible, >> the language and the compiler. We have an environment where there are >> many modules written in ASSEMBLER, PL/1 and C, >> calling each other dynamically,. I also show entry points adresses, >> return adresses (of course), resulting offsets, >> parameter lists, and DSA areas. If I know the size of the DSAs (in PL/1 >> and C, for example), I show the complete DSA, >> otherwise 8k. >> >> This error reporting feature (for IMS dialog, batch, TSO etc. ... >> everywhere the same layout) is in production use >> since 2005, and the users (that is: developers) are happily using it. >> Before that, we had different sorts of dump >> layouts, depending on environment and programming language, which was >> cumbersome for the users. >> >> Kind regards >> >> Bernd >> >> >> Am 04.05.2025 um 15:02 schrieb Steff Gladstone: >>> Is there some table (or data in some other form) in memory (maintained >>> perhaps by Language Environment) that details the current calling >>> chain of >>> 3GL or assembler programs starting with the main program and running >>> down >>> the chain to the current executing program? If so, how would I >>> navigate >>> to it? (Or is there a callable routine that provides the information?) >>> >>> I tried to produce such a chain by following the savearea chain from >>> the >>> current program up the calling hierarchy, but at some point in the >>> hierarchy I receive a spurious pointer to the next higher program's >>> savearea. >>> >>> Thank you for any assistance or pointers (double entendre) you can >>> provide. >>> >>> All the best, >>> Steff Gladstone >>> >>> ---------------------------------------------------------------------- >>> 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 >> >> >> >> >> ---------------------------------------------------------------------- >> 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 ---------------------------------------------------------------------- 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
