During my training, I worked on a BIND4-to-BIND9 migration in an IBM mainframe environment. One week I got bored and started "benchmarking" the server, wrote this little perl script that swamped the server with DNS queries. Then I realized that my feeble little antique of a desktop (Pentium II @400MHz, running NT 4.0, in 2004!) was not even capable to put some serious load on that behemoth, and had not IBM just recently ported Perl 5.8 to z/OS?
So I scp the script over to the mainframe, ssh into it, run it again... and grow disappointed that my puny little perl script is still the bottleneck. How much can this beast take, I wonder. Maybe, if I forked off a couple of children?
In retrospect, I should have let it go at this point. My benchmark was already querying the nameserver at a far higher rate than it would ever encounter in production. I should have written in my report that the performance impact of some configuration changes was negligible if not zero.
But I really wanted to see how many queries this beast could handle. So I kept increasing the number of worker processes hammering BIND with the same queries over and over, until ... my ssh connection dropped.
I pinged the mainframe, but I got no response. Ooops.
I was trying to look really busy as the monitoring guy who always looked as if he had just woken up walked down the corridor into our open plan office, grinning, and asked if anyone had something to tell him. Nobody replied. I do not think I have ever been that quiet in my entire life.
"Okay", he said, "the TCP/IP stack on that particular system just crashed, just in case you are wondering.". Oops
"Yeah, but SNA still works", the sysprog replied, "And the LPAR is scheduled for an IPL on Saturday, anyway. It'll do."
Obviously, it was a testing LPAR, so nobody got hurt; they would not let a trainee anywhere near a production system. But let the record show that I did manage to disable VTAM (at least the TCP/IP side of it) with a simple perl script from an unprivileged user account. By accident, but still. Also, I lost about a kilogram in sweat that day.
LPAR is the ancient, and still somewhat superior[1] version of what we call a VM or docker container today. "Logical partition".
It's funny how much of what seems new isn't, really. Mainframes had VM's figured out decades ago, in a pretty elegant fashion.
IPL is basically "initial boot", SNA was a network transport. VTAM is to SNA the same as Ethernet is to IP (roughly, I'm skipping over LU6.2/APPC/etc).
You didn't ask about CICS, but it's basically cron+middleware but better.
In fact, if you look at, say AWS, and the set of standardized services, it isn't much different from what a mainframe offered so long ago. Standard, if somewhat limited, interfaces for scheduling, load balancing, VMs, databases, "nosql", events, logging/alerting, etc. Even nods to "microservices" and other things that feel new, but aren't really. Self service is a bit new, but the rest is well established.
[1] better I/O isolation, fewer "noisy neighbor" issues for example
I haven't worked with mainframes since, but I found the fact they have their own words for things fascinating. Parallel evolution, so to speak. Like, what mainstream operating systems call a kernel is called a "nucleus" on z/OS, which IMHO is a much cooler name.
Comments
During my training, I worked on a BIND4-to-BIND9 migration in an IBM mainframe environment. One week I got bored and started "benchmarking" the server, wrote this little perl script that swamped the server with DNS queries. Then I realized that my feeble little antique of a desktop (Pentium II @400MHz, running NT 4.0, in 2004!) was not even capable to put some serious load on that behemoth, and had not IBM just recently ported Perl 5.8 to z/OS?
So I scp the script over to the mainframe, ssh into it, run it again... and grow disappointed that my puny little perl script is still the bottleneck. How much can this beast take, I wonder. Maybe, if I forked off a couple of children?
In retrospect, I should have let it go at this point. My benchmark was already querying the nameserver at a far higher rate than it would ever encounter in production. I should have written in my report that the performance impact of some configuration changes was negligible if not zero.
But I really wanted to see how many queries this beast could handle. So I kept increasing the number of worker processes hammering BIND with the same queries over and over, until ... my ssh connection dropped. I pinged the mainframe, but I got no response. Ooops.
I was trying to look really busy as the monitoring guy who always looked as if he had just woken up walked down the corridor into our open plan office, grinning, and asked if anyone had something to tell him. Nobody replied. I do not think I have ever been that quiet in my entire life.
"Okay", he said, "the TCP/IP stack on that particular system just crashed, just in case you are wondering.". Oops
"Yeah, but SNA still works", the sysprog replied, "And the LPAR is scheduled for an IPL on Saturday, anyway. It'll do."
Obviously, it was a testing LPAR, so nobody got hurt; they would not let a trainee anywhere near a production system. But let the record show that I did manage to disable VTAM (at least the TCP/IP side of it) with a simple perl script from an unprivileged user account. By accident, but still. Also, I lost about a kilogram in sweat that day.
What do these acronyms mean?
SNA LPAR VTAM
LPAR is the ancient, and still somewhat superior[1] version of what we call a VM or docker container today. "Logical partition".
It's funny how much of what seems new isn't, really. Mainframes had VM's figured out decades ago, in a pretty elegant fashion.
IPL is basically "initial boot", SNA was a network transport. VTAM is to SNA the same as Ethernet is to IP (roughly, I'm skipping over LU6.2/APPC/etc).
You didn't ask about CICS, but it's basically cron+middleware but better.
In fact, if you look at, say AWS, and the set of standardized services, it isn't much different from what a mainframe offered so long ago. Standard, if somewhat limited, interfaces for scheduling, load balancing, VMs, databases, "nosql", events, logging/alerting, etc. Even nods to "microservices" and other things that feel new, but aren't really. Self service is a bit new, but the rest is well established.
[1] better I/O isolation, fewer "noisy neighbor" issues for example
Some IBM mainframe acronyms
SNA -> Systems Network Architecture
LPAR -> Logical partitions
IPL -> Initial program load
VTAM -> Virtual Telecommunications Access Method
I might be wrong of course
Nah, that is how I remember it. ;-)
I haven't worked with mainframes since, but I found the fact they have their own words for things fascinating. Parallel evolution, so to speak. Like, what mainstream operating systems call a kernel is called a "nucleus" on z/OS, which IMHO is a much cooler name.
LGTM