[apologies ... this got long ... I count three topics]
I was actually rather stunned at the time (circa 1995), /amazed/ that
MVS could have a Unix face. Wow!
And then they did it on VM too. (With understandable constraints because
CMS is a DAT-off environment.)
Wish I could answer Phil's question and get it out of the way, but I
(still) live more on the VM side, so my knowledge of Java usage in z/OS
land is reduced.
Never the less, let me share this observation: Z and forerunners have
had micro-coding for a long time. When ZAAPs arrived and were promoted
for hosting Java workloads, I thought perhaps they had micro-coded JVM
into hardware. Now THAT would have been something! My dismay was great
when I learned this was not the case, that the ZAAP was merely a
ham-strung GP.
Java is its own ecosystem.
I generally disagree with the author (not having read the article, so I
actually disagree with the snippet): Java didn't save the mainframe.
I'm with Ed and Mike: _USS saved the mainframe (saved MVS, that is)_.
Martin is right, for one thing, a filesystem with arbitrary naming is
essential.
In the earliest days of USS, there were many traditionalists (especially
on the MVS side, but also VM, VSE, and the rest) who hated Unix and thus
resented USS.
But forget running "in" USS, just having access to that Unix-like
filespace is a big boost.
I figure the guy who wrote that piece lives in the Java ecosystem.
More about fileystems, when I wrote a web server for VM/CMS, I could
fake the arbitrary file naming of URLs and lay that on top of CMS
(either minidisk or SFS). But that was a hack and required manual
attention. Better to just let things be named as people expect (within
reason*) and not have to play name mangling games.
*users, especially in the extreme consumer space, are terrible at making
up meaningful filenames.
To this day, punctuation, especially blanks, are a real problem in
"arbitrary" filename space. Blanks are annoying on the web too (but
consumers don't notice).
Back to USS (and OVM), I will confess my own shock and knee-jerk reaction.
When I joined BMC, Steve Carl said I'd get to play with OpenVM. Yay!
(Shop I was in before that did not have it yet.)
So I spun-up the shell, brought in a tarball of my favorite shell
scripts, and ... what the heck? ... they were all garbled.
I had not considered the OpenVM (nor OpenMVS) would be EBCDIC. (My
scripts were all ASCII, of course.) So I shied away from it for like
seven months. What a waste of time.
Then it hit me: OVM and OMVS *had* to be EBCDIC because the underlying
operating system was EBCDIC. After that, I just ran with it ... and
loved it. (And now we have charset tagging, but that's a whole nutha
topic.) Given a decent C compiler (of which there were several in the
1990s) it was just a matter of time (and hard work) to bring in enough
Unix-like utilities. (And it would all be EBCDIC.) That would expose
what system services had to be added to the nucleus (and they were), and
eventually a proper POSIX environment was born.
All of this is old.
Unix on the mainframe predates USS by fifteen years, predates Linux by
more than two decades.
It started at Princeton in the mid 1970s. Amdahl acquired the project
and brought it to market as UTS in 1981. By 1986 it was fully native. It
was a better Unix than others of the time (early SunOS, certainly AIX of
that era, even true AT&T followers). And it had no allergy to 3270
tubes. (The UTS 3270 driver was bequeathed to Linux several years ago.)
Be wary, my friends. UTS is discontinued.
Linux might have killed it in the long run. But IBM gets a lot of blame
for its demise.
UTS only ever ran on mainframe systems (IBM Z and forerunners and
compatible). Since IBM forced all hardware competition out of the
market, UTS could only ever run on actual IBM brand machines. If you
want a market to thrive, you MUST allow alternatives.
That sorta brings us back to Java.
They're big on this "write once / run anywhere" thing, which mostly
works. (Perhaps not so much if one wants to optimize.)
So Java aficionados can take their object code and drop it on MVS and it
*should* "just work". Maybe.
But since the reverse is also true, I don't see it "saving the
mainframe", unless the mainframe is just soooo much better in one way or
another.
Oh, yeah, that's right: ZAAP isn't a JVM in hardware. Bummer.
-- R; <><
On 3/26/25 12:16 PM, Mike Shaw wrote:
+1 Ed.
I was at the Poughkeepsie TDM where Don Ault gave ISVs the initial
presentation on Open MVS. That was way before Linux was ported to the
mainframe. At the time, I didn't understand the need for OMVS, but it has
turned out to be a lifesaving element that has kept our ecosystem afloat.
Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.
On Wed, Mar 26, 2025 at 11:10 AM Ed Jaffe <
[email protected]> wrote:
On 3/26/2025 7:38 AM, Phil Smith III wrote:
https://www.quora.com/What-are-some-notable-failed-programming-tools-that-promised-to-revolutionize-software-development
Trausti Thor Johannsson's response (which is currently at the top there,
but might not be later) includes "[Java] not only made Mainframe computers
not die but made them very useful."
I don't think I've ever seen anyone claim that Java saved IBM Z, nor
that it's a major use case. Yeah, it's there, but even with zIIPs and zAAPs
it's not all THAT common, is it? Or have I just been working with the wrong
sort of customers?
I have said *many* times that z/OS UNIX nee OS/390 USS nee MVS Open
Edition saved the mainframe. Of course, by "mainframe" I meant
traditional z/OS mainframe environments.
Years ago, I met Bill Schoen at an IBM TDM reception in Poughkeepsie and
shook his hand so vigorously that he probably remembers it to this day.
I told him that I credited him, more than any other individual in the
world, with saving the mainframe. If Don Ault had been there, I would
have congratulated him too. That team (I think they were in Kingston at
the time) implemented a fundamentally-crucial difference in capability
that has been leveraged over the years by TCP/IP, Java, z/OSMF, and many
other critical components. And now Kershaw Mehta and his team, standing
on the shoulders of giants, continue that great work by fundamentally
improving z/OS UNIX to support native containers.
--
Phoenix Software International
Edward E. Jaffe
Chief Technology Officer
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/
--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system
into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email [email protected] with the message: INFO IBM-MAIN
--
-- R; <><
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
