May 16, 2014 at 00:12IBM System / 360 - A Failing Story
I continue my series of articles about IBM System / 360 (the first part about the system as a whole , the second part about architecture ). Several interesting topics remained unaffected, and the first of them was System / 360 operating systems, especially the historical aspect of their development.
Until the early 1960s, IBM's "powerful" and "budget" solutions were incompatible. Porting programs was difficult, and sometimes completely impossible. This was due to many reasons, ranging from differences in operating systems to differences in peripherals. What now seems self-evident - the compatibility of various software and hardware components, was then completely optional. It was during the development of System / 360 that the company's engineers decided that such an approach would greatly increase the cost of development and further maintenance, and decided to standardize the new system, simplifying porting of programs and computer maintenance.
It was originally planned to supply System / 360 computers with a new operating system with batch job processing. Simply put, each program that needs to be run is described as a “package” —the program itself and a set of input data. These packets are processed sequentially depending on priority and availability of resources. This approach allowed us to reduce human participation in the planning of the mainframe and optimize its load, thus reducing overhead. The operating system was to be called OS / 360.
The developers of this OS set themselves incredibly ambitious tasks that were not solved before. This operating system was supposed to provide support for "multiprogramming." With slow peripherals, executing only one program at a time led to frequent downtime when the system was waiting for some data from an external device. Therefore, an approach similar to modern asynchronous programming was used. Several programs were loaded into memory and the first of them was launched for execution. If a long wait was necessary, the context of the current program was saved, and control was transferred to the next one, which could work while the first one was waiting for data. The operating system in this case had to keep everything under constant control, protecting downloaded programs from failures of other programs, and controlling access to resources. All this was complicated by the lack of the concept of virtual memory. The operating system was supposed to work on all models of the line, so the configurations ranged from 16 KB of RAM to 1 MB, and the speed of operation ranged from several thousand operations per second to half a million. Also, the operating system had to satisfy the needs of all programs, starting with complex mathematical calculations that almost never used external drives, and ending with simple DBMS analogs that were completely based on input-output operations.
As you can see, the plans were ambitious, but time was running out. The hardware was ready to go on sale, competitors attacked market segments in which IBM was the most vulnerable, and a stable and reliable version of OS / 360 was never born. In addition, the resulting solution did not want to fit in the memory of younger models. It was Solomon's decision to release the operating system in a simpler form with the promise of further upgrades.
Several intermediate options have been developed.
BOS / 360 (Basic OS) - a system for the simplest low-end models.
TOS / 360 (Tape OS) - system for modifications with loading from a magnetic tape.
DOS / 360 (despite the name, had nothing to do with the familiar x86-era DOS) - the "main" version for most medium and powerful configurations.
PCP (Primary Control Program) is what we would now call the "beta version" of full OS / 360, which did not support multiprogramming.
By the release of Series / 360-67 (if you read the first part of the article, you should remember that the concept of virtual memory appeared in this system) the release of TSS / 360 (Time Sharing System) was planned. As the name implies, this version was supposed to support time-sharing mode. Trial versions of this operating system were given for testing to large corporate clients, but the reviews were negative, and the OS was already “late” taking into account the market situation, so the TSS / 360 was canceled. By this time, the CP-67 OS, which was developed at the IBM Cambridge Research Center, was already sufficiently debugged. The CP-67 was so stable that IBM began to provide it to customers, although under the terms of the "cancellation of warranty", as an OS with support for time sharing. Further development of this operating system has led to
“The
problems that IBM faced when developing OS / 360 were so great that they gave impetus to the development of“ software engineering ”in the form in which we know it. It was then that it became clear that software development and process management was Resource-intensive disciplines that require a scientific approach to achieve a controlled result The
senior project manager of the OS / 360 development project, who was personally responsible for everything, wrote a book that has become almost a bible for software development managers (as the author said, “all we don’t read it, but nobody follows it. ”) Yes, we are talking about Frederick Brooks and his book“ The Mythical Man-Month. ”
Of all the principles that Brooks formulated, the following two most clearly characterize the essence of the OS / 360 development project.
Adding resources (including human resources) to a project does not always lead to a reduction in its terms, often the effect may even be the opposite. As stated in the book, the development of the Algol compiler always takes six months, regardless of the number of programmers involved.
A new version of a successful system is often doomed to failure, as developers will try to realize all the wishes of users. Brooks called it the "second system effect."
As you can see, on the one hand, the development of the main version of OS / 360, if it did not become a complete failure, is very close to it. On the other hand, IBM managed, despite this, to make System / 360 successful, and the lessons learned from this became the foundation of modern approaches to software development.
To be continued
Until the early 1960s, IBM's "powerful" and "budget" solutions were incompatible. Porting programs was difficult, and sometimes completely impossible. This was due to many reasons, ranging from differences in operating systems to differences in peripherals. What now seems self-evident - the compatibility of various software and hardware components, was then completely optional. It was during the development of System / 360 that the company's engineers decided that such an approach would greatly increase the cost of development and further maintenance, and decided to standardize the new system, simplifying porting of programs and computer maintenance.
It was originally planned to supply System / 360 computers with a new operating system with batch job processing. Simply put, each program that needs to be run is described as a “package” —the program itself and a set of input data. These packets are processed sequentially depending on priority and availability of resources. This approach allowed us to reduce human participation in the planning of the mainframe and optimize its load, thus reducing overhead. The operating system was to be called OS / 360.
The developers of this OS set themselves incredibly ambitious tasks that were not solved before. This operating system was supposed to provide support for "multiprogramming." With slow peripherals, executing only one program at a time led to frequent downtime when the system was waiting for some data from an external device. Therefore, an approach similar to modern asynchronous programming was used. Several programs were loaded into memory and the first of them was launched for execution. If a long wait was necessary, the context of the current program was saved, and control was transferred to the next one, which could work while the first one was waiting for data. The operating system in this case had to keep everything under constant control, protecting downloaded programs from failures of other programs, and controlling access to resources. All this was complicated by the lack of the concept of virtual memory. The operating system was supposed to work on all models of the line, so the configurations ranged from 16 KB of RAM to 1 MB, and the speed of operation ranged from several thousand operations per second to half a million. Also, the operating system had to satisfy the needs of all programs, starting with complex mathematical calculations that almost never used external drives, and ending with simple DBMS analogs that were completely based on input-output operations.
As you can see, the plans were ambitious, but time was running out. The hardware was ready to go on sale, competitors attacked market segments in which IBM was the most vulnerable, and a stable and reliable version of OS / 360 was never born. In addition, the resulting solution did not want to fit in the memory of younger models. It was Solomon's decision to release the operating system in a simpler form with the promise of further upgrades.
Several intermediate options have been developed.
BOS / 360 (Basic OS) - a system for the simplest low-end models.
TOS / 360 (Tape OS) - system for modifications with loading from a magnetic tape.
DOS / 360 (despite the name, had nothing to do with the familiar x86-era DOS) - the "main" version for most medium and powerful configurations.
PCP (Primary Control Program) is what we would now call the "beta version" of full OS / 360, which did not support multiprogramming.
By the release of Series / 360-67 (if you read the first part of the article, you should remember that the concept of virtual memory appeared in this system) the release of TSS / 360 (Time Sharing System) was planned. As the name implies, this version was supposed to support time-sharing mode. Trial versions of this operating system were given for testing to large corporate clients, but the reviews were negative, and the OS was already “late” taking into account the market situation, so the TSS / 360 was canceled. By this time, the CP-67 OS, which was developed at the IBM Cambridge Research Center, was already sufficiently debugged. The CP-67 was so stable that IBM began to provide it to customers, although under the terms of the "cancellation of warranty", as an OS with support for time sharing. Further development of this operating system has led to
“The problems that IBM faced when developing OS / 360 were so great that they gave impetus to the development of“ software engineering ”in the form in which we know it. It was then that it became clear that software development and process management was Resource-intensive disciplines that require a scientific approach to achieve a controlled result The
senior project manager of the OS / 360 development project, who was personally responsible for everything, wrote a book that has become almost a bible for software development managers (as the author said, “all we don’t read it, but nobody follows it. ”) Yes, we are talking about Frederick Brooks and his book“ The Mythical Man-Month. ”
Of all the principles that Brooks formulated, the following two most clearly characterize the essence of the OS / 360 development project.
Adding resources (including human resources) to a project does not always lead to a reduction in its terms, often the effect may even be the opposite. As stated in the book, the development of the Algol compiler always takes six months, regardless of the number of programmers involved.
A new version of a successful system is often doomed to failure, as developers will try to realize all the wishes of users. Brooks called it the "second system effect."
As you can see, on the one hand, the development of the main version of OS / 360, if it did not become a complete failure, is very close to it. On the other hand, IBM managed, despite this, to make System / 360 successful, and the lessons learned from this became the foundation of modern approaches to software development.
To be continued