The scripting request is in a different (header) parameter block so it is not affected by what is passed for the input string parameter.
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 On Tue, Feb 17, 2026 at 10:14 AM Jonathan Scott < [email protected]> wrote: > You need to think very carefully for yourself about what you are testing. > It appears that you are expecting on entry that the caller's parameters > will either start with the scripting mode prefix or with the legacy length, > which will not match the scripting mode indicator. If the prefix is not > present, your test as suggested below will be looking at 2 bytes before the > caller's parameter area, which is presumably not guaranteed in any way and > could spuriously contain something that looks like the scripting mode > indicator. > > I'm assuming that most of the code wants the parameter base register to > point to the legacy length, in which case there is no guarantee that the > scripting mode flag is valid unless after the initial test you use a > separate indicator to note that the prefix was present. The initial code > will see either the prefix or the length at the same address. You could > for example base the prefix on the register and check whether the request > type indicates scripting mode, and if so set a local flag to note that and > increment the register by the prefix length, then drop the USING for the > prefix. After that, you can establish the USING for the legacy fields > instead. After that use the local flag to determine whether scripting mode > is active before referencing the return code field. The obvious way to > handle this would be to have local work fields for the scripting mode > indicator (by default non-scripting) and return code, and to assign those > back to the prefix if present before returning. > > But it's not entirely clear what you're really trying to do, and it's not > the responsibility of the people on this list to tell you how to do it. > Please do not depend on answers from this list for how to code your > program. You've been given some hints, and you need to work it all out for > yourself using your knowledge of the required function and referring to the > published HLASM documentation as necessary. > > Jonathan Scott > > -----Original Message----- > From: IBM Mainframe Assembler List <[email protected]> On > Behalf Of David Clark > Sent: 17 February 2026 14:46 > To: [email protected] > Subject: Re: [External Sender] Re: Move data to a location prior to a > given (based) address > > Jonathan, > > OK so where I currently have coded the following (where STR_RETN is a > negative offset equate): > > IF TXTREQU,NE,REQU_SCRIPTED IF NOT SCRIPTING MODE > MVI TXTRETN,STR_NFND INITIAL SETTING FOR "NOT FOUND" > ELSE > MVIY STR_RETN,S_STR_NFND INITIAL SETTING FOR "NOT FOUND" > ENDIF > > > Are you saying that I can remove the negative offset equates and just > specify the following? > > IF TXTREQU,NE,REQU_SCRIPTED IF NOT SCRIPTING MODE <== R8 base+0 > MVI TXTRETN,STR_NFND INITIAL SETTING FOR "NOT FOUND" <== R8 base+1 > ELSE > MVIY TXTSRETN,S_STR_NFND INITIAL SETTING FOR "NOT FOUND" <== R10 base-1 > ENDIF > > > 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 > > > On Tue, Feb 17, 2026 at 9:34 AM Jonathan Scott < > [email protected]> wrote: > > > Instructions which use a long displacement, such as CLIY, MVIY and > > LAY, can refer directly to fields which have a negative displacement > > from the base register, in a similar way to your proposed use of > > fields with negative offsets. If you find that the scripting prefix > > is present on entry, you can then save some internal indicator that > > this has been done (or merely use the fact that the base register is > > no longer equal to the pointer from which it was loaded) and adjust > > the base register past the prefix. In either case you can then issue > > a USING for the base register with the start of the legacy string > > parameters (for which I've moved the name TXTINPT below) to process as > > for the legacy case. If you know (from the saved indicator) that the > > scripting parameters are present, you can then reference them directly > > provided that you use long-displacement instructions. So your revised > DSECT would be something like the following. > > > > TXTSINPT DSECT PARAMETERS WITH SCRIPTING PREFIX > > TXTSREQU DS CL1 SCRIPTING REQUEST CODE > > TXTSRETN DS CL1 SCRIPTING RETURN CODE > > TXTINPT DS 0H LEGACY STRING PARAMETERS > > TXTSTRL DS H LEGACY INPUT/OUTPUT STRING LENGTH > > TXTSTRG DS 256CL1 LEGACY INPUT/OUTPUT STRING > > > > Jonathan Scott > > >
