ANSI X3J18 Rexx Standardizing Committee, Nov. 1998 Notes


The minutes of the November meeting of the J18 committee standardizing Rexx will be made public when they are approved.  Meanwhile, here is an informal account.

The people at this Dallas meeting were Mike Cowlishaw (keeping us to the true spirit of Rexx), Chip Davis (our RexxLA leader), Kurt Maerker (from IBM's major Rexx product development in Germany), myself as non-voting chairman, and Pam Taylor (who heads the SHARE activity for REXX).  Given that the costs and difficulty of meeting keep the numbers down (for example the originator of Object Rexx, Simon Nash, was unable to attend), I would claim that these are the best people you could have to bring knowledge, influence, and experience to the job.

When the first standard was completed we thought the job was to draft a second standard along the lines of Object REXX.  The later emergence of NetRexx has given us two flourishing lines - the Object REXX users who want to exploit the system features of particular systems and the NetRexx users who want to exploit Java.  The committee has addressed, and largely solved, the technical issues in drafting a standard to cover both of these, but that is not sufficient.

It is not really a tenable position that there are vendors eager to implement a second standard encompassing the latest Rexx family.  The situation may change again, as it was changed by NetRexx, but for the moment the committee is recommending that its work drafting a second standard should stop.

This leaves the committee with a role in maintaining the first standard and another set of roles that arise because just because the meeting is a good opportunity to exercise them.  (Only the maintenance of the first standard will be under the control of the body, known as NCITS, which ANSI authorizes for the development of programming language standards.)

Some of the other roles are:

  1. Advice to implementors about language for Rexx extensions (eg. the meaning of the extra arguments recently allowed on the DATE builtin function).  This is now an activity in its own right, irrespective of "designing the next Rexx standard".  In recent years, with the concentration on standardizing what exists, the committee has not kept lists of "desirable extensions".  This may change.
  2. Writing formal definitions.  Although no longer needed as part of a new standard it is valuable to have such definitions of NetRexx and Object Rexx.
  3. Advising on the general trends of where Rexx programmers are operating and of their needs.  Also about Rexx technologies and their best use, for example using Rexx in conjunction with a "scripting host".  (A general merge of SHARE, RexxLA, producers and experts views)
  4. Dissemination.  With less to do in constructing a new standards draft we may find the committee more willing to spread information via, for example, the web.
  5. There is a potential for a "Rexx Compatibility Kit" analogous to the "Java Compatibility Kit" for testing products.  You may be surprised that this is not a standards activity, but in fact NCITS does not involve itself in testing conformance - it relies on producers who make claims doing their own testing.

At this particular Dallas meeting the main technical points of interest were:

The IBM proposal for a BigDecimal class for arithmetic is on track to eventually become part of Java.  This proposal is essentially the ANSI Rexx arithmetic.  (BigDecimal supports varieties of rounding, does not support FUZZ.)  This closeness of ANSI Rexx with Java highlights the differences between them and the arithmetic in some products.  (I expect there will be a detailed account of these differences in another report to this site.)

Discussion of the semantics of the keyword REQUIRED in Object Rexx led to the separation of two concepts:

  1. The ability to specify that a REQUIRED file should not be loaded if it has already been fetched to memory.  (This is functionally significant because the code at the start of the file is executed each time it is loaded.)
  2. The ability to group distinct files into a "package" and share names across just that package.

It was decided that the PACKAGE keyword was best reserved for a possible extension covering the second concept.  The LOADONCE option could be provided as a word on the existing OPTIONS statement; the OPTIONS statement would have to appear at the beginning of the file.  The keyword NORELOAD is a better choice than LOADONCE since it allows for the opposite, RELOAD, more obviously.

The next meeting will be April 30 in Jacksonville, i.e. just before the next Symposium.

Brian Marks, Formcroft@compuserve.com