Article View: comp.sys.amiga.tech
Article #8403Re: AREXX the low/medium level standard - NEXT THE HIGH LEVEL
From: Kim DeVaughn
Date: Fri, 01 Apr 1988 10:22
Date: Fri, 01 Apr 1988 10:22
57 lines
3055 bytes
3055 bytes
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
Technical Details
Message-ID:
<26156@amdahl.uts.amdahl.com>Path:
arc1-ca.pugleaf.net!utzoo!mnetor!uunet!lll-winken!lll-tis!ames!amdcad!amdahl!kimReferences:
<8647@eddie.MIT.EDU>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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!