REXX Symposium, May 1995

by Melinda Varian

I attended the Sixth International REXX Symposium, hosted by the Stanford Linear Accelerator Center.

One of the most hotly discussed topics of the Symposium was IBM's recent announcement that all REXX development will be moved from Endicott, New York, to Boeblingen, Germany, over the next few months. Apparently, none of the current developers will be moved. Having seen IBM do this to a number of other software products in the past, I am inclined to believe that (however talented the Boeblingen programmers being assigned to this project) we will see a period of 18-24 months during which REXX will make little forward progress. I am always appalled at how casually IBM squanders its intellectual capital.

However, lest one be inclined simply to shrug and say that IBM management will never learn, there was another announcement that astonished seasoned IBM-watchers: REXX Development will port the soon-to-be-completed Object REXX to LINUX, and the source code for that port will be made available on the Internet in the hope that others will use it as a basis for ports of Object REXX to other flavors of UNIX. Anyone who does such a port will be allowed to market it for a profit, with no royalties to IBM.

Object REXX was demonstrated repeatedly during the Symposium and has clearly progressed substantially since the last Symposium. It is now scheduled to become generally available as follows:

Although Symposium participants were quite enthusiastic about the current implementation, several expressed reservations about IBM's choice of VisualAge as the visual tool to be used with Object REXX (that being a rather pricey piece of software).

Attendance at the Symposium was about 130, double last year's number. As usual, many authors of REXX implementations were in attendance, including:

(We were all delighted to see Ian's bound copy of his Oxford doctoral thesis and to hear that he would soon receive his degree.)

Others in attendance included representatives from the Workstation Group (Uni-REXX and Uni-XEDIT, http://www.wrkgrp.com/) and from SIMWARE (2 Gurdware Road, Ontario K2E 1A2, Canada), which has REXX implementations for Netware, Windows, and the Macintosh.

Among the first-time attendees were Les Koehler, of Advantis, whom Mike credits with being the first person outside the UK to write a REXX program, and Russ Williams, now retired from IBM, who wrote the widely-used REXXIFY program that converted ever so many EXEC Classic and EXEC2 programs to REXX.

The Symposium program began with two excellent REXX tutorial sessions by Chip Davis, of Aresti Systems, a member of the REXX ANSI Standard Committee. The examples Chip used in his tutorials are available on the Symposium diskette.

The program continued with the following sessions:

Mike Cowlishaw (IBM), "REXX 1995: The Growth of a Language"

(Back to Table of Contents; on to next session).

REXX began when Mike woke up in the middle of a night in March, 1979, and began thinking about the possibilities. One of his inspirations was Chris Stephenson's 1973 paper that introduced the concept of a single macro language for many applications.

One of Mike's primary goals was to design a language that would be easy for users to learn and to retain (in other words, a language designed for the benefit of the user, not the implementer). His earlier experience with designing a language used for teaching programming had taught him that people have a hard time learning "notation"; that is, whenever people must learn (by rote) that a certain symbol has been assigned some arbitrary meaning, they have difficulty, and they tend to forget what they have learned if they go for a while without using the language.

By 1979, CMS users were writing quite complicated programs in EXEC2, so that language's use of ampersand to denote keywords and variables had become offputting. One saw programs in which more than 50% of the tokens began with ampersands.

Mike discussed his ideas for a new scripting language with colleagues at Hursley and with other IBMers over IBM's VNET network, which then had 300 nodes in Europe and North America. He sent out the first language specification and began incorporating the feedback. He typically wrote and circulated the documentation for each new feature to get feedback on the desirability of the new function before doing the implementation. He also typically first wrote a few programs to exercise the new feature and see whether it was right.

The first implementation was distributed via VNET on May 21, 1979. "From then on, the good ideas came from the users." For example, David N. Smith, the father of VMSHARE, insisted upon being able to nest comments.

Concatenation with a blank may be the only truly unique feature of REXX, according to Mike.

By the end of the first year of work on REXX, he had spent 1,000 hours on it (nights and weekends -- during the day he was designing hardware) and had produced 10,000 lines of Assembler and 5,000 lines of documentation.

He lists the following as the mistakes in his design:

He lists these factors as being particularly significant in the success of the language:

The development of REXX would not have been possible without the VNET network. The use of the network for rapid design evolution was almost an experiment, although not a deliberate one.

During the period of 1980 to 1984, there were 30 internal releases of REXX. The change of Args to Arg is estimated to have broken 2.5 million programs. Estimates of the internal costs of changing the name from REX to REXX (at the insistence of the lawyers) were about $1 million (for updating local documentation, etc.).

The first non-IBM implementation of REXX was Charles Daney's Personal REXX in 1985. There are now more than 25 REXX products available, and the number continues to grow rapidly. (In addition, there are about 70 REXX books, other than manuals, in print.) Mike is attempting to build a complete list of REXX implementations and books and would appreciate receiving updates and corrections to the list to be found in the REXX Web page, http://www2.hursley.ibm.com/rexx/.

His concluding points were:

(The usage numbers given here are very conservative and arrived at by the convergence of multiple approaches to calculating them. One indication is the number of copies of Mike's book The REXX Language that have been sold, which is 100,000.)

Tim Browne (IBM), "REXX: Launching the Next Generation"

(Back to Table of Contents; on to next session).

Browne is (for the time being) the IBM REXX Product Manager. He began his talk with assurances that all would be well with the move of REXX to Boeblingen and added that everything he said here today will apply even though his group will not be doing the work.

He defined the mission of REXX Development as being to:

In response to a question, Browne stated that IBM will make Classic REXX conform to the almost-completed ANSI standard, although no other development is planned for Classic REXX.

Boeblingen will have 30 people working on REXX, including development, marketing, planning, and information development.

His group will pick up some PowerPC work that is overflowing from Boca Raton. He stated that the reason for not instead moving the PPC work to Boeblingen was that Endicott already has some PPC expertise.

The Object REXX port to Windows will work on Windows 32S, NT, and 95.

The LINUX version will be distributed at no charge. The only requirement for people using it as the basis of a product is to acknowledge that it is derived from the IBM version. (It will not have a GNU-style license, as products based on it can be sold commercially.)

The Object REXX implementations for IBM platforms will not be separately priced, but will be bundled into the operating systems.

Dave Gomberg (Experimenta), "REXX in PC/DOS 7.0"

(Back to Table of Contents; on to next session).

Dave Gomberg, who is co-author of the first REXX book (Robert O'Hara and David Gomberg, Modern Programming Using REXX, second edition, Prentice-Hall, 1988), presented a brief overview of the REXX that IBM has added to PC/DOS in version 7.0 (and that IBM has described as being "the programming language of choice" for that system).

IBM's having introduced REXX into DOS is important as a sign of IBM's commitment to REXX. The REXX in DOS is essentially equivalent to the one in OS/2, but Dave finds that he misses some function from Charles Daney's Personal REXX and REXXLIB products.

One problem with the new REXX is that REXX programs by default have an extension of BAT, rather than CMD. This means that they cannot change the path, because so much of the environment, including the path, is refreshed when a BAT program exits.

IBM seems also not to be deriving the benefit it might have from having added REXX to DOS, as there is little documentation or other "marketing" of the new function. There is a REXX manual for DOS, but nobody in the room other than Mike had actually gotten hold of a copy of that manual.

Markus Pelt-Layman (Pelt Industries), "RexxAnne: Issues and Problems Writing REXX Compilers"

(Back to Table of Contents; on to next session).

Markus Pelt-Layman is a very active REXX enthusiast. He has a background in building computer operations automation software. His company is developing the RexxAnne compiler and development environment for Windows and markets the Enterprise REXX interpreter for Windows NT. (RexxAnne is not yet on the market.)

Before launching the RexxAnne project, Markus had a marketing survey done that concluded that Windows users don't know about REXX and, thus, would not be likely to buy RexxAnne. That and his enthusiasm for REXX led him to begin his INTER REXX newsletter and Info REXX, a multimedia compendium of information about REXX.

Info REXX and subscriptions to INTER REXX are available from:

Markus requested photos, film clips, and other REXX information, such as news of REXX products and publications, for use in Info REXX. He mentioned that the next issue of INTER REXX will have an article by Mike Baryla, of IBM Endicott, that does an excellent job of showing off Object REXX.

Pelt Industries has a REXX bulletin board, Rexx-R-Us, (303) 440-1351.

Les Cottrell and Bebo White (SLAC), "Writing WWW CGI Scripts in REXX"

(Back to Table of Contents; on to next session).

SLAC had the first Web server in the United States (September, 1991) and was the first IBM customer to have REXX (in the early Eighties), so it was not surprising to find that SLAC is leading the way in using REXX to build WWW Common Gateway Interface scripts. These two speakers have made the handouts from their very useful presentations available on the Web:

Most of their examples were of using Uni-REXX on a UNIX server, but mention was also made of using Rick Troth's WEBSHARE server for VM. (Since the Symposium, I have found it easy to port some of the SLAC CGI code for use on VM.) I found Cottrell's discussion of security considerations in writing CGI scripts in REXX to be particularly helpful. (Be very careful about using Interpret. ;-)

Rick McGuire (IBM), "Object REXX Up Close and Personal"

(Back to Table of Contents; on to next session).

Rick has worked in REXX Development in Endicott since March, 1982, when he became involved in integrating the internal version of REXX into VM/SP3. The Object REXX work was begun in 1988 by Simon Nash and was transferred to Endicott about two years ago.

Rick began by saying that Mike's philosophy with regard to enhancing REXX has always been to find a single general solution that not only solves the problem at hand but also enables other solutions. He makes a point of avoiding "creeping featurism". REXX Development has tried to adhere to that philosophy in writing Object REXX.

A beta-test version of Object REXX is available on the OS/2 Developers Connection. Object REXX is a complete rewrite of the interpreter. It is entirely upward compatible with "REXX Classic" and addresses many non-OO requirements against REXX Classic. The Object REXX interpreter is twenty percent faster than the existing Classic interpreter, as measured by Mike's standard REXX benchmark. (The design goal had been for no more than a fifteen percent degradation in performance.)

The remainder of Rick's presentation was an overview of Object REXX. Later in the symposium, another speaker commented that he had been disappointed to learn how much "notation" has been added to REXX for Object REXX, and I found myself agreeing with his comment. Nevertheless, Object REXX is an impressive achievement. The single hour allotted for Rick's presentation was far too little to allow him to do justice to the subject, and his pace was such that my notes below are very incomplete.

In Object REXX, everything is an object; everything that happens is a method; and everything that happens is caused by a message. It used to be in REXX that everything was a character string; now character strings are but one kind of object. Methods are actions on objects. Messages invoke methods. The character "~", which is pronounced "twiddle", sends a message. Thus, say name~word(2) is the same as say word(name,2). In the first case, the twiddle sends the message "word(2)" to the object "name" and thus invokes the "word" method of the "name" object, passing it an argument of "2". One can use either syntax as long as the objects are all strings.

(In addition to "~", there is also "~~". Both send a message, but while "~" returns the result of the method, "~~" returns the object that received the message.)

All REXX operators are now messages. Thus, say 1+2 is equivalent to say 1~'+'(2). The latter sends the message "'+'(2)" to the "1" object, invoking its "+" method with the argument "2". Most people would not want to code in that form, of course, but the benefit of making operators methods is that now one has "operator overload" or "polymorphism". The same message may be sent to dissimilar objects, and the specified method will behave as appropriate to the nature of the object in each case. For example, Object REXX has a Complex class which defines complex numbers. x = .complex~new(2,3) creates an instance of a complex number. (The message "new(2,3)" is sent to the "complex" class to invoke the class method "new" with arguments appropriate to a complex number.) After that statement is executed, say x produces "2+3i". Objects of the complex class have a "+" method. Thus, this little program: 

  x = .complex~new(2,3)
  y = .complex~new(4.5,6.7)
  say x+y

displays "6.5+9.7i". say x+y could be replaced with say x~'+'(y), but that is too ugly for anybody to use.

(The leading dot denotes an environment symbol. Its default value is the string consisting of the characters of the symbol translated to upper case. If the symbol identifies an object that the current environment has defined, its value is that object. In the case above, ".complex" identifies the Complex class, which like other Object REXX classes is preloaded into the environment.)

Every class has a "string" method, which returns its string representation. Thus, if we create an instance of the Animal class by specifying pooh = .animal~new, then say pooh displays "an ANIMAL". Objects of the hypothetical Animal class might also have a "display" method that would display other properties of the objects; that is, pooh~display might produce "Animal of genus ... with name eating ". An ugly syntax could be invoked to set the name for the object (assuming "name=" were a method of the Animal class): 

  pooh~'name='('Eeyore')

After that, pooh~display would display "Animal of genus ... with name Eeyore eating ". The same assignment could be done more attractively by pooh~name = 'Eeyore', and say pooh~name would produce "Eeyore".

Each class has a "methods" method that returns a list of methods for the class.

Directives, denoted by "::", split programs up into blocks to provide additional structure. (Control does not flow through a "::". Directives are processed first, and each denotes the termination of the previous block.)

There is a ::CLASS directive to define a class, e.g.: 

  ::class complex public inherit stringlike

The ::METHOD directive denotes the beginning of a method. For example, the "init" method (used for building a new instantiation) of the Complex class might look like this: 

  ::method init
  expose real imaginary
  use arg first, second
  real = first + 0
  if arg(2,'Omitted')
     then imaginary = 0
  else
     imaginary = second + 0

Use Arg has been added in Object REXX for passing objects as arguments; it provides essentially a call-by-reference capability. Expose is used to expose and create object variables within methods. It allows variables to be shared between methods and to persist between invocations of the same method.

To continue with the example above, an object of the Complex class would also have a "+" method that might begin like this: 

  ::method '+'
  expose real imaginary
  use arg adder
  if arg(1,'Omitted')
     then return self
  ...

"self" is new in Object REXX. It is a special variable that is set when a method is started (unless it is exposed). It is the value of the object against which the method is running.

Subclassing allows the definition of new classes that inherit the behavior of a class and add additional class-specific behaviors. For example, one might define the "Dog" class as a subclass of the "Animal" class. Then after the statement lassie = .dog~new had been executed, lassie~display might produce "Animal of genus Canis with name..."

Multiple inheritance is supported. Objects (and classes) may inherit from more than one class. In addition to a single parent class, an object may inherit from zero or more "abstract" or "mix-in" classes.

The special variable "super" is another that is set when a method is started (unless exposed). Its value is the class object of the immediate superclass. Thus, self~init:super would invoke the "init" method of the superclass and might be part of the "init" method for the subclass.

::method sound attribute creates "sound" and "sound=" methods.

There is an "uninit" method that is driven when the object is going to be garbage-collected.

Rick also described the concurrency that is built into Object REXX. All objects can execute concurrently. Coordination is achieved via the "start" message and the reply instruction.

The implementation of concurrency is not dependent on an underlying thread model; they have it running on Windows.

Tom Brawn (IBM), "Object REXX OpenDoc Support"

(Back to Table of Contents; on to next session).

Tom spoke briefly on the alignment of Object REXX with OpenDoc, which is an architecture for dealing with compound documents. (It competes with Microsoft's OLE.) It was developed originally by Apple. IBM is doing implementations for OS/2, AIX, and the Power PC. Word Perfect is doing an implementation for Windows. One will be able to write REXX scripts for OpenDoc "scriptable applications", such as Lotus 1-2-3.

Rick McGuire (IBM), "Other Fun Stuff"

(Back to Table of Contents; on to next session).

Rick spoke briefly about using Object REXX to write "network agents" that can be sent across a network to play games on a server and that can be implemented with no knowledge of networking. Thus, one has the infrastructure to provide client/server applications without changing the code in existing programs. He has implemented a scripted Web explorer using these techniques.

Brian Marks (IBM), "Report from the X3J18 Committee"

(Back to Table of Contents; on to next session).

Brian is the chairman of the REXX ANSI Standard Committee, X3J18. The Committee completed its document in 1994; the first public review ended May 3, 1995. The document is expected to be approved as an ANSI standard this year. The Committee continues in existance both for maintenance purposes and for further versions, including Object REXX.

The document was edited by Tom Brawn. It is 167 pages (including the informal parts) and is available from the REXX Web page, http://www2.hursley.ibm.com/rexx/.

The second edition of "TRL" (Mike Cowlishaw's book The REXX Language) was the basis for the standard. Brian commented that this first standard was not intended "to design a REXX for the Nineties", but primarily to standardize the current language. However, it does add date conversion, error subcodes, and command I/O to the language.

Brian also stated that the standard was not meant "to be the union of every existing implementation", but some accommodation for the requirements of different operating systems was made, such as allowing alternatives for negation and blank characters. (They didn't make it the union of all implementations, because they didn't want to confuse new implementations.)

Although the Committee made few changes to the existing language, it did not take a position of "better wrong than changed". They have "righted existing wrongs", but few programs should break, and they expect implementations to have a non-ANSI switch. The relatively obscure wrongs that are being righted:

Brian concluded by encouraging the attendees to encourage their REXX vendors to produce implementations that comply with the standard.

Sandy Syx (Mantissa Corp.), "CenterPiece: An Object-Oriented REXX Development and Runtime Environment"

(Back to Table of Contents; on to next session).

CenterPiece wins my prize for being visually the handsomest product displayed at the Symposium. One seldom sees such subtle use of color in GUI applications.

Mantissa Corporation specializes in software to automate computer operations. It has developed its own multi-threaded, object-oriented REXX for use in building its software products. Since this OO REXX has been developed completely independently of the IBM OO REXX, it was interesting to contrast the two approaches. The speaker, Sandy Syx (ssyx@mantissa.com), provided such complete foils that I think the best way to report his talk is simply to transcribe his foils:

CenterPiece Architectural Overview

What is CenterPiece?

CenterPiece Architecture

CenterPiece is Multi-platform

The Engine Is...

The User Interface

CenterPiece Built-in Classes

Fundamental Built-in Classes

Programmer's Helper Classes

Simple Visual Objects

Dialog Objects

Communication Classes

Object Storage to Disk

Application Delivery

CenterPiece Object-Oriented Extensions to REXX

Objects

Object Ownership

Attributes

Referencing Objects

Attribute Access

Object Attributes are selected with a double dot (..). 

                         object..attribute
   object identifier or, <======|======> attribute specification
   classname

The symbol to the left of the double dot is translated into a value. The translated value must be an object-id or a class name.

The symbol to the right (up to the next double dot) is treated exactly like a variable symbol and must reference an object or class member.

Attribute Access Examples

Object Creation/Destruction

Accomplished with two new REXX built-in functions: 

     object_id = ObjectCreate()
     rc = ObjectDestroy()
For example, 
     aLine = ObjectCreate( "Line" )
     aLine..x = 100
     aLine..y = 100
     aLine..x2 = 200
     aLine..y2 = 200
     ...
     call ObjectDestroy aLine

Classes

Inheritance Model

Dropping Attributes

The REXX Drop instruction can be used to cause an attribute to revert to its class default.

For example, assume that a class "Author" exists which has an attribute named "Name" that has a class default of "anonymous". 

   anAuthor = ObjectCreate( "Author" )
   anAuthor..Name = "Fred Brooks"
   say anAuthor..Name         ==> would print "Fred Brooks"
   drop anAuthor..Name
   say anAuthor..Name         ==> would print "anonymous"

Object-Related Built-in Functions

   ObjectCreate                   ObjectOpen
   ObjectDestroy                  ObjectOpenAsDialog
   ObjectClone                    ObjectClose
   ObjectFindOfClass              ObjectGoto
                                  ObjectGetOwner
   IsObject                       ObjectSetOwner
   IsObjectOfClass
   ClassOfObject                  ObjectFileOpen
   ClassIsSubclassOf              ObjectFileSave
   ClassIsDirectSubclassOf        ObjectFileClose

Iterating Over Objects

   DO   ; 
     END  ;

   repetitor (extensions):
     FOR EVERY class loopvariable
     FOR EVERY class loopvariable ON workspace
     FOR EVERY class loopvariable OWNED BY object

Example: Iterating Over All Objects of a Given Class

   num_employees = 0
   DO FOR EVERY Employee e
      SAY e..Name
      num_employees = num_employees + 1
   END

Object Member Iteration

   DO   ; 
     END  ;

   repetitor (extensions):
     FOR EVERY  MEMBER membervar
          OF object

Composite Objects

Embedded Objects

Methods

Self Reference in Methods

The double-dot with no prefix is an object self reference inside an object method. For example, imagine a user interface Button method that runs when the button is clicked: 

     /* begin Button..Click */
        ..Name = "Hello"
     return 0

In this example, the double-dot with no prefix means "this" button.

REXX Extensions for Complex Problems

Multi-threaded REXX

Unwinding the Stack on a Raised Condition

Normal REXX, strangely, doesn't unwind the call stack when a condition (exception) is raised. We extend the CALL ON and SIGNAL ON instructions to allow them to be prefixed with the keyword UNWIND. For example: 

     UNWIND CALL ON syntax NAME mysyntaxtrap
     . . .
     mysyntaxtrap:
        say "Tarfu"
     return

Developing CenterPiece Classes

Modularity

Constructors/Destructors

User Events

Mantissa Corporation
201 Summit Parkway
Birmingham, Alabama 35209
(205) 945-8930

John Tibbetts (Kinexis), "REXX, Distributed Systems, and Objects"

(Back to Table of Contents; on to next session).

Tibbetts addressed the current state of client/server technology and the reasons for the failure of so many client/server applications. I was reminded of the definition I'd heard recently of "second-generation client/server", i.e., "We'll do it right this time".

Tibbetts asserted that there is not an infrastructure on the planet that can implement an object-oriented, distributed, robust application, and that this is the reason why mainframe sales are way back up. He believes, however, that the necessary technology will be available quite soon. He also commented that most failures of "light-weight" client/server applications are due to a lack of understanding of the importance of function as an asset.

He divided the development of our industry into four phases:

The Four Phases of Computing

  1. Centralized computing (the mainframe)

  2. Clients to a Database Server

    This is what PC Week means by "client/server". Microsoft is a heavily Phase2-oriented company.

    Phase 2 applications tend to fail when they go to multiple sites or when they need multiple trust levels. Scalable performance is a problem. To optimize a distributed application, the function should be as close to the data as possible; Phase 2 applications are the opposite of that. Their goal is accessibility, not security.

    PC-class machines are metaphysically agents of the individual, not of the enterprise; whereas a 3270 terminal sitting on one's desk is an agent of the enterprise.

    Phase 2 C/S applications can work fine for work groups; they have the same kind of agenda. They can also work fine for departments, but not for the enterprise. They are not like down-sized mainframe applications; they are like upgraded PC applications.

  3. Clients to a Function Server

    This phase has fatter servers and skinnier clients. These C/S applications are bloody hard to build, but appropriate tools are beginning to come to the market.

  4. And Then There Are Objects

    The object is data surrounded by a protective layer of code. This may be viewed as a very fine-grained version of Phase 3; it has lots of small programs, but the interfaces are architected. This sort of C/S application is hard to do, because the infrastructure is profoundly function-oriented, rather than object-oriented. However, we will see the infrastructure for building high-integrity, robust application environments by the end of 1996.

Security and transactions never entered into the minds of the people who designed object technology. That function is now being added, and that is a big reason for not going to object technology too soon.

Acid Tests for Transactions

  1. Atomicity
  2. Consistency
  3. Isolation
  4. Durability

Most distributed object infrastructure today is not transaction-oriented. "I saw my first demonstration of OTS (Object Transaction Service) last week; this has Phase 4 transactional components."

Rick McGuire (IBM), "Getting Ready for Object REXX"

(Back to Table of Contents; on to next session).

Object REXX addresses many of the long-standing requirements against the REXX language, in addition to adding OO capability:

Simon Nash (IBM), "SOM: Present and Future"

(Back to Table of Contents; on to next session).

Simon is the original author of IBM's Object REXX, which he worked on for five years. He is now in SOM Development.

SOM, the System Object Model, is IBM's strategy for facilitating interoperability among OO languages. It defines interfaces that allow class libraries to be distributed in object form and to be used from languages other than the implementation language. This leads to release-to-release binary compatibility and the ability to distribute objects.

SOM is available today for OS/2, AIX, Windows, and Macintosh. It is announced for MVS and AS/400, and there are other ports in progress, including to other UNIX platforms. SOM support is available for C, C++, and Smalltalk. SOM support for Object REXX is in beta test. SOM support for OOCOBOL is announced.

Stephen Rondeau (AugmenTek), "Rexinda: A REXX Implementation of the Linda Parallel Programming Model"

(Back to Table of Contents; on to next session).

Rexinda is a REXX implementation of David Gelernter's Linda parallel programming model. (Gelernter named Linda for Linda Lovelace, as a play on Ada's having been named for Ada Lovelace; he is said now to regret this.)

Rexinda implements a Linda "tuple space" and REXX functions to put tuples into the tuple space, take them out, wait for a tuple to appear, etc. A tuple can be thought of as a database record. The tuple space is an unordered collection of tuples, possibly distributed over many processors. Thus, the tuple space provides an associative global data area for sharing of data at the record level among multiple processes. The ability to wait for the appearance of a tuple makes it simple for parallel programs to coordinate their progress.

Retrieving a tuple is done by matching on its contents by value, number of fields, datatype, etc. Updating a tuple is an atomic operation. An EVAL() function allows a Rexinda program to start a new process, which may then also access the tuple space.

Rondeau hopes that a REXX implementation of Linda will help popularize parallel programming, particularly because of the fast prototyping capability provided by REXX. His implementation manages not to require preparsing of the source. It does data-typing automatically, but allows for overrides. One of the interesting requirements was to make REXX handle user-defined events (i.e., data appearing in the tuple space).

He sees a good many parallels between the Linda model and REXX. Linda's associativity should be simple for REXX programmers to understand, being not very different from the way compound variables work in REXX. The tuple space is global, like the default scope in REXX.

Version 0.1 of Rexinda is available now for OS/2 and Amiga. Rondeau has plans for extensive enhancements, if there is sufficient market acceptance. Inquiries may be addressed to:

For more on the Linda programming model, Rondeau suggested How to Write Parallel Programs by Carriero and Gelernter (MIT Press, 1991, ISBN 0-262-03171-X).

Bob Vogel (IBM), "REXX for CICS/ESA"

(Back to Table of Contents; on to next session).

Vogel is an IBM application development manager from Dallas in charge of the group that produced the CICS REXX product.

He stated that 81% of the world's business transactions (on all platforms) are done under CICS on MVS or VSE. One of his motivations for producing CICS REXX was that he was expecting many VM customers to migrate to MVS, where they would wish to use their REXX expertise (and EXECs). IBM had received hundreds of customer requirements for REXX under CICS.

His first goal was to develop a strong productivity tool. The TSO/E REXX kernel served as the base for the interpreter. Added to that were REXX language support for CICS, a REXX-DB2 interface, and a native CICS application environment, including a text editor (with XEDIT and ISPF personalities), an interactive shell, a panel facility, a VSAM-based REXX file system, and file system utilities. The programmers in his group (mostly COBOL CICS programmers) have been amazed at their own productivity gains from using REXX. They believe that this gain has been on the order of 10-20 fold.

Vogel referred to a REXX CICS user experiences session presented at SHARE by Steve Ware, of the University of Florida.

Dick Goran (CFS Nevada, Inc.), "REXX Changes in OS/2 Warp Version 3"

(Back to Table of Contents; on to next session).

Goran is the author of the highly-recommended REXX Reference Summary Handbook and writes a REXX column for OS/2 Magazine.

I am too ignorant of OS/2 to attempt to reproduce his excellent talk; I suspect much of it will be found in forthcoming columns. His theme seems to have been taken from a line in his June, 1995, column:

The developers did a much better job designing the LaunchPad than the chroniclers did documenting it, as is typical of so many things in OS/2.
His talk revolved around determining how five new REXX functions added in Warp really work. The functions are SysCopyObject(), SysMoveObject(), SysCreateShadow(), SysSaveObject(), and SysOpenObject(). Fully understanding these new functions required lots of experimentation and help from his friends, because much that one needs to know is not documented. The new Third Edition of Goran's Handbook (ISBN 0-9639854-2-6) discusses the Warp additions.

Goran maintains an FTP/Web directory for distributing many of his OS/2 utilities at http://ftp.cfsrexx.com

David Salthouse (Open Direct), "S/REXX for UNIX"

(Back to Table of Contents; on to next session).

Salthouse is a former IBMer who now heads a software marketing company based in France. Among his products are S/REXX and SEDIT, which are REXX and XEDIT implementations for UNIX (for most of the important UNIX platforms, including AIX, HPUX, SunOS, Solaris, SGI, LINUX, Ultrix, etc.). SEDIT has a GUI interface; S/REXX includes a Motif-based debugger. Both were written by Robert Benaroya.

Salthouse commented that there is very little market for REXX in the UNIX world so far, because "we are not very good at explaining why REXX is good". His company is trying to use other products, such as SEDIT, to gain access to a vertical market. They now have a considerable number of customers, both commercial and university.

S/REXX is REXX 4.0 with the exception that the numeric digit specification is limited to 15. It includes full EXECIO support to facilitate the porting of CMS applications. It adds several built-in functions for the UNIX environment: CWD(), CHDIR(), MKDIR(), RM(), GETENV(), etc. UNIX(cmd,stem) issues a UNIX command and retrieves the result in a stem. Assigning a UNIX command enclosed in backquotes to a variable causes the result of the command to be assigned to that variable. User-supplied built-in functions written in C are supported; ADDRESS environments may be set up to allow C programs to retrieve and set REXX variables. In conjunction with SEDIT, S/REXX allows the building of MOTIF or OpenLook dialog boxes, with input fields, toggles, and buttons.

Martin Misseyer (Free University of Amsterdam), "A REXX-based Stock Exchange Realtime Client-Server Environment"

(Back to Table of Contents; on to next session).

Misseyer is an Assistant Professor of Economics at the Vrije University in Amsterdam, where he teaches decision support systems. The University had long had a portfolio simulation system called TRANSPAS, which began on a PDP11 in 1981. A key feature of the system was a real-time link to the Amsterdam Stock Exchange. The program was used to teach students about simulations and was also used by faculty members doing research, although the latter were in need of a more powerful database capability.

The simulation system, which was based on flat files and which was written in C, had evolved extensively over the years. In 1992, they lost the system it was running on (an IBM RT) and were left with tens of thousands of lines of C code that they decided would be too costly to port. (They did not have sufficient C experience, and they wanted a more sophisticated environment. The old program would also have required considerable reworking because the Stock Exchange had introduced a new trading system with a very different interface.)

A decision was made to move the system to SARA's VM system, rather than to a Sparc, and to do much of the reprogramming in REXX. On the VM system, they could set up a relational database containing all their data from the Stock Exchange and use it for both historical analysis and real-time simulation. After the rewrite was well under way, it was learned that the VM system would be terminated at the end of 1995, so the project is being moved to multiple platforms, including AIX and OS/2.

The client/server interface to SQL/DS that they had developed in REXX was ported to DB2/6000. OS/2 REXX programs were written perform the X.25 communications. They were able to port much of the code they had already developed on VM; in fact, they were able to move to the new platforms in only a few days. They found themselves using REXX for:

They are now working on a second generation of their simulation program using VX-REXX-based client/server function. Their future projects include a data extraction tool and a WWW server for the Stock Exchange with real-time graphical displays of the Stock Exchange index.

Misseyer's conclusions were:

He would like to see:

He recommended that portability issues be well understood during the design phase of any application that is likely to be ported between platforms.

Lois White (SLAC), "REXX and How I Hit the Ground Running in UNIX"

(Back to Table of Contents; on to next session).

Lois White, a long-time SLAC staffer (and long-time user of REXX), subtitled her talk "How I Learned to Stop Worrying and Love to Type in Significant Mixed Case".

Lois's primary responsibility is analysis of utilization and performance of SLAC's computers. Thus, she has had to make the move from VM to UNIX over the past few years. Since REXX has been her language of choice since the early Eighties, she was glad to find that most of her UNIX work could be done using Uni-REXX. (She finds the shells too weak and Perl too cryptic; a high priority is placed on producing readable code.) She has been using Uni-REXX since early in 1993 and recommends the Uni-REXX manuals as being particularly good for people making the transition from CMS to UNIX.

Lois was able to port her analysis skills readily. UNIX accounting data provided the information she needed, but there were no suitable reporting tools. She has developed what she needs, however, by using a combination of crontab entries, REXX, and SAS. With these, she has built a system to collect data, store them, produce (very handsome) reports, and do directory cleanup. She was able to port "lots of code" directly from CMS to UNIX. She is using the same techniques to analyze utilization of their network and telephone system.

RexxLA, The REXX Language Association

(Back to Table of Contents; on to next session).

The REXX Language Association is an independent organization dedicated to promoting the use of the REXX programming language. Membership information can be obtained from:

Membership benefits include a subscription to the Association's quarterly newsletter and a discount on REXX Symposium registration.

Attendee Announcements and Other Notes

(Back to Table of Contents).

Perhaps the best quip of the week was a reference to Perl as being "REXX done using only special characters".

Proceedings of the REXX Symposium are free of charge and can be ordered by sending email (including your postal address) to techpub@slac.stanford.edu. The Proceedings from the 1994 Symposium are still available; ask for SLAC Report 447.

Gabe Goldberg, co-editor of The REXX Handbook (Gabe Goldberg and Phil Smith III, eds., McGraw Hill, 1991, ISBN 0-07-023682-8), is thinking of putting together a REXX supplement for the Enterprise Systems Journal. (Gabe has been involved with earlier supplements.) His first task is lining up advertisers to fund the project; then he will recruit authors to write articles. He would like to hear from anyone interested in participating in this project. He may be reached at:

Another highly recommended new REXX book emphasizing OS/2 is The REXX Cookbook, available from:

The ISBN for the book is 0-9632773-4-0 and for the book with a companion diskette, 0-9632773-6-7.

Printing the Proposed ANSI Standard from CMS

I had considerable difficulty getting the PostScript file containing the proposed standard to print on CMS. It is rather oddly blocked (line end is indicated in some places by CR, in others by LF, and in others by CRLF), and the twelve segments are surrounded by PMPub (whatever that is) controls. I was successful in printing the document after uploading it in binary mode and running it through the following CMS EXEC and REXX CMS Pipelines filter to generate separate PostScript files for the twelve segments: 

/* FIXJ18 EXEC */

'PIPE (name FixJ18Pub)',         /* Make J18PUB CMS printable.  */
  '< j18pub binps |',            /* Read binary PostScript.     */
  'xlate a2e  21 5a  5b ad  5d bd  7c 4f', /* Make it EBCDIC.   */
             'a2 4a  a8 bb  ac b0  dd ba |',
  'deblock crlf |',              /* Deblock.                    */
  'split at anyof x0D25 |',      /* Deblock some more.          */
  'putj18'                       /* Break up into segments.     */

/* PUTJ18 REXX:   Break off pieces of J18PUB  */

Signal On Error

Do n = 1 by 1                    /* Do until end-of-file.       */

  'PEEKTO'                       /* Exit at end-of-file.        */

  'CALLPIPE (name PutJ18)',      /* Break off segment of file.  */
    '*: |',                      /* Input from calling pipe.    */
    'drop first 1 |',            /* Discard "userdict /PMpub".  */
    'tolabel userdict /PMpub|',  /* Up to the next segment.     */
    'drop last 1 |',             /* Discard "PMpub` restore".   */
    '> j18pub ps'n 'a'           /* Write this piece to disk.   */

End

Error: Exit RC*(RC<>12)          /* RC = 0 if end-of-file.      */

Melinda Varian / Office of Computing and Information Technology / Princeton University / maint@pucc.princeton.edu