Re: [netrexx-pipelines] Ad ooRexx scopes, ... (Re: Migrate OS/2 pipelines to NetRexx Pipes

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

Hello Rony!

Am 12.06.2022 um 12:39 schrieb Rony G. Flatscher:
> many questions... :)

Sorry, but because ooRexx 5.oo is still Beta I installed it on a
spare PC without mail system, so the questions piled up.

> Firstly one thing you should know: ooRexx is backwardly compatible
> with Rexx, this way one can develop and run classic Rexx programs
> including the Rexx scoping rules (which variables and labels can
> be seen from which part of a Rexx program).

That's for me the most important characteristic of ooRexx -- and
NetRexx from 4.04 on will also offer 'old-school' REXX, René said.

> Ad ooRexx scopes (from my slides):
> [...]

Thank you very much for this complete and concise overview, my
description was limited to variables only. Maybe I should review
all my published REXX programs with your "scopes cheat sheet"
besides the PC.

> ---
> [...]
> ooRexx directives are not available to NetRexx and will cause a
> syntax error.

Thus I can't use BsfContextVariables() in a stage of filetype NJP
which is to be translated by PIPC. Consequently I need another way
to put (or push) records from the pipe to something (var, array,
...) within ooRexx.

> ---
> [...]
> You can include BSF.CLS (which loads all external BSF4ooRexx
> functions and establishes the camouflaging support such that
> strictly typed Java classes and Java objects can be interacted
> with as if they were dynamically typed ooRexx classes and ooRexx
> objects) in two ways:
> [...]

Ok, I would go with the second possibility you mentioned,
> ::requires BSF.CLS
but since this is impossible within the "DIY" stages, I may only
set it in the ooRexx program which starts a NetRexx pipeline.

> BsfContextVariables() allows one to get all currently defined
> variables as a directory (index is name of the variable, item the

Wait a moment, I need Java (BSF.CLS is concealed Java, isn't it)
to get the variable pool of a running ooRexx? -- Oops, gotcha!
Honestly, you got me: exactly as on VM/CMS I use on the PC too the
stage REXXVARS which is part of OS/2 Pipelines too.
> Pipe rexxvars!> prgm.ini
and I have a file with current variable pool saved for a future
session to be used by Pipe < prgm.ini!varload -- simple as that.

> current value) for which in the meantime alternatives exist
> (.context~package~variables).

That's ooRexx 5.oo exclusively, I assume.

> BsfContextVariables() allows you to set multiple Rexx variable in
> the scope where you invoke it, if you supplied a directory with
> all variables that should get defined. For this usage I would
> suggest BsfContextVariables().

With pleasure, if NetRexx could deliver that directory in
question. But! - sorry for still not being convinced -- if I have
a directory in ooRexx, aren't there other, actually
better/faster/leaner processes to set the variables in accordance
with the directory?

> ---
> Ad fetching data from external sources. ooRexx 5 gained the
> ability to use the ADDRESS keyword instruction to redirect stdin,
> stdout and stderr from/to ooRexx if desired. To do so you define
> what collection you want to use from ooRexx, e.g. a stem or an array.

That is only possible within ooRexx 5.oo, which will remain for
some reasons in Beta further on.

> Not being familar with Netrexx pipes here a hypothetical pipe
> where the data comes from Rexx and the result is piped into Rexx
> again. So please excuse if the following pipe is syntactically
> wrong, but I think you get the idea:
>
>     command='pipe console | sort | console' -- intensions read
> from the console, sort, output to console
>     arrIn =.array~of("Max", "und", "Moritz", "diese", "beiden",
> "konnt", "...")
>     arrOut=.array~new
>     -- command gets input from ooRexx' arrIn, places stdout into
> arrOut
>     ADDRESS SYSTEM command WITH INPUT USING (arrIn) OUTPUT USING
> (arrOut)

That looks like temporarily redefining stdin and stdout for
command calls.

>     -- now we need to postprocess the data received from the
> NetRexx pipe

Post-processing? -- well, I should restrain from malicious glee or
schadenfreude because highly likely NetRexx Pipelines was not
designed to work with ooRexx as smooth as Pipelines on VM/CMS.

>     -- assuming that each line is in the form of "varName=varValue",
>     -- lines that start with an asterisk (*) get ignored
>     -- create a directory of varName/varValue entries
>     dir=.directory~new
>     do line over arrOut -- process output of pipe line by line
>          parse var line varName '=' varValue
>          dir~setentry(varName,varValue)  -- setentry will
> uppercase the index varName automatically
>     end

Rony! that's a good idea, thank you. Since this first pipeline of
VilMA.rx (with more than 20 others waiting for migration) consists
solely of two stages, i) reading INI file from disk, ii) set vars
accordingly, _and_ the need of post-processing the pipe's output,
it appears as if it's much simpler (in that artless case) to do
entirely without pipe. The remaining are still good candidates for
NetRexx Pipelines, worth to apply the a. m. drudgeries.

>     -- now you decide what do to with the directory:

In this case the decision is taken, next pipe to migrate is now:
> call RxPipe '< "' || .constDir[VMD_LILOC] || .constDir[VMD_TYPCP] || '"!stem tycap.'

Hmm... no, that looks quite similar like the first case, so this
one too I will not convert to NetRexx Pipelines. But the third
pipe is worth it:
> call RxPipe '< "' || fn || '"!l fs ; f1!stem loc.!spec fs 09 f1 1!stem n.'

but, instead of spec a substring would do too/better. (For René,
who has a ZIP of it, fn here is VilMA.Controllers.) BTW, stage L
is Locate abbreviated to the max.

> [...]
> HTH

Yes, it helped a lot. Until next hurdle I can't take on my own.

Best,
M.