Thanks for all of the suggestions! Of course, one fundamental question that the discussion has prompted in my mind is: Why does the data for a CDS need to be on a doubleword anyway? The data is read from or loaded into the low order 32 bits of two consecutive registers. As such, it seems that the data is really two consecutive fullwords, not a doubleword.
Using STGHEAD-STGPOOL(R5) is a good idea unless and until I need to change base registers, in which case, I have to remember to change the instruction. Better, but not ideal IMO. To answer the (first) original question, I guess HLASM doesn't "look" at hardcoded offsets, just generated base/offset (S-con). I am still not sure whether the actual data MUST be on a true doubleword boundary or if it would work on a fullword boundary. Guess it's time for an experiment. Thanks again, Mark Hammack Senior Technical Specialist Systemware, Inc. On Tue, Aug 17, 2010 at 1:27 PM, Schwarz, Barry A < [email protected]> wrote: > 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). >
