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
