IBM Mainframe Forum

by **bobguo** » Wed Nov 14, 2012 1:13 pm

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.

by **BillyBoyo** » Wed Nov 14, 2012 1:27 pm

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.

by **steve-myers** » Wed Nov 14, 2012 7:41 pm

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

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 -

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.

by **bobguo** » Sun Nov 18, 2012 6:13 pm

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.

by **steve-myers** » Sun Nov 18, 2012 9:56 pm

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.

by **bobguo** » Mon Nov 19, 2012 9:35 am

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.

by **steve-myers** » Mon Nov 19, 2012 7:39 pm

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.

by **bobguo** » Tue Nov 20, 2012 10:03 am

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.

by **steve-myers** » Tue Nov 20, 2012 10:08 am

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

by **bobguo** » Tue Nov 20, 2012 11:14 am

"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?

IBM Mainframe Forum

what's the mean of HSA LSA WD1?

what's the mean of HSA LSA WD1?

Re: what's the mean of HSA LSA WD1?

Re: what's the mean of HSA LSA WD1?

Re: what's the mean of HSA LSA WD1?

Re: what's the mean of HSA LSA WD1?

Re: what's the mean of HSA LSA WD1?

Re: what's the mean of HSA LSA WD1?

Re: what's the mean of HSA LSA WD1?

Re: what's the mean of HSA LSA WD1?

Re: what's the mean of HSA LSA WD1?