> 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. 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. IBM and ISVs are working on Python APIs for products right now. And they will be better than the REXX versions. > > 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 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 >> > > > -- > Jay Maynard > > ---------------------------------------------------------------------- > 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
