A few comments. 1) Rule number 1: Don't lie to the assembler.
I think that even though you may get it to work, having the possibility of a register pointing to different places in a DSECT is going to cause you grief sooner or later. And certainly will cause grief to the next person who works on the code. Usually you don't change the value of a register that you've used in a USING statement. The typical use case for doing so is when you step through a chain or array of identical data structures mapped by a DSECT. I don't think that's what you are proposing here. 2) I suspect that you are confused on how USING works. In particular, while it's not strictly wrong to have a USING in your DSECT, you should be aware that a USING takes effect at its position in the source module, and ends either at the end or when you issue a matching DROP or another USING that replaces the earlier one. Positioning it as you have suggests that you think that position is somehow related to addressing fields in that DSECT. It's not. 3) There are three kinds of instruction that can effectively use negative displacements. The most straightforward are the "modern" ones that have a 20-bit signed displacement, and are mostly part of the long-displacement facility, and mostly have mnemonics ending in Y. If, in your example, you had R10 pointing to say TXTSSTRG, you could use this kind of instruction to address fields both before and after that field. There are Y versions of many of the classic RX instructions. But note that there are no 20-bit versions of the SS ones like CLC and MVC. These are already 6 byte instructions and there's nowhere to put a larger displacement field, let alone two. Second are the relative instructions that also use a signed displacement to address a field relative to the current instruction address. There is no register involved with resolving the address, so these won't help you in dealing with a DSECT or any fields that don't have an offset from your instructions that isn't known at assembly (or in some cases binder) time. Third are the old original RX instructions such as L and LA. While their addressing arithmetic is unsigned, the effect of specifying a negative number as the displacement produces the same result as signed arithmetic would, and so it is possible to effectively subtract a constant from the sum of base+index+displacement if the index (or base) is negative. Again, I doubt that this technique is going to be useful or easy to write (and read). A negative offset isn't going to work on an MVC instruction, because there is only a base register (or two), and that is needed to point to the data. If an AI suggested this, well... don't pay too much attention. Overall I'm still not sure what you're trying to accomplish here. Can you give a brief example of the two (or more?) kinds of calls to your routine? Tony H. On Tue, 10 Feb 2026 at 17:42, David Clark <[email protected]> wrote: > Let me preface this by saying I'm not really that familiar with newer > instructions. But, I have a 40-year old subroutine that provided 15 string > manipulation functions for COBOL programs. Now I am adding three more (one > of which came up in my previous post). At the same time... > > The previous support was for one function at a time, even though multiple > input strings were supported (i.e., a variable-length parm list; with the > first for a header work area [R8], the second for a large "master" buffer > [R9], and the third for the beginning of one or more "working" > string parameters[R10]; where R11 is the code base register but only needed > for the fixed storage area LOCTR'd to the beginning of the subroutine). > > I would like to add a "mini-scripting" feature that allows one of 16 > different functions to be performed on a string-by-string basis and in a > single CALL. Naturally, this would have to be backward-compatible. To do > this I changed the string DSECT to have a "redefined" layout--as follows: > > TXTINPT DSECT > USING TXTINPT,R10 ESTABLISH REG 10 AS BASE > TXTSREQU DS CL1 SCRIPTING REQUEST CODE > TXTSRETN DS CL1 SCRIPTING RETURN CODE > TXTSSTRL DS H SCRIPTING INPUT/OUTPUT STRING LENGTH > TXTSSTRG DS 256CL1 SCRIPTING INPUT/OUTPUT STRING > ORG TXTINPT > TXTSTRL DS H LEGACY INPUT/OUTPUT STRING LENGTH > TXTSTRG DS 256CL1 LEGACY INPUT/OUTPUT STRING > > So as not to have to duplicate *all* of the code, I figured I would just > save off the first two bytes and then increment R10 by 2 such that the last > two fields would work for both modes (and the last two fields are the ones > that are referenced by the remainder of the subroutine). > > That is fine, but when I want to save the return code for the current > string and function, I initially coded it this way (I presume it is OK to > use regular arithmetic on an address)--and then continue on with whatever > else needs to be done next. > > IF TXTREQU,EQ,C'S' IF IN SCRIPTING MODE > SHI R10,2 POINT TO SCRIPTING PARM AREA > MVC TXTSRETN,HOLDRETN SAVE STRING RETURN CODE > AHI R10,2 POINT TO LEGACY LENGTH AND STRING > ENDIF ENDIF > > But then I had a thought... Is there any instruction that will let you > move (and examine) data to/in a location prior to a given address? Now, I > saw where an AI generated a sample MVC instruction that used a negative > displacement, but I didn't know if that was legitimate? Recommendations? > > Sincerely, > > Dave Clark > -- > int.ext: 91078 > direct: (937) 531-6378 > home: (937) 751-3300 > > Winsupply Group Services > 3110 Kettering Boulevard > Dayton, Ohio 45439 USA > (937) 294-5331 >
