Colin, At the moment, only DOS/VS RPGII or VSE COBOL programs will be calling this subroutine. VSE doesn't have JAVA (as I'm currently aware) and we don't write our own programs in C.
When they call this subroutine, the DSECTs map to storage in the caller's program. If the caller is not using scripting, then this DSECT will map to a 258-byte storage area in the caller's program. If the caller wants to use scripting, then this DSECT will map to a 260-byte storage area in the caller's program. 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 12:16 PM Colin Paice < [email protected]> wrote: > Some things to check before you start. > > - The DSECT Maps to some storage. Will the allocated storage be > the right length or does it do a getmain for 256+2 bytes? Using the > - length of the dsect is OK - it's the manual size that causes the > problem. > - Do any C/Cobol/Java programs access this data. > - In theory changing the DSECT, changing the documentation, and > recompiling should work. The problem occurs if you have two address > spaces using the information. You have to restart all of them at the > same > time so they are consistent. > - Do any programs outside of z/OS reference the data? This makes it > hard because they all need to be restarted at the same time. > > > if you look at IBM control blocks, they often have fields > DSECT > EYECATCHER DS CL4 > Version ds f > Length ds f > > 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 > > Then your programs check if the version is as expected (or not). > > The eye catcher is great for debugging > > Colin > > > > On Fri, 13 Feb 2026 at 15:32, David Clark <[email protected]> wrote: > > > 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 > > >
