Timothy, IMHO it isn't "... consuming non-trivial peak resources running their REXX scripts in TSO/ISPF" that is the issue for alternatives like Netrexx. It is the ability to use TSO facilities (like EXECIO, LISTDSI, etc.) and ISPF utilities like the LMMxxxx routines and other "command" environments that is the issue.
As an application programmer (not a systems programmer any more, though once upon a long-ago time I was), my use of Rexx is mainly for one-off client data and programming research issues. High performance is not usually an issue, flexibility and availability of the tools and subcommand tool sets is the issue. If Netrexx (or ooRexx) can provide the same tool sets then it is a good substitute. Any Rexx replacement that wants to make the grade with me must support the simple (non-object-oriented) syntax of TSO Rexx as well as any exotic enhancements possible because of the OO capabilities. When a problem appears in my task list I have to be able to write the code to research the issue with minimal or no references to the language manual. I just have to get the job done as fast as possible with the available tool sets. Said simply, without the tool sets available in TSO Rexx I can't do my job. Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Timothy Sipples Sent: Thursday, October 26, 2017 1:37 AM To: [email protected] Subject: Re: IBM open sources it's JVM and JIT code David Crayford wrote: >NetRexx is basically a translator that compiles REXX code into Java >source code. That's quite unique. All the other JVM languages compile >to byte code. No, it's not unique in that respect. That's how EGL works, to pick an example. >It has nothing to do with writing user interfaces, it's about writing >scripts. Most z/OS sysprogs do that in the TSO/ISPF environment. OK, but my point is that a programming language (and runtime) can have an enormous amount of business value even if it doesn't directly, specifically help z/OS system programmers write scripts for TSO/ISPF. Java is such an example. JavaScript (Node.js runtime), R, Swift.... There are lots of examples, and right on z/OS, too. If what you describe is a genuine business requirement -- I'm skeptical(*), true, but certainly not opposed! -- then addressing the requirement for Java should automatically address it for NetRexx. OK then, let's knock around some more ideas for Java and NetRexx.... >> How does WebSphere Application Server for z/OS and its ISPF panels work? >>(It works.) >Did you mean z/OSMF? No, I meant WebSphere Application Server for z/OS. It had product-specific ISPF panels prior to WebSphere Application Server Version 8.0 (or prior to Version 7.0?), for administrators to do various "Java things" to manage WAS. I don't remember exactly why the WAS product-specific ISPF panels were dropped in subsequent releases, but I have to assume it was because there wasn't *enough* need for them relative to their upkeep. Anyway, I mentioned them because maybe that particular intersection between the "ISPF world" and the "Java world" could inspire some independent technical solutioning, if you wish. Or maybe they're not a good example technically, but I remember them. (*) REXX exists, interpreted and compiled, and it's lovely. I'm all in favor of resource efficiency. But are z/OS system programmers consuming non-trivial peak resources running their REXX scripts in TSO/ISPF? Don't get me wrong. I'm technically interested in this potential integration, not opposed. At the same time I don't think NetRexx ought to be dismissed out of hand because it doesn't currently support REXX scripts in TSO/ISPF. That doesn't make sense to me at all. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
