I would have expected the alignment warning to occur on the DC LQ itself. Seems to me I've seen that before. And I'd expect any resolution problem with AIALENGTH to be reported where it's defined.
sas On Tue, Dec 29, 2015 at 9:49 AM, Paul Gilmartin < [email protected]> wrote: > On 2015-12-29, at 06:59, Peter Relson wrote: > > > FWIW, > > > > Adding at the beginning of the module > > *PROCESS SECTALGN(16) > > > > makes this work. I always think of needing SECTALGN(16) when there's a > > quadword-aligned item (the default for a DSECT is doubleword aligned). I > > don't know if my thought is fully correct. > > > > Of course "Statement is unresolvable" is not a good diagnostic if that is > > the situation. > > > Oh, this is tricky. If you're envisioning a new diagnostic to be issued > whenever the alignment requirement of any component exceeds the required > alignment of the section, Ed's two examples show the detection is > inconsistent: > > On 2015-12-28, at 17:44, Ed Jaffe wrote: > > > Check this out... > > > > Try to assemble the following test program. Attempts to use AIALENTH as > a duplication factor fail with 'ASMA080E Statement is unresolvable' while > BIALENTH works just fine. Why? > > > > AIADSECT DSECT , > > AIAVRS DS 0CL512 > > DS 32LQ > > AIALENTH EQU *-AIADSECT > > > > BIADSECT DSECT , > > BIAVRS DS 0CL512 > > DS 32XL16 > > BIALENTH EQU *-BIADSECT > > > > TEST CSECT > > DC (AIALENTH)X'00' > > DC (BIALENTH)X'00' > > DC (AIALENTH)X'00' > > DC (BIALENTH)X'00' > > END > > -- gil > -- sas
