On 7/29/23 11:28 AM, Jon Perryman wrote:
Can anyone provide the definition of MAINFRAME? The ARS Technica
article is complete nonsense because the mainframe is a state of
mind and nothing to do with reality. Can anyone prove me wrong?
I tend to agree that mainframe can be a state of mine which is formed by
history and available associated technical solutions.
The IBM z16 is just 4 motherboards containing 16 CPU and many PCIe
slots. Linux will run on an IBM z16. Is a PC also mainframe? Forget
zPDT because I suspect it still uses a PCIe zCPU card. I can't say
with any certainty, but I suspect that z/OS will run on a PC by using
Hercules. What is the definition of MAINFRAME?
I'm fairly certain that zPDT and RDz are purely software emulated
mainframes. I've not seen anything like the P/390-E card in a long time.
I also know for a fact that people have gotten some versions of z/OS to
run in Hercules.
1. CPU does not make a mainframe:
I think that the CPU and what it's optimized to do hints at what it is
well suited to be used for.
I've seen video evidence of a single human being tugging an air plane
from the gate. But that doesn't mean that airports are giving up on
their tug vehicles.
2. Hardware does not make a mainframe.
I think that the hardware and what it's optimized to do hints at what it
is well suited to be used for.
3. OS does not make a mainframe.
I think that an OS and what it's optimized to do hints at it is well
suited to be used for.
I know that my last three comments have effectively been an "it is what
it is" type of answer. But the crux of it is that the $THING has been
optimized to do the task that it's employed to do.
I wouldn't use an El Camino to haul rolls of steal to a factory any more
than I would use an eighteen wheeler to deliver a pizza.
Linux running on z16 doesn't make it mainframe Linux. There's nothing
stopping Linux from taking advantage of every z16 hardware feature
(e.g. 1,600 PCIe slots) but no one is willing to build the Linux
software.
I question the veracity of that statement.
Let's start with this - please share one z16 feature that Linux doesn't
use so that we can discuss it.
I'm sure there are a number of them. But I suspect the reason that
Linux doesn't use it is for possibly surprising reasons. Reasons that
are probably rooted in the origins of things.
IBM hasn't duplicated z/OS software features in Linux.
I actually largely agree with that statement.
To me, the biggest things that differentiates the mainframe / z/OS /
etc. from Linux is the other facilities that the mainframe / z/OS provide.
I think the package suite / solution stack that is the mainframe to be
the most salient thing that differentiates the mainframe from
non-mainframes.
I've read many articles / heard (recordings of / videos of) some
discussions where people say that porting applications from z/OS to
Linux isn't a matter of re-compiling things. Sure, the code will, or
can be made to, compile on Linux. But many the supporting facilities
that z/OS provides are completely non-existent.
4. Software does not make a mainframe. IBM sells DB2 for Linux and DB2
for z/OS.
I think that significant differentiators actually are software. It's
just not -- what I'm going to call -- the primary line of business
software like DB2 / Domino / SAP / etc.
I think it's other software, CICS, RACF, IMS, etc. that provide
supporting services afor the primary line of business applications.
DB2 for Linux runs on all hardware including z16. With Linux, you
can still run DB2 on z16 but large customers choose DB2 for z/OS.
I take what others are doing with a huge grain of salt. I've seen too
many businesses continue to run something somewhere that it has been
running for a long time because of non-technical reasons. People.
Support. Technical debt.
ASK YOURSELF: Since design philosophy is the only difference, name
the philosophy that makes a mainframe.
From what I've seen, the mainframe has integrated reliability,
availability, and serviceability (RAS) at the hardware and OS level.
Conversely, Open Systems tend to not have the RAS capabilities that the
mainframe has. As such, Open Systems application designers have
integrated RAS like features at different levels if they cared to have
them because the hardware / OS didn't provide them.
Despite the story's false claims for z/OS relevance, it is ignorance
in the Linux community that makes IBM z/OS relevant. Specifically,
it's the lack of design in Linux. Consider DB2 for Linux and DB2
for z/OS which are the same product both from IBM and available on
an IBM z16. Linux people tell you they provide the same results,
but they ignore the intrinsic capabilities of z/OS design.
Does ignoring the intrinsic capabilities of z/OS design alter what the
DB2 on z/OS vs DB2 on Linux on z is capable of doing?
I'm talking brutal dollar for dollar, pound for pound, BTU for BTU, etc.
I think that for most people, if not the vast majority, a lower end and
lower capable system is perfectly fine for them.
DB2 for Linux supports high availability and large databases but it
requires knowledge of big data solutions, Linux clustering solutions
and more.
Are you positing that knowledge of those same things is not required to
run DB2 on z/OS?
Add a computer to the cluster and you must replicate the master
disk. Take a computer offline from the cluster, then it must re-sync
or replicate the master disk.
I question the veracity of that.
My limited first hand experience with Linux and Windows OS level
clustering did not require any replication.
My understanding from discussions with friends who mess with it tell me
that (Open)VMS doesn't even require disk replication.
DB2 on z/OS does not experience these problems because of z/OS shared
dasd and dasd mirroring.
Open Systems have been using shared storage since (at least) the mid-90s.
/shared/ storage is completely different than /replicated/ storage.
Sharing is sharing, as in multiple systems access the same storage, be
it SCSI disk on a shared SCSI bus or shared LUN on a SAN.
Replication is replication, as in the same set of data is written to
multiple disks.
To me, shared access and replication are orthogonal to each other. You
can use one and / or the other. This seems to be true for any server
level OS / platform that I've looked at since the mid'90s.
ASK YOURSELF: Name 1 brilliant feature design that originated directly
from Linux or Unix. Please don't use features that originated from IBM
(e.g. databases, SQL, HTML, Cloud and more).
Does TCP/IP or SOCKETS count?
Wasn't HTML developed beside HTTP on Next computers at CERN? I've not
seen anything that HTML was developed by IBM.
I dare say that cloud was re-invented independent of IBM, probably
because too many people were ignorant of what IBM had to offer.
Brilliant feature design exposes very little. For instance, does anyone
know the problems solved by z/OS shared dasd and dasd mirroring. Linux
people on the other hand can easily name those problems solved if you
mention clustering solutions and big data solutions. I've personally
seen one sysplex split between 2 sites 40 KM apart using line of
site satellite dishes for communication, yet z/OS app programmers
were informed.
What do you mean by "z/OS app programmers were informed"?
I think that the Global Mirror technology is a wonderful thing. I know
that IBM has some very impressive solutions for this in z/OS and AIX. I
assume that they have similar for IBM i.
This also gets into SAN replication over long distances.
Open Systems can rely on the SAN backend to provide some features and
not have to worry about it themselves.
Aside: I think that sort of hints at a difference between mainframes
and Open Systems - Open Systems are frequently utilizing solutions (as
in facilities) of other components of the ecosystem. Conversely, IBM
had to develop many of these solutions to provide them to the mainframe,
mostly because the concepts didn't exist when IBM created them.
In other words, IBM designs for the 21st century.
I feel like this is late 20th century for all mentioned platforms.
ASK YOURSELF: Name 1 brilliant unnoticed Linux feature. Name several
brilliant unnoticed z/OS features.
How can a feature exist and be unnoticed?
I think there are many under utilized features of Open Systems.
The story claims Linux feature design is similar to z/OS feature
design. For example, the story claims Unix filesystems provide the
same functionality as z/OS datasets. A filesystem is the equivalent of
one PDS/e (even in Linux).
I can understand why someone might make that statement from a simplistic
point of view. I don't know if that simplistic point of view was for
the article's author and / or target audience.
This also gets into a question with a lot of minutia of "what is a file
system"? There are many aspects to the conversation.
In fact, z/OS Unix filesystems were built from PDS/e functionality. A
filesystem is a container file containing the files in a Unix
filesystem. You may have a filesystem using 10 disks but that's
not any different than a single z/OS PDS/e file with 10 full disk
extents. Like PDS/e members, files in a filesystem are randomly placed
in the filesystem.
I think that asking "what is a file system", "what is a database", and
"what are the differences between a file system and a database" start to
get very interesting when you start looking at each of them in different
ways. Ultimately, both of them are ways to store and access information.
ASK YOURSELF: Name 1 fundamental difference between a PDS/e and a
Unix filesystem.
What their intended purpose was at design time.
Probably what their access methods are.
ASK YOURSELF: Name the z/OS Unix feature that sort of fixes the
fundamental design flaw with Unix filesystems just described?
I don't see differences in design as a flaw any more than I see
different languages around the world to be a flaw. They are just
different, have different heritages, and are optimized for different things.
I suspect most people won't think about each user having a unique
filesystem using automount to make their filesystem available.
While that may be true, how does what most people do mean that what
other people do is wrong?
Just look at Fahrenheit verses Celsius vs Kelvin. Each does the same
thing just with different values and common reference points.
Typical Unix uses one file system with all users having directories
in the /user directory.
I question the veracity of that as written and the assumed intention
behind it.
1) I'm assuming you meant /usr, not /user.
2) User's home directories usually are in /home on Linux.
As to the concept of dedicated storage per user vs shared storage per
user, independent of where it happens to be mounted, seems to me to be
largely related to how space is allocated.
If you have a 100 ${UNITS} disk and you hard allocate 10 ${UNITS} to 10
users, you no longer have any free space in that disk to allocate to the
11th user. Conversely if you have users sharing the 100 ${UNITS} disk
and each user is taking ~2 ${UNITS} you can probably get 50 users on
that same 100 ${UNIT} disk.
The mediocre design philosophy extends past Linux and enters into
the programmer mentality.
I don't think I'd use "mediocre" to describe that.
But, yes, the mentality of what you're used to permeates what you do.
It takes effort to overcome what you know, learn new things, and change
how you do things. It takes an entirely different effort to get others
to buy in on the new thing that you want to do.
ASK YOURSELF: Name 1 z/OS application programmer that uses bTree,
big-O, clustering, big data and various other techniques required
for Linux.
That statement gives me indigestion.
Are you saying that IBM doesn't use bTrees inside of various different
things to optimize access through a consistent interface?
I think of big-O as a way of measuring something and it applies equally
well to the mainframe / z/OS as it does to iOS running on my watch.
I feel like Coupling Facility and clustering have similar effects even
if they have completely different execution methods.
How does the size of the data, or what is done with that data have
anything to do with Linux vs z/OS vs some other platform?
ASK YOURSELF: Name 1 reason why Twitter could not have been easily
written in Cobol on z/OS.
My only problem is with "easily". I think that it probably is possible
to write Twitter (or the next big thing) in any language on any
platform, including Cobol on z/OS.
I think the easy of access to z/OS for small shops / start ups is a HUGE
problem. As such small shops / start ups are going to work on the
platform that is at their disposal.
I view this as a failing on mainframe's caretaker's part, specifically
IBM management.
Excluding the user interfaces (e.g. phone app, Windows app, web browser
app, ...).
If we're having a thought experiment, then let's have the thought
experiment.
Why couldn't the user interface be coded on / run on the mainframe / z/OS?
I strongly suspect that someone could code the source files in ISPF's
editor and then cross compile with gcc in OMVS / USS.
As -- I think -- you said elsewhere, the mainframe (z/OS / OMVS / USS)
can run X11 clients applications for display on X11 display server's
elsewhere on the network.
So I maintain that Twitter, et al., could have been written in Cobol on
z/OS. But I also maintain that it likely wouldn't be /easy/ by any
stretch of the imagination.
I'm not saying I would be willing but it's doable without additional
effort.
I think it would take additional effort.
As many complained, the article says z/OS requires hundreds to
thousands to support it. Twitter went from 7,000 employees to
2,000.
I think there is a HUGE difference in creating something vs running said
creation.
One person can live in a house by themselves but they almost certainly
wouldn't be able to build said house by themselves.
Similarly, mainframes / z/OS can be run very few people, yet almost
certainly couldn't be created by the same small number of people.
Since it did not fall apart,
I question the veracity of that statement.
the real question: do Linux developers understand how to create a
well-designed application?
I think you can replace "Linux" with "most". If you do so, I'll agree
wholeheartedly.
As more and more applications are written for the web and / or Node.js,
which are largely platform agnostic, we see evidence that way too many
developers don't know how to do well designed applications.
z/OS applications programmers are business line experts whereas Linux
applications programmers are computer experts who create programs
for the business line. Exactly what makes them a computer expert?
The simple fact that they create something that the people that are
paying to have them crate said thing makes the more of an expert at
program creation than the people that are doing the paying.
I suspect that many mainframe programmers have had a luxury that I have
found lacking in Open Systems. I often encounter push back when I
inquire about how the business operates, what they do, who their
customer base is, how they ship products. I ask these questions so that
I build a mental image of what their business is so that I can recommend
solutions in line with my understanding of their business.
Unfortunately, so much development has come down to I want $THING that
does $JOB and no you can't know any more about what it will be used for,
where it will be used, nor who's using it.
I view such pigeon holing as a bad thing.
The story falsely claims Cobol is an ancient language.
When many thing things are old after 99 days, yes, Cobol which first
came out decades ago is ancient.
N.B. ancient doesn't mean that it's not being updated or enhanced.
TCP/IP is ancient too.
EBCDIC is ancient.
ASCII is ancient.
None of these three are bad.
Big data, clustering and more are hidden by z/OS.
What do you mean by "Big data ... hidden by z/OS."?
I think that clustering being hidden by z/OS (likely with CF) is a
perfect example of why you can't just compile a Cobol program on Linux
that came from a mainframe.
VSAM is simple and efficient to use in Cobol but Linux programmers
must use databases for the same purpose.
I question the veracity of that "must". I absolutely agree that many
do. But I don't think it's a hard requirement.
Also, how is VSAM not a database of sorts?
N.B. "database" can mean a LOT of different things.
ASK YOURSELF: Other than programmer self esteem, why do business
programmers need languages more complicated than Cobol?
Why did you single out business programmers? Why didn't you just say
programmers in general?
I know that there are some languages considerably newer than Cobol which
focus on incorporating protections into the language / compiler so that
it's MUCH more difficult to make some mistakes that were common
languages like C. "memory safe" is usually how I hear them described.
I'm sure there were some assembly programmers of old asking similar
questions of the then newer Cobol.
The story falsely claims z/OS needs xWindows & bitmapping. z/OS
supports xWindows & bitmapping. The author doesn't understand that
xWindows is not used for general access of a multi-user environment
(servers) regardless of platform. MS Windows and Mac don't use
xWindows. For Linux servers, the only people using xWindows from these
machines are sysadmins. Android is the largest Linux distro but no
platform (even z/OS) does not build xWindows programs because there
are so many different phone sizes.
ASK YOURSELF: Name 1 company that uses xWindows except for Linux
desktops and Linux workstations.
Why did you exclude Linux desktops / workstations?
How about Oracle Solaris systems? They use X for GUI.
What about IBM's AIX? It uses X for GUI.
I can tell you from first hand experience that Oracle's Universal
Installer requires you to use X or an answer file that you don't know
the questions to answer until after you run the GUI installer at least
one time.
ASK YOURSELF: Name 1 company whose programmers use their IDE
(development environment e.g. VSCode) from common servers.
I've worked for and with multiple companies that run IDE's in a VDI
which is tantamount to running the VDI instance as a server (it's not
the local workstation) and the VDI itself is hosted on a server.
The story mentions IMS & CICS but forgets to mention the Unix & Linux
equivalents that stemmed from IMS & CICS concepts. Surely people have
heard of SAP, Peoplesoft, web servers and other such products.
Tim Berners-Lee and his Next computer might take exception to the end of
that statement.
Our worlds are colliding. z/OS should be smashing Linux but Linux
survives on people's desire to be computer experts instead of business
line experts.
I think that z/OS and Linux serve two completely different purposes.
I can't run z/OS on a sub-100 dollar computer in my house. I can do
that with Linux.
Google management thinks it's cheaper to spend $4,000 for each of
their 5,500,000 servers than $4,000,000 for each IBM z16 computer
needed. You get what you pay for.
I don't know how many mainframes you're talking about, but if we simply
say two cores per CPU and two CPUs per server, that's 22,000,000 cores.
With just core counts alone, that would need to be 110,000 z16s. I'll
wager that the server's that Google is using have considerably more than
four cores.
Google's M.O. is MASSIVELY PARALLEL. They have clusters of hundrds or
thousands of systems. I do quite literally mean a singular cluster with
999 (or more) systems in it. Ans they have MANY such clusters. I know
that they are counting the number of those clusters in the three digits.
ASK YOURSELF: Are people delusional when they call the mainframe a
dinosaur when it's more advanced than the most advanced workstations
and servers?
I question the veracity of the statement that the mainframe is more
advanced than the most advanced workstation or server?
Not the least of which is when a mainframe is technically a special sort
of server. So it can't be more advanced than a group that it is itself
part of.
What is the definition of mainframe?
I view it as a combination of facilities provided to applications that
run on the system.
As you demonstrate, it's not the underlying hardware. It's not the
software that runs on the system. It's not the communications protocols
used to talk to it.
Grant. . . .
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
