>> Not re-assembling code is the basis for this question Well, at least not recompiling the COBOL code (that uses a dynamic CALL). Yes, I provide both an object module and an executable module so that the COBOL programmer is free to CALL it any way they like. Of course, COBOL programs using a static call have their own copy of the assembled code. But when those programs get recompiled, we don't want even a "simple" recompile to break the 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 Sat, Feb 14, 2026 at 7:14 PM Jon Perryman <[email protected]> wrote: > On Sat, 14 Feb 2026 13:28:05 +0000, Peter Relson <[email protected]> > wrote: > > >For full compatibility, start with:You must not require your existing > user to re-assemble. > > Not re-assembling code is the basis for this question > > > It seems very unlikely that you could land with request code > >and return code being possible to have as the two bytes that occupy > >the same place as TXTSTRL in the original unless the request code > >can be something not possible via TXTSTRL in the original. > > The TXTSTRL suggestion should work fine since the documented max length is > X'0100' (256AL1). > > >When the data does not allow such manipulation, you have to look > elsewhere. > > SYS1.MACLIB has various implementations. At least one should work for the > op. As a vendor, we retain a specific level of SYS1.MACLIB because it > guarantees our products will be backwards compatible to the release that > was retained. There are a few IBM products that don't have backwards > compatibility (e.g. IMS forces many exits specific to each IMS release or > we need to support new / old functionality at the same time. >
