Hi Rony,
Much respect for spending so much time to scribe such a response. We've
already flogged this horse within an inch of it's life already and we
will just have to agree to disagree. REXX is still an important language
on z/OS for TSO scripting, NetView and System REXX is quite cool. As a
general purpose
scripting language it's moribund. Given the other options available
nobody other than enthusiasts or language bigots want to use it (I have
no time for language bigotry in the workplace, it's unprofessional). IBM
are porting languages to try to keep the mainframe modern and accessible
to new hires.
I'm not sure why I would every want to use NetRexx. Coding standard Java
is easier not to mention Groovy and Kotlin. 15 years ago IBM were
shipping z/OS WAS scripts written in Jython. IMHO. NetRexx is a solution
looking for a problem and I can find no significant products that use it.
I don't want to get into another ping pong debate over REXX. Everyone
knows my opinion by now.
On 21/06/2022 6:12 pm, Rony G. Flatscher wrote:
On 20.06.2022 19:26, David Crayford wrote:
On 21/06/2022 1:07 am, Paul Gilmartin wrote:
On Mon, 20 Jun 2022 08:47:49 -0700, Charles Mills wrote:
...
The assembler routine will take as input a delay time in hundredths
of a second (because of STIMER), do a WAIT ECBLIST, and return one of
'T' -- the time expired
'P' -- the operator entered STOP
'F modify command operand' -- the operator entered MODIFY
What happens if the operator enters STOP during the (relatively
minuscule)
fraction of time that Rexx, not Assembler is active?
In that case the EXTRACT ECB will be posted and the routine will stop
when it is re-entered and the ECB is tested. I've written something
similar myself for Lua. The differnce is Lua is object oriented and
holds state where REXX is not so it's a Frankenstien monster to
create a reusable context.
It's hard to justify why anybody would do it for REXX when you can
just code a C++ program using __console() and a std::thread.
This is a question of philosophy in general.
"Name dropping" of computer programming languages does not
substantiate assessment of a problem and then thinking of the "best"
solution for it. One criterium might be performance, another needed
resources, another one is to solve a problem quickly (saving human
time), another one is legibility to improve understanding,
maintainability, reduce errors, and many more.
One important criterium is definitely standardisation: this makes sure
that in certain environments basic programming skills can be relied on
like in the mainframe world REXX or Java or Assembler. If one is able
to jump between different programming languages like Assembler, REXX,
Lua, C++, Python, Java, JavaScript, Perl, Ruby, ..., and the programs
should be maintainable by others, preferably by the shops where they
get deployed, then one should not "jump around" languages, just
because some person is able to do so as the resulting code might
lock-in the shops, make them dependent on the authors/sellers.
---
Seeing that you sometimes stress the importance of object-orientness
for various reasons (like above) pointing at REXX incapability in that
context, then seeing that you like to frame REXX with all bad and
negative emotions ("it's a Frankenstein monster") one wonders what is
the agenda of such a person.
Clearly, if it was possible to build on REXX skills and making it easy
to e.g. exploit object-oriented features, most notably the ability to
define data structures with functions/methods to maintain/interact
with them ( a.k.a. "types","classes"), why not use the language IBM
has originally built as an object-oriented successor to REXX i.e.
ooRexx? ooRexx is able to run Rexx programs and allows optionally to
define your own data structures/classes/types, plus it adds a wealth
of useful new features in an easy to learn and easy to use manner.
There are mainframe shops that use ooRexx as a mainframe port to the
Linux subsystem has been existing.
---
Now if someone were to try out/explore ooRexx it may be interesting to
extend ooRexx such that REXX programmers who got accustomed to ooRexx
may become able to interact with/exploit Java, noticing how
predominant Java is and how well it gets supported by IBM. (Heck, IBM
even has an OpenJDK distribution of its own! And not only IBM, even
Microsoft, believe it or not, and Amazon, and Bellsoft, and ...)
The interesting thing is, if the user, the programmer is in the center
of endeavors like enhancing REXX with object-oriented abilities such
that the language remains easy, and then extends the abilities to
encompass all of Java, but using a dynamically typed, caseless
programming language like REXX or ooRexx, then it is likely that
"normal" REXX programmers become quite quickly able to instrumentate
all important mainframe technologies from a Linux subsystem. (I teach
beginners, BA students!, in four months programming in a four hour
lecture, the last two months they use and take advantage of Java
without a need to learn Java at all! The most important indredient is
the programming language: first introducing REXX then ooRexx.)
The external ooRexx function library to bridge [oo]Rexx and Java is
called BSF4ooRexx and has been in development and proven for more than
20 years. There are mainframe shops where this bridge gets used with
ooRexx to become able (again) to run their Rexx programs against DB2.
The BSF4ooRexx installation package has a precompiled library for the
mainframe Linux subsystem aboard.
---
So the driving idea is to extend known and trusted skills and
technologies. Here building on the REXX skills.
The technologies are there, it is up to the interested REXX programmer
to put their toes into the water and then try it out as ooRexx is
available for Windows, Linux, MacOS, the mainframe and others.
(Also, if you know/love C++ it may be interesting to know that it is
quite easy to create external ooRexx function packages, its native API
is impressive. BSF4ooRexx uses it, making it - among other things -
possible to use [oo]Rexx as macro language for any Java application.
This is being exploited by JavaFX which can use [oo]Rexx as one of its
scripting/macro languages out of the box!)
For those of you who have never seen ooRexx and want to know how it
looks like and how it is based on REXX, you may want to skim over the
ten PDF pages at <https://epub.wu.ac.at/8118/>. The article is
"timeless" in the sense that everything it communicates is still
actual and relevant. It is meant as an easy introduction to REXX and
ooRexx allowing one to assess a little bit the underlying philosophy.
---
Ad one of the samples in this thread (writing to a file) in [oo]Rexx
may be as simple as:
call lineout 'somefile', 'hello, world !'
ooRexx extends the stream-BIF based functionality with a stream
class/type of its own that allows for reading from/writing to any
device including file systems. However, one would use that additional
functionality only, if it adds some benefit, e.g. using an open stream
as an argument to a Rexx function (yes, ooRexx allows one to fetch
arguments by reference including stems).
---
Lastly, if you are interested in writing Java programs, but do not
want to learn Java, then use NetRexx for that matter! NetRexx got
created by the father of REXX, Mike F. Cowlishaw who - among many
other great skills and talents - has been an expert on the Java
programming language more than 25 years ago.
NetRexx follows the REXX philosophy ("Java in the clothes of REXX")
such that REXX programmers would become able to create Java programs
quickly, they usually just do not realize that!
IBM's NetRexx BTW was the first JVM language in the world!
NetRexx - like ooRexx - has been handed over to the non-profit SIG
Rexx Language Assocation (RexxLA, cf. www.RexxLA.org) by IBM. RexxLA
has open sourced both languages and has been maintaining and
developing them.
Try them out, they are free! :)
---rony
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
