IBM 1130 User Manual page 219

(1) Job or program name
(2) Operation name
(3) Mac hine setup
(a) Disk cartridge assignment
(b) Input cards or tapes
(c) Output cards or tapes
(d) Carriage tape
(e) Sense switch settings
(4) The sequence of events to run the
test
(5) Listing of all possible messages
and halts
(6) Switch and index listings
(7) List of paper forms or card stock
for auxiliary equipment
i.
Object deck or disk cartridge
j. Blank forms, cards, disks
k. Source deck and listings
12. The test session
a. Plan the test session in advance. De-
cide upon the sequence in which pro-
grams shall be tested. Programs
should take precedence in testing
according to their importance, and the
most important programs should be re-
tested as often as possible until they are
completely debugged. Schedule a work-
load greater than can be accomplished
in the allotted test time. ASSign duties
(such as handling the card reader,
punch, printer, disk cartridges, and
console) to each person attending.
b. Arrive early. Confirm the testing
schedule that was established in advance
of actual testing. This schedule may
best be laid out as a series of half-hour
to full-hour sessions with one- to two-
hour breaks in between.
c. Be familiar with the latest versions of
all programming systems to be used.
d. Make certain that the test packet is
organized properly. Test the higher-
priority and larger programs first.
Each program should have its own input
test data; one program should not be
dependent on another program that was
run earlier in the same session.
e. Make sure that all units are in the
proper initial status--for example,
printer restored, disk units ready, no
leftover cards in the reader or punch.
Section Subsections Page
30
40
I
00 02
f. Debugging at the console is time-
consuming, error-prone, and generally
nonproductive. When the program hangs
up, the following steps should be taken
immediately:
(1) Note the console status--indicators,
lights and registers.
(2) Take core storage dumps.
(3) Take disk dumps.
(4) Go on tonext program or cease
work.
Even if a program goes to end-of-job
and appears correct, the above steps
should be taken in order to simplify
correcting errors discovered later.
When a program hangs up, do not force
it to continue without taking down status
information, since the conditions caus-
ing the original hangup would then be
destroyed.
g. Label all core storage dumps, disk
dumps, console sheets, etc., with date,
time, and program identification.
h. Debug off the console with deliberate
speed. With the above items, there is
more information to aid in locating the
reason for the hangup than is available
at the console. Do not make hurried
corrections to a program in a false
effort to maximize usage of test time.
Do not, however, spend three hours at
a desk to save five minutes on the
system. Strive for a reasonable cost
balance.
Before testing the program again,
find all possible bugs, not just the one
that caused the hang up . Step further
through the program after each test to
ensure that the program will not hang up
on the next instruction or routine.
Correct all errors in output content and
format. Strive for perfect output from
each test.
i. Note all corrections on the program
listing. Corrections that affect the halt,
switch, or index listings should be up-
dated accordingly.
j. Note the reason for the correction
adjacent to the card itself. Be sure to
include number and date. A post-test
listing of cards is desirable for refer-
ence when correcting the source deck.