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 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 > > > ---------------------------------------------------------------------- > 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
