On 2014-10-03, at 08:34, Ed Jaffe wrote: > On 10/3/2014 6:22 AM, Robert A. Rosenberg wrote: >> I can see how the displacement between CSECTS can be computed by the >> Assembler but this displacement can be wrong once the object deck is >> link-edited/bound since the order of the CSECTS are not fixed. Unless the >> LARL references RLDs (and thus adjusts for the location in the program >> object or load module (as occurs with ACONS) any reference in one CSECT to a >> location in another CSECT can be wrong. > (I would have clarified with "[paired] RLDs".)
> Cross-CSECT relative addressing, adjusted as needed across module rebind, has > been supported since z/OS 1.8. > Would the programmer be well-advised to use Binder ORDER commands lest SMP/E service reorder CSECTs and move a target out of relative addressing range? On 2014-10-02, at 22:13, Steve Smith wrote: > Your colleague may have been time-traveling... it's not an old assembler, > it's the new one that allows addressing across CSECTs, with relative > addressing. So, while LA R1,Field would generate the address in your dynamic > copy, a LARL R1,Field would still address it the original CSECT. > But I would hope that with the labelled USINGs suggested earlier LARL R1,M.Field would result in an unresolvable displacement error. Otherwise, too uncomfortably much DWIM. At worst, LA R1,Field and LARL R1,Field might both succeed, with no messages, but load different addresses. No, it would have been I time-traveling. The discussion occurred far before the advent of relative addressing or HLASM. IEV90 was so new that we couldn't make it a prerequisite for customers. IIRC, I tested with IFOX00 and couldh't reprouce the assertion. > Seems logically somewhat inconsistent, but it could also be useful, I suppose. > Inconsistent only insofar as it applies only to relative addressing. The same technique could as well be applied to base-displacement. (But is relocation of 12-bit operands supported?) -- gil
