3.1.5 Possible System Dependencies
Some of the functions in the built-in library are more or less
system or implementation dependent. The functionality of these may
vary, so you should use defensive programming and be prepared for
any side-effects that they might have.  These functions include:

·    ADDRESS() is dependent on your operating system and the
  implementation of REXX, since there is not standard for naming
  environments.

·    ARG() at the main level (not in subroutines and functions) is
  dependent on how your implementation handles and parses the
  parameters it got from the operating system.

·    BITAND(), BITOR() and BITXOR() are dependent on the character
  set of your machine. Seemingly identical parameters will in
  general return very different results on ASCII and EBCDIC
  machines. Results will be identical if the parameter was given to
  these functions as a binary or hexadecimal literal.

·    C2X(), C2D(), D2C() and X2C() will be effected by the
  character set of your computer since they convert to or from
  characters. Note that if C2X() and C2D() get their first parameter
  as a binary or hexadecimal literal, the result will be unaffected
  by the machine type. Also note that the functions B2X(), X2B(),
  X2D() and D2X() are not effected by the character set, since they
  do not use character representation.

·    CHARIN(), CHAROUT(), CHARS(), LINEIN(), LINEOUT(), LINES()
  and STREAM() are the interface to the file system. They might have
  system dependent peculiarities in several ways. Firstly, the
  naming of streams is very dependent on the operating system.
  Secondly, the operation of stream is very dependent on both the
  operating system and the implementation. You can safely assume
  very little about how streams behave, so carefully read the
  documentation for your particular implementation.

·    CONDITION() is dependent on the condition system, which in
  turn depends on such implementation dependent things as file I/O
  and execution of commands. Although the general operation of this
  function will be fairly equal among systems, the details may
  differ.

·    DATATYPE() and TRANSLATE() know how to recognize upper and
  lower case letters, and how to transform letters to upper case.
  If your REXX implementation supports national character sets, the
  operation of these two functions will depend on the language
  chosen.

·    DATE() has the options Month, Weekday and Normal, which
  produce the name of the day or month in text.  Depending on how
  your implementation handles national character sets, the result
  from these functions might use the correct spelling of the
  currently chosen language.

·    DELWORD(), SUBWORD(), WORD(), WORDINDEX(), WORDLENGTH(),
  WORDPOS() and WORDS() requires the concept of a “word”, which is
  defined as a non-blank characters separated by blanks. However,
  the interpretation of what is a blank character depends upon the
  implementation.

·    ERRORTEXT() might have slightly different wordings, depending
  on the implementation, but the meaning and numbering should be the
  same. However, note that some implementations may have additional
  error messages, and some might not follow the standard numbering.

·    QUEUED() refers to the system specific concept of a “stack”,
  which is external to REXX. The result of this function may
  therefore be dependent on how the stack is implemented on your
  system.

·    RANDOM() will differ from machine to machine, since the
  algorithm is implementation dependent. If you set the seed, you
  can safely assume that the same interpreter under the same
  operating system and on the same hardware platform will return a
  reproducible sequence.  But if you change to another interpreter,
  another machine or even just another version of the operating
  system, the same seed might not give the same pseudo-random
  sequence.

·    SOURCELINE() has been changed between REXX language level
  3.50 and 4.00. In 4.00 it can return 0 if the REXX implementation
  finds it necessary, and any request for a particular line may get
  a nullstring as result. Before assuming that this function will
  return anything useful, consult the documentation.

·    TIME() will differ somewhat on different machines, since it
  is dependent on the underlying operating system to produce the
  timing information. In particular, the granularity and accuracy of
  this information may vary.

·    VALUE() will be dependent on implementation and operating
  system if it is called with its third parameter specified. Consult
  the implementation specific documentation for more information
  about how each implementation handles this situation.

·    XRANGE() will return a string, which contents will be
  dependent on the character set used by your computer. You can
  safely make very few assumptions about the visual representation,
  the length, or the character order of the string returned by this
  function.

As you can see, even REXX interpreters that are within the
standard can differ quite a lot in the built-in library. Although
the points listed above seldom are any problem, you should never
assume anything about them before you have read the implementation
specific documentation.  Failure to do so will give you surprises
sooner or later.

And, by the way, many implementations (probably the majority) do
not follow the standard completely. So, in fact, you should never
assume anything at all. Sorry ...


 PREV   NEXT