Re: [netrexx-pipelines] Migrate OS/2 pipelines to NetRexx Pipes

[<hp...@we...>]

((Reply to a mail I missed))
>> So once more without the ZIP -- René, IMO you got it in your
>> personal mail, holler if not.
>>
> I have it.

Good. So you may take a closer look to the files VilMA uses or the
description of a "session". Probably this gives a bit more insight
than the bare REXX code only.

I skip all "documentation" related issues, I know it's not easy to
find a description level that fits for a non-uniform target group.

> I would suggest to use ’nrws’ (the Netrexx Workspace) for experiments with pipes.

'Netrexx Workspace' is neither mentioned in the NetRexx QuickStart
Guide nor in NetRexx Language Reference, there is a chapter about
it in NetRexx Programming Guide and one in NetRexx Pipelines Guide
and Reference. In that case I assume the Pipelines Guide will show
supplementary information only and all fundamentals about /nrws/
are in the Programming Guide where I start. BTW, since decades on
VM/CMS now with ooRexx, I use a very simplest "type REXX on the
command line" tool, consisting of just three lines:

> /* interactive REXX */
> trace '?R'
> address ''

Until I know how to run this with NetRexx I'll use 'nrws' -- which
shows something daunting at first try:

> nrws> say hello                                                        initial 1
>  2 +++ say hello;
>    +++     ^^^^^
>    +++ Error: Result of this expression cannot be just a type; it must have a va
> lue

This contradicts REXX principles of primary importance, at least
from my point of view. Fortunately we'll replace only the
pipelines, not the REXX dialect.

BTW, the nrws description uses every now and then the term "home
directory", once even "top level home directory". May I assume
this is the same as I set at some point during installation
procedure in the NETREXX_HOME system variable (and the top level
home directory to be the same)?

Now I slooowly start to grasp, what you sent recently had been
screen shots of a nrws session:

> ➜  test git:(master) ✗ cat varset.nrx
> vars =''
> address pipe with output stem vars
> "< vars.ini | nlocate 1 /*/ | cons"
> do i=1 to vars[0]
>   say vars[i]
> end

...and so on. Did you read along "the Book" about varset at
http://vm.marist.edu/~pipeline/pipeline.pdf ?
I know it's dated, but -- hobbyist I am -- I'm removed from
Pipelines evolution ever since the Runtime Library Distribution
was updated for the last time.

The comment for the pipe in line 94 of VilMA.rx is a silent hint,
that the nlocate stage is only necessary because OS/2 Pipelines
does not offer the COMMENTS option of varset.

> So that does more or less what you want already - the source redirect <, the nlocate works. If you want we can make a varset stage, I think we don’t have that at the moment but it cannot be too hard.

No, we should go all-in, if NetRexx Pipelines does not have a
varset stage yet it is a good test (for me to learn and for
NetRexx to point out) how to add those 'on the fly', analogous to
CMS Pipelines (filetype REXX). varset is almost something like

signal on error
do forever
    'READTO record'		/* don't mind delay */
    parse var record sc +1 vn (sc) sv
    if pos(sc, "* ") > 0,	/* see the COMMENT option */
     then iterate
    upper vn			/* optional, see also varload */
    dummy = value(vn, sv, ...)	/* for variable pool of caller */
end
error:; exit rc * (rc <> 12)	/* or whatever rc is OK */

Well, I hope NetRexx Pipelines allows home-made stages like this.
Maybe this "take in INI file" pipe could then look something like:

NetRexx Pipe "<" fn "|varload symbolic"

(see the differences in the defaults of varset and varload.)

Best,
M.