I am going to be more prescriptive than @Jonathan. (Fools rush in ...)
THE RIGHT WAY to accomplish what you are trying to accomplish is a new
entry point name for your new expanded functionality -- NOT creating a
maintenance and debugging nightmare by trying to write assembler code
that guesses at the parameter format.
Factor out your existing logic and create two entry points, a "legacy"
entry point that accommodates "no recompile" legacy callers with their
old parameter list and a "new function" entry point that accommodate new
function callers who must pass a new format parameter list.
Any time you find yourself agonizing over the cleverest way to do
something in assembler you should treat it as a wake-up call. MAYBE the
focus on cleverness is worth it -- perhaps you are solving some complex
issue that arises a million time a day. This is NOT one of those
situations. This problem is simple: is it a legacy caller or a new
function caller? Assembler over-cleverness is surely the wrong solution
to such a simple problem.
While you are at it
- Add a "parameter list version" code as the first byte of your new
parameter list. That will preclude having this issue come up again in a
year or three.
- Make the return code bigger than one byte. Hello? Your target machine
has gigabytes of real storage -- a 32-bit return code isn't going to
hurt anything. Something you might consider: the library routines like
this that I have written in recent years have included as one return
value a pointer to a text string so the routine can return human-useful
diagnostic information without an elaborate return code/documentation
dance. A particular function in your code might do three or four
independent things -- you want to be able to tell your caller not just
that the whole package failed, but WHERE it failed. Does them a favor,
and might make your future debugging easier.
Charles
On 2/17/2026 7:14 AM, Jonathan Scott 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
--
/Charles/
+1-707-291-0908
