What's new with REXX

From EDM2
Jump to: navigation, search

By Richard K. Goran

For the first time since OS/2 2.1 was released, we have a number of new events occurring in the REXX community resulting from new software releases by IBM. Warp has hit the streets with additional functions in REXXUTIL, Object REXX has finally been released on Volume 6 of The Developer Connection for OS/2 CD-ROM, and IBM has made REXX generally available for the DOS community with PC DOS 7.0.

Warp and REXX

Warp, or OS/2 Warp Version 3.0 as it is officially named, has added 5 new functions to the REXXUTIL application programming interface, or API as IBM likes to call it. Definitions 1 through 5 contain a description of these new functions. Unfortunately, IBM did not do a very good job in documenting these new functions. While copying, moving, or creating shadows of workplace shell objects (WPS) is somewhat intuitive, saving and opening WPS objects with the new functions is not.

SysCopyObject(), SysMoveObject(), and SysCreateShadow() are fairly straightforward in their purpose. These functions permit a simple means of copying, moving, or creating a shadow of WPS objects from within a REXX program. However, there are some points of special interest when using these three functions.

When an object is copied, no object ID is provided for in the copy. Whether the original object has an object ID or not, the copy will not have an object ID. The only mechanism for assigning an object ID to the copy is with a third-party utility such as DeskMan/2.

When a shadow is created, the shadow ID of the newly created object will have the same value as the object ID of the original object.

Apparently, the purpose of the SysSaveObject() function is to force OS/2 to write the os2.ini file to disk. I have no idea what particular purpose this was created for other than possibly as a fail-safe mechanism in case of a system error. I have asked the IBM REXX development group for an explanation of the function but they have been unable to provide any meaningful information yet.

The SysOpenObject() function is just as obscurely documented in the online rexx.inf file that comes with Warp. As with many of the other WPS functions contained in REXXUTIL, the IBM-supplied documentation refers to WPS and program manger C++ language functions that the average OS/2 user would not have access to without owning the toolkits made for OS/2. The information shown in Definition 4 was compiled from a combination of "bit-digging" research along with some assistance from IBM's Glendale Laboratories - the group responsible for REXX development. The numeric values shown in Definition 4, and used to tell the function which view is to be opened, may not be complete. It will take some trial-and-error testing along with independent research to determine what other values may be used. I suggest that users who want to keep up with the latest information, as it becomes available, stay current with the material in the various REXX related fora on CompuServe (OS2DF1, Section 6), IBM's IBMLink and TALKLink (OS2REXX CFORUM), comp.lang.rexx on the Internet along with your favorite local BBS.






Development Technologies and Greg Czaja have released version 1.51 of DeskMan/2 with updated REXX functionality as well as interfacing with the WPS functions for Warp. CFS Nevada, Inc. has released the third edition of the REXX Reference Summary Handbook (ISBN 0-9639854-2-6) with the Warp additions.

One of the other major changes in Warp that is directly related to REXX is the ability to both create and change printer objects (WPPrinter class) with the REXXUTIL functions. Fragment 6 contains two examples of possible setup strings which may be used to create printer objects. They were suggested by Georg Haschek of PSM, Austria on my OS2REXX forum on IBMLink.

Fragment 6 - Printer object creation

   class    = 'WPPrinter'
   title    = 'Test Printer'
   location = '<WP_DESKTOP>'
   setup    =,
      'QUEUENAME=MYTEST;'        ||,
      'OUTPUTTOFILE=NO;'         ||,
      'PORTNAME=LPT2;'           ||,
      'PRINTDRIVER=IBMNULL;'     ||,
      'DEFAULTVIEW=ICON;'        ||,
      'QUEUEDRIVER=PMPRINT;'     ||,
   call SysCreateObject class,,

   class    = 'WPPrinter'
   title    = 'Test Laser Printer'
   location = '<WP_DESKTOP>'
   setup    =,
      'QUEUENAME=MYLASER;'              ||,
      'OUTPUTTOFILE=NO;'                ||,
      'PORTNAME=LPT3;'                  ||,
      'PRINTDRIVER='                    ||,
      'LASERJET.HP LaserJet Series II;' ||,
      'DEFAULTVIEW=ICON;'               ||,
      'QUEUEDRIVER=PMPRINT;'            ||,
      'PRINTWHILESPOOLING=YES;'         ||,
   call SysCreateObject class,,

Object REXX

After a long awaited delivery preceded with many "real soon now"s, Object REXX was released as part of The Developer Connection, Volume 6. While I haven't had a chance to use these enhancements to traditional or "classic" REXX as one IBMer termed it, I have read some reviews that lead me to believe that, while the extended features of Object REXX may be substantial, it is not for the faint-at-heart. The idea of having a built-in interface to System Object Module (SOM) classes and methods is very exciting. However, the absence of documentation on the Volume 6 CD-ROM with Object REXX relating to the workplace classes and methods indicates that either IBM doesn't think that this product is ready for the big-time or they have intended it for commercial programmers.

In order to use Object REXX, it will be necessary to obtain a copy of the OS/2 Technical Library. Along with that, it will be necessary for the user to understand the format of C++ language calls and to interpolate what is written for C++ into the format required by Object REXX. This is not a very pretty way to introduce a "language neutral" facility.


While I know that both this magazine and this column are intended for OS/2 users, I would be remiss if I didn't mention the availability of REXX as an integral part of DOS 7.0. The DOS documentation calls it the "language of choice" for DOS users beginning with 7.0.

Because of the lead time necessary to submit this column, I have only had the opportunity to exercise beta copies of the DOS REXX interpreter. The PARSE VERSION instruction returns REXXSAA as the language processor along with a level of 4.0 and a date of 08 Jul 1992. Yet, this REXX interpreter, at least the version I have been testing, does an injustice to the System Application Architecture concept in which IBM states:

"Programs written in REXX according to SAA specifications are portable to all other SAA environments. For example, a REXX program written for the OS/2 environment can be run in a CMS or TSO/E environment, if the program does not use OS/2-specific features."

Unfortunately, this is not the case. As a matter of fact, the DOS REXX interpreter is a long way from being compatible with the OS/2 REXX interpreter. Furthermore, without an external data queue capability along with the general system and file functions available in OS/2 REXX, DOS REXX will probably serve very little useful purpose for OS/2 REXX programmers.