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
>
