The landscape would be quite different were IBM to provide legacy streams, port ooRexx to TSO and include BSF4ooRexx as part of z/OS. On my PCs I've pretty much abandoned SAA Rexx.
"Tell me the correct performance comparison between two language orocessors vand I'll devise a benchmark to prove it." -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Rony G. Flatscher <rony.flatsc...@wu.ac.at> Sent: Sunday, June 30, 2024 8:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Rexx is quite cool, flexible, powerful, feature-rich, thank you! (Re: z/OS 3.1 Enhancements & Support News On 28.06.2024 23:01, David Crayford wrote: > I'd prefer to avoid another instance of Crayford criticizing REXX, but here's > my take. :) > One major hurdle in adopting Python is its dependency on a UNIX environment. > When I introduced Python to REXX programmers, I received feedback from > seasoned professionals (like myself) who expressed reluctance due to their > reliance on PDS data sets, TSO, and unfamiliarity with USS. Conversely, > younger colleagues I work with rarely use TSO/ISPF. > > REXX is notably inefficient—capital "I" inefficiency. Badmouthing. > I tested a Lua program for dataset I/O that completed in less than a second, > whereas the equivalent REXX code took 12 seconds. Unfortunately, REXX's > performance isn't likely to improve; it's also considered a language riddled > with weaknesses. Says who? About two years we had an exchange here where you tried to proof how slow REXX would be compared to a C-program running an unreal example where the static and statically typed language C can shine: using the processor's long integer type. Now, a flexible dynamic and dynamically typed language like REXX would usually not represent long numbers in the processor's native format. Where a C-solution would be able to feed the processor with no conversions of the long values, a dynamic language would have to constantly convert from its internal representation to native and back to its internal representation (in REXX probably strings made up of number characters). Of course, a simple number-crunching static and statically typed program would be faster than a dynamic and dynamically typed program, and much faster so. You know that of course and came up with a small sample in C that would make REXX look extremely bad. In the course of the exchange in this list, I came up with a Rexx solution that surprisingly did beat your C-solution at which point you asked to stop that thread. The point I tried to make back then was that although a static and statically typed language like C (or Lua) would be faster than a dynamic and dynamically typed language like Rexx or Smalltalk, if real need be, then a Rexx programmer would be able to come up with solutions that are able to number crunch at comparable speeds to static and statically typed languages. How is that possible? Because of exploiting the flexibility the dynamic abilities of a dynamic language like Rexx and ooRexx allow for and instrumentating a statically typed language like NetRexx or Java for doing the number crunching. In order to show my students (who are business administration students) and interested professionals how to go about it, I created a few nutshell examples distributed in the samples directory of the Java bindings for ooRexx such that everyone interested can check them out and amend them for their purposes. Here an example (samples\4-600_compileAndRunEmbeddedNetRexx1.rxj) signal on syntax /* in case a condition gets raised */ /* A compiled NetRexx program has a static main method that expects an array of type String (representing supplied command line arguments). */ say "ooRexx: use embedded NetRexx program: fetch, compile & run it ..." d1=.dateTime~new /* for timings */ clzSquares=bsf.compile("squares", .resources~squares.nrx, "NetRexx") d2=.dateTime~new /* for timings */ clzSquares~main(.nil) /* run the NetRexx program */ d3=.dateTime~new /* for timings */ say "compiling NetRexx program:" d2-d1 /* show duration */ say "running NetRexx program :" d3-d2 /* show duration */ exit syntax: /* in case of an error */ co=condition('object') /* get all condition information */ say ppJavaExceptionChain(co) /* show Java exception chain */ say "---> this program needs NetRexx and ooRexx 5.0 or later" raise propagate /* let ooRexx interpreter handle it */ ::RESOURCE squares.nrx /* NetRexx source code */ /* NetRexx: squares.nrx */ options binary /* in this case we want speed */ items = 10000000 s = long[items] /* define a Java array of type long */ loop i=1 to items n=long i /* for multiplication we want to use long */ s[i-1] = n * n end /* use java.util.Arrays' stream() (introduced with Java 8) */ say Arrays.stream(s).max.getAsLong ::END ::requires BSF.CLS /* get full bidirectional Java support */ The above ooRexx program that contains a NetRexx program in the resource named "squares.nrx" which does the number crunching. The ooRexx program fetches the NetRexx source, compiles it at runtime and then runs it. As you can see NetRexx is really easy for a Rexx programmer. NetRexx is really Java in the clothes of Rexx making it extremely easy for REXX programmers to leverage their Rexx skills and exploit all of Java without a need to learn Java! --- Now, if people know Java already they could use it for the number crunching easily. Here the same example as above, but using Java (4-601_compileAndRunEmbeddedJava1.rxj): signal on syntax /* in case a condition gets raised */ /* A compiled Java program has a static main method that expects an array of type String (representing supplied command line arguments). */ say "ooRexx: use embedded Java program: fetch, compile & run it ..." d1=.dateTime~new /* for timings */ clzSquares=bsf.compile("squares", .resources~squares.java, "Java") d2=.dateTime~new /* for timings */ clzSquares~main(.nil) /* run the Java program */ d3=.dateTime~new /* for timings */ say "compiling Java program:" d2-d1 /* show duration */ say "running Java program :" d3-d2 /* show duration */ exit syntax: /* in case of an error */ co=condition('object') /* get all condition information */ say ppJavaExceptionChain(co) /* show Java exception chain */ say "---> this program needs ooRexx 5.0 or later" raise propagate /* let ooRexx interpreter handle it */ ::RESOURCE squares.java /* Java source code */ /* Java: squares.java */ import java.util.Arrays; public class squares { public static void main (String args[]) { int items = 10000000; long [] s = new long [items]; for (int i=1; i<=items; i++) { long n=i; s[i-1] = n * n; } System.out.println(Arrays.stream(s).max().getAsLong()); } } ::END ::requires BSF.CLS /* get full bidirectional Java support */ The above ooRexx program contains a Java program in the resource named "squares.java" which carries out the number crunching. The ooRexx program fetches the Java source, compiles it at runtime and then runs it. Both solutions are faster than the C solution (and mostlikely faster than Lua, Python and the like) using a dynamic and dynamically typed programming language! :) --- BTW, from day one REXX - due to its dynamic nature - was able to carry out arithmetics with an arbitrary number of numeric digits that was impossible for the static and statically typed languages of that time. Although not as fast assembler (by no means) REXX programs e.g. in the Stanford Linear Accelerator center would enable the researchers to carry out precise decimal calculations with an arbitrary number of precision by allowing an arbitrary number of digits. REXX' decimal arithmetics as defined in the ANSI REXX standard was used to define the decimal arithmetic standards IEEE 754. Here a presentation on an International Rexx symposium by the father of Rexx, Mike F. Cowlishaw: <https://secure-web.cisco.com/1dvXixHmgAR-0p7SlUKuKhTPs-ByF--hBACF5mX5YW_KO9curphCAc3wL2a4sQ1kG8buElJqjNSMEpkCqgvhnRJkjkxznW0ve1QkHXtD28vkgc8SbHNzaJ4q4ae5BmML2Le8f7b8ewUwOUhNtyyPrD7o8IbMtiKzwIDaUvEku8jnEww9Cs7datSksrkJwaZ08-L7xJ02WYNddIJuQkndlYiRV6CrXyXZgUItqc5_cRv5JeNIlvGeQDEB_MVKakDpQPg5PX3aqrw4BSdIAPpc7nYGJ0_Hj-PMMb5KmdCHF0U1a2lrpsvOWzpNNdKWpZod1hXGIYzNKAHeLmzn7hVl_IMaeH6v2JkTAdqhMJoXdrh7BJm8eRw5kEh7JaoVutqyyaAZQIgPRa9CvNFXF2uYdQ4PU3GhiTkTaqma5FniXiMQ/https%3A%2F%2Fwww.rexxla.org%2Fpresentations%2F2008%2Frexxnum2008.pdf> and here the specifications for general decimal arithmetics definitions <https://secure-web.cisco.com/11j_SgHcKj8mibUVD9I2QklpPFWGkZh3tvtC9yqzeoypAmEl-uUmBMt8zOjX_xfvLq9ZOgM-49bNUiqQgRtFH426TyUaSQbYUUtyn4sdJVQMipzUV_NhJUP_DjCPzVREiJZhsFOs8-tYw7b_fWsVarD86Trr4f6I7hVs65agrMMji6LCjGOC9l9-NwdFFhOHJY2OPD5_nOOEwYxffZGQTJuhPcJtisrPZCAJPXPFGSnqZ5COuaIFtKiDHXm7--XVrYszLqZLxvDhMV24OSM1M1Oso3t5kDR-Mr7ykXYCcAUJQ3bBH2ahtitjy58mgxedcgKdQ0-0emvNW-kUsBB8Ran3ClN-01a5mE0PsZrwwXNnLenQ3T9foBUbxr6N50w0isAq3SREAqs-SjPhiaFZyVFGeAfsGg2oCNTd0iWlo3Eo/https%3A%2F%2Fspeleotrove.com%2Fdecimal%2Fdecarith.pdf>. More about Mike F. Cowlishaw's activities to this very day can be found here: <https://secure-web.cisco.com/1_RcI4AUln7-NaoHAUhRIi2B-XJjziVuDj4bPmnGZ6uoI6wqbj76uG5fyq6YCn87gzqzDxaMtQz2GARy2kYj_TLDrvIV-rYMncXqMBeDm-sjWG8Qlej5p8yKOEwpbzMgpWzXXWRoN-_MhoEVRtQf06SRd4xUvclRhz6-rMuLtObvzhK6DW5CV3_nrmMYRCDkw1eK22uwy6TGj8bpWidw2uFBlohl-bBFX8j0G8elpSFuw3qdCBaKa8j_KI6E_27c7-RUZJZFlfG-bSsfsx9WuseERJZU5IW9xa23cQAm26DX8ha1m92Y5HBr0shCOGo6YlHnbWG1bYugpZL1n7-CHJ6wtG6RmIJ3ji8WrkQuta1-AV1V1-sDBzLpnu8aHimRI5G8MppVLMO9bzoynRd5t8uI1zoLTYCcbUJLZs5sXQ_w/https%3A%2F%2Fspeleotrove.com%2Fmfc%2F>. BTW, next year's International Rexx symposium will take place in Vienna, Austria, and Mike has already stated that he will attend in person. So if you want to meet a legend, come to Vienna (Sunday, May 4th, through Wednesday, May 7th, 2025) and have fun at a Rexx specific conference thereby visiting one of the few Imperial European cities: <https://secure-web.cisco.com/1PUPqa3bu1HpoDEtO1zXrGDGNiUvvGelWxp8KMKDg0F-sCnZt4Olmh_1oKde8PsiJbXpwt8yX5e6ZaIweqOLbOOwd84Fg7KcrOhPALc4n9GzmyxAh2147EDsLzezsyBipJIXJPIyLSCZzffoZPCH890Hc54vNeNqIZb5jbUwWrv64F34h-5WikkmWm9EzjwhX1S4NtHJjERRRM4sRPabwRTFp4VH0s9kul5Xkh6W7FjDI2q9Jt-8gywZ0SCAmPlEhRhT95Ll2LMC6nJiqcGfVFB6Mv71TsVyTodMaSjvezGvrDaf78P4FncP8iKCAWGmSlm4iwyrGX_flHgV_Nz4Ua-ZbKUuNgoAyU5mGRHE_MLpdFqLy3nXuiPog0RniExfzK7n--XiXN5pmkbemiCMIjwtD5cEr4vhXxSi_hHyvd80/https%3A%2F%2Fwww.rexxla.org%2Fevents%2Fsymposium.rsp>. > Python, although not my preferred language, is significantly feature-rich. ooRexx with the Java bindings is significatnly feature-rich. There is nothing that cannot be done with ooRexx and its Java bindings. Java puts Python (and Lua and other languages) into the shade regarding feature-richness, performance and the number of persons and teams of outstanding software engineers that keep on improving Java constantly in the open-source based OpenJDK (=Java) project. Where you have an urgent and constant need for Python modules (usually for the same features there may be many different Python modules that are incompatible with each other, such that you usually get locked-in into specific Python module) to do even the most simplest things, Java has an incredible wealth of features directly available with its runtime environment where 99% of all important features are already present (hence no overhead, no need to locate and load modules just for becoming able to write some simple Python script). NetRexx being Java is significantly feature-rich (any Rexx programmer could get productive with NetRexx within a few minutes). The Java bindings of ooRexx make all of Java immediately available to Rexx programmers making ooRexx significantly feature-rich in all possible aspects. > Many REXX programmers stick with REXX out of familiarity and resist learning > something new. As long as there is no real need, why invest time to learn something that has no practical benefits for the professional tasks at hand? OTOH I concur that curiosity and following new developments and to assess them should be something professionals should do constantly. > From a customer-oriented perspective, avoiding REXX is advisable. This would be a bad advise without context and sorber cost calculations (from maintaining existing code-bases to devising, buying, training new technologies, and writing new programs to replace existing ones, possibly tested and reliably running for a long time, ...). > Even before Python or Java emerged, opting for offloads to zIIPs was a better > choice. Python offers a generous 70% zIIP generosity factor. Well this is something IBM controls as it sets the terms in this area. If IBM wanted they could improve their REXX support and offer a modern, object-oriented version that - due to its dynamic (= flexible) nature and feature sets - simply runs rings around static and statically typed languages. Rexx and ooRexx are ideal for controlling applications, being used a scripting and macro language, creating ad hoc solutions, and much more. ---rony >> On 29 Jun 2024, at 1:20 AM, Charles Mills<charl...@mcn.org> wrote: >> >> @Timothy, is that a Yes or a No? >> >> There has been a lot of discussion here about Rexx versus Python: "Why are >> you still using that old-fashioned Rexx when Python is so much more >> wonderful?" There are several answers, valid IMHO, including developer >> familiarity. But the key objection to Python, for third-party and similar >> software that is intended for use at multiple, often as-yet-unidentified >> sites, is the one I cite below: "if we write it in Python than any potential >> customer will have to download the Python run-time, and some customers are >> extremely reluctant to download and install non-standard (FSVO non-standard) >> software." (For Rexx, the run-time is a standard part of a z/OS install.) >> >> Is it your opinion, is it the community's opinion, that that objection has >> now gone away or is going away as time passes by and more and more shops are >> on a post-7/1/2024 download of z/OS? >> >> Charles >> >> On Fri, 28 Jun 2024 04:10:13 +0000, Timothy Sipples<sipp...@sg.ibm.com> >> wrote: >> >>> Charles Mills wrote: >>>> Am I reading this correctly that the "they would have to download >>>> it and some shops won't do that" objection to the use of Python for >>>> third-party software goes away, at least for customers with z/OS >>>> systems ordered after July 1? >>> These 3 products are ?bypassable requisites? effective July 1, 2024. See >>> Marna?s blog post for more details: >>> >>> https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/chandni-dinani2/2024/06/26/zos-modernization-new-bypassable-products?communityKey=200b84ba-972f-4f79-8148-21a723194f7f >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN -- -- __________________________________________________________________________________ Prof. Dr. Rony G. Flatscher Department Wirtschaftsinformatik und Operations Management Institut für Wirtschaftsinformatik und Gesellschaft D2c 2.086 WU Wien Welthandelsplatz 1 A-1020 Wien/Vienna, Austria/Europe http://www.wu.ac.at/ __________________________________________________________________________________ ---------------------------------------------------------------------- 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
