what's the mean of HSA LSA WD1?

[bobguo]

Code: Select all

SA   0002BDC0  WD1 00001001   HSA 00029228   LSA 0002BEC0   RET 9432145E  EPA 942F7B70   R0  0002BFB8
               R1  157078C8   R2  00029AD8   R3  00000001   R4  157078C8  R5  00019588   R6  0001C7FC   
               R7  14321FFF   R8  0001CA80   R9  00000004   R10 0DA8B2EC  R11 94321000   R12 0001AA50


SA   00029228  WD1 0808CEE1   HSA 000089A4   LSA 0002BDC0   RET 8DA8A428  EPA 0DA961B0   R0  00000000
               R1  00029644   R2  0002966C   R3  00000004   R4  00000000  R5  00000718   R6  15707888
               R7  00000010   R8  8DA8A2E8   R9  0002A227   R10 0DA8B2EC  R11 0DA86AA0   R12 0001AA50

I saw it in the dump, but i don't know what's the mean and does it helpful when locate errors.
can somebody explain it or give me one link to reference.
thanks in advance.

[BillyBoyo]

Try googling for sa wd1 hsa lsa.

Don't chop off the heading when posting stuff here. Note that the stuff is very useful, although you'd not need all of it all the time, but it is too "involved" to explain it all on a forum.

See where you get with google, and ask further if you don't understand.

[steve-myers]

The dump is showing a trace of the save areas. A "standard" 72 byte save area is described by this DSECT -

Code: Select all

SAVEAREA DSECT ,  72 BYTE OS/360 SAVE AREA
SAVEWD1  DS    A  RESERVED
SAVEHSA  DS    A  ADDRESS OF PREVIOUS SAVE AREA
SAVELSA  DS    A  ADDRESS OF LOWER SAVE AREA
SAVER14  DS    A  CALLER'S REG 14
SAVER15  DS    A  CALLER'S REG 15
SAVER0   DS    A  CALLER'S REG 0
SAVER1   DS    A  CALLER'S REG 1
SAVER2   DS    A  CALLER'S REG 2
SAVER3   DS    A  CALLER'S REG 3
SAVER4   DS    A  CALLER'S REG 4
SAVER5   DS    A  CALLER'S REG 5
SAVER6   DS    A  CALLER'S REG 6
SAVER7   DS    A  CALLER'S REG 7
SAVER8   DS    A  CALLER'S REG 8
SAVER9   DS    A  CALLER'S REG 9
SAVER10  DS    A  CALLER'S REG 10
SAVER11  DS    A  CALLER'S REG 11
SAVER12  DS    A  CALLER'S REG 12

Save areas are useful in debugging as you can trace the path of program calls to arrive at the point of error - assuming, of course, that everyone in the path is doing the entire convention, which many people don't do. This is an example -

Code: Select all

APGM     CSECT
         USING *,12                ESTABLISH PROGRAM ADDRESSABILITY
OLDSAVE  USING SAVEAREA,13         CALLER'S SAVE AREA
NEWSAVE  USING SAVEAREA,15         NEW SAVE AREA
         SAVE  (14,12),,*          SAVE REGISTERS
         LR    12,15               COPY ENTRY POINT ADDR TO REG 12
         LA    15,NEWSAVEAREA      LOAD ADDRESS OF THE NEW SAVE AREA
         ST    15,OLDSAVE.SAVELSA  ADD NEW SAVE AREA TO THE
         ST    13,NEWSAVE.SAVEHSA   SAVE AREA CHAIN
         LR    13,15               ESTABLISH NEW SAVE AREA POINTER
         DROP  OLDSAVE,NEWSAVE     KILL SAVE AREA ADDRESSABILITY
*        ...
*        CALL  ANOTHER_PROGRAM
*        ...
         USING SAVEAREA,13         ESTASBLISH SAVE AREA ADDRESSABILITY
         L     13,SAVEHSA          LOAD ADDR OF CALLER'S SAVE AREA
         RETURN (14,12),RC=0       RESTORE REGISTERS & RETURN
         DROP  12,13               KILL ADDRESSABILITY
NEWSAVEAREA DC 18F'0'
         END


Many beginners don't bother with

ST 15,OLDSAVE.SAVELSA

either because they don't understand it is required for the dump program to properly trace the save area chain, they arrogantly believe, "my programs will never have an error," or they are just too lazy.

[bobguo]

thanks very much for you reply.
but right now i have a new question why SA(0002BDC0) is so small while EPA(142F7B70) is so large?

in my opinion, one program's SA should be next to the address of its process and normal varibles...

can i guess that SA isolates from the memory that one program(its process and local variables) takes. right? thanks again.

[steve-myers]

The save area can, and often is, located in completely different locations. In your example, the program at 142F7B70 is most likely a reenterable program loaded above the line, and its work area, including a save area, is allocated below the line. This is actually quite common since some data areas, such as DCBs, must be located below the line. A TSO command I've been playing with since sometime last month follows this pattern.

[bobguo]

thx in advance!

how to identify one program is reenterable or not? in other words, if i read one HLASM program, which keywords can tell me it's reenterable. besides, can someboby explain 'reuseable program' and what's the difference between them? i have referred to ibm red book about it, but...
thanks.

[steve-myers]

There are no keywords as such. Look for these indications, though they are not exhaustive -

• Program sections defined using RSECT. This causes the Assembler to look for obvious attempts to modify the code and data areas, but the Assembler can be easily fooled. In addition, other program sections in the assembly may not be defined as RSECTs. Some programmers - I've been doing this in the last year - carefully isolate the program into an RSECT and the data into a CSECT. I started doing this for addressability reasons; I happened the declare the code as reenterable because, in fact, it was reenterable, and the data area included data that is altered during execution.
• Assembler invoked using the RENT option. This causes the Assembler to look for obvious attempts to modify the code and data areas, but the Assembler can be easily fooled.
• Programmer comments declaring the program is reenterable. The comments might well be a lie.
• Even if the previous 3 bullets are true and correct, the program could well be linked with other modules that are not reenterable. This makes the entire load module not reenterable.
• The load module is marked by the Binder or Linkage Editor as reenterable, based on a programmer specified option. Until z/OS V1R10, reenterable modules in STEPLIB or JOBLIB data sets that are not also authorized data sets were loaded into storage that was not also protected for update. In other words, there was no formal way for a programmer to verify the load module was, in fact, reenterable. Sometime around 1980 this bit me in a very tender area. I had a module I thought was reenterable. When it was put in production in an authorized library, it turned out it was not reenterable. Oops. In z/OS 1.10, IBM defined a system option to load all reenterable load modules into protected storage, and there was a corresponding undocumented feature in z/OS 1.9 that had the same effect.

In any event, in your example, the program was definitely above the line, but it was not necessarily reenterable. It just allocated below the line storage that happened to include the save area.

[bobguo]

thanks steve, i think i have to take some more time to understand what you said.

i am sorry, i have one more question: what's the purpose of LSA? in my opinion, HSA is enough during linkage between programs.

[steve-myers]

I suggest you reread all of the posts in this thread. Your question will be answered if you do.

[bobguo]

"Many beginners don't bother with

ST 15,OLDSAVE.SAVELSA

either because they don't understand it is required for the dump program to properly trace the save area chain, they arrogantly believe, "my programs will never have an error," or they are just too lazy."

Yes, these sentences i have noticed, but i still puzzled about this quesiton:
1. current save area's address, we can find it, and it was stored in R13.
2. If want to get father program's save area, we can get HSA by issuing 'L R4,4(R13)'
so i think we can trace the save area chain without LSA, right?