Hey Rony, From what I understand, you haven't had experience working on z/OS. Let's stick to the topic and focus on discussing REXX as it functions on z/OS. This means no discussions about ooRexx or Java bridges, as they don't exist and are unlikely to in the future on z/OS.
The majority of REXX programmers here utilize classic TSO REXX and primarily work within a TSO/ISPF environment. In this setup, REXX lacks a module system. Therefore, any routines or libraries need to be manually copied and pasted wherever they're needed, or you have to create a pre-processor to merge source files together. If your language lacks the fundamental basic features to sort an array then to me that’s a good indication you should use one that does. I'm not spreading fear, uncertainty, and doubt (FUD). I'm simply stating my observations based on over 30 years of using REXX on z/OS, including developing extensions. I believe this gives me a significant level of expertise to offer commentary on the matter. > On 16 Mar 2024, at 6:03 pm, Rony G. Flatscher <rony.flatsc...@wu.ac.at> wrote: > > On 16.03.2024 01:17, David Crayford wrote: >>> On 16 Mar 2024, at 7:45 am, Jay >>> Maynard<000005997213d6c2-dmarc-requ...@listserv.ua.edu> wrote: >>> >>> That depends. Can you use, say, Python to implement all the scripting kinds >>> of things you can use REXX for? >> Like what, TSO? I don’t find I need to do that any more as I work in a UNIX >> shell. Let me flip that around. Can I use REXX to implement the kind of >> scripting that I do in Python? For example, process a YAML configuration >> file. > Yes, if you wanted, it is fairly easy BTW and would not be as potentially > dangerous if done in REXX than done with Perl or Python (cf. > <https://en.wikipedia.org/wiki/YAML#Security>). >> We need to do that stuff on z/OS now. CICS resource definitions can be >> defined as YAML documents, configuration as code and all that stuff. DevOps, >> Git repos. REXX is a pretty poor language for anything modern. > > Again, unsubstantiated and derogative, please just stop behaving like a > religious warrior and stick to facts and discuss sorberly, stop your FUD > please! > >> IBM and ISVs are working on Python APIs for products right now. > That is fine. On slides and in imaginations everything in the future is > always much better than what is available at present. >> And they will be better than the REXX versions. > > Well, that has yet to be seen. If improvements materialize, then it would a) > be fine and b) be a reason to look into the existing, working REXX versions > for the same improvements then. > > A massive improvement for the mainframes were to make ooRexx available on > them. > > Combine ooRexx with the ooRexx-Java bridge and software engineers have > immediately gained the ability to use *any* Java API from ooRexx, without a > need to learn Java at all, it suffices to be able to read the HTML > documentation of Java classes. The easiness and the productivity gains can be > inferred if you know that my novices can do this successfully during the last > two months of the semester even becoming able to exploit the SSL/TLS Java > socket classes, besides awt/swing, JavaFX and some more. > > The potential savings for the mainframe users would be enormeous if they > started to exploit that combination. It is actually available already today > in the Linux subsystems such that one can assess the technology (I know of > deployments that exploit this combination in production, using ooRexx to run > programs that interact with DB2 using JDBC). > > ---rony > >>> On Fri, Mar 15, 2024 at 6:36 PM David Crayford < >>> 00000595a051454b-dmarc-requ...@listserv.ua.edu> wrote: >>> >>>> Working with REXX doesn't feel comfortable to me at all. I'm troubled by >>>> the fact that every function call carries a potential side effect. While we >>>> can resort to procedures, we then encounter the challenge of dealing with >>>> telescoping exposure lists. When I hear about adapting to quirks, it seems >>>> to translate to "I acknowledge REXX's flaws, but I stick with it because >>>> it's what I'm familiar with, even if I have to tolerate it.” The recent >>>> discussions on this forum have brought attention to the shortcomings and >>>> limitations of REXX as a programming language. >>>> >>>> In comparison to other platforms, Z/OS used to offer limited options in >>>> terms of programming languages. However, that's no longer the case. What >>>> struck me as ironic during my recent presentation was that the majority of >>>> the audience were millennials who were unfamiliar with REXX. This might >>>> come as a surprise to seasoned veterans of mainframes who are used to REXX, >>>> but in today's landscape, familiarity with it isn't necessary. >>>> >>>>> On 16 Mar 2024, at 7:19 am, Seymour J Metz<sme...@gmu.edu> wrote: >>>>> >>>>> Every language has pitfalls. While I generally prefer strongly typed >>>> languages, I find Rexx and ooRexx to be comfortable to work with, and it is >>>> not difficult to adapt to its quirks: >>>>> <http://www.rexxla.org/Newsletter/9812safe.html> >>>>> <http://www.rexxla.org/Newsletter/9901safe.html> >>>>> >>>>> -- >>>>> Shmuel (Seymour J.) Metz >>>>> http://mason.gmu.edu/~smetz3 >>>>> עַם יִשְׂרָאֵל חַי >>>>> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר >>>>> >>>>> ________________________________________ >>>>> From: IBM Mainframe Discussion List<IBM-MAIN@LISTSERV.UA.EDU> on >>>> behalf of David Crayford<00000595a051454b-dmarc-requ...@listserv.ua.edu> >>>>> Sent: Friday, March 15, 2024 6:40 PM >>>>> To:IBM-MAIN@LISTSERV.UA.EDU >>>>> Subject: Re: Rexx numeric digits and scientific notation question >>>>> >>>>> REXX can indeed be quite tricky to navigate. I recently conducted a >>>> session titled "Python for REXX programmers" at work, and during the >>>> preparation, I was surprised (although not entirely) by the numerous traps >>>> and pitfalls inherent in REXX. When you add to this its absence of basic >>>> functionalities like sorting lists, it begs the question: Why opt for REXX >>>> when we have a plethora of alternatives available today? >>>>> The obvious answer may be familiarity, but in our industry, this >>>> argument seems rather weak unless you're confined to a limited environment. >>>> After all, I wouldn't want to revert to using a 1990s-era flip-top phone, >>>> let alone a rotary dial from the 1970s. >>>>>> On 16 Mar 2024, at 2:47 am, Charles Mills<charl...@mcn.org> wrote: >>>>>> >>>>>> Well, that explains a mystery. I did not realize that SIGNAL ON was >>>> pushed and popped on subroutine calls. I have had this vague problem where >>>> my SIGNAL ON NOVALUE did not seem to work but at the time of an error it is >>>> always easier to fix the NOVALUE condition than troubleshoot the SIGNAL ON. >>>>>> Thanks! >>>>>> Charles >>>>>> >>>>>> On Thu, 14 Mar 2024 12:04:00 -0500, Glenn Knickerbocker < >>>> n...@bestweb.net> wrote: >>>>>>> On Wed, 13 Mar 2024 11:01:30 -0500, Charles Mills<charl...@mcn.org> >>>> wrote: >>>>>>>> And the answer is ... "The three numeric settings are automatically >>>> saved across internal and external subroutine and function calls." >>>>>>>> I was setting numeric digits in an initialization subroutine, so Rexx >>>> helpfully unset it on return from initialization. I thought I had done it >>>> that way before but I guess I have not. >>>>>>> Funny, I work with a lot of code that has a common subroutine for >>>> retrieving a TRACE setting to set in the main routine, and I never even >>>> thought about why, or about all the stuff that gets saved across calls! >>>> From CALL HELPREXX on VM: >>>>>>>> The status of DO loops and other structures: >>>>>>> --though, importantly, not the *indices* of the loops! >>>>>>>> Trace action: >>>>>>>> NUMERIC settings: >>>>>>>> ADDRESS settings: >>>>>>>> Condition traps: (CALL ON and SIGNAL ON) >>>>>>>> Condition information: >>>>>>>> Elapsed-time clocks: >>>>>>>> OPTIONS settings: >>>>>> ---------------------------------------------------------------------- >>>>>> 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 >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> 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 >>>> >>> >>> -- >>> Jay Maynard >>> >>> ---------------------------------------------------------------------- >>> 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
