Here is an interesting site with info about IBM SYSTEM/360.
Architecture of the IBM System/360, by Gene Amdahl.
Andris PADEGS's page about the System/360 Input/Output Interface he invented.
In April 1964, IBM announced OS/360, an operating system developed to support the new generation and architecture of System/360 hardware - hardware capable of supporting both commercial and scientific applications. Prior to System/360, those applications ran on separate lines of hardware.
T.Falissard's note. I believe that the term "360" was coined by IBM to express their ambition to encompass the customers' needs at a 360-degree angle. Anyway, this ambition was not fulfilled, since afterwards the numbers 370 and 390 were used... (of course, they relate - approximately - to the years when the new S/370 and S/390 technologies took place !)
OS/360 included three control program options, delivered in stages beginning in March 1966. The first stage was the simplest -a sequential scheduler called the primary control program (PCP). PCP performed only one task at a time, and ran in 32KB of memory. That's right! Kilobytes, not megabytes. With PCP, a processor could spend considerable time waiting for I/O. OS/360 was the first operating system to require direct access devices.
Shmuel's note. OS/360 was not the first operating system to require DASD. Burroughs B5000 (MCP), CDC 6600 (CIPROS), Ferranti Atlas and GE 625 (GECOS, later GCOS) all required DASD, to say nothing of IBM's own DCS.
Multiprogramming introduced the technique of assigning control of the processor to another task while the first task was waiting for I/O. This technique utilized resources more effectively.
Next came the MFT option (multiprogramming with a fixed number of tasks). Initially, MFT supported four tasks at one time. Later, it was upgraded to support up to fifteen tasks. A third option, MVT (multiprogramming with a variable number of tasks) followed. Theoretically, MVT allowed any number of tasks to be performed concurrently. Because of the added function, more real storage was required : 64KB for MFT and 128KB for MVT.
Shmuel's note. The PCP, MFT and MVT that we all love < g > were not in the original OS/360; their predecessors were SSS, MSS and MPS. MPS evolved into VMS before becoming MVT. VMS was basically MVT without regions, and had to be abandoned because of storage fragmentation.
System installation was accomplished through sysgen, a time-consuming, difficult and tedious process performed in two stages: building the system and defining the I/O configuration. Early user requirements identified the need to simplify this process.
Shmuel's note. The two stages of a sysgen were assembling the system definition (including I/O) and assembling the output of stage 1. The I/O gen was not a separate stage, but a process for updating an existing system, and was broken into the same two stages.
T.Falissard's note. I remember how much these processes were tedious... We had to wait for MVS/XA v2.2.0 to get rid of the IOGEN, replaced by the MVSCP (which itself was replaced by HCD with MVS/ESA v5). The only product that has been keeping a SYSGEN-like procedure nowadays is IMS ; the process takes some time to complete, although it is not lasting any longer hours and hours, like in the past.
Prior to OS/360, even the most dedicated programmers found I/O programming to be a painful process repetitive, inconsistent and error-prone. OS/360 supplied data and telecommunications access methods that simplified the task.
Shmuel's note. OS/360 data management derived quite a bit from IOCS in IBJOB and other older systems.
Job control language (JCL) also was introduced at this time.
Shmuel's note. JCL was not introduced by OS/360, although the name was. Early systems such as IBJOB had job control languages, and provided much of the inspiration for OS/360 JCL.
Upon initial release, the access methods included BSAM, QSAM, BDAM, BPAM and BTAM. In addition, OS/360 contained system utilities, an assembler, and some compilers. Applications were soon developed that required faster access to data. Consequently, ISAM and QTAM were added. Later, improvements were made to linking and loading, additional compilers were developed, and new functions and operational enhancements were added. A checkpoint/restart facility was developed to allow applications to restart at points other than the beginning. However, due to the limited size of processor storage, many applications couldn't be stored in one piece. An overlay supervisor was developed to help control and load the application in parts.
Shmuel's note. ISAM and QTAM provided enhanced functionality, not faster access to data. If anything, they were slower than the older access methods.
Shmuel's note. The overlay supervisor was in the original OS/360 announcement, and derived from the overlay supervisor in IBSYS/IBJOB.
In 1968, a multiprocessing capability was designed for the System/360 (S/360) Model 65. This new function was supported by MVT, and allowed a user to have dual Model 65s, which could share central storage under the control of a single operating system. Having two processors working on the same job significantly improved application availability.
Shmuel's note. The 9020 (FAA version of S/360) had multiprocessing before 65MP.
As more and more organizations began developing compilers, users wanted the flexibility to pick and choose among these, including IBM compilers. To respond to this need, in 1969 IBM changed its definition of the operating system to distinguish our compilers from system code. Compilers were classified as program products, offered under separate license agreements.
OS/360 was originally developed as a batch operating system. However, users soon asked for interactive capability. In 1971, IBM released the time-sharing option (TSO), which became an integral part of the operating system. TSO used TCAM, a new telecommunications access method that was developed and released at the same time.
Release 21.8, the last in the OS/360 line, was made available in 1974.
Martin Wills' testimony. "I genned PCP on a 360/40 in London, England in 1968. I had to do a full sysgen, including an assembly of most of the nucleus, and the only way to figure out how SVCs like Open/Close/EOV worked was to manually disassemble, since there were no logic manuals or fiche available at the time. The nucleus size on our 128k system was 18k, but obviously more memory was taken up by transient SVCs. The operating system, although simple, had much of the basic structure that's still in MVS. That is, UCBs, Type 1 SVCs like Getmain/Freemain, rudimentary task management and so on. It was a wonderful opportunity to learn about operating systems since it was small enough to get your head around. I pity people starting from scratch today staring at all that complexity."
"I remember a large COBOL program that ran for six hours doing fairly little since it produced a lot of printed output and spent most of its time waiting for the 1403. It was also interesting to place an off-tuned radio near the CPU and run sonmething with lots of loops, like the Link Editor. The sounds the radio picked up could be very danceable. My understanding is that PCP metamorphosed into CMS in the VM world, almost intact." (Martin Wills works for MVS Solutions Inc., the home of ThruPut Manager.)