Dave,
The root issue you are having is that the subroutine must be able to
identify which calling parm block was used by the caller. So, you need a
new calling block that has something that the new subroutine can use to
make that determination.
I have provided two easy options that do not require the COBOL
programmer to manipulate bits and are fully backward compatible.
Tony Thigpen
President
Thigpen Enterprises
David Clark wrote on 2/16/26 9:38 AM:
Currently, are the calling parms and the calling statement in copybooks?
The calling parms have been provided in four separate copybooks. But they
have been told that they can code their own parameter blocks for any of the
three parameters as fits their needs. The calling statement is *not* in a
copybook because it has a varying parameter list length (even in the legacy
version).
Is the call a dynamic or static call?
Either is acceptable in this environment for batch. For CICS, they've been
advised to use a static call. But since the dynamic call also works under
CICS, there is nothing to stop them. There is no shop standard for these
situations.
Sincerely,
Dave Clark
--
int.ext: 91078
direct: (937) 531-6378
home: (937) 751-3300
Winsupply Group Services
3110 Kettering Boulevard
Dayton, Ohio 45439 USA
(937) 294-5331
On Fri, Feb 13, 2026 at 6:30 PM Tony Thigpen <[email protected]> wrote:
I went back to the original post since the thread has drifted.
Currently, are the calling parms and the calling statement in copybooks?
Is the call a dynamic or static call?
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
