If you expect STGHEAD to always be double word aligned and R5 to always contain
the address of an odd word, you need a way to inform the assembler you are
violating conventional alignment. One possible method is
STGXXX DSECT
DS F
STGPOOL DS 0X
STGSIZE DS F
STGHEAD DS A
...
which has the advantage of not requiring any changes to your USING statements.
All of which begs the question of why STGHEAD is DS A and not DS D. Or at
least preceded by a DS 0D.
If updating the DSECT is impractical at this time, you can still eliminate the
hardcoded offset by using STGHEAD-STGPOOL in place of 4. Your code will be
self adjusting if the DSECT ever does change.
-----Original Message-----
From: IBM Mainframe Assembler List [mailto:[email protected]] On
Behalf Of Mark Hammack
Sent: Tuesday, August 17, 2010 7:33 AM
To: [email protected]
Subject: Re: CDS and alignment question
Yes, STGHEAD is in a DSECT:
STGPOOL DSECT
STGSIZE DS F
STGHEAD DS A
STGCNT DS F
STGERR DS F
As I said in the original e-mail, the "easy" thing to do would be to
rearrange the dsect so that STGHEAD is on a doubleword boundary (i.e. move
STGERR before STGHEAD and add DS 0D before the actual data). However,
finding all of the procedures that rely on this particular layout may be
difficult. But I will be changing it in a future release of the software.
My other option is to 'go back' to hardcoded offsets (i.e. 4(R5) ) since
HLASM doesn't complain about that) and document why things are done the way
they are (forcing the pool definition to a 'doubleword+4' boundary so that
STGHEAD is on a doubleword for example which was another interesting
exercise and exactly what 4(R5) is).
