NetRexx 3.08 BETA2

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

NetRexx 3.08 BETA2

rvjansen
Dear NetRexx users,

enough has changed to warrant a second beta release of NetRexx 3.08. From the release notes, it now contains the following changes with respect to 3.07:

NetRexx 3.08 BETA2[August 6th, 2019]

- restore OS/2 and Java 6 compatibility
- suppress generics-related warnings by adding a @SuppressWarnings annotation
- added a NetRexxC.clgMain method for compile, load and go
- the pipes.runner class now (compiles and directly) runs a pipeline
- default stage separator is now | like on zVM
- added the VM abbreviations of >,<,>> for file I/O device drivers
- pipes compiler now reliably finds classes it needs
- cleaned up pipes examples to make sure they all compile
- fixed C2X function on specs pipe stage
- added listzip stage
- added zip stage
- added unzip stage
- pipes compiler command is now called pipc
- added Pipes for NetRexx doc to distribution
- fixes a serious translator problem introduced in 3.07 - again some classes ended up in the wrong files (but in a different way than with the problem that was fixed with this error)
- display failed summaries last - Jason Martin
- squelched the remark that we found a java compiler and others
- add an experimental rexxcps.nrx from the work of Mike Cowlishaw (being evaluated for meaning and correctness)

… and more.

Some time was spent in trying to get Pipes for NetRexx as close as the original CMS version as possible. One of the goals was to run a pipe command unchanged from its CMS version. I tried to implement this in shell scripting but of course I should have known better. The functionality is now in org.netrexx.njpipes.pipes.runner, which should be aliased to pipe and/or PIPE.

To enable running a PIPE command from the commandline, a compile, load and go facility was added to the NetRexx compiler. This enables generating NetRexx source from the Pipes Compiler, generating Java source from that and running the Java compiler to produce a JVM Class image, all without writing a single file to disk. This way, a pipeline can run at top speed in the Hotspot JVM, using all available CPU’s. A fast computer enables response times of 0.6-0.8 seconds. The architecture of the pipes subsystem causes elapsed time to be significantly less than cpu time on well running multiprocessor systems. I am fairly enthousiastic about this and will use it a lot. Also for the zVM/CMS people, the <, >, and >> abbreviations for the disk device drivers have been added.

The NetRexxC clgMain method also has its merit outside of the pipelines realm, as it enables much more dynamic code generation and execution, without the functional limitations and performance penalty of the interpreter. Note that clgMain reflectively invokes the public, static main(args=String[]) method of the generated class image from memory, without arguments. If something else is desired, the array containing the in-memory classloader and all generated classes can be externalized for your own purposes.

The documents are not up to scratch with this new functionality. As I share most of the criticism on the Pipes for NetRexx document, I propose that I circulate the drafts of the rewrite on this list, where you all can help me in making it more usable, understandable and complete.

The second beta is available now on the website http://www.netrexx.org - please note that if there is a problem with this website, there is a backup of all its files to be found at https://github.com/rvjansen/netrexx-site - and as an alternative, the source of the project are at https://sourceforge.net/projects/netrexx/ . Building it yourself is easy, and only requires a Java 8 JRE.

best regards,

René. 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|

Re: NetRexx 3.08 BETA2

Rony G. Flatscher
On 06.08.2019 13:25, René Jansen wrote:
Dear NetRexx users,

enough has changed to warrant a second beta release of NetRexx 3.08. From the release notes, it now contains the following changes with respect to 3.07:

NetRexx 3.08 BETA2[August 6th, 2019]

- restore OS/2 and Java 6 compatibility
- suppress generics-related warnings by adding a @SuppressWarnings annotation
- added a NetRexxC.clgMain method for compile, load and go
- the pipes.runner class now (compiles and directly) runs a pipeline
- default stage separator is now | like on zVM
- added the VM abbreviations of >,<,>> for file I/O device drivers
- pipes compiler now reliably finds classes it needs
- cleaned up pipes examples to make sure they all compile
- fixed C2X function on specs pipe stage
- added listzip stage
- added zip stage
- added unzip stage
- pipes compiler command is now called pipc
- added Pipes for NetRexx doc to distribution
- fixes a serious translator problem introduced in 3.07 - again some classes ended up in the wrong files (but in a different way than with the problem that was fixed with this error)
- display failed summaries last - Jason Martin
- squelched the remark that we found a java compiler and others
- add an experimental rexxcps.nrx from the work of Mike Cowlishaw (being evaluated for meaning and correctness)

… and more.

Some time was spent in trying to get Pipes for NetRexx as close as the original CMS version as possible. One of the goals was to run a pipe command unchanged from its CMS version. I tried to implement this in shell scripting but of course I should have known better. The functionality is now in org.netrexx.njpipes.pipes.runner, which should be aliased to pipe and/or PIPE.

To enable running a PIPE command from the commandline, a compile, load and go facility was added to the NetRexx compiler. This enables generating NetRexx source from the Pipes Compiler, generating Java source from that and running the Java compiler to produce a JVM Class image, all without writing a single file to disk. This way, a pipeline can run at top speed in the Hotspot JVM, using all available CPU’s. A fast computer enables response times of 0.6-0.8 seconds. The architecture of the pipes subsystem causes elapsed time to be significantly less than cpu time on well running multiprocessor systems. I am fairly enthousiastic about this and will use it a lot. Also for the zVM/CMS people, the <, >, and >> abbreviations for the disk device drivers have been added.

The NetRexxC clgMain method also has its merit outside of the pipelines realm, as it enables much more dynamic code generation and execution, without the functional limitations and performance penalty of the interpreter. Note that clgMain reflectively invokes the public, static main(args=String[]) method of the generated class image from memory, without arguments. If something else is desired, the array containing the in-memory classloader and all generated classes can be externalized for your own purposes.

The documents are not up to scratch with this new functionality. As I share most of the criticism on the Pipes for NetRexx document, I propose that I circulate the drafts of the rewrite on this list, where you all can help me in making it more usable, understandable and complete.

The second beta is available now on the website http://www.netrexx.org - please note that if there is a problem with this website, there is a backup of all its files to be found at https://github.com/rvjansen/netrexx-site - and as an alternative, the source of the project are at https://sourceforge.net/projects/netrexx/ . Building it yourself is easy, and only requires a Java 8 JRE.

best regards,

René.

Very interesting, well done! :-)

---rony


_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|

Re: NetRexx 3.08 BETA2

Jason Martin
In reply to this post by rvjansen
I see the difference with pipe.bat and pipc.bat for Windows.

But not the same for Unix pipe and pipc

This OK?

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|

Re: NetRexx 3.08 BETA2

rvjansen
I am not at a computer now, but I mean to write about scripts and aliases tonight. I don’t use the unix scripts so they might be behind.

alias pipe=“java org.netrexx.njpipes.pipes.runner”
alias pipc=“java org.netrexx.njpipes.pipes.compiler”
alias nrc=“org.netrexx.process.NetRexxC”

should do the trick.

René.

> On 6 Aug 2019, at 15:06, Jason Martin <[hidden email]> wrote:
>
> I see the difference with pipe.bat and pipc.bat for Windows.
>
> But not the same for Unix pipe and pipc
>
> This OK?
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : https://urldefense.proofpoint.com/v2/url?u=http-3A__ibm-2Dnetrexx.215625.n3.nabble.com_&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_6rXNpPJ1fYV-3bV1za02NiR4PUelvicfHXwtnTXpXE&m=NWsXIwzXo5fiymOzlDGjm0RiI2w-OfuuC--6oFaCcPk&s=i5UcEJZ5vn7o8IvRG9hRITxK7OIrv-WIOGsoMTffDGg&e= 
>


_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|

Re: NetRexx 3.08 BETA2

Jason Martin
In reply to this post by rvjansen
Yes, no runner in Unix one.

Thanks.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|

Re: NetRexx 3.08 BETA2

rvjansen
In reply to this post by Rony G. Flatscher
What I would really like is if we could do use BSF so people could take their mainframe execs (mostly called rexx as a filetype if they contain pipeline stuff) and execute them unchanged.

best regards,

René.

On 6 Aug 2019, at 14:25, Rony G. Flatscher <[hidden email]> wrote:

Very interesting, well done! :-)

---rony



_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|

Re: NetRexx 3.08 BETA2

Rony G. Flatscher
On 06.08.2019 23:02, René Jansen wrote:
> What I would really like is if we could do use BSF so people could take their mainframe execs
> (mostly called rexx as a filetype if they contain pipeline stuff) and execute them unchanged.

What would be an execution path that you envision?

In principle it should be already possible now to run such Rexx programs via BSF4ooRexx! There is an
option that allows one to define command handlers (in form of Java/NetRexx classes). There are two
nutshell samples installed with BSF4ooRexx that demonstrate how to do that, cf.
<samples/Java/handlers/commandHandlers>.  In essence you configure a Rexx interpreter instance with
the command handlers before executing the first Rexx program. Sounds difficult, however it is a
"know how" thing and easy, if there are short (nutshell) samples like the once mentioned above.

The samples in "samples/NetRexx" demonstrate how to use BSF4ooRexx to run and communicate with Rexx
programs.

If you have any questions please do not hesitate and ask!

Best regards,

---rony

P.S.: Once ooRexx 5 goes GA I will create a new branch of BSF4ooRexx where I intend to add/exploit
new ooRexx 5 features. One of the intended features is to allow adding command handlers dynamically,
a new feature in ooRexx 5, including support for redirection of stdin, stdout and stderr. That
version of BSF4ooRexx will then require ooRexx 5 to work, hence waiting for it to materialize.


_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|

Re: NetRexx 3.08 BETA2

Rony G. Flatscher
Oh, forgot to mention: the samples for command handlers also demonstrate how to configure the Rexx
instance to use additional filetypes ("externalCallExtensions") such that you could define "rexx"
for it and also how to add directories to the Rexx search path (and define the initial command
environment, preload required external function libraries, etc.; in essences everything the native
ooRexx APIs allow for).

---rony


On 07.08.2019 13:41, Rony G. Flatscher wrote:

> On 06.08.2019 23:02, René Jansen wrote:
>> What I would really like is if we could do use BSF so people could take their mainframe execs
>> (mostly called rexx as a filetype if they contain pipeline stuff) and execute them unchanged.
> What would be an execution path that you envision?
>
> In principle it should be already possible now to run such Rexx programs via BSF4ooRexx! There is an
> option that allows one to define command handlers (in form of Java/NetRexx classes). There are two
> nutshell samples installed with BSF4ooRexx that demonstrate how to do that, cf.
> <samples/Java/handlers/commandHandlers>.  In essence you configure a Rexx interpreter instance with
> the command handlers before executing the first Rexx program. Sounds difficult, however it is a
> "know how" thing and easy, if there are short (nutshell) samples like the once mentioned above.
>
> The samples in "samples/NetRexx" demonstrate how to use BSF4ooRexx to run and communicate with Rexx
> programs.
>
> If you have any questions please do not hesitate and ask!
>
> Best regards,
>
> ---rony
>
> P.S.: Once ooRexx 5 goes GA I will create a new branch of BSF4ooRexx where I intend to add/exploit
> new ooRexx 5 features. One of the intended features is to allow adding command handlers dynamically,
> a new feature in ooRexx 5, including support for redirection of stdin, stdout and stderr. That
> version of BSF4ooRexx will then require ooRexx 5 to work, hence waiting for it to materialize.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|

Re: NetRexx 3.08 BETA2

ThSITC
Hello there,

I did install NetRexx 3.08 BETA2 now, and did re-compile all my own
ancient stuff (still very function oriented) without any unexpected
problems.

My thanks again to Jason Martin for putting the errors at the bottom of
the translators output list.

Looks really very good :-) My congratulations !

Kindly, Thomas Schneider.

PS: am running under Windows 10, and am not using PIPES Yet, however.
Most of my code has been ported from IBM CMS Compiled Classic Rexx to
NetRexx using my own Rexx2Nrx, with my own Runtime Library, since 2002.

The NEW Code, namely my COBOL Parser and my PLI Parser, have been
developped in pure NetRexx, but again in an ancient style (function
oriented).

I am now working on the Code Generating Part again.

===============================================================================================

Am 07.08.2019 um 13:49 schrieb Rony G. Flatscher:

> Oh, forgot to mention: the samples for command handlers also demonstrate how to configure the Rexx
> instance to use additional filetypes ("externalCallExtensions") such that you could define "rexx"
> for it and also how to add directories to the Rexx search path (and define the initial command
> environment, preload required external function libraries, etc.; in essences everything the native
> ooRexx APIs allow for).
>
> ---rony
>
>
> On 07.08.2019 13:41, Rony G. Flatscher wrote:
>> On 06.08.2019 23:02, René Jansen wrote:
>>> What I would really like is if we could do use BSF so people could take their mainframe execs
>>> (mostly called rexx as a filetype if they contain pipeline stuff) and execute them unchanged.
>> What would be an execution path that you envision?
>>
>> In principle it should be already possible now to run such Rexx programs via BSF4ooRexx! There is an
>> option that allows one to define command handlers (in form of Java/NetRexx classes). There are two
>> nutshell samples installed with BSF4ooRexx that demonstrate how to do that, cf.
>> <samples/Java/handlers/commandHandlers>.  In essence you configure a Rexx interpreter instance with
>> the command handlers before executing the first Rexx program. Sounds difficult, however it is a
>> "know how" thing and easy, if there are short (nutshell) samples like the once mentioned above.
>>
>> The samples in "samples/NetRexx" demonstrate how to use BSF4ooRexx to run and communicate with Rexx
>> programs.
>>
>> If you have any questions please do not hesitate and ask!
>>
>> Best regards,
>>
>> ---rony
>>
>> P.S.: Once ooRexx 5 goes GA I will create a new branch of BSF4ooRexx where I intend to add/exploit
>> new ooRexx 5 features. One of the intended features is to allow adding command handlers dynamically,
>> a new feature in ooRexx 5, including support for redirection of stdin, stdout and stderr. That
>> version of BSF4ooRexx will then require ooRexx 5 to work, hence waiting for it to materialize.
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : https://urldefense.proofpoint.com/v2/url?u=http-3A__ibm-2Dnetrexx.215625.n3.nabble.com_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_6rXNpPJ1fYV-3bV1za02NiR4PUelvicfHXwtnTXpXE&m=QOgTtZJON7X4rnL384nyxZZ6lxhFectAuuDHsA9NFJk&s=pQhd5jjaahlNdqSYaSpr4dfQYEY4nrGakTqqtZnQujA&e= 
>

---
This email has been checked for viruses by AVG.
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.avg.com&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_6rXNpPJ1fYV-3bV1za02NiR4PUelvicfHXwtnTXpXE&m=QOgTtZJON7X4rnL384nyxZZ6lxhFectAuuDHsA9NFJk&s=KoZbrGDVh4lcbBEuyuKYFRn6SDlowA1jVD8W5DTfbtY&e= 


_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Thomas Schneider, Vienna, Austria (Europe) :-)

www.thsitc.com
www.db-123.com