The Neutralizing of Rexx


Porting is a pain in the rectal area.  It should not be so painful, nor so consuming of resources and time.  There should be an easier way.

There is.  In never-never-land at the moment, though it should be possible to bring relief to the many programmers saddled with this seemingly never- ending Job's task.

Think of the problem this way for a moment.  You have a program that does something in some environment, like reading some files, extracting bits here and there, and writing out some new files.  The routines that do the extracting and preparing of the new files is the same no matter what opsys you're using at that moment.  (Hang on a moment, ASCII/EBCDIC-shouters.)  When you want to port this program from opsys A to opsys B, then you need to change all the stuff related to input and output, the verification of file-(non)existance, etc.

So what we need is a program that discriminates.  A program that first of all removes all the opsys-dependant I/O stuff, putting that stuff in some external routines and using standardized names for those routines.  Second, any call to the opsys is "suspect", in that it may not be the same command, spelling, or syntax on any other opsys. Third, you may be making use of implementation-specific Rexx instructions or functions. Fourth, there are the calls to external site-specific functions. Fifth, you may well have your own personal external routines/functions.

There may not be much left of the original program after the above cutting and pruning.  Nearly nothing, if you used lots of opsys-specific stuff. (Somebody should be muttering "NetRexx" at this point...)

How in tarnation can that discriminating program know which is what? Well..  It could make use of the following items:

 1: This (proposed) standard for an "opsys-neutral" format for Rexx.
 2: A file with all the commands for this opsys (version).
 3: A similar file with site-specific external functions.
 4: The same for all things pertaining to that system's I/O model.
 5: You could specify a file naming your own external routines/functions.

Since that neutral format knows *nothing* about specific opsyses, lots of stuff can be externalized.  HAS to be externalized is more correct.

I want to squash *right* *now* any thought that I'm advocating a subset of Rexx as base for this neutral format.

It isn't really within their scope, but definition of that neutral format would be a very nice project for the ANSI X3J18 Standards committee. They could cleanly define which type of thing doesn't belong in a truly portable Rexx program.  Where those things should go, and how they can be resolved cleanly could become a set of recommendations defined by some taskforce set up for that goal.

Don't ask me exactly how to solve the above, nor why I didn't think of this, that, and the other.  My wish is for the porting exercise to become a truly easy thing to do for any programmer willing to program cleanly.  As to possible ASCII/EBCDIC-problems, well...  They would cease to exist, right?  (Skepticism is allowed, nay, it is _mandatory_...)

A step in the right direction might also be for people who have so-called "Rexx skeleton files" to gather together and hammer out the basics for a truly portable version thereof.  Do I hear someone suggest the creation of a mailing list or newsgroup for that purpose?  Or does such a list/group already exist?

Until we meet again, port in peace...  :-)

$$/
F. Scott Ophof (editor), Newsletter@RexxLA