|
The REXX Column January, 1995 by Dick Goran |
Index of articles |
| Disclaimer: This material is reprinted here, as it was submitted to OS/2 Magazine, as a service to the OS/2 user community. Only minor editing has been done to accomodate the change to HTML format. Some of the information which was valid at the time the original column was written may now be obsolete. No assurance is implied as to its accuracy or completeness. |
REXX Data QueuesREXX has an external data queue facility which can serve as an inter-process communication facility (a fancy term which means that two or more programs may communicate with each other). For simplicity, I'll refer to a REXX data queue simply as the queue. Conceptually, you can think of the queue as a virtual file. There is no restriction imposed upon the contents of the queue other than the fact that items are removed from the queue a line at a time. There are two types of queues. One queue, available only within an OS/2 session, is named SESSION and is allocated whenever a REXX program is started within the session. This local queue is created the first time that data is placed on the queue. The second type of queue, known as a private or named queue (although all queues are named), may be referenced by any REXX program running in any session. This type of queue is private in that any program referencing the queue must know its name. The name given to a queue is subject to the same rules as the formation of a variable name in REXX and the actual name of the queue is the uppercase value of the chosen name. Only one queue, regardless of type, may be considered to be the active queue for a given session at any point in time. The SESSION queue may be used without any special preparation on the part of the programmer. Data may be placed on the queue in multiple ways. The PUSH and QUEUE keyword instructions cause data to be placed on the active queue at the front (FIFO) or the rear (LIFO) of the queue, respectively. Also, output may be piped to the queue using the RXQUEUE subcommand shown in Definition 1. The RXQUEUE() built-in function, shown in Definition 2, is separate and distinct from the RXQUEUE subcommand.
Data may be removed from the queue, a line at a time, with the LINEIN() built-in function using the reserved name of 'QUEUE:' or via the PULL keyword instruction. This is the same PULL instruction which may be used to read input from the standard input stream (stdin) which defaults to the keyboard. In actuality, PULL always reads from the active queue and, if there is no data present on the queue, it reverts to stdin. Listing 1 contains a short program which lists all of the environment variables in the current session like you would see if you issued SET from the command line. The difference is that each line is preceded by a two digit sequence line. My apologies to those of you with more than ninety-nine environment variables.
Listing 1 - Display all environment variables
The SET command is passed to CMD.EXE since it is an external command. The output
from the SET command is sent to the session's currently active REXX data queue. (0002)
The QUEUED() function is used to limit the DO loop so that it will continue the
iteration only while lines remain in the queue. (0005)
The PARSE instruction with the PULL option, or the shorthand PULL instruction is
used to extract data from the queue. The difference between PARSE PULL and PULL is that
the latter also translates the queue data to upper case. (0006)
Inter-process Communication
The REXX data queue provides a convenient mechanism to allow synchronization of
multiple programs. For instance, if a tree list of all of the disk drives and directories of a system
is needed within a REXX program, the main program could start a detached dir command for
each directory after creating a unique queue for the specified drive letter and placing some data
in the queue. The detached dir command could be followed by the RXQUEUE subcommand
to clear the queue.
The main program would test for the absence of data in each queue to determine if each
dir command had completed. If the queue used to synchronize the two sessions (as opposed to
containing the output of the dir command) was named QUEUE_C for drive C:, etc; the program
shown in Listing 2 could be used to start a detached task to write the contents of the directory
command to a file and then clear the queue for each drive letter.
The program shown in Listing 2 can be downloaded.
|