>> the subroutine must be able to identify which calling parm block was used by the caller.
Yes, but that is already provided for in the first parm block being passed. That first parm block also has a request code and a return code that applies to the entire call--not just one string process. The following is the abbreviated version of that parm block (minus the equates for flag values). If this request code is 'S' then scripting mode is requested. Anything else is for legacy mode. TXTPARM DSECT HEADER PARAMETER TXTREQU DS CL1 REQUEST CODE TXTRETN DS CL1 RETURN CODE TXTPNTR DS H STRING POINTER TXTDLMS DS CL8 PARSE DELIMITERS RESERVED DS CL260 (INTERNAL USE ONLY) 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 Mon, Feb 16, 2026 at 12:06 PM Tony Thigpen <[email protected]> wrote: > 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 > >> > >
