
Hello World on z/OS - pjmlp
https://medium.com/@bellmar/hello-world-on-z-os-a0ef31c1e87f
======
Softly
Missed my favourite part of learning the mainframe: where the enter key is.

Return and enter and two different keys, but, on most modern systems, they
perform a similar function. On z/OS Return moves down a line (similar to Tab,
but ignoring all entries on the current line) and Enter actually sends to data
off.

Once you get used to it, it's really no different to the Linux or Windows
command lines. It's certainly dated, but that's what you get from running a
system designed to be fully backwards compatible (with 24-bit, 31-bit and
64-bit addressing modes) that can continue to run software that's over 40
years old.

[For reference, the mainframe originally had 24-bit addressing. When IBM
wanted to add 32-bit addressing, they found that people had been using the
remaining byte to store other data, such as flags. So, to avoid breaking
customer applications, the 32nd bit is used to identify whether the address is
24-bits or 31-bits]

((And yes, for the record, I am an IBMer, working in a z/OS product that's
over 40 years old))

~~~
bonzini
The ISPF editor is actually more than decent. About 20 years ago my father was
writing COBOL (on both AS/400, now iSeries, and PC) using SPFPC, an MS-DOS
editor inspired by ISPF. The line command/primary command mechanism is really
no more quirky than vi's movement and insert modes, and it makes a lot of
sense for languages like COBOL.

~~~
tolle
SEU, the built in editor on the iSeries/IBM i, is however rather shitty. It
does actually do some linting, but no syntax highlighting and the 5250
interface never really got improved as much as 3270, so its 24x80 or 27x132.
Granted you're supposed to use an eclipse based IDE since SEU is no longer
supported, but to just look at stuff really quick. A fast editor is preferred.

But I agree, ISPF editor is rather good.

~~~
southern_cross
I think SEU is far better than you seem to giving it credit for. In fact, I
used it for decades and my only real complaints about it started when IBM
stopped actively maintaining it. Over the years I also tried using various
other "modern" editors, only to eventually cast them aside as being too
unstable, buggy, or just slow and clunky (like Eclipse). In fact, I can only
recall one particular instance where using such an editor (Eclipse in this
case) actually proved unquestionably advantageous over using SEU, but even
then I quickly got annoyed at some of the stupid (IMO) implementation details
of it.

------
userbinator
The reason why things are the way they are on mainframes, and how you should
think intuitively, becomes a lot clearer once you realise that they are a
long-evolved version of the very first mechanical punched-card processors:

[https://en.wikipedia.org/wiki/Unit_record_equipment](https://en.wikipedia.org/wiki/Unit_record_equipment)

In fact, I'm almost willing to bet that the foreignness of mainframes to the
average developer is due to mini/microcomputers having become dominant and
taken a very different evolutionary path; Linux and DOS/Windows have far more
in common with each other than mainframe OSes, despite their huge differences,
because they evolved from mini/microcomputers and UNIX.

~~~
wolfgke
> Linux and DOS/Windows have far more in common with each other than mainframe
> OSes, despite their huge differences, because they evolved from
> mini/microcomputers and UNIX.

Surely Linux and the Windows NT line (don't confuse the Windows 9x line, which
evolved indirectly from DOS with the Windows NT line) have much more in common
with each other than mainframe OSes, but Windows did not evolve from UNIX:

The Windows 9x line evolved indirectly from DOS (cf. [1]). DOS was inspired a
lot by CP/M.

The Windows NT line is a spiritual succesor to VMS (cf. [2]). The kernels of
both operating systems were designed by Dave Cutler, who did not like UNIX
(cf. [3]). Indeed, Windows NT has I/O Completion Port (IOCP, [4]) as an - in
my opinion - better I/O system than the UNIX process input/output model.

[1]
[https://blogs.msdn.microsoft.com/oldnewthing/20071224-00/?p=...](https://blogs.msdn.microsoft.com/oldnewthing/20071224-00/?p=24063)

[2] [https://www.itprotoday.com/management-mobility/windows-nt-
an...](https://www.itprotoday.com/management-mobility/windows-nt-and-vms-rest-
story)

[3]
[https://en.wikipedia.org/w/index.php?title=Dave_Cutler&oldid...](https://en.wikipedia.org/w/index.php?title=Dave_Cutler&oldid=838448172#Attitude_towards_Unix)

[4]
[https://en.wikipedia.org/w/index.php?title=Input/output_comp...](https://en.wikipedia.org/w/index.php?title=Input/output_completion_port&oldid=774867977)

~~~
mschaef
> The Windows 9x line evolved indirectly from DOS

Not sure what you believe to be 'indirect' about that relationship. That
Windows codebase started out running on DOS and ultimately wound up so closely
coupled that they shipped together in the same box as the same product.

> Windows did not evolve from UNIX:

Windows, through its DOS lineage, does indeed have some roots in the Unix
tradition. (This should be unsurprising, since Microsoft was one of the more
successful Unix licensees in the early 80's.)

[https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/wh...](https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/why-
is-the-dos-path-character/)

To put Cutler's dislike of Unix into perspective, DOS (and Windows) had close
to a decade of development prior to his involvement. (DOS shipped in 81,
Cutler got involved in ~88, his first product shipped in ~93, and the old DOS-
based Windows wasn't fully deprecated until 2001-1.)

~~~
TheOtherHobbes
DOS commands and hierarchical file paths were based on DEC’s TOPS-10, via
CP/M, both of which Cutler would have been familiar with.

DOS was at best a mongrel mash-up. It no more evolved from Unix than AmigaOS
did.

~~~
mschaef
> DOS commands and hierarchical file paths were based on DEC’s TOPS-10, via
> CP/M, both of which Cutler would have been familiar with.

I'm sure he was, but DOS got pathnames in March of 83 and Cutler didn't join
until 6 years later.

------
nine_k
This is a nice reminder about how one feels when one meets a piece of
technology for which one's intuition can't offer anything useful, many "common
sense" assumptions end up incorrect, and you don't even know the right words
to feed to a web search engine.

I'll try to memorize this feeling, and remember it every time I try to explain
something technical to people outside that field. Maybe it will help me
explain better.

~~~
rbanffy
I remember when someone referred to Unix as the User Hostile Operating System.

They obviously never used MVS (z/OS's ancestor), OS/400 (now I/OS or something
like that) or Burroughs' MCP (when an OS lends its name to a movie super
villain, you have to respect it).

~~~
rbanffy
BTW, there's an interesting backstory on how MCP ended up being Tron's
villain: Bonnie MacBird, who co-authored the story with Steven Lisberger, is
Alan Kay's wife and Alan Kay was working at Unisys (or Burroughs) at the time
she wrote it, as well as being an advisor to Lisberger and his partner and
producer Donald Kushner.

------
AnIdiotOnTheNet
> IBM uses special and completely unintuitive names for basic concepts….
> because OF COURSE THEY DO.

As I recall, it's called "Bluespeak", and that sort of thing is pretty common
actually. I was educated in networking at a Cisco netacad, so I use Cisco
terminology that is apparently not universal.

Programming languages do this too for some reason: Sum type, tagged union,
discriminated union, variant...

~~~
JdeBP
The point that M. Bellotti came close to, but missed, is that "of course they
do" is because _every field has jargon_. The error here is in thinking that
one set of jargon is intuitive and normal whilst another set of jargon is
"special and completely unintuitive".

The simple truth is that there are many people to whom jargon such as "WIMP",
"ISOs", "flat UI", "IIFE", "DOM", "pull request", and "UX" is _equally as
opaque and foreign_ as "DASD", "APAR", "SRC", "PMR", and "PTF"
([http://jdebp.info./FGA/fix-terminology.html](http://jdebp.info./FGA/fix-
terminology.html)). _All_ are in fact niche terminology.

~~~
southern_cross
IIRC, as the story goes the folks who designed IBM's SNA (Systems Network
Architecture) _went out of their way_ in order to come up with a whole new set
of technical jargon for that. I don't remember why, though.

BTW, I've been around long enough to have had conversations like the
following:

Them: "I want to run Lotus 1-2-3." (This was the near-universal spreadsheet
standard before Microsoft Excel came along.)

Me: "OK, then first we're going to have to get you a PC."

Them: "What's a PC?"

Then I would have to explain that this was a "Personal Computer". And not just
any personal computer, either, but rather an "IBM" PC, in order to distinguish
it from an Apple or Commodore or TRS-80 or TI-99/4A or Atari or whatever. And
they might respond that they didn't even know that IBM _made_ personal
computers. (Which they don't any longer, of course.)

------
tony-allan
This article brings back some happy memories! Well done Marianne.

z/OS, TSO, JCL and the rest are different to what most people are used to but
this is where modern IT started, where virtualisation, high availability and
serious backward compatibility were invented.

Peel away the layers of technology is a large company and you will often find
a mainframe managing the core data of the business.

------
rbanffy
Another shameless plug: I think the IBM 3270 (the ones with beam-spring
keyboards) was the greatest terminal ever and I missed its screen font so much
I had to recreate it.

It's now my most popular GitHub project and is included in the Debian repos:

[https://github.com/rbanffy/3270font](https://github.com/rbanffy/3270font)

------
rbanffy
Just a shameless plug: there is very little information in the form of Stack
Overflow-like things and getting started with mainframes is, as this article
shows, pretty hard. I made this SE proposal that's in commitment stage (where
people commit to support the community). If you know about mainframes and are
willing to be part of it, you should commit too.

[https://area51.stackexchange.com/proposals/118484/mainframes...](https://area51.stackexchange.com/proposals/118484/mainframes?referrer=iAGSGOUsQhhu5K9oA-93Cw2)

~~~
walrus01
The hard part for mainframes is that unlike Linux and the BSDs, you can't
acquire a bunch of 4 year old Core i5 systems for $80 each (or sometimes free)
and install a bunch of different OS varieties on them to test stuff in your
home office or the bedroom of a bored teenager (example: centos hosting KVM
VMs, debian + xen, freebsd on bare metal, etc).

~~~
rbanffy
With zSeries it's a bit harder, but for the iSeries (I still count AS/400 as
alien enough to be "mainframes"), you can get machines for reasonable prices.
The prices drop precipitously when that hardware is dropped from the last OS
release.

For Z machines, you can use Hercules as an acceptable approximation. A couple
questions I posted as example are about Hercules.

~~~
bri3d
There's no legal way for a hobbyist to run anything better than MVS 3.8j on
Hercules and even if you're not morally opposed to piracy, z/OS is virtually
impossible to find and configure.

~~~
rbanffy
There is a Hercules-like product made by IBM that can legally run z/OS, the Z
Development and Test Environment. It's expensive, but legal.

Also, a surprising number of concepts of MVS 3.8j are present in z/OS, so what
you learn there is not wasted. As the article points out, a lot still spins
around 80-column punched cards. If you go for the less bare distributions of
MVS, you'll see lots of software that tries to replicate the functionality of
newer releases.

As an example, I pinged Cincom Systems to see if they had an old version of
Mantis that could run on MVS 3.8 that I could obtain for free (Mantis was the
language I used on mainframes). To my surprise, that version is still a
commercial product and is fully supported. Things dom change very slowly in
mainframe land.

------
Svip
In the 'Allocate New Data Set' screenshot, it says - for the expiration date
field - that the formats are 'YY/MM/DD, YYYY/MM/DD, YY.DDD, YYYY.DDD in Julian
form, DDDD for retention periods in days or blank'. (I added some commas,
which I assume are supposed to be there, but are just line breaks in the
screenshot.)

Does that mean z/OS supports the Julian calendar?

~~~
SuperPaintMan
It does, In a similar vein Cobol has the ACCEPT DATE (YYMMDD) and ACCEPT DAY
(YYDDD) constructs for retrieving the date. There's an optional argument for
supporting four digit year codes however. Julian dates pop up in some wonky
places across the system.

~~~
sdkmvx
Are you sure?

Today is July 31, 2018 in the United States, which adopted the Gregorian
calender per the act of British parliament entitled "An Act for Regulating the
Commencement of the Year; and for Correcting the Calendar now in Use" (24 Geo.
2 c. 23) by skipping September 3-13, 1752 (obviously this was prior to the
American revolution).

In the Julian calendar, there are leap days every four years. In the Gregorian
calendar, there are leap years every four years except every 100 years except
every 400 years. That is, 2000 and 2004 are leap years, but 1900 is not a leap
year.

Since 100, 200, 300, 500, 600, 700, 900, 1000, 1100, 1300, 1400, 1500, 1700,
1800, and 1900 were leap years in the Julian calendar but not the Gregorian
calendar, one must subtract 15 days to get to the Gregorian date to get the
Julian date.

Today is July 18, 2018 in the Julian calendar.

The Soviet Union adopted the Gregorian calendar in 1918 by skipping February
1-13. They were the last. This is why the famous February revolution took
place in March and why the October revolution took place in November. (Though
I noticed Reuters announced it had been 100 years last year on the wrong day.)

Mainframes are weird, but I really doubt they don't use the Gregorian calendar
whatever the text on the screen says.

------
mattzito
The mainframe infrastructure is both the core feature and showstopper bug of
the platform. On the plus side, it has empowered countless core business
applications to scale years, even decades, beyond their original development
lifecycle. On the negative side, it has created a stagnant cult of mainframe
“priests” who oversee a platform that most businesses would rather get rid of,
if they could only figure out how.

My startup was acquired by BMC software, one of the largest third party
providers of mainframe software, and I also worked for EMC for a time early in
my career, so I spent a lot of time hanging around the mainframe space. Two
quick anecdotes:

\- working on a giant data center move for a big bank, there was a break room
filled on a Saturday with operations people from the “open systems” (non-
mainframe) and mainframe teams. I was struck by the contrast: the Unix/windows
operations folks were tattooed, pierced, jeans and t-shirts, late 20s. The
mainframe folks were short hair, polos and jeans, mid-50s. The two groups self
segregated into clusters on opposite ends of the room, not speaking to each
other.

\- at a BMC leadership offsite, I found myself st the dinner table with a
couple of mainframe engineering and product directors. After a few drinks, we
got on the subject of why more tech companies weren’t using mainframes.
“They’re so reliable! Why wouldn’t you just go out and rent one from IBM, and
then you don’t have to worry about uptime or stability?”. I explained that the
fashion had become to build the reliability into the application and assume
that the hardware was not reliable. This confused them. “That sounds like a
huge pain in the ass, why would you bother dealing with that?” So I explained
that the cost per compute cycle was so much cheaper that it made it worth it,
plus open source, etc etc

One of them kept pressing: “but Facebook could just take all the engineers
they’re devoting to building reliable infrastructure and shift those people to
writing customer facing code!”

The other director stopped him and said, “don’t you see? They’ve already done
it. There’s no reason for them to go back now. People have figured out that
they don’t need mainframes to get mainframe reliability”. The other director
just kept shaking his head and we moved to other subjects.

This conversation happened in 2014.

~~~
dralley
One of my older coworkers told me that IBM used to have a travelling mainframe
demo in the back of a truck. As part of this demo, they would start a big
computation, and then reach into the mainframe and start pulling out RAM and
entire CPUs straight from the sockets, while the thing kept right on
computing.

~~~
floatboth
ZFS developers like to do this with hard drives :) But how did IBM do that
with _RAM_? Do mainframes have… redundant RAM? Like literally sticks mirroring
others?

~~~
krylon
I have seen one PC-based server that had redundant RAM. I never tried pulling
out RAM modules, but I guess there is not much point in having a RAID1-like
arrangement for RAM if the machine cannot handle random RAM modules dying
without crashing the OS. And it wasn't even a super high-end system.

~~~
forapurpose
> I have seen one PC-based server that had redundant RAM

Yes, I've seen this too, and on lowish-end servers.

~~~
snuxoll
Memory mirroring is a pretty common feature on basically every x86 server I've
used (going back to the Core 2-based Xeon's, no experience with older
platforms), though I've never tried just yanking DIMM's out and wouldn't
recommend trying it.

------
bonaldi
I find this sort of complexity absolutely fascinating: I imagine it is similar
intellectually to learning of a new order or family in biology: you understand
the mechanisms and underpinning goals, but the mechanisms and results are
wholly foreign to you.

Had a similar experience with the Bloomberg terminal, which is a similar
evolutionary offshoot. (Think "what if the GUI had never happened, but the
3270 form-style CLI had gained a mouse and graphical representations?")

~~~
aasasd
I mean, DOS had plenty of pseudo-graphical interfaces in the 90s: Norton
Commander, Borland IDEs and such, down to the use of the mouse―so it's rather
weird seeing people treating that paradigm as completely alien.

~~~
bonaldi
I am explaining it quite poorly. It's different from Commander etc because
they were (to my mind) essentially WIMP interfaces. You _could_ use them with
a keyboard, but it wasn't really the paradigm.

BBG's terminal is fundamentally still keyboard-driven: you _can_ use the
mouse, but in the same way you can use a mouse with emacs: you're going to be
driven back to the keyboard sooner or later, so you might as well stay there.

There are some introductions on YouTube, but they're all horrible. I'll see if
I can find a good one.

------
nailer
I demember doing virtualisation/containerisation for Linux on various
platforms (including s/390 and z/VM but also VMware and Xen) at IBM. No matter
what the platform was, the PMs would refer to the VM/container as an 'LPAR'
(logical partition). Fun times.

~~~
voidmain0001
Me too! I setup a couple of Linux LPAR on AS/400 - iSeries running OS/400\.
The distro was RedHat for PowerPC. One LPAR was for a Linux/Apache/PHP stack
that used the DB2/400 database on the iSeries, and the other was to host an
Oracle 8i instance. DB2/400 was a great RDBMS but there was an application
requirement for an Oracle database, so the director of IT at the time said
that if a DB is required then it must go on the iSeries since it hosts the
primary DB the company used. I didn't care for his rationale, I just thought
it was fun to be working with LPAR on the iSeries.

~~~
rbanffy
> it must go on the iSeries since it hosts the primary DB the company used.

Putting all the eggs in the same basket to justify the basket. That's
classical pointy-haired thinking.

~~~
southern_cross
Unlike so many "modern" systems, these systems are designed to let you to put
all of your eggs in one basket if you want to, and never even break a sweat!
Their built-in level of reliability (they're almost bullet-proof) generally
allows this, too. You may very well have legitimate reasons for not doing it,
though, including regulatory requirements and such.

~~~
rbanffy
The AS/400 descendants are not as bullet proof as the zSeries. They are POWER
servers similar to high-end Intel boxes, mostly the same hardware as their AIX
machines - RAID, ECC memory, multiple PSUs but, IIRC, won't easily recover
from failed CPUs or anything like that.

~~~
southern_cross
I'm not going to disagree with this, at least not concerning the typical POWER
i box. But for the higher-end boxes at least (the ones that can handle 16
LPARS or more - or at least they could back in the day), I expect that there's
considerable redundancy built-in. I doubt it's to the level of a higher-end
zSeries, though.

It's been a long time now since I've managed hardware so I don't really know
what the current situation is. But I happen to have ready access to a hardware
document from around 2008 (the last time that I worked with such large
system), and it lists a whole slew of RAS features that were copied from the
mainframe. I expect that if I tracked down the corresponding document for a
current high-end system that it would list even more.

That said, it was generally my experience that the whole platform family (low
end to high end, new systems and old) was just rock-solid reliable - not at
all like "The server crashed again - time to reboot it!" situation I usually
found on the Wintel side of things. Plus stuff like malware was practically
unheard of. And I've worked on systems that at any given moment might have
thousands of users on them, and maybe tens of thousands to hundreds of
thousands of jobs. From an operational perspective this might not have
necessarily been the best idea, for a variety of reasons, but at least the
system could handle it easily. And much like mainframes, unexpected outages
were basically unheard of - if they ever happened they were extraordinary,
jaw-dropping events. I'm not claiming the platform was/is perfect, though.

------
Keyframe
Check this out:
[https://www.youtube.com/watch?v=Uv7ThVwb7m8](https://www.youtube.com/watch?v=Uv7ThVwb7m8)
BASICS of running COBOL / JCL on z/OS. Almost of a conundrum like React/Redux.
Almost.

~~~
SuperPaintMan
This is literally the video I ripped my first JCL from in my post above. I
believe the relevant section is around 4:30 :)

------
JdeBP
Whilst the ways that one does command-line stuff and full-screen editing with
block-oriented (rather than character-oritented) terminals are an important
difference to learn, there are, of course, things here that are _not_
different.

* There's still "object" code, and a "link (edit)" step.

* The function key mappings such as F3 for Exit are Common User Access standards, and were to be found in some Microsoft and IBM softwares for PC operating systems in the 1980s; most prominently perhaps in the various "E" editors and clones thereof available on PC-DOS and OS/2.

* The underlines for the menu item hotkeys are also Common User Access things, as is F10 for bringing focus to the menu.

M. Bellotti would gain by learning about the "TE" line command. Xe would also
gain by not abusing the word "legacy", especially since the so-called "legacy
paradigm" of IBM's "panels" on block-oriented terminals is pretty much the
same paradigm as forms on a WWW browser. (-:

* [http://jdebp.info./FGA/legacy-is-not-a-pejorative.html](http://jdebp.info./FGA/legacy-is-not-a-pejorative.html)

And the doco, IBM's and others', is not really wildly different, in both range
and content, to other platforms'.

* Gary DeWard Brown (2002). _zOS JCL_. John Wiley & Sons. ISBN 9780471426738.

* [https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pag...](https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3SC193621/$file/f54em00_v2r3.pdf)

* Mike Ebbers, John Kettner, Wayne O'Brien, and Bill Ogden (2012). _Introduction to the New Mainframe: z /OS Basics_. IBM Redbooks. ISBN 9780738435343.

------
trasz
FWIW, this book ("Fake Your Way Through Minis and Mainframes" by Bob DuCharme)
provides a good short user-level introduction to z/OS (and VM, and VMS,
and...):

[http://www.snee.com/bob/opsys/fullbook.pdf](http://www.snee.com/bob/opsys/fullbook.pdf)

------
landbeyond
Hilarious! (disclosure: I am a mainframe systems op/dev)

The best part is where they didn't know about the INSERT key. I can understand
z and ISPF being a hassle if you're used to modern computing but the mainframe
logic is actually logical, and probably predates whatever modern stuff you're
on to... like "files". :)

~~~
JdeBP
You mean the _letter-a-going-up_ key.

* [https://superuser.com/questions/290814/](https://superuser.com/questions/290814/)

~~~
bunderbunder
Or perhaps the, "no, don't do that, that's confusing, that symbol is an
honest-to-goodness letter" key.

Useful for typing words like pâte, infâme, or grâce. Except not at all.

------
southern_cross
As someone who has been in IT for decades now and who over the years has moved
between IBM, Wang, Sperry, DEC, Unix, DOS, Windows, Teradata, etc. platforms
with aplomb, this article just has "Noob!" written all over it. :)

------
etaioinshrdlu
IBM is a special company that seems to not want anyone to use its products.
They sure go out of there way to make things hard to access. But they keep
them around forever. Happy to sell them to the right customer. So many
overlapping products that don't make sense in aggregate. The company seems to
be marketing-driven the last 10+ years, selling all manner of snake oil.

Possibly the worst big co in these factors?

~~~
api
They're not interested in anyone but people willing to write million dollar
plus checks using their products. Those same giant customers have large legacy
investments and plenty of money to hire teams of people to deal with things
that are hard to use. Those kinds of customers care much more about things
working for 30+ years without downtime than they care about UX.

There's a whole world of solid, reliable, but unbelievably boring
"institutional computing" out there that hackers usually don't touch because
it's... well... boring. Java is the closest most hackers ever get, and that
has more in common with Python or Ruby than COBOL or z/OS. Java is kind of a
modernized mini/micro computer business language.

~~~
wolfgke
> There's a whole world of solid, reliable, but unbelievably boring
> "institutional computing" out there that hackers usually don't touch because
> it's... well... boring.

I can imagine if the salaries would be sufficiently (i.e. very) high and the
complete culture would not be openly hostile towards the values of the hacker
culture, I can easily imagine that hackers would be willing to touch it.

~~~
tony-allan
(1) These systems were built from the ground up with security in mind.

(2) Mainframes are usually buried deep within an organisation behind many
firewalls.

I would love to see a z/OS system at a Defcon conference. After all Windows
and MacOS seem too easy these days.

Having said that, I found this... "Follow me on a journey where we p0wn one of
the most secure platforms on earth." Quite a cool presentation
([https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20pre...](https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20presentations/DEFCON-25-Ayoul3-Dealing-
the-Perfect-Hand-Shuffling-memory-blocks-on-zOS.pdf)) with a good mainframe
intro.

IBM zEC13 technical specs: • 10 TB of RAM • 141 processors,5 GHz • Dedicated
processors for JAVA, XML and UNIX • Cryptographic chips...

