Have you heard of Dave Plummer's Primes benchmark project, which is
widely regarded as a reliable way to test the speed of programming
languages? In this test, ooRexx only managed to complete 13 passes in 5
seconds, while Python with numpy completed 6969 passes, thanks to its
ability to leverage GPU processing power. Given that Python has a large
community of developers backed by big tech, it's not surprising that
more investment is being made to improve its performance compared to
REXX. Similarly, TSO/ISPF is only supported by one person, so IBM may
not prioritize investing in it as they focus on other strategic areas to
keep the mainframe technology relevant. While this news may not be
welcomed by some, it's important to consider the bigger picture of
ensuring the longevity of mainframe technology. We need to attract young
talent to the platform not handcuff them with tools for the 1970's no
matter how comforting they may be for old timers like us.
❯ rexx PrimeRexx.rex
joss_REXX;13;5.084288;1;algorithm=base,bits=8,faithful=no
8:59
❯ python3 PrimePy.py
Passes: 6769, Time: 5.000584452878684, Avg: 0.0007387478878532551,
Limit: 1000000, Count: 78498, Valid: True
emillynge_numpy; 6769;5.000584452878684;1;algorithm=base,faithful=no,bits=8
[1] https://github.com/PlummersSoftwareLLC/Primes
On 1/3/23 20:52, René Jansen wrote:
I agree with Rony. I think your ‘benchmarks’ are a bit synthetic but I
understand your goal. I think calling ISPF ‘a relic’ and constantly badgering
Rexx does not serve any purpose in front of this audience, most of which see
ISPF as something shiny and worthwhile (e.g. to have on OS VS2 r3.8 (clones of
Rexx and ISPF have even been built there recently)).
We know IBM has divested some of its software maintenance. It is important to
remember that ’the new mainframe’ *if casted in the image of Windows or Linux*
always would be a hampered version of something. The mainframe is a high-end
market and not everybody needs one anymore. It could be competitive, but it
would need competition, a sane pricing scheme and less RACF admins reared in
the 80’s ‘lock her down’ mindset. That last thing, not the toolset, is why it
is hard to get new staff in.
If good tools were enabled young people would choose them and use them. There
is no need for any badmouthing or skewed benchmarks. If one needs fast I/O, one
writes assembler or COBOL. It is important to not let new tools loose before
their time, and seen the difference in the number of interfaces to the OS
compared to Rexx, the time of Python has not come yet. I remember IBM or
Rational people demoing the new GUI way of working to grumpy old COBOL
programmers, and always having to open a 3270 TSO session to do something or
other before the demo could go on. It was a laugh. In the end, it meant that
the quality of people’s 3270 emulators went down the drain and they were
grumpier than ever.
I am sure Visual Studio Code is a nice editor (I sometimes use it on the Mac
for markdown, mermaid plugins etc) but it is not going to sell mainframes -
there will be VBS to confront, and maybe VSAM. And obj modules. And probably
Cool:gen or RPG. What adaptation to modern dinky machines does, is more dynamic
memory usage, more senseless multithreading and worse algorithms - just read in
that 88MB XML file and shove it into a Db2 column. Where you used to be able to
run an LPAR flat out at 100%, you cannot do that anymore because websphere and
service oriented architecture.
With IBM’s current approach and its horrible handling of its intellectual
property (sealing it off from a legal perspective, and neglecting it from a
development point of view) the mainframe is going to be a niche market. That is
not bad in itself: look at Tandem, long dead but still non-stop running a very
large part of cards transactions.
If IBM had been serious about the cloud, it would have been forced to
acknowledge that it would have been best and cheapest to run it on mainframe
lpars in sysplexes and on COBOL, but alas, they were not serious at all and
told us mainframe ‘always were the cloud’ but forgot to build one doing what
they did best.
We like Xedit, we like ISPF. We like Rexx, and we are very fortunate that IBM
open sourced Object Rexx and NetRexx before that window closed and the open
sourcing was locked down with ‘business cases’. It also meant, of course, they
are never going to maintain it again. We now see important parts in the hands
of private companies, and we see everything we know built anew, but worse. And,
old problems, once solved, are coming back (memory fragmentation anyone?).
Transactions? We now have No-SQL but please don’t run my bank accounts on it.
My suggestion would be to keep working on new things, but we don’t need the
negative propaganda. On the other hand, now would be a good time for IBM to
open source and publish everything they reaped the benefits from over and over,
instead of allowing it to wither and waste. And IBM should invent some good new
stuff.
best regards,
René.
On 1 Mar 2023, at 12:15, Rony G. Flatscher <[email protected]> wrote:
On 28.02.2023 20:55, David Crayford wrote:
I respectfully express my opinion without intending to badmouth anyone. I
believe that benchmarking the performance of reading a large file is not an
artificial test but rather a real-world use case that we encounter regularly.
It is no secret that REXX on z/OS can be slow. In fact, one of my colleagues
who worked on the IBM File Manager product, which incorporates REXX scripting,
developed their own subset of REXX because the performance of the TSO REXX
interpreter did not meet their objectives.
If that is the case then it shows that IBM needs to maintain their mainframe
REXX by replacing it with an up-to-date version of REXX (finally).
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
