www.netrexx.org/examples
Locked
123
123
Re: 3.04 RC2 Pipe Problems - IRange
 
|
René,
Thanks for the quick reply, and all else you do. I can sympathize on keeping the two jars small. But it also makes it harder to distribute "a pipe" to non-NetRexxers. Pipes offer a clear advantage for using NetRexx, and should, IMHO, be as easy to use as possible. Putting everything needed in NetRexxF.jar is a big step in that direction for writing pipes. A single jar, "NetRexxP.jar" (?) for runtime would help in publishing pipes. Jeff On 6/29/2015 3:12 PM, René Jansen
wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: 3.04 RC2 Pipe Problems - IRange
|
|
In reply to this post by Jeff Hennick
I have seen those kinds of errors when options strictassign is used
in a module not written for that option.
On 2015-06-29 12:05 PM, Jeff Hennick
wrote:
When I try to compile the included zonetests.njp I am getting lots of error messages. Here are the first few _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: 3.04 RC2 Pipe Problems - IRange
|
|
In reply to this post by Jeff Hennick
If you have a "standalone" NetRexx application, why not distribute
it as a jar file which includes any required NetRexx modules?
I have actually been considering adding an option to the NetRexx translator to output such a jar file on request. -- Kermit On 2015-06-29 12:29 PM, Jeff Hennick
wrote:
René, _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
I think that is a great idea. René Sent from my iPhone
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
Hear! Hear!
One needs not look far to see the evils of "almost-equal" Rexx implementations (c.f. VMREXX vs. TSO/REXX viz. StreamI/O). StreamI/O is (and has been for a long time) freely _available_ on TSO, but it involves linking a LOADLIB first. Since the author cannot assume the LOADLIB will be there, all manner of machinations are necessary to do I/O on the different platforms. Thus, everyone falls back on the non-Rexx, non-standard, and umm... inelegant, EXECIO. Please let us avoid this sort of problem with NetRexx. -Chip- On 6/29/2015 4:10 PM, René Jansen wrote: > I think that is a great idea. > > René > > Sent from my iPhone > > On 29 Jun 2015, at 22:06, Kermit Kiser <[hidden email] > <mailto:[hidden email]>> wrote: > >> If you have a "standalone" NetRexx application, why not distribute >> it as a jar file which includes any required NetRexx modules? >> >> I have actually been considering adding an option to the NetRexx >> translator to output such a jar file on request. >> >> -- Kermit >> >> On 2015-06-29 12:29 PM, Jeff Hennick wrote: >>> René, >>> >>> Thanks for the quick reply, and all else you do. >>> >>> I can sympathize on keeping the two jars small. But it also makes >>> it harder to distribute "a pipe" to non-NetRexxers. >>> >>> Pipes offer a clear advantage for using NetRexx, and should, IMHO, >>> be as easy to use as possible. Putting everything needed in >>> NetRexxF.jar is a big step in that direction for writing pipes. A >>> single jar, "NetRexxP.jar" (?) for runtime would help in publishing >>> pipes. >>> >>> Jeff >>> >>> On 6/29/2015 3:12 PM, René Jansen wrote: >>>> Hi Jeff, >>>> >>>> Yes, that is true. Pipes are only in NetRexxF.jar, like the >>>> Eclipse compiler. Several people have indicated the need to keep >>>> NetRexxR.jar and NetRexxC.jar as small as possible. >>>> >>>> I'll have a look at the error. >>>> >>>> Best regards, >>>> >>>> René >>>> >>>> Sent from my iPhone >>>> >>>> On 29 Jun 2015, at 21:05, Jeff Hennick <[hidden email] >>>> <mailto:[hidden email]>> wrote: >>>> >>>>> When I try to compile the included zonetests.njp I am getting >>>>> lots of error messages. Here are the first few >>>>> >>>>>> C:\NetRexx\examples\pipes>pipe zonetests >>>>>> >>>>>> C:\NetRexx\examples\pipes>set NJPIPES_HOME=C:\NetRexx\bin\ >>>>>> >>>>>> C:\NetRexx\examples\pipes>java -Dnrx.compiler=ecj -cp >>>>>> ".;C:\NetRexx\lib\NetRexxF.jar" >>>>>> org.netrexx.njpipes.pipes.compiler zonetests >>>>>> pipe (zonet1 ) diskr buffer.data ! zone w2 find 1! console >>>>>> pipe (zonet2 end ?) diskr buffer.data ! a: zone w2 reverse find >>>>>> 1! b: faninany ! console ? a: ! specs /missed:/ 1 1-* next ! b: >>>>>> pipe (zonet3 end ?) diskr buffer.data ! a: zone w3 reverse casei >>>>>> find T ! b: faninany ! console ? a: ! specs /missed:/ 1 >>>>>> 1-* next ! b: >>>>>> pipe (zonet4 end ?) diskr buffer.data ! a: not zone w3 reverse >>>>>> casei find T! b: faninany ! console ? a: ! specs /missed:/ 1 1-* >>>>>> next ! b: >>>>>> pipe (zonet5 ) literal 123 343 456 222 323 ! split ! zone (2.1 >>>>>> 2.1) find 22 ! console >>>>>> pipe (zonet6 ) literal 123 343 456 222 323 ! split ! zone (2.1 >>>>>> -1;-1) find 23 ! console >>>>>> pipe (zonet7 ) literal 123 343 456 222 323 ! split ! zone (1.1 >>>>>> 3.1) find 33 ! console >>>>>> pipe (zonet8 ) literal 123 343 456 222 323 ! split ! zone 2.1 >>>>>> find 2 ! console >>>>>> pipe (zonet9 ) literal 123 343 456 222 323 ! split ! zone >>>>>> (strict 1.2 2.2) find 1223 ! console >>>>>> pipe (zonet10 ) literal 123 343 456 222 323 ! split ! zone find >>>>>> 1223 ! console >>>>>> Error - zonet10 - ZONE expects a range, found: find 1223 >>>>>> Error - Compiling zonet10 RC=13 >>>>>> 118 +++ _c_ = _o_.subword(2,1) >>>>>> +++ ^^^^^^^ >>>>>> +++ Error: The method 'subword(byte,byte)' cannot be found >>>>>> in class 'rexx' or a superclass >>>>>> 132 +++ _c_ = _o_.subword(2,1) >>>>>> +++ ^^^^^^^ >>>>>> +++ Error: The method 'subword(byte,byte)' cannot be found >>>>>> in class 'rexx' or a superclass >>>>>> 143 +++ _ri_ = GetIRanges(a) >>>>>> +++ ^^^^^^^^^^ >>>>>> +++ Error: The method 'GetIRanges(rexx)' cannot be found in >>>>>> class 'zonet1_zone_find_2' or a superclass >>>>>> 144 +++ _nr_ = _ri_[0].Number() >>>>>> +++ ^^^^ >>>>>> +++ Error: Cannot convert value of type 'netrexx.lang.Rexx' >>>>>> for assignment to variable of type 'rexx' >>>>> >>>>> I was trying this because I was having problems with IRanges in a >>>>> stage I was writing. >>>>> >>>>> In searching to find my error, as far as I can tell, pipes >>>>> support is in NetRexxF.jar but not in NetRexxC.jar. Is that true? >>>>> >>>>> _______________________________________________ >>>>> Ibm-netrexx mailing list >>>>> [hidden email] <mailto:[hidden email]> >>>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Ibm-netrexx mailing list >>>> [hidden email] >>>> Online Archive :http://ibm-netrexx.215625.n3.nabble.com/ >>>> >>> >>> >>> >>> _______________________________________________ >>> Ibm-netrexx mailing list >>> [hidden email] >>> Online Archive :http://ibm-netrexx.215625.n3.nabble.com/ >>> >> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] <mailto:[hidden email]> >> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >> > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
- changed the subject line because it really is not pertinent to irange anymore - It would be good if we could enable some ‘tree shaking’ on this packaging, with different gradations of severity. If we look at what RoboVM is implementing in their ’treeshaker’ module, they have three variants: none, which is default, which just includes the libraries used, conservative, which excludes methods marked as @weaklylinked, and aggressive, which strips out everything not reachable by the main class. Of course, we can not annotate yet, but I like the approach - I suspect we will make ourselves not very popular when NetRexxF.jar is required for even the smallest executables. Also, working on a method basis would be good, because, for example, how many times I have used and supplied the entire net.commons jar when I only wanted to do ftp in an app. In comparison to the situation with Classic Rexx and the I/O streams library for example, I am happy that it is a new world nowadays. We see Maven builds just fetching in libraries from the net, and even companies prudent enough to disallow that, have a mechanism to add external libraries to internal repositories that can be used company-wide. The situation with Rexx is also a testament of how unwilling systems programming staff or how clueless management was/is/used to be on this platform. Personally, I either was the systems programmer, or asked someone to install it, so it was always usable. In z/os Unix, it is the standard, so just run your job with bpxbatch and voila, stream I/O. And to fully confess, I like the compactness of execio so I mostly just use it. This is a - z/OS Unix - mainframe exec from two weeks ago: PH01 ~/SDPTEST $ cat SubmitAndCheck.rexx /* REXX */ address mvs "execio * DISKR STDIN (stem JOB. " isfowner = Userid() jobno = SUBMIT(JOB.) say jobno 'submitted by' userid() But yes, a good packaging mechanism that yields a standalone jar for an application would be a great asset to NetRexx. best regards, René.
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
Knowing nothing of "tree-shaking", I'll defer to your judgement on
that René, and comment on what I do know. The following is OT to NetRexx except insofar as it relates to the issue of knowing that a specific feature will be available on all the platforms. The excellently bad example is IBM's screw-up of Rexx StreamI/O. Even if the existing TSO/REXX interpreter were smart enough to go out on the web and pull down the necessary libraries, no z/OS shop in the world would allow it. I don't see that situation changing any time soon. But don't blame the SysProgs, or even their IT Mgmt (as much as they might richly deserve it otherwise). The fundamental problem is that IBM includes VMREXX in the maintenance stream (it's SES-ified) with StreamI/O in the Built-in Function package. On z/OS, TSOREXX is SMTP-ified but the BiF package does not include StreamI/O. Given that security-paranoid environment (which is not necessarily a bad thing) it takes more than an act of Congress to get that Rexx Compiler Runtime LOADLIB accessed on a global basis. Therefore, the TSOREXX environment your program runs in will probably not have the LOADLIB available. IBM could easily fix this but has shown no inclination to even entertain the idea. And the idea that TSOREXX EXECs should be run under USS (which itself may or may not be available) only compounds the problem for the author of a platform-independent Rexx program. As for EXECIO, the _only_ thing it does with any reasonable efficiency is read an entire file to/from a stem. (On z/VM, hanging in a Do-loop on LineIn() is faster than EXECIO * DISKR; don't know about TSO). I suggest that 'PIPE < FOOBAR | stem FB.' is a better (and more universal) tool than EXECIO. OTOH, for any I/O processing that isn't just a pump for an entire stem array, it's better handled by StreamI/O which is much faster, more flexible, and native Rexx. Try doing a "read a record, determine if it has sub-records, read all sub-records, recursively" using EXECIO (inefficient) or PIPE (complex plumbing). And you'll play hell mimicking the CLIST WRITENR command that leaves the cursor at the end of the prompt, without CharOut(). Bottom line, and back on-topic: we need to ensure that the author of a NetRexx program can count on (or control) the necessary features on the target platform. "Balkanization" was no benefit to the Balkans. -Chip- On 6/30/2015 10:29 AM, René Jansen wrote: > - changed the subject line because it really is not pertinent to > irange anymore - > > It would be good if we could enable some ‘tree shaking’ on this > packaging, with different gradations of severity. If we look at what > RoboVM is implementing in their ’treeshaker’ module, they have three > variants: none, which is default, which just includes the libraries > used, conservative, which excludes methods marked as @weaklylinked, > and aggressive, which strips out everything not reachable by the main > class. Of course, we can not annotate yet, but I like the approach - I > suspect we will make ourselves not very popular when NetRexxF.jar is > required for even the smallest executables. Also, working on a method > basis would be good, because, for example, how many times I have used > and supplied the entire net.commons jar when I only wanted to do ftp > in an app. > > In comparison to the situation with Classic Rexx and the I/O streams > library for example, I am happy that it is a new world nowadays. We > see Maven builds just fetching in libraries from the net, and even > companies prudent enough to disallow that, have a mechanism to add > external libraries to internal repositories that can be used > company-wide. The situation with Rexx is also a testament of how > unwilling systems programming staff or how clueless management > was/is/used to be on this platform. Personally, I either was the > systems programmer, or asked someone to install it, so it was always > usable. In z/os Unix, it is the standard, so just run your job with > bpxbatch and voila, stream I/O. And to fully confess, I like the > compactness of execio so I mostly just use it. > > This is a - z/OS Unix - mainframe exec from two weeks ago: > > PH01 ~/SDPTEST $ cat SubmitAndCheck.rexx > /* REXX */ > address mvs "execio * DISKR STDIN (stem JOB. " > isfowner = Userid() > jobno = SUBMIT(JOB.) > say jobno 'submitted by' userid() > I really like how to read a whole file into an array, by indirection > on the commandline. I then address SDSF to check results and copy > spool datasets; everybody can read it because it is nice and compact, > and it would not have been in NetRexx because of the need for a thread > to read console output and several loops for I/O. It is unfortunate > about that paren not being closed - someone called me about that: “I > have found the error!” , but that wasn’t it. (I never knew actually, > can I close it?) > > But yes, a good packaging mechanism that yields a standalone jar for > an application would be a great asset to NetRexx. > > best regards, > > René. > > > >> On 29 jun. 2015, at 22:27, Chip Davis <[hidden email] >> <mailto:[hidden email]>> wrote: >> >> Hear! Hear! >> >> One needs not look far to see the evils of "almost-equal" Rexx >> implementations (c.f. VMREXX vs. TSO/REXX viz. StreamI/O). >> StreamI/O is (and has been for a long time) freely _available_ on >> TSO, but it involves linking a LOADLIB first. Since the author >> cannot assume the LOADLIB will be there, all manner of machinations >> are necessary to do I/O on the different platforms. Thus, everyone >> falls back on the non-Rexx, non-standard, and umm... inelegant, EXECIO. >> >> Please let us avoid this sort of problem with NetRexx. >> >> -Chip- >> >> On 6/29/2015 4:10 PM, René Jansen wrote: >>> I think that is a great idea. >>> >>> René >>> >>> Sent from my iPhone >>> >>> On 29 Jun 2015, at 22:06, Kermit Kiser <[hidden email] >>> <mailto:[hidden email]> >>> <mailto:[hidden email]>> wrote: >>> >>>> If you have a "standalone" NetRexx application, why not distribute >>>> it as a jar file which includes any required NetRexx modules? >>>> >>>> I have actually been considering adding an option to the NetRexx >>>> translator to output such a jar file on request. >>>> > > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
I agree, but for some reason I still don't know what to do differently. We have the case that with NetRexxR.jar one has the runtime support to run most NetRexx programs, but e.g. cannot call the interpreter. The decision to distribute NetRexxF.jar (F for full) had to do with the size of the eclipse compiler. Adding Pipes to that seemed logical, but there is no real reason not to add it to NetRexxC.jar. That would be the minimal functionality including modern things. I regard NetRexxR.jar a curiosity from another era, when we had no bandwidth and really small devices; it is there for whoever needs it (and trust me, whoever needs it would be very cross if we added several 100k to it).
I see the humour of these things popping up on the eve of every release, and I'll probably still release 3.04 tonight - after I address the typo that Jeff reported just when I went to sleep. Let's discuss this further - I remember Fernando mentioning a one jar packaging tool, let's look into that and see if we can get that function added to 4.00 Thanks for your compelling case. Best regards, René. Sent from my iPhone > On 30 Jun 2015, at 18:17, Chip Davis <[hidden email]> wrote: > > Knowing nothing of "tree-shaking", I'll defer to your judgement on that René, and comment on what I do know. > > The following is OT to NetRexx except insofar as it relates to the issue of knowing that a specific feature will be available on all the platforms. The excellently bad example is IBM's screw-up of Rexx StreamI/O. > > Even if the existing TSO/REXX interpreter were smart enough to go out on the web and pull down the necessary libraries, no z/OS shop in the world would allow it. I don't see that situation changing any time soon. > > But don't blame the SysProgs, or even their IT Mgmt (as much as they might richly deserve it otherwise). The fundamental problem is that IBM includes VMREXX in the maintenance stream (it's SES-ified) with StreamI/O in the Built-in Function package. On z/OS, TSOREXX is SMTP-ified but the BiF package does not include StreamI/O. Given that security-paranoid environment (which is not necessarily a bad thing) it takes more than an act of Congress to get that Rexx Compiler Runtime LOADLIB accessed on a global basis. Therefore, the TSOREXX environment your program runs in will probably not have the LOADLIB available. IBM could easily fix this but has shown no inclination to even entertain the idea. > > And the idea that TSOREXX EXECs should be run under USS (which itself may or may not be available) only compounds the problem for the author of a platform-independent Rexx program. > > As for EXECIO, the _only_ thing it does with any reasonable efficiency is read an entire file to/from a stem. (On z/VM, hanging in a Do-loop on LineIn() is faster than EXECIO * DISKR; don't know about TSO). > > I suggest that 'PIPE < FOOBAR | stem FB.' is a better (and more universal) tool than EXECIO. OTOH, for any I/O processing that isn't just a pump for an entire stem array, it's better handled by StreamI/O which is much faster, more flexible, and native Rexx. Try doing a "read a record, determine if it has sub-records, read all sub-records, recursively" using EXECIO (inefficient) or PIPE (complex plumbing). And you'll play hell mimicking the CLIST WRITENR command that leaves the cursor at the end of the prompt, without CharOut(). > > Bottom line, and back on-topic: we need to ensure that the author of a NetRexx program can count on (or control) the necessary features on the target platform. "Balkanization" was no benefit to the Balkans. > > -Chip- > >> On 6/30/2015 10:29 AM, René Jansen wrote: >> - changed the subject line because it really is not pertinent to >> irange anymore - >> >> It would be good if we could enable some ‘tree shaking’ on this >> packaging, with different gradations of severity. If we look at what >> RoboVM is implementing in their ’treeshaker’ module, they have three >> variants: none, which is default, which just includes the libraries >> used, conservative, which excludes methods marked as @weaklylinked, >> and aggressive, which strips out everything not reachable by the main >> class. Of course, we can not annotate yet, but I like the approach - I >> suspect we will make ourselves not very popular when NetRexxF.jar is >> required for even the smallest executables. Also, working on a method >> basis would be good, because, for example, how many times I have used >> and supplied the entire net.commons jar when I only wanted to do ftp >> in an app. >> >> In comparison to the situation with Classic Rexx and the I/O streams >> library for example, I am happy that it is a new world nowadays. We >> see Maven builds just fetching in libraries from the net, and even >> companies prudent enough to disallow that, have a mechanism to add >> external libraries to internal repositories that can be used >> company-wide. The situation with Rexx is also a testament of how >> unwilling systems programming staff or how clueless management >> was/is/used to be on this platform. Personally, I either was the >> systems programmer, or asked someone to install it, so it was always >> usable. In z/os Unix, it is the standard, so just run your job with >> bpxbatch and voila, stream I/O. And to fully confess, I like the >> compactness of execio so I mostly just use it. >> >> This is a - z/OS Unix - mainframe exec from two weeks ago: >> >> PH01 ~/SDPTEST $ cat SubmitAndCheck.rexx >> /* REXX */ >> address mvs "execio * DISKR STDIN (stem JOB. " >> isfowner = Userid() >> jobno = SUBMIT(JOB.) >> say jobno 'submitted by' userid() >> I really like how to read a whole file into an array, by indirection >> on the commandline. I then address SDSF to check results and copy >> spool datasets; everybody can read it because it is nice and compact, >> and it would not have been in NetRexx because of the need for a thread >> to read console output and several loops for I/O. It is unfortunate >> about that paren not being closed - someone called me about that: “I >> have found the error!” , but that wasn’t it. (I never knew actually, >> can I close it?) >> >> But yes, a good packaging mechanism that yields a standalone jar for >> an application would be a great asset to NetRexx. >> >> best regards, >> >> René. >> >> >> >>> On 29 jun. 2015, at 22:27, Chip Davis <[hidden email] >>> <mailto:[hidden email]>> wrote: >>> >>> Hear! Hear! >>> >>> One needs not look far to see the evils of "almost-equal" Rexx >>> implementations (c.f. VMREXX vs. TSO/REXX viz. StreamI/O). >>> StreamI/O is (and has been for a long time) freely _available_ on >>> TSO, but it involves linking a LOADLIB first. Since the author >>> cannot assume the LOADLIB will be there, all manner of machinations >>> are necessary to do I/O on the different platforms. Thus, everyone >>> falls back on the non-Rexx, non-standard, and umm... inelegant, EXECIO. >>> >>> Please let us avoid this sort of problem with NetRexx. >>> >>> -Chip- >>> >>>> On 6/29/2015 4:10 PM, René Jansen wrote: >>>> I think that is a great idea. >>>> >>>> René >>>> >>>> Sent from my iPhone >>>> >>>> On 29 Jun 2015, at 22:06, Kermit Kiser <[hidden email] >>>> <mailto:[hidden email]> >>>> <mailto:[hidden email]>> wrote: >>>> >>>>> If you have a "standalone" NetRexx application, why not distribute >>>>> it as a jar file which includes any required NetRexx modules? >>>>> >>>>> I have actually been considering adding an option to the NetRexx >>>>> translator to output such a jar file on request. >>>>> >> >> >> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >> > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
I am a user of One-JAR and find it useful to bundle jars together to make an application - and I would often use NetRexxR, too (just to be awkward :-) ). The NetRexxR/NetRexxC decision tends to go - "Am I already bloated due to dependencies?" Yes => NetRexxC, No => keep it lean.
One-JAR is not without its faults, and is one of several similar products that achieve much the same thing - I happen to use it but I cannot say whether it is the best of the bunch or not. One small thing in its favour is the BSD-style license. Dave. -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of René Jansen Sent: 01 July 2015 09:04 To: IBM Netrexx Subject: Re: [Ibm-netrexx] packaging NetRexx apps I agree, but for some reason I still don't know what to do differently. We have the case that with NetRexxR.jar one has the runtime support to run most NetRexx programs, but e.g. cannot call the interpreter. The decision to distribute NetRexxF.jar (F for full) had to do with the size of the eclipse compiler. Adding Pipes to that seemed logical, but there is no real reason not to add it to NetRexxC.jar. That would be the minimal functionality including modern things. I regard NetRexxR.jar a curiosity from another era, when we had no bandwidth and really small devices; it is there for whoever needs it (and trust me, whoever needs it would be very cross if we added several 100k to it). I see the humour of these things popping up on the eve of every release, and I'll probably still release 3.04 tonight - after I address the typo that Jeff reported just when I went to sleep. Let's discuss this further - I remember Fernando mentioning a one jar packaging tool, let's look into that and see if we can get that function added to 4.00 Thanks for your compelling case. Best regards, René. Sent from my iPhone > On 30 Jun 2015, at 18:17, Chip Davis <[hidden email]> wrote: > > Knowing nothing of "tree-shaking", I'll defer to your judgement on that René, and comment on what I do know. > > The following is OT to NetRexx except insofar as it relates to the issue of knowing that a specific feature will be available on all the platforms. The excellently bad example is IBM's screw-up of Rexx StreamI/O. > > Even if the existing TSO/REXX interpreter were smart enough to go out on the web and pull down the necessary libraries, no z/OS shop in the world would allow it. I don't see that situation changing any time soon. > > But don't blame the SysProgs, or even their IT Mgmt (as much as they might richly deserve it otherwise). The fundamental problem is that IBM includes VMREXX in the maintenance stream (it's SES-ified) with StreamI/O in the Built-in Function package. On z/OS, TSOREXX is SMTP-ified but the BiF package does not include StreamI/O. Given that security-paranoid environment (which is not necessarily a bad thing) it takes more than an act of Congress to get that Rexx Compiler Runtime LOADLIB accessed on a global basis. Therefore, the TSOREXX environment your program runs in will probably not have the LOADLIB available. IBM could easily fix this but has shown no inclination to even entertain the idea. > > And the idea that TSOREXX EXECs should be run under USS (which itself may or may not be available) only compounds the problem for the author of a platform-independent Rexx program. > > As for EXECIO, the _only_ thing it does with any reasonable efficiency is read an entire file to/from a stem. (On z/VM, hanging in a Do-loop on LineIn() is faster than EXECIO * DISKR; don't know about TSO). > > I suggest that 'PIPE < FOOBAR | stem FB.' is a better (and more universal) tool than EXECIO. OTOH, for any I/O processing that isn't just a pump for an entire stem array, it's better handled by StreamI/O which is much faster, more flexible, and native Rexx. Try doing a "read a record, determine if it has sub-records, read all sub-records, recursively" using EXECIO (inefficient) or PIPE (complex plumbing). And you'll play hell mimicking the CLIST WRITENR command that leaves the cursor at the end of the prompt, without CharOut(). > > Bottom line, and back on-topic: we need to ensure that the author of a NetRexx program can count on (or control) the necessary features on the target platform. "Balkanization" was no benefit to the Balkans. > > -Chip- > >> On 6/30/2015 10:29 AM, René Jansen wrote: >> - changed the subject line because it really is not pertinent to >> irange anymore - >> >> It would be good if we could enable some ‘tree shaking’ on this >> packaging, with different gradations of severity. If we look at what >> RoboVM is implementing in their ’treeshaker’ module, they have three >> variants: none, which is default, which just includes the libraries >> used, conservative, which excludes methods marked as @weaklylinked, >> and aggressive, which strips out everything not reachable by the main >> class. Of course, we can not annotate yet, but I like the approach - >> I suspect we will make ourselves not very popular when NetRexxF.jar >> is required for even the smallest executables. Also, working on a >> method basis would be good, because, for example, how many times I >> have used and supplied the entire net.commons jar when I only wanted >> to do ftp in an app. >> >> In comparison to the situation with Classic Rexx and the I/O streams >> library for example, I am happy that it is a new world nowadays. We >> see Maven builds just fetching in libraries from the net, and even >> companies prudent enough to disallow that, have a mechanism to add >> external libraries to internal repositories that can be used >> company-wide. The situation with Rexx is also a testament of how >> unwilling systems programming staff or how clueless management >> was/is/used to be on this platform. Personally, I either was the >> systems programmer, or asked someone to install it, so it was always >> usable. In z/os Unix, it is the standard, so just run your job with >> bpxbatch and voila, stream I/O. And to fully confess, I like the >> compactness of execio so I mostly just use it. >> >> This is a - z/OS Unix - mainframe exec from two weeks ago: >> >> PH01 ~/SDPTEST $ cat SubmitAndCheck.rexx >> /* REXX */ >> address mvs "execio * DISKR STDIN (stem JOB. " >> isfowner = Userid() >> jobno = SUBMIT(JOB.) >> say jobno 'submitted by' userid() >> I really like how to read a whole file into an array, by indirection >> on the commandline. I then address SDSF to check results and copy >> spool datasets; everybody can read it because it is nice and compact, >> and it would not have been in NetRexx because of the need for a >> thread to read console output and several loops for I/O. It is >> unfortunate about that paren not being closed - someone called me >> about that: “I have found the error!” , but that wasn’t it. (I never >> knew actually, can I close it?) >> >> But yes, a good packaging mechanism that yields a standalone jar for >> an application would be a great asset to NetRexx. >> >> best regards, >> >> René. >> >> >> >>> On 29 jun. 2015, at 22:27, Chip Davis <[hidden email] >>> <mailto:[hidden email]>> wrote: >>> >>> Hear! Hear! >>> >>> One needs not look far to see the evils of "almost-equal" Rexx >>> implementations (c.f. VMREXX vs. TSO/REXX viz. StreamI/O). >>> StreamI/O is (and has been for a long time) freely _available_ on >>> TSO, but it involves linking a LOADLIB first. Since the author >>> cannot assume the LOADLIB will be there, all manner of machinations >>> are necessary to do I/O on the different platforms. Thus, everyone >>> falls back on the non-Rexx, non-standard, and umm... inelegant, EXECIO. >>> >>> Please let us avoid this sort of problem with NetRexx. >>> >>> -Chip- >>> >>>> On 6/29/2015 4:10 PM, René Jansen wrote: >>>> I think that is a great idea. >>>> >>>> René >>>> >>>> Sent from my iPhone >>>> >>>> On 29 Jun 2015, at 22:06, Kermit Kiser <[hidden email] >>>> <mailto:[hidden email]> <mailto:[hidden email]>> >>>> wrote: >>>> >>>>> If you have a "standalone" NetRexx application, why not distribute >>>>> it as a jar file which includes any required NetRexx modules? >>>>> >>>>> I have actually been considering adding an option to the NetRexx >>>>> translator to output such a jar file on request. >>>>> >> >> >> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >> > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: packaging NetRexx apps
|
|
In reply to this post by rvjansen
I am currently working on repackaging some of my NetRexx applications, multiple class files into one jar and yes would like to include the runtime classes need from NetRexxR.jar too, so I can distribute my jar with all apps in it as one single jar...
I would be happy with just a list of classes used by my NetRexx apps, now I just unpack NetRexxR.jar and repackage all class file into my jar. So yes I would welcome this feature, but not for one NetRexx app, but also a number into one jar... My 2 cents on this Michael -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of René Jansen Sent: woensdag 1 juli 2015 10:04 To: IBM Netrexx Subject: Re: [Ibm-netrexx] packaging NetRexx apps I agree, but for some reason I still don't know what to do differently. We have the case that with NetRexxR.jar one has the runtime support to run most NetRexx programs, but e.g. cannot call the interpreter. The decision to distribute NetRexxF.jar (F for full) had to do with the size of the eclipse compiler. Adding Pipes to that seemed logical, but there is no real reason not to add it to NetRexxC.jar. That would be the minimal functionality including modern things. I regard NetRexxR.jar a curiosity from another era, when we had no bandwidth and really small devices; it is there for whoever needs it (and trust me, whoever needs it would be very cross if we added several 100k to it). I see the humour of these things popping up on the eve of every release, and I'll probably still release 3.04 tonight - after I address the typo that Jeff reported just when I went to sleep. Let's discuss this further - I remember Fernando mentioning a one jar packaging tool, let's look into that and see if we can get that function added to 4.00 Thanks for your compelling case. Best regards, René. Sent from my iPhone > On 30 Jun 2015, at 18:17, Chip Davis <[hidden email]> wrote: > > Knowing nothing of "tree-shaking", I'll defer to your judgement on that René, and comment on what I do know. > > The following is OT to NetRexx except insofar as it relates to the issue of knowing that a specific feature will be available on all the platforms. The excellently bad example is IBM's screw-up of Rexx StreamI/O. > > Even if the existing TSO/REXX interpreter were smart enough to go out on the web and pull down the necessary libraries, no z/OS shop in the world would allow it. I don't see that situation changing any time soon. > > But don't blame the SysProgs, or even their IT Mgmt (as much as they might richly deserve it otherwise). The fundamental problem is that IBM includes VMREXX in the maintenance stream (it's SES-ified) with StreamI/O in the Built-in Function package. On z/OS, TSOREXX is SMTP-ified but the BiF package does not include StreamI/O. Given that security-paranoid environment (which is not necessarily a bad thing) it takes more than an act of Congress to get that Rexx Compiler Runtime LOADLIB accessed on a global basis. Therefore, the TSOREXX environment your program runs in will probably not have the LOADLIB available. IBM could easily fix this but has shown no inclination to even entertain the idea. > > And the idea that TSOREXX EXECs should be run under USS (which itself may or may not be available) only compounds the problem for the author of a platform-independent Rexx program. > > As for EXECIO, the _only_ thing it does with any reasonable efficiency is read an entire file to/from a stem. (On z/VM, hanging in a Do-loop on LineIn() is faster than EXECIO * DISKR; don't know about TSO). > > I suggest that 'PIPE < FOOBAR | stem FB.' is a better (and more universal) tool than EXECIO. OTOH, for any I/O processing that isn't just a pump for an entire stem array, it's better handled by StreamI/O which is much faster, more flexible, and native Rexx. Try doing a "read a record, determine if it has sub-records, read all sub-records, recursively" using EXECIO (inefficient) or PIPE (complex plumbing). And you'll play hell mimicking the CLIST WRITENR command that leaves the cursor at the end of the prompt, without CharOut(). > > Bottom line, and back on-topic: we need to ensure that the author of a NetRexx program can count on (or control) the necessary features on the target platform. "Balkanization" was no benefit to the Balkans. > > -Chip- > >> On 6/30/2015 10:29 AM, René Jansen wrote: >> - changed the subject line because it really is not pertinent to >> irange anymore - >> >> It would be good if we could enable some ‘tree shaking’ on this >> packaging, with different gradations of severity. If we look at what >> RoboVM is implementing in their ’treeshaker’ module, they have three >> variants: none, which is default, which just includes the libraries >> used, conservative, which excludes methods marked as @weaklylinked, >> and aggressive, which strips out everything not reachable by the main >> class. Of course, we can not annotate yet, but I like the approach - >> I suspect we will make ourselves not very popular when NetRexxF.jar >> is required for even the smallest executables. Also, working on a >> method basis would be good, because, for example, how many times I >> have used and supplied the entire net.commons jar when I only wanted >> to do ftp in an app. >> >> In comparison to the situation with Classic Rexx and the I/O streams >> library for example, I am happy that it is a new world nowadays. We >> see Maven builds just fetching in libraries from the net, and even >> companies prudent enough to disallow that, have a mechanism to add >> external libraries to internal repositories that can be used >> company-wide. The situation with Rexx is also a testament of how >> unwilling systems programming staff or how clueless management >> was/is/used to be on this platform. Personally, I either was the >> systems programmer, or asked someone to install it, so it was always >> usable. In z/os Unix, it is the standard, so just run your job with >> bpxbatch and voila, stream I/O. And to fully confess, I like the >> compactness of execio so I mostly just use it. >> >> This is a - z/OS Unix - mainframe exec from two weeks ago: >> >> PH01 ~/SDPTEST $ cat SubmitAndCheck.rexx >> /* REXX */ >> address mvs "execio * DISKR STDIN (stem JOB. " >> isfowner = Userid() >> jobno = SUBMIT(JOB.) >> say jobno 'submitted by' userid() >> I really like how to read a whole file into an array, by indirection >> on the commandline. I then address SDSF to check results and copy >> spool datasets; everybody can read it because it is nice and compact, >> and it would not have been in NetRexx because of the need for a >> thread to read console output and several loops for I/O. It is >> unfortunate about that paren not being closed - someone called me >> about that: “I have found the error!” , but that wasn’t it. (I never >> knew actually, can I close it?) >> >> But yes, a good packaging mechanism that yields a standalone jar for >> an application would be a great asset to NetRexx. >> >> best regards, >> >> René. >> >> >> >>> On 29 jun. 2015, at 22:27, Chip Davis <[hidden email] >>> <mailto:[hidden email]>> wrote: >>> >>> Hear! Hear! >>> >>> One needs not look far to see the evils of "almost-equal" Rexx >>> implementations (c.f. VMREXX vs. TSO/REXX viz. StreamI/O). >>> StreamI/O is (and has been for a long time) freely _available_ on >>> TSO, but it involves linking a LOADLIB first. Since the author >>> cannot assume the LOADLIB will be there, all manner of machinations >>> are necessary to do I/O on the different platforms. Thus, everyone >>> falls back on the non-Rexx, non-standard, and umm... inelegant, EXECIO. >>> >>> Please let us avoid this sort of problem with NetRexx. >>> >>> -Chip- >>> >>>> On 6/29/2015 4:10 PM, René Jansen wrote: >>>> I think that is a great idea. >>>> >>>> René >>>> >>>> Sent from my iPhone >>>> >>>> On 29 Jun 2015, at 22:06, Kermit Kiser <[hidden email] >>>> <mailto:[hidden email]> <mailto:[hidden email]>> >>>> wrote: >>>> >>>>> If you have a "standalone" NetRexx application, why not distribute >>>>> it as a jar file which includes any required NetRexx modules? >>>>> >>>>> I have actually been considering adding an option to the NetRexx >>>>> translator to output such a jar file on request. >>>>> >> >> >> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >> > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
I see a link to the work on dependencies that I already was planning to do. If you start your app with java -verbose you will get a list you maybe already can work with.
best regards, René. > On 1 jul. 2015, at 10:43, [hidden email] wrote: > > I am currently working on repackaging some of my NetRexx applications, multiple class files into one jar and yes would like to include the runtime classes need from NetRexxR.jar too, so I can distribute my jar with all apps in it as one single jar... > > I would be happy with just a list of classes used by my NetRexx apps, now I just unpack NetRexxR.jar and repackage all class file into my jar. > > So yes I would welcome this feature, but not for one NetRexx app, but also a number into one jar... > > My 2 cents on this > > Michael > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of René Jansen > Sent: woensdag 1 juli 2015 10:04 > To: IBM Netrexx > Subject: Re: [Ibm-netrexx] packaging NetRexx apps > > I agree, but for some reason I still don't know what to do differently. We have the case that with NetRexxR.jar one has the runtime support to run most NetRexx programs, but e.g. cannot call the interpreter. The decision to distribute NetRexxF.jar (F for full) had to do with the size of the eclipse compiler. Adding Pipes to that seemed logical, but there is no real reason not to add it to NetRexxC.jar. That would be the minimal functionality including modern things. I regard NetRexxR.jar a curiosity from another era, when we had no bandwidth and really small devices; it is there for whoever needs it (and trust me, whoever needs it would be very cross if we added several 100k to it). > > I see the humour of these things popping up on the eve of every release, and I'll probably still release 3.04 tonight - after I address the typo that Jeff reported just when I went to sleep. > > Let's discuss this further - I remember Fernando mentioning a one jar packaging tool, let's look into that and see if we can get that function added to 4.00 > > Thanks for your compelling case. > > Best regards, > > René. > > Sent from my iPhone > >> On 30 Jun 2015, at 18:17, Chip Davis <[hidden email]> wrote: >> >> Knowing nothing of "tree-shaking", I'll defer to your judgement on that René, and comment on what I do know. >> >> The following is OT to NetRexx except insofar as it relates to the issue of knowing that a specific feature will be available on all the platforms. The excellently bad example is IBM's screw-up of Rexx StreamI/O. >> >> Even if the existing TSO/REXX interpreter were smart enough to go out on the web and pull down the necessary libraries, no z/OS shop in the world would allow it. I don't see that situation changing any time soon. >> >> But don't blame the SysProgs, or even their IT Mgmt (as much as they might richly deserve it otherwise). The fundamental problem is that IBM includes VMREXX in the maintenance stream (it's SES-ified) with StreamI/O in the Built-in Function package. On z/OS, TSOREXX is SMTP-ified but the BiF package does not include StreamI/O. Given that security-paranoid environment (which is not necessarily a bad thing) it takes more than an act of Congress to get that Rexx Compiler Runtime LOADLIB accessed on a global basis. Therefore, the TSOREXX environment your program runs in will probably not have the LOADLIB available. IBM could easily fix this but has shown no inclination to even entertain the idea. >> >> And the idea that TSOREXX EXECs should be run under USS (which itself may or may not be available) only compounds the problem for the author of a platform-independent Rexx program. >> >> As for EXECIO, the _only_ thing it does with any reasonable efficiency is read an entire file to/from a stem. (On z/VM, hanging in a Do-loop on LineIn() is faster than EXECIO * DISKR; don't know about TSO). >> >> I suggest that 'PIPE < FOOBAR | stem FB.' is a better (and more universal) tool than EXECIO. OTOH, for any I/O processing that isn't just a pump for an entire stem array, it's better handled by StreamI/O which is much faster, more flexible, and native Rexx. Try doing a "read a record, determine if it has sub-records, read all sub-records, recursively" using EXECIO (inefficient) or PIPE (complex plumbing). And you'll play hell mimicking the CLIST WRITENR command that leaves the cursor at the end of the prompt, without CharOut(). >> >> Bottom line, and back on-topic: we need to ensure that the author of a NetRexx program can count on (or control) the necessary features on the target platform. "Balkanization" was no benefit to the Balkans. >> >> -Chip- >> >>> On 6/30/2015 10:29 AM, René Jansen wrote: >>> - changed the subject line because it really is not pertinent to >>> irange anymore - >>> >>> It would be good if we could enable some ‘tree shaking’ on this >>> packaging, with different gradations of severity. If we look at what >>> RoboVM is implementing in their ’treeshaker’ module, they have three >>> variants: none, which is default, which just includes the libraries >>> used, conservative, which excludes methods marked as @weaklylinked, >>> and aggressive, which strips out everything not reachable by the main >>> class. Of course, we can not annotate yet, but I like the approach - >>> I suspect we will make ourselves not very popular when NetRexxF.jar >>> is required for even the smallest executables. Also, working on a >>> method basis would be good, because, for example, how many times I >>> have used and supplied the entire net.commons jar when I only wanted >>> to do ftp in an app. >>> >>> In comparison to the situation with Classic Rexx and the I/O streams >>> library for example, I am happy that it is a new world nowadays. We >>> see Maven builds just fetching in libraries from the net, and even >>> companies prudent enough to disallow that, have a mechanism to add >>> external libraries to internal repositories that can be used >>> company-wide. The situation with Rexx is also a testament of how >>> unwilling systems programming staff or how clueless management >>> was/is/used to be on this platform. Personally, I either was the >>> systems programmer, or asked someone to install it, so it was always >>> usable. In z/os Unix, it is the standard, so just run your job with >>> bpxbatch and voila, stream I/O. And to fully confess, I like the >>> compactness of execio so I mostly just use it. >>> >>> This is a - z/OS Unix - mainframe exec from two weeks ago: >>> >>> PH01 ~/SDPTEST $ cat SubmitAndCheck.rexx >>> /* REXX */ >>> address mvs "execio * DISKR STDIN (stem JOB. " >>> isfowner = Userid() >>> jobno = SUBMIT(JOB.) >>> say jobno 'submitted by' userid() >>> I really like how to read a whole file into an array, by indirection >>> on the commandline. I then address SDSF to check results and copy >>> spool datasets; everybody can read it because it is nice and compact, >>> and it would not have been in NetRexx because of the need for a >>> thread to read console output and several loops for I/O. It is >>> unfortunate about that paren not being closed - someone called me >>> about that: “I have found the error!” , but that wasn’t it. (I never >>> knew actually, can I close it?) >>> >>> But yes, a good packaging mechanism that yields a standalone jar for >>> an application would be a great asset to NetRexx. >>> >>> best regards, >>> >>> René. >>> >>> >>> >>>> On 29 jun. 2015, at 22:27, Chip Davis <[hidden email] >>>> <mailto:[hidden email]>> wrote: >>>> >>>> Hear! Hear! >>>> >>>> One needs not look far to see the evils of "almost-equal" Rexx >>>> implementations (c.f. VMREXX vs. TSO/REXX viz. StreamI/O). >>>> StreamI/O is (and has been for a long time) freely _available_ on >>>> TSO, but it involves linking a LOADLIB first. Since the author >>>> cannot assume the LOADLIB will be there, all manner of machinations >>>> are necessary to do I/O on the different platforms. Thus, everyone >>>> falls back on the non-Rexx, non-standard, and umm... inelegant, EXECIO. >>>> >>>> Please let us avoid this sort of problem with NetRexx. >>>> >>>> -Chip- >>>> >>>>> On 6/29/2015 4:10 PM, René Jansen wrote: >>>>> I think that is a great idea. >>>>> >>>>> René >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On 29 Jun 2015, at 22:06, Kermit Kiser <[hidden email] >>>>> <mailto:[hidden email]> <mailto:[hidden email]>> >>>>> wrote: >>>>> >>>>>> If you have a "standalone" NetRexx application, why not distribute >>>>>> it as a jar file which includes any required NetRexx modules? >>>>>> >>>>>> I have actually been considering adding an option to the NetRexx >>>>>> translator to output such a jar file on request. >>>>>> >>> >>> >>> >>> _______________________________________________ >>> Ibm-netrexx mailing list >>> [hidden email] >>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >>> >> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >> > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by rvjansen
René --
Please do not delay 3.04GA on account of this packaging issue! I am sorry I raised it at this time. We can still do a 3.05 this year if you find any of the recent issues critical to address in the near future. NetRexx version 4.00 requires language syntax changes that do not yet have ARB input on format/features/etc. (regexp, enums, generics, lambdas, annotations, etc.) Can't do much for it yet. -- Kermit On 2015-07-01 1:04 AM, René Jansen wrote: > I agree, but for some reason I still don't know what to do differently. We have the case that with NetRexxR.jar one has the runtime support to run most NetRexx programs, but e.g. cannot call the interpreter. The decision to distribute NetRexxF.jar (F for full) had to do with the size of the eclipse compiler. Adding Pipes to that seemed logical, but there is no real reason not to add it to NetRexxC.jar. That would be the minimal functionality including modern things. I regard NetRexxR.jar a curiosity from another era, when we had no bandwidth and really small devices; it is there for whoever needs it (and trust me, whoever needs it would be very cross if we added several 100k to it). > > I see the humour of these things popping up on the eve of every release, and I'll probably still release 3.04 tonight - after I address the typo that Jeff reported just when I went to sleep. > > Let's discuss this further - I remember Fernando mentioning a one jar packaging tool, let's look into that and see if we can get that function added to 4.00 > > Thanks for your compelling case. > > Best regards, > > René. > > Sent from my iPhone > >> On 30 Jun 2015, at 18:17, Chip Davis <[hidden email]> wrote: >> >> Knowing nothing of "tree-shaking", I'll defer to your judgement on that René, and comment on what I do know. >> >> The following is OT to NetRexx except insofar as it relates to the issue of knowing that a specific feature will be available on all the platforms. The excellently bad example is IBM's screw-up of Rexx StreamI/O. >> >> Even if the existing TSO/REXX interpreter were smart enough to go out on the web and pull down the necessary libraries, no z/OS shop in the world would allow it. I don't see that situation changing any time soon. >> >> But don't blame the SysProgs, or even their IT Mgmt (as much as they might richly deserve it otherwise). The fundamental problem is that IBM includes VMREXX in the maintenance stream (it's SES-ified) with StreamI/O in the Built-in Function package. On z/OS, TSOREXX is SMTP-ified but the BiF package does not include StreamI/O. Given that security-paranoid environment (which is not necessarily a bad thing) it takes more than an act of Congress to get that Rexx Compiler Runtime LOADLIB accessed on a global basis. Therefore, the TSOREXX environment your program runs in will probably not have the LOADLIB available. IBM could easily fix this but has shown no inclination to even entertain the idea. >> >> And the idea that TSOREXX EXECs should be run under USS (which itself may or may not be available) only compounds the problem for the author of a platform-independent Rexx program. >> >> As for EXECIO, the _only_ thing it does with any reasonable efficiency is read an entire file to/from a stem. (On z/VM, hanging in a Do-loop on LineIn() is faster than EXECIO * DISKR; don't know about TSO). >> >> I suggest that 'PIPE < FOOBAR | stem FB.' is a better (and more universal) tool than EXECIO. OTOH, for any I/O processing that isn't just a pump for an entire stem array, it's better handled by StreamI/O which is much faster, more flexible, and native Rexx. Try doing a "read a record, determine if it has sub-records, read all sub-records, recursively" using EXECIO (inefficient) or PIPE (complex plumbing). And you'll play hell mimicking the CLIST WRITENR command that leaves the cursor at the end of the prompt, without CharOut(). >> >> Bottom line, and back on-topic: we need to ensure that the author of a NetRexx program can count on (or control) the necessary features on the target platform. "Balkanization" was no benefit to the Balkans. >> >> -Chip- >> >>> On 6/30/2015 10:29 AM, René Jansen wrote: >>> - changed the subject line because it really is not pertinent to >>> irange anymore - >>> >>> It would be good if we could enable some ‘tree shaking’ on this >>> packaging, with different gradations of severity. If we look at what >>> RoboVM is implementing in their ’treeshaker’ module, they have three >>> variants: none, which is default, which just includes the libraries >>> used, conservative, which excludes methods marked as @weaklylinked, >>> and aggressive, which strips out everything not reachable by the main >>> class. Of course, we can not annotate yet, but I like the approach - I >>> suspect we will make ourselves not very popular when NetRexxF.jar is >>> required for even the smallest executables. Also, working on a method >>> basis would be good, because, for example, how many times I have used >>> and supplied the entire net.commons jar when I only wanted to do ftp >>> in an app. >>> >>> In comparison to the situation with Classic Rexx and the I/O streams >>> library for example, I am happy that it is a new world nowadays. We >>> see Maven builds just fetching in libraries from the net, and even >>> companies prudent enough to disallow that, have a mechanism to add >>> external libraries to internal repositories that can be used >>> company-wide. The situation with Rexx is also a testament of how >>> unwilling systems programming staff or how clueless management >>> was/is/used to be on this platform. Personally, I either was the >>> systems programmer, or asked someone to install it, so it was always >>> usable. In z/os Unix, it is the standard, so just run your job with >>> bpxbatch and voila, stream I/O. And to fully confess, I like the >>> compactness of execio so I mostly just use it. >>> >>> This is a - z/OS Unix - mainframe exec from two weeks ago: >>> >>> PH01 ~/SDPTEST $ cat SubmitAndCheck.rexx >>> /* REXX */ >>> address mvs "execio * DISKR STDIN (stem JOB. " >>> isfowner = Userid() >>> jobno = SUBMIT(JOB.) >>> say jobno 'submitted by' userid() >>> I really like how to read a whole file into an array, by indirection >>> on the commandline. I then address SDSF to check results and copy >>> spool datasets; everybody can read it because it is nice and compact, >>> and it would not have been in NetRexx because of the need for a thread >>> to read console output and several loops for I/O. It is unfortunate >>> about that paren not being closed - someone called me about that: “I >>> have found the error!” , but that wasn’t it. (I never knew actually, >>> can I close it?) >>> >>> But yes, a good packaging mechanism that yields a standalone jar for >>> an application would be a great asset to NetRexx. >>> >>> best regards, >>> >>> René. >>> >>> >>> >>>> On 29 jun. 2015, at 22:27, Chip Davis <[hidden email] >>>> <mailto:[hidden email]>> wrote: >>>> >>>> Hear! Hear! >>>> >>>> One needs not look far to see the evils of "almost-equal" Rexx >>>> implementations (c.f. VMREXX vs. TSO/REXX viz. StreamI/O). >>>> StreamI/O is (and has been for a long time) freely _available_ on >>>> TSO, but it involves linking a LOADLIB first. Since the author >>>> cannot assume the LOADLIB will be there, all manner of machinations >>>> are necessary to do I/O on the different platforms. Thus, everyone >>>> falls back on the non-Rexx, non-standard, and umm... inelegant, EXECIO. >>>> >>>> Please let us avoid this sort of problem with NetRexx. >>>> >>>> -Chip- >>>> >>>>> On 6/29/2015 4:10 PM, René Jansen wrote: >>>>> I think that is a great idea. >>>>> >>>>> René >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On 29 Jun 2015, at 22:06, Kermit Kiser <[hidden email] >>>>> <mailto:[hidden email]> >>>>> <mailto:[hidden email]>> wrote: >>>>> >>>>>> If you have a "standalone" NetRexx application, why not distribute >>>>>> it as a jar file which includes any required NetRexx modules? >>>>>> >>>>>> I have actually been considering adding an option to the NetRexx >>>>>> translator to output such a jar file on request. >>>>>> >>> >>> >>> _______________________________________________ >>> Ibm-netrexx mailing list >>> [hidden email] >>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >>> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >> > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
Hi Kermit,
no, I won’t, it will go up any minute now. I think 4.00 (or even 3.05) is the release to address this in. Pipes support is less complete than I wanted anyway (way too busy to finish the manual, which executes all its examples … neat but not too efficient in writing effort - everything I write has to be true now! (that is a joke, for those who doubted that a moment), but its time has come and we can discuss everything for what comes in the next release. I am convinced that 3.04 is so much better than 3.03 that we have to let it escape now. best regards, René. > On 1 jul. 2015, at 23:01, Kermit Kiser <[hidden email]> wrote: > > René -- > > Please do not delay 3.04GA on account of this packaging issue! > > I am sorry I raised it at this time. > > We can still do a 3.05 this year if you find any of the recent issues critical to address in the near future. NetRexx version 4.00 requires language syntax changes that do not yet have ARB input on format/features/etc. (regexp, enums, generics, lambdas, annotations, etc.) Can't do much for it yet. > > -- Kermit > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
«
Return to ibm-netrexx
|
1 view|%1 views
| Free forum by Nabble | Edit this page |