On 16.03.2024 00:35, David Crayford wrote:
Working with REXX doesn't feel comfortable to me at all.
Yes, one can tell.
I'm troubled by the fact that every function call carries a potential side
effect.
It is interesting how you keep communicating using FUD patterns ("fear, uncertainty, doubt")
pretending to talk about facts.
While we can resort to procedures, we then encounter the challenge of dealing
with telescoping exposure lists.
There is no problem here either.
If in addition you wanted arguments by reference then use ooRexx as the interpreter to run your Rexx
programs. ooRexx has the "use arg" keyword that you can use instead of the "parse arg" keyword
instruction. "use arg someStem." allows e.g. to fetch a stem by reference in a routine that was
supplied as an argument in a call, e.g. "call someProcedure someStem." .
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.”
If that was the case then there must be benefits that way outweigh whatever flaws you think there
are. However, it is FUD as you are not naming any.
The recent discussions on this forum have brought attention to the shortcomings
and limitations of REXX as a programming language.
Beg to differ: if someone has never worked with a specific keyword instruction and has no knowledge
about how Rexx saves and restores settings then questions are meant to help clarify the rules. Rexx
is quite well documented but again it is normal (for any programming language BTW) that if something
is unclear that one tries to get insights and the best way to do so is asking questions.
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.
Well, "millennials who are unfamiliar with REXX" can learn the language in one afternoon! (That is
not possible with popular languages like Java, Python, C# and the like) .
Heck, I am able to teach millennials who are non-programmers, real novices, programming with REXX
and ooRexx in a single (!) semester (four months). Reliably.
My millennials can program MS Excel or MS Word after two months via OLE. What about your
professional millennials learning Java or Python or C#, can they do that while learning those
languages after two months and e.g. create two-dimensional tables, formulas and graphics with MS
Excel as my students can? Your millennials mostlikely cannot do that due to the complexities of
those languages they have to master first before even becoming able to get at the OLE APIs of Windows.
In the last two months of that introductionary course my millennials learn how to write socket
programs (client-server programs), GUI programs, process XML files, how to apply XSLT, process HTML
5 (taking advantage of Jsoup). Can your professional millennials do that also after learning a
currently popular language after four months?
My novice millennials use for all of that Java class libraries such that the programs they create
run unchanged (!) on Windows, macOS and Linux. This is possible because the human-centric design
principle of REXX and ooRexx was applied to the design of the ooRexx-Java bridge as well, such that
they do not need to learn the Java programming language at all, believe it or not.
The reason why this is possible is simple, it is the programming language REXX that was successfully
designed to be human-centric and ooRexx adding oo features to REXX has followed that route as well.
It is one of the critical success factors that many popular programming languages lack.
Oh, BTW, I tried quite a few other languages with novice students to teach them programming, none of
them allow for this incredible type of productivity that REXX and ooRexx allows for.
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.
There is no surprise here. Again, a professional software engineer should have more than one
programming language in his toolbox in order to be as productive as possible.
---rony
P.S.: Having millennials *not* learn REXX when assigning them work on mainframes does not appear to
me to be too professional. If one extends your argument that millennials do not know REXX hence they
should not learn it to mainframes, then you should also suggest here that mainframes should be
replaced by Windows and Linux boxes as millennials do not know mainframes.
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
--
--
__________________________________________________________________________________
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
