REXXwishes


Mailbook Everywhere!

This month's first subject is that great MUA by Richard Schafer called "Mailbook", which runs on IBM/S VM/CMS operating system. ("MUA" stands for "Mail User Agent", meaning the application used to read, write, sort, and index your email.  To actually send and receive email items, an MTA (Mail Transfer Agent) is used;  they usually work in the background, ie. invisible to the user.)

Mailbook is an application that originated in the VM/CMS world as a set of Rexx macros built around the IBM editor called XEDIT.  Anyone used to XEDIT has little - if any - problem using Mailbook, because almost any application in the the CMS world will use the XEDIT editor.  (Yes, there is also the ISPF editor; for all practical purposes it is a rather close relative of XEDIT.)

Since Mailbook was written in Rexx, it was - and still is - quite easy to write modifications for by most any CMSer familiar with Rexx.  Users can also (re)configure Mailbook with their own preferences.  The configuration options span a huge range of possibilities.  Mailbook also makes use of the CMS NAMES utility, which is the CMS equivalent of an addressbook on a PC.  Although that is not doing NAMES real justice; NAMES is actually a free-form database and can be used for much more than just addresses.  In combination with Mailbook it does things like expanding nicknames to full names and email addresses, automagically filing both sent and received items in the relevant mailbook (folder, notebook file), and so forth.

Many people who have had to migrate from CMS to other platforms have been quite unhappy at not being able to find a MUA that can do what Mailbook can so very easily do.  First of all, the interface of non-CMS MUAs is so very different from Mailbook, because none are based on XEDIT.  Second, no editor works like XEDIT - except uni-XEDIT, Kedit and THE (The Hessling Editor).  Even if one can use one of those three editors, the MUA itself has a completely different interface and command structure.  And is simply not as configurable as Mailbook.  Third, no database seems to be usable in the same way as the CMS NAMES utility (actually often replaced by LNAME).

Wouldn't it be nice if Mailbook (and NAMES or LNAME) could be ported to other operating systems?  Of course one of the problems (if one can call it that) is that XEDIT and NAMES/LNAME are totally command-line oriented.  But with the introduction of PETs (Pointer Enabled Tools) by Rick Ellis, Mailbook could be accessible to those who prefer using a mouse - as long as they are using a PC with 3270 emulation.  Could be accessible, since some work needs to be done to Mailbook to make it easier for PETs to work together with it.

Of course the above solution only takes care of a subset of those wanting to continue to use Mailbook.  So a version of Mailbook capable of running in any IBM mainframe opsys, Windows, Linux, Unix, OS/2, Amiga, MacIntosh, or even DOS would be a most welcome thing, methinks.  And since Mailbook is written in Rexx, it should be quite portable.  And for those who wish it, Kedit supports the use of a mouse, I think uni-XEDIT does too, and I'm not sure of THE, but wouldn't be surprised if it did.  All these editors in the XEDIT family are aware of at least one implementation of Rexx, and are available for more than one environment (except uni-XEDIT/REXX, which covers only the Unix environment, IIRC).

I have written my own (very meager!) subset of macros to emulate Mailbook on my PC, and still am often amazed at how easy it is to (re)configure and use my word-processing macros with it.  It has led me to one large change in mindset; Mailbook's index of items is a separate file that is saved between sessions.  When saving, moving, or deleting anything, the actual mail item is processed, necessitating an update of its index file.  In my "MRexx" subset of Mailbook, only the relevant line in the index file is deleted or moved to another index file.  The notebook files themselves are not touched at all.  The items referred to in an index file may be - ARE - spread out over various notebook files.

Anyway, "all" we need to do is convince Richard that porting Mailbook _IS_ worth the effort, find a group of people willing to assist Richard Schafer in the porting work, and help them all where possible with - for example - beta test-sites.  This should be a piece of cake for those of us dedicated to making applications work the way we users want them to.  <grin>

Rexx Compliance Test Suite:

In this, the second subject, I'd like to address the need for a suite of compliance testing software for Rexx implementations.  No such suite of tests exists, as far as I know.  The ANSI-Rexx standard presumes - like many other standards - that the implementor of a Rexx interpreter or compiler will see to it that their version conforms to the standard.  Or conforms to some - possibly not even mentioned - degree.

Users of some Rexx implementation run into problems when they discover - to their negative surprise - that that Rexx does not do what they expect.  If that Rexx version is their only experience with Rexx, they might think that the erroneous way is how it should work.  So the error can remain unknown for quite some time.  Even the implementor(s) of that Rexx version may not even know of the error; nobody is perfect, after all.  :-)

My hope is that there are people out there who will write testing software that exercises some part of Rexx in two ways:

  • What Rexx should do.
  • What it should not do.

And will submit their test program to some central point where it can be reviewed and checked for completeness.  The REXXLIST mailing list could function as such a central point, and I'm confident that there are enough very knowledgeable people there who know what to check for.

A test program need not test all of Rexx, just some part(s) of it. Nor would I expect an exerciser for classic Rexx to be useable in testing  - let's say - a NetRexx implementation.

After such an exerciser has been passed, it could be made available from a central point like the RexxLA website, for anyone who wishes to check the Rexx they are using, implementing, or updating.  Such a test suite would also be very useful for magazines reviewing some version of Rexx.

Let's hear from you, the reader.  Send your opinions and ideas to the RexxLA list, REXXLIST, or email us here at the newsletter for inclusion in the "Parse Readers" column.

Windows Scripting Host?  NOT!

Hey!  MS has something called the "Windows Scripting Host"!  And it's supposed to help you make macros for your applications! No, that's wrong.  If you want to just glue a few applications together (like invoking MS Word, where you write something, and then get it printed without needing to give the print command), you use the Active Scripting utility.  Or finding all the ".TMP" files and deleting  them.

If however you want to write macros for use within (say) MS Word, then you use VBA (Visual Basic with the Windows Scripting Host).  But WSH does not support the use of Rexx.  Only VBA, Perl, and something else that I don't remember.  It turns out that getting Rexx supported by WSH costs real money, and not just a few dollars.  The price is in the six figures, I was told...

An alternative is to write the Rexx macros needed to make the Xedit-like family of editors (Kedit, THE (The Hessling Editor), etc.) work like the editor you prefer (be it Word, WordPerfect, "vi", etc.).  Then you can use your preferred editor or word-processor, and still use Rexx to write your macros...

This concept is not limited to editors and word-processors.  The Xedit family can easily and neatly be used as display and input mechanism for almost any kind of application; email programs, databases, spreadsheets, web browsers, you name it!  One can also (re-)define the commands to be the same as in other applications, making it easier for the user to remember a command, due to the lack of difference.

The configurability of the Xedit family is so vast that I personally can see no true limits.  And methinks one could also devise some generic form of Rexx macro that allows the user to use some other language as macro language.  The one generic Rexx macro would be the transfer mechanism for data and commands to/from the macros written in the language you choose.

You think something like this would cost you in speed?  I think it won't.  But if it does, it won't be much.  And that would be more than offset by the increase in ease-of-use, in being able to use the same commands as in any other application. My contention is that you as user are keeping the effective speed down, mainly due to needing to remember where specific functions are located.

Let's say you use your web browser more than anything else, and are used to some function being clickable just to the right of top-center of the tool bar.  But that same function is in the left-most menu of your data- base, two levels down.  If you can reconfigure your database to put that function where you want it, you need not remember a different location, so you will be able to work more easily, and certainly faster.

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