Here is my list of must haves for a scripting language. Does REXX or
ooRexx meet the requirements?
1. Short circuit evaluation
2. Functions as first class objects
3. Mutli-threading
4. Dynamically typed, preferably with type hints
5. co-routintes
6. A module system
7. Support for object oriented programming
8. Regular expressions
9. Libraries for web programming, pegs, JSON/YAML parsing etc
It's my understanding that IBM dropped Swift because there was no
interest in it. They have since ported Golang which is more useful. For
example, running Prometheus/Grafana natively on z/OS or Docker.
On 6/1/22 7:46 pm, René Jansen wrote:
Answers inline.
On 6 Jan 2022, at 04:54, David Crayford <[email protected]>levelled. If young
employees don’t want to work on 3270 tube images or JCL, maybe we should stop hiring
prima donna’s but instead disadvantaged people who want to work and learn something.
It's insulting to call young people prima donna's just because they don't want
to use 3270 or JCL. Are we pima donna's because we didn't want to use paper
tape and typewriters to write code? Technology moves on and the mainframe has
to keep up. And I'm happy that IBM are doing a brilliant job of doing that.
I used all of those including punch cards. It was needed at the time. You did
not parse the sentence right, it started with if, and young is just an adverb.
I know some old men here that categorically refuse to logon to z/VM - they also
are prima donna’s. So don’t make it look like I said anything about young
people. I know a lot of young people who work on 3270 and don’t complain.
Tragically, the true value of the mainframe, which is realized in all those
products you call old, is not realized in those ‘modern’ programming paradigms
- remember the first TCP implementation for MVS ? - it ran like a dog and
chewed up whole lpars while VTAM still did the work. This was of course because
it was a straight port of the code for some other architecture.
Have to disagree with you there Rene. I work with the guy who was the architect
for OMVS back then and TCP was implemented in Pascal with a crap compiler. It's
a topic of nostalgic jokes on our internal slack channels.
If you have seen the code then you must know that it did not really utilize the
channel architecture. We are talking pre-omvs. OMVS needed TCP and not the
other way around. The second Pascal version was a lot better because it
understood architecture.
Moving to other tools while they are not ripe for the environment would be
irrational. I don’t know what happened to the budget for Swift on z/OS but I
hope you see what I mean. A port of Python that is not ready will accomplish
the same thing. Your prima donna’s will complain that library X, Y or Z is
still not available on the mainframe and pressure their management to go off it
- I see that happen every day, while fighting performance myths and disasters
caused by ‘modern’. It is undeniable that git - which I love and use every day,
is much more complicated on z/OS because of EBCDIC, access methods, records and
block sizes. This is the reality and we should not deny it to please people who
learned to allocate a file with ‘touch test.txt’. They will get stuck without
that knowledge and hate their work even more.
A Swift port wasn't expensive. IBM had already ported LLVM to z/OS using a
ported front end and their TOBY back-end so it was just a matter of interop.
Same with golang etc, etc. Now there is a real z/OS port open source port of
LLVM the possibilities are endless. Why not be positive about the future?
Another suggestive statement. I can argue with you about facts, without
accusations and suggestions. Can you? I worked with the Swift compiler, to sort
out some things for a colleague. I liked it and am disappointed IBM now
decided, over Medium, to push Python, which I find decidedly mèh and not
innovative at all compared to Swift. While knocking Rexx without any valid
content. Because it is old? Exec and Clist are old, and I don’t need to say
anything bad about it, they just are available and keep running.
We all have different tastes and that is one thing, another thing is when that
taste is driven by commercial interests. And still another when those interests
are going against the best interest of the platform.
The best interests of the platform is maintain the system of record and the
legacy and then modernize. Otherwise, the platform with wither on the vine.
I worked on systems in the other side of the ocean on a pensioner’s adsl (half
the cost, half the speed). The only thing that works well is 3270, and
technical people must know why it is better than RDP. While putting Racf on a
z/VM and protecting the tcpip too well, I had to fall back to the emulator on
the HMC. I am still dreading the moment that might happen again.
To keep this alive, IBM should invest in Rexx, provide an OO version and make
sure the compiler, which generates revenue, is uplevelled to 64 bit. If it
chooses to back Python, that is fine with me, but it can be done without
pitting it against Rexx. The adoption of Rexx was a groundswell against IBM
management, that made strategic choices at the time like we need to use TSS, go
off VM and convert to JES3.
Then of course it should invest in Python to make sure its interfaces can call
24, 31 and 64 bit code, use or replicate the existing ADDRESS environments, and
that will be a lot of work. Then it is to be seen if that investment can be
recuperated.
What would be even better is to let the customers decide and develop. For some
reason IBM stopped taking care of the tools that brought in the money, and
instead of letting customers take care of them, it sold off or outsourced a lot
of stuff. There are a lot of people willing to work in this, but the source is
closed and the development environments expensive. *That* is the real old-world
thinking here. Other companies (I heard Amazon, lately) are writing whole API
compatible layers now to enable companies to re-platform their stuff, those
must be enormous investments, and IBM could obviate them with opening up the
development environments and right-pricing the OS and hardware; put in a
services model. It is no coincident that a machine with only IFL’s in it is a
tenth of the price? Those miss one or two instructions - and that exactly shows
you the value of z/OS and other things that are being called old.
Best regards,
René.
On 5 Jan 2022, at 05:20, David Crayford <[email protected]> wrote:
On 5/1/22 12:01 pm, Bob Bridges wrote:
Hm. If that's true of many shops (and it sounds plausible), maybe my sneers at
the colleges' ignorant comments are ill-founded and they may be starting to win
their war against the mainframe. Of course, if their efforts have a lot of
effect then surely the need for CICS will reverse the trend...wouldn't you
think?
I don't think the universities have got anything against the mainframe. They
don't have access to them. IBM should make mainframe emulators freely available
to all universities. Some of our best young guys have degrees in engineering,
not CS. It takes a long time to train new hires on the mainframe. For example,
JCL is arcane and generally despised by kids who have grown up coding shell
scripts. As you mentioned CICS it's worth noting that CICS supports both Spring
Boot and Node.js. They set the standard for modernization. The open beta has a
new has a new YAML file for resource definitions that comes with a JSON schema
so you can get context assist in editors and validation in the DevOps pipeline.
The CICS guys innovate and modernize. I salute them.
---
Bob Bridges, [email protected], cell 336 382-7313
/* [On the observation that every culture has words equating "uncivilized" and
"foreigner":] Tragic? It's sidesplitting! It's the only joke the Almighty ever
repeats, because it never grows stale with use. -from _Star Beast_ by Robert A Heinlein. */
-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of
David Crayford
Sent: Tuesday, January 4, 2022 21:48
It's true. The company I work for has been on-boarding millennials for years
now to replace the guys that are retiring. I work with some very smart young
guys, some of who write systems level code. None of them use REXX unless it's
used in a product they are working on. We're ripping and replacing decades old
build tools written in REXX with Python because it's become technical debt and
no one can support it.
The typical millenial uses:
* An IDE such as VS Code, IntelliJ, Slickedit with plugins for
mainframe languages and to access the MVS file system.
* They don't use TSO or the ISPF editor so there is no need for REXX
edit macros etc. ISPF is mainly used for SDSF and submitting jobs.
* They work in a interactive shell and use UNIX utilties.
* Everything is stored in Git repositories.
* They code scripts in Python, Node.js or a JVM language.
--- On 5/1/22 10:06 am, Seymour J Metz wrote:
That's David Crayford, not me. I have no basis to either confirm or contradict.
It's unfortunate if true.
________________________________________
From: Bob Bridges [[email protected]]
Sent: Tuesday, January 4, 2022 9:03 PM
Shmuel, I'm interested (and perhaps a little dismayed) at your third point. I've gotten
the impression, from reading ads about job openings, that REXX programmers aren't very
thick on the ground even at IBM where you'd think it'd be pretty easy to find them. But
"shrinking by the day"? Where do you get that? I'm not disagreeing -- I have
no data -- but have you?
-----Original Message-----
From: David Crayford
Sent: Tuesday, January 4, 2022 19:23
1. IBM are too busy porting contemporary languages like Python, Golang
and Node.js
2. No vendor will port ooRexx because there is no market for it that is
willing to pay support
3. The pool of REXX developers is shrinking by the day and no young
people want to learn it unless they have to
----------------------------------------------------------------------
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
----------------------------------------------------------------------
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
----------------------------------------------------------------------
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
