Menu
▾
▴
netrexx-pipelines
You can subscribe to this list here.
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(1) |
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2020 |
Jan
|
Feb
|
Mar
(4) |
Apr
(3) |
May
(6) |
Jun
(7) |
Jul
(10) |
Aug
(9) |
Sep
(9) |
Oct
(1) |
Nov
(3) |
Dec
(5) |
| 2021 |
Jan
|
Feb
(1) |
Mar
(5) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
(3) |
Oct
(9) |
Nov
(1) |
Dec
(14) |
| 2022 |
Jan
(8) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(165) |
Jul
(8) |
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
(5) |
| 2023 |
Jan
(19) |
Feb
(14) |
Mar
(2) |
Apr
(3) |
May
|
Jun
(2) |
Jul
(10) |
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
(10) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <hp...@we...> - 2022-06-12 03:00:21
|
Hi Rony!
Once started from the promise/allegation, NetRexx Pipelines would
work the same as the role model on VM/CMS I planned to eliminate
OS/2 Pipelines in a ooRexx program -- and René agreed to help --
we are now at the detail point, how do I get BSFContextVariables
to do what I need? Currently I'm not convinced to be still on
track, but that's my impression which could be wrong.
Let me picture the idea I have about REXX variable pools. It may
be the source of failure because too coarse or completely wrong or
too much influenced by REXX as I know it from VM/CMS. So please
holler if I have the wrong picture.
Every REXX program has its own variable pool. Subroutines within
the same file share this pool _unless_ protected by "procedure"
which optional may share a selected set of variables by "expose".
Within ooRexx it's just the other way round, objects and methods
are protected "like lepers", what might help in vast program files
where by chance use of same variable names might occur. So each
"entity" has a variable pool of its own.
This "keep 'em separated" is absolute when running NetRexx
Pipelines from ooRexx, since stages like var, stem and alike all
fail (from an ooRexx-centric point of view). The solution using
the stack to bring an ooRexx stem's content to the NetRexx pipe
shown by Gil Barmwater works, highly likely it could also work
backwards. Alas, NetRexx Pipelines lack the stack stage.
At the moment I have trouble with BsfContextVariables() in two
ways, theoretically and in practice.
Theoretically with respect to the current variable pool involved:
Am 10.06.2022 um 16:00 schrieb Rony G. Flatscher:
>> [...]
>> Please define "current" ;)
>
> It is the context of the Rexx code executing
> BsfContextVariables(). ;)
In that case a simple a = b would set the same variable A as does
BsfContextVariables('Set', a, b). So there is for sure something I
did not grasp yet. Nonetheless I gave it a try -- the trouble in
practice:
The first replacement of OS/2 Pipelines by NetRexx P. would be:
> ripe = '@java -cp "',
> || value("NETREXX_HOME", , "ENVIRONMENT"),
> || '\lib\NetRexxF.jar;',
> || value("CLASSPATH", , "ENVIRONMENT"),
> || '"' 'org.netrexx.njpipes.pipes.runner'
> fn = vilma.ini
> '' ripe '"(sep !) <' fn '!nxvarload'
with nxvarload being a draft of a future varload stage, a current
snapshot of it:
> /* nxvarload.njp: NetrexX VARLOAD, still incomplete */
> import org.netrexx.njpipes.pipes.
> class nxvarload extends stage
> method run()
> do /* who needs this? */
> addpipe (bs end ? sep !) *in:!a: fanout!strip!locate!*in:?a:!*out:
> loop forever
> line = Rexx readto()
> parse line.upper sc +1 vn (sc) sv /* UPPER to force keyword SYMBOLIC */
> if sc <> '*' then BSFContextVariables("Set", vn, sv)
> end
> catch StageError
> rc = rc()
> end
> exit(rc*(rc<>12))
> ::requires BSF.CLS
(In case you wonder about the addpipe, 'the Book' specifies,
"varload strictly does not delay the record." That implies, even
without explicit operation description, varload copies records to
the primary output stream.)
Problem: without ::requires directive BSFContextVariables() is
unknown, with it the PIPC compiler or translator dislikes the
colons of the directive. Frankly, methinks it's a bit contorted to
use a ooRexx directive and function within a NetRexx stage, but
without know-why I am pretty helpless.
>> [...]
> There is no choice available to use any other pool than the
> context one, i.e. the variable pool of the location where your
> program runs BsfContextVariables(). (You could have a routine
> which collects the pipe results and returns it and at the receiver
> side issue the BsfContextVariables() with that data.)
When I have collected pipe results in ooRexx I see no need for
BsfContextVariables(). Sorry, but I would access the results
collection directly.
> [...]
> If you want to set variables (instead of interpret) you can use
> the value() BIF (built-in function) like this:
>
> call value hi, 'hi, my beloved world'
> say hi /* will say 'hi, my beloved world'
Nice, but how do I get that "hi, my beloved world" from NetRexx
Pipelines to that BIF value in line one?
Please advice.
M.
|
|
From: Rony G. F. <Ron...@wu...> - 2022-06-10 14:00:38
|
Hi Mike,
On 6/10/2022 10:47 AM, hp...@we... wrote:
... cut ...
> You advised to use BsfContextVariables() to set, get, or drop
> variables of the _current_ variable pool.
> Please define "current" ;)
It is the context of the Rexx code executing BsfContextVariables(). ;)
... cut ...
> In contrast to the varset stage, varload will filter by default
> comments and blank lines before doing something like
>
>> loop forever
>> line = Rexx peekto() /* readto() would do in this case */
>> parse line.upper sc +1 vn (sc) sv
>> BSFContextVariables("Set", vn, sv)
>> readto()
>> end
>
> My question is, how does BSFContextVariables() "know" which pool
> to use?
There is no choice available to use any other pool than the context one, i.e. the variable pool of
the location where your program runs BsfContextVariables(). (You could have a routine which collects
the pipe results and returns it and at the receiver side issue the BsfContextVariables() with that
data.)
> From my point of view, there are several available in this
> context: one of the stage involving BSFContextVariables(), another
> one of ooRexx that started the NetRexx pipe, which itself could be
> a method of a method of... and so on, resulting in several pools
> within the same program/application. And does it make a difference
> if BSFContextVariables() is called in a stage which was involved
> by callpipe or addpipe?
Then BSFContextVariables() will effect the Rexx context there.
> Is that described or documented somewhere? TIA!
Yes, BSFContextVariables() uses the ooRexx native API named "rexxapi.pdf", section "1.17. Rexx
Interface Methods Listing", APIs named: DropContextVariable(), GetContextVariable() and
SetContextVariable().
Just noticed that the context are "routine" and "exit", but not "method".
---
Getting, setting and dropping variables without BsfContextVariable():
If you want to read the variables of the current context you could use the RexxContext object's
variables method like this (cf. rexxref.pdf, section "5.4.16.12. variables"):
do counter c with index idx item value over .context~variables
say "#" c":" idx"="value
end
If you want to set variables (instead of interpret) you can use the value() BIF (built-in function)
like this:
call value hi, 'hi, my beloved world'
say hi /* will say 'hi, my beloved world'
If you want to drop variables use the DROP keyword statement like this:
drop hi
say hi /* will say 'HI' */
HTH,
---rony
|
|
From: <hp...@we...> - 2022-06-10 08:49:35
|
Hi!
Now I do need having a blocnote to jot things down, since ooRexx
5.oo is on another machine than my mail system.
The example from Gil Barmwater shown some days ago on
[oorexx:discussion] now works:
> fn.0 = 3
> fn.1 = 'Tom'
> fn.2 = 'Dick'
> fn.3 = 'Harry'
> do n = 1 to fn.0
> queue fn.n
> end
>
> rx = 'rexx -e'
> rs = '"do while queued()>0;parse pull l;say l;end"'
> runpipe = 'java org.netrexx.njpipes.pipes.runner'
> pipeln = '"console | reverse | console"'
> rx rs "|" runpipe pipeln
But, this NetRexx pipe runs without knowledge about neither
NETREXX_HOME nor CLASSPATH, what makes me wonder.
That's the way to pass content of ooRexx variables to the NetRexx
Pipeline. For the other way round, to save results to variables I
have installed BSF4ooRexx, but not yet conducted a first trial
with it.
Hello Rony!
You advised to use BsfContextVariables() to set, get, or drop
variables of the _current_ variable pool.
Please define "current" ;)
The first pipe of my VilMA.rx to be converted to NetRexx Pipelines is:
> fn = vilma.ini
> call RxPipe '< "' || fn || '"!nlocate 1 /*/!varset'
what I'd like to convert to
> ripe = '@java -cp "',
> || value("NETREXX_HOME", , "ENVIRONMENT"),
> || '\lib\NetRexxF.jar;',
> || value("CLASSPATH", , "ENVIRONMENT"),
> || '"' 'org.netrexx.njpipes.pipes.runner'
> fn = vilma.ini
> ripe '"(sep !) <' fn '!varload"'
In contrast to the varset stage, varload will filter by default
comments and blank lines before doing something like
> loop forever
> line = Rexx peekto() /* readto() would do in this case */
> parse line.upper sc +1 vn (sc) sv
> BSFContextVariables("Set", vn, sv)
> readto()
> end
My question is, how does BSFContextVariables() "know" which pool
to use? From my point of view, there are several available in this
context: one of the stage involving BSFContextVariables(), another
one of ooRexx that started the NetRexx pipe, which itself could be
a method of a method of... and so on, resulting in several pools
within the same program/application. And does it make a difference
if BSFContextVariables() is called in a stage which was involved
by callpipe or addpipe?
Is that described or documented somewhere? TIA!
Best,
M.
Am 07.06.2022 um 14:30 schrieb Rony G. Flatscher:
> On 6/6/2022 10:23 PM, René Jansen wrote:
> ... cut ...
>> [...]
>>> OK, back to the subject.
>>> Additional question: if I would program a VARLOAD stage or alike,
>>> and set there some variables according the data trickling through
>>> the pipe, would those be set within the VARLOAD routine only or
>>> for the NetRexx program which called the pipe in question? Would
>>> this also be possible from ooRexx? Probably not, but is there a
>>> chance to access a "common pool" from both "dialects"? Something
>>> adequate the GLOBALV concept of VM/CMS? Well, that would require
>>> some kind of "pull" in ooRexx after the NetRexx pipe finished, a
>>> "push" of the results (variables set directly) would be more
>>> appropriate.
>>>
>> We have to speak to Rony about this, I am sure BSF4ooRexx has a
>> fitting solution here.
>
> with BSF4ooRexx you would have the ability to get and set any Rexx
> variable in the current context.
>
> BSF4ooRexx would allow to create the classic Rexx exits in Java
> and using BSF4ooRexx already one could even implement them in
> ooRexx! :)
>
> [Planning on adding support for the redirectable environmentto
> BSF4ooRexx introduced in ooRexx 5, once I have a little bit of
> free time on my hands. Probably sometimes in the summer.]
>
> It should be possible to write stages in ooRexx, if there is a
> Java interface definition for stages in the NetRexx pipes. If so,
> please point it out (not having had my fingers on NetRexx pipes
> just as of yet, short of time, but very interested in this
> infrastructure) and I try to come up with an example.
>
> ---rony
>
>
>
>
> _______________________________________________
> netrexx-pipelines mailing list
> net...@li...
> https://lists.sourceforge.net/lists/listinfo/netrexx-pipelines
|
|
From: <hp...@we...> - 2022-06-09 02:44:37
|
Hello Rony! Sorry for my delayed response, but a PC not touched several month takes its time to be up to date again. Am 08.06.2022 um 13:31 schrieb Rony G. Flatscher: > > Maybe one more thing: the current version of BSF4ooRexx is > supposed to work with ooRexx 4.1 and higher. If it does not, then > it is to be regarded as an error in the current GA release of > BSF4ooRexx! If you find such errors please file a bug with a small > sample at <https://sourceforge.net/p/bsf4oorexx/bugs/> (if going > there, yes, currently there are no known bugs!). This may be > possible as my testing with pre-5.0 interpreters (due to time > restrictions) has become limited (e.g. it may be the case that > here and there 5.0 features got introduced by mistake). I'd like to get VilMA converted to use NetRexx Pipelines first as agreed with René. When this works I'll take it to the pre-5.0 ooRexx PC. I prefer to take one step after the other and to avoid as much interferences as possible. > Ad release and supported minimum versions of ooRexx and Java: one > can infer that from the naming, the current GA version of > BSF4ooRexx is named: "BSF4ooRexx-641.20220131". So here the > deciphering in a rexxtry session: > [...] Is there an indicator if the installed java is too old? > --- > > Also, one, two things you might want to know: > > * it is possible to run ooRexx 5.0 without installation, if no > older Rexx is installed. I have on my "test-NetRexx-Pipelines-with-BSF4ooRexx-Support"-PC now installed ooRexx 5.0, which installed also ooDialog 4.2.4 (preview), unasked. No problem since it's a test machine only. > * ooRexx 5.0 introduced the ability to run 32- and 64-bit ooRexx > interpreters in parallel without > inhibiting each other! It is also possible to run different > revisions of ooRexx 5.0 in parallel. I assume, the how-to is described somewhere. How to use BSF4ooRexx to make stage varload set vars in ooRexx -- later please, not now, I'm too tired. Best M. |
|
From: Rony G. F. <Ron...@wu...> - 2022-06-08 11:32:04
|
Hi Mike, On 6/8/2022 1:46 AM, hp...@we... wrote: > Am 07.06.2022 um 14:30 schrieb Rony G. Flatscher: >> Hi Mike, >> [...] >> If you have BSF4ooRexx installed > > I have not yet... sorry -- and same time thank you for your > detailed advice -- but as I described before, I refuse to install > ooRexx 5.00 Beta 5840 (or above already?). But... since I have > more than one PC available, I can't say NO! so harsh and impolite > when others are so kind and help, so I'll give it a try on one > machine. Tomorrow. Maybe one more thing: the current version of BSF4ooRexx is supposed to work with ooRexx 4.1 and higher. If it does not, then it is to be regarded as an error in the current GA release of BSF4ooRexx! If you find such errors please file a bug with a small sample at <https://sourceforge.net/p/bsf4oorexx/bugs/> (if going there, yes, currently there are no known bugs!). This may be possible as my testing with pre-5.0 interpreters (due to time restrictions) has become limited (e.g. it may be the case that here and there 5.0 features got introduced by mistake). Ad release and supported minimum versions of ooRexx and Java: one can infer that from the naming, the current GA version of BSF4ooRexx is named: "BSF4ooRexx-641.20220131". So here the deciphering in a rexxtry session: *ver="BSF4ooRexx-641.20220131"* ........................................... rexxtry.rex on WindowsNT *parse var ver "-" nums '.' reldate* ........................................... rexxtry.rex on WindowsNT *say "release date:" reldate* release date: 20220131 ........................................... rexxtry.rex on WindowsNT *say "minimum ooRexx version:" nums//100* minimum ooRexx version: 41 ........................................... rexxtry.rex on WindowsNT *say "minimum Java version:" nums%100* minimum Java version: 6 ........................................... rexxtry.rex on WindowsNT *call bsf.cls* /* load the ooRexx-Java bridge */ ........................................... rexxtry.rex on WindowsNT *say .bsf4rexx~display.version* /* show the exact versions of ooRexx, BSF4ooRexx, Java, operating system in effect */ ooRexx 5.0.0 r12376 (21 Apr 2022) / BSF 641.20220131 / Java 17 (released: 2021-09-14), 32-bit (x86) / Windows 10.0.19043 --- Also, one, two things you might want to know: * it is possible to run ooRexx 5.0 without installation, if no older Rexx is installed. Just add the ooRexx bin directory to the PATH environment variable or use a batch file that does that for a specific session, * ooRexx 5.0 introduced the ability to run 32- and 64-bit ooRexx interpreters in parallel without inhibiting each other! It is also possible to run different revisions of ooRexx 5.0 in parallel. HTH, ---rony |
|
From: <hp...@we...> - 2022-06-08 01:44:09
|
Am 07.06.2022 um 22:38 schrieb J Leslie Turriff:
> On 2022-06-07 14:59:38 René Jansen wrote:
>> It is a bit like CMS not closing round brackets — I cannot get used to
>> that.
>
> It is a bit confusing; CMS is using ( as a separator, not for grouping.
The way you describe it is not at all confusing. The '(' marks the
end of arguments and start of options. Same with ')' since it
marks the end of the options and -- in case of XEDIT as you
mention it -- the beginning of parameters. If nothing follows the
options, there is no need to separate it from the options.
> The only time
> when using a matching ) is useful is when calling an Xedit macro, where ) can be followed
> by parms for the macro; e.g.
> | xedit fn ft fm (profile special) parms...
> which allows SPECIAL XEDIT to parse its arguments:
> | parse arg . ')' ...
Instead of ')' something else never part of arguments, options,
parameters, younameit could be used. In an ooRexx program I use
> arg cfgID '#' kyhld
because 'kyhld' is in this special case not an option which all
are set in the CFG file. (In fact it is an option, it's an
optional "key held down" at power-up of an emulated calculator to
trigger rarely used functions like changing the digit separator.
On Windows '#' is not a line-end character, so I dare to use it.)
Best,
M.
|
|
From: <hp...@we...> - 2022-06-08 01:44:08
|
Hello René! Am 07.06.2022 um 21:59 schrieb René Jansen: >>>> [...] >> Main obstacles had been: wrong file type, must be .njp instead of >> .nrx, no option (sep !) possible, no /* */ bracketed comment on >> line with addpipe, and many other showstoppers I can't describe >> any more. >> > I don’t know if you are like me, always having a blocnote to jot things down - that might be quite valuable. As these emails are. Hopefully you are not like me, otherwise colleagues might dislike you. No, I am not taking notes, what I can't remember was not worth it. I know this is a problem, getting older I forget too much. For example now in this respect of NetRexx Pipelines I got some hints and can't find them any more. Was it on this list or on ooRexx help forum? Time of others wasted who tried to help. Sorry. >> [...] >> Next steps? No idea. Experts -- please advice. > > If you want to donate the stage, we can put in in 4.04. I’ll have a look at the other pipes. Donate? But it's absolutely not finished yet, it's nothing but a first try how it /could/ look like. In addition, donate... all code snippets, all ideas discussed and published here are public property. My point of view. Just in case (if ever) I claim something to be my ownership I tag it 'licensed under the QPL 1.0" (what is a joke because I can't enforce it). No, this Varload still needs some enhancement. First and foremost a mechanism to actually set variables /at minimum/ in callers variable pool. In addition, did you see all the options of Varload in 'the book'? Then, do "we" have templates like those here: http://vm.marist.edu/%7Epipeline/#Skeleton ? I found them helpful not to forget something. Best, M. |
|
From: <hp...@we...> - 2022-06-08 01:44:04
|
Am 07.06.2022 um 19:14 schrieb Jeff Hennick: > Mike, Jeff, > Something that may help you in transitioning to NetRexx Pipelines from CMS is > the HTML version of the Stages documentation. It notes all the differences > between the two, both in stage availability in each system, and options differences. Intellectuals are said to have radical ideas now and again. So please don't be surprised when I argue, if NetRexx Pipelines (allegedly) works like CMS Pipelines, there should be no differences at all. -- Ok, that's a joke, who knows if I'm an intellectual ;) > Currently *Stages Built Into****NetRexx Pipelines 4.03**& **CMS Pipelines V7R1 > **and Their Differences* is available at > *https://www.rexxla.org/blog/images/stages.html* . It is my hope that it will > be included in the Pipelines documentation in the next release. Already enclosed in this release: NetRexx 4.03-GA Pipelines Guide and Reference, authors Ed Tomlinson/Jeff Hennick/René Jansen, ISBN 978-90-819090-3-7, chapter 20 'Differences with CMS Pipelines', p. 35 ff, shows the comparison list (or a precursor of it, comparing NetRexx Pipelines 4.02 vs CMS Pipelines V7R1). Best, M. |
|
From: <hp...@we...> - 2022-06-08 01:44:04
|
Hi ---rony, Am 07.06.2022 um 14:30 schrieb Rony G. Flatscher: > Hi Mike, > [...] > If you have BSF4ooRexx installed I have not yet... sorry -- and same time thank you for your detailed advice -- but as I described before, I refuse to install ooRexx 5.00 Beta 5840 (or above already?). But... since I have more than one PC available, I can't say NO! so harsh and impolite when others are so kind and help, so I'll give it a try on one machine. Tomorrow. Best, M. |
|
From: <hp...@we...> - 2022-06-08 01:44:03
|
Hi Marc! Thank you for this hint. It's new for me, a nice finding :) Best, M. Am 07.06.2022 um 20:29 schrieb Marc Remes: > > > On 6/7/22 18:25, hp...@we... wrote: >> BTW, the argument for pipe.bat (or ripe.bat >> for me) only requires a double quote at the beginning but none at >> the end. That's one more know-how issue, free of know-why. > > Mike, > > I think that's courtesy of Microsoft CMD.EXE implementation. > When an argument (or program) contains blanks, it requires a > double quote at the beginning of the string. > It's less stringent on having a closing double quote: > << > C:\Users\win11>dir /B "a space.txt" > a space.txt > > C:\Users\win11>dir /B "a space.txt > a space.txt >>> > > Marc > > > _______________________________________________ > netrexx-pipelines mailing list > net...@li... > https://lists.sourceforge.net/lists/listinfo/netrexx-pipelines |
|
From: J L. T. <jlt...@ma...> - 2022-06-07 20:39:19
|
On 2022-06-07 14:59:38 René Jansen wrote: > > Result is the same as with first version of p4varload_1 but now > > with an addpipe quirk. BTW, the argument for pipe.bat (or ripe.bat > > for me) only requires a double quote at the beginning but none at > > the end. That's one more know-how issue, free of know-why. > > It is a bit like CMS not closing round brackets — I cannot get used to > that. It is a bit confusing; CMS is using ( as a separator, not for grouping. The only time when using a matching ) is useful is when calling an Xedit macro, where ) can be followed by parms for the macro; e.g. | xedit fn ft fm (profile special) parms... which allows SPECIAL XEDIT to parse its arguments: | parse arg . ')' ... When calling ooRexx programs from bash I use [ ] instead of ( ), because bash doesn't try to expand [ ] except in special cases, and will allow [ without ]. (I have no idea what one might use in Windows to get around this.) Leslie -- Operating System: Linux Distribution: openSUSE Leap 15.3 x86_64 java version "18" 2022-03-22 NetRexx portable processor 4.03-BETA build 303-20220331-1205 Open Object Rexx Version 5.0.0 r12286 Build date: Aug 12 2021 Addressing mode: 64 |
|
From: René J. <rvj...@xs...> - 2022-06-07 19:59:58
|
Hi Mike, > On 7 Jun 2022, at 18:25, hp...@we... wrote: > > Hello René! > > Am 07.06.2022 um 11:15 schrieb René Jansen: >>> [...] >> I know you are not a fan of non-GA, but in this case you might want to grab what is pointed to at https://www.rexxla.org/blog/netrexx/release404/ <https://www.rexxla.org/blog/netrexx/release404/> , bottom of page. > > When I look at the pace NetRexx is updated it makes a big > difference compared to ooRexx which is Beta since 2014-02-24 -- > more than eight years now. But changed almost twice a day. A never > ending story. Reassessing a statement from Frank Zappa I could > say, it's not dead but it smells funny. > Well, it is better every day. I would release it. > Because I publish few of my programs made with ooRexx I refuse to > use its Beta version. How could I argue to use a Beta? Beta is > better? Beta is fresh and fine, everything else is frumpy? When I > install NetRexx 4.04 Alpha now it's highly likely when VilMA is > fully migrated either NetRexx 4.04 is also done and out or > finalised within few month only. > Yes, I expect that no to take too long. Marc just released a branch that has TRACE INTERACTIVE, and we cannot sit too long on that. >>>> addpipe "(sep !) *in:!strip!l!*in:" >>> but the compiler doesn't like the way I put it -- and I can't find >>> sufficing documentation about addpipe. >> >> There is an example of addpipe at examples/pipes/addpipetest2.njp which might help. > > There are several examples beginning with addpipetest, numbered > from 1..8, but they all made me wonder about the keywords, the > options, the sequence, where all the dos and donts are documented. > > In short: got it working. But... it took quite a while. The only > chance I had without description was molesting and butchering that > silly addpipetest2, trial and error and again, never give up. > Finally it returns what it should. Honestly, I detest results > based on know-how only and absolutely no know-why. > Main obstacles had been: wrong file type, must be .njp instead of > .nrx, no option (sep !) possible, no /* */ bracketed comment on > line with addpipe, and many other showstoppers I can't describe > any more. > I don’t know if you are like me, always having a blocnote to jot things down - that might be quite valuable. As these emails are. > The modified proposal for varload now looks like this (it's still > work in progress, no options for now): >> /* p4varload_2.njp: prepare for kind of VARLOAD */ >> import org.netrexx.njpipes.pipes. >> class p4varload_2 extends stage >> method run() >> do /* why a DO here, for what? */ >> addpipe (bs) *in:|strip|locate|*in: -- /* may this cause a dealay? */ >> loop forever >> line = Rexx peekto() >> parse line.upper sc +1 vn (sc) sv /* UPPER to force keyword SYMBOLIC */ >> /* sc <> '*' is together with the !strip!l above the default COMMENT "* " */ >> /* the plan is to put the output to stack or stem and interpret it line by line */ >> if sc <> '*' then output(vn '=' sv) /* reduced due to addpipe */ >> readto() >> end >> catch StageError /* now outside the repetitive loop, is that correct? */ >> rc = rc() >> end >> exit(rc*(rc<>12)) > > It's same like CMS Pipelines, only different. > What could you do with it? Compile it and run it: >> C:\prgm\NetRexx\examples\VilMA>pipc p4varload_2 >> addpipe (p4varload_2_bs ) *i_A:|strip|locate|*i_B: >> >> C:\prgm\NetRexx\examples\VilMA>ripe "(sep !) < vilma.ini!p4varload_2!term >> VIMDR = C:\PRGM\REXX\VILMA\ >> CTLDR = C:\PRGM\HP-EMULATORS\V41\ >> VILDR = C:\PRGM\HP-EMULATORS\VIRTIL\ >> DELTA = 3 >> ITLVL = STD.VILMA >> CTRLS = VILMA.CONTROLLERS >> TPCPT = TYPICAL.CAPTION >> DIAPOS = 321 23 > > Result is the same as with first version of p4varload_1 but now > with an addpipe quirk. BTW, the argument for pipe.bat (or ripe.bat > for me) only requires a double quote at the beginning but none at > the end. That's one more know-how issue, free of know-why. > It is a bit like CMS not closing round brackets — I cannot get used to that. > Next steps? No idea. Experts -- please advice. If you want to donate the stage, we can put in in 4.04. I’ll have a look at the other pipes. Best regards, René. > > Best, > M. > > > _______________________________________________ > netrexx-pipelines mailing list > net...@li... > https://lists.sourceforge.net/lists/listinfo/netrexx-pipelines |
|
From: Marc R. <re...@gm...> - 2022-06-07 18:29:40
|
On 6/7/22 18:25, hp...@we... wrote: > BTW, the argument for pipe.bat (or ripe.bat > for me) only requires a double quote at the beginning but none at > the end. That's one more know-how issue, free of know-why. Mike, I think that's courtesy of Microsoft CMD.EXE implementation. When an argument (or program) contains blanks, it requires a double quote at the beginning of the string. It's less stringent on having a closing double quote: << C:\Users\win11>dir /B "a space.txt" a space.txt C:\Users\win11>dir /B "a space.txt a space.txt >> Marc |
|
From: Jeff H. <Je...@Je...> - 2022-06-07 17:40:22
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Mike,</p>
<p>Something that may help you in transitioning to NetRexx Pipelines
from CMS is the HTML version of the Stages documentation. It
notes all the differences between the two, both in stage
availability in each system, and options differences.</p>
<p>Currently <b>Stages Built Into</b><b> </b><b>NetRexx Pipelines
4.03</b><b> & </b><b>CMS Pipelines V7R1 </b><b>and Their
Differences</b> is available at <b><a class="moz-txt-link-freetext" href="https://www.rexxla.org/blog/images/stages.html">https://www.rexxla.org/blog/images/stages.html</a></b>
. It is my hope that it will be included in the Pipelines
documentation in the next release.</p>
<p>Jeff<br>
</p>
</body>
</html>
|
|
From: <hp...@we...> - 2022-06-07 17:34:45
|
Hello René! Am 07.06.2022 um 11:15 schrieb René Jansen: >> [...] > I know you are not a fan of non-GA, but in this case you might want to grab what is pointed to at https://www.rexxla.org/blog/netrexx/release404/ <https://www.rexxla.org/blog/netrexx/release404/> , bottom of page. When I look at the pace NetRexx is updated it makes a big difference compared to ooRexx which is Beta since 2014-02-24 -- more than eight years now. But changed almost twice a day. A never ending story. Reassessing a statement from Frank Zappa I could say, it's not dead but it smells funny. Because I publish few of my programs made with ooRexx I refuse to use its Beta version. How could I argue to use a Beta? Beta is better? Beta is fresh and fine, everything else is frumpy? When I install NetRexx 4.04 Alpha now it's highly likely when VilMA is fully migrated either NetRexx 4.04 is also done and out or finalised within few month only. >>> addpipe "(sep !) *in:!strip!l!*in:" >> but the compiler doesn't like the way I put it -- and I can't find >> sufficing documentation about addpipe. > > There is an example of addpipe at examples/pipes/addpipetest2.njp which might help. There are several examples beginning with addpipetest, numbered from 1..8, but they all made me wonder about the keywords, the options, the sequence, where all the dos and donts are documented. In short: got it working. But... it took quite a while. The only chance I had without description was molesting and butchering that silly addpipetest2, trial and error and again, never give up. Finally it returns what it should. Honestly, I detest results based on know-how only and absolutely no know-why. Main obstacles had been: wrong file type, must be .njp instead of .nrx, no option (sep !) possible, no /* */ bracketed comment on line with addpipe, and many other showstoppers I can't describe any more. The modified proposal for varload now looks like this (it's still work in progress, no options for now): > /* p4varload_2.njp: prepare for kind of VARLOAD */ > import org.netrexx.njpipes.pipes. > class p4varload_2 extends stage > method run() > do /* why a DO here, for what? */ > addpipe (bs) *in:|strip|locate|*in: -- /* may this cause a dealay? */ > loop forever > line = Rexx peekto() > parse line.upper sc +1 vn (sc) sv /* UPPER to force keyword SYMBOLIC */ > /* sc <> '*' is together with the !strip!l above the default COMMENT "* " */ > /* the plan is to put the output to stack or stem and interpret it line by line */ > if sc <> '*' then output(vn '=' sv) /* reduced due to addpipe */ > readto() > end > catch StageError /* now outside the repetitive loop, is that correct? */ > rc = rc() > end > exit(rc*(rc<>12)) It's same like CMS Pipelines, only different. What could you do with it? Compile it and run it: > C:\prgm\NetRexx\examples\VilMA>pipc p4varload_2 > addpipe (p4varload_2_bs ) *i_A:|strip|locate|*i_B: > > C:\prgm\NetRexx\examples\VilMA>ripe "(sep !) < vilma.ini!p4varload_2!term > VIMDR = C:\PRGM\REXX\VILMA\ > CTLDR = C:\PRGM\HP-EMULATORS\V41\ > VILDR = C:\PRGM\HP-EMULATORS\VIRTIL\ > DELTA = 3 > ITLVL = STD.VILMA > CTRLS = VILMA.CONTROLLERS > TPCPT = TYPICAL.CAPTION > DIAPOS = 321 23 Result is the same as with first version of p4varload_1 but now with an addpipe quirk. BTW, the argument for pipe.bat (or ripe.bat for me) only requires a double quote at the beginning but none at the end. That's one more know-how issue, free of know-why. Next steps? No idea. Experts -- please advice. Best, M. |
|
From: Rony G. F. <Ron...@wu...> - 2022-06-07 12:30:59
|
Hi Mike, On 6/7/2022 10:40 AM, hp...@we... wrote: ... cut ... > The output of p4varload_1 looks nice: >> C:\prgm\NetRexx\examples\VilMA>ripe "(sep !) < vilma.ini!p4varload_1!term >> VIMDR = C:\PRGM\REXX\VILMA\ >> CTLDR = C:\PRGM\HP-EMULATORS\V41\ >> VILDR = C:\PRGM\HP-EMULATORS\VIRTIL\ >> DELTA = 3 >> ITLVL = STD.VILMA >> CTRLS = VILMA.CONTROLLERS >> TPCPT = TYPICAL.CAPTION >> DIAPOS = 321 23 > > Now we "only" need to interpret this in ooRexx. ... cut ... If you have BSF4ooRexx installed (https://sourceforge.net/projects/bsf4oorexx/files/GA/BSF4ooRexx-641.20220131-GA/), then add "::requires BSF.CLS" (loads BSF4ooRexx) at the end of your program. Afterwards you have access to the external Rexx function BsfContextVariables() which allows one to read, set or drop Rexx variables from/in the current variable pool. Here the synopsis: BsfContextVariables( "G[et]" [, name] ) ... return value of a Rexx variable with given name, if omitted, returns a directory of all current Rexx variables in the current context BSFContextVariables("S[et]", { name, newValue | directory | stringTable} ) ... either sets a single Rexx variable name to newValue, or takes all directory or stringtable pairs of INDEX (variable name ) and ITEM (value to be set to) and processes them accordingly, returns .true BSFContextVariables("D[rop]", name) ... drops the Rexx variable name from the current context, returns .true HTH, ---rony |
|
From: Rony G. F. <Ron...@wu...> - 2022-06-07 12:30:50
|
On 6/6/2022 10:23 PM, René Jansen wrote: ... cut ... > Glad you said that. This is one of the improvements of 4.04 - there you can use Classic Rexx notation for all built-in-functions (BIFs). In this case, I did that and the original decision to have only oo-invocation is Mike’s. > >> OK, back to the subject. >> Additional question: if I would program a VARLOAD stage or alike, >> and set there some variables according the data trickling through >> the pipe, would those be set within the VARLOAD routine only or >> for the NetRexx program which called the pipe in question? Would >> this also be possible from ooRexx? Probably not, but is there a >> chance to access a "common pool" from both "dialects"? Something >> adequate the GLOBALV concept of VM/CMS? Well, that would require >> some kind of "pull" in ooRexx after the NetRexx pipe finished, a >> "push" of the results (variables set directly) would be more >> appropriate. >> > We have to speak to Rony about this, I am sure BSF4ooRexx has a fitting solution here. with BSF4ooRexx you would have the ability to get and set any Rexx variable in the current context. BSF4ooRexx would allow to create the classic Rexx exits in Java and using BSF4ooRexx already one could even implement them in ooRexx! :) [Planning on adding support for the redirectable environmentto BSF4ooRexx introduced in ooRexx 5, once I have a little bit of free time on my hands. Probably sometimes in the summer.] It should be possible to write stages in ooRexx, if there is a Java interface definition for stages in the NetRexx pipes. If so, please point it out (not having had my fingers on NetRexx pipes just as of yet, short of time, but very interested in this infrastructure) and I try to come up with an example. ---rony |
|
From: René J. <rvj...@xs...> - 2022-06-07 09:15:37
|
Hi Mike,
> On 7 Jun 2022, at 10:40, hp...@we... wrote:
>
> Hello René!
>
> Am 06.06.2022 um 22:23 schrieb René Jansen:
>>> On 4 Jun 2022, at 16:20, hp...@we... wrote:
>> […]
>>> Back to the subject. […] Instead of
>>>
>>>> say length("ABC")
>>>
>>> I have to put it this way:
>>>
>>>> say "ABC".length
>>>
>>> What a progress! Re-use of old-style REXX routines impossible.
>>
>> Glad you said that. This is one of the improvements of 4.04 - there you can use Classic Rexx notation for all built-in-functions (BIFs). In this case, I did that and the original decision to have only oo-invocation is Mike’s.
>
> The saying goes 'the better is the death of the good', but since I
> am faster with what I'm used to, it must be much better. So thank
> you to bring back the old-style notation, I'm looking forward to
> V4.04.
>
I know you are not a fan of non-GA, but in this case you might want to grab what is pointed to at https://www.rexxla.org/blog/netrexx/release404/ <https://www.rexxla.org/blog/netrexx/release404/> , bottom of page.
>
>> addpipe "(sep !) *in:!strip!l!*in:"
> but the compiler doesn't like the way I put it -- and I can't find
> sufficing documentation about addpipe.
>
> Now, without help, I'm at the road's end.
There is an example of addpipe at examples/pipes/addpipetest2.njp which might help.
Best regards,
René.
>
> Best,
> M.
>
>
> _______________________________________________
> netrexx-pipelines mailing list
> net...@li...
> https://lists.sourceforge.net/lists/listinfo/netrexx-pipelines
|
|
From: <hp...@we...> - 2022-06-07 08:45:37
|
Hello René!
Am 06.06.2022 um 22:23 schrieb René Jansen:
>> On 4 Jun 2022, at 16:20, hp...@we... wrote:
> […]
>> Back to the subject. […] Instead of
>>
>>> say length("ABC")
>>
>> I have to put it this way:
>>
>>> say "ABC".length
>>
>> What a progress! Re-use of old-style REXX routines impossible.
>
> Glad you said that. This is one of the improvements of 4.04 - there you can use Classic Rexx notation for all built-in-functions (BIFs). In this case, I did that and the original decision to have only oo-invocation is Mike’s.
The saying goes 'the better is the death of the good', but since I
am faster with what I'm used to, it must be much better. So thank
you to bring back the old-style notation, I'm looking forward to
V4.04.
>> OK, back to the subject.
>> [...] Something
>> adequate the GLOBALV concept of VM/CMS? Well, that would require
>> some kind of "pull" in ooRexx after the NetRexx pipe finished, a
>> "push" of the results (variables set directly) would be more
>> appropriate.
>>
> We have to speak to Rony about this, I am sure BSF4ooRexx has a fitting solution here.
With my finding of this WE I made the next step and prepared a DIY
stage, which (hopefully) could serve as beginning of Varload. It
filters and rearranges the content of VilMA.INI to be used by an
interpret() -- no options at the moment:
> /* p4varload_1.nrx: prepare for kind of VARLOAD */
> import org.netrexx.njpipes.pipes.
> class p4varload_1 extends stage
> method run()
> loop forever
> line = Rexx peekto()
> parse line.upper sc +1 vn (sc) sv /* UPPER to force keyword SYMBOLIC */
> /* First: nice pitfall could be IF expression, expression, expression, ... THEN */
> /* length(sc) > 0 to avoid filter STRIP!L -- whild strip is missing here */
> /* pos(sc, '* ') = 0 is the default COMMENT "* " */
> /* the plan is to put the output to stack or stem and interpret it line by line */
> /* I was unable to split the clause and inject "inline" comments */
> if sc.length > 0 & '* '.pos(sc) = 0 then output(vn '=' sv)
> readto()
> catch StageError
> rc = rc()
> end
> exit(rc*(rc<>12))
BTW, to be in conformity with CMS Pipelines the stage LOCATE
should work with all abbreviations down to L.
What I describe in the comment as "nice pitfall" is in fact a
nasty surprise sice it works just in contrary to ooRexx and C.
A commentline like
> /* pos(sc, '* ') = 0 is the default COMMENT /* / */
was rejected by the compiler (or translator?) for "unbalanced /*"
what is kind of overdone.
The output of p4varload_1 looks nice:
> C:\prgm\NetRexx\examples\VilMA>ripe "(sep !) < vilma.ini!p4varload_1!term
> VIMDR = C:\PRGM\REXX\VILMA\
> CTLDR = C:\PRGM\HP-EMULATORS\V41\
> VILDR = C:\PRGM\HP-EMULATORS\VIRTIL\
> DELTA = 3
> ITLVL = STD.VILMA
> CTRLS = VILMA.CONTROLLERS
> TPCPT = TYPICAL.CAPTION
> DIAPOS = 321 23
Now we "only" need to interpret this in ooRexx.
Because I am a little unhappy with the "if sc.length > 0 &..." I
tried to insert something like
> addpipe "(sep !) *in:!strip!l!*in:"
but the compiler doesn't like the way I put it -- and I can't find
sufficing documentation about addpipe.
Now, without help, I'm at the road's end.
Best,
M.
|
|
From: <hp...@we...> - 2022-06-07 08:45:37
|
Hi! Am 06.06.2022 um 22:03 schrieb René Jansen: > Nrws is to run pipes with no name and no options, quickly, for the moment. No problem. Since the target system for this project is ooRexx it might be a good idea (for me and in this case) _not_ to use NRWS. My simplest "prototyping-toy" > /* interactive REXX */ > trace '?R' > address '' offers already an ooRexx environment. Enter single-line Rexx clauses, loops must also be entirely on one line using semicolons. To quit hit Enter (or Return?) with nothing entered. "Try REXX" reduced to the max :) Best, M. |
|
From: <hp...@we...> - 2022-06-07 08:45:37
|
Hi René! Am 06.06.2022 um 22:26 schrieb René Jansen: > Btw, NetRexx does not have value() Yes, I remarked that already. But if I look at value() of ooRexx it seems only halfway done. It can do this and that, even read environment variables, alas it does not access all what var, stem, varload, ... stages can on VM/CMS: choose which of its ancestors variable pools to use. > I use Interpret in Classic Rexx for those things, and I ned to study on how we can provide a value(). To develop something adequate to ooRexx value() will probably take some time, sure, a nice-to-have, but if mostly used for just the current variable pool Interpret() could be ok for the first go. Well, value() does read and write while intepret() will set vars only. And drop vars. > There is no Interpret() either, although we have the mechanism to do that if we want to, What could make you to want to do it? Best, M. |
|
From: René J. <rvj...@xs...> - 2022-06-06 20:27:12
|
Btw, NetRexx does not have value() - I don’t know why. I use Interpret in Classic Rexx for those things, and I ned to study on how we can provide a value(). There is no Interpret() either, although we have the mechanism to do that if we want to, René. |
|
From: René J. <rvj...@xs...> - 2022-06-06 20:23:43
|
Hi Mike,
> On 4 Jun 2022, at 16:20, hp...@we... wrote:
>
[…]
> First I wanted to see if the ooRexx function 'value' works the
> same under NetRexx. It will -- hopefully -- be documented in
> "NetRexx Language Reference", ISBN 978-90-819090-1-3, which shows
> on the title page Mike Cowlishaw and REXXLA as author (I doubt. In
> addition, Adobe Acrobat Reader shows as first bookmark 'List of
Mike C. authored nearly this whole book, if that is what you doubt. The errors are mine.
> Tables' which is linked to 'Content' on page upper-case II, there
> 'List of Tables' is indicated to be on page upper-case VII, a
> mouse-klick on this entry does just nothing, while the 'List of
> Tables' is in fact on page upper-case VIII. Sure, this could be a
> negligible detail, if not details stand for the whole. The
> responsible publisher of this edition is mentioned on page
> upper-case I, but who involved them? Mike Cowlishaw?)
I’ll tell the publisher. The 4.04 version has the same problem, which nobody noticed yet.
>
> Back to the subject. I expected a language reference documentation
> to be structured according the language, something like: A-general
> concept, B-keyword instructions, C-functions, etc. Since I still
> have REXX in mind as I know it since VM/SP my assumption was a
> fail. Similar to the "clash of the cultures" I encountered with
> ooRexx I see it now with NetRexx. Instead of
>
>> say length("ABC")
>
> I have to put it this way:
>
>> say "ABC".length
>
> What a progress! Re-use of old-style REXX routines impossible.
Glad you said that. This is one of the improvements of 4.04 - there you can use Classic Rexx notation for all built-in-functions (BIFs). In this case, I did that and the original decision to have only oo-invocation is Mike’s.
>
> OK, back to the subject.
> Additional question: if I would program a VARLOAD stage or alike,
> and set there some variables according the data trickling through
> the pipe, would those be set within the VARLOAD routine only or
> for the NetRexx program which called the pipe in question? Would
> this also be possible from ooRexx? Probably not, but is there a
> chance to access a "common pool" from both "dialects"? Something
> adequate the GLOBALV concept of VM/CMS? Well, that would require
> some kind of "pull" in ooRexx after the NetRexx pipe finished, a
> "push" of the results (variables set directly) would be more
> appropriate.
>
We have to speak to Rony about this, I am sure BSF4ooRexx has a fitting solution here.
> Sorry, with my nonexisting knowledge of NetRexx I'm stuck. At
> least I was able to answer two questions on my own. Now it's the
> turn for real experts.
>
> Best,
> M.
>
>
> _______________________________________________
> netrexx-pipelines mailing list
> net...@li...
> https://lists.sourceforge.net/lists/listinfo/netrexx-pipelines
|
|
From: René J. <rvj...@xs...> - 2022-06-06 20:04:08
|
> On 6 Jun 2022, at 19:32, hp...@we... wrote:
>
> I don't like to be stuck, so I tried this and that in the hope to
> find a way out. Result: few more questions -- and another hurdle
> overcome.
>
> Am 04.06.2022 um 16:20 schrieb ((me, myself and I)):
>> [...]
>>
>>> /* ooRexx */
>>> nrh = value("NETREXX_HOME", , "ENVIRONMENT")
>>> ripe = '@java -cp "'nrh'\lib\NetRexxF.jar;%CLASSPATH%"',
>>> 'org.netrexx.njpipes.pipes.runner'
>>> fn = vilma.ini
>>> ripe '"<' fn '|term"'
>> Works. So the BAT file is obsolete for this project.
>
> Taking a closer look to this I was not sure if %CLASSPATH% is
> resolved as it should. TRACE '?I' shows, it is not. In addition,
> the a. m. procedure returns 'RC=13' (w/o quotes). So I correct:
>
>> /* ooRexx */ trace '?I'
>> ripe = '@java -cp "',
>> || value("NETREXX_HOME", , "ENVIRONMENT"),
>> || '\lib\NetRexxF.jar;',
>> || value("CLASSPATH", , "ENVIRONMENT"),
>> || '"' 'org.netrexx.njpipes.pipes.runner'
>> fn = vilma.ini
>> ripe '"<' fn '|term"'
>
> Result: RC=13
> Eagerly searched 'Pipelines Guide and Reference' what RC=13 stands
> for, alas... it's not referenced in this /Reference/.
You have a good point and we looked at that earlier. It is a bit of work to round these up from the codebase.
I noted it down. Glad you found the debug option. I am apt to put a trace in the code and build a new jar in these cases.
> Question: how may I get the information, which stage caused the
> trouble and if it's a problem of the specification parser while
> scanning my teeny two-stage pipe or later while executing it?
> Answer: Found option 'debug' in Chapter 17 'The Pipes Runner'.
> With option 'debug 63' I get:
>
>> Starting pipe p6c85b5c p6c85b5c@34ab52cb
>> Starting diskr_1 p6c85b5c@34ab52cb
>> Preparing to stop diskr_1 p6c85b5c@34ab52cb 13 1
>> Autocommitting diskr_1 p6c85b5c@34ab52cb to -1
>> Starting term_2 p6c85b5c@34ab52cb
>> Ending Pipe p6c85b5c p6c85b5c@34ab52cb 320 13
>> RC=13
>> Preparing to stop term_2 p6c85b5c@34ab52cb 0 2
>> Autocommitting term_2 p6c85b5c@34ab52cb to -1
>
> I found in 'Pipelines Guide and Reference' neither an explanation
> for the numeric argument of option debug nor something about the
> message of this output. Taking the term "reference" in the title
> as a promise I'm slightly disappointed.
And rightly so. Another note made.
>
> At least I found my mistake: if I run this test in the subdir
> where the file to read, VilMA.INI, is located -- then it works.
>
Yes, always safest to specify full paths and make sure where you are with relative paths
> Next issue, a new one. Since I try to have NetRexx Pipelines in
> coexistence with OS/2 Pipelines I'd like to be sure about which
> one I run to avoid all interference (on my part). With the a. m.
> correction of setting variable 'ripe' to respect also CLASSPATH I
> see currently no problem to run a NetRexx pipe from ooRexx (while
> 'run' does not include access to all possible sources and sinks
> analogue CMS Pipelines). But for tests I'd like to use NRWS too.
>
> From within NRWS I have no access to RIPE.BAT (PIPE.BAT renamed)
> located in subdir bin. Instead I have to use PIPE. So I have to be
> very attentive: from the command line of a cmd window 'PIPE'
> involves OS/2 Pipelines, while from NRWS it runs NetRexx Pipelines.
> Question: is it possible to change that?
Nrws has the )sys command to run an outside program/script - you might try that. Under macOS I cannot get a pipeline to run though ( I have those commands as aliases ) but your mileage may vary with Windows.
The syntax is slightly different though - one of the things to clear up still.
>
> Next, PIPE within NRWS does not like options. From VM/CMS running
> with codepage 273 I am used to use the exclamation point as stage
> separator. So I did:
>
>> NWRS> pipe (sep !) < vilma.ini!term initial 4
>> 50 +++ _s_1 = (sep()
>> +++ ^^^
>> +++ Error: The method 'sep()' cannot be found in class 'p38d9569' or a super
>> class
>> Throwable:java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
>
> Pleas advice.
>
Nrws is to run pipes with no name and no options, quickly, for the moment. What needs to be done is: harmonise the pipes compiler from file (.njp) to the command line and the nrws version. These are small differences but a lot of work.
> Next, it is said to be simple to develop DIY filters, according to
> chapter 5 'Write your own Filters' in 'Pipelines Guide and
> Reference'. So I made my first steps with an idea 'varload' could
> look like in some future. No chance, a total fail: NetRexx
> Pipelines refuses to run my filter.
>
> So I tested what is described in 'Pipelines Guide and Reference'.
> Again an annoying pitfall, the first example on page 13
>
>> pipe ”literal abcd | bagvendt | console”
>
> can not be transferred by edid-copy/edit-paste from Adobe Acrobat
> to the cmd window since the double quotes are double byte chars.
Fixed in 4.04.
> Nonetheless, correcting this I get
>
>> 59 +++ _s_2 = bagvendt()
>> +++ ^^^^^^^^
>> +++ Error: The method 'bagvendt()' cannot be found in class 'p78187b2' or a
>> superclass
>> Exception in thread "main" java.lang.IndexOutOfBoundsException: Index: 0, Size:
>> 0
>> at java.util.ArrayList.rangeCheck(Unknown Source)
>> at java.util.ArrayList.get(Unknown Source)
>> at org.netrexx.process.NetRexxC.clgMain(NetRexxC.java:220)
>> at org.netrexx.njpipes.pipes.compiler.compile(compiler.java:1260)
>> at org.netrexx.njpipes.pipes.compiler.<init>(compiler.java:1357)
>> at org.netrexx.njpipes.pipes.runner.executePipe(runner.java:143)
>> at org.netrexx.njpipes.pipes.runner.main(runner.java:100)
>
> Same from NRWS but a less detailed error message.
>
> One phrase on p. 13 makes me nosy: "The resulting .class file
> needs to be on the CLASSPATH environment variable." How may I
> check this is done? Isn't the dot on CLASSPATH sufficient to
> include also the current subdir? The resulting .class file -- was
> it really prepared, and if yes where actually? Could it work if I
> compile -- ah, no, /translate/ -- it first and run the result?
It … well, in this case, translated twice (from ‘pipe' to netrexx, from netrexx to java, and then compiled by either javac or ecj).When you run with the runner, all files including the class file stay in memory; the compiled pipe needs to find your stage, and it can only do that if it is compiled to a .class file.
>
> Well, guess what -- it works. Reading again carefully 'Pipelines
> Guide and Reference', chapter 5 'Write your own Filters', p. 13, I
> begin to wonder about that phase "Because the source uses pipe
> idioms, the regular NetREXX compiler cannot understand everything,
> and we need to uses the pipes compiler pipc to compile this
> source." Me, mainframe dinosaur I am, slowly start to grasp, this
> was an advice or in fact an order to translate it in advance. I
> hope there is no drawback when I used not PIPC but NRC as shown in
> the postage-stamp-sized figure 10 on p. 14 (set zoom to 300% and
> it is instantly visible).
>
Yes, as you found out, a stage can be compiled by the ’normal’ NetRexx compiler, as there are no pipes in it.
> Enough for today...
> M.
>
Excellent progress though, and again valuable pointers for improvement of the docs. Thank you.
René.
>
> _______________________________________________
> netrexx-pipelines mailing list
> net...@li...
> https://lists.sourceforge.net/lists/listinfo/netrexx-pipelines
|
|
From: <hp...@we...> - 2022-06-06 17:39:26
|
I don't like to be stuck, so I tried this and that in the hope to
find a way out. Result: few more questions -- and another hurdle
overcome.
Am 04.06.2022 um 16:20 schrieb ((me, myself and I)):
> [...]
>
>> /* ooRexx */
>> nrh = value("NETREXX_HOME", , "ENVIRONMENT")
>> ripe = '@java -cp "'nrh'\lib\NetRexxF.jar;%CLASSPATH%"',
>> 'org.netrexx.njpipes.pipes.runner'
>> fn = vilma.ini
>> ripe '"<' fn '|term"'
> Works. So the BAT file is obsolete for this project.
Taking a closer look to this I was not sure if %CLASSPATH% is
resolved as it should. TRACE '?I' shows, it is not. In addition,
the a. m. procedure returns 'RC=13' (w/o quotes). So I correct:
> /* ooRexx */ trace '?I'
> ripe = '@java -cp "',
> || value("NETREXX_HOME", , "ENVIRONMENT"),
> || '\lib\NetRexxF.jar;',
> || value("CLASSPATH", , "ENVIRONMENT"),
> || '"' 'org.netrexx.njpipes.pipes.runner'
> fn = vilma.ini
> ripe '"<' fn '|term"'
Result: RC=13
Eagerly searched 'Pipelines Guide and Reference' what RC=13 stands
for, alas... it's not referenced in this /Reference/.
Question: how may I get the information, which stage caused the
trouble and if it's a problem of the specification parser while
scanning my teeny two-stage pipe or later while executing it?
Answer: Found option 'debug' in Chapter 17 'The Pipes Runner'.
With option 'debug 63' I get:
> Starting pipe p6c85b5c p6c85b5c@34ab52cb
> Starting diskr_1 p6c85b5c@34ab52cb
> Preparing to stop diskr_1 p6c85b5c@34ab52cb 13 1
> Autocommitting diskr_1 p6c85b5c@34ab52cb to -1
> Starting term_2 p6c85b5c@34ab52cb
> Ending Pipe p6c85b5c p6c85b5c@34ab52cb 320 13
> RC=13
> Preparing to stop term_2 p6c85b5c@34ab52cb 0 2
> Autocommitting term_2 p6c85b5c@34ab52cb to -1
I found in 'Pipelines Guide and Reference' neither an explanation
for the numeric argument of option debug nor something about the
message of this output. Taking the term "reference" in the title
as a promise I'm slightly disappointed.
At least I found my mistake: if I run this test in the subdir
where the file to read, VilMA.INI, is located -- then it works.
Next issue, a new one. Since I try to have NetRexx Pipelines in
coexistence with OS/2 Pipelines I'd like to be sure about which
one I run to avoid all interference (on my part). With the a. m.
correction of setting variable 'ripe' to respect also CLASSPATH I
see currently no problem to run a NetRexx pipe from ooRexx (while
'run' does not include access to all possible sources and sinks
analogue CMS Pipelines). But for tests I'd like to use NRWS too.
From within NRWS I have no access to RIPE.BAT (PIPE.BAT renamed)
located in subdir bin. Instead I have to use PIPE. So I have to be
very attentive: from the command line of a cmd window 'PIPE'
involves OS/2 Pipelines, while from NRWS it runs NetRexx Pipelines.
Question: is it possible to change that?
Next, PIPE within NRWS does not like options. From VM/CMS running
with codepage 273 I am used to use the exclamation point as stage
separator. So I did:
> NWRS> pipe (sep !) < vilma.ini!term initial 4
> 50 +++ _s_1 = (sep()
> +++ ^^^
> +++ Error: The method 'sep()' cannot be found in class 'p38d9569' or a super
> class
> Throwable:java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
Pleas advice.
Next, it is said to be simple to develop DIY filters, according to
chapter 5 'Write your own Filters' in 'Pipelines Guide and
Reference'. So I made my first steps with an idea 'varload' could
look like in some future. No chance, a total fail: NetRexx
Pipelines refuses to run my filter.
So I tested what is described in 'Pipelines Guide and Reference'.
Again an annoying pitfall, the first example on page 13
> pipe ”literal abcd | bagvendt | console”
can not be transferred by edid-copy/edit-paste from Adobe Acrobat
to the cmd window since the double quotes are double byte chars.
Nonetheless, correcting this I get
> 59 +++ _s_2 = bagvendt()
> +++ ^^^^^^^^
> +++ Error: The method 'bagvendt()' cannot be found in class 'p78187b2' or a
> superclass
> Exception in thread "main" java.lang.IndexOutOfBoundsException: Index: 0, Size:
> 0
> at java.util.ArrayList.rangeCheck(Unknown Source)
> at java.util.ArrayList.get(Unknown Source)
> at org.netrexx.process.NetRexxC.clgMain(NetRexxC.java:220)
> at org.netrexx.njpipes.pipes.compiler.compile(compiler.java:1260)
> at org.netrexx.njpipes.pipes.compiler.<init>(compiler.java:1357)
> at org.netrexx.njpipes.pipes.runner.executePipe(runner.java:143)
> at org.netrexx.njpipes.pipes.runner.main(runner.java:100)
Same from NRWS but a less detailed error message.
One phrase on p. 13 makes me nosy: "The resulting .class file
needs to be on the CLASSPATH environment variable." How may I
check this is done? Isn't the dot on CLASSPATH sufficient to
include also the current subdir? The resulting .class file -- was
it really prepared, and if yes where actually? Could it work if I
compile -- ah, no, /translate/ -- it first and run the result?
Well, guess what -- it works. Reading again carefully 'Pipelines
Guide and Reference', chapter 5 'Write your own Filters', p. 13, I
begin to wonder about that phase "Because the source uses pipe
idioms, the regular NetREXX compiler cannot understand everything,
and we need to uses the pipes compiler pipc to compile this
source." Me, mainframe dinosaur I am, slowly start to grasp, this
was an advice or in fact an order to translate it in advance. I
hope there is no drawback when I used not PIPC but NRC as shown in
the postage-stamp-sized figure 10 on p. 14 (set zoom to 300% and
it is instantly visible).
Enough for today...
M.
|
