On 2016-12-20, at 17:19, Webster, Chris wrote: > What is your initial using for r13? Is DLTABLE part of that dsect? > That shouldn't matter for a dependent USING which is supposed to map one DSECT over part of another DSECT.
There's some Bad History here. Warnings for overlapping USINGs and multiple resolution were provided before long displacements (over which HLASM had no control) and dependent usings (over which HLASM had complete control.) > -----Original Message----- > From: Steve Smith > Sent: December-20-16 10:15 AM > > Well, I found a work-around: > > * USING DLTABD,DLTABLE This fails w/ASMA307E > USING DLTABD-4000,DLTABLE-4000 Trick to fool HLASM > In fact, I recall by experiment that the second offset can be absurdly large, anything within 32-bit range, well beyond any currently supported displacement (that I know of). If I had a dog in this fight, and I had raised it from a puppy before dependent USINGs and long displacements, I'd change the rule so that warnings and errors were never reported at the USING instruction, not even one that's documented but not (IIRC) reported. I would report multiple resolutions (and, of course unresolvables) at the point at which they occur. One day I might submit an SR on a case in which a base and displacement are resolved which are algebraically wrong in AMODE 64. I believe an overflow during resolution is not reported. The restriction of assembly-time arithmetic does not excuse generating code which is clearly incorrect in AMODE 64 and questionable in AMODE 31 or 24. -- gil
