[comp.lang.rexx] REXX for Unix

ets@wrkgrp.uucp (Edward T Spire) (10/23/90)

I have been asked to forward these comments on Jeff Lankford's recent
posting regarding REXX in the Unix environment, so here it is...

------------------------------------------------------------------------

From uunet!HDEDH1.BITNET!NADWL Mon Oct 22 06:21:48 1990
Return-Path: <uunet!HDEDH1.BITNET!NADWL>
Received: from uunet.UUCP by wrkgrp (4.0/SMI-4.0)
	id AA10104; Mon, 22 Oct 90 06:21:47 CDT
Received: from cunyvm.cuny.edu by uunet.uu.net (5.61/1.14) with SMTP 
	id AA17112; Sat, 20 Oct 90 21:12:06 -0400
Received: from HDEDH1.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) w
Received: from HDEDH1.BITNET (NADWL) by HDEDH1.BITNET (Mailer R2.07) wit
 id 3023; Sun, 21 Oct 90 01:02:26 SET
Date:         Sat, 20 Oct 90 23:41:37 SET
From: Scott Ophof <uunet!CUNYVM.CUNY.EDU!NADWL%HDEDH1.BITNET>
Subject:      Re: Cross posting from Comp.lang.rexx re:  Why REXX in Uni
To: Ed Spire <ets@wrkgrp.com>
Message-Id:   <901020.234137.SET.NADWL@HDEDH1.BITNET>
In-Reply-To:  Your message of Mon, 8 Oct 90 10:02:40 CDT
Status: RO

On Mon, 8 Oct 90 10:02:40 CDT Jeffrey P. Lankford said:
>A while back I cross posted a question from Comp.lang.rexx regarding
>why in the world anybody would want or need REXX under Unix.
>Here's the summary of the private discussion that was recently posted
>to Comp.lang.rexx, which I am cross posting without comment at this tim
...
>Third, there is a Unix REXX discussion list titled Unix-REXX and
>available through Usenet i believe.

The BITnet discussion list is called UREXX-L, and lives at
LIVERPOOL.AC.UK (I take it this is what you mean, Jeff).

>...
>	kill $SIG `/$HOME/bin/pick \`ps -ag | egrep "$*"\` | awk '{print $1}'`
>(:-) There's a smiley here - did everyone see it?                 --
  ===
If you mean the underlined with "=", yes.  But it's the form for lefties
so can I assume the part underlined with "--" reverses it to "normal"?


>3) Good debugging facilities.
>I agree, if TRACE is a standard part if REXX.  Although sh(1) and csh(1
>have something similar, they aren't nearly as flexible.

TRACE is a standard part of the REXX language definition as M.F. Cowlish
defined it.  No idea what the Amiga implementation does re TRACE.


>4) Some users want to move (REXX) applications from CMS to Unix without
>   major reprogramming effort (or any effort at all).
>
>I don't buy this one at all.  The cost of using environment Y effective
>must be accounted for when justifying moving an application from
>environment X to environment Y, or it implies that the environment is
>irrelevant, in which case why move?  Also, almost any interesting or
>sophisticated application is going to invoke system commands (to copy
>a file or some such action); unless all such commands are supported
>as part of the REXX run-time environment, the code will have to be chan

Example:  We have a number of applications running both on PCs and our
VM/CMS system, built in REXX.  Any really opsys-dependant stuff is invok
as external subroutines (which may be of course built in any language).
Like a SetColor routine I know of in one of those calls the relevant
system-dependant program called SetColor on the opsys where it's invoked
REXX also has a PARSE SOURCE instruction, which returns (among other thi
the name of the opsys (CMS, DOS, HPUX (Ed, please correct this if needed
etc.).  So with PARSE SOURCE one can quite easily build opsys-dependant
code.  We will probably port the above mentioned applications to UNIX, s
the PARSE SOURCE will definitely come in handy there.  Of course some
re-coding needs to be done, but there's a large chance it won't be the s
as completely rewriting it...

The idea of including system-dependant system commands in a language see
ludicrous to me.  Personal REXX for MS-DOS did it, but then most PC stuf
includes *even* the kitchen sink in an effort to bypass DOS.  My persona
opinion re PCs is that if programmers adhere to this kind of thinking, t
DOS is already dead, but doesn't realize it yet...


>Besides, you have to know (a little) something about Unix to run a Unix
>REXX interpreter.  Replies > /dev/null.

This is self-evident of course, and I never argued for "REXX as a replac
ment for UNIX".


>One an interesting line of discussion might be: what techniques
>can be applied to minimize and/or isolate environment dependencies
>of REXX programs?

Partly answered above, but more specific here:
 - Using PARSE SOURCE, determine the opsys, and call a (maybe external)
   subroutine to collect the various other programs needed into memory
   (EXECLOAD and NUCXLOAD for CMS, no idea for other opsyses).
 - Again with the help of PARSE SOURCE, hard-code the necessary stuff (i
   not possible otherwise, or so small an external routine is overkill).
 - Call an external subroutine for stuff which is known to be system-
   dependant.  Thus any change in a specific opsys can be quite easily
   taken care of.
 - The subroutine could be internal, but that means rebuilding the whole
   thing any time some (maybe small) bit is changed.

Note that *external* subroutines are viewed as if they were system-comma
and don't need to be included (can't even be!) at run-time.  Neither can
they be included in a compiled version of REXX.  Note that I'm not talki
about internal subroutines, and the same goes for (user-written) functio

I agree that any program ported to another environment will need to be
changed.  Any programmer *really* worth his title & salary will probably
have set up his program such that structured and modular thinking can be
used on it, thus making porting easier.  At least identification of opsy
dependancies should be present, and preferrably isolation where possible


>...
>5) Extensions to REXX to better couple into the Unix environment are
>   possible (have been or can be done).
>Now this could be an interesting topic of discussion; e.g., what generi
>language extensions to REXX should be adopted to provide more powerful
>and flexible interaction with the environment in a portable manner?
>For example, a common environment dependent application need is:
>from a REXX script, execute any arbitrary command and on failure recove
>an error diagnostic code or message, while on success capture command
>output into a REXX variable.

In CMS the "return code" of any command pass to an external environment
*is* passed back to the REXX variable RC.
The REXX DIAG() function (CMS REXX only) can be used to return *any* dat
resulting from a CP command.  Thus no need for EXECIO, although it can d
stuff DIAG() can't (like stuff each separate line returned into an array
>From your posting I get the impression you didn't know of the existance
the DIAG() function.  Please correct if wrong (and why).


>In the VM environment, this CANNOT be accomplished in general
>(this is a defect of VM, not REXX).  However,
>the following cases can be accomplished: the CMS EXECIO command can
>be used to capture the output of any CP command (may be a diagnostic
>message if the command failed and CP has SET EMSG ON); for CMS commands
>output can only be captured on the stack and only if the command
>specifically supports the STACK option (most commands don't).

One could also spool the console output to a file, and use that to trap
whatever was necessary.  The nice thing (as *I* see it!), is that system
commands can be used to trap stuff.  And now that CMSPIPES is available,
spooling the console isn't even needed anymore.  Again, I want to stress
the point that REXX is extremely INDEPENDANT of the opsys!


>...
>stream I/O re-direction, not to mention pipes (i thought i told you not
>to mention them.).

*grin*


>...
>6) Some users have large applications doing numeric computation in REXX
>   and they ...
>.. were born to suffer.

NOT where it concerns sparse arrays!  That's where REXX certainly shines


Regards.
Scott/