David,
Use:
TXTINPT DSECT INPUT STRING PARAMETER
TXTSTRL DS H INPUT/OUTPUT STRING LENGTH if positive
TXTSTRG DS 256CL1 INPUT/OUTPUT STRING VALUE
and for new version:
TXTINPT DSECT INPUT STRING PARAMETER
textvers DS H version number if negative
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
In your subroution, if textvers is positive, use the old record format.
If it is negitive, then treat it is a version number.
This make it easy for the Cobol caller as they just need to move -1 to
TEXTVERS. No bit settings. And, if you make more changes in the future,
then they can move -2 or -3.
Tony Thigpen
President
Thigpen Enterprises
David Clark wrote on 2/13/26 10:31 AM:
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
