On 7/3/23 02:39, Rony G. Flatscher wrote:
On 06.03.2023 02:43, David Crayford wrote:
I'm sure your BSF4ooRexx is a really nice library. But it's moot
point talking about it on this forum because ooRexx has not been
ported to z/OS, I'm sorry to say that I think it probably never will be.
That would be unfortunate and actually a little bit unprofessional if
other non-IBM-invented and great software gets ported to it. OTOH
seeing the FUDding towards ooRexx it is not a surprise, keeping
everyone in the wait-and-see room (the purpose of FUD marketing).
Unless, of course, there is a REXX enthusiast who has the time and
skills to do the port. I can tell you from experience, it's not easy.
Your experience stems from the days where ooRexx was coded to be
32-bit only, with quite a few hacks from its history at IBM (written
originally at a time where C++ was not yet standardized, every company
had its own C++ (pre-)compiler, then the need to have it run on OS/2,
AIX, Windows and the like).
In the meantime the kernel got totally rewritten and the build system
changed from autotools to CMake, making it possible to create ports of
ooRexx with any bitness and operating system targets quickly.
I did notice that CMake is being used for the build. That's good as IBM
have ported CMake to z/OS. It's hidden away on a personal Github repo by
an ex-IBMer who used to work in the Java JIT team. I may mention that to
IBM.
Anyway, I digress. ooRexx still have the same portability issues as
before. For example, it assumes that 'phread_t' is a integer. On z/OS,
System i, BSD etc it's an opaque type, a struct.
In file included from
/u/ts8004/git/ooRexx/common/platform/unix/SysSemaphore.hpp:51:
/u/ts8004/git/ooRexx/common/platform/unix/SysThread.hpp:70:36: error: no
matching constructor for initialization of 'pthread_t'
SysThread() : attached(false), _threadID(0) { ; }
^ ~
/usr/include/sys/types.h:300:19: note: candidate constructor (the
implicit copy constructor) not viable: no known conversion from 'int' to
'const pthread_t' for 1st argument
typedef struct {
^
/usr/include/sys/types.h:300:19: note: candidate constructor (the
implicit move constructor) not viable: no known conversion from 'int' to
'pthread_t' for 1st argument
/usr/include/sys/types.h:300:19: note: candidate constructor (the
implicit default constructor) not viable: requires 0 arguments, but 1
was provided
In file included from
/u/ts8004/git/ooRexx/rexxapi/client/ClientMessage.cpp:41:
In file included from
/u/ts8004/git/ooRexx/rexxapi/client/LocalAPIManager.hpp:47:
In file included from
/u/ts8004/git/ooRexx/common/platform/unix/SysSemaphore.hpp:51:
/u/ts8004/git/ooRexx/common/platform/unix/SysThread.hpp:86:17: error:
cannot convert 'pthread_t' to 'uintptr_t' (aka 'unsigned long') without
a conversion operator
return (uintptr_t)_threadID;
^~~~~~~~~~~~~~~~~~~~
/u/ts8004/git/ooRexx/common/platform/unix/SysThread.hpp:89:37: error:
cannot convert 'pthread_t' to 'size_t' (aka 'unsigned long') without a
conversion operator
inline size_t hash() { return (((size_t)_threadID) >> :sunglasses:
* 37; }
IBM warns about this in it's documentation
https://www.ibm.com/docs/en/i/7.1?topic=ssw_ibm_i_71/apis/concep17.html
Amazon have been fixing this bug in their C SDK
https://github.com/awslabs/aws-c-io/issues/217
There also appears to be bugs in SysThread where the "attached" member
variable is not initialized in the constructor that takes a pthread_t
argument.
I also wonder what will happen to ooRexx once Rick McGuire retires?
Is there a big enough community to keep it going?
Again FUD (fear, uncertainty and doubts): make its future doubtful
should anyone think of porting it to z/OS?
Seriously, ooRexx is open-source so no one can pull it from the market
such that any investment in it is strategically safe. The current set
of features add already a lot of wealth of help and flexibility to the
REXX table, there would be no need to add new ones to keep ooRexx an
extremely improved over classic REXX tool forever.
I you want to attract people to work on ooRexx then I suggest
modernizing the development pipeline. Move everything to Github. Nobody
wants to use Subversion anymore and you can create wikis and improve the
documentation.
Back to your doubts: yes, there are plenty of highly skilled
programmers in the ooRexx community to take on maintenance and even
add new features if deemed necessary (one of the ooRexx developers has
even an experimental branch of ooRexx where he tests all sort of
interesting features).
So, there is no reason to doubt the future of ooRexx. It is a safe
investment.
I would be interested to know to average age of the commiters.
FWIW, the Python Py4J and JPype (and others) libraries are similar
to BSF4ooRexx and both run on z/OS. Note: you will need access to the
xlclang/xlclang++ libraries to install those packages as PyPi doesn't
have binaries for z/OS.
https://talvi.net/posts/a-brief-overview-of-python-java-bridges-in-2020.html
Thank you for that interesting link. The only implementation of a Java
bridge there that adheres to the Java standard (this should go without
saying that everyone should adhere to!), i.e. the Java scripting
framework as defined in the javax.script package is Jython.
As such only Jython can be used as a scripting language from the Java
side, if Java programmers want to run a Python script from their
application using the Java scripting framework. E.g. you can use
Jython for event handling in JavaFX, but none of the other Python-Java
bridge attempts which is unfortunate.
All other bridges just ignore the Java scripting framework standard
and whatever the respective author felt was right for himself turned
into the infrastructure one has to learn in order to become able to
use a particular Java bridge. Such an approach is quite ignorant and
hence dilletantic despite the talent that people may show. Also one
can tell the fascination of new Java-related projects like GraalVM
(which is not ready for prime time for quite some time) without caring
for business (professional) deployments of Java.
So the only candidate for a valid Python-Java bridge would be Jython.
[Let me add that ooRexx+BSF4ooRexx is faster by comparison (comparing
loading and dispatching scripts on the same machine in the same Java
runtime environment).]
Comparing the ooRexx-Java bridge (BSF4ooRexx): it is fully implemented
in both directions from ooRexx to Java and from Java to ooRexx: you
can send ooRexx messages to Java objects (including arguments meant
for the targeted Java method) that cause the appropriate Java method
to be invoked on the targeted Java object; vice versa: you can invoke
Java methods on the ooRexx proxy object on the Java side which will
cause the proxied ooRexx object to receive a genuine ooRexx message
accompanied with all Java arguments going with it.
BSF4ooRexx even allows you to implement abstract Java methods in
ooRexx, wich is actually very easy! :)
Does it support lambda functions?
We use ReactorNetty for Java TCP servers [1]. Although it's far more
common these days to use a layer 7 protocol such as HTTP(S) using a
framework like Spring to do all the heavy lifting. It would be
interesting to see how BSF4ooRexx could use ReactorNetty and if there
would be any benefit over just using Java or Kotlin.
[1] https://projectreactor.io/docs/netty/release/reference/index.html
The above URL yields a bad request (400), using
<https://projectreactor.io/docs/netty/release/reference/> works.
One could use that Java class library from ooRexx+BSF4ooRexx, it would
be straight forward (interesting to see the old reactor implementation
put to work which is fine). Also if logging was active you could cause
any Rexx logging output to have it prepend "REXXout>", "REXXerr>" or
"REXXtrc>" which helps enormeously in finding Rexx-related output in
Java log files which can become huge (I added that feature because
otherwise the Rexx programmers may lose an incredible amount of time
locating Rexx output inmidst with Java output).
Python is not my favorite language by a country mile. For scripting I
would choose Lua every day of the week and twice on Sundays. My
younger colleagues, however, would not. A lot of universities use
Python as the language for Introduction to Programming courses so the
new hires already know the language from colleague.
Yes, this is unfortunate as they really are using one of the wrongest
language for teaching programming to novices. It is impossible for
novices to really learn and master programming within a semester, the
best that can be usually achieved is to get them to the point where in
narrowly confined areas they become able to write little programs but
need a lot of additional time to get to learn the broader Python
environment.
The industry has spoken! Python is the most popular programming language
in the world so haters will have to just suck that up.
The major reason being that - unlike REXX, ooRexx and NetRexx - Python
is *not* an easy programming language for novices! (It is quite
difficult to come up with an easy to learn, to use and to understand
programming language, the REXX language - and its families - stand out
in that respect.)
I disagree. It's simple to learn. It's hard to learn the standard
library as it's so huge but that comes with using it.
Take as an example your hint to
<https://docs.python.org/3/library/selectors.html>: it is simply
impossible to teach novices in 90 minutes everything that is necessary
to become able to write a socket server and socket client as an
assignment. Forget it if the novices are business administration
students who have no clues of Unix/Linux/POSIX nor a theoretical
background of what is documented there. T
I don't think anybody uses selectors these days. Modern Python has
asyncio with co-routines and async/await similar to JavaScript or
Kotlin. It's so simple to write a high performance web application.
To see for yourself you can look through the slides:
* Introduction to programming, object-oriented programming, Windows
programming with OLE including
MS Office: <https://wi.wu.ac.at/rgf/wu/lehre/autowin/material/foils>
* Introduction to BSF4ooRexx (ooRexx-Java bridge), exploiting the
infrastructure, teaching with
nutshell programs platform independent programming for GUIs,
client-/server programming,
processing XML texts, Apache OpenOffice/LibreOffice, JavaFX:
<https://wi.wu.ac.at/rgf/wu/lehre/autojava/material/foils>
---
I'll give it a look.
I'm happy to continue this conversation with you offline so we don't
drift this thread any further.
Not asking the younger ones to learn the tools helping them or needed
for mainframes, but rather ignore all these tools and only use Python,
just because they know it, is simply not professional and unbearable
for professionals. (It looks like the famous hammer philosophy,
usually a recipe for desaster...)
However, this is not to say to not learn or to use Python (or any
other, additional language)! Use Python everywhere where its
application gives you noticeable benefits (saving time, saving costs,
enabling something that is not possible otherwise and the like).
That is also the reason why in today's world it is important to learn
and use Java which is a stunning, professional programming and runtime
environment that carries not only more functionality in form of class
libraries than any other language. Deploying Java, taking advantage of
Java is of strategic importance for any company IMHO.
The reason I evangelize Python on z/OS is because I can see that IBM
are backing it and it's strategic. I recently noticed IBM have
released the Python AI Toolkit for z/OS which is free of charge.
Exciting times ahead.
https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/1/897/ENUS223-021/index.html&lang=en&request_locale=en
This is fine and o.k. as the Python tool can be used for that
application area.
Do you realize, that if it is possible to use Java for exploiting this
technology then that is already enough for ooRexx+BSF4ooRexx and of
course also for NetRexx to be used for it? (No need for an extra
library for a specific programming language to be created and to be
made available as is the case with Python here.)
Ad COBOL-Java that gets stressed in the context of that announcement
in
<https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/3/897/ENUS223-013/index.html&lang=en&request_locale=en>:
it may be interesting for COBOL programmers to know that thanks to the
COBOL-Java bridge one could employ/dispatch REXX scripts, believe it
or not and even supply arguments (even Java objects, if needed) and
fetch return values!
The secret here lies in the standard Java scripting framework (the
package javax.script) which makes it really *easy* to use any
scripting language for executing scripts or macros. BSF4oRexx comes
with a wealth of instructive nutshell samples in
"samples/Java/javax.script" or the equivalent samples in NetRexx
"samples/NetRexx/javax.script". These nutshell samples go from simple
to powerful, demonstrating how easy it is to have a REXX/ooRexx script
execute via Java/NetRexx and even supplying arguments and fetching
return values to/from these Rexx scripts.
ooRexx+BSF4oorexx, NetRexx: powerful, helpful stuff and best: really
*easy* to learn and easy to use! :)
---rony
On 6/3/23 04:16, Rony G. Flatscher wrote:
Comment, asking:
> Like what? Have you ever tried to write a TCP server in REXX?
Comment, receiving:
> Start here and it is reasonably simple:
- TCPIP.SEZAINST(RSSERVER)
- TCPIP.SEZAINST(R6SERVER)
Comment: so writing a TCP server in REXX is not only theoretically
possible, but a reality. Interesting what happens next:
Thanks for the links. Now, there is code duplication between
the two modules. How would one go
about externalizing the common code to a module?
The method of maintaining the socket descriptor list is crude
and highlights the lack of data
structures in classic REXX.
Writing a non-blocking, multiplexing TCP server in Python is
simple
https://docs.python.org/3/library/selectors.html
Comment: surprisingly bringing up totally different items/aspects
(somehow as "if you can, confuse/sidetrack/derail them"). The answer
is: if one has a need for a TCP server or a TCP client in REXX one
can create and use one as has been pointed out.
There have been no questions asked about how to go about "writing a
non-blocking, mulitplexing TCP server in Python". If there was a
need to "write a non-blocking, multiplexing TCP server in Python"
why was that particular question not asked in the first place?
OTOH if the need is for REXX servers and/or clients (the original
question) that employ "a non-blocking, mulitplexing TCP server" (the
new, derailing questions) and one wishes to code that in REXX one
can either look for REXX function libraries supplying the needed
infrastructure, or create such interfaces to such libraries, or use
NetRexx or BSF4ooRexx, which get one even more powerful abilities
due to be immediately able to exploit the multiplatform, tested,
cunning Java class libraries that come for free with Java. :)
Here slides where business administration students who learn
programming (in a course named "Business Programming") as novices
(!) in the second part of the semester (after two months learning
Rexx and then ooRexx from scratch) having become able to use all of
Java as a huge external ooRexx function and class library:
<https://wi.wu.ac.at/rgf/wu/lehre/autojava/material/foils/230_AutoJava_Sockets_V05.pdf>
(the slides also demonstrate how to take advantage of the Java
SSL/TLS classes, it is actually quite easy). This demonstrates among
other things how easy it becomes to exploit Java from ooRexx for
creating TCP server and clients, and as one can see it is even easy
doing the same with employing Java's SSL/TLS from the Rexx programs!
[BTW this has become possible because of ooRexx dynamic and message
based nature. Java objects suddenly understand ooRexx messages, the
case of spelling method names or field names is not relevant anymore
and some more. Or invoking Java methods on the Java RexxProxy class
causes messages to be sent off to the proxied Rexx object and some
more.]
Compare the Python library above with what Java allows for, here a
nice overview article about it:
<https://liakh-aliaksandr.medium.com/java-sockets-i-o-blocking-non-blocking-and-asynchronous-fb7f066e4ede>.
Anything you see in the discussion about the POSIX definitions (that
shine through that Python library above and as such mandates the
knowledge about it) , the explanations about blocking, non-blocking,
synchroneous, asynchroneous, multiplexing followed by the overview
of respective Java classes in an overview form as well as the
nutshell Java samples (using Sockets, NIO, NIO2) can be directly and
immediately used/exploited from REXX in the form of ooRexx and
NetRexx, where NetRexx will even create native Java classes from
your Rexx code (running at the speed of native code). If wanting to
keep the interactivity of an interpreter, the dynamics and the
flexibility of ooRexx at runtime then use that.
The point here is simple: everyone who has REXX skills can rather
easily and immediately take advantage of ooRexx or NetRexx.
The design principle of "human-centricness" of REXX defined by its
inventor Mike F. Cowlishaw has been successfully applied for these
two Rexx languages as well, making it even for newcomers (novices,
see above!) easy to learn and take advantage of these Rexx languages
(as a matter of fact Mike F. Cowlishaw also designed NetRexx at IBM
which later got open-sourced and gets further developed by RexxLA.org).
Just try out these REXX variants, experiment a little bit, they open
totally new doors in addition to those you have been enjoying with
classic REXX already, hence it will pay in any case.
:)
---rony
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
