There have been some happenings recently in the REXX arena. A happening, as defined by Webster, is "something (as an event) that is particularly interesting, entertaining, or important". With the release of OS/2 Warp 4 (a.k.a. Merlin), OS/2 now has two REXX interpreters - classic REXX and Object REXX. Classic REXX is the name being used to designate the SAAREXX interpreter that has been available on previous releases of OS/2 Warp. Object REXX is a completely new REXX interpreter that has a direct interface with System Object Module (SOM) and provides many new capabilities to the REXX programmer. Prior to OS/2 Warp 4 Object REXX had only been available in beta release on the Developer Connection CD-ROM. All of the functionality of classic REXX is included in Object REXX along with the new object capability.
IBM chose to release OS/2 Warp 4 with classic REXX as the default REXX interpreter that is installed when you install Warp 4. There are a couple of reasons this was necessary. The most important was a paradigm shift with Object REXX where a complete REXX program is checked syntactically before execution is allowed. This is not the case with classic REXX. As a result, a REXX program that contains syntax errors in its code will not trap until that code is executed. Therefore, REXX programs that have run properly for some period of time may all of a sudden begin to trap with varying errors. The same program under Object REXX will not execute at all since the syntax errors are caught prior to the code being executed. This change alone would cause a large percentage of existing REXX programs to fail. The second major change with Object REXX is its dependency on the Workplace Shell. Since a number of large enterprise installations run OS/2 without the Workplace Shell, defaulting to Object REXX would make it impossible for them to install OS/2 Warp 4. The choice of classic REXX as the default interpreter rather than Object REXX poses no real hardship since IBM also provided the ability to toggle between the two. The only down-side to this is that a re-IPL (or reboot) is required to implement the alternate REXX interpreter. There is no way around this since the two interpreters can not co-exist on the same system because of DLL conflicts.
Warp 4 contains the file \os2\switchrx.cmd which will toggle the classic REXX and Object REXX interpreters on your system. Calling SWITCHRX a second time before re-IPLing allows you to undo the previous toggle. While SWITCHRX is not the most flexible REXX program I have ever seen, it works properly so long as your DLL files are in the same directories where the original OS/2 Warp install put them. After switching from classic REXX to Object REXX its is also necessary to run \os2\wpsinst.cmd. This program will register the Workplace Shell classes used by Object REXX. WPINST can also be used to query whether the Object REXX classes have been registered.
Some long awaited fixes to classic REXX are included in OS/2 Warp 4. Among these are the problems caused by applying Fix Packs 17 through 22 to OS/2 Warp 3.0. These errors are most noticeable when running REXX programs written in either the VX-REXX from Watcom International or VisPro/REXX from HockWare. These same fixes will be available in a later Fix Pack from IBM; however, they are also available free for download as [rexxsom.zip]. Check the REXX-related Files page at this web site for the latest information. Some of the symptoms of the problems that are fixed include: truncated dialog boxes, SYS3175 traps when exiting the respective GUI REXX design environment, spin buttons that don't pass their changes back to the program that owns them, and mysterious hangs when running GUI REXX programs.
If you are interested in both computer games and REXX and want to see a GUI program that exploits REXX in a graphical environment to its fullest, I have made our new video poker game, CFSPoker, available free for anonymous download. This game replicates the video poker machines that have become so popular around the world. The program is distributed with 1,000 video poker credits and, so long as you maintain a positive credit balance, there is no registration fee or other obligation.
Any time you update your operating system, you run the risk of "losing" programs and files that you had previously installed. This is a particularly perplexing problem when a program that you installed along time ago also had Dynamic Link Library (DLL) files that it installed. Similarly, you probably have executable files (.exe) that are buried deep in your PATH that you have forgotten about. It is a fairly simple task in REXX to write programs that will traverse both the PATH and LIBPATH in your config.sys. You can then use the SysFileTree() function to build a stem or compound variable of all of the appropriate file extensions and create a list of these files. There are two free tools (listdll.zip and listexe.zip) which you can anonymously download which will accomplish this task for you or which you can use as a model to write your own program. LISTDLL not only produces a listing (listdll.txt) of all DLLs in their search order precedence, it also will provide you with a listing of any DLL that appears in more than one directory which is included in your LIBPATH. Similarly, LISTEXE will list all of the executable files in the same search order that they would be found if you launched the program.
One particular DLL that you probably have in more than one directory is vrobj.dll. This file contains the run-time routines used by VX-REXX. Each VX-REXX program you install more than likely comes with its own copy. If you have programs on your system that were written with version 1 of VX-REXX you cannot discard the version 1 VROBJ since the current version (2.1d) is not compatible with the older version. However, if you have multiple VX-REXX programs that use version 2 of VROBJ, you only need one copy of the 900K file so long as it is located in a directory that is included in your LIBPATH.
FAXWorks Pro for OS/2
The FAXWORKS Pro for OS/2 is expected to have the REXX Application Program Interface (API) interface designed by the Keller Group for PMFax (the enterprise parent of FAXWorks Pro for OS/2) ready for release in the near future. The REXX API allows you to fax enable your REXX programs, customize voice answering scripts, and augment the product with your own value-added features. The REXX API provides you to create customized voice, FAX, text, and E-mail applications and delivering them to a diverse user community.
The API consists of two types of functions. The FxLn functions (Line Control REXX Functions) can be called only within REXX scripts which are running as an "Answer Script" or "Dial Script" in PMFAX to answer incoming calls and interact with the caller. The FxRx functions (External REXX Functions) can be called from any REXX code, including applications that are written in VisPro REXX, VX-REXX or other REXX tools to provide your applications with a full Presentation Manager interface.