>> Or - better - ask marketing for *their* solution... Ha! I like that one.
>> Can you restrict the scripting request code to 7 bits? It would have to be 6 bits -- the leftmost bit is reserved for the sign and the right-most bit of the top byte is reserved for a length of exactly 256 (b'10000'). But, 6 bits do give me 63 combinations. So, yes, I could create flags for 16 possible request codes and the 8 possible return codes out of that. However, this subroutine was originally intended to help COBOL programmers perform string functions not directly supported by COBOL. A calling COBOL program would have a difficult time setting those request codes and checking those return codes. >> Or - if not - can you add a flag at the end to delineate the new format. Now you're talking about creating a separate 260-byte work area to transform the scripting parameter layout into a 3rd layout that would more easily support both runtime modes. If this subroutine were only going to be used in batch, then I could dynamically allocate that storage and be "in like Flynn", as it were. But I don't think I should do the same in a CICS partition. 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 10:39 AM Alan Atkinson <[email protected]> wrote: > If you have a halfword for a 256 byte string you have 8 flags for new > formats in the top byte. > Can you restrict the scripting request code to 7 bits? > > Or - if not - can you add a flag at the end to delineate the new format. > > Or - better - ask marketing for *their* solution... > > > > On 2/13/26, 10:32 AM, "IBM Mainframe Assembler List on behalf of David > Clark" <[email protected] <mailto: > [email protected]> on behalf of [email protected] > <mailto:[email protected]>> wrote: > > > > > EXTERNAL > > > > > ====================================================================== > 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 > > > >
