Make your own free website on
5.6. Opening a Stream

In most programming languages, opening a file is the process of
binding a file (given by a file name) to an internal handle. REXX
is a bit special, since conceptually, it does not use stream
handles, just stream names. Therefore, the stream name is itself
also the stream handle, and the process of opening streams becomes
apparently redundant.  However, note that a number of
implementations allow explicit opening, and some even require it.

REXX may open streams “on demand” when they are used for the first
time.  However, this behavior is not defined in TRL, which says
the act of opening the stream is not a part of REXX [TRL2]. This
might be interpreted as open-on-demand or that some system-
specific program must be executed to open a stream.

Although an open-on-demand feature is very practical, there are
situations where you need to open streams in particular modes.
Thus, most systems have facilities for explicitly opening a file.
Some REXX interpreters may require you to perform some
implementation-specific operation before accessing streams, but
most are likely to just open them the first time they are referred
to in an I/O operation.

There are two main approaches to explicit opening of streams. The
first uses a non-standard built-in function normally called
OPEN(), which generally takes the name of the file to open as the
first parameter, and often the mode as the second parameter.  The
second approach is similar, but uses the standard built-in
function STREAM() with a Command option.

Example: Not closing files

Since there are no open or close operation, a REXX interpreter
never knows when to close a stream, unless explicitly told so. It
can never predict when a particular stream is to be used next, so
it has to keep the current read and write positions in case the
stream is to be used again.  Therefore, you should always close
the streams when you are finished using them. Failure to do so,
will fill the interpreter with data about unneeded streams, and
more serious, it may fill the file table of your process or
system. As a rule, any REXX script that uses more than a couple of
streams, should close every stream after use, in order to minimize
the number of simultaneously open streams. Thus, the following
code might eventually crash for some REXX interpreters:

     do i=1 to 300
          call lineout ‘file.’||i, ‘this is file number’ i

A REXX interpreter might try to defend itself against this sort of
open-many-close-none programming, using of various programming
techniques; this may lead to other strange effects.  However, the
main responsibility for avoiding this is with you, the REXX script

Note that if a stream is already open for reading, and you start
writing to it, your implementation may have to reopen it in order
to open for both reading and writing. There are mainly two
strategies for handling this. Either the old file is closed, and
then reopened in the new mode, which may leave you with read and
write access to another file. Or a new file handle is opened for
the new mode, which may leave you with read and write access to
two different files.

These are real-world problems which are not treated by the ideal
description of TRL. A good implementation should detect these
situations and raise NOTREADY.