Re: IBM open sources it's JVM and JIT code

[Farley, Peter x23353]

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 LMM 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:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Timothy Sipples
Sent: Thursday, October 26, 2017 1:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM open sources it's JVM and JIT code

[Jack J. Woehr]

On 10/25/2017 11:37 PM, Timothy Sipples wrote:

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.



Thought for the Day :)


--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM open sources it's JVM and JIT code

[Timothy Sipples]

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.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM open sources it's JVM and JIT code

[Paul Gilmartin]

On Wed, 25 Oct 2017 15:35:38 +0800, Timothy Sipples wrote:
>
>To add to Walt's point (a bit, and roughly), I'm pretty sure it's possible
>and not hard for REXX (TSO/E, ISPF) to call Java and thus NetRexx. 
>
>Unless I'm missing some other point?
> 
The issue that appears to concern David is much tthe opposite:  Not whether
TSO can call NetRexx, but that NetRexx is impoverished in its repertoire of
host command environments.  Too many valuable services are needlessly
inextricably embedded in the TMP.  Examples are TRANSMIT, RECEIVE,
LISTDS, ...

In 1987, when TSO was riding high, designers may have thought it wise to
make these TSO services.  Now, that seems wrong; better would be to
have //STEP EXEC PGM=TRANSMIT; etc. with wrapping TSO commands, as
was done with IDCAMS services, available either from JCL or as TSO commands.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM open sources it's JVM and JIT code

[David Crayford]

On 25/10/2017 3:35 PM, Timothy Sipples wrote:

David Crayford wrote:

NetRexx can't be used in TSO/ISPF environments which is why it's not
popular on z/OS.

The other commenters have raised some good points. I'd like to raise this
question: especially in 2017 and beyond, is it a grave problem if your end
users don't use TSO/E and ISPF user interfaces to enjoy applications
written in NetRexx? That they use, as notable examples, a Web or mobile
user interface instead?


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.



Maybe back in 1987 this omission was a "Dead on Arrival" showstopper, but
now? OK, if it is a showstopper for you, Walt provided some good ideas to
pursue for any/every programming language and runtime that requires such
integration. (Reports welcome!) But is it a genuine showstopper, or are you
the showstopper? :-)


I'm not the showstopper, I'm a realist. If you had a better grasp of the 
technical details your comments would have more credibility.



To add to Walt's point (a bit, and roughly), I'm pretty sure it's possible
and not hard for REXX (TSO/E, ISPF) to call Java and thus NetRexx. So you
should be able to create a hybrid application rather easily and
straightforwardly, with a REXX user interface calling NetRexx program
logic, both components of course written in the REXX programming language.
You can also work such magic very easily in CICS Transaction Server, and
even keep your NetRexx logic in a separate region ("AOR") from your REXX
classic user interface ("TOR"). Somewhere I read in an application
programming book that logically separating presentation logic from business
logic is a good idea. :-) You can take the same basic approach in IMS TM.


I can't think of a good reason to call bpxwunix() to invoke a Java 
program when I can do everything I want natively.



How does WebSphere Application Server for z/OS and its ISPF panels work?
(It works.)


Did you mean z/OSMF? The ISPF interface in z/OSMF is a white elephant 
while users still have 3270 emulators. In fact, z/OSMF is not that great.
I want to love it but when I hang in unresponsive JavaScript dojo code 
it's hard to love it! Give me green screen SDSF any day of the week.



Unless I'm missing some other point?


As usual!




Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM open sources it's JVM and JIT code

[David Crayford]

On 25/10/2017 2:51 AM, Tony Harminc wrote:

What's the obstacle (not to popularity, but to TSO toleration)?


One can certainly write a Rexx interpreter (or compiler, for that matter),
and run it under TSO and/or ISPF; in that sense it*tolerates*  those
environments. But for reasons known only to IBM, the interfaces needed to
implement*integration*  with the TSO/E and ISPF environments are
undocumented. It used to be possible to write one's own Terminal Monitor
Program (TMP), and there was even a book describing how to do so. With
TSO/E that book was dropped, and while one can guess at much of what needs
to be done, there are OCO control blocks and interfaces that inhibit
implementing interfaces like Address TSO and Address ISPF.

Of course the same thing inhibits implementing Lua or Python or  in the TSO/E environment as much as it does
competitive Rexxs.


TSO is easy to integrate using IKJEFTSR in C Lua modules.

-- REXX --
call outtrap 'o.'
"LISTALC"
do i = 1 to o.0 say o.i end

-- Lua --
local o = tso.exec("LISTALC")
for line in o do print(line) end

ISPF is difficult. That's where the real integration with REXX works 
nicely, the binding between REXX variables and the ISPF function 
variable pool. And you're right, there's no published API
to do something similar. A service that could return a list similar to 
option 7.3 would make this easy. But even then it's not ideal in 
languages with lexical scoping to "pollute" the environment with global 
variables.  For Lua I decided to map ISPF variables to tables using the 
VDEFINE service. The variables are cleaned up with VDELETE when the 
garbage collector destroys the table or explicitly with a release() 
function.


local row = ispf.bind {
  { "name", "char", 20 },
  { "age", "int" },
  { "addr", "char", 60 },
}

ispexec("TBCREATE TAB NAMES(NAME,AGE,ADDR) NOWRITE REPLACE")
row.name = "Sherlock"
row.age = 64
row.addr = "221b Baker Street"
ispexec("TBADD TAB")

Of course, this looks like a step down. It's more code and strings are 
fixed length. But the real benefit over REXX comes with modules. I find 
with REXX it's impossible to apply the DRY principle.


-- REXX --

"LMINIT DATAID(ID) DATASET(DSNAME) ENQ(SHR)"
"LMOPEN DATAID() OPTION(INPUT)"
member = ''
do forever
  "LMMLIST DATAID() OPTION(LIST) MEMBER(MEMBER)"
  if rc > 0 then leave
  say member
end
"LMCLOSE DATAID()"
"LMFREE  DATAID()"

-- Lua --

local ISPF = require("ISPF")
ISPF.MemberList(dsname, "SHR"):foreach(function (member) 
print(member.name) end)


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM open sources it's JVM and JIT code

[Timothy Sipples]

David Crayford wrote:
>NetRexx can't be used in TSO/ISPF environments which is why it's not
>popular on z/OS.

The other commenters have raised some good points. I'd like to raise this
question: especially in 2017 and beyond, is it a grave problem if your end
users don't use TSO/E and ISPF user interfaces to enjoy applications
written in NetRexx? That they use, as notable examples, a Web or mobile
user interface instead?

Maybe back in 1987 this omission was a "Dead on Arrival" showstopper, but
now? OK, if it is a showstopper for you, Walt provided some good ideas to
pursue for any/every programming language and runtime that requires such
integration. (Reports welcome!) But is it a genuine showstopper, or are you
the showstopper? :-)

To add to Walt's point (a bit, and roughly), I'm pretty sure it's possible
and not hard for REXX (TSO/E, ISPF) to call Java and thus NetRexx. So you
should be able to create a hybrid application rather easily and
straightforwardly, with a REXX user interface calling NetRexx program
logic, both components of course written in the REXX programming language.
You can also work such magic very easily in CICS Transaction Server, and
even keep your NetRexx logic in a separate region ("AOR") from your REXX
classic user interface ("TOR"). Somewhere I read in an application
programming book that logically separating presentation logic from business
logic is a good idea. :-) You can take the same basic approach in IMS TM.

How does WebSphere Application Server for z/OS and its ISPF panels work?
(It works.)

Unless I'm missing some other point?


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM open sources it's JVM and JIT code

[David Crayford]

On 25/10/2017 1:02 AM, Paul Gilmartin wrote:

On Tue, 24 Oct 2017 14:27:13 +0800, David Crayford wrote:


NetRexx can't be used in TSO/ISPF environments which is why it's not
popular on z/OS.


What's the obstacle (not to popularity, but to TSO toleration)?


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. The same
restrictions apply to running Java in a TSO environment. You would have 
to spawn a Java JVM (yikes!). The TSO and ISPF interfaces would have to 
be done using JNI. It sends a shiver down my spine just thinking about 
it. I think you can forget about address TSO and address ISPEXEC 
environments. NetRexx doesn't support command environments like 
mainframe REXX, it uses classes.





-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM open sources it's JVM and JIT code

[Anne & Lynn Wheeler]

t...@harminc.net (Tony Harminc) writes:
> One can certainly write a Rexx interpreter (or compiler, for that matter),
> and run it under TSO and/or ISPF; in that sense it *tolerates* those
> environments. But for reasons known only to IBM, the interfaces needed to
> implement *integration* with the TSO/E and ISPF environments are
> undocumented. It used to be possible to write one's own Terminal Monitor
> Program (TMP), and there was even a book describing how to do so. With
> TSO/E that book was dropped, and while one can guess at much of what needs
> to be done, there are OCO control blocks and interfaces that inhibit
> implementing interfaces like Address TSO and Address ISPF.

early/mid 70s, internal politics from the Future System group was
shutting down 370 products (pushing that everything would be moved to
completely different Future System). The lack of 370 products during
this period is credited with giving clone processor makers market
foothold.

32june1969 unbundling announcement started to charge for software &
services ... but managed to make the case that kernel software would
still be free. when FS imploded there was mad rush to get products back
into the 370 pipeline. old IBM reference:
http://www.jfsowa.com/computer/memo125.htm

at the same time (because of the rise of clone processors) there was
decision to transition to charging for kernel software (my resource
manager was initial guinea pig). This continued into the early 80s
... then starts the OCO-wars. One of the motivations for OCO-wars was
(again) the clone processor competition ... but another motivation was
that customers weren't migrating off MVS to MVS/XA according to
plan. Part of the blame was placed on customers that had source and made
local modifications ... which weren't easily migrated from MVS to
MVS/XA. Eliminating source would minimize customers making local
modifications and enhance IBM control of their customer base.

Complicating things was introduction of clone "hypervisor" (subset of
virutal machines in hardware) which allowed concurrent operation of MVS
& MVS/XA much more efficiently than traditional virtual machine. IBM was
eventually able to respond with PR/SM & LPARS for 3090 (but by that time
some amount of the MVS->MVS/XA had passed).

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM open sources it's JVM and JIT code

[Walt Farrell]

On Tue, 24 Oct 2017 14:51:13 -0400, Tony Harminc  wrote:

>One can certainly write a Rexx interpreter (or compiler, for that matter),
>and run it under TSO and/or ISPF; in that sense it *tolerates* those
>environments. But for reasons known only to IBM, the interfaces needed to
>implement *integration* with the TSO/E and ISPF environments are
>undocumented. It used to be possible to write one's own Terminal Monitor
>Program (TMP), and there was even a book describing how to do so. With
>TSO/E that book was dropped, and while one can guess at much of what needs
>to be done, there are OCO control blocks and interfaces that inhibit
>implementing interfaces like Address TSO and Address ISPF.

You're right that IBM no longer documents how to write a TMP. But you don't 
need that much for a REXX (or similar) implementation/integration. For example, 
Address TSO should be possible by using IKJEFTSR, which is still documented. As 
for Address ISPEXEC I believe the ISPF documentation contains enough for that 
one as they document how an application can invoke ISPF services, though I'm 
less certain about Address ISREDIT.

-- 
Walt

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM open sources it's JVM and JIT code

[Jack J. Woehr]

On 10/24/2017 12:51 PM, Tony Harminc wrote:

Perhaps IBM thinks that someone is going to steal this radical technology
and use it on Linux or something, and so it must remain a closely held
secret...


More likely TSO Development barely remembers institutionally how it all 
works, so they don't want to
promise anything about the interface because they never know what 
they're going to have to fix someday

nor what they'll need to do in order to fix it.

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM open sources it's JVM and JIT code

[Tony Harminc]

On 24 October 2017 at 13:02, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Tue, 24 Oct 2017 14:27:13 +0800, David Crayford wrote:
>
> >NetRexx can't be used in TSO/ISPF environments which is why it's not
> popular on z/OS.
> >
> What's the obstacle (not to popularity, but to TSO toleration)?
>

One can certainly write a Rexx interpreter (or compiler, for that matter),
and run it under TSO and/or ISPF; in that sense it *tolerates* those
environments. But for reasons known only to IBM, the interfaces needed to
implement *integration* with the TSO/E and ISPF environments are
undocumented. It used to be possible to write one's own Terminal Monitor
Program (TMP), and there was even a book describing how to do so. With
TSO/E that book was dropped, and while one can guess at much of what needs
to be done, there are OCO control blocks and interfaces that inhibit
implementing interfaces like Address TSO and Address ISPF.

Of course the same thing inhibits implementing Lua or Python or  in the TSO/E environment as much as it does
competitive Rexxs.

Perhaps IBM thinks that someone is going to steal this radical technology
and use it on Linux or something, and so it must remain a closely held
secret...

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM open sources it's JVM and JIT code

[John McKown]

On Tue, Oct 24, 2017 at 12:02 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Tue, 24 Oct 2017 14:27:13 +0800, David Crayford wrote:
>
> >NetRexx can't be used in TSO/ISPF environments which is why it's not
> >popular on z/OS.
> >
> What's the obstacle (not to popularity, but to TSO toleration)?
>

​Well, the code will run as it would in a non-TSO batch step. But for
interactive TSO, it lacks the "ADDRESS TSO" capability of running TSO
commands (such as DELETE DSN). There is also no ADDRESS ISPEXEC or ADDRESS
ISREDIT for ISPF services. And, lastly, it also lacks the ADDRESS SYSCALL
environment for UNIX services. But for UNIX services, there may well be
some Java library which could be used instead. I'll need to consider the
possibility of looking at NetREXX again. I just don't like showing up on
the "large MSU users" report and telling my boss what I'm doing when it
doesn't really relate to company business.​



>
> -- gil
>
>
-- 
I just child proofed my house.
But the kids still manage to get in.


Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM open sources it's JVM and JIT code

[Paul Gilmartin]

On Tue, 24 Oct 2017 14:27:13 +0800, David Crayford wrote:

>NetRexx can't be used in TSO/ISPF environments which is why it's not
>popular on z/OS.
> 
What's the obstacle (not to popularity, but to TSO toleration)?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM open sources it's JVM and JIT code

[John McKown]

On Tue, Oct 24, 2017 at 7:38 AM, David Crayford  wrote:

> On 24/10/2017 8:25 PM, John McKown wrote:
>
>> NetRexx was born at IBM Hursley in 1995 at the hands of REXX's father,
>>> Mike
>>> Cowlishaw. It is the world's first alternative language for JVMs. The
>>> REXX
>>> Language Association's members and contributors actively maintain
>>> NetRexx.
>>> The latest release as I write this is Version 3.05 (April 27, 2017), and
>>> the Version 3.06 beta was released on April 28, 2017. Mike is still
>>> actively involved in the NetRexx community.
>>>
>>> ​I have NetREXX installed. But, as Mr. Crayford indicated, it is not a
>> replacement for TSO REXX in a TSO environment. I have, on occasion, used
>> it
>> to write a "batch" program or a UNIX command line program. I can't do this
>> much here because we are MSU constrained and don't have an zIIP (or zAAP)
>> on our z9BC. ​So I get "dinged" if I show up on my boss's MSU radar
>>
>
> Right! But if you had a JIT compiled classic REXX it would save you
> money!  But that won't happen. For starters it would need to be a rewrite
> in C++ with a VM. It's no secret I'm a Lua fan and it interested me that an
> IBM JIT developer has an experimental project that JIT enables Lua 5.3
> using OMR https://github.com/Leonardo2718/lua-vermelha. I could use that
> to "supercharge" Lua on z/OS. But there just doesn't seem to be much
> appetite for new languages on z/OS. Old dogs new tricks I suppose.


​I would guess that the lack of interest in new languages on z/OS is due to
two main reasons.

The first is that most z/OS programmers are rather old. They are most
likely programmers, not because they love to program, but because it pays
well. And they are also most likely looking forward to retirement. ​So they
are pretty much in a "stasis" mode. I am going to be 65 in December, so I'm
getting towards retirement. I got into programming because I was (and
generally still am) in love with programming itself. So I _love_ learning
new things. Which, in today's world, I direct onto my Linux/Intel system.

The second reason is company management. As far as I can see, with perhaps
a few exceptions, they simply view the IBMZ with z/OS as "obsolete". They
keep around only because they don't want to face the cost of doing a good
conversion to some other platform. That cost & difficulty is what caused
our manage to reverse course on our "cloud sourcing" the z/OS processing
via an outsourcer.

And, perhaps a third reason is that acquiring and running "language X" on
z/OS ends up being much more expensive than acquiring and running the same
"language X" (say Python, or PHP) on Linux or even Windows.



>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
I just child proofed my house.
But the kids still manage to get in.


Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM open sources it's JVM and JIT code

[David Crayford]

On 24/10/2017 8:25 PM, John McKown wrote:

NetRexx was born at IBM Hursley in 1995 at the hands of REXX's father, Mike
Cowlishaw. It is the world's first alternative language for JVMs. The REXX
Language Association's members and contributors actively maintain NetRexx.
The latest release as I write this is Version 3.05 (April 27, 2017), and
the Version 3.06 beta was released on April 28, 2017. Mike is still
actively involved in the NetRexx community.


​I have NetREXX installed. But, as Mr. Crayford indicated, it is not a
replacement for TSO REXX in a TSO environment. I have, on occasion, used it
to write a "batch" program or a UNIX command line program. I can't do this
much here because we are MSU constrained and don't have an zIIP (or zAAP)
on our z9BC. ​So I get "dinged" if I show up on my boss's MSU radar


Right! But if you had a JIT compiled classic REXX it would save you 
money!  But that won't happen. For starters it would need to be a 
rewrite in C++ with a VM. It's no secret I'm a Lua fan and it interested 
me that an IBM JIT developer has an experimental project that JIT 
enables Lua 5.3 using OMR https://github.com/Leonardo2718/lua-vermelha. 
I could use that to "supercharge" Lua on z/OS. But there just doesn't 
seem to be much appetite for new languages on z/OS. Old dogs new tricks 
I suppose.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM open sources it's JVM and JIT code

[John McKown]

On Tue, Oct 24, 2017 at 1:08 AM, Timothy Sipples  wrote:

> John McKown wrote:
> >Hum, I wonder if anybody at IBM is considering using this JIT technology
> >with the REXX language?
>
> The REXX programming language is already available for all Java runtimes
> (including z/OS) in the form of NetRexx:
>
> http://www.netrexx.org
>
> NetRexx already exploits whatever JIT optimizations are available,
> including the new and unique Pause-Less Garbage Collection on IBM z14 with
> Java 8 SR5 and z/OS.
>
> NetRexx was born at IBM Hursley in 1995 at the hands of REXX's father, Mike
> Cowlishaw. It is the world's first alternative language for JVMs. The REXX
> Language Association's members and contributors actively maintain NetRexx.
> The latest release as I write this is Version 3.05 (April 27, 2017), and
> the Version 3.06 beta was released on April 28, 2017. Mike is still
> actively involved in the NetRexx community.
>

​I have NetREXX installed. But, as Mr. Crayford indicated, it is not a
replacement for TSO REXX in a TSO environment. I have, on occasion, used it
to write a "batch" program or a UNIX command line program. I can't do this
much here because we are MSU constrained and don't have an zIIP (or zAAP)
on our z9BC. ​So I get "dinged" if I show up on my boss's MSU radar.


>
> Please enjoy (and contribute).
>
> 
> 
> Timothy Sipples
> IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
> E-Mail: sipp...@sg.ibm.com
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
I just child proofed my house.
But the kids still manage to get in.


Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM open sources it's JVM and JIT code

[David Crayford]

NetRexx can't be used in TSO/ISPF environments which is why it's not 
popular on z/OS.



On 24/10/2017 2:08 PM, Timothy Sipples wrote:

John McKown wrote:

Hum, I wonder if anybody at IBM is considering using this JIT technology
with the REXX language?

The REXX programming language is already available for all Java runtimes
(including z/OS) in the form of NetRexx:

http://www.netrexx.org

NetRexx already exploits whatever JIT optimizations are available,
including the new and unique Pause-Less Garbage Collection on IBM z14 with
Java 8 SR5 and z/OS.

NetRexx was born at IBM Hursley in 1995 at the hands of REXX's father, Mike
Cowlishaw. It is the world's first alternative language for JVMs. The REXX
Language Association's members and contributors actively maintain NetRexx.
The latest release as I write this is Version 3.05 (April 27, 2017), and
the Version 3.06 beta was released on April 28, 2017. Mike is still
actively involved in the NetRexx community.

Please enjoy (and contribute).


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM open sources it's JVM and JIT code

[Timothy Sipples]

John McKown wrote:
>Hum, I wonder if anybody at IBM is considering using this JIT technology
>with the REXX language?

The REXX programming language is already available for all Java runtimes
(including z/OS) in the form of NetRexx:

http://www.netrexx.org

NetRexx already exploits whatever JIT optimizations are available,
including the new and unique Pause-Less Garbage Collection on IBM z14 with
Java 8 SR5 and z/OS.

NetRexx was born at IBM Hursley in 1995 at the hands of REXX's father, Mike
Cowlishaw. It is the world's first alternative language for JVMs. The REXX
Language Association's members and contributors actively maintain NetRexx.
The latest release as I write this is Version 3.05 (April 27, 2017), and
the Version 3.06 beta was released on April 28, 2017. Mike is still
actively involved in the NetRexx community.

Please enjoy (and contribute).


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM open sources it's JVM and JIT code

[David Crayford]

> On 24 Oct 2017, at 12:26 am, John McKown  wrote:
> 
> On Mon, Oct 23, 2017 at 12:54 AM, David Crayford 
> wrote:
> 
>> IBM have open sourced their Java JVM and JIT code
>> https://www.eclipse.org/openj9/index.html.
>> 
>> The interesting code is not the Java JVM but the runtime technology
>> http://www.eclipse.org/omr/.
>> 
>>   *The Eclipse OMR project* consists of a highly integrated set of
>>   open source C and C++ components that can be used to build robust
>>   language runtimes that run on many different hardware and operating
>>   system platforms.
>> 
>>   The core technology components include, but are not limited to: a
>>   platform porting library, a thread library, diagnostic services,
>>   monitoring services, a just-in-time compiler, and a garbage collector.
>> 
>> IBM have a technology preview that adds a OMR JIT compiler to Ruby
>> https://developer.ibm.com/open/2016/11/18/introducing-ruby-jit/. They're
>> also working on versions of CPython, Smalltalk and PHP. So in theory we
>> could have all of the languages running on z/OS at the speed of compiled
>> code that will optimize dynamically depending on the hardware. How exciting!
>> 
> 
> ​Hum, I wonder if anybody at IBM is considering using this JIT technology
> with the REXX language?​ It might even be interesting to use with ooREXX,
> which is more likely since it is open sourced

I doubt it. I would expect them to target modern languages with VMs. 


> -- 
> I just child proofed my house.
> But the kids still manage to get in.
> 
> 
> Maranatha! <><
> John McKown
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM open sources it's JVM and JIT code

[John McKown]

On Mon, Oct 23, 2017 at 12:54 AM, David Crayford 
wrote:

> IBM have open sourced their Java JVM and JIT code
> https://www.eclipse.org/openj9/index.html.
>
> The interesting code is not the Java JVM but the runtime technology
> http://www.eclipse.org/omr/.
>
>*The Eclipse OMR project* consists of a highly integrated set of
>open source C and C++ components that can be used to build robust
>language runtimes that run on many different hardware and operating
>system platforms.
>
>The core technology components include, but are not limited to: a
>platform porting library, a thread library, diagnostic services,
>monitoring services, a just-in-time compiler, and a garbage collector.
>
> IBM have a technology preview that adds a OMR JIT compiler to Ruby
> https://developer.ibm.com/open/2016/11/18/introducing-ruby-jit/. They're
> also working on versions of CPython, Smalltalk and PHP. So in theory we
> could have all of the languages running on z/OS at the speed of compiled
> code that will optimize dynamically depending on the hardware. How exciting!
>

​Hum, I wonder if anybody at IBM is considering using this JIT technology
with the REXX language?​ It might even be interesting to use with ooREXX,
which is more likely since it is open sourced.

-- 
I just child proofed my house.
But the kids still manage to get in.


Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM open sources it's JVM and JIT code

[Walt Farrell]

On Mon, 23 Oct 2017 22:48:42 +0800, David Crayford  wrote:

>On 23/10/2017 9:02 PM, Walt Farrell wrote:
>> On Mon, 23 Oct 2017 13:54:10 +0800, David Crayford  
>> wrote:
>>
>>> IBM have a technology preview that adds a OMR JIT compiler to Ruby
>>> https://developer.ibm.com/open/2016/11/18/introducing-ruby-jit/. They're
>>> also working on versions of CPython, Smalltalk and PHP. So in theory we
>>> could have all of the languages running on z/OS at the speed of compiled
>>> code that will optimize dynamically depending on the hardware. How exciting!
>> That does sound interesting, David, but I don't see anything in the website 
>> that mentions z/OS. I see they have a version for Linux on z, though.
>>
>> Have I missed something?
>
>The z/OS stuff can be found here
>https://github.com/eclipse/omr/tree/master/port/zos390.

Thanks.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM open sources it's JVM and JIT code

[David Crayford]

On 23/10/2017 9:02 PM, Walt Farrell wrote:

On Mon, 23 Oct 2017 13:54:10 +0800, David Crayford  wrote:


IBM have a technology preview that adds a OMR JIT compiler to Ruby
https://developer.ibm.com/open/2016/11/18/introducing-ruby-jit/. They're
also working on versions of CPython, Smalltalk and PHP. So in theory we
could have all of the languages running on z/OS at the speed of compiled
code that will optimize dynamically depending on the hardware. How exciting!

That does sound interesting, David, but I don't see anything in the website 
that mentions z/OS. I see they have a version for Linux on z, though.

Have I missed something?


The z/OS stuff can be found here 
https://github.com/eclipse/omr/tree/master/port/zos390.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM open sources it's JVM and JIT code

[Walt Farrell]

On Mon, 23 Oct 2017 13:54:10 +0800, David Crayford  wrote:

>IBM have a technology preview that adds a OMR JIT compiler to Ruby
>https://developer.ibm.com/open/2016/11/18/introducing-ruby-jit/. They're
>also working on versions of CPython, Smalltalk and PHP. So in theory we
>could have all of the languages running on z/OS at the speed of compiled
>code that will optimize dynamically depending on the hardware. How exciting!

That does sound interesting, David, but I don't see anything in the website 
that mentions z/OS. I see they have a version for Linux on z, though.

Have I missed something?

-- 
Walt

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

IBM open sources it's JVM and JIT code

[David Crayford]

IBM have open sourced their Java JVM and JIT code 
https://www.eclipse.org/openj9/index.html.


The interesting code is not the Java JVM but the runtime technology 
http://www.eclipse.org/omr/.


   *The Eclipse OMR project* consists of a highly integrated set of
   open source C and C++ components that can be used to build robust
   language runtimes that run on many different hardware and operating
   system platforms.

   The core technology components include, but are not limited to: a
   platform porting library, a thread library, diagnostic services,
   monitoring services, a just-in-time compiler, and a garbage collector.

IBM have a technology preview that adds a OMR JIT compiler to Ruby 
https://developer.ibm.com/open/2016/11/18/introducing-ruby-jit/. They're 
also working on versions of CPython, Smalltalk and PHP. So in theory we 
could have all of the languages running on z/OS at the speed of compiled 
code that will optimize dynamically depending on the hardware. How exciting!



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN