Ha, I expected Jonathan Scott would explain the complications... I forgot to mention, there should also be a DS 0F just before the FTOECLR DS 0CL(FTOECLRL) to ensure it lands in the right place.
sas On Thu, Aug 18, 2022 at 9:58 AM Jonathan Scott <[email protected]> wrote: > The DS 0CL cannot be resolved in the first pass, because the > length is a forward reference, and that creates a location > counter break at that point, so the alignment after it is > unknown and padding bytes might be needed at any point where a > more aligned field follows a weaker alignment. > > (In this case, as the duplication factor is zero, a person can > tell that this would not affect the location counter, but as the > whole DC gets deferred as "unresolved" this causes a break. We > have investigated the possibility of an enhancement to allow a > DC statement to be "partially resolved" to improve handling of > similar cases, but this would be very difficult to implement.) > > This means that if the first field does not have the strongest > alignment, the length cannot be resolved until the alignment > before that field is known, but the DS 0CL cannot be resolved > until the length is known, so the statement cannot be resolved. > > João writes: > > 000020 32923+FTOECLR DS 0CL(FTOECLRL) > > ** ASMA080E Statement is unresolvable > ... > > When I put FTOAASCB (a fullword) in the front, it works fine. > > > > When I put FTOMTLN (a halfword) in the front, is doesn’t work. > > Jonathan Scott, HLASM > IBM Hursley, UK >
