IBM System / 360 - The story of the failure, not so
I continue my series of articles on the IBM System / 360 (the first part about the system as a whole , the second part about the architecture ). Some interesting topics remained untouched, and the first of them is System / 360 operating systems, especially the historical aspect of their development.
Until the early 60s, IBM’s “powerful” and “budget” solutions were incompatible. The transfer of programs was difficult, and sometimes completely impossible. This was due to many reasons, starting with the difference in operating systems and ending with peripheral differences. What now seems self-evident - the compatibility of various software and hardware components, then it was not at all mandatory. It was during the development of System / 360 that the company's engineers decided that such an approach greatly increases the cost of development and further maintenance, and decided to standardize the new system, simplifying the porting of programs and the maintenance of computers.
It was originally planned to supply the System / 360 computers with a new operating system with batch processing of tasks. Simply put, each program that needs to be launched is described as a “package” —the program itself and the input data set. These packages are processed sequentially depending on priority and resource availability. Such an approach allowed reducing human participation in planning the work of the mainframe and optimizing its load, thus reducing overhead costs. The operating system was supposed to be called OS / 360.
')
The developers of this OS have set themselves incredibly ambitious tasks that have not been solved before. This operating system was supposed to provide support for "multiprogramming." With slow peripherals, executing only one program at a time resulted in frequent downtime when the system waited 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 one was launched for execution. If you need a long wait, the context of the current program was saved, and control was transferred to the next one, which could work while the first 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 a concept of virtual memory. The operating system had to work on all models of the line, so the configurations varied from 16 KB of RAM and up to 1 MB, and the speed of work - 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, which almost did not use external drives, and ending with simple analogs of the DBMS, which 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 the market segments in which IBM was most vulnerable, and a stable and reliable version of OS / 360 was not born. In addition, the resulting solution did not want to fit in the memory of younger models. It was decided by Solomon 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 most simple low-end models.
TOS / 360 (Tape OS) - system for modifications with loading from magnetic tape.
DOS / 360 (despite the name, had nothing to do with the familiar DOS of the x86 era) - the “basic” version for most medium and powerful configurations.
PCP (Primary Control Program) is what in our time would be called a "beta version" of a full OS / 360 that 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 virtual memory concept appeared in this system) the release of the 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 to large corporate clients for testing, but the reviews were negative, and the OS was already “late” in view of the market situation, so the release of TSS / 360 was canceled. By this time, the CP-67 operating system, which was developed at the Cambridge IBM Research Center, was already quite debugged. The CP-67 was so stable that IBM began to provide it to customers, albeit on a “disclaimer”, like an OS with time-sharing support. Further development of this operating system led to the fact that it formed the basis of VM / 370 and then z / VM.
"
The problems that IBM faced in 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 management of these processes are resource-intensive disciplines, to which a scientific approach should be applied to obtain a controlled result.
The senior project manager of the OS / 360 development project, which was personally responsible for everything, wrote a book that became practically a bible for software development managers (as the author said, “everyone read it, but no one follows it”). Yes, it's 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 project for developing OS / 360.
Adding resources (including human) to a project does not always lead to a reduction in its time, often the effect may even be reversed. 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 implement all the wishes of users. Brooks called this the "second system effect."
As you can see, on the one hand, the development of the basic version of OS / 360, if it did not become a complete failure, was very close to it. On the other hand, IBM managed, despite this, to make System / 360 successful, and the lessons learned from it became the foundation of modern approaches in software development.
To be continued
Until the early 60s, IBM’s “powerful” and “budget” solutions were incompatible. The transfer of programs was difficult, and sometimes completely impossible. This was due to many reasons, starting with the difference in operating systems and ending with peripheral differences. What now seems self-evident - the compatibility of various software and hardware components, then it was not at all mandatory. It was during the development of System / 360 that the company's engineers decided that such an approach greatly increases the cost of development and further maintenance, and decided to standardize the new system, simplifying the porting of programs and the maintenance of computers.
It was originally planned to supply the System / 360 computers with a new operating system with batch processing of tasks. Simply put, each program that needs to be launched is described as a “package” —the program itself and the input data set. These packages are processed sequentially depending on priority and resource availability. Such an approach allowed reducing human participation in planning the work of the mainframe and optimizing its load, thus reducing overhead costs. The operating system was supposed to be called OS / 360.
')
The developers of this OS have set themselves incredibly ambitious tasks that have not been solved before. This operating system was supposed to provide support for "multiprogramming." With slow peripherals, executing only one program at a time resulted in frequent downtime when the system waited 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 one was launched for execution. If you need a long wait, the context of the current program was saved, and control was transferred to the next one, which could work while the first 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 a concept of virtual memory. The operating system had to work on all models of the line, so the configurations varied from 16 KB of RAM and up to 1 MB, and the speed of work - 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, which almost did not use external drives, and ending with simple analogs of the DBMS, which 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 the market segments in which IBM was most vulnerable, and a stable and reliable version of OS / 360 was not born. In addition, the resulting solution did not want to fit in the memory of younger models. It was decided by Solomon 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 most simple low-end models.
TOS / 360 (Tape OS) - system for modifications with loading from magnetic tape.
DOS / 360 (despite the name, had nothing to do with the familiar DOS of the x86 era) - the “basic” version for most medium and powerful configurations.
PCP (Primary Control Program) is what in our time would be called a "beta version" of a full OS / 360 that 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 virtual memory concept appeared in this system) the release of the 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 to large corporate clients for testing, but the reviews were negative, and the OS was already “late” in view of the market situation, so the release of TSS / 360 was canceled. By this time, the CP-67 operating system, which was developed at the Cambridge IBM Research Center, was already quite debugged. The CP-67 was so stable that IBM began to provide it to customers, albeit on a “disclaimer”, like an OS with time-sharing support. Further development of this operating system led to the fact that it formed the basis of VM / 370 and then z / VM.
"The problems that IBM faced in 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 management of these processes are resource-intensive disciplines, to which a scientific approach should be applied to obtain a controlled result.
The senior project manager of the OS / 360 development project, which was personally responsible for everything, wrote a book that became practically a bible for software development managers (as the author said, “everyone read it, but no one follows it”). Yes, it's 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 project for developing OS / 360.
Adding resources (including human) to a project does not always lead to a reduction in its time, often the effect may even be reversed. 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 implement all the wishes of users. Brooks called this the "second system effect."
As you can see, on the one hand, the development of the basic version of OS / 360, if it did not become a complete failure, was very close to it. On the other hand, IBM managed, despite this, to make System / 360 successful, and the lessons learned from it became the foundation of modern approaches in software development.
To be continued
Source: https://habr.com/ru/post/222985/
All Articles