>> When has marketing ever made a DSECT demand that is hidden in a macro
(e.g. DCB)?
I agree that if something is hidden in a macro (from an assembler
perspective), then marketing isn't going to care. But in this case, the
demand is coming from the COBOL side. They don't want any fixed fields
following the 256-byte string because they want that string to be a
variable-length byte string using the COBOL "DEPENDING ON" phrase.
Now, the new layout I have provided in a copybook for them (as follows)
does not use the DEPENDING ON phrase because I have coded it as an
array--which gets messy when you're talking about combining the DEPENDING
ON phrase with it. But that does not stop them from coding their own
parameter block for the very reason that they *want* to use the DEPENDING
ON phrase.
01 TXTMAN-SCRIPT.
* The array is not limited to 99, as there is no technical limit--
* only whatever COBOL allows for the total size of an 01-level.
03 TXTMAN-S-ENTRY OCCURS 99. <== array
05 TXT-S-PARM-REQU PIC X(01).
* scripting requests dependent on a master buffer to manipulate
88 TXT-SCRIPT-COPY VALUE 'C'.
88 TXT-SCRIPT-DELETE VALUE 'D'.
88 TXT-SCRIPT-FIND VALUE 'F'.
88 TXT-SCRIPT-INSERT VALUE 'I'.
88 TXT-SCRIPT-OVERLAY VALUE 'O'.
88 TXT-SCRIPT-PARSE VALUE 'P'.
* scripting requests that transform only the string parameter
88 TXT-SCRIPT-JUSTIFY-L VALUE 'J'.
88 TXT-SCRIPT-JUSTIFY-M VALUE 'M'.
88 TXT-SCRIPT-JUSTIFY-R VALUE 'R'.
88 TXT-SCRIPT-TRIM-R VALUE 'T'.
* scripting requests that translate only the string parameter
88 TXT-SCRIPT-TOASCII VALUE 'A'.
88 TXT-SCRIPT-TOEBCDIC VALUE 'E'.
88 TXT-SCRIPT-PRINTMASK VALUE 'K'.
88 TXT-SCRIPT-LOWERCASE VALUE 'L'.
88 TXT-SCRIPT-UPPERCASE VALUE 'U'.
88 TXT-SCRIPT-WORDCAPS VALUE 'W'.
05 TXT-S-PARM-RETN PIC X(01).
88 TXT-S-STRING-COMPLETED VALUE ' '.
88 TXT-S-STRING-INHERIT VALUE 'I'.
88 TXT-S-STRING-NOT-FOUND VALUE 'N'.
88 TXT-S-STRING-WAS-FOUND VALUE 'Y'.
88 TXT-S-PARSED-AT-BUFEND VALUE LOW-VALUE.
88 TXT-S-INVALID-REQU VALUE 'E'.
88 TXT-S-INVALID-INHERIT VALUE 'F'.
88 TXT-S-INVALID-STRLEN VALUE 'S'.
05 TXT-S-PARM-STRLEN PIC 9(04) BINARY.
05 TXT-S-PARM-STRING.
10 TXT-S-PARM-BYTE PIC X(01) OCCURS 256.
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 Sat, Feb 14, 2026 at 12:37 AM Jon Perryman <[email protected]> wrote:
> On Fri, 13 Feb 2026 10:31:43 -0500, David Clark <[email protected]>
> wrote:
>
> >I'm guessing a lot of you are not comfortable with my idea for backward
> >compatibility
>
> In the professional world, backwards compatibility is always guaranteed
> using macros. If there are 3 versions of those macros, then we verify each
> remains compatible.
>
> >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 not unusual and you will see various solutions scattered
> throughout SYS1.MACLIB. Ever see SYSSTATE in a macro? Have you ever coded
> DCB or DCBD? It should take long to find a macro with compatibility code in
> many forms albeit they may not be obvious. How you determine compatibility
> (to or from) is up to the person writing the code.
>
> >I'm guessing that you would rather add the new fields to the end of the
> DSECT.
>
> This is a common practice by professional developers to avoid coding
> errors (e.g. alignment). QA might not think about testing requirements on
> fields that follow the change.
>
> >But let's say marketing demanded the above format and then
> >let's talk about maintaining backward compatibility.
>
> When has marketing ever made a DSECT demand that is hidden in a macro
> (e.g. DCB)?
>
