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?

  • 5
    I recall using a timeshare account on the university's IBM 360 back in the early 1970s. Primary task was writing and testing my APL programs.
    – sawdust
    Commented Nov 26, 2020 at 6:01
  • 7
    My university used to give student accounts on their IBM mainframe running CP/CMS, and this was pretty common. Had I started a year earlier I would've gotten one for my first year CS courses. I believe all current IBM mainframe operating systems of the 80's at least had the option of supporting multiple interactive users.
    – user722
    Commented Nov 26, 2020 at 6:20
  • 3
    I used to work in an Agile Cobol shop on the AS/400. Everybody had their own account, and worked as individual users on the machine running what code was necessary for doing their job. Commented Nov 26, 2020 at 8:50
  • 5
    I have to disagree where you say the multiuser capabilities of Linux are not being used - true, most people do not have multiple physical people logged in to a Linux system running an interactive shell. But there are processes running in the OS as different “users”. At a minimum, the current user and “root”.
    – mannaggia
    Commented Nov 26, 2020 at 12:02
  • 2
    But by that token, any IBM system with user identities -- say via RACF -- is also "multiuser", as long as more than one of those identities is "active" at the same time.
    – dave
    Commented Nov 26, 2020 at 13:28

17 Answers 17


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.

  • 6
    I think it was VM/CMS - at least that's the system I was using at my first real computer job back in the mid-80s. Certainly was multi-user (supported a whole engineering department), could run arbitrary code, had some nice development tools. (I still use a derivative of its Xedit editor.) About the only thing it lacked was a *nix-style tree-structured file system.
    – jamesqf
    Commented Nov 26, 2020 at 16:37
  • 3
    As antique OSes go it's actually quite usable... however a lot of that is down to people who have continued to update it with helpfiles etc. smrcc.org.uk/members/g4ugm/VM370.htm Commented Nov 26, 2020 at 21:04
  • 2
    Wasn't this the programming environment that some compared to "kicking a dead whale down the beach"?
    – EvertW
    Commented Nov 27, 2020 at 10:39
  • 2
    @jamesqf VM/CMS was the successor to CP/CMS.
    – RonJohn
    Commented Jan 3, 2021 at 7:28
  • 1
    "AFAIK it was mainly used for software developers": VM/CMS was heavily used as an academic computing environment for researchers, teachers and students in the 1970s and 1980s. The famous statistical packages SAS and SPSS both started out on mainframes, and were most commonly used under VM/CMS. However, as the 1980s progressed, more and more of these workloads migrated to Unix, and in the 1990s it became increasingly defunct as an academic platform Commented May 3 at 10:03

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.

  • 4
    Adding to this, older versions of AIX ran on System/370 and ESA/390 hardware, so UNIX has been around on IBM mainframes for a while even before z/OS and Linux. Commented Nov 26, 2020 at 17:17
  • 2
    I'm struck by how much those IBM Z units resemble a soft drink vending machine, especially when open Commented Nov 27, 2020 at 3:13

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.)

  • 3
    Newcastle University in the UK ran MTS on a 360/67, and I believe Leeds University ran MTS on an Amdahl 470/V7 to replace George 3/4 on ICL 1906A (but this was after my time).
    – dave
    Commented Nov 26, 2020 at 16:51
  • 1
    Also MUSIC/SP, which goes as far as having TCP/IP support. Commented Nov 26, 2020 at 21:06
  • 3
    I remember SNOBOL very fondly, and after I got out of college, SPITBOL/386 was available as a commercial package that I purchased to run at home. It was my favorite language until I started using Python.
    – Itsme2003
    Commented Nov 28, 2020 at 19:02
  • 1
    In addition to Durham and Newcastle in the UK there were several other MTS sites, including the University of British Columbia, Simon Frazer University, the University of Alberta, the University of Michigan, Wayne State University, and Rensselaer. There was networking support for X.25/X.29 as well as TCP/IP using PDP-11 front end processors attached to the S/370 (the stuff I worked on in the 1980's.) Commented Nov 28, 2020 at 20:12
  • 1
    @brian-borchers Hi Brian, you probably don't remember me but we were in Hall Hall together that first semester in '84. Commented Nov 28, 2020 at 21:53

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.


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.)


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.


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.

  • 1
    Re scheduling - George 3 on the Leeds 1906A used the same theory - the High Level Scheduler was more willing to start your job if it hadn't seen too much of you lately.
    – dave
    Commented Nov 28, 2020 at 2:44
  • Much later (1987) I started using it. By then it had proper file protection (via RACF) - very flexible and easy to use ACLs. As a machine it had some significant influence in the wider world (en.wikipedia.org/wiki/Phoenix_(computer)). Commented Mar 9, 2021 at 21:40

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.

  • 2
    Although I think there was something a bit odd about the APL\360 runtime. I've only been into it sufficiently deeply to get my favoured terminal emulator running with it, but my understanding is that it was rather a hybrid between timesharing and "one program supporting lots of users" which is the normal mainframe way. Commented Nov 26, 2020 at 21:08
  • 1
    @MarkMorganLloyd Any OS gives the user a restricted environment. APL\360 gave the user an environment restricted to the APL language. CP/67 was less restricted, so it could run a wider variety of applications, including APL\360, but a CP/67 process was not a bare hardware environment.
    – John Doty
    Commented Nov 26, 2020 at 23:46
  • 1
    I am fully aware of that, but it's not what I meant or said. A multiuser system on e.g. unix has each user running a separate instance of the shell and whatever programs he needs, identified by numeric PID etc. A traditional online mainframe however typically has a single program accepting queued queries from users and returning responses (i.e. in unix terms this would be a single PID for all users), it is my understanding that this is how APL\360 worked. Commented Nov 27, 2020 at 8:38
  • 1
    @MarkMorganLloyd A distinction without a difference. In APL\360 each user had a separate instance of a shell-like command line interpreter, with both builtin commands as well as commands that invoked named program objects in the workspace. In APL\360's case, the named program objects happened to be binaries in bytecode that represented APL, while for Linux, for example, they are ELF binaries. A user's workspace contained named objects representing both code and data, just as in other systems. The namespace wasn't organized hierarchically, but that was a common limitation in early timesharing.
    – John Doty
    Commented Nov 27, 2020 at 12:45
  • 1
    If we're going to exclude systems where there's one instance of code interpreting commands from all users, then suddenly most of the classic timesharing systems were not timesharing systems after all. Example, TOPS-10.
    – dave
    Commented Nov 27, 2020 at 13:27

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

IBM features heavily.


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.


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.



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.

  • 1
    I just missed having to use punched cards. When I started, there were still some courses using punched cards, but not in the main CS curriculum. By the time I graduated, I think it was down to one punch/reader for the occasional old professor who walked in with his old deck. Commented Nov 26, 2020 at 17:56
  • 1
    I suspect the 7090 was 'one program at a time' batch -- if it was running IBSYS then it was. I've run punched-card FORTRAN jobs under IBSYS on a 7094.
    – dave
    Commented Nov 27, 2020 at 13:33

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.


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.


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.


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.


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.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .