>> 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 >
