Here’s a comment from Jeff Savit: "Supposedly about 10,000 machines are in use and each one needs a staff of 1,000 people" The former sounds about right, the latter is orders of magnitude too high.
There were indeed implementations of BASIC for VM/CMS, such as VS BASIC, which might still run on current CMS on z/VM. It was never open source - VS BASIC was a licensed product that didn't get much uptake. VS BASIC was very straightforward to use on CMS - the command name followed by command line arguments including the source code file.
Here's the Open Source OS/360 BASIC I was talking about:
SOUTH HAMMOND INSTITUTE OF TECHNOLOGY BASIC/360 FALL 1974
It was written by a student in the 1960s, and later updated in the 1970s. It wouldn't have been called Open Source in the early 70s, but by today's standards it probably would.
When I taught Business student Freshmen the introduction to computers (circa 1970) at the University of Rhode Island we had BASIC on 360/50. The mainframe worked well and so did BASIC time sharing, but the IBM terminals, 2741s, were always in need of repair. Although slow and noisy, held up much better.
I don't really remember. While I was there. I am sure that they upgraded to OS/MVT, but what they had in 1970 is a mystery. Along with the OS upgrade they changed out the machine to 370/155.
I suspect the BASIC360 manual needs updating. It is currently just a marked up version of the 1964 Dartmouth manual but the examples runs show that he has added string variables and formatting print functionality. It's fun to think someone else implemented BASIC in PL/1. Dartmouth's 7th and 8th editions of BASIC were implemented in PL/1 subset G. That PL/1 compiler was written in the 1973-1978 timeframe so Basic7 and Basic8 had to wait. :-)
William A. Wulf co-authored a paper in the Oct 1968 CACM which discussed an implementation made of BASIC at the University of Virginia on a B5500. Perhaps that version is in the public domain. https://dl.acm.org/doi/10.1145/364096.364115
(Professor Wulf died early last year, but his wife, Anita Jones, still seems to be alive and may know where to find this BASIC implementation.) https://en.wikipedia.org/wiki/William_Wulf
The paper is very interesting and brings up some interesting problems if you are writing an incremental compiler/programming environment. It appears that the compiler ran at 10-20 statements a second but since it was doing the compilation after the user enters each line, it is pretty well hidden. (Unless one loads a large program I assume)
That's interesting, I never knew it was an incremental compiler. When you type RUN it did say Compiling before it would start running. It's possible that it was just a final housekeeping pass before starting execution. It did run very fast. DEC also did what they called a checkpass before running a BASIC-PLUS program that was incrementally compiled.
z/VM is not an operating system. It's a virtual machine hypervisor. It creates virtual machine System Z architecture environments in which operating systems run. z/OS can run "under" z/VM. DOS/VSE can run "under" z/VM. z/LINUX can run "under" z/VM (and is a very popular way to virtualize large numbers of servers). z/TPF can run "under" z/VM. There's even a z/VM only operating system, CMS (Conversational Monitor System) that runs under z/VM. CMS is the primary z/VM management tool, containing various support utilities including a file editor (XEDIT).
I'm familiar with CMS. I worked for IBM in the 80s and I used PROFS for email, IBM Forums for sharing all sorts of interesting things from around the corporation, Labor account management, and Travel reporting all running on CMS. I was working for IBM Federal Systems (IBM FSD) at the time, and we also had applications on CMS that were used for government contracts. We called it VM/CMS, at time time, and treated the combination as a very affective general purpose Time Sharing System. We even had compilers that worked interactively. When I joined IBM I had never used a mainframe, so just for the heck of it, I wrote a Fortran program and compiled and executed it under CMS. I also used XEDIT and REXX.
I should add, in IBM FSD we tended to call VM/CMS just VM. Technically that was wrong, but in local slang we'd just say VM. That slang creeped into my writing.
1000 people per frame is a load of bull. I have first hand experience. My last "real job" before retirement was with one of the largest financial services firms in the world. I was on the team that supported the online systems (trading, brokerage, mutual funds, customer statements, etc.) The company had two geographically separated mainframe data centers (North Carolina and Nebraska), each location running 6-7 physical frames running a total of 20+ system images (logical partitions each one running a copy of the z/OS operating system) spread across 7 parallel sysplexes (look it up). Every day, at market open, we processed more transactions per second in the first 15 minutes than the number of searches Google handles in a few hours. Our support staff consisting of system programmers (which I was), operators, network engineers, and production control numbered less than 100 people. The idea that mainframes are "more expensive" is also bunk. The total cost of operating that environment, including hardware, software licensing, and salaries, was less than 25% of the overall annual I.T. budget. The perception (and that's all it is, a perception) that mainframe systems are expensive comes from the fact that individual expenditures/purchases in the mainframe space tend to be large - large enough to require senior executive approval, so they get noticed. Incremental costs for individual servers and individual staff hires tend to be small, so a mid-level manager in a large corporation can buy hundreds of them and hire dozens of staff over a few years' time, and those purchases will escape the attention of senior execs. However, the total cost of handling the same business workload that even a medium sized mainframe is capable of, capacity wise, on small servers ends up being more expensive in the long run, not to mention more complex due to the number of server systems required. You can't plow a field by harnessing up 10,000 chickens.
This is a comment from Brian S Williams on the Vintage Mainframe Enthusiasts FaceBook Group.
Sir: Regarding your statement of “Each mainframe needs 1,000 people to support it”. Are you kidding? Were you just exaggerating? If not, I’d like to politely request you cite your reference when you throw out a silly statistic like this one!
For the last five yrs, I’ve been working for a Unisys customer. We currently have ~5 (Burroughs MCP) mainframe systems (two production systems, one development system, one for quality assurance, and another for production support); all told, with mainframe application software developers (15), data center mainframe tech support (10), mainframe software quality assurance testers (10), mainframe computer operators (15), all told, probably ~50 people at the max.
Prior to my current position, I previously worked for Unisys Corporation for ~30 yrs from 1980 to 2009; the last twenty of those yrs were in Eagan, MN which was Unisys’s corporate datacenter, AND premier outsourcing datacenter. At its peak before I left, we had ~30 mainframes of Burroughs MCP vintage, and probably a similar nbr of Sperry OS2200 mainframes, with a total of about 100-150 datacenter support personnel.
I don’t have a good feel of how many people were in the I.T. area (application developers, testers, etc.) - but it wasn’t anywhere near 1,000 people per mainframe. I’d guess Unisys had, at most 500 application software developers/testers/analysts across both (Burroughs & Sperry) hardware platforms. Those 500 I.T. people and 150 datacenter support people “supported” 50-60 mainframes, twenty yrs ago.
Sir: One reason why I initially wrote is due to the phrase…”each mainframe takes x people to support it”. I typically would not add in application developers, QA testers - i.e., people in I.T.; those people don’t “support” mainframes; they write software applications for it but don’t “support” it. So, when I indicated the 500 I.T. people above, they should really be eliminated from the equation - and so, we’re left to ~150 datacenter support people supporting 50-60 mainframes.
I’m hoping this helps you understand that no mainframe takes 1,000 people to support it - not even close. I sincerely apologize if the “1,000” was a typo; even if it were just one hundred people to support a single mainframe, that still would mean, 5,000 people to support the ~50-60 machines we had at Unisys ~twenty yrs ago, and I can confirm we never, ever had that many in the combined datacenter support departments and I.T. application development departments. Ever.
Hey everyone, don't hesitate in posting comments here, particularly if I get something wildly wrong, like the number of people needed to work on a mainframe. At least I know there are people out there 😳
Gary, I think this is the situation with the Unisys environment today and it is worth pointing out the dichotomy. If I am wrong, I hope you or someone can clarify it.
It appears to me that they actually support two complete environments. Both run under emulation of the old hardware instruction set architectures, but the machines running the emulators seem to be a modern cluster of Intel CPUs, as you referred to,
Also, Microsoft says: "The Unisys mainframe systems trace their heritage to the first commercially available mainframes. The Unisys ClearPath Forward (CPF) Dorado (legacy Sperry 1100/2200) and Libra (legacy Burroughs A Series/Master Control Program) systems are full-featured mainframe operating environments. They can scale vertically to handle mission-critical workloads. These systems can be emulated, converted, or modernized into Azure. Azure offers similar or even improved performance characteristics and service-level agreement (SLA) metrics."
Yes, they do have two complete environments. One is legacy Burroughs, and the other is legacy Univac. When I was working at the General Services Administration (GSA) they were using the Burroughs legacy equipment, so my link is wrong. I forgot Clearpath is the Univac side. I’m sure they have a similar bundle for the Burroughs side. At the University of Maryland, in 1980, they had a Univac 1100 series model. I don’t remember the exact number. The Burroughs machines I worked on at Delaware were much better machines. The time-sharing system for the Univac machines was very odd and counterintuitive.
Here’s a comment from Jeff Savit: "Supposedly about 10,000 machines are in use and each one needs a staff of 1,000 people" The former sounds about right, the latter is orders of magnitude too high.
There were indeed implementations of BASIC for VM/CMS, such as VS BASIC, which might still run on current CMS on z/VM. It was never open source - VS BASIC was a licensed product that didn't get much uptake. VS BASIC was very straightforward to use on CMS - the command name followed by command line arguments including the source code file.
Here's the Open Source OS/360 BASIC I was talking about:
SOUTH HAMMOND INSTITUTE OF TECHNOLOGY BASIC/360 FALL 1974
It was written by a student in the 1960s, and later updated in the 1970s. It wouldn't have been called Open Source in the early 70s, but by today's standards it probably would.
When I taught Business student Freshmen the introduction to computers (circa 1970) at the University of Rhode Island we had BASIC on 360/50. The mainframe worked well and so did BASIC time sharing, but the IBM terminals, 2741s, were always in need of repair. Although slow and noisy, held up much better.
What OS did you use for time sharing?
I don't really remember. While I was there. I am sure that they upgraded to OS/MVT, but what they had in 1970 is a mystery. Along with the OS upgrade they changed out the machine to 370/155.
I suspect the BASIC360 manual needs updating. It is currently just a marked up version of the 1964 Dartmouth manual but the examples runs show that he has added string variables and formatting print functionality. It's fun to think someone else implemented BASIC in PL/1. Dartmouth's 7th and 8th editions of BASIC were implemented in PL/1 subset G. That PL/1 compiler was written in the 1973-1978 timeframe so Basic7 and Basic8 had to wait. :-)
re: BASIC on B5500
William A. Wulf co-authored a paper in the Oct 1968 CACM which discussed an implementation made of BASIC at the University of Virginia on a B5500. Perhaps that version is in the public domain. https://dl.acm.org/doi/10.1145/364096.364115
(Professor Wulf died early last year, but his wife, Anita Jones, still seems to be alive and may know where to find this BASIC implementation.) https://en.wikipedia.org/wiki/William_Wulf
The paper is very interesting and brings up some interesting problems if you are writing an incremental compiler/programming environment. It appears that the compiler ran at 10-20 statements a second but since it was doing the compilation after the user enters each line, it is pretty well hidden. (Unless one loads a large program I assume)
That's interesting, I never knew it was an incremental compiler. When you type RUN it did say Compiling before it would start running. It's possible that it was just a final housekeeping pass before starting execution. It did run very fast. DEC also did what they called a checkpass before running a BASIC-PLUS program that was incrementally compiled.
z/VM is not an operating system. It's a virtual machine hypervisor. It creates virtual machine System Z architecture environments in which operating systems run. z/OS can run "under" z/VM. DOS/VSE can run "under" z/VM. z/LINUX can run "under" z/VM (and is a very popular way to virtualize large numbers of servers). z/TPF can run "under" z/VM. There's even a z/VM only operating system, CMS (Conversational Monitor System) that runs under z/VM. CMS is the primary z/VM management tool, containing various support utilities including a file editor (XEDIT).
I'm familiar with CMS. I worked for IBM in the 80s and I used PROFS for email, IBM Forums for sharing all sorts of interesting things from around the corporation, Labor account management, and Travel reporting all running on CMS. I was working for IBM Federal Systems (IBM FSD) at the time, and we also had applications on CMS that were used for government contracts. We called it VM/CMS, at time time, and treated the combination as a very affective general purpose Time Sharing System. We even had compilers that worked interactively. When I joined IBM I had never used a mainframe, so just for the heck of it, I wrote a Fortran program and compiled and executed it under CMS. I also used XEDIT and REXX.
I should add, in IBM FSD we tended to call VM/CMS just VM. Technically that was wrong, but in local slang we'd just say VM. That slang creeped into my writing.
1000 people per frame is a load of bull. I have first hand experience. My last "real job" before retirement was with one of the largest financial services firms in the world. I was on the team that supported the online systems (trading, brokerage, mutual funds, customer statements, etc.) The company had two geographically separated mainframe data centers (North Carolina and Nebraska), each location running 6-7 physical frames running a total of 20+ system images (logical partitions each one running a copy of the z/OS operating system) spread across 7 parallel sysplexes (look it up). Every day, at market open, we processed more transactions per second in the first 15 minutes than the number of searches Google handles in a few hours. Our support staff consisting of system programmers (which I was), operators, network engineers, and production control numbered less than 100 people. The idea that mainframes are "more expensive" is also bunk. The total cost of operating that environment, including hardware, software licensing, and salaries, was less than 25% of the overall annual I.T. budget. The perception (and that's all it is, a perception) that mainframe systems are expensive comes from the fact that individual expenditures/purchases in the mainframe space tend to be large - large enough to require senior executive approval, so they get noticed. Incremental costs for individual servers and individual staff hires tend to be small, so a mid-level manager in a large corporation can buy hundreds of them and hire dozens of staff over a few years' time, and those purchases will escape the attention of senior execs. However, the total cost of handling the same business workload that even a medium sized mainframe is capable of, capacity wise, on small servers ends up being more expensive in the long run, not to mention more complex due to the number of server systems required. You can't plow a field by harnessing up 10,000 chickens.
IBM also had a BASIC on the 360 that ran on terminals with no JCL needed. I used it in college.
This is a comment from Brian S Williams on the Vintage Mainframe Enthusiasts FaceBook Group.
Sir: Regarding your statement of “Each mainframe needs 1,000 people to support it”. Are you kidding? Were you just exaggerating? If not, I’d like to politely request you cite your reference when you throw out a silly statistic like this one!
For the last five yrs, I’ve been working for a Unisys customer. We currently have ~5 (Burroughs MCP) mainframe systems (two production systems, one development system, one for quality assurance, and another for production support); all told, with mainframe application software developers (15), data center mainframe tech support (10), mainframe software quality assurance testers (10), mainframe computer operators (15), all told, probably ~50 people at the max.
Prior to my current position, I previously worked for Unisys Corporation for ~30 yrs from 1980 to 2009; the last twenty of those yrs were in Eagan, MN which was Unisys’s corporate datacenter, AND premier outsourcing datacenter. At its peak before I left, we had ~30 mainframes of Burroughs MCP vintage, and probably a similar nbr of Sperry OS2200 mainframes, with a total of about 100-150 datacenter support personnel.
I don’t have a good feel of how many people were in the I.T. area (application developers, testers, etc.) - but it wasn’t anywhere near 1,000 people per mainframe. I’d guess Unisys had, at most 500 application software developers/testers/analysts across both (Burroughs & Sperry) hardware platforms. Those 500 I.T. people and 150 datacenter support people “supported” 50-60 mainframes, twenty yrs ago.
Sir: One reason why I initially wrote is due to the phrase…”each mainframe takes x people to support it”. I typically would not add in application developers, QA testers - i.e., people in I.T.; those people don’t “support” mainframes; they write software applications for it but don’t “support” it. So, when I indicated the 500 I.T. people above, they should really be eliminated from the equation - and so, we’re left to ~150 datacenter support people supporting 50-60 mainframes.
I’m hoping this helps you understand that no mainframe takes 1,000 people to support it - not even close. I sincerely apologize if the “1,000” was a typo; even if it were just one hundred people to support a single mainframe, that still would mean, 5,000 people to support the ~50-60 machines we had at Unisys ~twenty yrs ago, and I can confirm we never, ever had that many in the combined datacenter support departments and I.T. application development departments. Ever.
Thank you for your time and consideration.Here's a comment from
Hey everyone, don't hesitate in posting comments here, particularly if I get something wildly wrong, like the number of people needed to work on a mainframe. At least I know there are people out there 😳
Gary, I think this is the situation with the Unisys environment today and it is worth pointing out the dichotomy. If I am wrong, I hope you or someone can clarify it.
It appears to me that they actually support two complete environments. Both run under emulation of the old hardware instruction set architectures, but the machines running the emulators seem to be a modern cluster of Intel CPUs, as you referred to,
(1) OS 2200 as you mentioned. An environment descended from the UNIVAC 1108 EXEC 8 et seq. operating system <https://en.wikipedia.org/wiki/OS_2200> for the Unisys ClearPath Dorado family of mainframe systems. <https://www.support.unisys.com/2200/docs/CP19.0/78310612-036.pdf>
(2) MCP. An environment descended from the Burroughs MCP operating system <https://en.wikipedia.org/wiki/Burroughs_MCP> for the the Unisys Clearpath/MCP systems
There are separate sets of documentation for each at the top of the list here:
<https://public.support.unisys.com/common/epa/documentationlibraries.aspx>
An amusing aside: for MCP, they've modernized their ALGOL manual from BNF to rail-road charts like those for the classic PASCAL language definition: <https://public.support.unisys.com/aseries/docs/clearpath-mcp-18.0/86000098-516/index.html>
Also, Microsoft says: "The Unisys mainframe systems trace their heritage to the first commercially available mainframes. The Unisys ClearPath Forward (CPF) Dorado (legacy Sperry 1100/2200) and Libra (legacy Burroughs A Series/Master Control Program) systems are full-featured mainframe operating environments. They can scale vertically to handle mission-critical workloads. These systems can be emulated, converted, or modernized into Azure. Azure offers similar or even improved performance characteristics and service-level agreement (SLA) metrics."
<https://learn.microsoft.com/en-us/azure/architecture/example-scenario/mainframe/unisys-clearpath-forward-mainframe-rehost>
<https://learn.microsoft.com/en-us/azure/architecture/mainframe/virtualization-of-unisys-clearpath-forward-os-2200-enterprise-server-on-azure>
Those documents have diagrams (click to embiggen them) of the layering above both the MCP and 2200 systems.
Yes, they do have two complete environments. One is legacy Burroughs, and the other is legacy Univac. When I was working at the General Services Administration (GSA) they were using the Burroughs legacy equipment, so my link is wrong. I forgot Clearpath is the Univac side. I’m sure they have a similar bundle for the Burroughs side. At the University of Maryland, in 1980, they had a Univac 1100 series model. I don’t remember the exact number. The Burroughs machines I worked on at Delaware were much better machines. The time-sharing system for the Univac machines was very odd and counterintuitive.