<snip> This is the legacy layout: TXTINPT DSECT INPUT STRING PARAMETER TXTSTRL DS H INPUT/OUTPUT STRING LENGTH TXTSTRG DS 256CL1 INPUT/OUTPUT STRING VALUE
And this is the new layout to, in my case, support mini-scripting for these same 16 functions. TXTINPT DSECT INPUT STRING PARAMETER TXTSREQU DS CL1 SCRIPTING REQUEST CODE TXTSRETN DS CL1 SCRIPTING RETURN CODE TXTSTRL DS H INPUT/OUTPUT STRING LENGTH TXTSTRG DS 256CL1 INPUT/OUTPUT STRING VALUE </snip> For full compatibility, start with:You must not require your existing user to re-assemble. That means that you cannot add to the size of area that the existing user must provide. If you can segregate the data such that there are choices that the current user cannot provide,then you have a chance. It seems very unlikely that you could land with request code and return code being possible to have as the two bytes that occupy the same place as TXTSTRL in the original unless the request code can be something not possible via TXTSTRL in the original. When the data does not allow such manipulation, you have to look elsewhere. That could include: - new callers use a new entry point and the new parameter list applies at that EP - new callers provide a value in the parameter list address register that could notpossibly be a valid parameter list address and have the parameter list addressin a different register in that case. Your choice of language and other interfacerequirements could make this approach infeasible Peter Relson
