If the assembler programs are written to be LE conforming (e.g. CEEENTRY
macro) then finding the Stack frame size is the same as any other LE
conforming language. LE CEEENTRY macro generates the Standard entry
code statements which contains the Stack frame size and the pointer to
the PPA1 control block. One would think that this is a big miss for
IBM. How long has LE been available, something close to 30 years.
Nobody in that 30 years has complained that the CEEDUMP does not print
the Stack frame storage for an LE conforming assembler program. Pretty
remarkable. IBM established the standards for LE environments they
should be handling the printing of the Stack frame storage in CEEDUMP
just like they do for every other language. If they are forcing that on
the language groups then they should have made the same request to the
HLASM group. And it should not have taken 30 years.
On 12/4/2021 11:00 PM, ASSEMBLER-LIST automatic digest system wrote:
There is 1 message totaling 83 lines in this issue.
Topics of the day:
1. CEEDUMP does not print LE conforming assembler LE Stack frame storage
----------------------------------------------------------------------
Date: Sat, 4 Dec 2021 09:48:55 +0100
From: Bernd Oppolzer <bernd.oppol...@t-online.de>
Subject: Re: CEEDUMP does not print LE conforming assembler LE Stack frame
storage
When I wrote a routine for a customer of mine
which writes all the stack frames at the time of ABEND
(top to bottom with respect to call hierarchy)
- which was meant as a replacement for CEEDUMP, just because the
customer has a mix of C, PL/1 and homegrown ASSEMBLER routines,
which DON'T follow LE's conventions -
I soon realized that the problem here is that I know (or: can find out)
the LENGTH of the stack frame areas for C and PL/1 modules -
it is stored somewhere near the entry point address.
But I cannot find out the same information for the ASSEMBLER routines,
although many of them use the same mechanism (allocate a - sort of - DSA,
address it by reg 13 and chain it to the SA chain, much the same way as
LE does it).
So I ended up printing only 8 k from the starting point of the DSA area
for ASSEMBLER modules, as long as the area lies within accessible storage
(controlled by VSMLOC). This helps much, because most of the customer's
ASSEMBLER routines store their automatic data there, and 8 k (2 base regs)
is enough most of the time.
Furthermore, the routine prints 4 k storage from every address which is
in the general registers at the time of ABEND. This is also very helpful
in most cases.
Sometimes (but not often) it is necessary to check the SYSUDUMP which
is written after this - so called - "short dump" to examine additional
storage
areas.
This routine was written in 2005 and is in production use at a large
global company until today. The routine does the same dump editing,
no matter if the environment is Batch, IMS/DC or TSO.
With respect to another current thread: I use the backward SA chain and
then (in a first step) I try to re-construct the forward chain, which is
often corrupted.
If the backward SA chain does not go back all the way to TCBFSA (first
save area),
I try to use the forward chain starting from TCBFSA and try to fix the
problem.
If this does not work, I write the two parts of the chain and tell the user
about the gap.
HTH, kind regards
Bernd
P.S.: if you want to know more, feel free to send me an offline note.
Am 03.12.2021 um 18:33 schrieb Larry Slaten:
I just created IBM RFE 153397 to fix the CEEDUMP process. It does not
currently print the LE Stack frame storage of LE conforming assembler
programs in the Traceback list. I would appreciate all of your
votes. After going through the process of creating an RFE, maybe I
understand why this has not already been requested. I am sure that I
am not the only programmer that has coded an LE conforming assembler
program. From my chats with IBM and the Debugging Guide, it appears
that printing the LE Stack frame storage is a language responsibility
and not an LE responsibility. Personally I believe that an
unformatted dump of the LE Stack frame storage could be left in the
hands of LE and any storage formatting could be directed to the HLLs.
We all know that assembler does not store and keep track of options,
releases, special control blocks etc., unlike COBOL, C/C++. and PL/I.
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=153397
------------------------------
End of ASSEMBLER-LIST Digest - 3 Dec 2021 to 4 Dec 2021 (#2021-55)
******************************************************************
