On Mon, 21 Oct 2024 at 19:28, Seymour J Metz <[email protected]> wrote:

> If I know the lengths of an input string and the length of a buffer, I can
> specify a pad character and copy it with MVCL. If I know that it is
> delimited by, e.g., a blank, I can use MVST but I run the risk of a buffer
> overrun. Is there a quick way to copy a delimited string without
> overrunning either the input or output buffer and without resorting to TRT?
>

If you're willing to limit your string to 256 bytes, you can probably use
TROO (TRANSLATE ONE TO ONE), using your data as the table (GR0) and
something like DATA DC 256AL1(*-DATA) as the data (R2). The same trick has
been used with TR since S/360 days to reverse (or otherwise reorder) a
string, but TROO adds the optional test for a terminating "function
character" in R0 that's actually going to be checked for in your source
string. TROO (vs TR) also doesn't require reinitializing the table for each
use, because it doesn't translate in place.

This won't do padding, and your two operands have to have the same length,
so it doesn't have everything wrapped into one instruction, i.e. strncpy().
Generally though, how often does one encounter a situation where the
lengths are both known *and* there may be a delimiter character *and* you
want padding? If that's the case you'd probably use SRST followed by MVCL,
and unfortunately have two passes over the data.

Hmmm... This TROO trick can still check only one length, so you'd have to
be sure the source string has a delimiter, and know the length of your
target field. Which is probably not so unusual.

I'm not seeing a way to use any of the other TRxx instructions to allow for
a longer string, but I may be missing it. I also haven't thought hard about
what happens upon hitting the CPU-determined number of characters and
branching back on CC3, but it's probably fine.

Tony H.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to