Or better yet.
New book has:
TXTINPT DSECT INPUT STRING PARAMETER
txtflag DS cL2 if not zero, use old layout
txtvers DS cl2 version number
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
New COBOL code does:
move low-values to txtflag.
move '01' to txtvers.
Subroutine says:
CLC txtflag,=x'0000'
BE NEW_CODE
OLD_CODE DS 0H
...
..
NEW_CODE DS 0H
CLC txtvers,=C'01'
BE VER_01
B BAD_VER
VER_01 DS 0H
CLI txtsrequ,c'X'
BE VER_1_REQ_X
....
Tony Thigpen
President
Thigpen Enterprises
Tony Thigpen wrote on 2/13/26 6:57 PM:
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
