IBM 700/7000 series
The IBM 700/7000 series is a series of large-scale computer systems that were made by IBM through the 1950s and early 1960s. The series includes several incompatible processor architectures; the 700s use vacuum tube logic and were made obsolete by the introduction of the transistorized 7000s. The 7000s, in turn, were replaced with System/360, announced in 1964; however the 360/65, the first 360 powerful enough to replace 7000s, did not become available until November 1965. Early problems with OS/360 and the high cost of converting software kept many 7000s in service for years afterward; the IBM 700/7000 series has six different ways of storing data and instructions: First: 701 Scientific: 704, 709, 7040, 7044, 7090, 7094 Commercial: 702, 705, 7080 1400 series: 7010 Decimal: 7070, 7072, 7074 Supercomputer: 7030 "Stretch"The 700 class use vacuum tubes, the 7000 class is transistorized. All machines use magnetic core memory. Early computers were sold without software; as operating systems began to emerge, having four different mainframe architectures plus the 1400 midline architectures became a major problem for IBM since it meant at least four different programming efforts were required.
The System/360 combined the best features of the 7000 and 1400 series architectures into a single design. However, some 360 models have optional features that allow them to emulate the 1400 and 7000 instruction sets in microcode. One of the selling points of the System/370, introduced in mid-1970, was improved 1400/7000 series emulation, which could be done under operating system control rather than shutting down and restarting in emulation mode as was required on the 360s. While the architectures differ, the machines in the same class use the same electronics technologies and use the same peripherals. Tape drives use 7-track format, with the IBM 727 for vacuum tube machines and the 729 for transistor machines. Both the vacuum tube and most transistor models use the same card readers, card punches, line printers that were introduced with the 701; these units, the IBM 711, 721, 716, are based on IBM accounting machine technology and include plugboard control panels. They are slow and it was common for 7000 series installations to include an IBM 1401, with its much faster peripherals, to do card-to-tape and tape-to-line-printer operations off-line.
Three machines, the 7010, the 7040 and the 7044, adopted peripherals from the midline IBM 1400 series. Some of the technology for the 7030 was used in data channels and peripheral devices on other 7000 series computers, e.g. 7340 Hypertape. Known as the Defense Calculator while in development in the IBM Poughkeepsie Laboratory, this machine was formally unveiled April 7, 1953 as the IBM 701 Electronic Data Processing Machine. Data formatsNumbers are either 36 bits or 18 bits long, only fixed point. Fixed-point numbers are stored in binary sign/magnitude format. Instruction formatInstructions are 18 bits long, single address. Sign – Whole-word or Half-word operand address Opcode – 32 instructions Address – 4096 Half-word addressesTo expand the memory from 2048 to 4096 words, a 33rd instruction was added that uses the most-significant bit of its address field to select the bank. RegistersProcessor registers consisted of: AC – 38-bit Accumulator MQ – 36-bit Multiplier-QuotientMemory2,048 or 4,096 – 36-bit binary words with six-bit characters IBM's 36-bit scientific architecture was used for a variety of computation-intensive applications.
First machines were the vacuum-tube 704 and 709, followed by the transistorized 7090, 7094, 7094-II, the lower-cost 7040 and 7044. The ultimate model was the Direct Coupled System consisting of a 7094 linked to a 7044 that handled input and output operations. Data formatsNumbers are 36 bits long. Fixed-point numbers are stored in binary sign/magnitude format. Single-precision floating-point numbers have a magnitude sign, an 8-bit excess-128 exponent and a 27-bit magnitude Double-precision floating-point numbers, introduced on the 7094, have a magnitude sign, a 17-bit excess-65536 exponent, a 54-bit magnitude Alphameric characters are 6-bit BCD, packed six to a word. Instruction formatThe basic instruction format is a three-bit prefix, fifteen-bit decrement, three-bit tag, fifteen-bit address; the prefix field specifies the class of instruction. The decrement field contains an immediate operand to modify the results of the operation, or is used to further define the instruction type; the three bits of the tag specify three index registers, the contents of which are subtracted from the address to produce an effective address.
The address field either contains an immediate operand. Registers Processor registers consisted of: AC – 38-bit Accumulator MQ – 36-bit Multiplier-Quotient XR – 15-bit Index Registers SI – 36-bit Sense IndicatorThe accumulator registers operate in sign/magnitude format; the Index registers operate using two's complement format and when used to modify an instruction address are subtracted from the address in the instruction. On machines with three index registers, if the tag has two or three b
The Mythical Man-Month
The Mythical Man-Month: Essays on Software Engineering is a book on software engineering and project management by Fred Brooks first published in 1975, with subsequent editions in 1982 and 1995. Its central theme is that "adding manpower to a late software project makes it later"; this idea is known as Brooks' law, is presented along with the second-system effect and advocacy of prototyping. Brooks' observations are based on his experiences at IBM while managing the development of OS/360, he had added more programmers to a project falling behind schedule, a decision that he would conclude had, counter-intuitively, delayed the project further. He made the mistake of asserting that one project—involved in writing an ALGOL compiler—would require six months, regardless of the number of workers involved; the tendency for managers to repeat such errors in project development led Brooks to quip that his book is called "The Bible of Software Engineering", because "everybody quotes it, some people read it, a few people go by it".
The book is regarded as a classic on the human elements of software engineering. The work was first published in 1975, reprinted with corrections in 1982, republished in an anniversary edition with four extra chapters in 1995, including a reprint of the essay "No Silver Bullet" with commentary by the author. Brooks discusses several causes of scheduling failures; the most enduring is his discussion of Brooks's law: Adding manpower to a late software project makes it later. Man-month is a hypothetical unit of work representing the work done by one person in one month. Complex programming projects cannot be partitioned into discrete tasks that can be worked on without communication between the workers and without establishing a set of complex interrelationships between tasks and the workers performing them. Therefore, assigning more programmers to a project running behind schedule will make it later; this is because the time required for the new programmers to learn about the project and the increased communication overhead will consume an increasing quantity of the calendar time available.
When n people have to communicate among themselves, as n increases, their output decreases and when it becomes negative the project is delayed further with every person added. Group intercommunication formula: n / 2 Example: 50 developers give 50 · / 2 = 1225 channels of communication. Brooks added "No Silver Bullet — Essence and Accidents of Software Engineering"—and further reflections on it, "'No Silver Bullet' Refired"—to the anniversary edition of The Mythical Man-Month. Brooks insists that there is no one silver bullet -- "there is no single development, in either technology or management technique, which by itself promises one order of magnitude improvement within a decade in productivity, in reliability, in simplicity." The argument relies on the distinction between accidental complexity and essential complexity, similar to the way Amdahl's law relies on the distinction between "strictly serial" and "parallelizable". The second-system effect proposes that, when an architect designs a second system, it is the most dangerous system they will design, because they will tend to incorporate all of the additions they did not add to the first system due to inherent time constraints.
Thus, when embarking on a second system, an engineer should be mindful that they are susceptible to over-engineering it. The author makes the observation that in a suitably complex system there is a certain irreducible number of errors. Any attempt to fix observed. Brooks wrote "Question: How does a large software project get to be one year late? Answer: One day at a time!" Incremental slippages on many fronts accumulate to produce a large overall delay. Continued attention to meeting small individual milestones is required at each level of management. To make a user-friendly system, the system must have conceptual integrity, which can only be achieved by separating architecture from implementation. A single chief architect, acting on the user's behalf, decides what goes in the system and what stays out; the architect or team of architects should develop an idea of what the system should do and make sure that this vision is understood by the rest of the team. A novel idea by someone may not be included if it does not fit seamlessly with the overall system design.
In fact, to ensure a user-friendly system, a system may deliberately provide fewer features than it is capable of. The point being, if a system is too complicated to use, many features will go unused because no one has time to learn them; the chief architect produces a manual of system specifications. It should describe the external specifications of the system in detail, i.e. everything that the user sees. The manual should be altered as feedback comes in from the users; when designing a new kind of system, a team will design a throw-away system. This system acts as a "pilot plan" that reveals techniques that will subsequently cause a complete redesign of the system; this second, smarter system should be the one delivered to the customer, since delivery of the pilot system would cause nothing but agony to the customer, ruin the system's reputation and maybe the company. Every project manager should create a small core set of formal documents defining the project objectives, how they are to be achieved, going to achieve them, when they are going to be achieved, how much
The Unix philosophy, originated by Ken Thompson, is a set of cultural norms and philosophical approaches to minimalist, modular software development. It is based on the experience of leading developers of the Unix operating system. Early Unix developers were important in bringing the concepts of modularity and reusability into software engineering practice, spawning a "software tools" movement. Over time, the leading developers of Unix established a set of cultural norms for developing software, norms which became as important and influential as the technology of Unix itself; the Unix philosophy emphasizes building simple, clear and extensible code that can be maintained and repurposed by developers other than its creators. The Unix philosophy favors composability as opposed to monolithic design; the UNIX philosophy is documented by Doug McIlroy in the Bell System Technical Journal from 1978: Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input. Design and build software operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them. Use tools in preference to unskilled help to lighten a programming task if you have to detour to build the tools and expect to throw some of them out after you've finished using them, it was summarized by Peter H. Salus in A Quarter-Century of Unix: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because, a universal interface. In their award-winning Unix paper of 1974, Ritchie and Thompson quote the following design considerations: Make it easy to write and run programs. Interactive use instead of batch processing. Economy and elegance of design due to size constraints.
Self-supporting system: all Unix software is maintained under Unix. The whole philosophy of UNIX seems to stay out of assembler. In their preface to the 1984 book, The UNIX Programming Environment, Brian Kernighan and Rob Pike, both from Bell Labs, give a brief description of the Unix design and the Unix philosophy: Even though the UNIX system introduces a number of innovative programs and techniques, no single program or idea makes it work well. Instead, what makes it effective is the approach to programming, a philosophy of using the computer. Although that philosophy can't be written down in a single sentence, at its heart is the idea that the power of a system comes more from the relationships among programs than from the programs themselves. Many UNIX programs do quite trivial things in isolation, combined with other programs, become general and useful tools; the authors further write that their goal for this book is "to communicate the UNIX programming philosophy." In October 1984, Brian Kernighan and Rob Pike published a paper called Program Design in the UNIX Environment.
In this paper, they criticize the accretion of program options and features found in some newer Unix systems such as 4.2BSD and System V, explain the Unix philosophy of software tools, each performing one general function: Much of the power of the UNIX operating system comes from a style of program design that makes programs easy to use and, more important, easy to combine with other programs. This style has been called the use of software tools, depends more on how the programs fit into the programming environment and how they can be used with other programs than on how they are designed internally; this style was based on the use of tools: using programs separately or in combination to get a job done, rather than doing it by hand, by monolithic self-sufficient subsystems, or by special-purpose, one-time programs. The authors contrast Unix tools such as cat, with larger program suites used by other systems; the design of cat is typical of most UNIX programs: it implements one simple but general function that can be used in many different applications.
Other commands are used for other functions. For example, there are separate commands for file system tasks like renaming files, deleting them, or telling how big they are. Other systems instead lump these into a single "file system" command with an internal structure and command language of its own; that approach is not worse or better, but it is against the UNIX philosophy. McIlroy head of the Bell Labs Computing Sciences Research Center, inventor of the Unix pipe, summarized the Unix philosophy as follows: This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because, a universal interface. Beyond these statements, he has emphasized simplicity and minimalism in Unix programming: The notion of "intricate and beautiful complexities" is an oxymoron. Unix programmers vie with each other for "simple and beautiful" honors — a point that's implicit in these rules, but is well worth making overt. Conversely, McIlroy has criticized modern Linux as having software bloat, remarking that, "adoring admirers have fed Linux goodies to a disheartening state of obesity."
He contrasts this with the earlier approach taken at Bell Labs when developing and revising Research Unix: Everything was small... and my heart sinks for Linux when I see the size of it. The manual page, which re
Frederick Phillips "Fred" Brooks Jr. is an American computer architect, software engineer, computer scientist, best known for managing the development of IBM's System/360 family of computers and the OS/360 software support package later writing candidly about the process in his seminal book The Mythical Man-Month. Brooks has received many awards, including the National Medal of Technology in 1985 and the Turing Award in 1999. Born in Durham, North Carolina, he attended Duke University, graduating in 1953 with a Bachelor of Science degree in Physics, he received a Ph. D. in Applied Mathematics from Harvard University in 1956, supervised by Howard Aiken. Brooks served as the graduate teaching assistant for Ken Iverson at Harvard's graduate program in "automatic data processing", the first such program in the world. Brooks joined IBM in 1956, working in Poughkeepsie, New York, Yorktown, New York, he worked on the architecture of the IBM 7030 Stretch, a $10 million scientific supercomputer of which nine were sold, the IBM 7950 Harvest computer for the National Security Agency.
Subsequently, he became manager for the development of the IBM System/360 family of computers and the OS/360 software package. During this time he coined the term "computer architecture". In 1964, Brooks accepted an invitation to come to the University of North Carolina at Chapel Hill and founded the University's computer science department, he chaired it for 20 years. As of 2013 he was still engaged in active research there in virtual environments and scientific visualization. A few years after leaving IBM he wrote The Mythical Man-Month; the seed for the book was planted by IBM's then-CEO Thomas Watson Jr. who asked in Brooks's exit interview why it was so much harder to manage software projects than hardware projects. In this book Brooks made the now-famous statement: "Adding manpower to a late software project makes it later." This has since come to be known as Brooks's law. In addition to The Mythical Man-Month, Brooks is known for the paper No Silver Bullet – Essence and Accident in Software Engineering.
In 2004 in a talk at the Computer History Museum and in a 2010 interview in Wired magazine, Brooks was asked "What do you consider your greatest technological achievement?" Brooks responded, "The most important single decision I made was to change the IBM 360 series from a 6-bit byte to an 8-bit byte, thereby enabling the use of lowercase letters. That change propagated everywhere."A "20th anniversary" edition of The Mythical Man-Month with four additional chapters was published in 1995. As well as The Mythical Man-Month, Brooks has authored or co-authored many books and peer reviewed papers including Automatic Data Processing, "No Silver Bullet", Computer Architecture, The Design of Design, his contributions to human–computer interaction are described in Ben Shneiderman's HCI pioneers website. Brooks has served on a number of US national committees. Defense Science Board Member, Artificial Intelligence Task Force Chairman, Military Software Task Force Member, Computers in Simulation and Training Task Force National Science Board In chronological order: In January 2005 he gave the Turing Lecture on the subject of "Collaboration and Telecollaboration in Design".
In 1994 he was inducted as a Fellow of the Association for Computing Machinery. Brooks is an evangelical Christian, active with InterVarsity Christian Fellowship. Brooks named his eldest son after Kenneth E. Iverson. Media related to Fred Brooks at Wikimedia Commons Quotations related to Fred Brooks at Wikiquote