Hi John,

Thanks for your comments. They're helpful.



My actual case is similar to your example, but is not quite the same. Below is a snippet from the listing.

I am using DXDs to record the length of a csect. It occurs at the end of the assembly, and it assigns a duplication factor to a DXD X that is equal to the length of the csect.

All my assemblies end with a similar DXD, but their names are all different.

Then later, the Binder will accumulate all the DXDs into an external dummy whose length will match the load module's length. Then the Binder will stash that length into a CXD.




Here is the snippet from an assembly listing...

 00003CB0                                   93657+ENDCMDS  DS    0D,F
93658+DXDCMDS DXD (ENDCMDS+8-TFSCMDS)X
 ** ASMA500W Requested alignment exceeds section alignment
 ** ASMA435I Record 87 in CSW.Z22.PUBLISHD(@CSECTZ) on volume: CSW00M
00003CB4 00000000 93659+ DC Q(DXDCMDS) REQUIRED REFERENCE
                                            93661          END   , SRCCMDS



You will note that while the DXD does not reference any forward defined variable, its dup factor nonetheless resolves to a value derived from a forward address.

The peculiar thing is, while every single one of my 200+ assemblies ends with similar logic, only fourteen report the ASMA500W warning.

I hope this sheds additional light on this bug of yours.



I will raise a support case.
Dave Cole
President, ColeSoft
dbc...@gmail.com (personal)
dbc...@colesoft.com (business)
540-456-6518 (cell)





At 4/20/2022 05:59 AM, you wrote:
Dave Cole, please raise a support case for this.

APAR PH40885 exposed a bug when the duplication factor on a DXD
involves a forward reference, for example:

DXD1     DXD   (A)X
A        EQU   3

The problem is that if a DXD definition has to be deferred
because it cannot be resolved immediately, the field which would
normally point to the owning section (itself) is used instead to
point to some information about the deferred definition, to be
resolved after the end of the first pass.

In the second pass, when the alignment is supposed to be checked
against the alignment of the owning section, it ends up being
checked against the deferred definition instead, in which the
field corresponding to the alignment is unused, equal to zero,
causing the warning.

The good news is that this doesn't affect the object code output.

Jonathan Scott, HLASM
IBM Hursley, UK

Reply via email to