When designing your external function packages, keep this in mind: Mike Cowlishaw's primary design goal for the Rexx language was that it should be easy to use for both the professional user and the casual user as well. It is very easy to create functions which are simply wrappers over top of system API calls; in many cases, these are the most useful functions to add. But when you add functions such as these, remember that your "audience" will inevitably consist of general users who are not necessarily familiar with the intricacies of the systems they use. Make your external functions as simple as possible, with as few required arguments as possible and try to make the arguments that are necessary as intuitive as possible.
We've discussed in this article just a single aspect of the extensibility of the Rexx language. Earlier, we alluded to some of the other things that can be done using the Rexx API. The sorts of support that the Rexx API offers includes not only the external function support, but also support for external subcommand environments. Within a Rexx program, the user may issue commands to the supporting operating system. Under MS/PC-DOS, for example, you may include a line in your Rexx program such as "del *.bak". When the interpreter encounters this line, it is passed off to the active subcommand environment for execution. Notice that I said the active subcommand environment. Yes, multiple subcommand environments can be available. Those different environments are accessible by using the "ADDRESS" Rexx statement.
The Rexx API allows users to create new subcommand environments and to make them available to Rexx programs. One of the many uses for subcommand environments is in emulating other operating systems. For example, under Windows NT, I can create a "TSO" subcommand environment wherein I emulate commands that are usually available only on that system.
Yet another example of using subcommand environments points as well to another application of the Rexx language, that of an imbedded macro language for, say, an editor or a terminal application. You might use subcommand environments in this situation in order to retrieve information from the application such as the current cursor position, or the status of a communications port.
Using Rexx as a batch, or procedures language is well established. IBM has named Rexx as it's SAA procedures language and it is standard equipment under TSO/E, VM/CMS and OS/2. Instead of having to write your batch files in "batch" language under OS/2, you have the option of using the more powerful Rexx language. ARexx is standard equipment on Amiga computers and Quercus Systems provides Personal Rexx for OS/2, MS/PC-DOS, 16-bit Windows and Windows NT. Other vendors supply Rexx implementations for various flavors of Unix(4) and VMS(5) as well.
The Rexx API allows for access to the variable pool associated with the Rexx program that is running. You could write a function where the user tells you the name of the variable into which you should write the results of the function, instead of returning it directly from the call.
The Rexx API also provides access to system exits, which allow the user to tailor things such as input and output. For example, one of the exits provided is for the "say" keyword instruction. I could "hook" this exit and prepend "bill: " to every line that is written with the "say" instruction.
Finally, the Rexx API offers support for access to Trace/Halt requests, External Data Queues and the MacroSpace.
At the end of the day, Rexx is likely one of the most powerful languages ever developed. Certainly the most extensible language ever developed. I hope that this article has shed at least a small amount of light on the ease with which Rexx can be extended, and thus shown a fraction of its power as a programming language for virtually any programming task.
Return to Contents
Read Footnotes
Bill Potvin
bill.potvin@network.com