>> But I am still re-basing the passed parameter address--but this time in all cases.
Sorry, that is incorrect. I am only re-basing if in scripting mode. Oops. ;-) Sincerely, Dave Clark On Tue, Feb 17, 2026 at 11:43 AM David Clark <[email protected]> wrote: > Jonathan, > > Thank you. The following is now working without using negative offset > equates. Also learned something new about the capabilities of CLIY/MVIY. > > 00078C EBD7 AFFE FF55 00000 1295+ CLIY TXTSREQU,C'P' > 000792 A774 000E 007AE 1296+ JNE ELSE0010 > ...snip... > 0007A4 EBC2 AFFF FF52 00001 1308 MVIY TXTSRETN,INV_BUFL > 0007AA A7F4 0542 0122E 1309 J SCRIPTXT > > And this is the data structure--as you laid it out. > > TXTSINPT DSECT SCRIPTING INPUT STRING PARAMETER > TXTSREQU DS CL1 SCRIPTING REQUEST CODE > TXTSRETN DS CL1 SCRIPTING RETURN CODE > TXTINPT DS 0H LEGACY INPUT STRING PARAMETER > TXTSTRL DS H LEGACY INPUT/OUTPUT STRING LENGTH > TXTSTRG DS 256CL1 LEGACY INPUT/OUTPUT STRING > > This is the USING for this 3rd parameter and all those that may follow. > > JAS R2,GETSTRG GET (NEXT) STRING PARAMETER ADDRESS > USING TXTINPT,R10 ESTABLISH REG 10 AS BASE > > But I am still re-basing the passed parameter address--but this time in > all cases. When, in scripting mode, I need access to TXTSREQU or TXTSRETN > then I just use CLIY/MVIY and I get what I want. Note that scripting mode > is determined by the following R8-based DSECT. > > TXTPARM DSECT HEADER PARAMETER > TXTREQU DS CL1 OVER-ALL REQUEST CODE > > TXTRETN DS CL1 OVER-ALL RETURN CODE > > TXTPNTR DS H BUFFER POINTER > TXTDLMS DS CL8 PARSE DELIMITERS > RESERVED DS CL260 (INTERNAL USE ONLY) > > > Sincerely, > Dave Clark > > > 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 >> >> >>
