Xref: utzoo comp.sys.amiga.tech:164 comp.sys.amiga:17108
Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!amdcad!amdahl!kim
From: kim@amdahl.uts.amdahl.com (Kim DeVaughn)
Newsgroups: comp.sys.amiga.tech,comp.sys.amiga
Subject: Re: AREXX the low/medium level standard - NEXT THE HIGH LEVEL
Message-ID: <26156@amdahl.uts.amdahl.com>
Date: 1 Apr 88 10:22:35 GMT
References: <8647@eddie.MIT.EDU>
Organization: Amdahl Corporation,  Sunnyvale, CA 94086
Lines: 56
Keywords: Read me if you want to influence an existing commercial product.
Summary: I see a de facto standard in the making ... i.e., current practice!

In article <8647@eddie.MIT.EDU>, gary@eddie.MIT.EDU (Gary Samad) writes:
> I would like to point out that there already exists a low and medium
> level standard that is sufficiently powerful to mediate conversations
> between applications and provide control mechanisms - AREXX!  ARexx may not
> be THE perfect solution (I personally have some problems with the
> language syntax), but it does meet the 'sufficiently powerful' test
> by being fully programmable and allowing the passing of ANY data in
> ANY format between concurrently running applications.
>
> It has another overwhelming benefit:  it exists TODAY as a commercial
> product with the support of Bill Hawes, ace programmer!  This alone
> carries great weight with me, a commercial developer with a commercial
> product longing for this type of interprocess communication and data
> transfer.

Exactly.


> It is more than longing, though;  the code to support ARexx is going
> into Microfiche Filer II even as we speak!

Glad to hear it!


> [ ... ]
>
> In the rexx system, communication is not symmetrical.  Programs can
> invoke macros and macros can command programs.  However, programs cannot
> command macros (other than by passing parameters upon startup or by
> responding to a message from the macro).

Ah, but they *can* control further execution of the macro with a well thought
out return-code/error-code handling strategy (as you mention later in your
posting).  I simply want to amplify what you said a little ...

In addition to passing a simple return-code back to the macro (which is often
all that's needed for processing control), the host program can also be
instructed to pass back result *string*.  This allows even greater flexibility
and a more sophisticated level of control of subsequent macro execution.

This can be accomplished via the RXFB_RESULT modifier bit in the command code,
with the host program then returning a pointer to an ArgString in rm_Result2.

Naturally, all this must be thought about ahead of time, and must be designed
into the system in the first place.  This is why error/exception/result processing,
and reporting is so fundementally important to take full advantage of the ARexx
interface.

/kim


-- 
UUCP:  kim@amdahl.amdahl.com
  or:  {sun,decwrl,hplabs,pyramid,ihnp4,uunet,oliveb,cbosgd,ames}!amdahl!kim
DDD:   408-746-8462
USPS:  Amdahl Corp.  M/S 249,  1250 E. Arques Av,  Sunnyvale, CA 94086
CIS:   76535,25