Ted asks:

> > But, as I said before, in QueryCalc, the code would merely be:
>  >
>  >     rjs$(ab4,4)
>
>  And would you care to give the equivalent code which *includes* the
trailing
>  spaces (see previous Python and Perl samples)?

In an allocated memory field form of storage, as occurs in a database, I
would be highly prone to say that there is *never* any reason to consider
trailing blanks to be part of the dataitem's value. Indeed, to do so is
undoubtedly a fundamental philosophical mistake. For a single dataitem's text
value, there can be presumed to be an infinite number of trailing blanks,
just as there can be presumed to be an infinite number of leading zeroes in
front a numeric item.

If, for example, the dataitem under consideration was an I2 datatype, the
values 34 and 00000000000000034 are/must be presumed to be exact equivalents
on one another. That wouldn't be true, of course, if the datatype were an X18
field; the "0"'s in that case are text characters and would be as valid as
the other numeric characters or the letter "a", thus "34" and
"000000000000034" must be considered to be two completely different values.
But if the field is numeric, all leading zeroes must be dropped. Just as
similarly, if the field is text, all trailing spaces must be similarly
dropped, because neither the trailing spaces nor the leading zeroes can be
presumed to have any meaning.

A fixed-memory allocation variable, as apparently occurs in COBOL, is not a
string variable. A string variable has at least these two qualities: a
maximum length allocation value and a current length counter. It is this
second counter that LEN$( )-like functions are returning, and that allow the
presence of trailing spaces, simply because the language "knows" how much of
the fixed allocation space to grab and return.

Languages are designed for the context in which they operate. No query
language that operates against the simple fixed-field memory allocations of
an IMAGE-like database can consider the trailing blanks to be part of the
dataitem.

However, neither does HP BASIC do this completely consistently with its true
string handler. While trailing spaces are maintained during string
manipulations ($L = $A+$B), and are processed correctly, as they should be
when using strings, when the same strings are printed, BASIC's intrinsic
print routines strip off all trailing spaces and a NUL character has to be
added to the ends of the strings to prevent this from occurring. While I'm
sure that this printing behavior was put into BASIC during the very earliest
days, when printers were slow as molasses, as a simple efficiency mechanism,
it is a small philosophical faux pas that sooner or later catches everyone.

If you're going to handle strings as strings, then they should be manipulated
in a consistent manner. If you're going to handle text data in the simpler
format of a fixed memory allocation variable, as occurs in IMAGE, then that
too has to be done in a consistent manner.

Wirt