REXX Components

By Richard K. Goran

One of the more difficult tasks in learning a new programming language is trying to digest all of the facilities that the language provides. REXX has only 26 actual key-word instructions. Its power lies in the functions that accompany the instruction set. Tables 1 through 4 were compiled to provide the REXX programmer, particularly those who are new to the language, with a concise overview of these functions. Each table contains a logical grouping of the functions by what they do or the services they provide.

Table 1 contains a list of the 26 key-word instructions. Table 2, the largest of the four, contains a list of the built-in functions. Table 3 contains a list of the external commands provided with OS/2 REXX. Finally, Table 4 contains a list of the functions contained in the REXXUTIL application programming interface (API) which accompanies OS/2 REXX. At first glance, the limited number of key-word instructions might give the impression that REXX is limited in its scope. Quite the contrary. The small number of instructions and the large number of built in functions is one of the reasons that powerful REXX programs can be written so quickly and so easily. The built-in functions in Table 2 are divided into logical groups according to what they do. Most of the group names are self-explanatory. However, clarification is warranted on some. The conversion functions provide the capability of converting one type of field into another. The particular conversion is dictated by the key letters B, C, and X (both preceding and following the character 2 in the function name) representing binary, character, and hexadecimal. The Boolean functions permit individual bits to be used within strings. The Page Manager function is unique and allows REXX programs limited capability in producing graphical dialogue boxes with imbedded icons and push buttons.

The System functions that appear in mixed case in Table 2 are unique to OS/2; whereas, all of the other built-in functions should be present in all of the other SAA REXX interpreters available from IBM.

The REXXUTIL functions shown in Table 4 are what allow REXX to become so well integrated with OS/2 and the Workplace Shell. It is the object-related functions that permit REXX programs to create, manipulate, and alter WPS objects on an OS/2 system. The five functions identified with an asterisk (*) are new to OS/2 Warp Version 3. Graphical User Interface (GUI), or Presentation Manager, programming is available with VX-REXX from WATCOM Systems, VISPRO REXX from Hockware, or Gpf REXX from Gpf Systems. There are also numerous APIs available as either freeware, shareware, or commercial products that further enhance REXX with OS/2. Quercus Systems produces the REXXLIB module and SoftNet distributes the GammaTech SuperSet/2 package both commercial offerings which provide a wide range of system-related functions, math routines, and file system functions. Also, the YDBAUTIL group of functions is available as rxu1a.zip.

Various other specialty APIs can be found on file repositories around the world. Some of the more popular function modules provide asynchronous communications, data base interfaces, high precision mathematical routines as well as some diverse specialty routines.

Using the Warp Internet Access Kit, you can "surf" the net looking for additional REXX APIs, many of which are free. As well as the other Internet addresses that have already been listed, the following are known to be REXX repositories: rexx.uwaterloo.ca/pub/freerexx, and ftp.cfsrexx.com/pub.

Correction
In last month's column, I published some wrong information about one of the five new REXXUTIL functions introduced in Warp. The error resulted from some ambiguous information released by IBM's Glendale Lab - the REXX development group.

The following is a corrected version of the definition of the SysSaveObject function.

Warp/REXX Mystery Failures
There has been a "fix" in Warp Version 3 implemented by IBM that is subtly causing REXX programs, that ran with prior versions of OS/2, to fail. The culprit is the lack of file handles in the OS/2 session where the REXX program is running.

The default number of file handles, a resource required for each open file, is, and has been, twenty. Of the twenty, fifteen are available for user programs with five being reserved for system-related files. Prior to Warp Version 3.0, when multimedia support was installed it changed the default for the number of file handles from twenty to eighty. Apparently, this was being done without the knowledge of the kernel developers and they deemed it necessary to "correct" this problem.

The end result is that if you have a REXX program that inadvertently references file with any of the input/output (I/O) functions: CHARIN, CHAROUT, CHARS, LINEIN, LINEOUT, or LINES or uses any library functions that do not close all of their files (for example - the SysGetMessage function); these programs may begin to fail. The only way to prevent this from happening is to increase the number of file handles available in the particular session where the program is running. This can be done with the GrowHandles C function. Quercus Systems has implemented this capability in their latest version of REXXLIB, a commercial product that is available in a fully functional "demo" form from your favorite OS/2 BBS or repository. With the addition of rexxlib.dll, you can call the DOSFILEHANDLES function and specify the number of file handles you want to be available for that session. Once the number of file handles has been increased, the larger number of file handles remain available to that session until the session is closed.