The IBM 370 Programming Environment
This lecture is a “trip down
memory lane”, designed to explain the software
development environment in which the IBM 360 and OS/360 were developed.
The IBM 360 is the immediate
predecessor of the IBM 370, which itself is
the indirect predecessor of every existing IBM Mainframe computer.
There are many factors that can
be seen implicitly in the design of
the assembly language. It is helpful to point these out.
We begin with the structure of
typical I/O devices:
punched card readers,
punched card punches, and
We continue with a discussion
of the “label rich” environment associated
with a typical assembly language program and show tricks to make that more structured.
We then shall discuss the
original structured programming movement and its
origins in the development of OS/360 – the operating system for the IBM 360.
When the IBM 360 was first
designed, most data input was from 80–column
punched cards. IBM experimented with other formats, but they never caught on.
Here is the picture of a
typical 80–column punched card.
It has 12 rows, ten rows labeled 0 – 9, and two unlabeled rows at the top.
Punched Cards (Part 2)
Here is a card with column
markings appropriate for FORTRAN programs.
Again, it has 12 rows, ten of which are labeled.
Note the division of columns
into fields appropriate for the language
Columns 1 – 5: Either a “C” for comment or a five digit statement label
Column 6: Any nonblank character to indicate a continuation card
Columns 7 – 72: The FORTRAN statement
Columns 73 – 80: The card’s collating sequence.
A Few Notes on Assembler and FORTRAN
Though distinctly different
languages, Mainframe Assembler and
FORTRAN (developed by IBM in the 1950’s) share a common heritage.
1. Each programming language statement is expected to be one line
Multiple–line statements must be indicated by a continuation character.
For FORTRAN, any nonblank character in column 6 indicates
present line is a continuation of the previous line of code, on the previous card.
For Mainframe Assembler, any nonblank character in column 72
that the next line is a continuation of the present line.
2. The FORTRAN cards have an eight–digit sequence number in columns
73 – 80.
These were optionally used to identify the program and the card’s
position in that program.
If the card deck was dropped, the cards could be placed in a
card sorter and restored to the proper order.
3. Occasionally, the text printed on the top line of the card did
accurately the punch codes in the 12 rows of the card.
This could cause significant problems in debugging a program.
The IBM 029 Key Punch
Here is a picture of the device used to produce punched data cards.
The card feed was at the right.
The card moved right–to–left as it was punched.
The punched cards were stored in a tray at the top left.
IBM 029 Punch Card Codes
Here is a card punched with
each of the 64 characters available under this format.
Note the lack of lower case letters; the IBM Mainframe assembler reflects this.
The codes are given by rows: A
is 12–1, K is 11–2, S is 0–2, etc.
Digits were punched in a single row: the row is the number.
Back to EBCDIC
Consider the IBM 029 punch codes and compare them to the EBCDIC.
Punch Card Codes
0 through 9
F0 through F9
0 through 9
A through I
C1 through C9
12–1 through 12–9
J through R
D1 through D9
11–1 through 11–9
S through Z
E2 through E9
0–2 through 0–9
This table explains the design of the EBCDIC system.
1. IBM chose this
design for ease in processing input
from existing devices, such as the IBM 029 key punch.
2. The gaps in the
EBCDIC system: no character from the 64 character set
has a non–decimal digit as its second digit.
Cards did not have rows marked A, B, C, D, E, or F.
Fields, Records, and Files
Given our discussion of punched
cards, the section “Fields, Records, and Files” on
page 18 of the textbook comes into better focus.
The preferred 80–character form
of a record reflects immediately the
heritage from 80–column punched data cards as input.
The IBM terminology here is rather standard.
A file is seen as a collection of related records, preferably records of the same kind.
A record is a collection of one
or more related fields.
There is no requirement for the fields to represent the same kind of data.
Some fields may be character data, some numeric data, and some structured data.
A field containing structured data might contain subfields. A date field should contain the month, day, and year as subfields.
NOTE: The sample record in Figure 2–1 on page 18 must have been created
the days before relational databases.
The modern practice would be to split this into two records in different tables.
1. The customer ID, customer name, and customer address
2. The customer ID and customer balance.
Common Output Formats
There are two common data
formats seen in the time of the IBM 370.
These are 80 column and 132 column outputs.
Quite often, the first
character output would be used to control the print device.
For this reason, an 80 column output might have 81 characters, etc.
The 80–column output was used
by devices such as the console printer,
a modified teletype device.
The 132–column output was used by devices such as a line printer.
The device at left is an IBM 1403 line printer.
It used a print chain to print 132 column output.
As the output involved
mechanical action of the print
chain, the device produced a very audible sound as it printed.
One popular hobby of the
computer geeks was to devise
output sequences that would cause the printer to play music.
A sample: Raindrops Keep Falling On My Head.
Page printers and laser printers date from much later.
Fixed Format Statements
Unlike the free–format modern programming languages, the early languages such as FORTRAN and Mainframe assembler had a fixed format.
A fixed format simplifies the design of the compiler and/or assembler.
Here is the format suggested for Mainframe Assembler.
Columns 1 – 8: Statement label.
If column 1 contains an “*”, the line is a comment.
Column 9: Blank. This contains nothing.
Columns 10 – 14: The assembly language operation.
This must be followed by at least one blank position.
Columns 16 – 71: The operand or operands.
The count of operands depends on the operation.
Multiple operands are separated by commas with no spaces.
The first blank not in quotes
following the operand list
begins an in–line comment that follows the instruction
Column 72: Continuation character; the next line continues this one.
Older assembly languages, such
as IBM Mainframe Assembler, require the use of
a large number of statement labels.
This requirement is due to the
lack of higher–level structures, such as most looping
constructs, if–then–else constructs, break statements, etc.
On page 46 of the textbook, our
author suggests one strategy for
managing the complexity associated with many labels.
The author suggests a “sort
order” for labels, so that code lines later in
the program have labels that sort after labels for lines that occur earlier.
1. Each program is to be divided into logical sections.
2. The program code
with each section is to be associated with a letter.
Labels for that section begin with that letter.
3. The next two
characters in the label are to be digits, increasing by
intervals of 10: A10, A20, A30, etc.
4. The next 1 to 5
characters are indicated by a name descriptive
of the function performed by this section of code.
Since labels are sequential, they are easier to locate.
The IBM System/360 was developed as a joint hardware/software project.
Along with the “big iron”, IBM
developed also compilers, assemblers,
and an operating system, OS/360. For more details, see the Wikipedia reference.
The OS/360 project quickly got
out of hand. Among the other problems,
was too larger to fit into the limited memory of the smaller System/360 models.
Fred Brooks was the manager for OS/360 development. As a result of his experiences, he formulated Brook’s law: “Adding manpower to a late software project makes it later”. He also coined the slogan “No silver bullet”.
He also wrote the book The Mythical Man–Month: Essays on Software Engineering.
The cover of that book is shown
at left. It depicts prehistoric
creatures becoming trapped in the La Brea tar pit, now within the city of
The term “structured programming” dates from the earliest days of the software engineering movement, some time in the mid 1960’s.
As described in our textbook,
structured programming has a number
of stages that are to be undertaken sequentially.
1. Problem analysis.
Here one defines the problem and discusses the solution with the customer.
2. Data design
For commercial products, this involves considerable design of forms for
the input and output of data. IBM developed a tool, called HIPO, for this.
For COBOL programs, this is the time to lay out the data sections.
3. Logic design
Here the logic of the program is defined. High–level tools should be
used to specify the design before code is written. This is “structured design”.
Here the code is written. In higher–level languages, the constructs used should
be those of structured programming: sequence, repetition, and selection.
Most assembly languages do not support these constructs.
Coupling and Cohesion
The ideas of coupling and cohesion were developed by the structured programming
movement and have persisted into the more modern methods, such as Object–Oriented Analysis and Design.
The ideas here are quite simple: 1. Modules should be highly cohesive, and
2. Any pair of modules should be loosely coupled.
A module with optimal cohesion performs only one function.
A module with acceptable cohesion is a collection of procedures to perform related functions. An example would be a trigonometry package calculating the sine, cosine, and tangent of angles as well as converting between degrees and radians.
A module with incidental cohesion is one containing a random collection of procedures.
Modules with low coupling exchange data only through argument lists or not at all.
Modules with common coupling exchange data through shared global data spaces.
Modules with tight coupling have direct access to each other’s local variables.
The design goal is to have highly cohesive modules with low coupling among them.
Comments and Documentation
Well documented code makes use of a number of tactics.
The most obvious is the use of descriptive names for variables and statement labels.
Judicious use of comments will
greatly improve the readability of the code.
Some comments should be viewed as section headers,
telling what the next section of code does.
Some comments are worthless. Here are two examples
AR 1,2 Add register 2 to register 1
A10 DC F’1827’ RIP LVB
The last example is from a real program. This comment was the only one in the code.
What do you think it signifies?