Were any IBM mainframes ever run multiuser?

Question

Now of course there is a sense in which they were – some mainframe installations supported thousands of users! But there is a distinction.

Consider the familiar fixture in so many 80s computer science labs: a VAX running UNIX or VMS, with an account for each student. That's a multiuser system in the sense that each user had an account with the right to run arbitrary code. Thus it was necessary or at least highly beneficial for the operating system to use memory protection to screen the users from each other, so that e.g. one student trying to debug a C program dereferencing stray pointers, couldn't crash another's processes.

By contrast, consider this site, retrocomputing.stackexchange.com. It has many users – but we are not users on the underlying server. The server is running an operating system, most often Linux, that has multiuser capability like the VAX – but that multiuser capability is not being used. We users do not have the right to run arbitrary code, and we can be handled purely in software. To the operating system, the entire site is just one user.

Now, IBM mainframes were not really about providing student accounts. Their stock in trade was transaction processing. A mainframe might, say, run an airline reservation system. Each teller making bookings would be a user within the reservation system – but not running arbitrary code, and not a user on the operating system.

So that's the typical mode of use of an IBM mainframe. And at least in the early days, some of them were also used to run student jobs in batch mode.

But were any of them used like the college-lab VAX, to provide a bunch of people with interactive shell accounts that could run arbitrary code?

Answer 1

Yes. There were CP/CMS and VM/370 - true multiuser operating systems running on the mainframe with individual users logged in. AFAIK it was mainly used for software developers (to develop IBM mainframe software).

I had the pleasure working on VM/370 once. Not what you'd call an ideal development environment. You got storage allocated to you: A certain number of 'cylinders' on the hard disk. Then you allocated files on it yourself. By cylinder number. IIRC. Not pretty.

Here's a wikipedia article on (historical) IBM operating systems that points to other articles on these multiuser systems.

Try it yourself on the Hercules emulator! 🡄 no warranty here! I have not tried it myself and have no intention to at any time whatsoever.

Answer 2

IBM mainframes are still around (IBM Z). Linux has been available for IBM Z hardware and its predecessor, System/390, for 20 years, and z/OS is itself a certified UNIX through the z/OS UNIX System Services. Which is to say that IBM mainframes have been run in UNIX-like multi-user fashion for two decades by running UNIX.

Apart from that, z/OS and its predecessors have been supporting multiple concurrent users through RACF (access control) and TSO (time sharing) since the 1970s.

Answer 3

Another one to mention is MTS which was first released in 1967, last release in 1988. It was in use at Rensselaer Polytechnic Institute from 1976 to 1999, of which I took part during the early 80s. In 1984 they were running it on Sybil, a dual processor IBM 3081D; slightly before that it ran on Myron, which I think was a 3070 but I'm not sure.

There were a wide variety of dumb terminals attached, everything from IBM Couriers to AMD3As to even some DECWriters if you needed a transcript.

And yes, we all had our own "shell" accounts with access to multiple compilers (PASCAL, LISP, FORTRAN, SNOBOL come to mind. The C course I took had its coursework on an IBM PC, but there was probably a compiler for that on MTS too.)

Answer 4

Certainly. A place where I worked in the early 1980s had an IBM 4341 system running some species of MVS, with the TSO ('time sharing option') that supported interactive program development.

I'm slightly familiar with this, since at the time I was writing a 3277 terminal emulator for VMS, and once it was good enough, the IBM sysprogs switched to that so that they could work on VMS and MVS with only one terminal on their desks.

Answer 5

But were any of them used like the college-lab VAX, to provide a bunch of people with interactive shell accounts that could run arbitrary code?

Absolutely 100%!

TL;DR University of Maryland - hundreds of simultaneous users on ASCII terminals emulating 3270 terminals for full interactive usage of email and programming.

I was a student at the University of Maryland, College Park in the 1980s. They had several IBM mainframes as well as some VAXen, a Univac 1100 mainframe and assorted smaller machines including while I was there starting to add labs full of IBM PC/XT/AT instead of just dumb terminals.

The VAXen were used primarily for graduate level research and occasional other courses - I never had the opportunity to use them myself! The IBM mainframes were the main systems used for Computer Science courses and for the typical COBOL courses in the Business department. Everyone (by which I mean, undergraduate students and professors in those courses, which were the bulk of the people on campus using email at the time) had interactive accounts running under VM/CMS. For anyone who had to (or wanted to) program, they had access to many languages running on the IBM mainframes.

There were some real IBM 3270 terminals in the bowels of the computer science building. But almost everyone used an ASCII video terminal (ADM 3A was typical, but there were some other types) or a DECwriter to access these mainframes as well as to access the Univac, the VAXen and possibly some other systems. There was some system in between the terminals and the mainframes that (a) handled (in some cases, some were dedicated to one system) selection of host system and (b) translated ASCII to EBCDIC for the IBM systems.

Initially all those terminals (not just the DECwriters :-) ) were all running in TTY mode. While I was there they switched to full-screen 3270-emulation for most of the video terminals, which was a huge improvement. I (and my evil twin) helped teach our class how to use the full-screen editor as it was a big change and not everyone jumped right in. We also went down to the computer science basement over winter break to have our terminal (Wyse 100 - beautiful machine) programmed into the Series/1 that handled the 3270 emulation so that we could use all the features (more than the ADM 3A could do).

I don't know how well memory protection, storage partitioning, etc. all worked on those mainframes. We were basically assigned a chunk of space (IIRC, you could get more space if you justified it) and just did our thing, essentially as if we had our own standalone mainframe - except no access to bare metal, of course. I do know that if you ran something that really hogged CPU time they might notice and get you in a little trouble. (But that is a story for another time.)

Answer 6

Thus it was necessary or at least highly beneficial for the operating system to use memory protection to screen the users from each other ...

That "memory protection" scheme is typically virtual memory.

---

But were any of them used like the college-lab VAX, to provide a bunch of people with interactive shell accounts that could run arbitrary code?

Yes, dating back to the late 1960s.
"The IBM System/360 Model 67 was announced in 1965 and shipped in 1966 to support the demand for time-sharing systems, computers that could support numerous users at the same time. The Model 67 was essentially a Model 65 with the addition of virtual memory.
It supported "on-line" computing with remote users, time-sharing, and multiple concurrent users. Unfortunately, due to delays in releasing the operating system the Model 67 was not a large success, with only 52 installations by the end of 1970."

Quotes from http://www.righto.com/2019/04/iconic-consoles-of-ibm-system360.html

Similar information is at https://www.computerhistory.org/revolution/mainframe-computers/7/161:
"A version for timesharing, called the Model 67, was the first 360 to use virtual memory."

I recall using a timeshare account on the university's IBM 360 back in the early 1970s. A hardcopy terminal (probably an IBM 2741 Terminal) with a Selectric "golf ball" print head was used for sessions, and were scattered around the campus.

Answer 7

The University of Cambridge (UK) Computing Service acquired a 370 around 1972 at the time I was starting my Ph.D, and operated it as a time-sharing service. Using experience from the Titan operating system, they pretty well rewrote the system (it was unusable out of the box).

Particular features I recall were the job scheduler devised by John Larmouth, which was designed on the premise that rationing resources didn't work, and paying for resources didn't work, instead you incentivised users by giving faster turnround if they made an effort to economise on their use of resources - this worked very effectively.

JCL of course was totally unusable, so they wrote their own Phoenix Command Language to replace it: I don't remember who was responsible for it, but Steve Bourne was an active member of the team and I think you'll find early ideas in there that later came to fruition in the Bourne shell.

There was also an in-house text editor developed by Philip Hazel later famous for the PCRE regex engine; it was a powerful language which I think someone proved to be Turing complete, and it was the only language small enough to run in the 8K memory available to interactive users, so we did some powerful coding in it.

I did all my coding in BCPL, as did many others, under the guidance of Martin Richards. I seem to remember my own contribution was a little utility for freeing up space in disk libraries ("partitioned data sets" IIRC?) needed because the IBM utility was incredibly resource hungry.

The other thing I recall was that on the Titan machine security had been a major feature, and breaking the security was considered a major challenge. On the 370, security was so feeble that breaking it was no fun at all. They made the radical decision to remove all filestore protection: everything was public, so you simply didn't put anything sensitive on the machine, and you didn't gain any kudos for penetrating it.

Answer 8

Circa 1970, MIT's EE department operated an APL\360 virtual machine under CP/67 on an IBM 360/67. APL\360 was a multiuser dialup system for 360 mainframes, specialized for APL, but virtualizing it meant that the physical mainframe computer was shared with other users, who were mostly using CMS. So, a timeshared timesharing system. IBM's research center in Yorktown, NY was running multiuser APL\360 commencing no later than 1967.

Answer 9

Wikipedia has this: https://en.wikipedia.org/wiki/Time-sharing_system_evolution

IBM features heavily.

Answer 10

In the 70's I used Orvyl and Wylbur extensively on Stanford's 360/67, which Wikipedia says were originally developed in 1967-68. There were golfball terminals all over campus. Keypunched batch jobs were simultaneously being processed via card reader at the computer center.

Answer 11

To add to all this, System/370 with virtual memory was one of the first platforms (perhaps the third) that UNIX was ported to. You can read a paper about that porting done here. IBM would follow it up with an AIX port not long after.

It was never a dominant mainframe OS, but a number of customers ran UNIX or UNIX clones on their mainframes starting in the 80s, often under virtualization alongside other OSes. Some still do, with zSeries having excellent Linux support.

Answer 12

Yes

To add to the UM students above we had a 7090 in the mid 60s that any student could run their own program on by submitting a punch card deck to the computer center.

You picked up the print out and your cards later, often being returned to our own building where you could also have submitted them to be carried to the computer center.

Later in the 60s the IBM datacenter on 19th st in DC offered shared running of user programs in their 360/65. Other computers even the 360/30 were designed to run multiple jobs at once and the user would have been irrelevant if one was allowed to access the computer whether themselves or by having an operator submit the job.

Once telecomm was widely used most IBM mainframes were accessed by many users either with RJE or by time sharing.

Answer 13

Lots of good information here but as an ex-MVS sysprog I would like to approach it from a different direction.

The MVS/370 operating system (Multiple Virtual Storage on 370 architecture) was an OS that could provide virtual address spaces to a large number of users. Although not directly equivalent think of an address space as being like a Unix process and its associated memory space. Certain memory addresses (the nucleus/kernel) would be common and probably read-only for user processes but each address space would have its own private memory that it could do with as it pleased without affecting any other address space. Unless explicitly specified programs could be loaded anywhere into memory so internal addresses had to be relocatable. Many features of modern computing that we take for granted were invented or first implemented by these early IBM systems.

Thus one address space would be used to run JES2 or 3 (Job Entry Subsystem), another for VTAM (Virtual Telecommunication Access Method - terminals etc), one for CICS, one for an IMS database etc.

For interactive users they could either all connect to a single CICS region or by using TSO (Time Sharing Option) each user would also have their own address space. This was quite resource heavy for the system so TSO use was generally limited to those who really needed it. And for reference, ISPF, a panel-driven interface that ran under TSO gave MVS a "friendly" user interface when Unix was still using the command line :-)

As has been mentioned another OS that used this architecture at the time was VM/370. As the name suggests the only function of VM was to provide Virtual S370 architecture Machines in which you would run the "real" OS. MVS for example could be run within a single VM virtual machine and many shops would run multiple MVS copies each in their own virtual machine running under a single instance of VM/370. Another OS that ran under VM/370 was CMS which was a single user environment providing a command line interface, disk space etc. CMS also had its own panel-driven environment but this was not as powerful as ISPF.

So yes, through VMs and address spaces the early IBM mainframe OSes definitely provided separate user spaces in which individuals would run programs etc.

Answer 14

Yes, I had a timeshare account on my university's IBM System/360 in the early 1970s where I wrote and debugged programs in APL. The computer center had several dumb terminals that students could use for personal projects. Input was by keyboard and light pen -- no mouse. Printouts could be picked up in the printer room down the hall.

Answer 15

Many answers mention interactive timesharing systems, but, even in a purely batch environment, there would typically be multiple jobs (i.e. processes) loaded into main memory at once and the CPU would switch between them.

The reason was efficiency. If you have one job that had to stop and wait for, say, a tape to be mounted, you'd want the CPU to switch to a compute bound job. Although core memory was very expensive, high-end CPUs were very very expensive; it made sense to buy enough core memory that several jobs could fit in it at once, so as to keep the idle time of the CPU low.

Then as now, the computer was executing arbitrary machine code submitted by the user. Users would typically put stacks of cards in a bin for the operator to pick up and load into the card reader. After a few cards at the front that contained the user name, password, and OS commands, these cards would (or could) contain machine code.

Thus memory protection was important, since you wouldn't want a stray pointer from one job to mess up another.

This really has little to do with there being multiple users. Then, as now, you didn't want bad pointers in one process to mess up another process, even if the same user owns both processes.

One place where user accounts were important was for reading and writing files. If the operator got a request to mount a tape belonging to user X from a job submitted by user Y, that would be a problem. When disks files came along, the protection needed to be automated.

Another place where user accounts were important was billing.

Answer 16

Most large System/360 and System/370 installations were multiuser. I never saw a University whose S/360 or S/370 was not multiuser, and I never worked on a machine larger than a 360/50I that was not multiuser. CP-67, TSO and VM were common, to say nothing of the services running multi-user APL software.

As for single threading command interpretation, that never happened, except perhaps on dedicated APL services (I doubt that APL did that either, but can't rule it out.) It's true that the TSO code in the Link Pack Area (LPA) was shared by all users, and that CMS users commonly shared a Dis-Contiguous Shared Segment (DCSS), but that was read-only code, not part of the user's state, and multiple users could be concurrently executing the code.

Answer 17

CTSS at MIT was one of the first timesharing systems ever built. It ran on a modified IBM 7094 mainframe. This is from the 1963-1966 time frame.

Memory protection was extremely primitive. There were two banks of memory, one for the system and the other for the current user. The user program could only clobber its own memory.

Users could develop programs interactively, from teletypes or terminals that looked like an IBM selectric typewriter.

https://www.multicians.org/thvv/7094.html