If you have a halfword for a 256 byte string you have 8 flags for new formats in the top byte. Can you restrict the scripting request code to 7 bits?
Or - if not - can you add a flag at the end to delineate the new format. Or - better - ask marketing for *their* solution... On 2/13/26, 10:32 AM, "IBM Mainframe Assembler List on behalf of David Clark" <[email protected] <mailto:[email protected]> on behalf of [email protected] <mailto:[email protected]>> wrote: EXTERNAL ====================================================================== I'm guessing a lot of you are not comfortable with my idea for backward compatibility--requiring the re-basing of a DSECT by 2 bytes to support dual formats for the associated parameter. If so, I'm actually open to hearing how the real world would handle backward compatibility when 16 legacy functions are dependent upon one parameter format and now you want those same 16 functions to also support a new parameter format? 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 I'm guessing that you would rather add the new fields to the end of the DSECT. But let's say marketing demanded the above format and then let's talk about maintaining backward compatibility. Thanks, Dave Clark
