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
>
>
>
