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