C20 1690 0_1130_Computing_System_Users_Guide 0 1130 Computing System Users Guide
C20-1690-0_1130_Computing_System_Users_Guide C20-1690-0_1130_Computing_System_Users_Guide
User Manual: C20-1690-0_1130_Computing_System_Users_Guide
Open the PDF directly: View PDF 
.
Page Count: 706
| Download | |
| Open PDF In Browser | View PDF |
C20-1690-0
13 JAN 1970
IBM 1130 Computing System User's Guide
This manual, covering a wide range of subjects that are of interest
to 1130 customer personnel, is designed for insertion in a workbook
along with user-generated materials. It deals with the steps to be
considered in any successful installation program: preinstallation
planning, documenting current applications~Cdesign of new appfications, conversion, program development, testing, and program
documentation.
Additional topics discussed include the 1130 system, the 1130
Monitor, Job Management, Disk Management, Core Management,
File Organization, Disk Data Storage, FORTRAN and the Commercial Subroutine Package, Sorting and System Evaluation - Performance.
It is suggested that the User's Guide be placed in a binder and
that dividers be inserted before the various sections. The resulting
workbook becomes the single major source of installation guidance
when you include your own data processing policies, standards, and
control forms.
IBM 1130 Computing System
This first reprint contains a few minor changes to the original edition, but does not in any
way obsolete the original edition.
Copies of this and other IBM publications can be obtained through IBM branch
offices. Address comments concerning the contents of this publication to:
IBM, Technical Publications Department, 112 East Post Road, White Plains, N.Y. 10601
Section
01
Subsections
Page
I
01
00
00
READER'S GUIDE
INTRODUCTION
This section is intended as a guide to help you get
the most out of this manual. Because of the magnitude of the manual and the differing needs of various
readers, such a guide, or "road map", is particularly important.
For purposes of the guide, readers will be
divided into three groups:
1. Top management, who want an overview of
the system.
2. Data processing management, who have
direct responsibility for the installation and management of the 1130 System.
:3. Programmers and systems analysts, who will
actually set up the system, determine the methods
to be used , and/or code the programs.
Groups 2 and 3 are subdivided into those concerned with "pure" scientific applications, and
those working in a commercial or mixed scientificcommercial atmosphere.
Figure 01.1 shows a general outline of the manual and suggests which sections should be read by
each group. However, the top manager who wants
a more detailed view of the 1130 will find much of
the data processing management material to be
relevant; the data processing manager may want to
read more than Figure 01. 1 indicates; etc.
The effectiveness of this Guide depends entirely
on the responsible manager in your installation.
The Guide contains possible paths to a successful
installation. Since the installation of data processing equipment is a disciplined venture that involves
decisions concerning the selection of the best paths,
your management's responsibility is clearly delineated. This responsibility began with the creation
of realistic objectives. Control is exercised through
timely reviews in which progress is related to
checkpoints and corrective action is undertaken.
A WORD TO TOP MANAGEMENT
Within the last several years, your company may
have increased its plant capacity to meet growing
needs. Before this new resource became fully
operational, though, many things had to be done.
Management was chosen, an organization chart
drawn up, a plan for startup formulated,a date
picked for the start of production, etc.
Just recently you may have added a new product
or scrvice. The introduction of this product or
service involved many considerations. Its need was
studied, its function determined, an announcement
date selected, etc.
In both cases, management:
• Defined its objectives
• Made a plan
• Established checkpoints
• Assigned responsibilities
Timely reviews determined whether your plans
were being followed, your objectives met, etc. On
the basis of these reviews, modifications and adjustments were made to ensure that the operation was a
success.
Now you are adding another resource to your
organization - an IBM 1130 Computing System. As
before, there are many things that you, as management, must do if your 1130 installation is to meet
its planned objectives.
Should the installation of a new data processing
system be any less subject to management control
than a new plant, or a new product? The answer is
no. Data processing capability is a resource, just
like the new plant or new product. In fact, a data
processing system is a unique type of resource; it is
one that extends management's ability to control
other resources.
'
Your 1130 system may be used to maintain a personnel skills inventory or to schedule plant operations. It may be assigned to keep a close watch on
cash flow or to determine reorder points for your
inventory. In each case, data processing is a resource being used to control other resources.
In this light, the IBM 1130 Computing System that
you are about to install should take on an added importance. Objectives, checkpoints, and the mechanics
for review should be established for this resource,
just as for any other resource available to you.
The 1130 Computing System, through its storedprogram power and random access disk capability,
embodies a new technology. The maximum value
will be derived from this technology only if the system is oriented toward your objectives and its installation is closely monitored to see that those
objectives are achieved. It is through this type of
involvement that the philosophies and policies of a
manager can be manifested.
The 1130 User's Guide has been designed with
these thoughts in mind. First, it deals with all the
considerations that lead to a successful installation.
Second, it is so organized as to lend itself to the
control and review process. The cornerstone of
Section
01
Subsections
Page
I
02
00
00
THE READER
Top
Mgmt
THE TOPIC:
Preinstallation Planning
Documenting Current Applications
Preliminary Questions & Answers
Application Design
DP
Mgmt
(CommercialScientific)
DP
Mgmt
(Scientific)
Programmer/
Analyst
(CommercialScientific)
v
v
v
Introduction
Introduction
v
..
Cards vs 0 isk Files
v
Safeguarding Data
v
..
Accounting Controls
v
v
Programmer/
Analyst
(Scientific)
..
..
Forms Design
v
v
Card Design
v
v
.J
.J
..
Disk Design
Introduction
Program Development
Testing Effectively
Introduction
Documentatio n
Introduction
.
.;
v
v
v
v
.J
"
,j
Conversion
,j
The 1130 System
v
.;
v
v
The 1130 Monitor
v
v
v
v
Job Management
v
v
Layout of 0 isk
v
v
"v
I n creasi ng Space
v
v
Disk Util. Prog.
v
v
v
v
v
v
Disk Management
.J
Core Storage Management
FORTRAN
Arithmetic
v
Overlapped I/O
v
v
Character Handling
,j
Core Saving Tips
v
.J
Timing
v
.;
Introduction
Sorting
..
Introduction
Use of the Disk for Data Storage
Disk Organization and Processing
*
Improving Your System - Performance
Figure 01.1
,j
Introduction
v
..
Introduction
Introduction
.;
,j
Read this sectio n
..
May be skipped if you don't have, or are not considering using, the disk for data storage
*
.;
.
.
.
*
.;
.J
Section
01
this organization is an Installation Activity Schedule,
which highlights all the events leading to a successful installation. This is fully described in Section 05.
This Guide should become a working document in
your organization. Although the experience and
specific needs of each organization vary considerably, all the events apply to some extent in every
installation.
A WORD TO DATA PROCESSING MANAGEMENT
In addition to the comments directed toward top
management, several thoughts apply here.
You are the men in the middle - between top
management and the programmer/analyst. For this
reason the sections checked for your attention are
those concerned with how to do things the "right"
way; how to avoid potential pitfalls; how to get the
most out of your 1130 system; etc.
A WORD TO THE PROGRAMMER/ANALYST
As Figure 01.1 shows, this manual is directed primarily toward you; you should read its entire contents. This is especially true for those of you who
are working in a commercial, or mixed, environment.
However, the distinction between a commercial,
or mixed, environment and a "pure" scientific
environment is very tenuous. More and more,
users who once considered themselves "pure"
scientific find their applications taking on aspects
of the traditional commercial job - large data files
are developed, input and output formats become
more critical, alphabetic codes and data are encountered.
Actually, the subjects checked for the "pure"
scientific reader represent a bare minimum. Anyone who is or expects to be in a mixed environment
should read the entire manual.
SUMMARY OF THE USERIS GUIDE
The Installation Phase
The following listing of the material in this Guide
reflects the major grouping of installation events
and should provide an indication of the Guide1s comprehensive nature. Comments have been added to
each listed item to relate the manner in which that
subject matter may be used.
• Preinstallation Planning - provides a proven
method of scheduling and reviewing installation
activities, specifically tailored to the 1130 user,
Subsections
Page
I
03
00
00
and illustrates the points where management review
is most essential.
• Documenting Current Applications - concerns
the control and techniques that can be applied to the
documentation of existing procedures. Distinction
is made between manual operations and those already
mechanized.
• Some Preliminary Questions and Answers
Regarding Data Storage - considers the pros and
cons of using either cards or disk for data storage.
Also considers protecting your data - why and how
it should be protected.
• 1130 Application Design - includes card and
form design, record layouts, and flowcharts. The
elements of application design are made clear
through "live" illustrations, which are used throughout. This section also aids in the selection of the
right job-oriented programming language and thus
contributes to the effectiveness of the whole installation effort.
• Program Development - devotes itself to converting designs for 1130 applications into tested,
debugged machine programs. The application discussed throughout the Guide is provided to serve as
a teaching aid and time saver for the programmer.
Programming hints and aids are also provided.
• Testing Effectively - shows the methods an
installation should use in testing individual programs
and complete systems.
• Program Documentation - shows how a good
set of working documents, which a computer installation must develop, can be created during the
development phases.
• Conversion - outlines the procedures required
to perform the cutover from your present system to
the 1130.
The Operations Phase
This portion of the Guide contains several sections
of interest to users who have completed the installation phase:
• 1130 Computing System - contains a comprehensive description of the 1130 System and a brief
description of each component.
• 1130 Disk Monitor System - discusses the
1130 Monitor in general and leads into the more
detailed material of the next three sections.
• Job Management - covers those features of
the Monitor that help you manage the job, or unit of
work.
• Disk Management - describes the layout of
disk storage, how you may use it, and how to get
the most out of it.
Section
01
Subsections
Page
I
04
00
00
• Core Storage Management - outlines the
facilities the Monitor gives you to manage core
storage with the LOCAL, SOCAL and LINK overlay
systems.
• FORTRAN - General and Commercial covers many aspects of FORTRAN that are of interest to all users, but with special emphasis on the
needs of commercial programmers. Use of the
Commercial Subroutine Package, arithmetic considerations, and core-saving tips are among the major
topics covered.
• Sorting with Your 1130 - describes the sorting process and some alternate approaches.
• Use of the Disk for Data Storage - describes
the way data is situated on the disk, and stresses
efficiency.
• Disk Data Files - Organization and Processing - continues the previous topic, discussing the
various file organization techniques and how the
processing sequence affects the choice of organiation.
• Improving Your System - Performance covers performance and how it is affected by (1) the
Monitor, (2) the programmer, and (3) the 1130
itself. Three case studies are presented to illustrate various approaches to improving throughput rates and run times.
Section
02
Subsections
Page
I
01
00
00
CONTENTS
Section 01: Reader's Guide
Section 02: Table of Contents
Section 05: Preinstallation Planning
Section Contents. . . . . . . . . . . . . . . . . . . ..
Introduction. . . . . . . . . . . . . . . . . . . . . . . ..
General Planning. . . . . . . . . . . . . . . . . . ..
Application and Conversion Planning. ..
Programming Planning. . . . . . . . . . . . . ..
05. 00. 00
05.01.00
05.10.00
05.20.00
05.30.00
Section 10: Documenting Current
Applications
Section Contents. . . . . . . . . . . . . . . . . . . ..
Introduction. . . . . . . . . . . . . . . . . . . . . . . ..
Documentation of Manual Systems. . . ..
Documentation of Punched Card
Systems. . . . . . . . . . . . . . . . . . . . . . . . . . ..
Accounting Controls .................
Survey Questionnaires ...............
Billing. . . . . . . . . . . . . . . . . . . . . . . . . . ..
Accounts Receivable. . . . . . . . . . . . . . ..
Sales Analysis. . . . . . . . . . . . . . . . . . . ..
Inventory. . . . . . . . . . . . . . . . . . . . . . . . ..
Accounts Payable ..................
Payroll ...........................
Manual System Documentation ExamplePayroll. .. . . . . . . . . . . . . . . . . . . . . . . . . ..
Introduction .......................
Job Description. . . . . . . . . . . . . . . . . . ..
Survey Form ......................
Sample Documents .................
Systems Flowchart. . . . . . . . . . . . . . . ..
10.50.00
10. 50. 01
10.50.10
10.50.20
10.50.30
10.50.40
Section 15: Some Preliminary Questions
and Answers Regarding
Data Storage
Section Contents. . . . . . . . . . . .. . . . . . . ..
Introduction. . . . . . . . . . . . . . . . . . . . . . . ..
Data -- On Disk or Cards? ...........
General Considerations. . . . . . . . . . . ..
Flexibility in Order of Processing ...
Jobs Involving More than One File ...
Frequency of Changes to Your File. ..
Need for Inquiry into Your File. . . . ..
Size of Your Data File. . . . . . . . . . . . ..
Your Backup Requirements. . . . . . . . ..
Record Size .......................
Other Considerations.......... .....
Summary. .... .. ......... . .........
15.00.00
15.01. 00
15.10.00
15.10.01
15.10.10
15.10.20
15.10.30
15.10.40
15.10.50
15.10.60
15.10.70
15.10.80
15.10.90
10. 00. 00
10. 01. 00
10.10.00
10.20.00
10.30.00
10.40.00
10.40.10
10.40.20
10.40.30
10. 40. 40
10.40.50
10.40.60
How to Safeguard Your Disk Data
Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..
Introduction. . . . . . . . . . . . . . . . . . . . . . . ..
Know Your Data ......................
Know What Can Happen to Your Data. . ..
Design an Accident-Insensitive
System.. . . . . . . . . . . . . .. . . . .. . . . . . . ..
Detect Errors Before They Do
Damage ............................
Plan Modest-Size, Modular
Programs ..........................
Always Back Up Your Disk Files with
a Duplicate Copy ....................
Provide Tested and Documented
Recovery Procedures. . . . . . . . . . . . . . ..
Section 20: 1130 Application Design
Section Contents. . . . . . . . . . . . . . . . . . . ..
Introduction. . . . . . . . . . . . . . . . . . . . . . . ..
Accounting Controls .................
Review of Accounting Control
Principles. . . . . . . . . . . . . . . . . . . . . . . ..
More Specific Suggestions for
Document and Accounting Controls. ..
Form Design. . . . . . . . . . . . . . . . . . . . . . ..
1130 Considerations. . . . . . . . . . . . . . ..
Form Design Principles ............
Card Design ................... o'....
1130 Considerations. . . . . . . . . . . . . . ..
Card Design Principles. .. . . . . . . . . ..
Design of Disk Data Files ............
Introduction .......................
Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . ..
Field Size. . . . . . . . . . . . . . . . . . . . . . . ..
Data Sequence .....................
File Organization ..................
Record Format and Blocking. . .. .. ..
File Processing. . .. . . . . . . . . . . . . . . ..
File Control. . . . . . . . . . . . . . . . . . . . . ..
Payroll Example ....................
Narrative .........................
Card Forms and Console Keyboard
Input. . .. . . . . . . . . . . . . . . . . . . . . . . . . ..
Console Printer and Line Printer
Forms for Output. .. . .. . . . .. . . .. ...
Disk Record Formats ..............
System Flowchart. . . . . . . . . . . . . .. . ..
Language Selection ..................
Introduction .......................
Programming Languages. . . . . . . . . . ..
15.20.00
15.20.01
15.20.10
15.20.20
15.20.30
15.20.40
15.20.50
15.20.60
15.20.70
20.00.00
20.01. 00
20.10.00
20.10.10
20.10.20
20. 20. 00
20.20.10
20.20.20
20.30.00
20.30.10
20.30.20
20.40.00
20.40.01
20.40.10
20.40.20
20.40.30
20.40.40
20.40.50
20.40.60
20.40.70
20.50.00
20.50.10
20.50.20
20.50.30
20.50.40
20.50.50
20.60.00
20.60.01
20. 60. 10
Section
02
Subsections
Page
J
02
00
00
Application Programs ............. .
Which Programming Language or
Application Program Should You
Use? ............................ .
Section 25: Program Development
Section Contents .................... .
Introduction ....................... .
Programming and Documentation
Standards ......................... .
Program Change Authorization ...... .
Programming Aids ................. .
Documenting Variable Usage ....... .
Modular Programming ............ .
Programming Examples .•...........
Introduction ...................... .
Example 1: File Creation ......... .
Example 2: Add Name to the File .. .
Example 3: Changes to the File .... .
Example 4: Calculations and
Payroll Register ....•..............
Example 5: Check Writing ......... .
Example 6: Check Register ........ .
Example 7: 941 Report. ........... .
Section 30: Testing Effectively
Section Contents ................... .
Introduction ....................... .
Testing Strategy ................... .
Testing Tactics .................... .
Testing Hints ..•....................
Summary .......................... .
Section 35: Program Documentation
Section Contents .................... .
Introduction ........................ .
Installation Manuals ................ .
Program Information Manual ....... .
Operation Manual ................. .
Documentation Examples ............ .
Payroll System -- Program
Information Manual .............•..
Payroll System -- Operation
Manual ........................... .
20.60.20
20.60.30
25.00.00
25.01. 00
25.10.00
25.20.00
25.30.00
25.30.10
25.30.20
25.40.00
25.40.01
25.40.10
25.40.20
25.40.30
25.40.40
25.40.50
25.40.60
25.40.70
30.00.00
30.01. 00
30.10.00
30.20.00
30.30.00
30.40.00
35.00.00
35.01. 00
35.10.00
35.10.10
35.10.20
35.20.00
35.20.10
35.20.20
Section 40: Conversion
Section Contents ................... .
Introduction ....................... .
Planning for Conversion ............ .
Preparing for Conversion ........... .
Conversion Methods .
40.00.00
40.01.00
40.10.00
40.20.00
40.30.00
Section 45: 1130 Computing System
Section Contents ....................
Introduction ........................
45.00.00
45. 01. 00
0
•••••••••••••••
The 1131 CPU ...................... .
Console Printer and Keyboard ..... .
Data Switches .................... .
Console Display Lamps ........... .
Disk Storage ....................... .
Printers .......................... ,.
Card Readers and Punches .......... .
Paper Tape Readers and Punches .... .
Plotter ............................ .
Graphic Display .................... .
Optical Readers .................... .
Storage Access Channel ............ .
Teleprocessing .................... .
The 1130 Configurator .............. .
45.05.00
45.05.10
45.05.20
45.05.30
45.10.00
45.15.00
45.20.00
45.25.00
45.30.00
45.35.00
45.40.00
45.45.00
45.50.00
45.55.00
Section 50: 1130 Disk Monitor System
General.................. . .........
50.01.00
Section 55: The Monitor - Job Management
Section Contents .................... 55.00.00
Introduction ....................... . 55.01.00
Job and Subjob ...... " ............. . 55.10.00
Stacked Jobs or the Input Stream ..... . 55.20.00
Disk Cartridge ID Checking ......... . 55.30.00
Section 60: The Monitor - Disk Management
Section Contents .................... 60.00.00
Introduction ....................... . 60.01. 00
Disk Storage Layout ................ . 60.10.00
Introduction ........... " ......... . 60.10.01
Cylinder 0 ....................... . 60.10.10
IBM Systems Area ................ . 60.10.20
Working Storage (WS) ............. . 60.10.30
User Area (UA) .................. . 60.10.40
Fixed Area (FX) .................. . 60.10.50
Summary ......................... . 60.10.60
Increasing the Amount of Space Available to the User .................... . 60.20.00
Introduction ...................... . 60.20.01
How Much Room Do I Have? ....... . 60.20.10
How Can I Make More Space
Available? ....................... . 60.20.20
Summary ......................... . 60.20.30
The Disk Utility Program ........... . 60.30.00
Introduction ...................... . 60.30.01
Format of Material on the Disk .... . 60.30.10
The Most Commonly Used DUP
Functions ........................ . 60.30.20
Special Options -- Multiple Disk
1130 Users ....................... . 60.30.30
Section 65: The Monitor-Core Storage Management
Section Contents. . . . . . . . . . . . . . . . . . . .. 65. 00. 00
Introduction ........................ 65. 01. 00
Section
02
The Logical Layout of Core Storage. ..
Basic ............................ .
Flipper ...............•....•......
SOCAL Area ..................... .
LOCAL Area ..................... .
Program or LINK Area ........... .
COMMON Area ................... .
Unused Area ..................... .
Summary .......................... .
Section 70: 1130 FORTRAN and the
Commercial Subroutines
Section Contents ................... .
Introduction ....................... .
Arithmetic Considerations ...•.......
General .......................... .
Integer Mode ...........•..........
Real Mode ....................... .
Decimal Mode .................... .
Summary ........................ .
Overlapped Input/Output ............ .
Introduction ....•..................
The Commerical Subroutine Package
Overlapped I/O Subroutine ......... .
Using the Overlapped I/O System ... .
The Interaction of Arithmetic and 1/0 ..
Character Handling Techniques ...... .
General .......................... .
Code Conversion ................. .
Other Character Handling
Techniques ....................... .
FOR TRAN Core Saving Tips ........ .
General .......................... .
Reducing Program Size ............ .
Reducing Subroutine Requirements .. .
FOR TRAN Execution Times ......... .
Processing ...................... .
Summary and Conclusion .......... .
Section 75: Sorting with Your 1130
Section Contents ................... .
Introduction ....................... .
Some Preliminary Information ...... .
Alternate Approaches ............... .
Use of File Organization .......... .
Sorting Offline .......•.............
Methods of Sorting ................ .
Introduction ..............•........
Internal Sorting Methods ........... .
External Sorting Methods .......... .
A Detailed Look at an 1130 Record
Sort .............................. .
Summary .......................... .
65.10.00
65.10.10
65.10.20
65.10.30
65.10.40
65.10.50
65.10.60
65.10.70
65.20.00
70.00.00
70.01. 00
70.10.00
70.10.01
70.10.10
70.10.20
70.10.30
70.10.40
70.20.00
70.20.01
70.20.10
70.20.20
70.30.00
70.40.00
70.40.01
70.40.10
70.40.20
70.50.00
70.50.01
70.50.10
70.50.20
70.60.00
70.60.10
70.60.20
75.00.00
75.01. 00
75.10.00
75.20.00
75.20.10
75.20.20
75.30.00
75.30.01
75.30.10
75.30.20
75.40.00
75.50.00
Subsections
00
I
Section 80: Use of the Disk for Data
Storage
Section Contents ................... .
General .. , ........................ .
The Physical, or Hardware,
Structure of the Disk ............... .
The Disk As Seen by the FORTRAN
Programmer •......................
The Interrelationship of the Physical
and Logical Structures .............. .
The DE FINE FILE Statement ...... .
The *STOREDATA and *FILES
Cards ........................... .
Record Lengths and Sector
Utilization ......................... .
A Trick to Get Long Records and/or
Better Packing ................... .
Computing Record Length ........... .
Shortening Record Length ........... .
Some Examples of Disk File Layout .. .
Example 1 ..........•.............
Example 2 ..........•.............
Example 3 ..........•..•..........
Section 85: Disk Data Files -Organization and Processing
Section Contents .........•..........
General ........................... .
Organization ........•....•......
General .......................... .
Pure Sequential .......•.......•...
Indexed Sequential ................ .
Direct, or Random, Organizations .. .
Processing ..............•..........
The Interaction of Organization and
Processing ........................ .
Introduction ............•..........
Choosing the Organization ......... .
0
•••
Section 90: Improving Your System -Performance
Section Contents ................... .
General ........................... .
The Role of the Monitor ............ .
General ...........•...............
The Effect of the Monitor on
Performance .•........•...........
The Role of the Programmer ........ .
Planning for Performance ......... .
Organizing for Performance -How to Use LOCAL's ............. .
Programming for Performance .... .
The Role of the 1130 Hardware ..•....
00
Page
03
80.00.00
80.01. 00
80.10.00
80.20.00
80.30.00
80.30.10
80.30.20
80.40.00
80.40.10
80.50.00
80.60.00
80.70.00
80.70.10
80.70.20
80.70.30
85.00.00
85001. 00
85.10.00
85.10.01
85.10.10
85.10.20
85.10.30
85.20.00
85.30.00
85.30.00
85.30.10
90.00.00
90.01.00
90.10.00
90.10.01
90.10.10
90.20.00
90.20.10
90.20.20
90.20.30
90.30.00
Section
02
Subsections
Page
I
04
00
00
General ..........................
Productive Time That Cannot Be
Improved by Hardware Changes
Productive Time That Can Be
Improved by Hardware Changes
Nonproductive Time That Can Be
Reduced by Hardware Changes ......
90.30.01
90.30.10
90.30.20
90.30.30
Some Case Studies of Performance
Improvements .....•................
General .......•...................
Case I .......................... .
Case II .......................... .
Case III ..........•...............
Summary ........................ .
90.40.00
90.40.01
90.40.10
90.40.20
90.40.30
90.40.40
Section
05
Section 05: PREINSTALLATION PLANNING
CONTENTS
Introduction ....••.•..•.•.•••••••.••.
General Planning ...........•........
Application and Conversion Planning .. .
Programming Planning .............. .
05.01. 00
05.10.00
05.20.00
05.30.00
Subsections
Page
I
01
00
00
Section
05
INTRODUCTION
Now that your 1130 computing system is on order,
what should you do next? When the 1130 computing
system was proposed, mention was made that it
could perform both scientific and commercial jobs.
Some typical commercial jobs that may have been
considered at that time are:
• Payroll (used as an example later in the
manual) and labor distribution
• Accounts receivable
• Accounts payable
• Sales analysis
• Inventory control
Planning the use of the 1130 for specific applications such as the above leads to other questions that
Subsections
Page
I
01
01
00
need answers. How will the personnel for your
installation be selected? When will your applications be implemented on the 1130? How will this
job of implementation be carried to completion? In
other words, you need a plan to carry out the installation of this new system.
In answer to the first question, selection of
personnel, your IBM representative can supply you
with the Programmer's Aptitude Test, which will
help you with some of the selection. (It may be that
you will find these people in your company, but you
may also find it necessary to hire someone outside.)
The second and third questions, when will the
implementation be done and how, may be answered
by your general (installation) plan, which is discussed next.
Section
05
Subsections
Page
I
01
10
00
GENERAL PLANNING
The General Installation Plan is made up of two
items: the Activity List (Figure 05.1) and the
Activity Time Estimates (Figure 05.2)
Your Activity List contains the major areas of
concentration. It answers the questions "who" and
"what". Your Activity Time Estimates answers
the question "when". However, you still do not
have enough detail.
Before going into more detail, go back and be
sure the two lists are fully understood.
The Activity List contains the major installation
activities you need to complete a successful installation. The first two areas, Installation Organization and Document Current Processes, although not
end products, are most important. They are the
foundation of your installation. The remaining
items on the list are:
• Application Design
• Operations Planning
• Physical Planning
• Conversion and Applications Complete
• Evaluation
These will go smoothly if you ensure that the
first two areas are complete.
Your Activity Time Estimates makes this point
clear; notice that the early parts of your installation
efforts, as mentioned previously, must all have
start dates. If your foundation is firm and on
schedule, the later installation activities will also
be smooth and on schedule.
The later installation activities require more
detail. You may find these items helpful in planning
applications other than those listed.
GENERAL INSTALLATION PLAN
ACTIVITY LIST
Installation Organization
Select personnel:
Management
Programmers
Operators
Education
Train management
Train programmers
Train operators
Document Current Processes
Document current:
Payroll and labor distribution procedures
Accounts receivable procedures
Accounts payable procedures
Sales analysis procedures
I nventory control procedures
Determine 1130 documentation standards
Schedule application development and conversion
Management review
Application Design
Application development:
Payroll and labor distribution
Accounts receivable
Accounts payable
Sales analysis
I nventory control
Convert:
Payroll files
Accounts receivable files
Accounts payable files
I nventory files
Operation Planning
Establish operating schedules and procedures
Physical Planning
Physical layout
Management review
Order cables
Physical alterations
System Delivered
Conversion and Applications Complete
Entire Systems Evaluation
Figure 05. 1.
Section
05
Subsections
10
I
00
APPLICATION DEVELOPMENT PLAN
ACTIVITY TIME ESTIMATES
Activity
Figure 05.2.
Duration
in
Weeks
"Must"
Start (5) or
Finish IF)
Date
Original Schedule
Dates
Start
Finish
Revised
Dates # 1
Start
Finish
Revised
Dates # 2
Start
Finish
Page
02
Section
05
Subsections
Page
I
01
20
00
APPLICA TION AND CONVERSION PLANNING
Figure 05.3 is the Activity List for your Application Development Plan. This corresponds to the
Activity List for your General Installation Plan.
Similarly, Figure 05.4 is the Activity Time Estimates for your Application Development Plan.
The Application Development Plan is, in general,
composed of three items:
1. Analysis
a. Review of present system
b. Designing reports and card layouts
c. Flowcharting
2. Evaluation
a. Establishinent of controls
b. Management review
3. Programming of the application
The most important steps in this process are,
once more, the earliest: Analysis and Evaluation.
If these items are complete, that is, if the individuals and groups involved agree with what you
propose, the remainder of the installation effort
will be relatively free from serious problems.
Figures 05.5 and 05.6 are, respectively, the
Activity List and Activity Time Estimates for the
Conversion Plan.
Notice that the discussion of the Application
Development Plan so far has not included programming. The question, how will the programming be
carried to completion, will be discussed next.
Section
05
Subsections
Page
I
02
20
00
APPLICATION DEVELOPMENT PLAN
ACTIVITY LIST
For each application:
Review present system
Design reports and card layouts
Flowchart
Establish controls
Management review
*Program development
*Further detail
Figure 05.3.
APPLICATION DEVELOPMENT PLAN
ACTIVITY TIME ESTIMATES
Activity
Payroll and Labor
Distribution
Review present system
Design reports and
card layouts
Flowchart
Establish controls
Management review
*Program development
Accounts Receivable
Review present system
Design reports and
card layouts
Flowchart
Establish controls
Management review
*Program development
Accounts Payable
Review present system
Design reports and
card layouts
Flowchart
Establish controls
Management review
*Program development
Sales Analysis
Review present system
Design reports and
card layouts
Flowchart
Establish controls
Management review
*Program development
I nventory Control
Review present system
Design reports and
card layouts
Flowchart
Establish controls
Management review
*Program development
* Further detail (Figure 05.8)
Figure 05.4.
Duration
in
Weeks
2.0
2.0
1.5
1.0
1.0
7.0
1.5
2.0
1.0
1.5
1.0
5.0
.5
2.0
1.0
.5
1.0
6.0
1.0
1.0
1.0
.5
1.0
4.0
1.0
2.0
2.0
.5
1.0
7.0
"Must"
Start (S) or
Finish (F)
Date
Original Schedule
Dates
Start
Finish
Revised
Dates # 1
Start
Finish
Revised
Dates #2
Start
Finish
Section
05
Subsections
Page
I
03
20
00
CONVERSION PLAN
ACTIVITY LIST
For each application (where applicable):
Develop conversion procedures
Train conversion personnel
Convert files
Parallel or pilot run
Train other departments
Figure 05.5
CONVERSION PLAN
ACTIVITY TIME ESTIMATES
Activity
Develop data preparation and
card punching procedures
Develop conversion control
plans and procedures
Train conversion personnel
Convert payroll and labor
distribution files
Convert accounts receivable
files
Convert accounts payable files
Convert inventory files
Train other departments -ali applications
Parallel runs -- payroll and
labor distribution
Parallel runs -- accounts
receivable
Parallel runs -- accounts
payable
Parallel runs -- inventory
control
TOTAL CONVERSION
Figure 05.6.
Duration
in
Weeks
"Must"
Start (S) or
Finish (F)
Date
1.0
1.0
2.0
2.0
4.0
4.0
6.0
4.0
4.0
4.0
4.0
2.0
10.0
(F) - 4/8/68
Original Schedule
Dates
Start
Finish
Revised
Dates # 1
Start
Finish
Revised
Dates # 2
Start
Finish
Section
05
Subsections
30
PROGRAMMING PLANNING
The Activity List and Activity Time Estimates for
the Program Development Plan (Figures 05.7 and
05.8 respectively) complete the planning.
This is the detailed level of planning on which
your installation depends. For this reason you must
have control over the progress of these activities.
The Progress Charts for Program Development
(Figure 05.9) will provide the necessary control.
Used in conjunction with the Activity Time Estimates for the Program Development Plan, these
charts show you, at all times, the progress of
your installation effort. You can determine whether
it is ahead of schedule, on schedule, or behind
schedule and requiring action.
PROGRAM DEVELOPMENT PLAN
ACTIVITY LIST
For each application:
Define program
Flowchart
Code
Desk-check and list
Prepare test data
Test
Production test
Complete program documentation
Figure 05. 7.
I
00
Page
01
Section
05
Subsections
Page
I
02
30
00
PROGRAM DEVELOPMENT PLAN
ACTIVITY TIME ESTIMATES
Activity
Define PAY 01 (Payroll)
Flowchart PAY 01
Code PAY 01
Desk-check, list PAY 01
Test data PAY 01
Test PAY 01
Production test PAY 01
Complete documentation PAY 01
Define PAY 02 (Payroll)
Flowchart PA Y 02
Code PAY 02
Desk-check, list PAY 02
Test data PAY 02
Test PAY 02
Production test PAY 02
Complete documentation PAY 02
Define PAY 03 (Payroll)
Duration
in
Weeks
.1
.1
.1
.1
.1
.2
.2
.2
1.0
.5
.8
.2
.2
1.0
1.0
.5
.5
Flowchart PAY 03
Code PAY 03
Desk-check, list PA Y 03
Test data PAY 03
Test PAY 03
Production test PAY 03
Complete docu mentation PAY 03
.2
Define PAY 04 (Payroll)
.5
Flowchart PAY 04
Code PAY 04
Desk-check, list PAY 04
Test data PAY 04
Test PAY 04
Production test PAY 04
Complete documentation PAY 04
Define PAY 05 (Payroll)
Flowchart PAY 05
Code PAY 05
Desk-check, list PAY 05
Test data PAY 05
Test PAY 05
Production test PAY 05
Complete documentation PAY 05
Define PAY 06 (Payroll)
Flowchart PA Y 06
Code PAY 06
Desk-check, list PAY 06
Test data PAY 06
Test PAY 06
Production test PAY 06
Complete documentation PA Y 06
Define PAY 07 (Payroll)
Flowchart PAY 07
Code PAY 07
Desk-check, list PAY 07
Test data PAY 07
Test PAY 07
Production test PAY 07
Complete documentation PA Y 07
"Must"
Start (S) or
Finish (F)
Date
.2
.5
.1
.1
.2
.2
.2
.5
.1
.2
.2
.2
.2
.5
.2
.5
.1
.2
.2
.2
.2
.5
.2
.5
.1
.2
.2
.2
.2
.5
.2
.5
.1
.2
.2
.2
.2
*Only one start and finish date should be supplied for each program being developed.
Figure 05.8 (Sheet 1 of 5).
Original Schedule
Dates*
Start
Finish
Revised
Dates # 1*
Start
Finish
Revised
Dates # 2*
Start
Finish
Section
Subsections
Page
I
03
05
30
00
PROGRAM DEVELOPMENT PLAN
ACTIVITY TIME ESTIMATES
Duration
in
Activity
Weeks
Define PAY 08 (Payroll)
Flowchart PAY 08
Code PAY 08
Desk-check, list PAY 08
Test data PAY 08
Test PAY 08
Product test PAY 08
Complete documentation PAY 08
.5
.3
.5
.1
.2
.2
.2
.1
Define PLD 01 (Labor Dist.)
Flowchart PLD 01
Code PLD 01
Desk-check, list PLD 01
Test data PLD 01
Test PLD 01
Production test PLD 01
Complete documentation PLD 01
.8
.5
.5
.2
.3
.5
.2
.2
Define PLD 02 (Labor Dist.)
Flowchart PLD 02
Code PLD 02
Desk-check, list PLD 02
Test data PLD 02
Test PLD 02
Production test PLD 02
Complete documentation PLD 02
.5
.2
.5
.1
.2
.2
.2
.2
Define AR 01 (Accts Rec)
Flowchart AR 01
Code AR 01
Desk-check, list AR 01
Test data AR 01
Test AR 01
Production test AR 01
Complete documentation AR 01
.1
.1
.1
.1
.1
.2
.2
.2
Define AR 02 (Accts Rec)
Flowchart A R 02
Code AR 02
Desk-check, list AR 02
Test data AR 02
Test AR 02
Production test AR 02
'Complete documentation A R 02
.8
.5
.5
.2
.3
.5
.2
.2
Define AR 03 (Accts Reel
Flowchart AR 03
Code AR 03
Desk-check, list AR 03
Test data AR 03
Test AR 03
Production test AR 03
Complete documentation AR 03
Define AR 04 (Accts Rec)
Flowchart AR 04
Code AR 04
Desk-check, list AR 04
Test data AR 04
Test AR 04
Production test AR 04
Complete documentation AR 04
"Must'"
Stant (S) or
Finish ('F)
Date
1.0
1.0
.7
.2
.2
1.0
1.0
.2
.5
.2
.4
.1
.1
.5
.5
.2
*Only one start and finish date should be supplied for each program being developed.
Figure 05.8 (Sheet 2 of 5).
Original Schedule
Dates*
Stant
Fi'n,istl
Revised
Diltes # 1*
Start
Finish
Revised
Dates # 2'
Start
Finish
Section
05
Subsections
30
I
Page
00
04
PROGRAM DEVELOPMENT PLAN
ACTIVITY TIME ESTIMATES
Activity
Define AR 05 (Accts Reel
Flowchart AR 05
Code AR 05
Desk-check, list AR 05
Test data AR 05
Test AR 05
Production test AR 05
Complete documentation AR 05
Dw,ration
in
Weeks
"Must"
Start (S) or
Finish (F)
Date
Start
1.0
1.0
.7
.2
.2
1.0
1.0
.2
Define AR 06 (Accts Rec)
Flowchart AR 06
Code AR 06
Desk-check, list AR 06
Test data AR 06
Test AR 06
Production test AR 06
Complete documentation AR 06
.5
.5
.2
.1
.2
Define AP 01 (Accts Pay.)
Flowchart AP 01
Code AP 01
Desk-check, list AP 01
Test data AP 01
Test AP 01
Production test AP 01
Complete documentation AP 01
.1
.1
.1
.1
.1
.2
.2
.2
Define AP 02 (Accts Pay.)
Flowchart AP 02
Code AP 02
Desk-check, list AP 02
Test data AP 02
Test AP 02
Production test AP 02
Complete documentation AP 02
.5
.3
.2
.1
.1
.2
.2
.2
Define AP 03 (Accts Pay.)
Flowchart AP 03
Code AP 03
Desk-check, list AP 03
Test data AP 03
Test AP 03
Production test AP 03
Complete documentation AP 03
.2
.2
.1
.1
.2
.2
.2
.4
.4
.2
.4
Define AP 04 (Accts Pay.)
Flowchart AP 04
Code AP 04
Desk-check, list AP 04
Test data AP 04
Test AP 04
Production test AP 04
Complete documentation AP 04
.2
.1
.1
.2
.2
.2
Define AP 05 (Accts Pay.)
Flowchart AP 05
Code AP 05
Desk-check, list AP 05
Test data AP 05
Test AP 05
Production test AP 05
Complete documentation AP 05
.4
.2
.2
.1
.1
.2
.2
.2
.5
.4
*Only one start and finish date should be supplied for each program being developed.
Figure 05.8 (Sheet 3 of 5).
Revised
Dates 1+ 1*
Original Schedule
Dates *
Finish
Start
Finish
Revised
Dates # 2*
Stan
Finish
Section
05
Subsections
Page
I
05
30
00
PROGRAM DEVELOPMENT PLAN
ACTIVITY TIME ESTIMATES
Activity
Duration
in
Weeks
Define AP 06 (Accts Pay.)
.5
Flowchart AP 06
Code AP 06
Desk-check, list AP 06
Test data AP 06
Test AP 06
Production test AP 06
Complete documentation AP 06
.3
.5
.1
.2
Define AP 07 (Accts Pay.)
.4
.2
.2
.5
.4
.5
.1
.1
Flowchart AP 07
Code AP 07
Desk-check, list AP 07
Test data AP 07
Test AP 07
Production test AP 07
Complete documentation AP 07
.2
.2
Define INV 01 (Inventory)
Flowchart INV 01
Code INV 01
Desk-check, list INV 01
Test data JNV 01
Test INV 01
prod\.lction test INV 01
Complete doc\.lmentation I NV 01
.1
.1
.1
.1
.1
.2
.2
.2
Define INV 02 (Inventory)
Flowchart INV 02
Code INV 02
Desk-check, list INV 02
Test data INV 02
Test INV 02
Production test INV 02
Complete documentation INV 02
.4
.2
.2
Define INV 03 (Inventory)
Flowchart INV 03
Code INV 03
Desk-check, list INV 03
Test data I NV 03
Test INV 03
Production test I N V 03
Complete documentation INV 03
.4
.1
.1
.2
.2
.2
.4
.4
.4
.1
.1
.2
.4
.2
Define INV 04 (Inventory)
.5
Flowchart I N V 04
Code INV 04
Desk-check, list INV 04
Test data INV 04
Test INV 04
Production test I N V 04
Complete documentation INV 04
.4
.4
.1
.1
Define INV 05 (Inventory)
Flowchart INV 05
Code INV 05
Desk-check, list INV 05
Test data INV 05
Test INV 05
Production test INV 05
Complete documentation INV 05
"Must"
Start (S) or
Finish IF)
Date
.2
.2
.2
.4
.2
.2
.1
.1
.1
.2
.2
*Only one start and finish date should be supplied for each program being developed.
l7igure 05.8 (Sheet 4 of 5).
Original Schedule
Dates*
Start
Finish
Revised
Dates ~ 1*
Start
Finish
Revised
Dates #
Start
2~
Finish
Section
Subsections
30
05
I
Page
00
06
PROGRAM DEVELOPMENT PLAN
ACTIVITY TIME ESTIMATES
Activity
Define INV 06 (Inventory)
Original Schedule
Dates*
"Must"
Start (S) or
Finish (F)
Date
Duration
in
Weeks
Revised
Dates # 1*
Finish
Start
Start
Revised
Dates # 2"
Finish
Start
.4
.2
.2
.1
.1
.1
.2
.2
Flowchart INV 06
Code INV 06
Desk-check, list INV 06
Test data INV 06
Test INV 06
Production test I NV 06
Complete documentation INV 06
Define SA 01 (Sales Anal.)
.1
.1
.1
.1
.1
.2
.2
.2
Flowchart SA 01
Code SA 01
Desk-check, list SA 01
Test data SA 01
Test SA 01
Production test SA 01
Complete documentation SA 01
Define SA 02 (Sales Anal.)
Flowchart SA 02
Code SA 02
Desk-check, list SA 02
Test data SA 02
Test SA 02
Production test SA 02
Complete documentation SA 02
1.0
.5
1.0
Total, application development
16.0
.1
.1
.3
.4
.2
*Only one start and finish date should be supplied for each program being developed.
Figure 05.8 (Sheet 5 of 5).
PERCENTAGE COMPLETED
AIR
Finish 2/3
PAY
PAY
PAY
PAY
01
02
03
04
Define program
100
100
100
50
Document logic
100
100
100
50
Code
100
70
40
Desk-check
100
Prepare test data
100
Test
100
Finish 2/3
I
,
I
1
~
Activity
All
Applications
Start:
Start 12/4
Start 11/20
Payroll
I
A/R
01
~J
100
11/20/67
1.1
All
Payroll
,
All
A/R
II
~
Finish:
..
I
90
100
70
60
100
50
I
3/11/68
40
20
20
5
10
5
20
30
30
10
5
10
Production test
Complete documentation
90
20
20
20
30
All activities above
Figure 05.9.
85
49
33
Program development -- progress chart
15
50
50
t
I
',
31
35
"
10
~,
I
1
"
L
10'
Finish
Section
10
Subsections
Page
I
01
00
00
Section 10: DOCUMENTING CUR.RENT
APPLICA TIONS
CONTENTS
Intr<;>duction ........................ .
Documentation of Manual Systems .... .
Documentation of Punched Card
Systems ....•.......................
Accounting Controls ................ .
Survey Questionnaires .............. .
Billing .......................... .
Accounts Receivable ............. .
Sales Analysis ................... .
Inventory ........................ .
10.01.00
10.10.00
10.20.00
10.30.00
10.40.00
10.40.10
10.40.20
10.40.30
10.40.40
Accounts Payable ................ .
Payroll ........................ .
Manual System Documentation
Example - Payroll ................. .
Introduction .................... .
Job Description ................. .
Survey Form ................... .
Sample Documents ...•...........
Systems Flowchart of Weekly
Procedure ..................... .
10.40.50
10.40.60
10.50.00
10.50.01
10.50.10
10.50.20
10.50.30
10.50.40
Section
10
INTRODUCTION
Since the cornerstone of your installation effort,
planning, is now complete, the time to begin documenting is at hand.
If you were going to remodel a building, it would
be very important to have the plans of the structure
on which you would be working. You could, of
course, do the job without the plans, but much time
would be wasted in trial and error as you proceeded.
The same situation exists when you are converting an application to the 1130. Proper documentation of the present system will guide you rapidly and
efficiently into the new solution. Rather than
spending your time" rediscovering" the old procedures, you can spend it in improving them.
Depending on whether you are converting from a
Subsections
Page
I
01
01
00
manual system or a punched card system, one of the
following two subsections will help you plan this
phase of your preinstallation effort:
Documentation of Manual
Systems (10. 10. 00)
Documentation of Punched
Card Systems (10.20.00)
These introductory subsections are followed by a
discussion of the ways in which your current accounting controls can be documented (10.30.00).
Questionnaires used for documenting manual systems are then illustrated (10.40. 00).
A payroll example, which is used also in later
sections, is introduced in 10.50.00. This consists
of:
Job description
Survey forms
Sample documents
Systems flowchart
Section
10
Subsections
Page
I
01
10
00
DOCUMENTATION OF MANUAL SYSTEMS
Follow these steps if you currently do not use
punched card equipment, or if you are planning to
put additional applications on the computer that are
not now mechanized:
1. Ask questions about details of the job as it is
being done now.
2. Record the procedure by means of a flowchart.
3. Gather samples of all the documents being
used.
Survey Notes. A set of questionnaires
(10.40.00) is included that assists in surveying the
most common data processing procedures: billing,
accounts receivable, sales analysis, inventory,
accounts payable, and payroll. No questionnaire
can cover all the details of, for instance, all billing
procedures, but a start can be made that will lead
you to discover and analyze the unique elements
that have to be accounted for in your own system.
Before starting your survey with a questionnaire,
review the questions and determine which ones you
already know the answers to, those you want to
check out, and those you know are not applicable to
your company. Then add questions of your own.
Where none of these survey questionnaires are
applicable, record on plain paper the important
elements of the system~ answering the questions
"who" ~ "what", "when", "why", and "how". Notice
the amount of detail called for by the questionnaires,
and get down to that level in your own surveys.
You will often find that the people most familiar
with the details of the job do not see the forest for
the trees, or --to use a more precise metaphor -they think they have been looking only at elms when
some of the trees have been maples. Wherever
possible, count the files yourself (rough counts are
usually adequate), look at the completed (not the
blank) documents, and talk to the man who actually
does the work, rather than taking someone else's
word for what he does.
Flowcharts. As an understanding of the procedure is developed, you should draw flowcharts in
which input/output documents are represented by
one kind of block, processing or handling steps by
another, and the flow of work by arrows, as shown
in Figure 10. 1.
Other symbols can be used for certain variations
of the basic symbols; these are discussed in
greater detail in the IBM manual Flowcharting
Techniques (C20 - 8152) and illustrated in the manual examples in this section.
Sample Documents. Samples of each document
used in the procedure should be gathered. Where
pOSSible, filled-in documents should be picked up,
as well as blank documents on which the people
closest to the work have made notes explaining how
the documents are completed.
In other words, you should have at least two
samples of each document in the system:
1. A blank document. This should have the
following information written on it:
a. The volume of these documents produced
each day, week, or month -- both maximum and average.
b. Who produces them.
c. Where they come from, and where they
go, copy by copy.
d. For each different kind of information, or
"field", all possible varieties of information that can be entered. State how
long the field must or can be, and whether
Symbols
Example
Flow direction line
Processing
Prepare
Employee
Master Payroll
Cards
Flow direction line
Visually
Verify
and File
Figure 10.1.
Section
10
each individual "position" or character in
the field is strictly numeric, is sometimes alphabetic, may be blank, may contain special characters $. , '*0=+-&/,
or has any other restrictions on it.
e. For each field, whether the information
in it has limits. For instance, a weekly
salary field could go up to $999.99 and
still consist of only five digits, but you
may want to pull out all of those that go
above $500.00 for special handling.
f. For each field, its origin. If it has been
calculated, show the formula. If it came
from another document, state which one,
and whether it has been altered in the
process. Beware of fields that have the
same name but are slightly different,
such as date of receipt, date of entry,
date of transcription, date of processing.
2. At least one filled-in document. The filling in should be done by the man who normally per-
Subsections
10
I
00
Page
02
forms the job, and he or you should annotate the
reasons for and restrictions on each step of his
work. Make sure that all possible ways of filling in
the document have been illustrated.
Summary. When the documentation of manual
systems has been completed, you should have at
hand:
1. Flowcharts
2. Sample documents
3. Survey notes, including:
a. Complete lists of codes
b. Current standards
c. Procedure descriptions, where the flowchart is not self-explanatory
d. Reasons for current methods
e. Accounting control procedures
f. Any other facts they may influence or
cause restrictions on the wayan application may be designed.
All these survey notes should be cross-referenced to the flowcharts and sample documents.
Section
10
Subsections
Page
I
01
20
00
DOCUMENTATION OF PUNCHED CARD SYSTEMS
Follow these steps in documenting your present
punched card applications:
1. Make a list of all your control panels.
2. Arrange the list by job step within application. For instance, a payroll application, like the
one in 10.50.00, might consist of panels to perform
the balancing of current earnings cards to time
cards, matching current deductions cards to earnings cards, preparing the deduction register, and
all the remaining job steps.
3. Obtain copies of all the reports that have
been run using these panels.
4. Collect your current spacing charts and card
layouts and make a checklist of them. Use your
list of control panels to make sure that you have
gathered spacing charts and card layouts for all
the operations. If not, put them on your checklist,
and either find them or get them made up.
5. Check your spacing charts against the currently run copies of your reports, and bring your
spacing charts up to date. Mark them on your
checklist as they are updated.
6. Check your card layouts against your procedures as you run them. This will allow you to update both the card layouts and the written procedures
to conform with your current actual practice. Mark
the card layouts on your checklist as they are updated.
7. Obtain a current schedule of jobs. Use your
list of control panels to verify the schedule.
Having finished these steps, you should have
current and accurate copies of spacing charts and
card layouts. If you do not, your 1130 application
design and program development will suffer, and
you will be forced to retrace your steps to get up-
dated facts. The surveys (in 10.40.00) will either
verify the accuracy of your documentation or indicate discrepancies that need to be checked further.
Next, since you have all the information at hand,
you can develop the following items:
1. Updated flowcharts of your applications
2. Job descriptions
3. Calculation descriptions and formulas
These items, if prepared thoroughly (and this is
a very important "if"), can serve as the basis for
your entire 1130 application design effort.
Summary. The important thing in documenting
any procedure is that all the information be made
available to the programmer in concise, easily
understood form.
You will find that these documenting methods
will be very useful in analyzing all the procedures
in your business. By pinpointing bottlenecks, areas
of duplication, etc., they can provide a means of
improving those procedures that you do not plan to
convert immediately to the new system.
Once a program has been completed for an application, the documentation will become a permanent
record of the procedure. It can be used, for
example, as:
1. A source of information for implementing
future changes.
2. An education device for familiarizing new
operators and management personnel with the procedures.
3. A source of information for your auditors,
who must be familiar with your procedures.
Start documenting your present applications now.
Once the application is documented, programmed,
and operating on your new system, keep the documentation up to date. It will contribute toward an
efficient and productive data processing installation.
Section
10
ACCOUNTING CONTROLS
Understanding your present controls will help you
design practical and effective controls for your new
system.
Control procedures can be documented in two
places:
Subsections
Page
I
01
30
00
1. On your flowcharts, where, for instance,
control tapes are balanced to accounting machine
totals.
2. With the survey questionnaires or informal
narratives.
For a discussion of various kinds of accounting
controls that may appear in your system, refer to
section 20.10.00.
Section
Subsections
10
40
J
10
Page
01
SURVEY QUESTIONNAIRES
Survey Questionnaire - Billing
PROCEDURES
1.
Bill before shipment or after?
2.
Reasons
3.
Is completion billing used?
4.
Optimum time from order to shipment
5.
Are shipments from stock? What percent?
(a)
Buy outside %
(b)
Manufacture? Drop Ship?
6.
Do you send confirmation of order to customer? When?
7.
Sold-to and ship-to information required on invoices? % of invoices?
TERMS
1.
Standard by customer, variable by customer, or other
2.
Do salesmen have protected customers?
3.
Pricing flexible - changed to meet competition in field?
4.
How many must be acknowledged?
5.
Cash sales - volume and how handled?
ITEM QUANTITIES
1.
Whole numbers, fractions, or decimals?
2.
Will you print quantity ordered, quantity shipped, back ordered?
3.
Largest quantity sold (include decimals)
4.
Unit of issue
PRICES
1.
Standard, volume determines, customer class, variable? How many prices?
2.
Percent of billing lines with variable pricing daily
Section
10
Billing Questionnaire (cont'd)
3.
Variable pricing authorized by?
4.
Per CM, dz, gross, bd ft, other?
5.
Largest unit price
6.
Fractional prices
DISCOUNTS
1.
Line item only? Variable or standard?
2.
What governs discounts to customers?
(a)
Customer
(b)
Type of 'merchandise
(c)
Quantity of merchandise
(d)
Salesman's quoted price
(e)
Total of invoice
(f)
Combination of above
(g)
Other
3.
Group discounts
4.
Discounts on total invoice?
(a)
Standard by customer
(b)
V ariab Ie
5.
Should discount amount print on invoice?
6.
Chain discounts?
(a)
Line items
(b)
Groups
(c)
Invoice totals
7.
Chain discount examples
8.
Terms or cash discount. Should it be calculated?
Subsections
Page
I
02
40
10
Section
Subsections
Page
I
03
10
40
10
Billing Questionnaire (cont'd)
COSTING
1.
Standard, percent, other?
2.
Any lot or job costs?
TAXES
1.
How many states?
2.
What % of items taxable?
3.
Are selected items on an invoice taxable?
4.
Other taxes - excise, etc.
5.
Whole percents, fractional?
FREIGHT
1.
Based upon weight? Volume? Explain
2.
Examples of computation
3.
Prepaid percent - collect percent
4.
Is freight cost known at billing time?
5.
At prebilling time?
6.
Allowances - examples.
7.
Flat rates?
8.
Minimums?
9.
Do items have standard weights?
COMMISSIONS
1.
Paid on:
(a)
Gross profit
(b) Gross invoice
(c) Variable each line
How computed?
Section
10
Billing Questionnaire (cont'd)
2.
3.
(d)
Total customer purchase
(e)
Other
Percentage fixed by:
(a)
Product?
(b)
Salesman?
(c)
Customer?
(d)
Volume?
If volume, what are the breaks in computing rate?
FORMS INFORMATION
1
2
3
4
5
6
7
8
9
10
1.
Use of copies
2.
If you prebill, could invoice serve as picking document? As bill of lading?
3.
Average number of body lines
4.
Minimum depth of form
5.
Preprint invoice number? Why?
6.
Are back orders noted on invoice?
7.
What is the length of item descriptions?
(a)
Number and type of special characters included in descriptions?
(b)
Can description be conveniently abbreviated?
8.
Discount on line item?
9.
Largest quantity shipped? Largest unit price? Largest extension?
Subsections
Page
I
04
40
10
Section
Subsections
Page
J
05
10
40
10
Billing Questionnaire (cont'd)
10.
Cash discount printed on invoice? Terms?
11.
Length of ship-tol sold-to lines
12.
Cost extended - line items?
13.
Do credit memos and invoices use same format?
14.
Are contractual notes typed on irivoice or credit memo?
(a)
If yes, what is longest note?
(b)
What is the incidence of use (percent) of total invoices per day?
15.
Multi-page invoice? Frequency
16.
What class of products is most active? At what time of the year?
17.
Are the products of a seasonal nature? When? What is increase in orders?
18.
What items make up largest percentage of total sales volume?
19.
How much item information is needed on the order? On the invoice? Can it be typed later?
20.
How are items coded?
21.
22.
(a)
What is the length of part number or code?
(b)
Numeric or alphameric?
What procedure is being followed as to partial shipments?
(a)
How prevalent are they?
(b)
Are shipments made daily to all areas? If not, what is the policy regarding shipments?
(c)
Is warehouse sequence of items on the order important?
Describe miscellaneous data required.
Section
10
Subsections
Page
I
06
40
Billing Questionnaire (cont'd)
ANALYSIS
1.
Time from receipt of order to billing of customer
2.
Number and jobs of people performing order writing and billing
3.
Type of machines and equipment presently being used
CONTROL AND EDITING INFORMATION
1.
What is the editing procedure for invoicing? Who is responsible for final approval of invoice?
2.
What controls are now established for accuracy?
3.
Do you have subsidiary branch locations?
(a)
If so, what accounting functions are they performing?
(b)
How many invoices is each branch preparing?
(c)
Would it be more advantageous to centralize accounting operations, especially billing?
10
Section
10
Subsections
Page
I
01
40
20
Survey Questionnaire - Accounts Receivable
PROCEDURES: CASH
1.
List all cash credit posting media
2.
What discounts are offered? How are they handled?
3.
Cash receipts and deposit slip prepared:
(a)
Separately
(b)
Simultaneously
4.
How often do payments include copy of invoice or statement or identification?
5.
What percentage of payments are nonstandard?
6.
What is policy on overpayments?
7.
Can cash be applied to oldest balance or must it be selective?
8.
What accounts are involved?
9.
Can distribution be made at cash posting time?
10. How many ledger controls are carried?
(a)
How are control groups determined?
(b)
Illustrate divisions
11. How often is a trial balance taken?
(a)
Can trial balance be alternated by control?
(b)
Could trial balance, aging, and customer purchasing analysis be prepared simultaneously?
12. When are statements mailed?
13. Attach samples of accounting (A/C) journal used, revised to include additional information you require.
14. Volume and reasons for credit memos
Section
10
Accounts Receivable Questionnaire (cont'd)
FORMS CONSIDERATIONS - STATEMENTS
1.
How many accounts in ledgers?
(a)
Total active
(b)
Total inactive
(c)
Does total fluctuate or remain static?
(d)
How are they coded?
2.
Open item or balance forward?
3.
What percent of customers pay by:
4.
(a)
Statement?
(b)
Invoice?
(c)
Time pay?
How many statements mailed?
(a)
Total
(b) Weekly
(c)
Monthly
(d) Are they mailed to all accounts?
5.
If time pay is allowed, explain circumstances.
6.
Do statements show:
(a) All transactions for the month?
(b)
Open items only?
(c)
Aged balances only?
(d)
Aged transactions?
7.
Any objection to aged balances only, with no reference?
8.
What description shows on statement?
Subsections
Page
I
02
40
20
Section
Subsections
Page
I
03
40
10
20
Accounts Receivable Questionnaire (cont'd)
9.
Daily inquiries into customer records?
10. Extent of bad debts
11. Attach a sample statement, complete with various postings.
LEDGER RECORDS
1.
What description is shown on ledgers?
2.
Credit limit on each card?
3.
Purchases to date? Is this desirable?
4.
Is aging by invoice? Oldest dollar amount?
5.
Attach a sample card, complete with typical postings.
CREDIT REFERENCE
1.
Does credit department refer to ledgers? How often?
2.
Is a credit record other than ledger kept? If so, attach a sample.
3.
When does an account become delinquent?
4.
How are delinquents followed?
5.
Do you suspend credit buying of delinquent accounts? If so, how is it restored?
6.
Are accounts aged?
(a) What breakdowns?
(b)
'¥hen?
(c)
How often?
ANALYSIS
1.
Number of people involved
2.
Type of equipment involved
Section
10
Survey Questionnaire - Sales Analysis
1.
Information required by:
(a)
Customer
(b)
Item
(c) Area
(d)
Salesman
(e)
Class of trade
2.
What reports should management be receiving that they are not now getting?
3.
Report information
(a) What information is required on each report?
(1) What records or registers are used to substantiate reports?
(2) What can be added to present reports to make them more meaningful?
(b) Who receives each report?
(c)
By what priorities are reports prepared?
(d) Are cost analysis reports generated?
(1)
How often?
(2)
To whom?
(3) What information?
(4) By what classification?
(e) Are gross reports prepared?
(1)
(f)
By what classification?
Are comparative sales analysis reports generated?
(1) What period are the results based on?
(g) Are salesman commission statements prepared?
(1)
How many salesmen?
Subsections
Page
I
01
40
30
Section
10
Subsections
Page
I
02
40
30
Sales Analysis Questionnaire (cont'd)
4.
Control information
(a) What are controls and editing procedures for above reports?
5.
What is present cost to derive these reports?
Section
10
Subsections
Page
I
01
40
40
Survey Questionnaire - Inventory
1.
2.
3.
4.
What percentage of inventory items account for:
(a)
High activity?
%
(b)
Medium activity?
%
(c)
Low activity?
%
Does the present coding structure have any real significance, such as block code, significant digit, etc. ?
(a)
Give example
(b)
Are bin locations assigned in sequence by part number?
How many transactions are there of each type?
(a)
Receipts and returns
(b)
Issues
(c)
Miscellaneous
Are standard or economic order quantities used? If so, how are they determined?
(a)
5.
6.
Do you order by vendor group or as required?
Does the inventory record reflect planned requirements, such as:
(a)
On-hand balance
(b)
On-order balance
(c)
Reserved balance
(d)
Available balance
(e)
Minimum balance
(f)
Usage data, etc.
(g)
Maximum balance
What inventory costing method is used?
(a)
Average
(b)
Last in, first out (LIFO)
Section
10
Subsections
Page
I
02
40
40
Inventory Questionnaire (cont'd)
7.
(c)
First in, first out (FIFO)
(d)
Standard
What is the frequency of inventory cost changes? What is the frequency of inventory sales price
changes?
(a)
How often are price changes of finished goods made?
(b)
Are they made by product line or by item?
8.
If partial shipments are made, what is the procedure for handling them?
9.
Is there a back-order problem? If so, how is it controlled?
(a)
What percentage of orders have items back-ordered, substituted or canceled?
(b)
How much $ volume do you lose?
10. How and when is a physical inventory taken? By whom?
11. What controls are set up and maintained on the inventory system?
12. What is the cost of inventory maintenance?
13. What are the present costs of keeping inventory records?
14. What are the types of inventory records and reports?
(a)
Do they result in a stock status summary report?
(b)
How often are inventory reports prepared?
(c)
Who receives them?
15. What is the origin and layout of source documents and what controls are used?
16. How often are inquiries made into inventory records? What are their nature? Who makes them?
17. How are present inventory recordkeeping functions correlated with purchasing, billing, sales,
manufacturing, etc.?
Section
10
Inventory Questionnaire (cont'd)
18. What comparative information do you need?
(a)
Month-to-date
(b)
Year-to-date
(c)
Same period last year
(d)
Percent of comparisons
19. Where must current inventory records be physically located?
Subsections
40
I
40
Page
03
Section
10
Subsections
Page
I
01
40
50
Survey Questionnaire - Accounts Payable
REPORT INFORMATION
1.
2.
Is a cash requirement register being prepared?
(a)
What is the average daily cash requirement to meet payables?
(b)
How often is this register prepared?
Are amounts being distributed and charged to job orders and expense accounts?
(a)
(b)
What is the procedure for each of the above?
(1)
Number of open job orders
(2)
Number of expense accounts
Are departments budgeted?
(1)
How often are budgets depleted and how often are analysis reports submitted?
CONTROLS AND EDITING PROCEDURES
1.
How are payable accounts reconciled?
2.
Who is responsible for editing before releasing checks, and what is the procedure?
3.
How often are payable accounts reviewed?
4.
What controls are in effect?
PURCHASES
1.
Number of vendors active and inactive. What are criteria for active?
2.
Are orders placed verbally, by requisition, by purchase order, or other?
3.
Is blanket order placed for staggered shipments?
4.
How are incoming goods accounted for?
5.
How are partial shipments handled?
6.
What method is used to notify Accounts Payable regarding overs, shorts, or damaged goods?
Section
10
Subsections
40
I
Accounts Payable Questionnaire (cont'd)
7.
Are purchase orders (P. O. 's) coded by Accounting when written?
(a) If not, when and how are codes assigned?
INCOMING INVOICES
1.
Is an invoice register maintained? If not, how are invoices controlled?
2.
Pay by statement?
(a)
3.
Is early-pay discount given?
When is liability recognized?
(a) Receipt of goods
(h)
Receipt of invoice
4.
Are invoices matched to P. O. 's?
5.
Are invoices received from same vendor with different discount dates? How are they handled?
6.
Are any invoices paid before arrival of goods?
7.
Can one invoice be charged to two or more accounts?
PROCEDURE
1.
Is a voucher system presently in use? Ledger system? Other?
2.
How are invoices or vouchers filed to ensure that discounts will be taken?
3.
Are incoming invoices numbered consecutively?
(a)
Upon receipt?
(b)
Other?
CHECK WRITING
1.
How many banks are checks drawn against?
2.
If more than one, can the bank be determined before the voucher is opened?
3.
Are checks prenumbered?
4.
What accounting (A/C) distribution is required? Attach sample.
50
Page
02
Section
10
Subsections
Page
I
03
40
50
Accounts Payable Questionnaire (cont'd)
#
5.
How often are checks written?
6.
What is present form of checks, voucher, and remittance advice? Attach sample..
7.
Are discounts computed at check-writing time? If not, when?
8.
Is a check register required?
9.
Are certain checks written daily? 'If so, estimate number.
DISTRIB UTION
1.
Which accounts receive greatest number of distributions?
2.
How many income and expense accounts are kept? How many divisions are used?
3.
How many controlling accounts? Identify each.
4.
What department or person is responsible for
5.
Is apron or rubber stamp used?
6.
What percent of invoices contain items chargeable to different income and expense accounts?
7.
Is distribution made directly from invoice? At checkwriting time?
8.
How much detail in distribution record?
9.
How many items other than invoices (e. g., journal vouchers) are distributed each month?
AI C distribution of invoice?
10. What is cutoff date?
11. When is trial balance secured?
12. How is trial balance secured?
MISCELLANEOUS
1.
Is obligation record required?
2.
Is purchase journal available? How prepared?
3.
Is vendor control card required?
4.
Total purchases-to-date by vendor required?
5.
Do you, or will you, use group processing method?
6.
Do you, or will you, use balance-forward method?
7.
Are expenditures compared against budget?
Section
10
Survey Questionnaire - Payroll
1.
2.
3.
4.
How is time figured?
(a)
Tenths of hours
(b)
Hundredths of hours
(c)
Hours and minutes
(d)
Other (nearest half or quarter hour)
(e)
Incentive or price rates
What is overtime?
(a)
Over 40 hours
(b)
Over 8 hours
(c)
Other
How prevalent are rate changes? Temporary or permanent?
(a)
How many can a man have?
(b)
When?
(c)
Does job carry a rate?
How many shifts are there?
(a)
What kind of bonus is there?
(b)
How is it calculated?
5.
What is employee turnover?
6.
What YTD information will appear on check stub?
7.
How many timekeepers?
8.
Are timeclocks used? Is time recorded in tenths or hundredths of hours?
9.
Is there labor distribution?
(a)
By job? Department? Operation? Machine?
(b)
Is average labor cost used?
Subsections
Page
I
01
40
60
Section
10
Subsections
Page
I
02
40
60
Payroll Questionnaire (cont'd)
(c)
Actual labor cost?
(d)
How is overtime handled?
PREPARATION DATA
1.
What are pay periods?
2.
When does pay period close?
3.
What is paying date? P reparation time?
4.
How are employees paid?
(a)
Check, cash?
(b)
Is envelope used?
5.
How many copies of journals?
6.
Any objection to the use of spot carbon on check?
7.
Should check amount be protected?
8.
Is check signer used?
9.
Do you write payroll checks on more than one bank?
10. How and when are vacation checks written?
11. How are advances handled?
12. How are terminations handled?
13. How is sick pay handled?
14. How is holiday pay handled?
INCENTIVES, SIDFTS, ETC.
1.
How many shifts?
2.
What is incentive formula?
3.
Are rates for various jobs known by employees?
4.
How often is it necessary to pay "make-up" pay?
5.
List indirect labor categories
Section
10
Payroll Questionnaire (cont'd)
6.
Are efficiency standards established?
(a)
By machine?
(b) By employee?
DEDUCTIONS
1.
Voluntary
1
2
3
4
5
6
2.
Involuntary
7
8
9
10
11
12
3.
Average deduction amount
(a) Voluntary
(b)
Involuntary
1
2
3
4
5
6
7
8
9
10
11
12
4.
Percentage of activity
(a) Voluntary
(b)
Involuntary
1
2
3
4
5
6
7
8
9
10
11
12
Subsections
Page
I
03
40
60
Section
10
Subsections
Page
I
04
40
60
Payroll Questionnaire (cont'd)
5.
Largest month total ($)
(a) Voluntary
1
2
3
4
5
(b)
Involuntary
6
7
8
9
10
11
12
6.
List the posting media for each
of the above
1
2
3
4
5
6
7
8
9
10
11
12
7.
What reports must be furnished?
1
2
3
4
5
6
7
8
9
10
11
12
8.
How are salesmen paid?
(a)
Salary or standard commission
(b)
Explain other
Section
10
Subsections
Page
I
05
40
60
Payroll Questionnaire (cont'd)
9.
Reports (payroll and labor distribution)
(a)
Form (sequence of information)
(b)
Content (size of fields, number of classifications)
(c)
Frequency (Presently? With IBM approach to application?)
(d)
Distribution
10. Schedule requirements
(a)
Length of pay period
(b)
When are source documents available for processing?
(c)
When does pay period close?
(d)
How soon after pay period closes must checks be available?
(e)
How long does it take for changes to clear through the personnel department?
11. Reporting
(a)
Who reports payroll source data? Employees? Timekeeper? Foreman?
(b)
What degree of control does the accounting department have over the people who report data?
12. Management requirements
(a)
Who gets the reports?
(b)
What would they like that their present system doesn't give them?
13. Miscellaneous
(a)
In what states do you pay payroll ?
(b)
What special deduction considerations are there?
(c)
Is state or city income tax deducted?
Section
10
Subsections
Page
I
01
50
01
MANUAL SYSTEM DOCUMENTATION EXAMPLE -PAYROLL
Introduction
This example of a typical manual application consists of the following items:
Job Description -- Payroll
Survey Form - filled in for payroll
Samples of all documents being used
Flowchart -- all of payroll procedure
Notice that the illustrations are shown in the
order in which they are ordinarily developed. After
the job description is written~ the survey is completed, and all sample documents are gathered.
Then the procedure that produces the reports, using
the information from the survey form, is drawn in
flowchart form.
Section
10
Job Description
A job description is not always necessary, but is
useful when new people are introduced to an application, or when presentations are made for manage-
Subsections
Page
I
01
50
10
ment or visitors. Both of these situations occur
frequently during the conversion process.
The following is a typical job description. Note
that it is short, describes objectives, and provides
a summary of the procedure.
Payroll -- Job Description
The objectives of the payroll procedure are:
1.
To record earnings, deductions, and taxes for historical purposes.
2.
To provide state and federal governments, unions, and other agencies with a record of
moneys collected for them.
3.
To furnish employees with a personal record of earnings, deductions, and taxes.
4.
To write and reconcile paychecks.
5.
To provide entries to labor statistics and miscellaneous reports.
To accomplish the above, current period time cards, containing hours worked, are matched to the
production report, and gross earnings are calculated and posted to the payroll register. Then, deductions and net pay are calculated and posted to the payroll register, paychecks are written, and
earnings records are updated. Miscellaneous reports are produced from earnings records, and
quarter-to-date information is prepared for 941 and W-2 forms preparation.
Section
10
Subsections
Page
I
01
50
20
Survey Form
The following is a typical completed survey form.
Note that the answers are short and descriptive.
The survey form is always necessary.
Section
10
FACTORY PAYROLL
Survey Questionnaire - Pay 1.'011
1.
2.
3.
4.
How is time figured?
(a)
Tenths of hours
(b)
Hundredths of hours
(c)
Hours and minutes
(d)
Other (nearest half or quarter hour)
(e)
Incentive or price rates
X
What is overtime?
(a)
Over 40 hours
X
(b)
Over 8 hours
X
(c)
Other
How prevalent are rate changes?
~mpora~or
permanent?
(a)
How many can a man have?
Yvlcut:~))
ID
(b)
When?
(c)
Does job carry a rate?
~
How many shifts are there?
\ )l)
~
1.fC0v
cL-\. ~ ~~) ~~
(a)
What kind of bonus is there?
(b)
How is it calculated?
tyv Q)
,
~
.2,~ Jul'W/I~
~
02;5 c/~
te
~ ~ ~t 04- ~ ~
c~ ~ ~
5.
What is employee turnover?
6.
What YTD information will appear on check stub?
7.
How many timekeepers?
8.
Are timeclocks used?
9.
Is there labor distribution?
L.\P.'I
6~"""
V2.:.p artmen-g
~
~ ~ ~
Is time recorded in tenths or hundredths of hours?
~
(a)
By job?
Operation? Machine?
(b)
Is average labor cost used?
~
Subsections
Page
I
02
50
20
Section
10
Subsections
Page
I
03
50
20
(c)
Actual labor cost? .....fu-
(d)
How is overtime handled?
(U, }~x..~~ ~~
PREPARATION DATA
1.
What are pay periods? ~
2.
3.
When does pay period close? h\...<>J.,..,r
·1~j.~~~
~
What is paying date? '" Pr--eparati6h time? \ ~ .~- (~
4.
How are employees paid?
(a)
(b)
Ehe~ cash?
Is envelope used?
\)~ k~ ~
~
5.
How many copies of journals?
6.
Any objection to the use of spot carbon on check?
7.
Should check amount be protected? ~
8.
Is check signer used?
9.
Do you write payroll checks on more than ope bank?
''""\le-
~
10. How and when are vacation checks written?
y:t
~
~ ~ ~
(ru \l~
.~
11. How are advances handled?
0-u~~\.A
12. How are terminations handled?
M.Q...¥ ~ ~M.A.,-t~L ~ ~~
~~(J..A/\-U- ~~ L-~ ~~i ~ ~.~ .~.
13. lIow is sick pay handled?
~~ ,
U
Q:;l,~)ul:t., '>-\ ~\, ~ ~'lL ~ ~ ~.
14. How is holiday pay handled?
INCENTIVES, SHIFTS, ETC.
\ ~
h.~.
~v~
(j'~l
1.
How many shifts?
2.
What is incentive formula?
3.
Are rates for various jobs known by employees?
J.L4....-
4.
How often is it necessary to pay "make-up" pay?
~\.L.<.,Vu
5.
))
c,.'1.,
'2:>
~ Ie
)
"\ ~tLt.u_,,'C'\.iu ~~d:LeL ~>v ~IA."'~
Section
10
6.
Are efficiency standards established?
(a)
By machine?
(b)
By employee?
'~'tv
X
DEDUCTIONS
1.
Voluntary
e~\~
1
Q4~~~
2
~
3
4
5
6
2.
Involuntary
7
8
9
10
11
12
3.
Average deduction amount
(a) Voluntary
1 ~.5. ~
2 i (). '30
3 "Ii.e-tr
4
5
(b)
Involuntary
6
7
1\.5'0
1).
8 ~ 15.0-0
9 ~ 0.35
10 f Y. c-tf
11 t I,~
12
-1.
Percentage of activity
(a) Voluntary
1
;L5
2
3
90
l
4
5
6
(b)
Involuntary
7
qq
810 c
9
15
10
11
12
.00
COo
Subsections
Page
I
04
50
20
Section
10
5.
Subsections
Page
I
05
50
20
Largest month total ($)
(a) Voluntary
1
1}GJ~
2tl)H-CY
3 1);> i SO
4
5
6
(b)
Involuntary
7 t 3)~
8 ~ I) 5D1)
9 -~
I ~D
Ie 'If 7) rrHT
11 1> i) 1t"i1
12
6.
List the posting media for each
of the above
6
7.
What reports must be furnished?
1
2
3
4
5
~ttLehl l\./.A,~ Qc~
l\,A'-~ (~ ~~
,A~·~~jR &&t.~~.J:.
W-(L
qL\ \
6
7
~~.o..Y...
~~ '--\-hWM't
~~tc,
~
8
~\,u..0i(,
,&t.u...\>->
~~~V~,~~
8.
How are salesmen paid?
(a)
Salary or standard commission
(b)
Explain other
Mbv\(s" -t
\0
'/0
<'V-Ov~)
Section
10
9.
Subsections
Page
I
06
50
20
Reports (payroll and labor distribution)
(a)· Form (sequence of information)
(b)
Q,tt ~~
Content (size of fields, number of classifications)
~ (1A.C>.Mu-J
.~.
tv\
k. Jt/~~ (xxxx. X
)
.
C2~± &~),
C
)
xXX,X
JO~,A14~ (xxxx,x) ~t ~(~~I}()
3i~:M x)(· Ie) :l 0 J~Ii:tL£~ i""-,,. (Joel(') t1:.:J 1vw exxx.x)
eX)
ex
~k
~,~~ (xxxx.x) M~~~'ul (x.>(xx.x) ~~_ ~W(XXXXXIXX)
(c)
Frequency (Presently? With IBM approach to application?) W-U..~ a.Ac.c-~ ~tJ~~
(d)
Distribution
~~) pe\.A.Lt ,~D./VVt,\,t,~d:, ~\.:.t ~\A." )~~\;')
~\~ ~~(l.~ vvu,«-T
1 o. Schedule requirements
w~~
(a)
Length of pay period
(b)
When are source documents available for processing?
(c)
When does pay period close?
(d)
How soon after pay period closes must checks be available?
(e)
How long does it take for changes to clear through the personnel department?
.~
6
clcUO
11. Reporting
€em~
(a)
Who reports payroll source data? Employees? Timekeeper?
(b)
What degree of control does the accounting department have over the people who report data ?
~,4~~~0v~~
12. Management requirements
~l\-.Q...u.A.L.u::t I ~v~ Li; -tk ~t) ~~-t (\V\-U.AA",o...tt~
(a)
Who gets the reports?
(b)
What would they like that their present system doesn't give them? \.
. <1v\. \( p\
,::1,
~,OJ
0
13. Miscellaneous
~u.." ) ~, )
(a)
In what· states do you pay payroll?
(b)
What special deduction considerations are there?
(c)
Is state or city income tax deducted?
1..~
U),\jO')J,
.
j,/\o\..
~JLrn..)z._ Jo,l"O''L Lt~1.{"~A. )
h. ~.. ~~J..L'Vl~.
tr-. ~ftt~ ~'~ld
~~
,
J~,
ll~'~ I ~
i
k-cs-
Section
Subsections
Page.
I
07
50
10
20
ADMINISTRATIVE PAYROLL
Survey Questionnaire - Pay i'oll
1.
2.
3.
How is time figured?
Tenths of hours
(b)
Hundredths of hours
(c)
Hours and minutes
(d)
other (nearest half or quarter hour)
(e)
Incentive or price rates
~
What is overtime?
(a)
Over 40 hours
(b)
Over 8 hours
(c)
Other
X
How prevalent are rate changes?
(a)
How many can a man have?
(b) When?
(c)
4.
X
(a)
~mpo~r permanent?
1~) 4 fU>v '~Al.N
\)~
Does job carry a rate?
How many shifts are there?
Qtl,~
~
(a)
What kind of bonus is there?
(b)
How is it calculated?
~
\S tJ/D O-u.L~~
~Cv'\A..1'.L-
5.
What is employee turnover?
6.
What YTD information will appear on check stub?
7.
How many timekeepers?
8.
~
Are timeclocks used?1\ Is time recorded in tenths or hundredths of hours?
9.
Is there labor distribution?
v'-u"Uv ClLL
~
k
~7
~:rtme9 Operation?
(a)
By job?
(b)
Is average labor cost used?
LGr-
Machine?
Section
10
(c)
Actual labor cost? ~
(d)
How is overtime handled?
Subsections
Page
I
08
50
20
&~u. ~:\,.Q....2lJ
PREPARATION DATA
G:U.~C.k~I~
,---- - ' '-' '-' -'0-.
1.
What are pay periods?
2.
When does pay period close?
G.x.~ ~rv 3~_
3.
~ j.Ju-~A.
cS
What is paying date?/\ Preparation time? Q rYv\,cv~,1·- 4~
4.
How are employees paid?
(a)
(b)
~caSh?
Is envelope used?
'-~
~
5.
How many copies of journals?
6.
Any objection to the use of spot carbon on check?
7.
Should check amount be protected?
8.
Is check signer used?
9.
Do you write payroll checks on more than ope bank? ~
~
~
10. How and when are vacation checks written?
hand~
13. How is sick pay handled'!
Ci.:t...Q.~ ~ ~ \)~
.~
11. How are advances handled?
12. How are terminations
ll.e-
CULQ..
~~t ().....{.; ~\U~ ~.
_
~~~~~t~~
~~, .~~
14. How is holiday pay handled?
...
~
e>-t
:.k J>.-9
99. f 213i
%
6J
7.1
I,
J'9
13.4
I f-! 16.9_~_,(jl ~6
_
6. i
I
1
~:~~ l!~!9()
I
I
--+----1
~;:: 171!-PIJJ
0::.
7.1.1-
ZHt9JI/o.! I/J/.I //1.9
-
/?92.
i
i i 1130.
I I. A I 79 ? - .
.6 I -
997.
-
I
·
6.9
/. 7
:J. 7
/Z7/J!
I
i/O. 7 11),7 I. 7
.f. 9
IJ39.$'"
z~
Shift
Machine
I
Delay Time
Allow.
~~¥
13.7
6.Y
I¢.Z
~_.L+.6
91' ,7.1
15. I
~-
1
I
7.3'/./
/C76.
!
I
5637
/J.
~!_J~2.? 71.1
J.5
I
I .~
2.2
Bonus
H
aurS
M/U
Non
Rate
Bonus
Actu?1
°Hvert,me
ours
Actual
Dollors
.7
-
.J
/375.
.7
-
1.0
/696.
/,1
-
-
/377.
.5
-
-
90J'.
-
-
2790.
_+.7 1.7
---t----
I
JJ,O 36.5
I-
Actual
Dollars
:;).75
Man
!
J.;
LL
Rate
-------~ ---- ---J--- ----)------~ ---------- ---- -----+---l---S
.j""
I
I -
I
i Hours
-
5Y
__
28b651~+~-L7.!'+-.R
I -
Actual
Overtime
I
3.d'
5.0 I
14J.0
Actual Hours
Mach.
1 6.t?
6_r6~~ 7..>--0-'_"74
I 9120
1-/2 /2M,
i
.9
Non
Rate
Bonus
i
I
i9
Eff
I
+__+-_
Week Ending
Non
R t d
a e
J
1./
__
71.7 .6
k~2tJ~1_·6'_ ~-I-~2T·.I'-+9J~~~l4. ~L=+ .6
/J7t?6, .6
6754/4~31~q
HE' 431
Run
7
--
1.2
1.5
/-I.p-{'f
M
I
M
piS
Ft
cs.
I
q..
~
09
30
/,£. __ ~--+-.7---1i--+--T--+--£..-
PRODUCTION & LABOR REPORT
Date
I.t?
I
50
Shift
M/U
1.0
i
1./ I 90 132.5 70.1 1/'7
I
Allow.
Page
Machine
Delay Time
I
i
I
i i
i 6.tf ,/3.1'1
1.6
i
I
S
To
Date
N
on,
Rated I
cf~ I ~f ! /0.9 I / 9--1--7.-~--11--:-11
90--I,---;--9----r-/-'..,-2T"
~.
c:.
~.
+-~-=-- __
3
991"?'?
.t:'rJO
I
;
Total
Subsections
'I
----+----+---+---
i
2.J'",?oF
I
I
3.7
I
2'3 1.7.7
I.Y
I tfl-16
/.0
:J.2
1/7.fOJ
!
4:-0_ I 9_4 Ib6.J If}./ , [ /
!
,f./
l/aJ' //,1"[ /.tJ
193 15IR..J'tCZ~21 7.6
I
-
i.5/ IC5M9
Section
Subsections
10
1
50
30
Page
10
YEAR
NAME
CLOCK NO.
TAX CLASSIF"It;ATION
REMARKS
I
I
ADDRESS
S. S. NO.
TEL. NO.
CITIZENSHIP
EMPLDYMENT RECDRD
IN
1
I
I
PERIOD
ENDING
1
1-
2
1-
3
4
1-
I-
S
1-
6
-7
1-
8
9
110
1-
I-
n
-
12
-13
-
OTR.
14
-15
116
1-
17
18
11-
19
1-
20
1-
21
22
1---:1-
23
1-
24
1-
25
26
11-
OTR.
W-2
AGE
CONSTANT DEDUCTIONS
OUT
I
i
REASDN
YEAR
~ DATE
RATE
PER'
Z
OVERTIME
CITY OR
OTHER TAX
WHTAX
THIRD
oC
REASON
CODE
,,"ORK AVAILABLE
SICKNESS
WA
CATASTROPH E
CONTINUED
CA
DISCIPLINE
0
LD
SELF EMPL'D
SE
LABOR DISPUTE
REASON
FOURTH
!C
REG. RATE
FOAa SI
UNAVAILABIliTY
TOTAL
II:
RATE
EARNED
SECOND
EARNIN GS
HOURS
QUART'R
DEPT. (21
(1)
FIRST
...6
I
DEPT.
OTHERS
DEDUCTIONS
TOTAL
F. O. A. B.
YoITHHOLDING
TAX
A
B
AMOUNT
C
0
OF CHECK
CHECK
NUMBER
CODE
C
Section
Subsections
10
50
YEAR
CLOCK NO.
NAME
[
TAX CLASSIF'ICATION
""""
to. (/(/
Page
11
30
r
ItJ~G
/11-2
/.5.38t.1A·1
~P.I
20. CJOC:t/.
ADDRESS
AGE
DEPT. (2)
DEPT. m
_ --:!:S~S~N~O!:-_ _ _ _ _ _~~~_ _ _--IIIC=ON=&~TATNT~DE=DUfC~TI~ON~&I QAT
CITY OR
..
.
TEL. N C.
If-::--~,R-c-:::;--+R_'_AR_NE_O-+F_OA_'S-+'_W_HT_AX~OT=H
ER~TA,,-X~Ib..-=oRK,--;-R:A=V:~...
~AB=lE+CO_DE--l---R_EA_SO_N+-C---:ODEI
CITIZEI\iS~~ P'~LO~yn;:;M~EN"'T;--O;R;-;;-£C;:;rO:;-;;R-;;-D---,r.:!~E¥n,:A~~E~R~AT;;-E--..;;;-PER;;-II·-I--t----1I=s'c;:;:co=ND+---+--+--+---lI-.c~~I~~TK,:~~S,~SD~W~A~CA~TAS~TR~OPH~E~c-J
-.--IN---r'-O-UT-.---'-
REASON
f------+---+-----------5
40
SCJ(J.tJ(}
.£v.~
ZZ6tJ stJ.OC?
14
t(
MepOL.e
7~
40
.]%14
~.!f4
177C,
~4./f
/f?C?()
15
.L1. LJARAB.4CHErr
7~7
40
7~U3
7~'/.23
-
12~37
8.50
16
R. L. ,sh'E'pH'ARO
7~8
40
8~39
·8GS39
-
14-1.~Z
8M 211M
17
T. TR/SSLER
7~?
4tJ
JZ3.~
323.08 #.22 .2/4
9.IG
18
6.6RO,cT
770
40
~£J8
2~S38
11.70 -1233
19
L.STVOY
771
4tJ
~.14.14
~N·j¢
Z7.tJtJ 1()/.5ti
20
E.WA6NER
772
40
70/J.,/Z
7tJ8.'l2
117'/2
7.577
~f7
7578
7.3/..1.J
7.57r;'
7stJO
75'81
.tf~5.tJ7
7582
391.76
75tH
S.OC?
425.~3
7584
58.77 6.67
12
Y-7~
2tJ.0C?
1/.10
13
-
.3f4r;'7
.3f7~7
9/Cl
M. c/PYCe
CHECK
NUMBER
2<10.53
¢.~~
89:~7
£J. TERR.4MORSE
AMOUNT
Of CHECK
6¢f.%
7.bf
10
8.?O
D
04.14 5()'X
ItJ.3.00 558.
143432 z7.8o /tJ/ffff
63432
5If.?.J
C
24122
7565
28755
7~
21/4f
7587
3?7.4tJ
75'88
303.3'1
75{Y1
~fi!.3~
75'1P
2t?PO
~5.4>2
75'r;'1
lapp
2.M5'~
7.5?Z
2tJ.()0
21/..35' 75'?.1
ff04,78 75'14
l.'ltJ
574.IP
f1()(J 3.f:.~ 1//7.fltff ~l"O 11J16(J 6f.~ 71l11P #,//1 12~~
.f¢.f(211
14.12
7.5?5'
21
22
23
24
i
25
26
27
28
29
3D
TOTALS THIS SHEET
TOTALS FROM PRECEDING SHEET
TDTALS
I
HOURS
..
",
WDRKED
800
l//l?.Iff
/73fi
41flJ.fl 75638 H/..JII $1'11.#
.
J8N7.fI 7.%.~ 'ft£~ ~Df1?JJ !I.lf JIll¢! /If.// JlJ.7J 1m.!
25.1fi
TOTAL
HDURS
In..) ?/4Jn $:fbi lfl.H /i?31?
PERIOD
ENDING
RU:.UTt
HOURS
OY[~TUU
OTHUS
RATE
EARNINGS
TOUl
'.O.ll
DEDUCTIONS
C
2f2/Z .5N/6.~//
.J.7?A?
D
"'/J~.57
AM.UNT
.1
aFCHECK
CHECK
HUMBER
./
Section
Subsections
Page
I
14
10
50
30
I
I
1
I
I
PERIOD
ENDINO
I
I
I
I
RU. RATE
RATE
HOURI
I
OVIRTIIII
I
OTHUS
I
TOTAL
I
f. O. A. I.
WITHHOLDINC
TAX
EARNINGS
I
I
A
B
I
I
I
AMOUNT
D
C
OF CHECr
DEDUCTIONS
I
8123
N~
I
A- CITY TAX
C- Mlac.
THE CONTAINER COMPANY
I
a-INa.
O· CREDIT UNION
COLUMBUS, WASH.
I
PLEASE DETACH
KEEP THIS STUS ,.DR YDUR RECDRD
----~-----------------------------~--------------_._- --_.
.....
.. - - - - .
:C:I.J .. . . : . 1:1[ •
--
I
.-
..
.-
-
."
N~
8123
THE CONTAINER COMPANY
I
123 -4
567
COLUMBUS, WASH.
PAY
I
TO THE
ORDER or
$
THE CONTAINER COMPANY
PAYROLL ACCOUNT NO.2
TO THE NATIONAL BANK & TRUST CO.
OF COLUMBUS, WASH.
I
I
I
W-l
I
I
1_ _
,,,,,,.'-"0 •••• _,," -, ~
."
.--
--
--
.
----,-
'-
_. ....
_.. -
-
_ ..
--
----.
.....
-
'"
...
"
-
--_ •..
.
:--t=2=-2-=68t=4=O==+==4~150==+=1=80~10==t0=0!,===~OO=+=O==,=I0==90F=18=O="",I0==901F=7~18=+l=3=:16 r=I0i==6e=b10==t0='=,=1°=4=°=1"===+=""",",,,,*=1=+==1=29=:1',==18
I
II
PERIOD
~q
~~
REG RATE
OVIRTIIIE
OTHIRS
TOTAL
f. O. A. I.
WITHHOLDINC
ABC
0
EARNINGS
DEDUCTIONS
I
8123
N~
II
AM 0 U N T
UTE~_ _~_ _-~--~----+__~__n_x_~_ _~--~--~---~DFC"ECr
THE CONTAINER COMPANY
COLUMBUS, WASH.
A· CITY TAX
C· Mlac.
a- INa.
0- CREDIT UNION
I
PLEASE DETACH
KEEP THIS STUB ,.DR YDUR AECDRD
r---~--------------------------------------------N~
8123
THE CONTAINER COMPANY
COLUMBUS, WASH.
2-2-68
~
567
PAY
~
LA
TO THE
\
/!")
I'J.A
oRDERor ___
~
____~__~~~~~~'~~'
__
~
____________________
$
129· /8
QXOJi=O.2
THE CONTAINER COMPANY
TO THE NATIONAL BANK & TRUST CO.
OF COLUMBUS, WASH.
W-l
1
Section
10
Subsections
Page
I
01
50
40
SYSTEMS FLOWCHART OF WEEKLY PROCEDURE
Administrative
Time
Cards
Employee
Time
Sheets
Production
Report
Master
Employee
Time
Sheet
Master
Employee
Time
Sheet
Calculate
Gross
Pay
Post to
Payroll
Register
Machine
Activity
Report
Employee
Time
Sheets
Section
10
Subsections
50
I
40
Page
02
Calculate
Statutory
Deductions,
Voluntary Deductions
and Net Pay
Employee
Earnings
Records
Write Check,
Check Stub, and
Post to Payroll
Register and
Earnings Records
Total Each
Column of
Payroll
Register
Total Earnings
Records
Earnings
Records
File
Section
10
Subsections
50
1
Quarterly Procedure
Total Each
Column of
Earnings
Records
Original
941A
1st Copy 941A
Sent to Local
Government
Post to
Earnings
Records
Prior 941A
Calculate
Year-to-Date
Totals
Post to
Earnings
Records
Summarize
Earnings, FICA,
and FIT to
941
Type
941A
1st Copy
941
Write
W2
(year-end only)
2nd Copy
941A
40
Page
03
Section
15
Subsections
Page
I
01
00
00
Section 15: SOME PRELIMINARY QUESTIONS
AND ANSWERS REGARDING DATA
STORAGE
CONTENTS
Introduction ..................•........
Data - on Disk or Cards? ..............
General Considerations ..•..........•
Flexibility in Order of Processing ....
Jobs Involving More Than One File ...•
Frequency of Changes to Your File ....
Need for Inquiry into Your File ......
Size of Your Data File .•.•...........
Your Backup Requirements ..........
Record Size ........................
other Considerations ...............
Summary ..............•..•........
15.01.00
15.10.00
15.10.01
15.10.10
15.10.20
15.10.30
15.10.40
15.10.50
15.10.60
15.10.70
15.10.80
15.10.90
How to Safeguard Your Disk Data Files ..
Introduction ..............•.........
Know Your Data ....................
Know What Can Happen to Your Data ..
Design an Accident-Insensitive System
Detect Errors Before They Do
Damage ............................
Plan Modest-Size, Modular Programs
Always Back Up Your Disk Files with a
Duplicate Copy .....................
Provide Tested and Documented
Recovery Procedures ................
15.20.00
15.20.01
15.20.10
15.20.20
15.20.30
15.20.40
15.20.50
15.20.60
15.20.70
Section
15
Subsections
Page
I
01
01
00
INTRODUCTION
Often, before starting the design of a system, there
are many questions regarding data storage. Two of
the more important are:
• Should I use cards or disks for my data files?
• How can I safeguard my data?
This chapter answers these questions on a broad
basis, leaving the details for later chapters.
Section
15
Subsections
Page
I
01
10
01
DATA - ON DISK OR CARDS?
General Considerations
Before you get too far into systems design and programming, you should ask a basic question about
every data file you intend to use: Should it be stored
on a disk cartridge or in the form of a card deck?
The disk can be an extremely powerful medium
for the storage of your data; however, it can be misused. Some data, if placed on the disk, will cause
your programmer more work in the long run than if
a simple deck-of-cards approach had been used.
In order to lessen the possibility of such a situation, let us answer some of the questions that arise
when chOOSing a storage medium for data.
Section
15
Flexibility In Order of Processing
In general, your data, whether on disk or cards,
contains some master information (names, rates,
balances, etc.) in some order or sequence. When
you process this information, the transactions may
be in another sequence. For example, your employee master data file may be in man -number
sequence, while your employee detail cards are
grouped by department.
In this situation, the disk has a distinct advantage
over cards, since it is a direct access storage device (DASD). This means you can directly access
Subsections
Page
I
01
10
10
any record, regardless of which record was processed last or which record is next. This allows you
complete flexibility in the order of processing.
With your master data on cards, you have to sort
both the master deck and the transaction deck into
the same order, collate them together, and then
process your data in the desired sequence.
Although the disk has a great advantage over
cards, its importance varies with the size of the
file. Are you talking about 100 employees and a
10-minute sorting job, or 1,000 employees and 45
minutes of card handling? In later sections some
other considerations will be discussed that may tip
the scales in favor of cards.
Section
15
Subsections
Page
I
01
10
20
Jobs Involving More Than One File
The previous topic can be expanded to consider
more than one file, which is the case in many commercial applications. For example, many payroll
applications involve a job cost file as well as the
employee payroll file. If an employee detail card
says that man 607 worked 12.5 hours on job 70976,
you can find man 607 in the emp loyee file and add
12.5 hours to his weekly total, then find job number
70976 in the job cost file and add 12.5 hours to its
weekly total, all within one program. A card file
system would involve:
1. Sorting and collating the employee detail
cards with the employee master cards
2. Running the program and punching a new updated employee master card
3. Separating the cards
4. Sorting and collating the employee detail
cards again, this time with the job master cards
5. Running a different progrru;, this one punching a new master job cost card
6. Separating the cards and filing them
Depending on the number of cards involved, this
could be a cumbersome process. But again, some
of the considerations discussed later may override
this one.
Section
15
Frequency of Changes to Your File
A third consideration in deciding on card or disk is
the number of times the data in your file must be
changed, and the difficulty involved in changing it.
Some amount of change is inevitable; in a payroll
file every week will bring raises, new dependents,
changes of address, etc. These minor changes do
not present much of a problem.
With a card file it is very easy; a new card is
punched and substituted for the old card.
With a disk file it is somewhat more involved;
you must run a change program, which reads the
new data from cards or the console keyboard and
inserts it in the proper place on the disk record.
Major changes are another matter - new employees, a new group of items in stock, etc. Here
again, changing a card file is relatively easy, and
changing a disk file more difficult. It is a simple
matter to punch a master card for new item number
1 705 and place it in the card deck between items
Subsections
Page
I
01
10
30
1704 and 1800. It is not quite so simple on the disk,
where items 1704 and 1800 are probably adjacent,
with no space between them. Either item 1 705 is
placed in a special area, with a special routine to
find it, or the entire file is reorganized, moving
every item after 1704 "down" one position to make
room for item 1705. This also would require a
special program or routine.
If a data file is subject to frequent major (organizational) changes, you may add a few points to the
"card file" side of the balance. These points may
or may not be enough to swing the decision, since
the first two items (processing order and number
of files) are more important, and generally favor
disk use.
Remember, when you change a field on a card,
you still have the old card; when you change some
data on the disk (usually an entire record at a time!),
the old information is gone. Therefore, special
care must be taken to ensure that disk changes are
processed correctly the first time.
Section
15
Subsections
Page
I
01
10
40
Need for Inquiry into Your File
In some cases it is very desirable to be able to look
into your data file to get certain current information:
number of pieces of item number 170653 on hand,
year-to-date gross pay of man number 8091, etc.
When your data file is in the form of a card deck,
this is relatively easy, since you merely find the
right card, interpret it, and read the data, much as
you would any other hard-copy file - index cards,
ledger sheets, etc.
People are accustomed to doing- this, and often
resist the change to disk-resident files because they
cannot "see" what is on the disk.
It is true that data written on the disk is somewhat
less tangible than if it were on a deck of cards, but
this is not the overriding consideration it is made
out to be.
True, it takes a special program or subprogram
to read and display data on a disk, so demands for
inquiry do add a few points to the "card file" side of
the balance. However, a properly designed system
can lessen or eliminate these points entirely.
If someone within your company requires, say,
the current status of inventory, it may be possible
to replace his 5" x 8" card file with a daily listing
of stock status, or a weekly listing with daily updates. If he insists on immediate response to
up-to-the-minute status, the programmer can build
an inquiry subroutine into every program, calling it
only when some console switch is turned on:'
CALL DATSW(7, MM)
GO TO (9,10), MM
9 CALL INQUR
10 CONTINUE
These four statements would be placed at a convenient spot in every program. Whenever anyone
wanted to inquire of the disk, he would turn on
switch 7. The subroutine INQUR would soon be
called, and probably request that a part number be
entered through the console keyboard. After the
requested information was looked up on the disk, it
would be typed on the console printer, and the main
program would continue.
Large demands for inquiry sometime s make the
use of card files appear more attractive than disk
files, but proper systems design can often reduce
the importance of this factor. In fact, inquiry into
a disk-resident file is often a plus factor, since the
data obtained would have an up-to-the-minute status.
Section
15
Size of Your Data File
This item is hard to separate from some of the
other considerations. However, all other things
being. equal, putting very small data files on the
Subsections
Page
I
01
10
50
disk is sometimes not worth the extra effort, and
very large data files will not fit on the disk. Most
files fall somewhere in between, and some factor
other than size will govern the final card or disk
decision.
Section
15
Subsections
Page
I
01
10
60
Your Backup Requirements
Whenever you work with files containing important
data (payroll, accounting, etc.), you should not
ignore the possibility of accidental destruction of
this information. Many accidents can befall card
decks ~ card jams in the reader, floods, spilt
coffee, misplacement, etc. Because you can recover from many of these accidents by patching torn
cards, duplicating watersoaked cards, etc., it is
not too common to find duplicate sets of master
card files maintained.
Data files kept on the disk cartridge are subject
to a similar list of accidents, but with a difference:
it is often impossible to reconstruct the data after
an accident, unless you have planned for just such
an occurrence.
Because of the need for preplanning, the matter
of backup may be considered a disadvantage for the
disk file. In actuality, it may be on the plus Side,
since it forces duplicate files.
Section
15
Record Size
Because of the physical limitations inherent in a
punched card (80 columns), it can be cumbersome
to process long records that are kept in card form.
Subsections
Page
I
01
10
70
Each record may require four or five cards, which
must be identified and kept in order. On the other
hand, disk records may be as long as 320 words (640
characters). IT long records are required, you have
a few "plus" points for placing the data file on disk.
Section
15
Subsections
10
I
80
Page
01
other Considerations
In additiQn to the factors noted previously, there may
be others of equal or greater importance - factors
that may be completely unrelated to the particular
data file under study. Some typical factors are the
storage cost of many cards versus one disk, management's wishes, and the desire to train programmers in disk techniques.
Section
15
Summary
This section has briefly covered some of the diskvs-card considerations and attempted to give general
guidelines for making this decision. It would be
ideal if these factors could be presented in the form
of a decision table, score sheet, or other device,
but this is not possible. Lacking such a tool, you
must study each data file, mull over the pros and
cons of disk or cards, and make your own decisions.
Subsections
Page
I
01
10
90
Some companies (especially those installing their
first data processing system), realizing that their
files fall on the borderline, decide to start with card
data files. Their reasoning is correct: The system
may be less sophisticated and require more machine
and operator time, but it is easier to program, use,
and understand. Later, if they decide that a certain
file should be placed on the disk, it is relatively
simple to make the change. The bugs in the system
have been ironed out, the programmers are more
experienced and confident, and the general atmosphere is more conducive to such a step.
Section
15
Subsections
20
I
01
Page
01
HOW TO SAFEGUARD YOUR DISK DATA FILES
Introduction
This section is of particular interest to those using
(or considering) the disk for storage of data files.
Accidents will happen, and you must plan ahead to
minimize their effect. This is especially true in
the case of disk, where data is stored in the form
of magnetized spots, recorded at extremely high
densities, and read/written by a precise mechanism.
On the other hand, hard copy data is relatively
insensitive to accidents. Punched cards can be
folded, spindled, and mutilated (even torn, crum-
pled, splattered with coffee, etc.) without disastrous results. A few minutes (or hours) at the
keypunch can remedy all but the most drastic card
mishaps. Other paper documents (ledger book,
index cards, forms and reports) are not too
difficult to duplicate or reconstruct if the original
is destroyed.
The purpose of this section, however, is not to
discourage the use of the disk for data storage; used
properly, the disk offers advantages that overshadow the potential hazards. If you follow the
common-sense suggestions in this section, accidents can become rare, improbable events - more
a nuisance than a disaster.
Section
15
Know Your Data
Before starting into a long discussion of how to
protect disk data, let us review the various types
of data fields in your disk records and determine
which, if any, are worth protecting. Naturally,
you don't want any of your data lost, but certain
items are more important than others, since they
are much more difficult to replace.
Take a typical payroll file, where there is a
record for each employee:
1. Employee number
2. Name, address, city and state
3. Indicators - marital status, sex, number
of dependents, etc.
4. Pay rate
5. Year-to-date dollar figures - gross,
taxes, etc.
6. Quarter-to-date dollar figures - gross,
taxes, etc.
7. Miscellaneous cumulative - days vacation,
sick leave taken, etc.
Subsections
Page
I
01
20
10
The first four items are comparatively static,
seldom changing, but the latter three probably
change every pay period.
If an accident occurs (you should assume the
worst possible case), the entire record for every
employee is lost. How would you reconstruct your
data file? The first four items are easy - the
latest information probably exists in the form of
a card deck and can simply be reloaded onto the
disk. That is how it got there in the first place.
However, the last three items present a different
picture - they change each pay period. When you
write the updated disk record, this week's total is
written over last week's total, and last week's
total disappears from the disk. Unless you take
definite steps to save it before writing on top of
it, last week's total will completely cease to exist.
Some disk data fields, therefore, are more
critical than others - particularly those that
change often, are modified on the basis of previous
data (for example, year-to-date gross), or are
not kept in duplicate copies.
Section
15
Subsections
Page
I
01
20
20
Know What Can Happen To Your Data
Before you can go about safeguarding a disk data
file, you must know what you are safeguarding it
against. Basically, there are three general
classifications of hazards:
1. Physical hazards. Although the disk cartridge is in a sturdy container, it is certainly not
immune to careless handling, loss, natural disaster, etc. The cartridge should be stored at
moderate temperatures, (between 60 and 90 degrees
Fahrenheit) and should not be placed on high shelves
or other precarious places. In general, common
sense prevails.
2. Intentional modification. Payroll data and
other confidential information should be kept on
disk cartridges dedicated to that use, and should
be kept in a secure place. As in the case of
physical hazards, there is very little else that can
be said about this sensitive area except that
common sense must be used.
3. Accidental modification. Every program
that writes on the disk should be given very close
scrutiny. Ask yourself: Is there a chance that
wrong information could be written on my disk
file? Nine times out of ten the answer is yes. All
you need is one mispunched card column, with the
resulting wrong answers, and you have a disk
record with erroneous data. If the data you are
placing on the disk is of a critical nature (as discussed in the preceding pages), you may have
problems.
Later sections will discuss some of the ways
you may avoid such accidental modification, and
how you may easily recover from them. Some of
the potential sources of such accidents are:
1. Programming errors (program not completely debugged, etc.)
2. ErrQrS in input data
3. Mistakes by the 1130 operator (running a
program twice, etc.)
Section
15
Design an Accident-Insensitive System
The safety of disk data should be a constant consideration when designing a system. "An ounce of
prevention is worth a pound of cure" - or, in data
processing terms, a few minutes spent in planning can
save many frantic hours or days in keypunching and
Subsections
Page
I
01
20
30
computer reruns. An accident may never occur,
but it would be foolhardy to ignore its possibility.
By following a few basic guidelines, the system
may be designed so as to be relatively insensitive
to accidents; no matter what may happen, recovery
is quick and straightforward.
Section
15
Subsections
Page
I
01
20
40
Detect Errors Before They Do Damage
Whenever there is any chance of erroneous data
being written on the disk, you should provide a
series of checks to minimize the damage. If there
is any possibility that input data cards contain bad
data, they should be checked. Your keypunch
operators should be familiar with the business, so
that they can recognize outright mistakes on source
documents. Programmers should be urged to
build reasonableness checks into their programs.
For example, a program that reads employee
labor cards should always check the number of
hours worked and, if the number is questionable,
take appropriate action (such as type a message
and pause).
Program results in the form of printed answers
should be spot-checked before the next processing
phase. Most errors are easily spotted early in
the game, provided someone is there to look for
them.
Section
15
Plan Modest-Size, Modular Programs
At first thought, it would appear that the best
program is one that does as much as possible. Why
have half a dozen small payroll programs when one
could do everything? Unfortunately, however, a
large program that does many things tends to compound errors rapidly.
Let us look at the typical payroll job steps for
each employee:
1. Read employee's payroll labor card(s)
2. Read his master data from disk
3. Compute gross
4. Compute deductions and net pay
5. Compute all YTD and QTD totals
6. Write his new master disk record
7. Print payroll register
S. Print paycheck
9. Print check register
Suppose you wrote one very large program to do
all nine steps and one of the cards for the 56th man
somehow got mixed in with the cards of the 10Sth
man. Your programmer has done a good job of
error checking, so the 1130 types CARDS MIXED
UP and pauses. You have processed 107 employees
- printed the register, written checks, updated
disk records, etc. - with one man (the 56th)
completely wrong. How do you recover?
Correct the cards and rerun from the beginning?
No. Besides printing duplicate checks, that would
compute and write new YTD and QTD totals for
everyone and completely ruin your disk data
records.
Keep going and fix the 56th man later? Possibly,
but how? This would require a special program
to correct his now-erroneous disk record. It would
Subsections
Page
I
01
20
50
also require a handwritten paycheck, a hand
correction to the payroll register, handwritten
totals, and a lot of explaining to the accounting
department.
Reprogram the entire system to be less accidentprone? Yes, but a little too late. It should never
have been written to do so many things.
This example represents an everyday occurrence.
Programs are written this way and cause great
consternation when the inevitable error in input
data occurs - or when the operator enters the
wrong week-ending date, or when the paper in the
printer jams, etc.
A properly planned payroll system, like the
example used throughout the following chapters,
would consist of four programs, not one:
PAY16
• Read Input Cards
• Check for Errors
P A Y04, Part 1 • Read Input Card
• Find Man Number on Master
Disk File
• Perform Calculations
• Update Disk
• Repeat Steps 1 - 4 for All
Employees
P A Y04, Part 2 • When Part 1 Is Finished,
Print Payroll Register Directly
from Master Disk File
PAY05
• Print Payroll Checks Directly
from Master Disk File
PAY06
• Print Check Register Directly
from Master Disk File
The advantages of this plan are obvious:
1. The input cards are checked before they
are used to modify the disk records.
2. Payroll checks are printed after the payroll
register has been inspected for errors.
Section
15
Subsections
Page
I
01
20
60
Always Back Up Your Disk Files with a Duplicate
Copy
Regardless of how the processing system is designed, there should be a duplicate copy of every
disk data file. If you have multiple disk drives,
you can copy from one disk drive onto another; if
you have one drive, you must dump to cards. The
copying (or dumping) should be on a regular basis,
and should not be left to chance or done whenever
there is nothing else to do. Both copying and dumping may be done easily with the Disk Utility Program, as outlined in section 60.
If your 1130 system has only one disk drive, it is
impossible to copy disks, and backup must be in the
form of cards. Either the DUP *DUMPDATA function may be used, or you may write your own dump
program. With large data files, both dumps take a
significant amount of time. For example, it takes
about three hours to dump a 1000-sector data file.
Because of the time involved, there is a natural
tendency to avoid dumping such files. However, an
analysis of a typical situation shows this to be selfdefeating.
Assume an 800-man employee file, contained in
400 sectors. To dump it with a 1442, Model 6,
takes about 60 minutes.
The weekly processing sequence is as suggested
earlier:
PAY16
Edit
30 min.
PAY04
Calculations, Disk Update
90 min.
and Payroll Register
PAY05
Payroll Checks
60 min.
PAY06
Check Register
30 min.
For purposes of analysis, assume the worst possible case - namely, that somehow during PA Y04
the payroll data cartridge is completely destroyed.
(No matter how improbable or infrequent you think
this might be, it can happen.) How do you recover?
If you dump the data file every week, you must:
Reload the dumped deck
30 minutes
Rerun PA Y16 and PAY04
2 hours
You have completely recovered in 2-1/2 hours.
If you dump every other week, and you again consider the worst case (your last dump was two weeks
ago), you must get the data cards from last week,
and:
Reload the dumped deck
30 minutes
Rerun PAY16 and PA Y04 with
2 hours
last week's cards
2 hours
Rerun PAY16 and PA Y04 with
this week's cards
In 4-1/2 hours you have caught up to where you were
before the accident.
If it had been three weeks since your last dump,
the reconstruction time would be 6-1/2 hours; four
weeks, 8-1/2 hours; five weeks, 10-1/2 hours; etc.
Each week adds about 2 hours.
These figures assume that you can immediately
lay your hands on the previous week's data cards in
the proper order. If this is not so, these times
could go up drastically. The figures also assume
that everything goes smoothly during the recovery
phases. This, however, is not a very safe assumption, since the operators will be rushed and unfamiliar with the procedures.
Without knowing the probability of such an accident, it is impossible to compute the optimum dump
frequency. It is probable, however, that you will
not want to be in a 10-1/2-hour recovery position,
no matter how slight the probability, just to save an
hour a week and a few thousand cards.
In this case, the best approach would seem to be
a dump every week for the first few months of the
installation, every other week after everything has
stabilized, and every third week if conditions seem
to warrant it.
Section
15
Provide Tested and Documented Recovery
Procedures
It does little good to follow the previous advice if
your recovery procedures have not been tested and
documented. Usually, time is of the essence, and
the operator should not have to study program listings to determine what to do when accidents occur.
This is inviting trouble and can turn a minor mistake into a disaster.
Subsections
Page
I
01
20
70
If a program checks the input data for errors (as
it certainly should), the error messages should be
self-explanatory or be keyed to a document that explains exactly what to do. For example, a well
written and well documented program will type a
message such as ERROR NO. 6 and pause, waiting
for the operator to take corrective action. The
"run book", or "operation manual", should contain
a complete description of what happened and what to
do about it. Figure 15.1 shows a typical error recovery sheet; Figure 15.2 is a blank copy of the
same form.
Section
15
Subsections
20
I
Page
70
02
IBM 1130 ERROR RECOVERY SHEET
JOB
PAYROL.L
P~Yfb
PROGRAM NAME
PROGRAMMER NAME
JP
PAUSE - DISPLAYED IN ACCUMULATOR
MESSAGE TYPED:
ERROR
MMMM JJJJ
~
I1 I1 I1 I 1 I
AFTER PAUSE, CONTROL TRANSFERS TO STATEMENT
176 , AND:
CL£ARS TOTAL ANO GOES TO .eEAD ,ii D£T~/L C,.c;,e D,
A.5SUM/NG IT 15 THE ,t=/RST CAeO FOR NEW M,4N
DESCRIPTION OF WHAT IS WRONG:
DE7AIL CARD M~AI NUlv18ER JJJJ /.5 LOWER TH~I\I
LI1ST C,LfR.D~ WI-IICH W4~ MMMM-. /75HOUL-O BE'" GQUAL
OR HIGHER
PROBABLE CAUSE:
TilE- DET~/L C~_(?D JUST READ /.5 IIV Tf..IG" WRONG PL~CE".
E~RLIE·R IAI ,HE DECK.
IT 8eLO:\lGS
RECOVERY PROCEDURES:
RE.MOV~
0(/7- 01="- SEQUEAlCF C,L;ROS ~/VD CONTINC/E"
WITI-I JOB. NOL D C..tIRDs k€).-'l()V£D UNT/L PI?OG.f?A,A./f
END
IS RUN ~GA/M ADJClST CONT~OL TOT/-)LS
RUN,
,.c;r
o,c
COMMENTS;
~
c~/eD5
SCORESHEET
I
Figure 15.1.
)
CERT~/N TH~T t-f/HOEVt:R 1l.s0~TED
KNOW...5 TI-I,.qr TI-IEY GOOFED!
/vI.LiKE
DATE
INITIALS
1~;;~81;~ffl
u
7Hli"
I I I I I I
Section
15
Subsections
Page
I
03
20
IBM 1130 ERROR RECOVERY SHEET
PROGRAM NAME
JOB
PROG RAMMER NAME
PAUSE - DISPLAYED IN ACCUMULATOR
MESSAGE TYPED:
I
I
I
I
I
AFTER PAUSE, CONTROL TRANSFERS TO STATEMENT
DESCRIPTION OF WHAT IS WRONG:
PROBABLE CAUSE:
RECOVERY PROCEDURES:
COMMENTS:
SCORESHEET
Figure 15.2.
I
DATE
INITIALS
I
I
I
I
I
I
I
I
I
70
Section
20
Section 20:
Subsections
Page
I
01
00
00
1130 APPLICATION DESIGN
CONTENTS
Introduction. . . . . . . . . . . . . • . . . . . • . . • . .. 20.01.00
Accounting Controls. • . . . . • • . . . . . • . . . •• 20.10.00
Review of Accounting Control
Principles .••.••••.•.•.•.••.•.•.•. 20.10.10
More Specific Sugge stions for Document and Accounting Controls. • . . . .. 20.10.20
Form Design ..•......•.•••.....•..•. 20.20.00
1130 Considerations. . . . . • . . . . • . . . .. 20.20.10
Form Design Principles. • • . . . . . • . .. 20.20.20
Card Design ..••.•.•....••..••.••..... 20.30.00
1130 Considerations. • . • . • • . . . . . . . •. 20.30.10
Card Design Principles. • . • . . . . . . . .. 20.30.20
Design of Disk Data Files. • • • . • . . . . • • .. 20.40.00
Introduction. . . . . . . . . . . . . • . . . . . • . .. 20.40.01
Data. . • . . • • . • . . . • . . • . . . . . . • . . . . • •. 20.40.10
Field Size. • . . • . . . . . . . . . . • . . . . . . • .. 20.40.20
Data Sequence ••..•.....•.•......•. 20.40.30
File Organization. . . • . . . . • . • . . • . • •. 20.40.40
Record Format and Blocking. . . . . . . ..
File Processing. . .. . . .. . . . . . . . . . ....
File Control. . . . . . . . . . . . . . . . . . . . . . ..
Payroll Example ......................
Narrative. • • • • • • • • • • •. • • • • • . • . . . • ••
Card Forms and Console
Keyboard Input •••••.••••.•..•..••••
Console Printer and Line Printer
Forms for Output.. •• •. • . • • • • • . • • • ••
Disk Record Formats. • . • •• • • • •• . • •••
System Flowchart.
Language Selection ••••••..••••..•..•.•
Introduction. • • . • • • • . • • •• • • • • •• • •• ••
Programming Languages ••
Application Programs.. • • • • • • •• • • • ..
Which Programming Language or
Application Program Should
You Use? •••••••.
0
•
0
•
•
•
•
•
•
•
•
•
•
•
•
•
0
••••••
•
••
0..
••••••••••••••••
20.40.50
20.40.60
20.40.70
20.50.00
20.50.10
20.50.20
20.50.30
20.50.40
20.50.50
20.60.00
20.60.01
20.60.10
20.60.20
20.60.30
Section
20
INTRODUC TION
Up to this point, you have been concerned mainly
with planning and gathering facts about the way you
are processing your data now. The next step is to
take this information and mold it into application
designs for the 1130. Follow this plan:
1. Be sure your current-system documentation
is complete. This cannot be overemphasized, because time gained by doing a hasty but poor job in
documentation will be lost later. In fact, it will
probably be lost several times over, because of the
need to sift out errors of omission from other design and programming errors, research the omitted
facts, then rewrite and retest all affected programs.
2. Design or redesign your reports. This must
be done in detail, and all interested parties should
sign off on the new layouts. The forms layouts
illustrated later in this section are sufficient to
guide data processing personnel in their programming. The people who will use these forms should
be shown samples, as they will actually appear,
with real data hand-printed in the formats that are
planned.
3. Layout the cards (see 20.30.00).
4. Draw flowcharts of the procedures you will
follow in processing the cards to produce the reports. Decide what programming system or application program (such as 1130 Commercial Subroutine Package) you will use for each run, and note
it on your flowcharts.
Subsections
Page
I
01
01
00
5. Establish procedures for accounting controls
where you need them. They may be different from
those you are using now.
(Steps 2-5 are usually overlapped to a large extent.
Changes in reports usually require changes in card
formats, procedures, and accounting controls.
Similarly, changes in anyone of the latter three
elements affect the others.)
6. Hold a management review after the first
application has gone through the steps above.
7. Let each person who is programming carry
one of the programs in this initial application
through Program Development (see section 25) to
completion. By so doing, he will broaden his experience quickly, develop a more realistic idea of
the amount of time required for application design,
programming, and testing, and get a clearer idea
of the depth of detail needed in your current system documentation. After this experience has been
gained, review your activity schedule dates and adjust them according to what you have learned.
This section reviews the important considerations of designing accounting controls, forms, and
cards. Then the same payroll example introduced
in 10.50.00 is presented, along with typical form
and card designs and job flowcharts, as well as the
disk record layouts for the programs required to do
this payroll.
To help you decide which language to use for any
given run, this section also covers the considerations that go into language selection. Finally, it
presents an example of a method for estimating the
length of time required to run a program.
Section
20
Subsections
10
I
00
Page
01
ACCOUNTING CONTROLS
This section covers the subject of accounting controls at two levels. The first part, "Review of
Accounting Control Principles", points out the types
of control that are required and serves as a review
if you have set up and used controls before. It ends
with a short summary.
The second part, "More Specific Suggestions for
Document and Accounting Controls", deals with
specific examples of control sheets and methods of
control, and can be used as source material for
setting up your own control documents and procedures.
Section
20
Review of Accounting Control Principles
Accounting controls are an essential part of your
data processing installation. The inherent accuracy
of data processing equipment and the elimination of
many error-prone clerical steps helps reduce the
number of errors in processing; however, good
accountingpractice requires that you have a precise
procedure available to prove and reconstruct the
basic records of the system. Controls are also
necessary to guard the records of your bu~iness
against fraudulent acts.
The accompanying exhibit shows a typical information flow through a system. Information
from source documents is punched into cards. The
first control (AI) ensures that your information was
transcribed correctly and completely. This can be
determined in one of several ways:
1. The cards can be key-verified.
2. Control totals from the source documents can
be balanced against the cOard totals. For example,
an adding machine total of the quantities on a batch
(several source documents) can be balanced against
the total of the quantities in the cards created from
the documents., This same technique can be used
to control other numeric fields, such as employee
number, part number, etc. The total is often
called a "hash" total. If an out-of-balance condition occurs, a listing of the cards provides a means
of comparing the card information with the source
documents, and the error is quickly isolated and
corrected.
3. Document or transaction counts can be used
to ensure that a card document is created for every
trans ac tion.
Since the information in the cards will be used
to update several associated records, accuracy is
of prime importance.
At the time the cards are run through the system
for accumulating control or hash totals, other tests
can be performed.
Fields may be tested for size or reasonableness.
For example, the nature of your business may be
such that the quantities have reasonable limits,
based on the class of an item. Any item exceeding the limit can be so noted for review before
processing. This type of test might keep you,
for instance, from shipping 24 bathtubs to a small
country store as a result of mispunching an item
number for pliers.
Batch size (the number of documents included
in a control group) should be small enough to keep
error tracing from becoming too cumbersome. On
Subsections
Page
I
01
10
10
the other hand, it is not reasonable to control each
document separately.
As the documents enter the process (A2) , the
same control list above can be used on a cumulative
basis to ensure that all the cards from the several
batches that constitute a processing run are completely processed.
Card documents being created by the process
can be balanced against your control (A3) totals.
A control should be maintained on all card files
(A4) . The total from (A3) will be used to update
this control as cards enter the file. Before procesSing a large card file, it is often advisable to run
a trial balance on the file--particularly if the file
is being updated or used as a source of reference
between processing runs. The purpose of this trial
balance is to catch errors in filing, missing cards,
duplicate cards where a change was made but the old
record was not removed, etc.
A control listing of all cards entering and leaving
the file establishes the control total entry and provides an audit trail if it is necessary to identify
lost or duplicate records.
The accompanying exhibit also shows an example
of a simple control sheet. Each time records enter
the file or are removed, an appropriate entry is
made and the file balance is updated.
It is often possible to provide audit requirements
as a by-product of creating normal reports. For
example, the trial balance of your file might be a
stock status report. The value of separate balancing
runs must be determined by experience for each
application and will vary with the experience and
capability of your operating personnel.
The number and types of controls will depend
a great deal on the application. Your own auditors
should be consulted in determining control procedures. Controls and audit trails should conform
with their requirements and should be established
as an integral part of the data processing procedure. Much of the material in subsection 20.10.20
will help you and your auditors design adequate
control forms.
In setting up controls that will operate successfully, the following should be kept in mind:
1. Only those controls that satisfy a need
should be included.
2. The overall system of controls should be
conceived and arranged for when procedures are
being planned. Thus they will be an integral part
of each procedure, and those areas that may have
a tendency to be overcontrolled or undercontrolled
will be spotted.
Section
20
Subsections
Page
I
02
10
10
Has the information on the source documents been
transcribed correctly on the cords?
I
I
I
Does every source document or transaction have an
AI associated punched card?
I
Do figures meet reasonableness tests?
I
gl
Are all necessary fields filled with information?
~I
Register provides an audit trai I.
/,/I~
/#//~
h/'l
"
IP/ll
Ilf/IP
OIlDEIl HU.BEII
/ dill/
"
"
.,
.
"
,
.,
I,
Itll /~-
"
I/s
ItJ /Ij/
1/
/,/ "
/tJ~"-
"
"
10
I"//,s-
"
/1"
IP/17
/17/17
/tJ/lf
/19
lujl .,
I~~.~
ft1 / /.,
1284~,
/I
.,
"
/I
liE. AllIS
/II/i'
/ ' //.
.
"
/0
DATE
5HII'I'ED
1/
III
II
Order register
..-:::....
l
'r ~
/
BATC
/0
DATE
Ke~e/~P~:r
TO:
NO
~V
f'ROM:
?~~
V~.:C.
NUMBERED
.17
/,;{ 3 S
.,j-
!
f'ROM
NO. Of' DOCUMENTS
/.:ldY/
TO
RECEIVED ATTACHED DOCUMENTS SPECIFIED ABOVE
I
DATE
SIGNATURE
I'\,[ASE SIGN AND FORWARD THE CO'Y OF THIS BATCH CONTROL
TICKET TO SENDING O,"T. WITHOUT DHA>.
Batch control ticket
\
CARD SHIPMENT TRANSMITTAL
F'i'""
r,':j"
..
~
TO. III(QltU"(O U. TN(
.[GtiTlItAnoN DAT& F(Wt
us.
SAYINGS 10NO
.:::
..
MT ' : ) •
HN
'-'I~';-'
~::::':::~.'::;'::'.:-:;
D. Do ..
Fte.:'
D" R:
"."T ..........
TO:
Machine Accounting Dept.
DATE:
,AN'I"wH£.rte.
::.::. ~'~:~"C~:,r.
"n. ,••, .....fA
. . . . . . . . . ,"
.0. . . . . . . . . . . . . .
I I
11/25
•
FROM:
......., I
Marketing
THE FOLLOWING PRICE CHANGES SHOULD BE MADE:
ITEM NO.
12
12
13
13
13
DESCRIPTION
NEW PRICE
PEA SOUP
ORANGE JUICE
HAND SOAP
CONDENSED MILK
TOOTH PICKS
2685
3074
1111
2954
4182
$
6.001
3.857
2.200
1 .639
.353
AUTHORIZED SI'GNATURE
Change authorizations
CHANGE REGISTER
FACTOR
DATE
ITEM CODE
11-26
-""""'-
12 2685
12 3074
13 1111
13 2954
13 4182
..-...L.,..--...
Change register
DESCRI PTION
PEA SOUP
ORANGE JUICE
HAND SOAP
CONDENSED MILK
TOOTH PICKS
-~
~
....
FACTOR
BEFORE
AFTER
CHANGE
CHANGE
5.956
3.132
2.253
1.652
.352
-
6.001
3.857
2.20v
1.639
.353
.....-
Subsections
Page
I
04
10
20
Section
20
Subsections
Page
I
05
10
20
Control techniques and devices. A list of control devices and techniques, many of which can be
incorporated into the procedure for any data processing system, includes:
• Serial numbering. The serial numbering of
orders, invoices, checks, etc., provides control
while the data is in transit. Each item or document
in the series or group is assigned a successive
number; an indication of the beginning and ending
numbers accompanies the group.
• Batching with a document or item count. In
batching data with a document or an item count, the
items or documents are counted instead of numbered;
an indication of the count accompanies the group.
This technique can be used to control data, both
before and after it is punched into cards--for example, requisitions, changes, receiving reports,
and punched cards for various analysis reports.
• Batching with a control total. In batching with
a control total, some data field that is common to
all items or documents is accumulated for the control total, which then becomes the basis for balancing operations during processing. The control field
may be an amount, a quantity, an item code, an
account number, etc.; totals based on an account
number or code are known as "hash" totals. An
advantage of this technique is that balancing can
often be performed during regular machine processing operations at no extra cost in time.
• Crossfooting. Crossfooting is the addition
and/ or subtraction of factors in a horizontal spread
to prove processing accuracy. It can be used on a
payroll register to prove that the final totals of
net pay and deductions equal the final total earnings;
this provides control on report preparation as well
as calculating and card-punching operations. In
posting transactions to records that are temporarily
stored in a computer (for example, accounts receivable), crossfooting is used to prove the accuracy of posting, either as each transaction is
posted, or collectively at the end of the run, or both.
• Zero balancing. Zero balancing is an effective method of verification when both detail items
(for example, accounts payable distribution cards
or records) and their summary (for example, an
accounts payable disbursement card or record) are
processed together. Each detail item is accumulated
minus, and the summary plus. The result is a zero
balance if both are correct.
• Negative balance test. It is possible to detect
a change in Sign during arithmetic operations and
either stop the machine or signal the condition for
subsequent review. In payroll applications the sign
check is used to indicate the condition in which
deductions exceed gross pay; in accounts receivable,
accounts payable, inventory, and general ledger
applications it can be used to recognize any balance
that becomes negative.
• Blank field test. This means checking any
data field for all blank positions. As a computer
control, it can be used to prevent the destruction
of existing records in storage, indicate when the
last item from a spread card has been processed,
skip calculation if a rate or factor field is blank,
etc.
• Comparing. Comparing; as a control technique, permits data fields to be machine-checked
against each other to prove the accuracy of matching, merging, coding, balancing, reproducing,
gang punching, and record selection.
• Sequence checking. Sequence checking is used
to prove that a set of data is arranged in either
ascending or descending order before it is processed. It is generally a mechanized operation and
may be performed in a separate machine run or
simultaneously with another operation in one run.
• Visual comparisons. Comparisons are based
primarily upon experience, past performance, and
a knowledge of trends that have intervened. By
knowing the status as of a certain time and observing trends since that time, it is possible to determine to some degree whether present records
represent a complete and accurate picture. For
example, present-period payroll is often compared
against last-period payroll to spot any questionable
variations.
Controls on processing operations. The number
of available techniques indicates the need for a
thorough study of your application and equipment in
order to come up with a system of controls which
is adequate but which does not overcontrol and delay
processing. In so doing, it is desirable to mechanize as many controls as possible. Mechanized controls are always performed at a constant, rapid
speed; manual ones are not. A study of the application will reveal:
1. How closely it is to be controlled.
2. Points in the procedure at which controls
must be placed.
3. The correcting and restart procedures to be
employed at each point, in case the operation does
not balance. If the procedure is a manual one, it
should be clearly documented for operator reference and training purposes.
4. How accounting control responsibilities are
to be divided.
The basis for control during processing must be
established as data enters your installation. This
Section
20
is generally done when transactions are edited and
may consist of assigning a system of serial numbers or developing a document count, a transaction
count, an item count, a tape listing and total
of some field such as quantity, amount, or code,
etc., or a combination of these. When these preliminaries are taken care of, your transactions are
ready for processing.
During report preparation, the primary control
objective is to prove that all items (accounts or
transactions, etc.) are included in the processing
and that arithmetic is performed accurately It
can be assumed that the data itself is correct, since
punching, summary, and posting operations are
proved as they occur.
To ensure the inclusion of all items in the report,
a final control total is developed during processing
and balanced at the end of the run to a predetermined
one. In cycle billing operations, the control may
be an account number hash total of those accounts
that are in the cycle; for other reporting operations
it may be a control total based upon an amount, a
quantity, or another code field. For control of
arithmetic functions that occur during report preparation, the following techniques should be investigated: crossfooting, total transfer, zero balancing,
parallel balancing, reasonableness test, or a combination of these.
Built-in checks and controls. Built-in checks
should be taken advantage of and not duplicated by
programmed or manual controls. They function as
a result of internal machine circuitry and are therefore performed automatically. For example, all
machines have checks which stop the machine for
an operation that is impossible or in conflict with
another.
Computers utilize input/output checks. The
input check ensures that all data is read and coded
correctly. The output check ensures that your output characters are correctly set up for punching
and/or printing.
This discussion does not include all built-in
checks; for more information regarding a speCific
piece of equipment, refer to the reference manual
describing the machine.
The audit trail. An audit trail must be incorporated into every procedure; you should provide for it early so that it becomes an integral part.
In creating an audit trail it is necessary to provide:
1. Transaction documentation that is detailed
enough to permit the association of any transaction
with its original source document.
0
Subsections
Page
I
06
10
20
2. A system of accounting controls which proves
that all transactions have been processed and that
accounting records are in balance.
3. Documentation from which any transaction
can easily be recreated and its proceSSing continued,
should that transaction be misplaced or destroyed
at some point in the procedure.
The audit trail shown in the accompanying exhibit might be found in an accounts receivable application. The original or entry sales register is
prepared by date of entry immediately after the
cards have been punched or activated from a file.
All punched .information is listed on the register
in detail, so that if a transaction has to be recreated
at some later time, reference to the source document will not be necessary. To prove the accuracy
of the register's preparation, its final total is
balanced to a predetermined one; if the two are
equal, the final total is also posted to the control
sheet. The sum of these individual totals on the
control sheet establishes the final control total to
which all accounts receivable operations for the
period must balance.
Cards for the cash receipts book are either
punched or activated from a holding file. After
being prepared in detail, the cash receipts book is
balanced to a predetermined total. If it is in balance, the final total is posted to the control sheet
and the receipts are posted to accounts receivable.
When the aged trial balance is run, the final total
should equal the difference between total debits and
total credits to accounts receivable; this difference
is available from the control sheet. If the totals do
not agree, all the transactions for the accounting
period can be sorted into entry date sequence, summarized, and checked against the daily entry totals
on the control sheet to isolate the entry date that is
out of halance. The transactions for that date are
relisted; an entry-by-entry comparison on the duplicate and original entry registers will reveal the
discrepancy so that a correcting entry can be
initiated.
The sales register and cash receipts book provide documentation that is sufficient for reconstructing a transaction or associating it with the original
source document. Balancing each register to a
predetermined total proves that all transactions in
the group have been processed through that point.
The entries on your control sheet provide the means
for balancing accounting records at the end of the
accounting period.
Section
Subsections
Page
I
07
10
20
20
O ............. "' .. V·"'(:TU·'_c:O .. " ..... "
SALES "IGtSTE"
Eltr SHAN'" ""ITH SRK
sa
SHANK RIGID
SOL T ...NO NUl SHANK
ANO SPA RING STEM
1 7
J
11
°°
21
",0
10 '
FREIGHT
so SOCKET RIGID
CuSTOM BulL T
RND SPA RING STEM
fLAT TOP SWivEL
FRE 16HT
7
2 liB
2 1123 101 I
21123 10 7 1
2 1123 1011
2 1123
1
21123
"""
"
"
;: :J::I
16102 130!>2
71 )1
13052
& 13052
, }2
1
052
1 0!>2 107
ill
1
1 30!>2
"
! !~
~
~;
O.
: i:
10
E ).lENS ION SHANK
AOJ AD"PTER ROUND
BOL T "NO NUT SH"NK
FREIGI-4T
; :.
g~
pi
780510.
7:~;~
.21 "
1>1
)1
:,
;:~;~Io:, ~:
AT A.NGLE HEAD
SlD PIPE STEM
(uS-10M BUll T
FREIGHT
I 42 021 30541
317 0
I )0541 I
121 )0541
• >t
I )054) 7
I 30!>.)
FLAT TOP RIGID
(uSTOM Bull T
FLAT TOP SWivEL
FLAT TOP AlGID
CuSTOM Bull 1
FREIGt-iT
I 31 02
I 5102
5 32 08
63108
10
• >t
E"lT S""lAr'iK wi TH BAK
S'; SO(I(, T Swl'lE:..
FLAT TOP SWIVEL
"NO SPR RING STEM
CUSTOM Buill
FRE luHT
I 12 03 2
, OJ 022
1 l ' 0' ,
, 'I 0' 2
10 ,
• ~I
2
)1
1>1
)1
~:
pi
")5>10,
2 1)>5
2'355
4
, 1)5,10,
, 1355
213554
7
2
10,
~:
~:11
"'10'
,ql
...
)1
'."" ,,
''" 10' "
'
)1
I
I 11
51
,
, .... ~:
I
I
I
Jl
CASH "'ClII'TS "EG'STE"
1235
12351(
lZHl'
.. il :
11 0
!12)!»
~~~~l
0
HA!qOWAR£ co
UNION SUPPLY
C£NTIi'fAL
CH"'NEL.. WHOLES'"'L..E
COVENTRY OIL
HA5K£L..
INO S!JPP CO
K[;.LVINAIRE
CORP
MAIZE
!qE~INING
CO
NEWTON .. AAIC
"NO
co
ME)( I CO CO,-"P"NY
NEW
0"5
ANO ELEC CO
vESTAL STEEL co
Fit .. I LWAY
WINTERO"LE
0
12)52
123!>2
12352
121!>2
12352
121~2
1235
1215
12351
12l!>
12l!>
12)!>4
12354
123'H
1235lt
i2354
12355
12)5!>
i2l5!>
12355
12355
12355
12355
12'356
12'356
1235b
12)56
1])5&
1235&
12 3~b
0
0
0
8062 2 5 1 )
8251 ) .. 7 1
112}
22079
19285 195:
)6512
11'
59151 1)67
61221 22·6
78050
7',
87652 1616
.92117
'691O)
500 100
9 5 0 ~9 7
1
415 "
)81 166
Z)18
1686
2285
I"'" 1
I'"
'" I: i:;1 ~
2)25
0"52
9562
1'°. 1 ,8
18.
""
,,
18,
13~0
1000'00
105Slo,
1"6161
6501.0
i .'-.
89~0
1)4;~O
) 01 1198
6~0
""
.,
11<0.
l'
2l~'
''''
21<>.
<:,>0
'1'''
11: 7 7
I
211125261180
",*,5
I,..
42~4
116+5'
907"5
'0
"
351t8
16~8
19$5
"t"
"'0
1)1
~$;
261180
7,
1760
13~·0
119~~
,J.8
72:&0
9.175
111'1
,
,,I
l~~~
'0 llq'f a
<48,
I~I
17~O
20
50
Incoming transactions
listed in detail for permanent
audit reference
.
~41116~)
;
."'.
121:50
12l()5
11000
qt.-O'
121~O
..... 0
12105
IlfJOO
19i.!>O
88~'5
70~'1}
:
14~0
'"t,>o
Bell7!>
'>2
1'1~0'
I
I
,
714ti)
14 3 f2
112+1
"'i'
1b~.
'"
1/:
J
ACCOUNTS "ECEIVABU
c:ot(I"lIOL SHIp
o
._
o
uI5"5"
1
,I""
,
S 1/"
...
1
III/
"
.zit "
71",117
7s1 \.ll
2ZI.z 1$
.1 7.5111.,.
I 1/,
Jol~
~" I~
.J. 11;. ~.z
.5ol"S
,
.Jsl.z.s
I",ffo
Totals are posted
to the control sheet
from both
daily registt:rs
____-...-.--10"""
.U
J'
7.n'l1s7
91.5n 07
fl¥1l'lI,,,
III lJ
7if.2.sI.U
, Ifl U
f17orl'1
17fl'-l
•• .....r .... ·
Ch~O
Trial
.... III
~
J/
Balanc~
)61165
"'90,00
9)1,95
40 7 ,02
)81,66
252'56
I
6915,07
I
2to'
492117
761 1' 1
"}
0
I
Audit trial
0
~
I:
i', ~
,ZZ92
" I: ~:; ~
I: ~:~ ~
1506
2'00
450)5 1 0 7 .
58091 2219
610 ..
• 1 8
0
lNVOIc.a
1
~ ~ l:g l
10,,19)
1"6161
650,40
I
6904121
,
1,'8
10,00
0
19,02
0
5:05
0
8,'1
,
Z1110
I
I
70:86
~
0
0
Section
20
FORM DESIGN
The first part of this section, written for persons
familiar with punched card processing, deals with
1130 considerations only.
Subsections
Page
I
01
20
00
The second portion is more detailed and serves
as an introduction to the subject for those who are
new to automated data processing.
Section
20
Subsections
Page
I
01
20
10
1130 Considerations
1. The ability of both FORTRAN and the 1130
Commercial Subroutine Package to provide heading
information can greatly reduce the cost of forms.
Standard stock forms can be used for all internal
reports, and appropriate headings can be provided
at the time the report is prepared. Setup time can
be significantly reduced by eliminating the need to
change forms in the printer.
2. The 120-character print line is probably at
least equal to your present capacity. Consider
printing narrow forms two-up --that is, two pages
side by side (on special paper for splitting), printed
at the same time. This teclmique can double your
output or can avoid the need for extra runs or extra
carbon copies where the number of required copies
is large.
3. The extra speed of your printer (1403) may
allow you to make some short runs twice instead of
buying expensive multiple-part paper just for those
runs.
4. Interchangeable chain cartridges for the 1403
allow you to improve the appearance of certain
reports by providing a variety of special characters.
Also, printing speed can be considerably improved
by selecting a character set containing only the
characters you need.
5. The ability to have both the 1403 and 1132 on
line can save time, in some cases, by eliminating
the need for rerunning cards to produce a second,
different report.
Section
20
Form Design Principles
The design of effective, economical forms reqires a
certain amount of preparatory evaluation and
analysis. The major objectives are legibility,
simplicity, economy, and efficient preparation.
Local IBM representatives should be consulted
early; their guidance and reference materials may
help avoid costly mistakes. steps to be taken in
forms de sign are:
1. Establish the need for the new form. Similar forms may exist which, with minor changes,
will satisfy the new requirements.
2. Study the machine to be used for printing.
In so doing, use the reference manual for that
machine; most manuals have at least one section
devoted to the tape-controlled carriage and/or form
deSign. These sections contain valuable information
about forms specifications as well as different
printer characteristics and operation.
3. List all types of information to be recorded
and the number of positions that will be allotted for
printing each. In doing this, assemble and study
past and present statistics. These can be evaluated
in light of future plans and then used as an indication of probable needs. One of the greatest
weaknesses in forms design is the tendency to
burden a form with unnecessary information. Since
entire data processing procedures may be geared
to the preparation of a certain report, extraneous
information can be costly.
4. Layout the form on a printer spacing chart.
(See Figure 20.17.) In using the spacing chart the
following tips will be helpful (some will be discussed in greater detail later):
• Use bold type to make special information or
headings stand out.
• In columns for figures allow sufficient space
for the largest amount plus punctuation.
• Place filing information near the top of the
form.
• Ti tIe the form.
• Include form number, date, and page number.
• Keep headings small, to allow room for
written data.
• Consider total headings at the bottom of the
form.
• Use different-colored copies as an aid in
routing.
• Use double-ruled lines to set off sections.
• Avoid horizontal rulings as much as possible.
• Consider guide marks for names, addresses
and folding.
Subsections
Page
I
01
20
20
• If possible, choose a standard form width.
• Make certain that the form length is compatible
with the spacing to be used.
• Include a guide for forms alignment in the
printer.
5. Make a test using a copy of the proposed form.
Examine the report carefully to make certain that
zeros are printing properly and that amoUnt fields
are large enough.
During the creation of a form the designer should
understand and keep in mind the following:
Form width. The overall width of a form is
important in determining printing space. Although
the IBM form-feeding devices available will handle
a great variety of document sizes, certain practical
aspects should be observed.
Form costs can be reduced by confining widths
to the standard sizes of paper stock used by business
forms companies. (These sizes can obtained from
the companies; reference to the individual machine
manual will indicate which are acceptable. )
In addition, width standardization permits (1) purchase of report binding and filing supplies in fewer
sizes and greater quantities at reduced cost, (2)
more convenient forms handling, and (3) a reduction
in the setup time of form-feeding devices.
Form length. The total number of body lines in a
form (regardless of whether six-or eight-lines-perinch spacing is employed) can be any whole number,
up to 132. It should be evenly divisible by two in the
case of double spacing, and by three in the case of
triple spacing.
Horizontal spacing. All printing is ten characters
per inch. Vertical lines separating fields and
decimal positions should be drawn so that each splits
a printing position. If they are drawn between adjcent positions, paper shrinkage, variations in form
insertion and alignment, as well as other variables,
may prevent satisfactory registration during printing.
Vertical spacing. The vertical spacing of the
printers is under operator control and can be set
for six or eight lines per inch. The importance of
this is that double spacing at eight lines per inch
permits 33-1/3% more lines to be li-sted on a page
than double spacing at six lines per inch. While it is
true that six lines per inch at single spacing gives
more items than eight lines per inch at double
spacing, the latter offers increased legibility.
Form skipping. The maximum distance that can
be skipped without losing machine time is not the
same for all printers. The individual machine or
systems reference manual should be read so that
little or no processing time is lost.
Section
20
Subsections
Page
I
02
20
20
Form alignment guide. If possible, a guide for
form alignment should be determined and preprinted
on each form to facilitate machine setup operations.
It is important that a description of the form alignment guide and its use be included in the operation
manuals. A delay in machine setup will create a
delay in processing.
Numeric amounts. In determining the number of
print positions needed for numeric fields, the size
of the total must be provided for, rather than the
size ofthe detail amounts. If marks of punctuation
are to be machine-printed, the size of the field
should be checked to make certain that printing
pOSitions have been allotted.
Printable characters. The standard printable
characters are:
A-Z
o-
9
+/ (
- $)
&*=
More information may be foupd .. I '".• '~ appropriate
machine reference manual.
Marginal perforations. Most forms have a vertical perforation 1/2" from each side. Sometimes,
however, forms are designed with dissimilar
margin widths. For example, a form with an overall width of 9-7/8" may be perforated 1/2" on the
left and 7/8" on the right, to leave an 8-1/2" x 11"
letter-size report after the marginal strips are removed. Many such variations in margin size are
used. At least one unused printing position should
be left between a machine-printed character and a
perforation.
Since some report binders utilize the form-feeding holes for binding, many reports are set up with
no perforation on the binding side. The practice of
eliminating perforations and letting the form-feeding
holes remain on both sides of the finished reports is
being followed more and more, particularly with
internal reports.
Binding. In most cases, it is desirable to minimize binding space in order to reduce form cost.
Therefore, information that will be referred to
least should be placed nearest the margin, since it
becomes more difficult to read information near the
binder posts as sheets are added to a binder.
Because of the amount of space required for
headings, many forms can be bound at the top, with
no sacrifice in readability. If it is desirable to bind
continuous forms without bursting them or binding
them on the side, binding hole s can be punched in
both the top and bottom of the forms.
Carbon copies. Substantial savings can be realized by mininizing the number of carbon copies.
Some techniques that are effective in doing this are:
1. Side-by-side duplicate reports
2. Consolidation of reports for multiple use
3. Sequence-routing of reports to different departments, instead of simultaneous distribution
4. Mechanical or photographic reproduction
Any report that is subject to constant usage, such
as a weekly timesheet, should be prepared on a durable grade of paper., For most multiple-copy work,
the first, or original copy and the last copy are
heavier in weight than the intermediate copies.
Lighter weights of paper have less cushioning effect
on the printing impact, and therefore permit more
legible printing on multiple copies. On the other
hand, the paper must be of sufficient weight and
strength to prevent tearing while feeding or ejecting
forms.
The carbon paper used should produce the required number of legible copies without excessive
smudging. Various carbon forms in use include:
1. One-time carbon. This is used once and discarded.
2. Carbon-backing paper. The carbon surface is
on all or part of the reverse side of the original.
3. Chemical-coated paper. The chemical coating
on the back on one sheet reacts with the coating on
the face of the next, under the impact of the printing
mechanism.
Type style is also an important consideration for
multiple carbon copies. Standard type gives maximum legibility. A smaller type style tends to "fill
in" when printed through several sheets of paper;
with a bolder type style the force of the hammer
blow is spread so that sharpness and density are
decreased.
The legibility of some special-purpose type is
limited. Since it is fixed in size, the more characters that are crowded within the area, the smaller
each character becomes. Therefore, as the number
of carbon copies increases, the difinitive lines of
each character seem to become broader. The result
is a character that is difficult to read.
In some cases carbon paper is narrower than the
form. It may be held in place by a fastening technique at the horizontal perforations between forms,
or by some other method such as stitching, gluing,
or marginal perforations.
Section
20
The recommended maximum distances between
fastenings are:
Form Length
1 to 5 inches
5-1/2 to 11 inches
Maximum Distance
between Fastenings
5 inches
11 inches
11 to 14 inches
7 inches
14 to 17 inches
8-1/2 inches
For forms more than 17" in length, the maximum distance between stitches should be determined by actual test.
Subsections
Page
I
03
20
20
If staples are used, they must:
• Be located out of the printing area.
• Be properly crimped so they won't catch on
guide edges or staples in succeeding forms.
• Not cause excessive bulging during feeding,
particularly at the out-fold.
Form types. Depending on its purpose and destination, the form on which a report is printed may
range from the least expensive blank stock to custom design. Imprinted stock forms are standardsize forms which are stocked in large quantities
and upon which lines, headings, markings and some
designs are printed as desired. Custom forms are
those designed to fill special needs of size, complexity, and design. Although more expensive, they
can be used advantageously to "sell" your company.
Section
20
Su bsections
Page
I
01
30
00
CARD DESIGN
This section is divided into two parts. The
first provides information that will be useful to a
person who has had punched card experience but
wants to become familiar with the considerations
unique to the 1130. The second deals with more
basic card design principles. A more extensive
coverage of the subject is contained in the IBM
manual Form and Card Design (C20-8078).
Section
20
1130 Considerations
1. Lining up similar fields between cards is
desirable for ease of recognition, for offline
punched card processing, and for ease of card
handling. A program can as easily define a field in
one set of columns as in another.
2. The results of calculations often do not have
to be punched into cards. It takes but a few milliseconds for the computer to recalculate the same
figure the next time it needs it.
3. The EBCDIC character set contains 256
possible codes. However, many of them cannot be
handled by standard FORTRAN programs. Only 53
characters are permitted in card input (see the
FORTRAN manual, C26-3715); of these, only 48
may be printed by the 1132 Printer.
Subsections
Page
I
01
30
10
4. Normally, an II-punch over the units position of a field indicates to the 1130 Commercial
Subroutine Package that a field is negative, while
a 12-punch or no-zone indicates that it is positive.
The combinations (11-0) and (12-0) are not valid
FORTRAN codes. However, the 1130 Commercial
Subroutine Overlapped I/O Package can handle them.
5. Punching speed for serial punches (1442)
varies with the last column punched. For example,
if the card is to be punched in cc 1-10, 176 cards
per minute can be punched on a 1442, Model 6. The
same data can be punched in cc 71-80 at only 49
cards per minute. Therefore, fields to be punched
should be placed close to column 1. Fields to be
read can then be placed anywhere to the right of
fields to be punched, with no effect on card reading
speed.
Section
20
Subsections
Page
I
01
30
20
Card Design Principles
Determining Card Data
The first step in card design requires a study
of the final report that is to be printed from the
card and a listing of data needed for it. Next the
procedure is studied, and any data needed for processing but not for the report is added to the same
listing. Every item is recorded on a worksheet.
Provision must be made for recording in the card
all data that is listed, unless it is calculated or
otherwise generated.
A check should be made that the necessary
reference data is included. Reference data should
be sufficient to:
1. Identify the transaction with the original
source document from which it was created.
2. Indicate the date on which the transaction
occurred.
3. Establish some reference, such as invoice
number, batch number, account number, or
salesman number.
Care should be taken to avoid duplicate or unnecessary reference data.
Determining Field Size
The number of pOSitions required to record each
type of information should be determined.
The size of the field for card codes, invoice
number, and account number is determined by the
largest single number to be recorded. With
quantity and amount fields, the largest amount
that will occur on a reasonably frequent basis must
be determined, rather than the largest it could
ever be. If the largest possible amount is lmown
and its chances of occurring are rare, multiple
cards may be punched for the transaction.
After all card data is listed, the number of
columns required should be added. If this is
between 80 and 100, it may be possible to reduce
it to 80. If it is over 100, an additional card is
evidently required. At this point a check should
be made to see whether the fields can be rearranged so that all transactions need not have
multiple cards, but could have if necessary.
Master information can be punched in one card and
variable information in the other. Sufficient reference information must be included in the second
card if sorting is required.
Some techniques to be considered for reducing
the number of card columns are:
• Reduce the size of reference fields by repeating the numbering series more frequently. For example, invoice number may start with 1 each quarter instead of each year.
• Record in the eleventh and twelfth punching
positions various codes that may be using a separate punching position.
• Avoid unnecessary data: for example, the use
of both an order number and an invoice number may
not be necessary if one will provide adequate reference to the other.
• Reduce the size of reference fields by recoding. It may be possible to eliminate several positions.
• Reduce the number of columns required for
recording reference data by ignoring positions that
are not essential for this purpose.
If more than one card is to be used to hold a
"record", the division of information between the
cards can be made on the following bases:
1. Place constant information in one card
(master) and temporary information in the second
card (detail).
2. If more than one source document is used,
place the information of each document on a separate card and code the cards.
3. When one transaction affects two different
accounts, design a card for each account with
differing degrees of detail as required by each
account.
4. For printing a bill, order, or other notice,
design a card for each section of the form. Some
of these cards (for example, name and address
cards, constant data cards) can be reused.
Determining the Sequence of Fields
Four basic factors are involved in determining
field sequence:
1. Sequence of data on the source document
from which the new card will be punched
2. Machines and programs used to process the
new cards
3. Manual operations in which the new card will
be used
4. Location of identical data in other cards with
which the new one will be processed
Keeping the sequence of fields similar to the
order in which the data is read from the source
document will make the keypunching operation
faster and more accurate. This is especially
important since keypunching is a manual operation
and therfore subject to far greater fluctuation in
Section
20
speed and accuracy than the subsequent mechanized
operations. The sequence of fields can be arranged
to take maximum advantage of machine characteristics. Specifically, field sequence can be designed
to maximize the usage of card punches, sorters,
computers (see 20.30.10), control panel wiring, or
the manual handling of cards. Placing data in the
same columns of the new cards as used in other
cards ensures that sorting and controlling the data
can be speedily performed when the cards are processed together. It also simplifies control panel
wiring where cards are processed by standard
punched card machines. If data on the new card is
to be checked visually by manually fanning a deck of
cards, the fields for that data should be located at
either the left or right end of the card.
Using a Card Layout Form
A multiple-card layout form (X24-6599) should be
used when planning several cards simultaneously
or when planning a new card that will be used with
existing cards. The use of this form makes it easy
to align those fields that are common to more than
one card, where this is desirable. It also makes
working with the formats easier, since they are on
one sheet of paper and can be compared with one
another.
Designing the Card Form
After field size and sequence are established, the
design of the card itself can be done. This is
usually drawn on a special form cons iderably larger
than the punched card. Photographic reduction is
used to create the proper-size print plate (called an
"electroplate", or "electro").
It is not always necessary to design a card form
for each card used in an application. Where the
cards are used only within your data processing
department, are interpreted, and are needed only
in small quantities, it may be advantageous to use
a standard card form, such as the IBM 5081.
Certain principles in the design of card forms
should be kept in mind:
1. Field and box headings should be explicit and
fo rce writing into des ired locations.
2. Adequate space should be allowed for accommodating written information.
Subsections
Page
I
02
30
20
3. The right-hand side of a box containing handwritten information should be at least five columns
to the left of the columns in which it is to be
punched. This is so that the data will not be obscured by the punch station of the card punch
machine when it is time to punch it.
4. Information to be punched should not be handwri tten along the bottom edge of a card, since the
shield on the IBM card punch obscures the lower
1/8" of the card.
5. Field headings should be above the zero row
of a card unless interpretation or printing of
punches prevents it.
6. Headings and interpreted data should be kept
between rows, so that punches will not obliterate
them.
7. Preprinted decimals and commas should be
placed where dollar amounts will be interpreted.
8. Colored cards, colored stripes, and corner
cuts may be used for visible distinction between
cards. Also, an identifying punch (called a "key")
may be used.
9. Card column numbers should be preprinted
where possible and digits should be placed where
the numbers can be punched. These aid in reading
the punches in a column.
10. Mark-sensing fields should be placed on the
right-hand side of a card, so that the card can be
easily held and marked.
11. Card or company names should be printed on
the ends of a card.
12. When coded punches are used, decoding
abbreviations should be preprinted on the card.
13. Where no more than 40 columns are needed,
a sectional or "tumble" card may be des igned in
which the layout in columns 1-40 is duplicated
upside-down in columns 41-80. This allows the
card to be used twice and cuts card costs in half.
Testing the Card Layout
After the card layout is developed, the fourth and
final step in card design is performed - namely,
testing the card for its effectiveness. For the test,
the new design must be laid out on several cards
and the cards must be used in their designated
procedure.
Section
20
Subsections
Page
I
01
40
01
DESIGN OF DISK DATA FILES
Introduction
The formats of cards and form s are the tangible
types of input/ output. You still must design the intangible record formats.
Your 1130 Computing System is concerned with
two different intangible records: those in core
storage and those on the disk cartridge. Although
the storage media are different, the design considerations are the same.
The items discussed in this section concern the
components of disk records, the order of the components, and groups of records. Considerations
covered include growth, organization, and content.
More detailed information on many of the topics
covered here may be found in section 80.
Section
20
Data
Subsections
40
I
10
Started _ _ _
FILE DESIGN WORK~HEET
Dote
Completed _ _ _
Designer
File Nome
Process Cycle
MO
WK
YR
Charactc:r Silt:'
MIN
MAX
Vdr.
File Media Requirements
File Dynamics
Record Characteristics
Type:
Fixed
NO. REC.
AV
A
YRLY%
ADD
YRlY%
DROP
B
C
5 YR %
GROWTH
D
TOT NO.
REC
E
AMOUNT
TYPE
5(B-C)=D A+AD=E
Inform3tion Required for Processing and
Reporting
Sequence
Field Size
Type of Inform J tion
Required
TRIAL
Figure 20. 1. File design worksheet
01
include an additional deduction field in your payroll
appl icat ion.
• Determine any additional information needed
for planned applications. It may be more practical
to include an extra field now than to reorganize your
files later.
• Study the feasibility of consolidating existing
data files into a single data file to eliminate duplication of common information, if such a combined
record would not too adversely affect the running
time.
• Ascertain whether material needed in a new
application, for which the data file is to be designed,
is available already in an existing data file.
• Verify that the data file, when set up, will
contain all the basic information to meet the requirements of all persons who will be using the products resulting from the file processing.
• Consider file maintenance and audit control.
The first step in file design requires a study of all
procedures that utilize the file. On the basis of
these studies, record each necessary item on a
worksheet like the one illustrated in Figure 20.1.
Indicate the type of information, the frequency of
occurrence, and the sequence in the source document, if applicable. The following should be done:
• Check that the necessary reference data is included, if this is a source file.
• Weigh the effects of media storage costs vs
program execution time for constant-type data, such
as tax-exempt dollars in payroll.
• Include fields obtained by processing, if the
results must be recaptured later.
• Examine all applications that utilize the file,
in order to prevent omission of necessary data.
• Explore future requirements of the current
procedures. For example, it might be judicious to
DA
Page
TRIAL
TRIAL
FINAL
IN
SOURCE
OOC
IN
IN
RECORD
RELATED
FILES
REMARKS
Section
20
Subsections
Page
I
01
40
20
Field Size
File Size (Total Number of Records)
The number of positions required to record each item
of information should be determined and entered on
a form similar to that shown in Figure 20. 1.
Since the field size affects the total record siz"e, all
unnecessary positions should be eliminated to decrease I/O time and storage media requirements.
Type of Field
Future Requirements
Control and indicative data field size should equal
the total number of digits in the largest single item
to be recorded in the particular field. Occas ionally,
to conserve storage, the high-order digits may be
disregarded for a field such as order number.
Quantitative data field size may equal the total
number of digits in the largest amount to be recorded,
or the number of digits that will occur with reasonable frequency. Procedures can be developed to
handle the rare exceptions.
If the demands to be placed on the information ind i-
Recording Medium
Since some media, such as cards and disks, contain
a fixed number of positions per unit of storage (card
field or disk sector or track, etc.), it is essential
to consider this overall limit in order to design
efficient and practical records.
Example:
On the 1130, your disk records are automatically
Itblocked lt within 320-word sectors. A 55-word
record will be blocked 5 records to the sector
with 320-(5x55) or 45 words unused. Rather than
waste these 45 words, you might as well increase
the size of the record to 64 words, which will
still allow 5 per sector (5x64 = 320) with ~
waste. Or, if possible, reduce the record size
to 53 words, which permits 6 records per sector.
cate an impending need for another position, it
would be easier to incorporate the additional character in the design phase so as to avoid reprogramming
and a patched -up record layout.
Field Compaction Techniques
Because a reduction in the length of a record produces such positive results as an increase in DASD
packing and a decrease in time to read and/or write,
field compaction techniques should be investigated
and the cost of the technique evaluated as each file
is designed. Some methods to consider for reducing
the number of positions are found in 80.60.00.
A given compaction technique must be evaluated
for:
1. Amount of core storage required to hold the
encode-decode instructions
2. Encode-decode subroutine timing requirements
3. Compaction percentage achieved
4. Compatibility with programm ing systems
5. Retention of collating sequence
6. Retention of fixed field length
7. Effect on the overall system, including related clerical functions
Some of these methods are discussed in detail in
section 80. For a discussion in depth of compaction
techniques see Record Compaction Techniques
(E20-8252) .
Section
20
Data Sequence
Data sequence is most critical for those files that
work with source documents. Card punching, terminaloperations 3 etc., being manual operations, are
subject to the greatest variation in rate of production.
Anything that simplifies these functions tends to ensure a faster and more accurate operation. The following are points to bear in mind:
• Recording of data in the same order as that in
which it is normally read. If the data sequence is
considerably different from that on the source document, it may be necessary to redesign the source
document and retrain personnel. If the file is to be
used as input to a serial I/O unit, such as disk to
card, the sequence is dictated mainly by the sequence desired on the output unit.
• Location of like fields in the same relative
record pos itions in files that work together. This
Subsections
Page
I
01
40
30
ensures that sorting and controlling can be accomplished if the file is contained in cards; it also
facilitates programming.
• Placement of sorting fields adjacent to one
another, with the minor code on the right and each
progressively higher code to the left. Although sort
programs can operate on multiple-control fields,
time is used to extract and combine fields into a
single key.
• Compatibility with computer characteristics
so that data sequence does not affect processing
speed.
• Arrangement of alphabetic/alphameric data in
one area of the record. This facilitates handling of
data, particularly in fixed-word-length machines,
such as the 1130, and permits minimum core and
media requirements.
• Adherence to requirements of programming
systems.
Section
20
Subsections
Page
I
01
40
40
File Organization
Indexed Sequential Disadvantages
For strictly card- and/or paper-tape-oriented
systems, file organization normally is sequential.
Therefore, the following discussion of indexed sequential (as in an encyclopedia) vs random organization (as in shuffled playing cards) is oriented
mainly toward the design of disk data files.
• More core storage may be required because
of index handling routines.
• Process time is greater for random input
because of index file seeking and processing.
Indexed Sequential Advantages
• Both sequential and random transactions can
be handled effectively in most cases.
• Reports arranged in data file sequence can be
obtained without sorting.
• Control over both the proces sing and the stored
file can be more positive.
• Less storage space is required.
• Frequently the entire file need not be online
simultaneously.
Random Advantages
•
•
Less core storage is required normally.
Process time is less for random input.
Random Disadvantages
• To maintain access requirements, frequent
reorgan ization may be neces s ary if the file is dynamic.
• Extensive key analysis and development of
address conversion routines probably are required
for implementation.
A detailed description of the·se techniques may be
found in section 85.
Section
20
Record Format and Blocking
To select the record format and blocking, each of
the following factors must be considered:
1. File boundaries. Cards are limited to 80
columns of punched data, while the disk has 320
words that may be recorded on each sector.
Subsections
Page
I
01
40
50
2. Core storage requirements. Since rocs
handles physical records for I/o operations and contains a core storage area large enough to accommodate the physical record, you must supply a core
storage area for a logical record. In addition, for
efficient operation, multiple I/O areas may be required for the I/o devices.
Section
20
Subsections
40
I
60
Page
01
File Processing
Before the file design is finally determined, the run
time and associated costs should be calculated for
the entire system. The results must be evaluated
to determine whether the original design objectives
have been met. If the system is I/O-limited (that
is, if I/o time exceeds prooess time), the following
approaches may be considered:
• Create a second master file splitting awayfrom
the main master file those fields not required on the
primary runs. For example, name and address
records could be kept in a separate name and address
file. This new file would be used perhaps only as
output documents are printed.
• Extract from the master file the active records
for processing. This method is useful if the ratio of
active master records to total master records is
very low.
• Increase the number of input buffers. If the
activity rate is low and processing time per hit is
high, more process time can be overlapped if the
input is queued in additional buffers. Ifprocesstime
requires 250 milliseconds while an input area can
be filled in 50 milliseconds, there will be 200 milliseconds of unoverlapped process time per hit, with
two input areas. If the number of input areas were
increased to four, only 100 milliseconds would not
be overlapped.
Section
20
File Control
The design of a data file connot be divorced from
the environment in which the file must function.
Some of the considerations of file control and maintenance are now discussed.
Data Validation
The entry of incorrect data into a file should be prevented. The following techniques may be used to
control the accuracy of input data:
1. Precoded forms, or standardized and simplified forms, which reduce the possibility of error at
the point of origin of the data.
2. Batch controls that establish totals for a
given group of records to detect the loss or distortion of data during intermediate handling. A
batch may consist of a fixed number of items or the
transactions that occurred in a given period of time.
Typical batch totals are record counts, dollar or
quantity amounts, and "hash" totals of significant
data, such as wage rates. Frequently, batch totals
are recorded in a trailer record to provide automatic zero-balance checking.
3. Turnaround documents, such as prepunched
remittance forms, which require little or no extra
recording and a minimum of handling.
4. Character checking, which determines
whether the data in given positions of the record
contain permissible characters. This type of check
can be used to ensure that the proper algebraic
sign is present for the type of transaction or that
alphabetic data is not included in numeric fields,
and vice versa, or that data is present where required (not blank).
5. Field checks that examine the content of a
field for certain characteristics. These include:
• Limit checks, which determine whether data
is within a prescribed range. Such checks can apply
to fields such as employee t s wage rate, amount of
gross pay, etc.
• Historical checks, which use prior experience
as a basis of validation. The public utility industry
often compares, for reasonableness, prior consumption for a year or more against current usage.
• Validity checks, which compare the content
of a field against a list of existing "good" numbers.
This prevents posting to nonexistent account numbers.
Matching by control key against a master file indicates duplicate and missing numbers.
• Logical relationships, which determine whether
the items of input data have a logical relationship to
one another or to the file they affect. For example,
Subsections
Page
I
01
40
70
if an employee adds a bond deduction, a bond denomination is also required.
• Self-checking numbers, which detect incorrect
identification numbers (such as account number,
employee number, etc.) by performing certain
mathematical calculations on the base number and
comparing the resulting digit against a check digit
appended to the base number.
Operating Controls
The following controls are common methods used to
detect errors caused by poor operator performance,
equipment failure, or malfunctioning programs:
1. Disk cartridge ID checking, which verifies
that the proper cartridge is online before any processing can take place.
2. Record counts, which check that the numbers
of records before and after processing are the same,
in order to guard against accidental loss of a record.
3. File totals, which ensure that the file is in
balance in light of the transactions just processed.
For example, the previous file total for a given
field plus the net change represented in the transactions should be equal to the sum of the individual
record fields after the transactions are processed.
4. Intervention logging, which records through
the console printer any intervention by the operator.
Error Analysis
The file control techniques suggested above indicate
the wide variety of methods available. Selection of
the specific control procedures depends on such
factors as the frequency of possible occurrence, the
results if the error were allowed to enter the system,
and the chance that the error might remain undetected even through later operations. All errors
should be logged indicating the nature and the cause.
A review of these error logs can serve as a guide
to management to increase or decrease error
control.
When errors are detected, any of the following
procedures can be used:
1. Programmed halts, where the computer is
halted by detection of certain conditions, and the
operator follows prescribed steps dependent upon
the nature of the halt. The trend is away from programmed halts to eliminate operator intervention.
2. Bypass procedures, where the error condition is recorded on some output medium, such as
paper tape or console printer, for later analysis,
and the computer continues without stopping.
Section
20
Subsections
Page
I
02
40
70
3. Suspense accounts, where totals are posted
for invalid records in order to keep in a single
account all items requiring analysis.
Audit Trail
An audit trail may be defined as the means whereby
the source transaction and its corresponding supporting documentation can be related to processed
data. Although the audit trail may be a by-product
of normal processing, it may sometimes be additional. The requirements of the auditor should be
discussed to provide the necessary historical information trail.
Reconstruction
If the information on a file is mutilated, the need for
reconstruction arises. The method selected depends
upon such factors as job priority, the time and cost
required to provide reconstruction data, and the
time and cost required to perform the reconstruction.
Listed below are several approaches:
1. Periodically, a dynamic disk file should be
copied (dumped) on paper tape, on cards, or on
another disk. Often, the copy can be made as a
by-product of a periodic run. All transactions since
the last dump must be retained to update the copy to
current status.
2. To avoid reprocessing of all transactions
since the last dump, write the updated records on
paper tape or cards as the transactions are processed
against the file. In sequential processing, only one
paper tape or card record per active disk record is
written. In case of reconstruction, the record with
the most recent status can be used to replace the
corresponding record on the dumped file.
3. If no output unit is available to record the
updated records, as suggested above, the master
can be flagged, and on a later run the flag can signal
a copy operation for a given record. This technique
requires a rewrite to the file for removal of the flag.
4. The contents of a static file should be available
either by copying to another disk or by dumping onto
paper tape or cards that may be used later to reload
the mutilated file.
Section
20
PA YROLL EXAMPLE
Narrative
Note: All of the pages in the following example
represent material that you should have developed
by this point in the installation of your system.
When completed, the material becomes a part of
your system documentation (see section 35).
* * *
The corporation consists of six manufacturing
plants, engaged in the fabrication of Liquid Dairy
Product Packaging in Ohio, Indiana, West
Virginia, and Texas. The payroll system was
designed to accommodate all six plants, which
have separate bookkeeping records. However,
the accounting functions are centralized in one
location. Communication is by phone and mail.
The system consists of 16 programs.
The files creation program is first. Data decks
are keypunched for each individual, in sets, by
plant. The data is edited and, when correct, is
loaded on the disk by PAYOl. Three files are
created: a master file, an index file, and a plant
information file. A second data deck with employee
clock number and name is loaded onto the master
file by PA Y02.
Changes to the disk information are made by
PAY03. Documents, received from personnel departments at the individual plants, are checked,
Subsections
Page
I
01
50
10
summarized, keypunched, and verified. Time
sheets, submitted by the plant payroll departments,
are keypunched and verified. All these cards are
processed by PA Y16, which edits and generates
control totals. PA Y04 then processes these cards,
performing all payroll calculations. Cards are read,
pay is computed, disk files are updated, and cards
are extended with current pay figures. After all
cards are processed, a payroll register is printed.
Checks are printed by PAY05. A header card is
read and the checks are printed from the disk file.
PA Y06 lists the check register from the disk file.
If an error is made in computing pay, PAY11 provides the means of voiding checks. The extended
time cards from PAY04 are read in and the affected
employee records are reset. The above are
weekly runs.
At month end, registers are prepared showing
each individual's deductions for the month:
PAY13 writes union dues register.
PAY14 writes credit union register.
PAY15 writes stock deductions register.
PAY12 resets charity deductions code.
At the end of the quarter and at the end of the
year, PAY07 and PAY08 are used to balance the
disk files to control totals.
PAY09 produces the 941 tax report.
PAY10 produces a tax worksheet used to determine tax liability.
Section
20
Subsections
Page
I
01
50
20
Card Forms and Console Keyboard Input
Plant no. - 1 digit - keyboard
Week no. of month - 1 digit - keyboard
Check no. - 2 digits - keyboard
Name - 18 blanks - keyboard
Plant name - 32 characters maximum - keyboard
Figure 20. 3 - card
PAY02
Plant no. - 1 digit - keyboard
Figure 20. 4 - card
Plant no. - 1 digit - keyboard
PAY03
Figure 20. 2 - card
Social Security Number, if changed - keyboard
Figure 20. 5 - card
Figure 20. 6 - card
Figure 20. 7 - card
PAY04
Check no. - 5 digits - keyboard
Week no. of month - 1 digit - keyboard
Maximum check amount allowed - 5 digits - keyboard
Figure 20. 8 - card
PAY05
Figure 20. 7 - card
Check no. - 5 digits - keyboard
Check maximum amount - 5 digits - keyboard
Clock no. (if requested) - 4 digits - keyboard
PAY06
Figure 20. 7 - card
PAY07
Plant no. - 1 digit - keyboard
PAY08
Figure 20.10 - card
Figure 20.11 - card
Figure 20. 6 - card
PAY09
Figure 20.12 - card
Figure 20.13 - card
Figure 20.14 - card
Figure 20.15 - card
Figure 20.16 - card
PAYI0
Figure 20.10 - card
Figure 20. 6 - card
PAYll
Figure 20. 7 - card
Figure 20. 9 - card
Figure 20. 6 - card
If requested:
Insurance deduction - 4 digits - keyboard
Stock deduction - 4 digits - keyboard
Charity deduction - 4 digits - keyboard
Miscellaneous deduction - 4 digits - keyboard
PAY12
Plant no. - 1 digit - keyboard
PAY13
Plant no. - 1 digit - keyboard
Individual amount for a plant - 4 digits - keyboard
PAY14
Plant no. - 1 digit - keyboard
PAY15
Plant no. - 1 digit - keyboard
PAY16
Figure 20. 7 - card
Figure 20. 8 - card
PAYOI
Section
Subsections
20
Clock
No.
..
1l
u
Change
0000 00 00000
50
I
Page
20
02
Blank
o0 0 0 0 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 46 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80
1111 11 11111 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
2222 22 22222 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2.2 2 2 2 2 2 2 2 2 2
3333 33 3 3 3 3 3 333333333333333333333333333333333333333333333333333333333333333333333
4444 44 44444 444444444444444444444444444444444444444444444444444444444444444444444
5555 55 55555
555555555555555555555555555555555555555555555555555555555~55555555555
6666 66 66666 666666666666666666666666666666666666666666666666666666666666666666666
7 77 7 7 7 7 7 7 7 7 777777777777777777777777777777777777777777777777777777777777777777777
8888 88 88888 888888888888888888888888888888888888888888888888888888888888888888888
9999 99 99999 999999999999999999999999999999999999999999999999999999999999999999999
1 2 3 4 5 6 7 I
t
1011 12 13 14 15 18 17 II II 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 5253 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 71 71 80
Figure 20, 2,
'C
c:
Clock
No.
Pay
Rate
Social
Security
No.
0
'" ~l
~~
Q)
iii.f Jj
Gross
Earnings
YTD
FICA
YTD
FIT
YTD
Local
Tax
YTD
Credit
Union
Deduction
'"g
Vi
~
~u
"iii
Union
Dues
Blank
J
~
i~
Blank
00000 000 0000 00 0000 000 0000000 00000 00000 00000 00000 0000 o 0 0 0 000 0000 000000 00 000000000
1 2 3 4 5 6 7 8 9 10 11 12 1314 15161718 192021 22 23 24 25 28 27 28 29 30 31 3233 3435363738 39 40 41 4243 44 45 46 47 48 495051 52 5354 55 56 575859 60 61 62 63 646566 67 68 69 7071 72 73 74 75 76 77 78 7980
11111 111 1111 1-1 1111 111 1 1 1 1 1 1 1 11111 11111 11111 11111 1111 1111 111 1111 111111 11 111111111
22222 222 2222 22 2222 222 2222222 22222 22222 22222 22222 2222 2222 222 2222 222222 22 222222222
33333 3 3 3 3333 33 3 333 333 3333333 33333 3 3 3 3 3 333 3 3 33333 3 3 3 3 33 3 3 333 3 3 3 3 333333 33 333333333
44444 444 4444 44 4444 444 4444444 44444 44444 44444 44444 4444 4444 444 4444 444444 44 444444444
55555 5 5 5 5555 55 5555 555 5555555 55555 5 5 5 5 5 55 5 5 5 55555 5 5 5 5 55 5 5 555 5 5 5 5 555555 5 5 555555555
66666 666 66 6 6 66 6666 666 6666666 66666 6 66 6 6 66666 66666 6666 66 6 6 666 6666 666666 66 666666666
7 7 77 7 7 7 7 7 7 7 7 77 7 7 7 7 7 7 7 7777777 7 7 7 7 7 7777'7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 77 7 7 7 7 7 7 7 7 7 777777 7 7 777777777
88888. 888 8888 88 8 888 888 8888888 88888 88888 88888 88888 8888 8888 888 8 8 8 8 888888 8 8 888888888
99999 999 9999 99 9999 999 9999999 99999 99999 99999 99999 9999 9999 999 9 9 9 9 999999 99 999999999
1 2 3 4 5 8 7 • I 101112 1314 15181711 112021 122232425262728 2930313233 3435363738 39 40 41 4243 44 45 46 47 48 ~9 50 51 52 53545556 575859 60616263 64 65 66 67 68 69 7071 7273 74 75 76 77 78 79 80
Figure 20, 3,
Section
20
Subsections
50
I
Page
03
20
i~
~u
Clock
No.
Name
"
Blank
0>
0000 000000000000000000 0000000000000000000000000000000000000000000000000000000000
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
~N~~~~~~~~nM~~n~~~~~~«%~~~~~~~~M~~~~~~~~~M~~~H~~nnn~~nnnn~
1111 111111111111111111 1111111111111111111111111111111111111111111111111111111111
2222 222222222222222222 2222222222222222222222222222222222222222222222222222222222
3333 333333333333333333 3333333333333333333333333333333333333333333333333333333333
4444 444444444444444444 4444444444444444444444444444444444444444444444444444444444
5 5 5 5 555555555555555555 5555555555555555555555555555555555555555555555555555555555
6666 666666666666666666
666G666666666666666666666666666666666666666~66666666666666
7 7 7 7 7777 77 777 7 7 7 7 7 7 7 77 7777777777777777777777777777777777777777777777777777777777
8888 888888888888888888 8888888888888888888888888888888888888888888888888888888888
9999 999999999999999999 9999999999999999999999919999999999999999999999999999999999
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 1920 21 22
~N~~~~~~~~nM~~n~~~~~~«%~~~~~~~~M~~~~~~~~~M~~~H~~nnn~~nnnn~
Figure 20.4.
g
Social
Security
No.
Clock
No.
~
~
::l
~
Pay
Rate
~ .~
u::::>
:g
.:,(.
!Ii
~
<{
~
j
u
Blank
0000 000000000000000000 000 00 0000 00 00 0000 0000 0000 0000 0000 0000 000 000000000000000000
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 2l
~
24 2!
~2
28~~31 ~n
M35
~37~39 ~41
4243 «%
~
47
~
49
~51
5253M55
~57~59 ~
6162
~M~~~H~~nnn~~.nnn~
1111 111111111111111111 111 11 1111 11 11 1111 1111 1111 1111 1111 1111 111 111111111111111111
2222 222222222222222222 222 22 2222 22 2 2 2222 2222 2222 2222 2222 22 2 2 222 222222222222222222
3333 333333333333333333 333 33 3 3 3 3 33 33 3333 3 3 3 3 33 3 3 3 3 3 3 3 3 3 3 3333 333 333333333333333333
4444 444444444444444444 444 44 4444 44 44 4444 4444 4444 4444 4444 4444 444 444444444444444444
5555 555555555555555555 5 5 5 55 5 5 5 5 55 55 5 5 5 5 5 5 5 5 5555 5555 55 5 5 5 5 5 5 5 5 5 555555555555555555
6666 666666666666666666 666 66 6 6 6 6 66 66 6666 6666 6666 6666 6 666 6666 666 666666666666666666
77 7 7 777777777777777777 7 7 7 7 7 7 7 7 7 77 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 777777777777777777
8888 888888888888888888 888 88 8 8 8 8 88 88 8888 8888 8888 8888 8 8 8 8 8 8 8 8 8 8 8 888888888888888888
9999 999999999999999999 999 99 9999 99 99 9999 9999 9999 9999 99 9 9 9999 999 999999999999999999
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 232421
Figure 20. S.
~2
~~~31
32
n M35 ~37~39 ~41 4243 «% ~ 47 ~ 49 ~ 51 5253 M55 ~57~59 ~ 6162 ~M~~~H~~nnn~~nnnn~
Section
20
Subsections
Page
I
04
50
20
i~
..JU
Blank
"
en
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO~OO00000000000000000000000000
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 46 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 11 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
22222222222222222222222222222222222222222222222222222222222222222222222222222222
3333333333333333333333333333333333333333333333333333 33 3 3333333333333333333333333
44444444444444444444444444444444444444444444444444444444444444444444444444444444
55555555555555555555555555555555555555555555555555555555555555555555555555555555
66666666666666666666666666666666666666666666666666666666666666666666666666666666
7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 77 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7
88888888888888888888888888888888888888888888888888888888888888888888888888888888
99999999999999999999999999999999999999999999999999999999999999999999999999999999
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 3233 34 35 36 37 38 39 40 41 424344 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 727374 75 76 77 78 79 80
Figure 20. 6.
Plant
No.
Check
Date
Earnings
Date
Total
Clock
Numbers
Total
Regular
Hours
Total
Overtime
Hours
Total
Bonus
Hours
Total
Special
Earnings
Blank
0000000 000000 0000000 0000000 0000000 0000000 0000000 OOOOOjOOOOOOOOOOOOOOOOOOOOOOOOOO
1234567 • • 10111213 14 15 16 17 18 19 20 21 22 23 24 25 28 27 28 29 30 31 32 33 34 35363738 39 40 41 42 43 44 45 46 47 48
~5O~~~54~56~58~60~~6364~66~68~mnnnu~n77nn8O
1111111 111111 1111111 1111111 1111111 1111111 1111111 11111111111111111111111111111111
2222222 222222 2222222 2222222 2222222 2222222 2222222 22222222222222222222222222222222
3333333 333333 3333333 3333333 3333333 3333333 3333333 33333333333333333333333333333333
4444444 444444 4444444 4444444 4444444 4444444 4444444 44444444444444444444444444444444
5555555 555555 5555555 5555555 5555555 5555555 5555555 55555555555555555555555555555555
6666666 666666 6666666 6666666 6666666 6666666 6666666 66666666666666666666666666666666
7777777 777777 7777777 7777777 7777777 7777777 7777777 77777777777777777777777777777777
8888888 888888 8888888 8888888 8888888 8888888 8888888 88888888888888888888888888888888
9999999 999999 9999999 9999999 9999999 9999999 9999999 99999999999999999999999999999999
1234567 8 • 10 111213 14 15 16 17 18 I. 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 4243 44 45 46 47 48
Figure 20. 7.
~50~~~54~56~58~60~~6364~66~68~mnnnU~n77nn8O
Section
20
Subsections
Page
I
05
50
Clock
No.
Regular
Hours
0000 000
20
Overtime
Hours
Bonus
Hours
.,
"C
0
U
li~
-JU
Special
Earnings
~
8
Special
Earnings
~
8
Special
Earnings
"
Blank
0>
Ii 0 0000 00000 0000000 000000 000000 0000000000000000000000000000000000000000000
1 2 3 4 5 6 7 8 9 10111213 1415161718 19 20 21 22 23 24 25 26 27 28 29 30 31 3233 34 353637
~~~~~~~~~~~~OO~~~M~~~~~OO~~~M~"~N~ronn~u~~nnn~
1111 11111 1111 11111 1 1 1 1 1 1 1 111111 111111 1111111111111111111111111111111111111111111
2222 22222 2222 22222 2222222 222222 222222 2222222222222222222222222222222222222222222
3 3 3 3 3 3 3 3 3 3333 3 3 3 3 3 3333333 333333 333333 33333333333333';3333333333333333333333333333
4444 44444 4444 44444 4444444 444444 444444 4444444444444444444444444444444444444444444
5 5 5 5 5 5 5 5 5 55 5 5 5 5 5 5 5 5555555 555555 555555 5555555555555555555555555555555555555555555
6666 66666 6666 66 6 6 6 6666666 666666 666666 6666666666666666666666666666666666666666666
7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7777777 777777 777777 7777777777777777777777777777777777777777777
88 8 8 8 8 8 8 8 8 8 8 8 88 8 8 8 8888888 888888 888888 8888888888888888888888888888888888888888888
9999 99999 9999 99999 9999999 999999 999999 9999999999999999999999999999999999999999999
1 2 3 4 5 6 7 8 9 1011 1213 1415161718 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37
~~~~~~~~~~~~OO~~~M~~~~~OO~~~M~"~N~ronn~u~~nnnoo
Figure 20,8,
Clock
No.
Regular
Hours
Overtime
Hours
Bonus
Hours
"C
0
U
Special
Earnings
~
8
Special
Earnings
~
U
Special
Earnings
Pay
Rate
Net
Gross
FIT
FICA
Local
Tax
Credit
Union
Union
Dues
Total All
Other.
~
D.eductlons ro
3~
"
0>
o0 0 0 00000 0000 00000 0000000 000000 000000 000 000000 000000 00000 0000 0000 0000 0000 00000 00
1 2 3 4 5 6 7 I 9 10111213 1415161718 19 20 21 22 23 24 25 26 27 28 29 30 31 323334353637
~39~
4142 43
~
45
~
47 48 49 00 51 52
53M55~57 ~
59 00 61
62~M65
"67 N 69 7071n73 747576
n 78 79~
1111 11111 1111 11111 1111111 111111 111111 111 111111 111111 11111 1111 1 1 1 1 1111 1111 11111 11
2222 22222 2222 22222 2222222 222222 222222 2 2 2 222222 222222 22222 2222 2222 2222 2222 22222 22
3 3 3 3 3 3 3 3 3 3333 3 3 3 3 3 3333333 333333 333333 333 333333 333333 3 333 3 3333 33 3 3 3 3 3 3 3333 33333 33
4444 44444 4444 44444 4444444 444444 444444 444 444444 444444. 44444 4444 4444 4444 4444 44444 44
5 5 5 5 5 5 5 5 5 5 5 5 5 55555 5555555 555555 555555 555 555555 555555 5 5 5 5 5 5 5 5 5 55 5 5 5 5 5 5 5555 55555 5 5
6 6 6 6 66666 6 6 6 6 66666 6666666 666666 666666 666 666666 666666 66666 6666 6666 6666 6666 66666 66
77 7 7 7 7 77 7 7 7 7 7 7 7 7 7 7 7777777 777777 777777 7 7 7 777777 777777 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7
8 8 8 8 88888 8 8 8 8 88888 8888888 888888 888888 888 888888 888888 888 8 8 8888 8 8 8 8 8888 8 8 8 8 8 8 8 8 8 88
9999 99999 9999 99999 9999999 999999 999999 999 999999 999999 9 9 9 9 9 9 9 9 9 9 9 9 9 9999 9999 99999 99
1 2 3 4 5 • 7 I 9 10111213 141518171. ,. 20 21 22 23 24 25 262728293031 32 33 34 35 36 37
Figure 20,9,
~~~
4142 43
~ ~ ~
47 48 49 00 51 52
~M55~57 ~
59 00 61 6263 M65 "67 N 69 7071n73 747576
n 78 79~
Section
20
Plant
No.
Subsections
Page
I
06
50
20
Blank
000000000000000000000000000000000000000000000000000 0 000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00 0 0 0 0 0 0 00
lJ34567a9W»U~"~~17UUm~~~N~~n~~~~~~M~~V~~~~~~«~~~q~~~~~~ ~$~M~~~~~M~~~u~ronnnu~nnnn~
11111111111111111111111111111111111111111111111111111111111111111111111111111111
22222222222222222222222222222222222222222222222222222222222222222222222222222222
33333333333333333333333333333333333333333333333333333333333333333333333333333333
44444444444444444444444444444444444444444444444444444444444444444444444444444444
5555555555555555555555555555555555555555555555555555 5 5 55555555555555555555555 555
66666666666666666666666666666666666666666666666666666666666666666666666666666666
7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 77 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7
8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8. 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8
9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9· 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9
12345'7a9W»U~"~U17UUm~~~N~~n~~~~~~M~~V~~~~~~«~~~q~~~~~~ ~$~M~~~~~M~~~u~ronnnu~nnnn~
Figure 20. 10.
Clock
No.
Blank
0000000000000000000000000000000000000000000000000000 0 0 0 0 0 0 0 0 0 0 0'0 0 0 0 0 0 00000000000
1 2 3 4 5 6 7 8 910» 121314151617 18 19 m 21 ~ ~ 24 ~ ~ 27 28 29 ~ 31 32 ~ M 35 ~ 37 ~ 39 ~41 4243« 45 ~ 47 q 49 ~ 51 52 ~ ~ ~ $ 57 M 59 ~ 6162 ~ M ~ ~ 67 U 69 70 717273747576 n 78 79 ~
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 11 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 11 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
222222222222222222222222222222222222222222222222222222 2222222222222222222L222222
33333333333333333333333333333333333333333333333333333333333333333333333333333333
44444444444444444444444444444444444444444444444444444444444444444444444444444444
55555555555555555555555555555555555555555555555555555555555555555555555555555555
66666666666666666666666666666666666666666666666666666666666666666666666666666666
77777777777777777777777777777777777777777777777777777777777777777777777777777777
88888888888888888888888888888888888888888888888888888888888888888888888888888888
9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9-~ 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9
1 2 3 4 5 6 7 8 9 10 » 12 13 14 15 16 17 18 19 m 21 ~ 23 24 ~ 26 27 ~ ~ ~ 31 ~ ~ M ~ ~ 37 ~ 39 ~ 41 42 43 « ~ ~ 47 q 49 ~ 51 52 53 ~ ~ $ 57 M 59 ~ 61 62 63 M ~ ~ 67 U 69 70 71 72 73 74 75 76 77 78 79 ~
Figme 20.11.
Section
20
Subsections
Page
I
07
50
Date for
Reporting
Period
.20
ci
z
Q)
Blank
!
0000000 00 00000000000000000000000000000000000000000000000000000000000000000000000
1 2 3 4 5 6 7 8 9
rolln~Uffi~n~"ro~~~u~~~~~~~~~M~~~~~~~~~«~~~~~OO~~~~~~~~~~~~ ~M~~~~"ronnnu~nnnn.
1111111 11 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
2222222 22 222222222222222222222222222222222222222222222222222 2 22 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
3333333 33 33333333333333333333333333333333333333333333333333333333333333333333333
4444444 44 44444444444444444444444444444444444444444444444444444444444444444444444
5555555 55 55555555555555555555555555555555555555555555555555555555555555555555555
6666666 66 66666666666666666666666666666666666666666666666666666666666666666666666
7777777 77 77777777777777777777777777777777777777777777777777777777777777777777777
8888888 88 88888888888888888888888888888888888888888888888888888888888888888888888
9999999 99 99999999999999999999999999999999999999999999999999999999999999999999999
1234567 6 9 10 11 12 13 14 15 16 17 18 19 ro 21 22
~
24
~ ~
27 28
~ ~
31 32 ~ M ~
~
37
~ ~ ~
41 42 43 « 45
~
47
~
49 00 51 52
~ ~
55
~
57
~
59
~
61 62
~
M~
~
67
~
69 70 71 72 73 74 75 76
n 78 79 80
Figure 20. 12.
Company Name
Blank
00000000000000000000000000000000000000000000000000000000000000000000000000000000
123456789rol1n~uffi~n~"ro~~~u~~~~~~~~~M~~~~~~~~~«~~~~~00~~~~ ~~~~~~~~~M~~~~"ronnnu~nnnn.
11111111111111111111111111111111111111111111:111111111111111111111111111111111111
22222222222222222222222222222222222222222222222222222222222222222222222222222222
33333333333333333333333333333333333333333333333333333333333333333333333333333333
44444444444444444444444444444444444444444444444444444444444444444444444444444444
55555555555555555555555555555555555555555555555555555555555555555555555555555555
66666666666666666666666666666666666666666666666666666666666666666666666666666666
7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 77 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7
88888888888888888888888888888888888888888888888888888888888888888888888888888888
9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 99 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 919 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9
123456789rol1n~uffi~n~"ro~~~u~~~28~~~~~M~~~~~~~~~«~~~~~00~~~~ ~~~~~~~~~M~~~A"ronnnu~nnnn80
Figure 20.13.
Section
20
Street Address
Subsections
50
I
20
Blank
00000000000000000000000000000000000000000000.00000000 0 0 0 0 0 0 0 0 0 0 0 0 0000000000000000
1234567.9W"~"U~~n~~~~~~N~a~~~~~~~M~~n~~~~~~~~~~~~~~~~M "~~~~~~~~M~M~u~ronnnu~nnnn.
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1'1 1 1 1 1 1 1 1 1 1 1 1 ttl ttl t ttl t t ttl t 1 1 t t t t t t
22222222222222222222222222222222222222222222222z22222222222222222222222222222222
33333333333333333333333333333333333333333333333333333333333333333333333333333333
44444444444444444444444444444444444444444444444444444444444444444444444444444444
55555555555555555555555555555555555555555555555555555555555555555555555555555555
6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6' 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6
77777777777777777777777777777777777777777777777777777777777777777777777777777777
88888888888888888888888888888888888888888888888888888888888888888888888888888888
99999999999999999999999999999999999999999999999999999999999999999999999999999999
12345671IWll~"U~~n~~~~~~N~a~~a~~~~M~~n~~~~~~~~~~~~~~~~ M"~~~~~~~~M~M~u~ronnnu~nnnn.
Figure 20. 14.
City and Zip Code
Blank
00000000000000000000000000000000000000000000000000000000000000000000000000000000
1 2 3 4 5 6 7 8 I 10 11 12 13 14 15 18 n 18 II ~ 21 ~ ~ 24 ~ a 27 ~ 29 ~ 31 32 ~ M ~ 36 37 ~ ~ ~ 41 42 43 ~ 45 ~ 47 ~ 49 ~ 51 52 53 M 55 ~ 57 ~ 59 ~ 61 62 ~ M 65 M 67 U 69 70 71 n 73 74 75 76 n 78 79 •
1 t t t t ttl t 1 1 t 1 1 1 1 t 1 1 ttl 1 ttl t 1 1 t 1 1 1 1 1 1 1 1 t 1 1 1 t 1 1 1 1 t 1 1 1 t 1 t 1 1 t 1 1 1 t ttl ttl 1 1 1 1 1 1 1 t 1 1 1 1 t
22222222222222222222222222222222222222222222222222222222222222222222222222222222
33333333333333333333333333333333333333333333333333333333333333333333333333333333
44444444444444444444444444444444444444444444444444444444444444444444444444444444
55555555555555555555555555555555555555555555555555555555555555555555555555555555
66666666666666666666666666666666666666666666666666666666666666666666666666666666
7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 1 7 7 7 7 7 7 7 7 7 7 7 77 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 77 7 7
88888888888888888888888888888888888888888888888888888888888888888888888888888888
99999999999999999999999999999999999999999999999999999999999999999999999999999999
123458789W"~"U~~n~~~~~nN~a~~29~~~~M~36n~~~~~~~~~~~~~~~~M "~~~~~~~~M~M~u~ronnnu~nnnn.
Figure 20.15.
Page
08
Section
20
Subsections
Page
I
09
50
State
Account
No.
20
Blank
Federal
Account
No.
Blank
0000000000 0000000000000000000 0000000000 00000000000000000000000000000000000000000
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 29 27 28 29 30 31 32 33 34 35 36 37 38 39
~~~~~~~~~~~~~~M~~~~~~~~~~~~~~~Mnnn~~nnnn~
1111111111 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1111111111 11111111111111111111111111111111111111111
2222222222 2222222222222222222 2222222222 22222222222222222222222222222222222222222
3333333333 3333333333333333333 3333333333 33333333333333333333333333333333333333333
4444444444 4444444444444444444 4444444444 44444444444444444444444444444444444444444
5555555555 5555555555555555555 5555555555 55555555555555555555555555555555555555555
6666666666 6666666666666666666 6666666666 66666666666666666666666666666666666666666
7777777777 7777777777777777777 7777777777 7 7 7 7 7 7 7 7 7 7 7 77 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7
8888888888 8888888888888888888 8888888888 88888888888888888888888888888888888888888
9999999999 9999999999999999999 9999999999 99999999999999999999999999999999999999999
1 2 3 4 5 6 7 8 9 10 11 12 13 1415 16 17 18 1920 21 22232425 29 27 28 29 30313233343536373839
Figure 20. 16.
~~~~~~~~~~~~~~M~~~~~~~~~~~~~~~Mnnn~~nnnn~
Section
20
Console Printer and Line Printer Forms for Output
PAY01
PAY02
PAY03
PAY04
PAY05
PAY06
PAY07
PAY08
PAY09
PAYlO
PAYl1
PAYl2
PAYl3
PAYl4
PAYl5
PAY16
None
None
None
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
None
Figure
Figure
Figure
Figure
20.18
20.19
20.19
20.20
20.21
20.17
20.22
20.23
20.18
20. 24
20.25
20.26
20.27
Subsections
Page
I
01
50
30
en
l\:)
~------------------------------------------------------_._--_._-----------------------------------------
IB"1
0
INTERNATIONAL BUSINESS MACHINES CORPORATION
PRINTER SPACiNG CHART
co
n
.....
O·
::J
OJ
0
en
c
0VI
f--Co-'
0
co
n
.....
O·
::J
VI
0
l\:)
Figure 20.17.
----------------------------.----------------------------.- -- -------------------------------------"- ----I
,----------~------------------~--------
IB~
INTERNATIONAL BUSINESS MACHINES CORPORATION
8 Lines Per Inch
FielD HEADINGS/WORD MARKS
LINE DESCRIPTION
I
I
PRINTER SPACING CHART
IBM 407, 408, 409, 1403, 1404, 1443; and 2203
Print Span:
'''''-,-,--.+-,-,---,--,-.--r-rT-r-4--,-~;::::;:;::;:;:~
IBM 1403 ,-'+M
__ odels
11TTnllll-r
Ihn~~T~~~~~,r~~~~n.~~~rlh_rT~~nrl-r
r
1 &
I
4H
I
IBM 407, 408, 409, and 1403 Models 6 and 7
I fTTIT: I n [TTL: I 1 T1 i
I I I
I I!
I
I
I
1
1111 1
I
11_1 J l
11 11 I I I
IBM 1403 !f0dels 2,~~N1 and 1404
llTTTl TiTTTTrT I I I J'Tl:TlTTl
IBM 1443 Models 1, N 1, an? 2203
J
1
II
TrTrTTnTl
If
_0
GL UE
1
2
3
5
4
6
7
8
9:
10
11:
AH 2345678901,23415167890,1234567890,12.34,5:",718901 2'345678901,23'4 151678,9 011.1314'.5,6,lZf42-!011[213T4'5'6,7 81901'2,3,4'51617890112:345,678,9 0,112!3'415 617 8901234567890
1
,
, 1
I
ILl i
_l..'...J...LLLLL _I ! i i , ! I ITT-' , ; I I I '
, : _'_1---'--'++++--+"-J'-H,-i-I+-+++-L'-4--t--+-H4--+-++++++-+-H--+-H
2
3
I
i
'
I ,
I
_1.
I
I
,
•
I I ill
,
+'
I Ii,'
-i'
"
:!
'
i
I I I :
I!:
, I : I i
I'
I
I
I
I
I
:
I
1
I
'
'
I '
!,
I'
: i
II
""..'
Figure 20. 18.
,
I
1
I
1
=--
I I
,
..I-
1
I
II i i i '
'i I:
'"U
Q)
co
co
---------------,--------------------- -,-,- ---------------,---------"
IB~
----------------~~-----'!;
I
PR!NHR SP,£\CiNG CHt"RT
I
i 3_,_1i4_W_'
MA_R_KS_ _ ,~_-8-Li-n-es-Pe,__r-l-n-ch---__,_I-B-M--4-0)7-'",_-,----40_8"'-,,4_09_',,,____
1_4_W-.___4,__",____1
___4",4__3_,_,_c
___n_d___2_2--,---O_3,_____ .P_'_in_,_t_S,-,--!pom_: ----TT-------r-----~I
INTERNt..TIOt..JAL BUSiNESS MACHINES CORPORL,TlON
FIELD HEADINGS/WORD
If----r-r-,---,-,--.--,--,-l-r,-,---,-T"-"+"-,--,,,,-.----r,rlTfTTTT:-c-r :-lTiT1TTTI-{'-r-r: r iTT
!iiTTTTTcTTnTUllT r-TTTr----;:TT TTTrTT-:-T'TTTITTTT1-lr
TfT'-';-"
f i T ) T , : ' i, I ;
'-;~~:;::;:::;:~::;--'~"'T-'111_'4~I'00i'3r_ll T il!l-nTt{ ---,"T\-,---,--"_+ir-_,",
,--,--,--,-,--,,--h
-~1'--1:-:1~1'~1~1~1=,t;rr~I~I~!?tj~~);7~r'~14,il~r~~~~-Gr'i-m~!d!4~O)~3M~O~de~ls~6~a~~dt!~~~~
:j~:::=:::j~~~:::J::~~:::J::::=::~:J:~~~:-~~=:-=1~~~~~~1IB~M~1~403~-M~O?,~de,II\~2,~3~,15,~N~1~a0n~d~1~4~04~~~~~~~
h -,---L--,--'--r~'--r'__'_--,--'--rl-'--1~---'--___,-'--,---,__'__-,--_"_--,-'___'_"-'---~~.:..~r~,_'____':
T-LIT--Y-',-,-IT-'-i J""T-rLTTTTl r
! i
II
!i
I -IT' iTni rill i ll l illi r'~ '11'11 nTTTTTTTi
.~~~-.-14~~~~-~~~~~~~-'T~~.~r~~~~-~~.~~-~-~-~T~r~.~'~~~1~~~~~~I~~M~1!«~1~3r~o~ls
N~la~ 2203
f----_ _ _ _ _ _ _ _ _r
, - - - , I, _
I
I
I'
iii
X :~
I
+H
I
TT"
I
, I
I
II
I
II
Jl
:
I
I
I
=
I
I
'=
I
j
I
I
!-
II
-'rim:
!
I
II i
I
,I
ll~'
1I
I(
].00
--.l
I~
1i
J.qc
I;!
2JT
-1
I
11lI~
!I
! ,
'i!
Ii'
i!
I
II
i
"",...
"'""
Figure 20.18. (Cont)
l:\:)
0
(f)
CD
(')
r-+
o·
::J
C,)l
0
(f)
c
0'"
(J)
-
CD
(')
~.
C;.:I
0
0
C;.:I
0
::J
(J)
'iJ
Q)
to
CD
en
I:\j
f
INTERNATIONAL BUSINESS MACHINES CORPORATION
IBt.1
IBM 407, 408, 409, 1403, 1404, 1443, and 2203
8 lines Per Inch
FIELD HEADINGS/WORD MARKS
Print Span:
01
0
I
li-r-"'-'--'I~r~-l'--'-'~l-rJJ--'--'-l'+-"'-'l---rll--rr-.,..--,-ih--T-'---r,I-,---~'T I~I,~--.-r,---,-·-h--~I"!lCnTl!
I ,I,!,
,L
GL UE
I
,Ll
I I
I
o
2
!
I
Ii
I
I
.';"'!lCT;2"'3'"'4=
0
0
c.n
O·
~
VI
\J
Q)
to
co
CIl
ro
r
~~~ -----~-----------
IBr.,
PRINTER SPACiNG CHARi
:1I
JI
I
i
(J,it ~,./Al
JS... f~ .. i
il I
i
I
I
I
I
:,
i
I
J J
II
I I J II I
III
LII
1443
,
.
GL ~UE
,.' ,-
;;: ."-
I
.1
i
"
I:
:
~ ~
~1~
,~
ij
.=
~
;
il
I
I
I I I
c,..,
0
1
1111111 I
10
11111
I II
I
1
1
I
I
I
!
I
I
I
I
;;
II
!VI} I
~
~
.
I
1
I
. I
~
I
I
,
Ii
!
I
~~~
J
i
I
,
1
.
I
I'
1
1
I
I
I
I
E
~==
Figure 20. 21.
I
I
Ii:
I
""'"'
:l
CIl
"'0
0
0)
I
~tc:~
ro
n
::!.
0
1
I
I
I
CIl
C
C"'
a,n~
9
I
I,
I
w
j g
i~
I
Aodels 1 N1
I,
I
I'i
0
1
Aodels 2, 3. 5, ,N1 and
~-
0
11
~ ~'
j1
i
1
:
Ol
~
"7
III i.
I
\I)
;;
c ..,
I
I
I
I
1
I
:5
'
I
:
w
:~
8
6
'
I
I
-I
1
0,
I
L
.
e"¥
'
+i
407, 4:18, 409, and 1:193 Models 6 clnd
11111111
IBM 1403
I
~
o·
:l
CIl
'0
OIJ
Aadels 1 & 4
II! i II
, : ' Ij
I
Print Span:
·IBM 1403
ill I
n
I
IBM 407, 408, 409, 1403, 1404, 1443, and 2203
8 lines Per Inch
FiElD HEADINGS/WORD MARKS
0
I
INTERNATIONAL BUSINESS MACHINES COR?ORATION
LINE DESCRIPTION
l\:)
I
I
I
""
til
to
ro
I
Ii
INTERNATIONAL BUSINESS MACHINES CORPORATION
IB"1
LINE DESCRIPTION
FIELD HEADINGS/WORD MARKS
I
PRINTER SPACING CHART
IBM 407, 408, 409, 1403, 1404, 1443, and 220'3
8 lines Per Inch
I
Print Span:
IBM 1403 Models 1 & 4
+-l
I
IBM 407, 408, 409, and 1403 Madels 6 and 7
IBM 1403 Models 2, 3, 5, N 1 and 1404
I'
i I
IBM 1443 Models 1, N 1, an~ 2203
GL UE
o
I
2
3
!
I : I
I
4
&1'"'1'-2"-3;"-4-:>"S==6""'7=a'-9hO'""1'-2'-3"4'""S"'6-:T"
7'-'a'-9~O'-'-'2r.3.-r4.1CSOr6"'7=r·8 9 0 1 213415.617 89 0,1 2 :l 4
+J
I
5T6 7
5
6
I
7
8
10
11
a 90 1 234 S 67 890 1 2;1 4 S 6 7 a 9
9:
1 2 3;4:5,67'8!9 0 1 23 4'5 M7 89 () 1 234 5 67
819 011 2,34 S 1617'819 0'1 2 3
I t I
I
i
, I
"
O'
I
I . :-h-.,f--IH-+++++-c-"...,,-'.~H-++-H--+:_,--!I--,I:-t-H-++'_'+-L+-+'~H-++++++-H~If--H-I++++++-H~H-+++++f.I
Il
I I
I
II
I
I
! ,
Ii
I I
I
I I I
I I
I I
I i I I
I II
- ~DC
! .
I I
: I I
Ii!
I: i
i
1
!
1-+ :
I
i
)(
IX
~
I
l
I·
l(
I
!
I
I
Ii
' I
rIlDC
[~
Iyllt
fill
, I
I
--i
.L
I
+
I
I
I
I
I I
I
, II
i
'II'
, II
I
I
I
II
!
!
I
I
I
(f)
~
0
CP
(")
.-+
O·
:::::I
c.n
0
(f)
c
0CIl
~
eN
0
CP
=.
(")
0
:::::I
CIl
Figure 20. 22.
0
-l
"'iJ
ell
<0
CP
en
l:\:)
-- -_._-------------
I
i
I
--
~-.--~
--
-.-~
._ ...
-.---~
..... -...
-.~----
-_._-
----_._------_.-
IS",
-
-
-
-
-
I
--~
LINE DESCRIPTION
FiElD HEADINGS/WORD MARKS
PRINTER SPACING CHART
IBM 407, 408, 409, 1403, 1404, 1443, and 2203
8 Lines Per Inch
Print Span:
1403 ",,-dels 1 &~
I
L
! !IL U III I
L
10
-!
407, 4 )8,. 409, and
.1 I LLULI
,.
~UE
n
.
w
3e
.
~
!
~
II
~
~ ~
~~~ II~
in
~
.' •
I ILL
" -
~
I----
"7
~
II L LJ I L
N1. c
I
i"-
:-'-"I
, ,
•
~~ ~.
il I
li
'
0
11
0
00
I
I
I
I
I~
I
I
! i
f-of-o-
I-
I
I
~~ ~
O·
en
c
0"
(1)
()
r+
O·
~
(/)
~
I
I
-
Figure 20. 23.
~
Aodels
r+
(/)
I
I
~
nd
01
0
I
I
i
I,
I
~
Models 6
1
I
I
!jn
~io:::=
1443
I
j
I
1~(?3
I
Aodels 2, 3, 5, _N1 and
)
,-
~!:
~1 ~
.2 ~
l_L
ilLJ!
'u
-
_L
-H
(1)
()
~
I
1403
;;~ GL
,:
INTERNATIONAL BUSINESS MACHINES CORPORATION
0
~
LL
~
"-
."
=i
"
Q)
to
(1)
INTERNATIONAl~~U~INESS
IB"1
LINE DESCRIPTION
MACHINES CORPORATION
-- ------- -
fiELD HEADINGS/WORD MARKS
8 Lines Per Inch
IBAA A07, 408, 409, 1402, 1401,. 1443. and 2203
-
---~---
-----t
r
PRfNTER SFAClh1G CHART
Print Span:
I
Figure 20.24.
~
0
en
CD
(")
.....
o·
:J
I:)l
0
CJ)
C
0fJ)
!----CJ,:)
0
CD
(")
.....
o·
:J
fJ)
0
to
""tI
Ql
c.c
CD
CJ)
Cl)
I:\:)
0
IB~
!NTERNAT.l0~.JAL
BUSINESS MACHINES CORPORATION
FIELD HEADINGS/WORD MARKS
8 Lines Per Inch
!:!'.
0
::J
PRINTER SPACING CHART
LINE DESCRIPTION
(")
IBM .407, 408, 409, 1403, 1404, 1443, and 2203
Print Span:
OJ
0
CJ)
C
CVI
r-V.:l
0
Cl)
(")
!:!'.
0
::J
VI
I
:
i
I
i
J.l
-,.
~l:mw~m~==tttt~~~~~~~~~~=~~~tt:~~T~t0~~~=:~~~:~~==mIk=t~t:~:
f-'
0
,
,
i
•
~l ~~n~~:~+Hr-----~~rr~~~-~++rrrr~~~~rrn,~~-T~!-~r~-C~'-T~-'~---'~--~~--+-'~~'~-H~r-~r-~~i~"~-7~';'~'~-~~~+---~~~++++rr~~
.,.
,
e~
.2 ~
•
.~
~~++I~+++++Hr-----~~rh~~~"+~T+-r
o~+H~rH+Hr-----~~~
I
~
g N~++~~++t++if-------+~++~
!~
~~~~rf-t+Hr-----~rlrre
~ ~
~
; ~~...-r++++Hr----.---t;-7Hf-+-A-'
1
",'
...
.. ;
-::
L ___ '
,--
i~i.L,-
+
1 . •.
.~
,
•
,
m~++i~l-~+Hr-----~~rrrr~~~++++rrHH~++++rrrH+~++++++rrH,~-rr+T~--~r-~--~~-~-~'-H~--~7-r~~-+-+it-~rH~~+-++~~~++++rr~~
I
~~~...-r++++Hr-----~Hf-++~~~1-4+·rr++~~-++++++~-"~~-~~,rr+!;
-",'
j
ii
i
J.
,
~ ~wtwtnt~~~====~~~~ql~~~~~~Si~;rtdfji;~ir;;t=t~j~rn+tTf--'~~";'-~-f~-r+"·"-+lf-f-i-~-~,+'i··fH-r~'L~-·!J~~-~H+~"+~Y-'~~~r+~HH-H-~4++h1
;
c~
j
,
·;_·c ..·
~: ~~~...-r++++Hr-----~rlrrrr~~+++T++rr~~~++~~n~-rnm
:~ ~
:
!
,
I
....
~
U.I
I'
I
i:
! ;
I
i
,'"hh-h-+-t-"+t'ri~~-~i-,~rt~+~t~~n-t+H-t--~~-rl+rrl-~+HK+rH+~~~+rH++n++rrt+r~
;
I
i
! !
i I
I
I
LI
I
I
'1
~--~----b~~~~~±ijl'~~~~tQ~~~~~tg~~tb~~~~tt~=tj±tBl1±t~~1t~3J-±±ttl±1ttEB;;:;~~~~~~~~tt~ilEb~±i~~it~~
""'"
...-- """"
"'~
I
Figure 20.25.
I
-0
OJ
co
Cl)
L
:
INTERNATIONAL BUSINESS MACHINES CORPORATION
IBl1
LINE DESCRIPTION
PRiNTER SPACING CHART
IBM 407, 408, 409, 1403, 1404, 1443, and 2203
8 Lines Per Inch
FIELD HEADINGS/WORD MARKS
t-i
1403 Madels 1 & 4
I
, !
407. 498
,n
~ ~
..
GL :UE
;
I
II
il
II
i
I,
.~
11
~; 5
jl
j~
I
, I I I I I
I
4
II
!
Iii ,1111
I
rr
~
IAA
W
I
6
I
I
I
II~
I
I
II!
c~nd
7_
and
I
c ~
N
lIodels
~
""" ...
1
:
I
I
I
I
I
I
I
1-1 R
A! i~
I
II
II
I
I
I
I
I
I
I
I
I
,
:
i
' I
I
I
I
I
I
'
~
;;
!
I
I
I
I
I
i
i
I
~
I
~)(~
rr
I
·IBM 1443
7
'!
i
I
I
I
I
0
;;
;
I
409, and 14C~3 Models 6
1403 Models 2. 3, 5,
I
I
A
~
5
I
,
I
I
I
-~~
!
I
I
5 ;;
]
I11II
I
I
~! :
~1 ~
.:
IIIIIIIII
)
.
:~
I
I
,
"
el
I
i
I
,-
I
Print Span:
I
TA
i
I
""- ~
60==""
Figure 20. 26.
I
INTERNATIONAL BUSINESS MACHINES CORPORATION
IBl1
LINE DESCRIPTION
FIELD HEADINGS/WORD MARKS
I
PRINTER SPACING CHART
IBM 407, 408, 409, 1403, 1404, 1443, and 2203
8 lines Per Inch
:
Print Span:
IBM 1403 Models 1 & 4
-H
TT,,,~-~~,,,~-'r1,,,-,,,,,~~
IBM 407, ,428, 409, and 1403 Models 6 and 7
I"T--,r-,IT~I
-rr-,-l-,--.--.--I''--+-'-rr-,---,i-,--,-I,,-jl-,I-,I-'---'''-_'--'-'-+o-I-,-I-.-,[',1"11,--,-,1-+-.-.-1,-1,-1,,,,11--..1+--,--,--.-1,-1
!-.
I
I
B~~E~~~:;:S
0-7Jt12t'
Tn •TTl IT-rTTTfT!!Tr TT1TTTI11 tTTTllTTTI
I
I
;!
;:=r_T~::=TI].t1:121~'-~I~I~1~rl~T~lT0-2:ln~T~1~1~
IT~r
IBM 1403 Models
T-
I
2, 3,
_~~
!
IBM 1443 Models 1, N 1,
GLIUE
N_O\D())-.,j
Ii
0
1
2
3
4
5
6
',12345678901234'516789.0,1234561718'90,12345617189 012'345678901 2,3!4f516:i'sf9
7
0
:45;6:
8
8,'
an~
9:
I I I
1404
I
I II I I I I
I
2203
10
11
I
012345678901234,56,789012345678901234567890
~
0
U)
CD
(')
.-+
o·
::J
-~-L,
Cl1
i
Ii
I
--r.J-.
=-
i
0
:
C/l
,
-.c.:::
U)
c
0-
~
bb
W
0
CD
(')
.-+
o·
::J
C/l
Figure 20.27.
f-'
f-'
"0
Q)
to
CD
Section
20
Subsections
Page
I
01
50
40
Disk Record Formats
Employee File - Figure 20.28
Index to Employee File - Figure 20.29
Company Record in the Corporation File - Figure 20.30
Section
20
Subsections
Page
I
02
50
40
}
)
~
z
EMPLOYEE information record
starting at 109 and continuing
thrll 156 is current information"
ci)
~i
I
I
I
I
I
I
I
I
::>
~
Q)
Q)
"~
E
"c
en
E
~
X
"~
(J)
ttl
~
Q)
Q)
(J)
~
e
Q)
ttl
x
II:
en
>
ttl
X
-c e
u.
I
en
c.
E
c.
"0
Q)
ttl
0..
ci)
I
)
~
I
(
I
10 11
5 6
~
0
e:
~
-.0
U
0..
L1J
~
(J)
Q)
en ~
"!!! E
Name
0
0
Q)
~
(.)
~
(.)
~
>
0
Ci
(J)
"~
0
15 16
20 21
Year-to-Date Information
40 41
35 36
30 31
25 26
45 46
0
-c ...6
0
~
::t:
Quarter-to-Date
Information
e:
0
-Se:
0
0
Z
"c ~
e:
.... 0
>- :c
"c
Ql
0
l-
6
-c -c -c -c -S...
coe: 0
e:
0 0
::t:
Ql
~
(.)
::>
Ql
..c:
U
::>
U ....
I
I
I
I
I
I
65 66
70 71
'"
Z
ro
e
Cl
c::
.~
ttl
Ql
II:
"0
0
III
U
e
19
-c
Ql
(.)
e
>
ttl
a.
I
0
I
Ql
Ql
0
0
~
";;
:c"0
«
(.)
0
en
c:
-
ci)
Q)
Ql
~
ttl
e
0
..c:
~ U
U
ci)
::t:
II:
"3
en
Ql
~
I-
c:
0
0
co
I
I
r
I
c:
x
I-
l-
u:
(.)
0
--l
(J)
0
"c
::>
co ....
:c
~
U
Q)
~
"~
ttl
..c:
U
~
0
c:
0
"c
::>
Q)
(.)
c:
e
~
(.)
g
E ~
ic:1 en
For Growth
of Record
(
J
_I
150151
Figure 20,28,
155156
I
I
120121
115116
_I
160
I
I
I
I
125126
..c:
0
I
I
130131
I
>
ttl
I
I
i
105106
I
>
ttl
c::
>
ttl
:2
.g
0..
ttl
en
::t:
>
I
135136
ttl
I
I
>
I
140141
I
0..
«
U
Z
u.
ttl
....
~
(.)
(.)
0
(5
co
I
u
~
c:
0
"0
0
L1J
~
II:
I
0..
0..
Ql
ttl
(J)
I-
I
100101
>
ttl
'E
L1J
L1J
I
I
en
ttl
ttl
I
95 96
en
c:
'E
'E
....
ttl
"3
en
Q)
en
II:
I
en
en
c:
(J)
L1J
I
I
90 91
en
c:
ttl
::t:
::t:
ttl
I-
0
~
0
0
::>
0
Cl
'E
~
-c:
"c
Ql
0
I
c:
....
"c
Overtime
Rate
Previous 13 weeks
~
:c
85 86
80 81
~
0
ttl
I
~
)
ttl
I
u.
-c
~
(.)
en
~
110111
)
I
~
«
I
I
I
75 76
dl 0
>
0..
I
Ql
Ql
~
Ql
I
cI)
I
e
ttl
0
)
60 61
55 56
J
e
(
I
50 51
I
I
I
145146
Section
20
Subsections
Page
I
03
50
40
Each record is composed of 1 word.
The number of records in the file is
the number of employees in the
plant plus 25%. The last entry is
the record number of the last clock
number entered.
Figure 20.29.
c:i
z
~
(.)
Q)
This is the plant information record.
.l:
Plant Name
U
.~
U.
I
I
I
I
I
~
Q)
Q)
s:
I
I
10 11
5 6
0
z
15 16
I
General Ledger
Account Numbers
for Posting
Trade Association Information
I
I
I
I
I
I
I
I
I
I
.J
I
30 31
25 26
J
I
I
35 36
40 41
45 46
for
Available
I
I
I
I
65 66
Figure 20. 30.
I
I
I
70 71
I
I
I
I
I
75 76
I
I
I
I
I
80 81
I
I
I
I
I
85 86
I
u
0
>
s:
::::J
I
I
I
50 51
Q)
Q)
I
...
Q)
I-
I
I
55 56
I
60 61
Expansion
I
I
I
90 91
I
I
I
I
I
95 96
I
I
I
I
I
100101
I
I
I
~
.l:
u
co
.:
u.
!90
0
l-
I
~
s:_Z
~
]t::l
~
Z
~
m!1!
·E
c:i
>
~
~«
I
I
....c:
.s:
,
20 21
~
(.)
Q)
I
105106
I
Section
20
Subsections
50
I
50
Page
01
System Flowchart
Employee
Earnings
Record
Clock No.
and
Name
Zero Balance
Totals
fAY.1§.
INPUT
EDIT
Out of Balance
Control Totals
fAY..Ql
EAX..Q.2..
ADD NAMES
FILE
CREATE
Clock No.
and
Name
File create (initially and as necessary)
All but
Name
Section
20
Subsections
50
I 50
Total on
Adding
Machine
Changes
Control
Total
Zerq
Balance
Total
EAY...1..Q.
INPUT
EDIT
Out of Balance
O.K.
Control
Total
Changes
Control
Total
~
FILE
CHANGES
File changes (weekly)
Changes
Page
02
Section
20
Subsections
Page
I
03
50
50
Weekly
Time
Sheets
Totals on
Adding
Machine
Details
Zero Balance
.f8Y.1.§
Control
Totals
INPUT
EDIT
Out of Balance
Control Totals
Details
Payroll
Register
Zero Balance
Totals
PAY 04
CALCULATION
Details
Control
Totals
Payroll calculations and register (weekly)
Section
20
Control
Totals
Calculated
PAY 05
PAYROLL
CHECKS
Pay Checks
and Stubs
Total on
Adding
Machine
TAPE
Only When
Totals Balance
Control
Totals
PAY 06
CHECK
REGISTER
Check
Register
Control
Totals
Print paychecks (weekly)
Subsections
50
I
50
Page
04
Section
20
Subsections
Page
I
05
50
50
Only When Totals Do Not Balance
Disk
Payroll
Control
Totals
File
Details
PAY 11
VOID
CHECKS
Control
Totals
Payroll check voiding (as necessary)
Details
Section
20
Subsections
50
General
Ledger
Union
Dues
Register
PAY 13
UNION
DUES
Credit
Union
Register
PAY 14
CREDIT
UNION
Stock
Deduction
Register
PAY 15
STOCK
DEDUCTION
PAY 12
RESET
MONTHLY
TOTALS
Payroll deduction registers (monthly)
I
50
Page
06
Section
20
Subsections
50
I
50
Page
07
General
Ledger
Totals
PAY 07
AUDIT FILE
BY COMPANY
Enter Plant
Number
TAPE
Plant
Numbers
Calculated
Control
rotals
PAY 09
--s4I
REPORT
941
Report
Tax
Worksheet
PAY 10
TAX
WORKSHEET
Plant
Numbers
Pa}Toll file audit, 941, and tax worksheet (quarterly)
Section
20
Plant
Numbers
W-2
Reports
Subsections
50
I
50
General
Ledger
PAYnn
---w2
REPORTS
r-----------------------------------------------,.~ TAPE
Plant
Numbers
Print W- 2 reports (annually)
Page
08
Section
20
Subsections
50
1 50
Page
09
Disk
Payroll
File
Select Desired
Clock Number
Card
Clock
Number
Individual
Payroll
Record
PAY 08
INQUIRY
Last Week's
Payroll
Register
Use PAY 16
& PAY 03
to Change the
Disk Payroll
Record
Return to
Print Where
Error
Occurred
Error detection and correction (as necessary)
Only when
entire original
error has been
corrected
Section
20
Remember, all of these pages are developed by
this point in your system design. In addition, they
Subsections
Page
I
10
50
50
now become a part of your system documentation
(see Section 35).
Section
20
Subsections
Page
I
01
60
01
LANGUAGE SELECTION
Introduction
Now that your system has been specified, the implementation of the design must be considered.
Since you will be writing a program, the logical
question is "What language shall I use?"
IBM supplies and supports a wide variety of
programming languages and application programs
for the 1130 Computing System. Among the
programming languages (Type I programs) are:
1130 Assembler Language
1130 FORTRAN
Some of the application programs (Type II programs) are:
• Continuous System Modeling Program (CSMP)
• Data Presentation System (DPS)
• Linear Programming - Mathematical Optimization Subroutine System (LPMOSS)
• Mechanism Design System - Gears and
Springs
• Civil Engineering Coordinate Geometry
(COGO)
• Numerical Surface Techniques and Contour
Map Plotting
• Programs for Optical System Design (POSD)
• Programs for Petroleum Engineering and
Exploration
• Project Control System (PCS)
• Route Accounting for Dairies and Bakeries
• Scientific Subroutine Package (SSP)
• Statistical System
• Structural Engineering Systems Solver
(STRESS)
• Type Composition
• Work Measurement Aids
• Commercial Subroutine Package (CSP)
Your IBM representative can help you determine
which programming language or application program
should be used to implement your system.
In addition to these two types of programs, IBM's
Program Information Department maintains a
library of contributed programs and distributes
these programs to interested parties. These are
contributed to the library by:
1. IBM employees (Type III programs)
2. IBM customers (Type IV programs)
Type II and type IV programs have been submitted to the Program Information Department for
general distribution in the expectation that they
may prove useful to other members of the data
processing community. The programs and documentation are, es sentially, in the author's original
form and have not been subjected to any formal
testing. IBM serves only as the distribution agent.
It is your responsibility to determine the usefulness
and technical accuracy of the programs in your
own environment. Unlike programming systems
(Type I) and application programs (Type II), these
programs are not part of the IBM support package.
The remainder of this section elaborates on
each of the programming languages and application
programs and discusses some of the considerations
in answering "Which do I use?"
Section
20
Subsections
10
60
Page
01
1
Programming Languages
Assembler Language
The IBM 1130 Assembler Language, while similar
in structure to machine language, replaces binary
instruction codes with symbols and uses labels for
other fields of an instruction. Other features,
such as pseudo operations, expand the programming
facilities of machine language. Thus, the programmer has available, through an assembler language,
all the flexibility and versatility of machine language, plus facilities that greatly reduce the machine language programm ing effort.
The IBM 1130 Assembler Language has two
parts: the symbolic language used in writing a
program and the assembler program that converts
the symbolic language into machine language. An
additional component is a library of relocatable I/O,
arithmetic, and functional subroutines.
Symbolic language is the notation used by the
programmer to write (code) the program. A program written in symbolic language is called a
source program. It consists of systematically
arranged mnemonic operation codes, special characters, addresses, and data, which symbolically
describe the problem to be solved by the computer.
The use of symbolic language:
1. Makes a program independent of actual machine locations, thus allowing programs and routines
to be relocated and combined as desired.
2. Allows routines within a program to be
written independently and causes no loss of
efficiency in the final program.
3. Permits instructions to be added to or
deleted from a source program without the user
having to reassign storage addresses.
The assembler program (processor), supplied
to the user by IBM, operates from paper tape, from
punched cards, or under control of the 1130 Disk
Monitor Systems. It converts (assembles) a
symbolic-language source program into a machinelanguage (object) program.
The conversion is one for one-- that is, the
assembler produces one machine-language instruction for each symbolic-language instruction.
The IBM 1130 Assembler is a two-pass program.
The processor is loaded into the computer and is
followed by the first pass of the source program.
During the first pass, source statements are read
and a symbol table is generated. During the second pass, the source program is read again and
the object program and/or error indications are
punched into the first 20 columns of each source
card. If paper tape is used, the second pass results
in the punching of a new tape that contains both
source statements and corresponding object information. If disk is used, this becomes a one-pass
procedure, the disk being used for intermediate
storage. Both card and tape object programs must
be compressed (via a Compressor Program supplied
with the assembler) into a relocatable binary deck
(or tape) before they can be loaded into core storage for execution.
The output from the second pass is called the
list deck (or tape) and can be used to obtain a program listing of source statements and corresponding
ing object statements. Use of disk automatically
compresses the object program into relocatable
(loadable) form. A program listing is an option if
the one-pass disk procedure is used.
A library of I/o, arithmetic, and functional
subroutines is available for use with the IBM 1130
Assembler.
The user can incorporate any subroutine into his
program by simply writing a statement referring
to the subroutine name. The assembler generates
the linkage necessary to provide a path to the
subroutine and a return path to the user's program.
The ability to use subroutines simplifies programming and reduces the time required to write a
program.
A description of available subroutines is contained in the IBM 1130 Subroutine Library (C26-5929).
FORTRAN Language
FORTRAN (FORmula TRANslation) is a coding
system with a language that closely resembles the
language of mathematics. It is a system designed
primarily for scientific and engineering computations. Since this system is essentially problemoriented rather than machine-oriented, it provides
scientists and engineers with a method of communication that is more familiar, easier to learn, and
easier to use than actual computer language.
The IBM 1130 Basic FORTRAN IV Programming
System consists of two parts: the language and the
compiler. The language is a set of statements,
composed of expressions and operators, that are
used in writing the source program. The 1130
FOR TRAN compiler, provided by IBM, is a program that translates the source program statements
into a form suitable for execution on the IBM 1130
Computing System. The translated statements are
known as the object program. The compiler detects
Section
20
Subsections
60
I
10
Page
02
certain errors in the source program and writes
appropriate messages on the console printer, 1132
Printer, or 1403 Printer. At the user's option, the
compiler also produces a listing of the source program and storage allocation.
Section
20
Application Programs
Continuous System Modeling Program
This program provides engineers and scientists
with a simple but versatile tool for solving dynamic
system simulation problems. For many problems,
this program obviates the need to use an analog
computer facility.
CSMP is a "digital analog simulator" program
using a block-oriented input language in which the
functional blocks represent the elements and organization of an analog computer. A total of 25 standard functional blocks plus the ability to define
special functions are provided. The continuous system model may be developed and tested, and results
observed in an online interactive mode by means of
the console k.eyboard and output devices. The simplicity of the language statements enables a user to
rapidly gain proficiency with the program and facilitates modification of the model via the console. In
addition, via the console printer, the beginner is
provided instructional comments that can be suppressed as experience is gained. Simplicity and
flexibility are the foremost characteristics of the
program.
Data Presentation System
This program can present a large variety of data in
plotted forms such as graphs, charts, schematics,
and modified drawings. It supplies high-quality,
hard-copy, graphic output at exceptionally low cost.
The system can be used independently as a Graphic
Report Generator, or the user can choose one or
two levels of subroutines from the system for inclusion in his own graphic output programs. These
three levels of access are made even more flexible
by several system modification and expansion
features. The scope and flexibility of DPS make it
valuable in almost every application of the IBM
1130 Computing System.
Linear Programming -- Mathematical Optimization Subroutine System
LP-MOSS provides the 1130 disk user with a simple,
efficient means of solving linear programming
problems and a means for implementing a variety
of mathematical optimization applications.
Mathematical optimization is any mathematical
technique for determining the optimum use of various resources such as capital, raw materials,
manpower, and plant or other facilities. The
Subsections
60
I
20
Page
01
technique seeks to attain a particular objective
(for example, minimum costs or maximum profit)
when there are alternate uses for the resources.
Linear programming is the most widely used of
these techniques, and has been used to allocate, assign, schedule, select, or evaluate the uses of
limited resources for various jobs, such as blending,
mixing, bidding, cutting, trimming, pricing, purchasing, planning, and the transportation and distribution of raw materials and finished products.
Mechanism Design System -- Gears and Springs
This program provides design and analysis for five
distinct mechanical components used in a wide
variety of machines in all industries. Spur and
helical gears, compression, extension, and torsion
springs are the components covered. The program
provides the mechanical engineer and mechanism
designer with a low-cost, flexible, easy-to-use
program set which will design new parts or analyze
existing parts.
The engineer is expected to furnish the problem
description in terms of design restrictions and
material parameters. This description is in a
flexible problem language format which greatly
simplifies man-machine communication. Operation
can be either by a batch card input mode or in a
conversational typewriter input mode. In the latter
case, an engineer can readily evaluate parametric
changes and truly use the computer as a design
tool.
Civil Engineering Coordinate Geometry
COGO is a simple, efficient tool designed especially
to assist the civil engineer with a wide variety of
geometric calculations. With COGO, the engineer
can state his problems using familiar terminology
common to the engineering field. No knowledge of
traditional programming is necessary.
The civil engineer requires a simple but efficient
means to solve geometriC problems now being done
laboriously by hand. 1130 COGO provides the
solution to his problem by allowing the engineer to
(1) enter the data for the job into the computer by
typewriter or punched cards, using a language with
which he is familiar, and (2) to have solutions
automatically printed out. COGO is especially useful because it provides the facility for the engineer
to try many different methods of solving a problem.
COGO can be used for many different types of jobs,
e. g., control surveys, highway design, right-of-way
Section
20
Subsections
Page
I
02
60
20
surveys, bridge geometry, subdivision calculations,
land surveying, construction layout.
COGO can, in fact, be used wherever geometric
calculation is required.
Numerical Surface Techniques and Contour Map
Plotting
This program provides a variety of techniques for
describing and operating on surfaces. Surfaces
may be described analytically by equations or numerically by sets of data points. In addition, various arithmetic and logical operations may be performed on these surfaces. These techniques may
be carried out individually or in various combinations by storing intermediate data in the online
disk storage. Final output is commonly in the form
of maps drawn by the 1627 Plotter, but may optionally be in card form.
Optical System Design
POSD provides the optical designer with a convenient' efficient design tool. It is in the Computer
Aided Design (CAD) category of programs, thus
exhibiting a close man-machine relationship throughout the design task. The \130 Computing System is
ideal for this interaction, because it is fast, convenient, and inexpensive to use.
POSD removes the drudgery and error-proneness
from the innumerable calculations required in the
optical design and evaluation process and allows
the designer to spend his time exercising creative
and critical judgments. The program gives the
designer step-by-step assistance from the very
early stages of the design through to the final optimization process. In addition, the designer may
evaluate the quality of his design at any time he
chooses through many data plot or printout routines
or both. Using this program, the optical designer
can tackle virtually any lens system, including
those requiring a high degree of sophistication, with
the assurance that the lens performance will meet
specifications in modeling and manufacture.
Programs for Petroleum Engineering and Explora-"
tion
Economic Evaluation of Petroleum Projects Program can be used to screen drilling proposals and
rank them according to their profitability. Given
the investment schedule and production forecast for
an exploration and drilling prospect, the programs
compute the payout period and rate of return using
the discounted cash flow method.
Casing Design Program allows the user to design
the most economical combination casing string, in
terms of grade and weight, that will meet the requirements of a given well.
Decline Curve Analysis Program computes the
coefficients in the equation best fitting past production data and the reserves associated with these
data.
Tarner Material Balance Program is an aid in
predicting the performance of a reservoir.
Schilthuis Material Balance Program for a reservoir that is subject to water influx, is evaluated
at each past production data point (for up to 28
points). These values are weighted according to
oil production and subjected to a least-squares
solution to compute a most probable value of the
original oil in place.
Two-Dimensional Waterflooding Program allows
the user to determine the pressure distribution
throughout a reservoir, taking into cons ideration
the effect of water injection.
Gas Deliverability Program allows the user to
project the annual rate at which volumes of gas
reserves may be received into gathering systems.
Multi-State Flash Calculation Program is a
general purpose flash claculation program that can
be used for a variety of the computations made by
the petroleum engineer. The program may be used
to design surface separators or to determine the
physical properties of the oil and gas from a surface facility. A laboratory differential liberation
may be simulated.
VelOCity Functions from Time-Depth Data Program permits"a geophysicist to derive a velocity
function and to prepare a tabulated time-depth chart
from well vel oci ty data.
Wave-Front Ray-Path Determination Program
provides a flexible method to compute and tabulate
a seismic wave-front ray-path chart; the geophysicist uses such a chart to restore seismic reflections to their true subsurface position.
Synthetic Seismogram Program computes and
plots a one-dimensional seismic model from well
log data.
Gravity and Magnetics Continuations, Derivatives, and Residual Program provides a method for
computing (1) upward and downward continuations of
gravity and magnetic fields, (2) first and second
derivatives of these fields, (3) residuals of arbitrary
type for gravity and magnetic values.
Section
20
Theoretical Gravity of a 3-D Mass Program
allows the user to establish a synthetic gravity
anomaly by computing the theoretical gravity of an
assumed mass.
Quantitive Log Analysis Program permits the
user to compute the porOSity and water saturation
on prospective hydrocarbon zones in a well, using
data from several log combinations.
Dipmeter Program is designed to assist in the
analysis of the continuous dipmeter log by calculating
the true dip of intervals in a well.
Project Control System
This program provides a basic tool needed by
management to fulfill its responsibilities in the
planning, supervising, and controlling of projectoriented work. In addition to critical path analysis,
the system provides the capability for summarizing
externally prepared resource and cost.information.
For critical path networks, the 1130 PCS will
process 2,000 activities either in the form of
precedence lists or in ij/PERT / CPM notation. Its
design allows for a simple approach to networking,
but also offers many of the features normally found
only in programs designed for large computers.
Route Accounting for Dairies and Bakeries
This is a set of programs offering the functions of
route settlement and associated report preparation
as required in the dairy and baking industry. Output includes order listings, production requirements,
load listings, product load strips, route settlement,
and statistical reports.
Scientific Subroutine Package
SSP is a collection of FORTRAN subroutines that
provide a major addition to those built into
FORTRAN. They are input/output-free, computational building blocks that can be combined with a
user's input, output, or computational routines to
meet his individual needs. The package has widespread application to the solution of problems in research, development, and design, in both science
and engineering, wherever FORTRAN is used.
Subsections
60
I
20
Page
03
Statistical System
This is a collection of four major tools: stepwise
regression analysis, factor analysis, analysis of variance, and orthogonal polynomial curve fitting. This
flexible system accepts user-supplied control cards
(and data) that instruct the system to perform one or
more of the above analyses.
Structural Engineering Systems Solver
STRESS is a powerful tool for solving structural
engineering problems. It is a problem-oriented
language that enables the engineer to communicate
with the computer even though he has had no previous
programming experience.
This program covers many application areas in
the field of structural analysis. Most buildings
and bridges are designed by consulting engineers
or government agencies, but many other types of
structures in other industries can also be designed
using 1130 STRESS. Some of the other industries
and typical applications for each are:
Industry
Typical Application
Aerospace
Wing members
ManufacUlring
Conveyor framing, plant design
Process
Supporting towers
Utilities
Transmission towers, culvert
sections
Federal
Dam design, ship design
Type Composition
This program extends the speed and flexibility of a
digital computer into the composing rooms of the
printing industry. Type compositors can use this
program to provide significant time savings in
transcribing textual material into a form required
by linecasting machines for setting type.
The program is designed to allow computer
acceptance of perforated paper tape containing
(1) the copy that is to appear in print and (2) instructions pertaining to a desired printing format.
From the paper tape, a tape suitable for controlling
the operations of a linecasting machine is produced
and allocated to the proper point in the composing
room. The output tape contains the original copy in
the form of properly justified lines arranged according to the stylistic and graphic requirements described
by the user with the format instructions. The programs are capable of producing justified lines in
any format within the inherent limitations of the
linecasting machine.
Section
20
Subsections
60
I
20
Page
04
Work Measurement Aids
Commercial Subroutine Package
This program aids manufacturers who need to
know the time it should take to manufacture a produc t. This task, often referred to as work measurement, has traditionally been very time-consuming
and expensive. Work Measurement Aids provides
two programs to assist in setting time standards.
This information also forms the foundation for labor
standards, cost estimates, machine operation
instructions, and scheduling input. The two programs are:
Machinability, which determines optimum machine tool parameters such as speed, feed, horsepower,
tool life, and process time for machining operations.
Work Measurement Sampling, which determines
job standards for long cycle operations (over 15
minutes) and the distribution of time to job activities
(conventional work sampling) .
This program provides the scientific and engineering
user with added capabilities for handling functions
and techniques common to commercial programming.
It is a set of 28 subroutines callable by the
FORTRAN programmer in a similar manner to such
standard functions as sine, cosine, square root,
etc. The subroutines enable the 1130 user to add
commercial applications such as payroll, cost accounting, and many others.
The additional functions supplied are variable
length alphameric move, variable length alphameric
compare, variable length alphameric edit, variable
-length conversion from EBCDIC to floating-point,
variable length conversion from floating-point to
EBCDIC, zone manipulation, fill an area with a
specified character, stacker select, variable length
decimal add, variable length decimal subtract,
variable length decimal multiply, variable length
decimal divide, variable length decimal compare,
sign manipulation, overlapping printing and carriage
control, overlapped reading of cards with conversion of card codes, overlapped printing on the
console printer, and conversion from one character per word to two characters per word.
Section
20
Which Programming Language or Application
Program Should You Use?
In terms of coding ease and elapsed time from
problem definition to operating program, the programming techniques available to you will generally
rank as follows:
1. Application programs (except Commercial
Subroutine Package and Scientific Subroutine Package)
2. FORTRAN, Commercial Subroutine Package,
and Scientific Subroutine Package
3. Assembler Language
The Assembler Language is rarely used, because FORTRAN, augmented by the Commercial
Subsections
Page
I
01
60
30
Subroutine Package and Scientific Subroutine Package, is more than capable of handling almost all
applications, is' easier to code, and produces
efficient programs.
The brief descriptions given earlier will help
you to select the best language in which to program
your applications. A preview of the payroll programs given in Sections 25 and 35 will give you a
clearer picture of the kind and amount of writing
required to code some typical commercial jobs.
In addition, Section 70 discusses FORTRAN,
the Commercial Subroutine Package, and how to
use these two tools in implementing your system
design.
Section
25
Subsections
Page
I
01
00
00
Section 25: PROGRAM DEVELOPMENT
CONTENTS
Introduction ........•................
Programming and Documentation
Standards ........................... .
Program Change Authorization ....... .
Programming Aids .................. .
Documenting Variable Usage ....... .
Modular Programming .•...........
Programming Examples ..........•....
Introduction ...................... .
25.01. 00
25.10.00
25.20.00
25.30.00
25.30.10
25.30.20
25.40.00
25.40.01
Example 1: File Creation ..........
Example 2: Add Name to the File ...
Example 3: Changes to the
File
Example 4: Calculations and
Payroll Register .......
Example 5: Check Writing
Example 6: Check Register
Example 7: 941 Report
25.40.10
25.40.20
..................
25.40.30
.........
........
25.40.40
25.40.50
25.40.60
25.40.70
............
Section
25
INTRODUCTION
This section is a workbook for the programmer.
Primarily by example, and to some extent by narrative, he is furnished with a guide to coding.
First, suggestions are made for the adoption of
certain standard practices that will make the programming job easier and the results more uniform.
Then follows a series of programming aids.
The bulk of this section is occupied by the final
part, a group of examples of coding required to
Subsections
Page
I
01
01
00
implement a significant part of the payroll system
discussed earlier. They will prove useful in providing a starting point for the programmer and illustrating proven programming techniques, rather
than in being usable without change for any given
installation's system. Note that programs are
written at this point in the installation of your system. Also, Variable Summary Sheets are filled in
and flowcharts are drawn. These last two items
now become a part of your documentation (note
references to Section 35).
Section
25
Subsections
Page
I
01
10
00
PROGRAMMING AND DOCUMENTATION
STANDARDS
For a discussion of the documentation that you
should have upon completion of a program, see
Section 35.
It is advisable to decide on and write down, perhaps following this page, your own standard procedures for handling the situations below. You should
have some knowledge of programming before attempting to do this.
1. Alternative methods of handling standard
types of errors (for example, missing date card):
a. Assign a standard halt number.
b. Assign a standard halt number and error
message.
c. Assign a standard error stacker; do not
halt.
2. Standard error messages:
a. Establish a log of error messages and
halt numbers and their meaning.
b. Standardize spacing, skipping, location,
and whether to halt for each standard error message.
3. Standard FORTRAN labels:
a. Assign a standard symbolic name for
each I/O device.
b. Assign standard field names for fields
used frequently.
c. Assign standard subroutine names for
routines used frequently.
4. Record layout conventions:
a. Define standard heading (for example,
date to left, title in center, report number and page number to right).
b. Define spacing (for example, when listing,
single-space detail, double after minor,
triple after intermediate and up; when tabbing, single-space after minor, double after
intermediate, triple after major and up).
c. Define how totals are to be indicated
(with asterisks or message) .
d. Define how final totals and control totals
are to be printed (for example, at bottom
of page, on next page).
.
5. Specify when flowcharts are required for program logic:
a. When a significant number of GO TO or
IF statements are used.
b. When a complex table lookup is performed.
c. Whenever the logic of the computation is
so complex that another person would
have difficulty following it without the aid
of a chart (decision tables may be best).
6. Describe how program changes are to be
made:
a. Require changes to be authorized.
b. Assign all changes to a programmer
through the manager of data processing.
c. Keep track of time spent making program
changes by application and by initiator of
change.
d. Require that all necessary documentation
be brought up to date.
7. Outline methods of testing programs:
a. Define conditions in which a test deck is
sufficient.
b. Define conditions in which a program
must be production-tested before installation.
8. Standardize writing of specifications:
a. Establish a standard identification (see the
accompanying FORTRAN coding form).
b. Use a standard form of program identification, such as a three-character application code followed by a two-digit
program number (for instance, PAY10,
PAY20, BIL10).
Section
25
All changes to an operating program should be
controlled in order to avoid confusion and
PROGRAM CHANGE AUTHORIZATION
Program _ _ _ _ _ _ _ _ _ _ _ _ __
Requested by: _ _ _ _ _ _ _ _ _ _ _ _ __
Change Authorized by'
Date Coonge to be Effective
Date
Date Authorized
/
/
I
I
I
/
Actual Effective Date
/
/
Programmer:
Assigned for Change _ _ _ _ _ _ _ _ __
Original
Date Assigned
/
I
Systems Design Hours Required _ _ _ __
Coding/Debugging Hours Required _ _ __
Page
I
01
20
00
unauthorized changes. The following sheet is
suggested as a means of maintaining control.
PROGRAM CHANGE AUTHORIZATION
Application _ _ _ _ _ _ _ _ _ _ _ _ _ __
Subsections
Date Completed
I
I
Section
Subsections
Page
I
02
20
25
00
IBJ.1
Form
Poge
Punching Instruction,;
Program
1
I I I I I I I
Graphic
Programmer
IDote
I
i
..3
*
/ICard Form'll
10
15
20
30
25
I
"'UM.61r:U~.
:ra8
c---- -
I
73
II
J
1--
1
1
J
40
35
1
1
1
1
1
1
,
1
55
50
45
J>.A'IE.
C.OI>IED
c.--- -.1
c ____ _
,
,
C----I-
1- -
,
,
1
,
1
1
1
1
70
1
1
1
1
I
J
,
,
1
1
I
I
,
.F.LLc
I
NA"tI.E
,
.~
I
I
,
.o'tl
,
,
,
riUM
e£ ~
,
L E IM;..r.H . .RI. COl( b IS
1
1
I
I
,
1
,
.P.E.1l1 .S
e
C ·1"to.12
1
1
,
c- - - - c --- -
O.U.IIP.Il.T.
C----f-
1
c ____ _
-
FJJ:.L £.5.
1
I
I
-
"
--
3 .
I
'I
.11 .
.21.
1
-
- ,.
I
I
,
,
'I
,
1
,
1
,
1-
-
1
1
1
*
80
I
c-----
-I-
1
I
65
60
J
c,-----
of
Identification
FORTRAN STATEMENT
5 6 7
I~---- -
I I I I I
I
Punch
r= C FOR COMMENT
tS~~TEMENT
NUMBER
X28-7327-4
Printed in U.S.A.
FORTRAN CODING FORM
1-
-
-I
-
-
1
1
1
1
,
,
1
,
1
I
1-
-
1
1
I
J
1
1
I
,
1
1
I
I
1
1
A standard card form, IBM electro 888157, is available for punching source statements from this form.
1
1
Section
25
PROGRAMMING AIDS
Documenting Variable Usage
Especially when writing a large program in
FORTRAN, it is difficult to remember the functions
for which the variables have been used. This problem may arise during testing, particularly when
several programs are being tested at one time.
Again, program revision at a later date can be
Subsections
Page
I
01
30
10
difficult, and the problem is intensified if the revi'sion is being 'done by someone other than the original programmer.
The Variable Summary Sheet is a suggested form
for recording the usage of variables.
The sample shown here is related to PAY01
shown later in this section. Both the variables used
and the type (I, R, D, A) are indicated in the columns
to the left of thy form.
Section
25
Subsections
Page
J
02
30
10
VARIABLES
IBM
I
1130 COMPUTING SYSTEM
VARIABLE SUMMARY SHEET
Vl
-c
NAME
0
*W
$
0
'0
0
::2
z
ci
a..
::21w::J
1-0..
MAX.
j:::~ VALUE
~O
Date
Application
MIN.
VALUE
Program Name
~
*Mode: I = integer, R = real, D = decimal, A = alphabetic
No.
FUNCTION OF VARIABLES
Programmer
Section
25
VARIABLES
IBM
T
Subsections
Page
I
03
30
10
1130 COMPUTING SYSTEM
VARIABLE SUMMARY SHEET
Vl
'"C
(;
NAME
*W
Cl
0
2:
s:
..-
a..
2:1-
w::J
I-a..
~~
ci ~o
~
0
MAX.
VALUE
MIN.
VALUE
PAYROLL SYSTEA?
Program Name
z
1/2 /~ I;tJ
P8PE R ~4
Hie C rec:7 /e
Date
No./?4YO/
ap'~~7
Khc.E;..
Programmer
FUNCTION OF VARIABLES
Ck"MAX' R ~ T /Nt1.~ ¢.¢(/
COA4P
Application
-
-
Md%/h-1t//7l
cAecL t:7/?"?ov/J~ /br t:? ./;/e,
Ct)q;~U'.n!f //t?r.nt:!?
0 ~rP~ ~¢'~ Trdk ~SSoc/pl?on repe:;rh.
v~ed I ' n 2)0 /t:?o,P
1" 1
Z
r
Et7~/;"'a/e/7~ I-GJ .£/1/1
Z / AI' Se-,J ,.t'or
/ T each rva .iJe.q/;?r)//;t:/ ch~c.l;;. "'t;n·?/;~r t://Ae/J uN,'/f/,UI Ch~c.es.
l.lCIICIC
Record r}~~~er/'1 c/17p/o;/ee ;e://e:s:. se~~ ~..:1
yeo!.. I I T 250 f
"PL4~1'
Rle
r1u,nbe"" t:P~ /;"'d4?,X Pc:::>r a /,/t?I'?/: ,.0# + /eJO
/(;15/
fA/£)
Z / T /o~
fA/OEX I 2£ T >(X}(X I~rd(i f/74'~x to ,,0/4"/ /itt:)t.V 6~/"'~ ,Pr~ce;s.sed
¢
(//7/,0',., I/;/ rI (:,h~,., I'e e
¢
L/l/LT I I 0
LNI I / r 250 1 P€lct:Jrd ,?vh'?kr /A .1'nd~xe5 ~Em,P~:fee"s:;k
Z,A/Z f I N - qPI'vt:?k,?/ T~ fA/L
E,/v/v4/t!?n~ ?"o I A/.t
INS .z / AI - .t6t~/·vtt?Ie'/7r ~Q Z #.1
l' A/4- I / AI E~V/~4/~/?r 7'oJ/1/1
INS I / AI - .,..
E~t//'vc?/~/Jr T~IA/:f
£/./6 -' I AI
;r~c-.;~s S f4!tlS o~~cod;,;' ,t'rx~.ssl;"-!1 o/c~
IPP Z / 0 ~ ¢
fSC/)oP 17 1,3 0 ¢
[LJ SI./,PtDlt:!?m~rJ"4/ Sl'c~ P~y
ZTCJT lr /1 r 1723 ~ ;lc~ovn~ /lvh1~~r ,t;rposh".,! 1"" /;' ~~Er"'//tedf~1'
~e~ t:)f' r;'~ /J?t::';?rh
rl1/EEK f / T S- .f
Ie
r
- -
*Mode: I
=
integer, R
= real,
D
= decimal, A = alphabetic
Section
Subsections
Page
I
01
25
30
20
Modular Programming
General
Modular programming is used to divide your problem
solution into its logical parts or routines so that
each routine may be programmed independently. It
enables your complex problems to be divided into
many simple sections. A building block program is
thereby created that is controlled by a single routine
commonly known as the "main line" .
A modular program utilizes the same communication system as established by an organization
chart. Work assignment decisions are made by the
main line routine, which is not concerned with the
functions of the processing routines. If for some
reason a routine is revised or eliminated, other
processing routines within the program are not
affected. However, a segment of the main line
might be changed.
There are three primary design criteria of modular programming: ease of understanding, ease of
program modification, standardization of program
construc tion.
To prepare and use an operational program
effectively and efficiently, you must be able to
understand the content of the program readily. Ease
of understanding is provided in the following three
ways:
1. Modular flowcharts. A modular system flowchart gives an overall picture of the major components and structure of the routine; program flowcharts then progress to any desired level of detail,
depending on the complexity of the routine. The
program coding is referenced throughout.
2. Detailed narrative of each routine. The narrative of each routine states the purpose of the
routine, describes the data processed by the routine,
and explains each step of the program logic as portrayed by the modular flowchart of the routine.
3. Programming conventions. The use of standard labeling conventions and standard program documentation techniques enables a person unfamiliar
with the program to readily understand the program
content.
Years of experience have shown that, with 98%
assurance, all of your operational programs will
require modification and change during their useful
life. Ease of program modification is of cardinal
importance when your program must be converted to
fit a specific new situation. This may be because of
changing company policy, varied environmental
parameters or different management objectives.
Your programmer, then, has the problem of creating a program that can be adjusted to each specific
situation. There are two ways of handling this
problem.
One is to try to anticipate every type of special
situation that might be encountered and write a set
of routines to handle each situation. This would
require a fantastic ability to forecast the future and
would lead to slow, cumbersome programs.
The other alternative is to create a program that
can be quickly understood and easily modified to reflect changing conditions. Modular programming
aims to accomplish the latter alternative.
Once again, you may more readily prepare and
more quickly implement an operational program if
all the runs (programs) within your application adhere to a standardized construction. As indicated
above, the logical structure of your program must
be such that modifications and additions can be
easily made.
Consider the problem of multiple routines - for
instance, three economic order quantity routines.
The normal method of lumping these three routines
into a program necessitates setting switches to tell
the program which routine to excute at a given time.
Any attempt to modify one of the existing routines
necessitates trying to extract the routine, patching
up the holes in the flow of the program created by
the changes, and then fitting the modified routine
back in. Anyone who has ever tried to modify a
program written by someone else knows how difficult
it is to dissect and patch another person's logic if
the 'routines are intertwined.
U sing modular programming, each routine is a
separate entity. Your main line routine provides
the master control that ties all of your individual
processing routines together and coordinates their
activity .
Modification of routines is simplified. Furthermore, new routines may be added by simply expanding the main line routine to transfer control to the
new routine in the proper sequence.
Modular Programming Conventions
Modularity is accomplished by employing the
following conventions:
1. The main line
a. The main line routine makes all decisions
governing the flow of data to the proper
processing routines.
b. No processing routine can direct data flow
to another processing routine.
Section
25
c. Input and output functions that are common
to more than one processing routine are
controlled by the main line routine.
2. Processing routines
a. A separate processing routine is created
for each logical segment of the program.
It should accomplish one task in its total-
ity.
3.
b. Each processing routine is complete within itself, with its own defined areas, when
such areas are for the exclusive use of
that routine. No decision made outside
the segment should determine the processing within a segment, and likewise, no
decision within a segment should determine
the processing outside the segment.
c. Each routine is designed so that it is, in
effect, an out-of-line subroutine. Control
is transferred to the processing routine
from the main line routine, and when
the routine has performed its function, it
sends control back to the main line routine.
Entrance to and exit from the routine
never depends on a particular preceding
or trailing segment.
d. A processing routine may transfer control
to a multiple-use subroutine. When that
routine has performed its function, it
transfers control back to the processing
routine.
e. Input or output functions that affect only
one processing routine may be performed
by that routine. All segments should
contain their own initialization to ensure
noninterference with other segments.
f. A debugging aid that is sometimes useful
is the inclusion of pauses at the exit of
processing routines. During testing, the
pause indicates that a particular processing routine has been executed. After
the routine is checked out, the pause is
removed. The insertion of GO TOs into
the program at strategic points may also
be used to bypass the testing of particular
routines. Action to be taken regarding
such PAUSEs and GO TOs must be known
and documented before the testing session.
This technique tends to make good use of
test time.
Multiple-use subroutines
a. If the same sequence of statements is used
by two or more processing routines, these
statements should be established as a
multiple-use out-of-line subroutine.
Subsections
30
I
20
Page
02
b. A multiple-use subroutine must be well
documented for the purpose of program
modification. Comments cards should be
used to indicate which processing routines
call upon each multiple-use routine and to
document the linkage established.
Designing a Run
To design a modular program, determine the program variables. List the requirements, elements,
and functions of the pr0gram as they come to mind,
giving no attention to logical order.
Once the variables have been set down, reviewed,
and revised, determine the logical order of the processing routines, and design the main line of your
program. Construct your main line so that the
largest volume of data is processed by the lowest
number of instructions - that is, in the fastest
possible way. A speedy main line contributes
greatly to the throughput capabilities of your program.
Once you have established the logic of your main
line, draw the overall, big-picture, system flowchart. Give careful attention to this diagram because it will tend to reveal most errors in logic.
The following components are generally found to
be present in the main line of typical programs:
1. Beginning of item. Before obtaining a record,
it is often necessary to initialize certain switches,
counters, and areas. Generally, fewer ins tructions
are required to initialize before entering a routine
than after exiting from it, since routines commonly
have several exits.
2. Obtain the item. This segment of the run
retrieves the record, sequence-checks the file, and
updates the input control.
3. Process the item. The processing of the
record is accomplished. The main line transfers
control to the proper processing routines in the
proper sequence.
4. End of item. Generally, there are a few instructions to be executed just before disposing of a
record. The instructions associated with the cleanup work for the present record should not be confused with initialization for the next record.
5. Dispose of the item. This segment of your
run generally puts the record in an output file, updates the output controls, and transfers the program
to the beginning-of-item routine to start the loop
again.
Use the modular technique with a block wherever
it simplifies the logic of the processing routine.
Each routine should be as efficient as possible.
Section
25
Subsections
Page
I
03
30
20
Look for opportunities to consolidate several in-line
routines into one multiple-use subroutine. While
sophisticated programming techniques are acceptable,
the particular degree of skill and knowledge available to maintain and modify the program should be
kept in mind.
The following suggestions may help when programming and documenting:
1. List the functions of your routine.
2. Plan the logic of your routine and sketch a
flowchart.
3. Program your routine.
4. Draw the final modular flowcharts of your
routine, shown to the necessary levels of detail.
5. Create the test data so that every leg of your
routine will be thoroughly tested.
6. Write the detailed narrative of your routine.
It is easier to document your routine when the
information is fresh in your mind; furthermore, the
documentation thus produced is more meaningful
and more comprehensive.
Summary
It has been found that programs employing the
modular technique are efficient from the standpoint
of both core storage utilization and program execution time. Section 90 illustrates the importance of
these techniques.
Furthermore, extremely comprehensive and
detailed applications, designed and documented
with the use of modular techniques, may be readily
understood by non-pro gram-oriented personnel,
ranging from company executives to novice programmers.
Section
25
PROGRAMMING EXAMPLES
Introduction
The examples in this section show various basic
programs in the payroll system. Note that these
Subsections
Page
I
01
40
01
examples are programming illustrations and therefore may not be considered as complete, usable
programs.
The programs are arranged in the order of their
complexity, progressing from the simplest to a
complex file-update run with exception reporting.
Section
Subsections
Page
25
40 110
01
Example 1: File Creation
This program reads cards containing employee
earnings information. The information is edited
for reasonableness and then written onto the disk.
The program illustrates a simple single-file at a
time run, with a minimum of calculations. The following programming techniques have been used:
1. Documenting with comments. Comment
cards have been used to document the program
logic. The program name and other indicative information are documented at the beginning of the
program. Comment cards describing the processing to be performed are placed before each logical
section of the program.
2. One-at-a-time input from the console keyboard. Data items to be read from the console keyboard are requested one at a time (statements 69+1,
69+2, and 69+3). This technique will reduce console
input errors and will notify the operator when a requested field has been completed (the keyboard request light will go out).
3. Entering a partial record. Since the complete employee record requires more than 80 card
columns, it cannot be punched in one card. 'Fhe
name, which requires 18 card columns, is punched
on a second card. However, to prevent a name
card and its associated employee record card from
becoming separated, the employee name is stored
on the disk by PAY02.
4. Editing for reasonableness. Fields on a
card which have limits, or a range of values, are
checked to ensure that they fall within the range
(statements 100 through 109). This provides an
effective control of the information being stored on
the disk.
5. Program identification numb~ing. The program identification for the· File Creation Program
in the Payroll System is P1\Y01. This method of
identification uses a three-character alphameric
abbreviation of the application, followed by the twodigit run number in the application .. Identifying
programs and documentation in this manner facilitates an efficient system of organizing and filing the
documentation and the various decks pertaining to
each computer run.
6. Using packed data. To take full advantage of
the disk storage available, as much information as
possible is packed. This includes the employee and
plant name fields. In addition, where possible,
some values are compressed by storing them as
integers rather than real numbers.
7. Setting up for future reference to the file.
The file organization scheme to be used in the payroll system is indexed sequential. This program
must create the index, in addition to creating the
file. Notice that there is an index entry for each
employee. Later programs will be able to locate
any employee by simply searching the index in core
storage and then reading the employee record. The
relative position of the employee number in the index is the record number of the employee in the
file.
8. Variable Summary Sheets. These very important forms are present in the following pages.
They have been prepared for this program and all
other programs in the system.
Section
25
Start
Initialize
Variables
Setup
Name
Field
Retrieve
Company
Name
Yes
Setup
Quarterto-Date
Information
Check the
Data for
Reasonableness
Initialize
Trade
Association
Information
Subsections
Page
I
02
40
10
Section
25
Subsections
Page
I
03
40
Clock
No.
Pay
Rate
"8u
)(
Jl
10
!!!
Social
Security
No.
.S!
"'~
~
c~ ~
.!!
al
x
W
Gross
Earnings
YTD
FICA
YTD
FIT
YTD
Local
Tax
YTD
Credit
Union
Deduction
1
6
~
co ..
~
.~
Union
Dues
Blank
'5 S
::i!(J')
Blank
00000 000 0000 00 0000 000 0000000 00000 00 % 0 00000 00000 0000 0000 000 0000 000000 00 000000000
1 2 3 4 5 • 7 • • 101112 1314 151.171. 1.2021 ~232425282728 21 30 31 3233 34 35 38 37 38 39 40 41 4243 44 45 48 47 48 4950 51 52 5354555& 575&59 60 &1 62 83 &4 85 8& &7 &8 69 7071 727374757677787980
1 1 1 1 1 1 1 1 1 1 1 1 11 1 1 1 1 111 1 1 1 1 1 1 1 1 1 1 1 1 11111 11111 1 1 1 1 1 1111 1111 111 1 1 1 1 1 1 1 1 1 1 11 111111111
22222 222 2222 22 2222 222 2222222 22222 22222 22222 22222 2222 2222 222 2222 222222 22 222222222
33333 333 3333 33 3333 333 3333333 33333 33333 33333 33333 3333 3333 333 3333 333333 33 333333333
44444 444 4444 44 4444 444 4444444 44444 44444 44444 44444 4444 4444 444 4444 444444 44 444444444
55555 555 5555 5 5 5555 555 5555555 55555 55555 55 5 5 5 55555 5555 5 555 555 555 5 555555 55 555555555
66666 666 6666 66 6666 666 6666666 66666 66666 66666 66666 666·6 6666 666 6666 666666 66 666666666
7 7 7 7 7 7 7 7 7 7 7 7 7 7 7777 7 7 7 7777777 777 7 7 77 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 777777 7 7 777777777
88888 888 8888 88 8888 888 8888888 88888 88888 88888 88888 8888 8888 888 8888 888888 88 888888888
99999 999 9999 99 9999 999 9999999 99999 99999 99999 99999 9999 9999 999 9999 999999 99 999999999
1 2 3 4 5 • 7 • • 101112 13 14 151.171. 1.2021 122232425282721 21 30 31 32 33 34 35 36 37 38 39 40 41 4243 44 45 48 47 48 4950 5152 5354555& 575&59 60 &1 62 63 &4 65 8& 67 &8 69 7071 72 73 74 75 7& 77 7879 &0
Section
IBM
I
Page
I
04
40
25
VARIABLES
Subsections
10
1130 COMPUTING SYSTEM
VARIABLE SUMMARY SHEET
0
a.
"0
~r0 w::J
r-a.
s: --r'0 r-::J
~
z
VI
NAME
*W
a
R8PE R
.z
I
%'4
I
.L/\/LJEX
LA/IT
JAIl
INZ
Z,A./,S
/Nt!.~ ¢.~(I
~
-
I AI
-
1'/t/4- I / A./ .TN'S .E I AI I//'6 ~- I AI
IPZ;> Z I 0 t»
TSC/;OP ..T 13 0 ¢
ZTtJT .T II r 1723
*Mode: I
1
F; Ie C /'ec7 /e
No./?4YO/
ap~;/07
K~(:;k-
Programmer
MdX'/;,y;P/Tl c~ecL c:7,fl?OU/7/- ,!br4 .,/J/e,
Ct)H7~a.n!/ ndn7c?'
T
S-
Ei'V'/~a/ea:t'
rc;
.£A/..I
.i3e.q/;?nl/J4 cA~c.i:;. /1"'m.?/;~'" ~;'e/J
-Wr~/em~,,;l4/ SI'c./: ~~y
~
;It:~O(N?/- /1VR1¢t!'r;;,..;:,oShl1,ff 1'() /;' ~/?Er"'//4!~~1'
.f
~e~
= integer, R = real, D = decimal, A = alphabetic
tf)1'
~A r!'
/J?t:!);?rh
Section
25
Subsections
Page
I
05
40
10
VARIABLES
IBM
I
1130 COMPUTING SYSTEM
VARIABLE SUMMARY SHEET
III
0-
"E0 :2fw::::l
NAME
*w
0
0
:2
~
'0
f-a. MAX.
;::~ VALUE
MIN.
VALUE
ii20
L.BT
r
LAIC
£ /
LAST
Program Name
~/ /e
-
I
,-:-;-Y5/~.A¢
AI -
N
~u/vt?k~;// ~o
Date
8j/sh7
K//ck:.
ra/ Programmer
Creq;/e
FUNCTION OF
L"80
/<
P4 VROLL'
ci
z !:
.1 I .AI (2f
Z I ;- 9
Z / T XxX ¢
z / N
-
ZfYJ/A
Application
No./??
VAR~ABLES
ICOL.
Lt?S/ qJ,rd /~.s,t
£4'.5/ /"C'?cor/ nan/~er //'7 /3/e
-
E1'/.//va/e',n/ ~o .z-eOL
qu/vok/7/ ~t7 feaL
-
E?U/Vdk,/~~ /0
ZeaL
L57 .r / T 2.50 ;:::>5$ ~tt?.s/ recortr',l')vn-"6&,,.. /r; q /)/e
Til /S 'dt?/lr's dCCth??U/lf?ho"'7 tJ,<' hOd"'-,s &ulOr,l:~t?
¢
LY,k-WR .I I 0 ¢
r~r vt?_~/-;On PQ!?
A4
I
I
r
U'set7 /""
/WAR Z / ~6 2
MI/A/C E I AI ¢
N~tJW/I E / 0
-
-
¢
¢
tVAM6
(/£ 9 ;;~
/f/C#'C"e,
I
/f/CV
L /
Alct/~.tJ
Z
I C)
r
r
I I;/J
I
0
t;~ X>(.)(''X.
~
I
A4d~//a.1 ..s-.1',1';:.IS"- (l-s/;'g/ehrP-/Y?drr/'ed)
-
EPv/vq/~/)f .10 ZC~L
¢
4d~Y;"'rJq/ u.I/,1hA4!1 MA 9 ~/1'7Pu",~
at
(,tf
¢
/ ;;;; xx. xx ¢
M'¥~S(1!l
NA4lse E I 0 ¢
If/t7P.lT £ I / ~
f
NOvE'S
Xx.x>(
:Do loop
~P1~I¥ 4r~ ,Iot?/~Cd~c/ s;t/dce
hr ""t1me
CAec.l:. /7vn?.6er vs-ed /2,,... 7:4/s eh~/O..Ye~
c~~.~;t ~~!,~~;, c~/~r-/c/'~ /'~r~
#o"lh~ C~e~/ (//1/0I"i ~pt!v~ r;OhS (In c/'mes)
(h,/C;I'1 4ves dtpdvcr-/on
.Tr1SVrp4Ce
d~~/veh~n
l'f,f/s('"'~I/e1~eat.ls d~d'ucl/o'-?s-
P/,,,r flv,nbt!!"r
*Mode: I = integer, R = real, D = decimal, A = alphabetic
Section
IBM
I
Page
I
06
40
25
VARIABLES
Subsections
10
1130 COMPUTING SYSTEM
VARIABLE SUMMARY SHEET
MAX.
VALUE
I-c..
f::~
~o
MIN.
VALUE
PA yROL L SYSTE;-W
Prngram Name
~
"c/ /e ered /-e.
Date
No./34;/C/
C3j/S/67
K'//6/c::.
Programmer
FUNCTION OF VARIABLES
I [l;CJ 3yf{ff
/2S Ep~/C)'y,ee P&?y .". <:7/t::::~
Z I 10a .9
Sex-(/-/e/7/4/e) ,(2-",14/e)) (3-Ir-UI'Cker)
I
A/5sAN I 3 Iz;o 1l/t(l4f~S 9tltj,/$ ~oc/a/ SecL/.,...;/;' r?dn7b~/7
# ...s·cX
En-J,Plo~ee .:sl.rlh~s -(/-c.//JN:m.J) ('2- r,..~clc.e""J.,(B-"oa."'l'1ioa)
rvll -h""e).,(4-,,0.-1-u.t?':t:),,.! 'pdr r 1-';~/e)J~--rt!:"',..,n;r1~rt!'d)
WST .45
Z
/
/VSTCK
I
/ 11;"0
A/STkZJ
.I I 0
Nt/A
{/rJ/!ec! a/~e'd/ cledvc:l/pr7s
t;tJ X)(.XX ¢
.£ / ?;tJ .xX'XX I~~¢ CL'()t:i:- /1 Un? be/"
Z
/V't/M
AlWKUP I
;(//1/,,1(R LJ I
*Mode: I
=
xx.xx
ct
slock. ,c'!Rc!vcr'/CJn
.r;rJ
¢
Mc7/J/h~ s/ocJ:. decluch;;'ns
1 0
¢
¢
/ 0
¢
rtf
IfIvn7,be/, (f).'/ r.p('i'-~e~s r:'0/d
¢'
¢
~eq"e........a/ exe'n-1p,t/e,~5
'1;0 /7
0
%0
R ~ 1;0
YTO
/
I
NX'M.Pr I /
NXM'pS .r I
c:;JRTD R
5"
()
integer, R
17
X><>()(· )()
~)()C")(.JClc
= real,
¢.(II¢
~~(1f
~n70~rt:?/ ~ee~s e/71/.:;/pye'/
Sid/e exe/i1p-;'-/c/.,JsC;f./t?r~er-fo-dt1l'e /n~r/7?Qr/on(/)9rOSS/2)/I7;(.3)rIC4"
(4)Loc.MX rs),e-IC4 wt:1ges ('~)Slck £)1:1"',._
Yed/' - -It) ·dt?J'-~ p?/o~;nqbe:u?(/)g"'t:lS $:/;:') rIC 4, (..3) r10
(4) ,r.rC.4 1AJ4.qes ,(S),sicA:. .00'1. ?~J s~t!'C. A (;1) spec. g~
~)/()C::. -r~)(.;(9) rt2.? hrs.; (/t))
hrs~(fl) JPr7u$" nrs.,
~Z);"e.~. er/1~, (1,3) O'T~rn$.:04 j 6()~41$ e/'/1s.
or
D
= decimal, A = alphabetic
Section
25
Subsections
Page
I
07
40
10
Form X28-7327-4
Printed.in II.S.A.
IB"1
FORTRAN CODING FORM
Page
Punching Instructions
P~'(ROl.t..
Program
Programmer
SYsre""
\='ILE
!Date
CftEATION
r= C FOR COMMENT
I¢I~I/I:;I;I
Punch
t S~A,TEMENT
~
NUMBER .3
I
I ¢Ioll III'Ll I
Graphic
*
IiCard Form 1#
of
Identification
1~8 :f.JI!
I I
'1
I
80
FORTRAN STATEMENT
5 6 7
c.-----
20
15
10
25
30
40
35
45
55
50
:fo 61 .fIIA.M.EI
60
I
c.-- __ _
1- -
fl+IY./J.f
I
70
65
72
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
,f .I,l £
I
I
I
I
I
I
1
I
I
I
(
c. -- - --
I
I
I
c. - - - - -
DAne
Co Plif,D
Co - - - - -
.bAnE
UP,[)dlr T f-.lJ,
c.--_-c----1
c - -- - - ,I,N,P
c.-----
-
-
F IlL. ~
UT
I
S,
I
O,U,T f>. u,
-
Fir, L e s
j,
I
I
I
I
-- --
I
I
I
I
I
I
t. ___ -
*
_....
--
2
I
I
I .
.If,
t
I
I
1.
I
I
2-
1
5
I
I
'Z.
I 'I
I
,3,
I
I
I
I
I
I
I
I
1
/
fl.1J.
I
I
I
I
I
I
I
J.rI.1--t
I
,
I
I
I
I
/
1:,/01'1>1 X, 3,
1.01
I
I
avallable for punchmg source statements from thlS form.
I
,5,d
1.-:-fI)
I
15
I
.3
I
A standard card form, mM electro 888157,
1/ 31
I
I
:2,~tJ
I
I
I
.'1.#.
I
I
/
[32.A
./
I
/
Form X28-7327-4
Printed in U.S.A.
IB"1
FORTRAN CODING FORM
PAV'~LL..
Programmer
FILKO
SVS1'EM
!Date
C(l..EATION
*
I¢ lol/lxl%:! I
14> I~ I I 19Z-1 q I I I
IiCard Form 1#
Graphic
Punch
of
Page
Punching Instructions
Program
I
L
I
.I,tJ.
--
~.
I
I
t-....
I
1--
c..----~
I
I
I
J
t -- -- ~-
1--
I
c.-----
I
Identification
IK.13~I~1
I
80
~ C FOR C~MMENT
STATEMENT
NUMBER
1
5
c
.3
FORTRAN STATEMENT
6 7
". . ----1-
I
t-,- - _ - C-- - - -
20
15
10
I
I
I
-
.....
c.---- ------...
-
-I
-
-
1-
-
-I
-
25
30
III
,z. f( I»'~ ,4,
J "I,
Irlf>lx.tJ'
J ,~
I I'Ib ,x ,
-
-
1-
-I
40
35
--
I
45
I O.'h
I
55
50
I
I
60
I
.S(J
lOs-,
/
150
J6
I
3.0
'I
- - - - - - - - - - - -
-
70
65
72
3~o
I
1.3~O
I
13 it
-
-
- -
c)
-
- .-
Section
25
IB,.,
08
10
Form X28-7327-4
Printed in U.S.A.
Date
Page
Card Form #
Grophic
Programmer
of
Identification
IPA'lJ¢t
PunCh
73
I
I
80
C~MMENT
"S~A.TEMENT C
.3
5 6 7
FORTRAN STATEMENT
15
10
20
25
30
35
40
c - - - ------
AL.l 0
c-----
c..-----
>I<
I
40
Punching Instructions
NUMBER
Page
FORTRAN CODING FORM
Program
r= c FOR
Subsections
A standard card form,
mM
electro 888157, is available for Pllnching source statements from this form.
45
50
55
60
65
70
72
Section
Subsections
I
40
25
Page
09
10
Form X28-7327-4
Printed in U.S.A.
IB"1
FORTRAN CODING FORM
Page
Punching Instructions
Program
Programmer
Dote
of
Identification
Cord Form #
Graphic
leA Yr.I
Punch
73
I
80
~ C FOR COMMENT
,
STATEMENT
NUMBER
i
.3
FORTRAN STATEMENT
5 6 7
15
10
c,-----
I
c- ____
:r
20
I
N 1: T IA
L..~'
25
I
~
t
30
I
~.s
VAtR.rASI.
~----CK.M.AI'X :;Z . .s-.;I(j.d.•
,
Ie =
L.I=
I
0:. /II 1:
Tl '"
0.
J:
I
P
b
"'I
as
I
.bIA. .1:.: 11\ 1.3
Z.\
I
I
I
I
I
I
I
1
.1
1
I
I
I
I
1
I
J
.1
J
I
L
1
I
I
I
I
I
I
I
I
I
I
1
.1
,
1
I
I
I
,
I
1
-'
I
I
I
I
I
I
L,.2..p.
,
5':) : (:>I.:z. s
I
,
J:T.O.TI <.2..):
.TI (
I
1
.L
:J:. \" 0
72
I
I.L I I
:.'-1.2.0.
70
65
I
::I. TO.T ( I. \ :
J:TO'I(3)
-*
=,0-
60
55
50
,
J
,
I S \J. PIP. <.
45
,
N 1 '"I I
'1).0.
40
,
I
I
co
I
.b.B
II
35
-'
,
I
1.
.1
I
I
I
I
1
I
'-
I
,
I
I
I
I
I
I
I
I
I
I T.6Til. b.) ="1 2 '
I
I
I
I
I
I
IT.o:rd7) : 101:2...7
I
I
I
I
1
1
:t T.Q.TI ('E.) .. bl~ g.
1
,
I
I
I
I
~T.O:Td.Cf) :01
1
I
I
I
I
I
I
I
I
I
I
I
I
1.
I
I
1.
.L
.L
IITo./IC/./) ~lb35.
I
I
I
I
LYR. HIR.=.~
I
I
I
I
I
.
A standard card form, mM electro 888157, is available for punching source statements from this form.
,
I
I
I
I
I
I
,
I
I
Section
Subsections
Page
I
10
25
40
Form X2B-7327_4
IBM
Printed in U.S.A.
FORTRAN CODING FORM
PAYRoLl..
$Y.sT&:A/I·
Flui
C~EATION
Programmer
I epic II
III~I
1¢1~l/lrl;1
Graphic
IDate
Punch
of
Poge
Punching Instructions
Program
r==
10
I
IICard Form fI
I
II
*
Identification
17~ti:':fJ~ 1
80
65
70
I
C FOR COMMENT
,.STATEMENT ~
NUMBER .3
5
I
FORTRAN STATEMENT
6 7
10
15
INA J)WU:~
20
25
30
55
50
I
I
I
=6
I
I
I
I
IN.CU .1> I D." .tj.
I
I
I
l
I
L
:.d.
,
I
I
I
1
I
1
1
H.WIe.PIll.: .th.
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
CIK
I
!N.M:J.SIc.:m
I'IWk.MP
4>. R.T. hi l.~.'l
-=.0. •
(i)J:~.T ~d'.)
::..01.
1),0
.M.::-
,'Iq.
J I ., J ,J/.
YTb(IM\ =~.,
---
----'--
-
I
I
I
I
I
I
I
I
I
I
I
I
I
I
-
-
_1-
- - - -
I
I
,
I
I
I
I
I
I
I
I
I
-
-
- -
-
-
I
L
I
- -
- -
-
-
- -
-
- - -
-
Form X2B-7327-4
Printed in U.S.A.
FORTRAN CODING FORM
PAYRoLL
FILE:
1q,lol/lrl~1
~ I J I ",I.l~ I
Graphic
SYSTE.N1
IDote
CK..CATION
Punch
I¢I
I
I
of
Page
Punching Instructions
Programmer
I
I
IB,.,
Program
I
I
-I
72
I
I
I
- - ,- -
-I
60
I
NS'Tklb-::~
c..~--
45
I
IH.C.JJ
lit
40
35
*
IICard Form fI
Identification
IE~:rI~1
I
80
73
II
~ C FOR C~MMENT
STATEMENT
NUMBER
I
c
.3
FORTRAN STATEMENT
5 6 7
c-- - -,-
C-----
20
15
10
I
I
,-..(VMB~R1 ..
c- ----
/l/.o.P.L.J
R£At>,(' ,if. ) I I
R £;:
......
40
35
I
I
W~E'I~
111. IlMI g
45
I
~
ti. ,
IA- ' " /'}.
55
50
I
I
I
C H ECkLNVI1.B
A-~(, .... ,s.} I
I
I
F () .R. .~A
S
r-D.R .MIA.. ( I 2. )
-
-I
-
I JI
-
72
I
t:lte
I
,
I
I
I
1
I
I
I
Ie.liclk
.1./--
r (
T
\,J.E l71k.
70
65
60
I
R ~ A.CI( 6 .... ./f,} 1
,,-----
30
I
I
PLIAN-r
R tAlb
25
I
,
1
I
I
I
,
1
)
1-
1
-
-I
- -
1-
-
-I
-
-
1-
-
- -
- - -
-I
--
1-
-
----
.-r -
-
1-
-
-I
-
-~
Section
Subsections
25
I
40
Page
11
10
IBM
Form X28-7327-4
Printed in U.
I -r o-n ( I
I
,dd::
J 7 '2..3.
I
(i.,o
,,(j)
-1'"10
I
I
I
I
I
I
I
1
1
1
I
:,rbl
I
I
1
1
I
I
1
1
1
I
L ST.:1s'0,
,S".if
(;.0
ss
5.7,
,TIO
S T, ~I 1,S':dJ.
L
L,T,Q,TI (,4,)
s cO
=13~,
I
* A standard card form, IBM electro 888157,
L ST
IS
1
1
1
I
I
1
1
I
1
1
I
1
1
I
I
1
I
1
1
1
1
I
1
1
1
1
1
1
1
1
I
1
1
1
1
1
1
I
1
I
1
available for punchmg source statements from
IBM
I
I
form.
thiS
Form X28-7327-4
Printed in U.S.A.
FORTRAN CODING FORM
-Page
Punching Instructions
Progrom
PAYROLL
Progrommer
Graphic
SVSTE/JI1
I Dote
CREA TID'"
FIl-E
Punch
14>1 olllIl~l
I
IICord Form #
J
I
II
I
¢ I~
I
II; I
~
I
*
af
Identificotion
'hfJ \t::::I'~ I
-1
80
,--- C FOR COMMENT
~STATEMENT
NUMBER
I
....
5
.:
FORTRAN STATEMENT
~
6
7
15
10
S,7
IrOrl(i/--)
,s-.9
ITOTd/(j)
e,----- -
-I
1
-
20
= 1~l
Punch
I ; I " I
of
Pag,e
Punching Instructions
Program
*
"Cord Form #
Identification
12a:1I(~l
J
/
60
73
II
~ C FOR COMMENT
STATEMENT c
NUMBER ~
5
I
FORTRAN STATEMENT
6
-- -
c--
15
10
7
I
c.-----
I
1
"0
.N.A fIl,E
IF
I
i),
0 I, ALL,
c,- - -- -
I
R.~ ~,D' ( ~
,S,O 0
-
I
/
tI U'" ~1
I
I
I
I'll
,- -
.-
-
-1
1)(1
I
I.S
I
,
,
,T,W:t S
11
Identification
IP8:r1~
73
I
G-OI
.T~O~
" 1If, fI,
-
(;01
To
J
!
II' F
-
( kl- q)
-,
,
-
l,tiJ
I
1
-
I
/
60
,«.
,
'drj,
1.tIL
- ,- - ,-, -
.-
1
I
I
,
1
,
L
~
F'Z •
c.
/5,
fl
,IJ
-I
"
-
1-
~
1
1
I
___ .J.
-I
-
-
-
1-
LIAST~R.b
(!
"I
.Ml A-f<.
I
------L
I
YT D,
1
\'iT,b. ( 3 )
(12. )
'"
/
.;
.J
i::J
I3
..
III.
~
I2.
'IX
,J
I
I
I
I-
,
I
"
I
I
- -
1-
I
,
.J
I
-I
I
I
,
,
-
,
I
/
.L........~.
-
72
1
L
-
EO
r:~.-4 ~ IS' -; J.II.'f,
1.
1
I
__ L~~~
N UAI, ....ti...~I,h'LS.
J.
-
CI/1 E
M f!lLy-~b (, I )
1
1
70
65
60
55
~~~~~L-_~
,
1-
tlx
-'----'---~--~ ..
t
...L
)1
t.
-----1-. __ .•_.
I
C A R.D.?
T
50
__. __ _.. J_ .~ .. ~_._ L __ ..• _u._.~.l_..__ ~_~~ .. L~_ ..___ u I
it/IriS , ~C;:I ~
,
I
lrA S
-
,
~i.~~_~~
N~~7--AS SA ";)1
Mt.U)
1
H.i
45
N~ M P LI o~£J.Al)
I
,
I
__
I
SL
I
I
I)
o
:.)~ ,I.3) I 2.,) I f ) IIX) II...
Y f;
C - - - -!-
c--- - -[
r
.:II
~
/
/
No
I
I
of
Page
*
IiCard Farm #
I
I
40
35
F,o,l(,
'" R,A .7'115 ..
,'(,TtJJ 2)
(1)(1.1 ~-lf)
I
Ie. - - ~ -I-!
/
/
~
I
30
Z (I/,t:.o,Il"'l" T 1",0 N
I
I
iF'.O,It,MIA.i
.t..c_----c--_--
25
... } I
,
II
2
20
,
I
C,- - - - -
"
-
-
~-
FORTRAN STATEMENT
i
6 17
i
..
~~-
"
I
I~
-
-
Instructions
,-_. C FOR COMMENT
-
,
,
L4doll II Lzl
cp t I
~
Graphic
5YST6#1
F;1.6
~STA1[MENTI~
c--
I
1
FORTRAN CODING FORM
Programmer
5
I
__ .L.....-
,
-
___~_~~~._.L~
Form X28-7327-4
Printed in U.S.A.
EAY~oLL
NUMBER
L~
,
Punching
I
.. ~ ___
72
,J.
IBM
Program
_~
70
65
,V~
IC.Oi\1 Pft I NY
'-1:1_ C
-
-
1-
60
55
,
I
-
-
50
-------l~~~~L~_._.~~_.
/
,
- - - - -
,
/
~
.Pt./J, D
45
I
,
FOR MIA -1.1.AI2..,.1
F\EA.J),(b,~
40
35
,
ElL. ~
NA M E
REAbIC" .. 3)
3
F I
,
1
30
,
I
Tr\,~
S E'."U P
e-----
25
20
-
-I
- - ,- -
-...L
-
Section
25
Subsections
Page
I
13
40
10
Form X28-7327-4
IB,.,
Printed in U.S.A.
FORTRAN CODING FORM
Poge
Punching Instructions
Progrom
PAYRoLL
Progrommer
SYS'TEM
C~EAT£o'"
r:-rLE
11L l j ::
60
55
50
,
.1
i:.x.EMrP.T'":I.o.MS ,
I
,
Mp. Fe
Q.R..T.b,t
13. rA'r£
~
,
-'
tV X.M PIS ::.JJ.~.
,
I
C (') b.E.•
S TAIT lJ ~
I
N'S.T.AlS.. - ,
I
45
40
35
30
i
1
,
C-----
25
,
.4)/1])
I
Q.R..T.t>tl.'f ')
---- -.....
1
:.'1'11.1)
-
1-
C8 ),
':-
- - -
1
I
1
,
1
1
I
I
1
I
I
I
I
I
I
-'
I
Q.R.T.!'J (3.~ :,.Y,T.b.l 2..)
t----- - ...., -
I til F O.~./t1. AIT.AI
I
-'
1
I
1-
,
1
- -
- -
- -
-'-
I
-I
,
I
-ll
Q-T
I
72
70
65
-
-
1-
.--r -
1
I
I
-
1
-
1-
-
-I
-
-
-
-
-----1-
-I
Section
Subsections
Page
I
14
25
40
Form X28-7327-4
Printed in U.S.A.
IBM
FORTRAN CODING FORM
Page
Punching Instructions
Program
10
Sy STEM
-!--'f,YkOL L
Programmer
r!:t-~
CP.Ff>.:T
1¢loll II I~I I I
I¢ I ~II I'fl~ I I I
Graphic
jDate
JoN
Punch
*
Cord Form '#
of
Identification
1.fi.8~lq.
I
80
~ C FOR COMMENT
STATEMENT ~
NUMBER
-3
FORTRAN STATEMENT
5 6 7
1
10
t:".-- ---
I
C---- -
l::
c.- -- - -
III ~
;0' I
1:)
I
r
T-
1.r/J.3
MA Plr
C G S <:
rA~.
-r
f: CI"1IAR.)
F( MIA.~ - l )
,
hI U~
I .0./ .. I. 0. ~
,
,
L
I
S
h E.P () ,C,TLIO.N.,
,
I
LS Ex
c...
0
1
1l. G;
,
iIJ.,~
L~(.,
I F.CII,O.P.L,T.- 3.)
/ /.s
N.b.U,tIS.=.m.
,
/20
J. r;(/I/i.S£X)
,JdJ.9.
I
IA N . b r i t :
I
72
I
J
~
_1
I
I
J
1
,
I
,
1
1
I
I
I
I
1
I
,
I
70
65
J
,
I
I
,
I
I
I
I
I
I
I
,
,
u/J,3 , I/.tlJlI.. 110.'
UES )
tI DUElS =.~
,
,
I
A,Ci/:::.,
/,dJ.I/
I
I
,
I
."l.AS.::..=?
I .2.. IdJ,...
,
, I. lSi., I. 2...D.
,
I
II(/)
9
fA
IrJ,7
,
,
,
,
I.d.t
I F. (11,5 ~ X - 3, ),
,
I
/,dJ.g
N.<"TA,S.,;.Z-
I
,
,
,
I
t.f.s E,X, =t.
,
,
,
1
I
I
I
I
,
,
,
,
,
,
,
.dJ9
c..o .D~~l
60
55
50
,
I
S 1T A 1'. VS,
J.(/) 2.,. I. dJ. 2 .. J Id;, I
,
s.r
ENf,L. DIY EE
~y
,
116. I
t111.k ~ JI
II rIAlI b
r
I
r
c..f)
*
,U rJlI~/II
45
40
35
I
,S, i"A,U-5
M OIl>
C.A L LIS. rAC IK..
j
30
I
I
AIQ'/.
,
C.A L L I
,ldY.2-
25
20
/
C----lof,(f)
15
,
I J.fh
Tin
/II.:SEX,:: 2.
CA,L.i-l
,
STAc,Jc
I I.d>. ..., I,i.'~, ,l,/.a. 9
I
I
,
I
,
,
I
A standard card form, IBM electro 888157, is available for punching source statements from this form.
,
,
,
,
I
,
,
,
I
I
.
1.
,
,
,
I
,
I
L
1
,
,
I
I
I
,
,
,
I
,
,
,
,
,
,
,
I
I
I
I
,
,
,
I
Section
25
Subsections
Page
I
15
40
10
IBM
Form
Punching Instructions
Program
~fFA":::'J,.J
\=.,.\..~
r== C FOR COMMENT
... STATEMENT
NUMBER
I
:s '{:: . . . ; . fl,
-PAV(Jo~.
Programmer
IDate
i
.3
Graphic
[a>[O[I[r[i:[
Punch
I?I
~
t I'~I~
I
I
15
10
c- - -- - -
-I
-
-
20
1-
-
25
-I
-
-
35
30
1-
-
-1
-
-
40
1-
-
IiCord Form #
I
II
I
1
1
1
45
-I
-
-
,
r ___ -_
1
Identification
il~6'~'I~
1-
-
60
55
l
1
eo
L- - - - -
I
WR..I
TIE
1
(,N.o
I
1
,
,
~
~
1
2..
1
3
1
-- -
,
,
1
~
1
c-_ -_.:..
1
1
,
1
,
,MJIr.f<...'"
I
1
1
1
-
-I
-
-
1-
-
,-I
-
,NIX,,,,,PF,AI
..
L YR HI<.
,N.C,v,
NIM.r.s.c..
.N,VA..
1-
-
s AM
"
~
,-,
.N..J,T,/<.U"'l.
,
.I
IIISIE
x..
.N.C.,H,Ck.
rS,UPP
,
J
.,
1
1
-
-
I-
I
-
,-1
-
-
1-
-
I
.,
..
~
IP,}), ,
"
..,
,1lI,t/S.1
,
,tJ,S "'rIC/:..,
,
1
I
'l.T.1>~, ,G).~.T,T")
..
,NAD,v/.JI..,
I./V,.r.r,
I
,
,NIR.,A,T,E,
J
L
NW~.MPIlWtK.,p,il
~
NX,M,PIS
IrIC.V/) D.
,.
I
Als 1"IASNI b VF.s.
~
1
I
-
NS
1
1
I
'
I
1
I
I
1'1£..1. ' r~()L }NtUMMAMf2
72
-I
,
1
70
65
I
,
*
*
73
50
c---_-
c-- - - -
of
Poge
[
FORTRAN STATEMENT
5 6 7
Co - -
X28-7327-4
Printed in U.S.A.
FORTRAN CODING FORM
1
I
' I
1
1
1
t
1
,
1
1
I
1
I
,
,
1
1
-'1
-
-
1-
-
-I
-
-
~-
-
-
I
1
1
1
,
,
,
1
1
,
1
I
~
I
1
1
1
1
1
1
I
1
1
1
I
_I
I
A standard card form, IBM electro 888157, is available for punching source statements from this form.
-
Section
25
IBM
Page
I
16
40
10
Form X28-7327-4
Printed in U.S.A.
FORTRAN CODING FORM
SYS'T€"M
PAYROl.l...
Programmer
F:J:t..~
IDate
CI2.EA'T:r:ON
ITI~I
1d>lo I I
Graphic
Punch
/
¢ I ~ I I 1;-1 ~ 1
I
*
IICard Form #
1
Identification
1~~~I(jl
I
80
73
II
I
of
Page
Punching Instructions
Program
Subsections
~ C FOR COMMENT
c
STATEMENT
NUMBER
I
FORTRAN STATEMENT
j
5
6
7
c.-----
I
c- ____
I
LA.s T
1'-----
I
I
T'" ~I
I
,t..btJI Ib,c>, ,'15~.
25
PAs
<:. A-Je,.f.)
rNIrrI+L'rJ"lE.
c,-----
/:,sdJ
20
15
10
E:
I
I
SEEM
~ E~.1l
r fl
A-Il>f:
1
,I~II.
J
I
I
.~.
I
J
I
I
() ,,;
-
- -
'1
I
Ii'"
-
'-,,-
I
70
65
I
I
-rr
/II
(J
.. - - - - - - -
- -
-
I
I
-
I
_I
I
I
I
I
-
-
t-
I
I
-
- - - - -
-
r-
--
- - -
..I
t"orm X28-7327-4
Printed in U.S.A.
IBM
FORTRAN CODING FORM
Page
Punching Instructions
Program
72
I
I
- -
60
I
F 0 I?I#l A
~
IF.I6 RolE: (r. ),:laS
C---_-
55
50
I
ASI..$ (lCl/1"rl
I
45
40
35
30
SYSTEM
PAYROLl..
Programmer
~'Tl.~
Graphic
IDate
C R.E:A'T' ro I\i
I
cbl 0
I
I
II I
i:
I
1
J¢I~IJI/~I~1
Punch
I
*
II Card Form #
IS of
I~
Identification
17~&rl~1
II
I
80
~ C FOR COMMENT
STATEMENT
NUMBER
1
5
c
FORTRAN STATEMENT
j
6
7
15
10
!c.-----
I
Lc- - - - -
20
I
W,f{.r:.I'I.I!:.
25
I
30
I
I
7"Jhf. :r.(I/)iE.x. .O.n
40
35
I
EM P L In.Y.LE:cSI
I
~l).R.
T Uy{'
L.A.:;. TI
::
c----..........
-
-I
-
I.C O. Lt
IN R I. TI E ( l:
-
N
-
hi
I
1-
I
I.)
I
{I
- -
I
I
IN bEXI (1: ) ., L:; I •. L..A-IS. T.
- -
.J
-
-- --
1-
55
50
I
I
I
PLANT,
I
60
I
I
I
~
I
I
.1
)
-
70
65
I
..b,I S 1<. •
TO
,
i
t.,- - - - -
----
45
I
I
-
-
- -
-I
-
-
to-
- ,...
- -
- - -
72
I
Section
Subsections
I
40
25
Page
10
17
IBM
Form X28-7327-4
Printed in U.S.A.
FORTRAN CODING FORM
Page
Punching Instructions
Program
Programmer
rs;,
5
I
c
.3
1<1>lol,III1:1
Punch
I¢I~I Jlqz-I~I
*
IICard Form #
I
IE
I
of
Identification
73
II
8 rl~l
I
80
FORTRAN STATEMENT
6 7
10
C----c- - - --
- --
I
'rJ.fJ...TlrE
I.N.
20
15
I
Ic.- - - --
IT
'Ho
I
WRr..Tir;. (rAl hi'
-----
C.A.L
LI
~x I.
-
-I
-
£r/./).
I
7i
-
I
·rcd-l.CJ(.
'"
45
I
AMh
50
I
f'L,ANT7io
I
Co 0 .M,P
I
I
,
,
I I .W.~. E.~,
,
,.
l>..I 51 k. ,
-- -- - I
-
I
I
III11MIRER
Ol~
I
,
.t=.I.! ,~.t;.
,
.I,ro.7". ,
"
,
1-
,
- - I
-.
,
- -
I
72
I
EflI PIL o. YE.hs
I
I
C..k:.M.AX,
,
I
I
,
,
.-1
70
65
.1
I
I
I
rU,e
60
STl>, P
I
I
55
I
L.A-STi
- - - I
U,r..s.
INJ:d:X
I
.r,)
,
L 's.'T':),
TillE;
T
40
35
I
~ID ~
,
-
C-- __ -
lTD
I
'I"'{J.P.£.
30
I
A£c..ORb
.PILANT
t----c.- - -
25
I
.TI'flE.
WR...7..nE (,1. ~
I
jDate
C~EAr.IoN
FILE
Graphic
C FOR C~MMENT
STA TEMENT
NUMBER
(..-
SYSTEM
PAYROl-L
-
I
I
,
I
~-
-
,---
.-
,
-
-
Section
25
Example 2: Add Name to the File
This program is an extension of PAY01, File Creation. Because the employee record contains more
than 80 characters, one card is not sufficient. The
name field for each employee appears on a second
card which is processed by this program.
The dummy name field, set up in the disk record
by PAY 01, is filled in with the actual name on the
card.
The program illustrates a simple single-file update with no calculations. The following programming techniques have been used (see Section 35 for
a listing of this program):
1. Updating masters. The master file is updated
by changin~ the name field in the master record.
Note that only the variable name in the output list
has been changed.
Subsections
Page
I
01
40
20
2. Searching an Index. The index to the file
contains an entry for each employee. The clock
number is placed in the index at a location corresponding to the record number for the employee.
Each index entry is exam ined to find a match with
the clock number on the card (statements 120-125).
When a match is found, the location of the match in
the index is the employee record number in the disk
file.
3. Indicating exceptional conditions. When the
index is searched, it is possible that the clock
number on the card will not match any index entry.
If this occurs, the clock number is printed in the
following message:
CLOCK NO XXXX NOT IN FILE.
Section
25
Subsections
40
I
30
Page
01
Example 3: Changes to the File
This program illustrates a complex single-file update procedure. Anyone of 16 different changes can
be performed.
The master file is the file created by PAY01 and
PAY02. The transaction file is on cards, where
each card contains the clock number, a code indicating where the change should be applied, and the
new or changed information.
The one important change this program will not
perform is deletions from the file. However, this
may be accomplished by changing the pay rate to
zero.
The following programming techniques should be
noted in this program (see Section 35 for a listing
of this program):
1. Setting a switch rather than testing. The
change code is a two-digit number form 01 to 16
(statements 105+1 and 106). When it has been validated, proven greater than -zero and less than 16,
the code is used as the index for a computed GO TO
statement (statement 140). This saves the program
a set of IF statements, each statement testing the
code and deciding on an action.
2. Detailed data validation. Since PAY01 and
PAY02 were so careful about building the file and
making sure the data was correct, common sense
indicates that the same care should be extended to
any changes to it. This is done through checks,
not only on the change code, but on the plant number,
the clock number, and, where applicable, the
change itself. Note that the addition to the file of a
new employee causes a check to see whether that
employee clock number is already in the index.
3. Use of the alternate stacker. Any time an
error is detected, the card involved in the error is
selected to the alternate stacker of the IBM 1442
(statements 3 + 1, 8 + 1, 5 + 1, and 7 + 1). This
will save the operator the task of picking out those
cards with errors.
Section
25
Example 4: Calculations and Payroll Register
This program cons ists of extens ive calculations and
report writing. Payroll calculations are performed,
including calculations of gross pay, taxes, voluntary
deductions, and net pay. The report shown is the
payroll register.
In addition, the calculations are balanced to control totals and each disk record is extended with the
current period's calculations.
The following programming techniques have been
used (see Section 35 for progTam listing):
1. Arithmetic Statement Function. Since the
1130 is a binary computer, decimal fractions may
not be expressed exactly in binary. This inaccuracy
may be avoided by performing all calculations with
whole numbers. (See Section. 70.10.20.) When
calculations are complete, the result must be halfadjusted and the decimal point placed. Since there
are many calculations in this program, it makes
sense that the rounding procedure should be set up
only once and accessed from many different places.
The Arithmetic Statement Function, PHIL, will be
used to do this.
2. Use of data switches. Since the check number,
week number, and maximum check amount are not
permanent, a facility must be built into the system
to change them. By setting the console data switches
appropriately (statements 3 + 5 and 71), each or all
of these numbers can be changed. A hard-copy
record of any changes is produced on the console
printer.
3. Zero balance test. The control totals are
compared with accumulations produced during the
Subsections
Page
I
01
40
40
processing of the file. The original control totals,
the accumulated totals, and the differences are
printed. If the differences are not zero, the operator knows that further examination of the output is
necessary. (See statements 15-18.)
4. A variety of calculations. The calculations
performed with this program are more extensive
than the other sample programs. The first set of
calculations is used to initialize the program variables, while the second set initializes the plant
variables. The third set initializes the variables
for an individual.
The remaining detail calculations pertain to
regular, overtime, and bonus earnings, taxes (including federal, state, and local), and voluntary
deductions. Finally, the net amount is calculated
and plant totals are accumulated.
5. Backup is built into the system. To provide
a means of recovery when an error condition or an
out-of-balance condition occurs, the calculated
information (gross, net, tax, etc.) is punched into
the employee's weekly card (see statement 9). A
simple list of these cards will thus supply sufficient
information to check or reconstruct portions of the
file.
6. Another type of half-adjusting. In printing
the payroll register the dollar and cents figures
should appear with decimal points. To round off,
reposition the decimal point, and clear fractions,
the WHOLE Function (from the Commercial
Subroutine Package) is used (see statements 515515 + 11).
AMT = WHOLE (AMT + (AMT/ABS(AMT»*0. 5)/100.
Section
25
Subsections
Page
I
01
40
50
Example 5: Check Writing
This program demonstrates the use of the Commercial Subroutine Package (CSP) in preparing a
report--namely, the check and check stub.
In this example, the employee file is accessed
sequentially. If the paid indicator is set appropriately, a check is written. In either case, the next
employee record is read.
Control totals are carried, and a zero-balance
check is performed.
The following programming techniques should be
noted in this program (see Section 35):
1. The use of subroutines. There are three
specific operations which are used many times (see
statements 91 + 9 - 95 + 5). These are PUT, MOV E,
and EDIT. PUT converts from real format to Al
format, MOVE moves information, and EDIT inserts
and removes characters. Rather than repeating the
statements that perform these three operations each
time, it is much simpler and shorter to make subroutines out of the statements. This, in addition to
saving core storage, is much easier to test and
document. All three subroutines are supplied with
the 1130 Commercial Subroutine Package.
2. Editing data for output. The use of the EDIT
subroutine is a very powerful technique. It requires
two kinds of data. The first is the data to be edited,
and the second is a description of the result, the edit
mask. As can be seen, the edit mask is treated as
a constant and is initialized at the beginning of the
program (see statement 4). The result of editing
can be seen in the amount field of the check speciman
shown.
Section
25
Example 6: Check Register
This program illustrates a report in which detailed
items are written, three up, (three items per line).
A plant file is accessed for each employee (see
statement 655), and a line containing check number,
employee clock number, employee name, and net
Subsections
40
I
60
Page
01
check amount is composed. When three employees
have been placed on one line, the line is printed.
This technique will produce a very concise report,
easily read, filed, and used. The technique also
decreases printer time to produce the report by
decreasing the number of lines to be printed.
Section
25
Subsections
Page
I
01
40
70
Example 7: 941 Report
This program will process multiple files to produce
the 941 report. One report is produced for each
plant.
Note that a count of the lines printed on each page
is kept (see statements 195 + 5 and 150). In this
way, headings can be and are printed at the top of
each page in the report.
Also, notice that the plant totals are reset only
when a new plant is to be processed (see statements
2 + 1 thru 3 - 2), while page totals are reset when
a new page is to be printed (see statements 4 + 4,
4 + 5).
Section
30
Subsections
Page
J
01
00
00
Section 30: TESTING EFFECTIVELY
CONTENTS
Introduction .•......................... 3 O. 01. 00
Testing Strategy ........•.............. 30.10. 00
Testing Tactics ........................ 30.20.00
Testing Hints •......................... 30.30.00
Summary ...•......................... 30.40.00
Section
30
INTRODUCTION
Now that programming is "finished", it is time to
evaluate what you have in relation to your objectives.
Do your programs and systems produce the results
you want? To find this out you must test the programs -- but not until you have a plan.
Experience has shown that more time can be
wasted in testing than has originally been allotted
to testing.
In other words, testing must be performed effectively.
* * * * *
There is a great temptation to get a newly written program on a machine and see it run. A little
extra effort before going to the machine can save a
great deal of time and effort in the long run. If you
must travel some distance to test a program before
the installation of your own machine, it also means
real money saving.
The chances are very good (99.99%) that your
program contains errors of various types:
1. Programmer clerical errors. It is easy to
make minor clerical errors when filling out the
coding sheets. Although they are minor, the program will not work properly until they are corrected.
2. Programmer procedural errors. The number
of procedural errors will depend on the experience
and proficiency of the programmer. These are
caused by not adhering to the programming rules as
outlined in the language manuals.
3. Card punch errors. Errors may be introduced when the program is punched into cards.
Punching programs into cards is very exacting, and
the keypunch operator must be very careful. Because of the nature of the information on the program sheets, it is difficult to achieve speed and
accuracy in punching.
4. Program logic errors. Logic errors may be
caused by poor or incomplete analysis of the problem
prior to programming, or by incorrect programming
after correct analysis. In any event the program
must be able to either process, or properly reject,
all the various pieces of information that will be
given. Someone who is intimately familiar with the
procedure, as it is now being done, should review
the logic of the program for completeness.
Subsections
Page
I
01
01
00
Most clerical errors, both programming and
card punching, can be detected by a careful review
of the material. Key verification should always be
done, and it is essential to proofread coding sheets
before they are punched. The most common errors
occur in the use of 0 and 0, 1 and I, 2 and Z.
Standards should be adopted in which, for instance,
alphabetic is written 0, zero is 0, Z as..g, I as a
printed capital (I), and 1 as a straight line (I). It
is wise to formally familiarize your keypunch operators with the adopted conventions.
°
Program procedural errors can often be detected
by having someone other than the original programmer review the programming sheets. Even
where the programmers are relatively inexperienced,
they will often catch errors in syntax (grammar of
forming statements). This review can also serve as
an excellent way to improve programmer knowledge.
During a review of the program, program logic
errors are more difficult to catch. This is particularly true when the person who is familiar with the
procedure is not also familiar with programming.
Logic errors are generally caught during testing
when sample data is processed by the program. The
sample data must be prepared so that all of the various exceptions, combinations, and ranges of information are introduced to the program, insofar as
it is practical to do so. It should be remembered
that any element or combination of elements that is
not tested is very likely to appear eventually; if it
can happen, it will.
At the time that your program is assembled or
compiled on the system you are installing, a series
of diagnostic tests is also made to detect many of
the potential errors, and these errors are noted.
By properly prechecking your programs, you can
materially reduce the amount of time to get a program compiled and tested successfully. Care in
the preparation of test data will also detect logic
errors so that they can be corrected before the processing of actual data.
The final test of any program is the successful
processing of "live" data, after which the results
can be compared against those obtained by the previous system.
Note: If the results of this last test do not agree
with previous results, check again to be sure what
the right answers should be. Sometimes the old
system has not produced the correct solutions.
Section
30
Subsections
10
I
00
Page
01
TESTING STRATEGY
Any good system is like a successful athletic team.
Each member must do his job well, and all members
must work together. These two things are what
you must accomplish with your testing strategy.
Each individual program is tested. When all programs give correct results, pairs are tested. When
the first pair gives correct results, another run is
added to the system. Finally, all runs are tested
together, and the entire system is checked out.
The individual tests are the foundation of the
system's test. A deck of test cards should be made
up for each program (or subprogram) and kept for
use in testing the program again in the future.
The ideal rule to follow in deciding what test data
to include is this: include every field at least once
under every condition in which it can occur, not
only by itself, but with every possible combination
of conditions in which all the other fields can occur.
With a simple program this is easy enough to do,
but where many fields appear under many conditions,
the number of possible combinations can become
enormous. Then your programmer must use his
judgment in making up a limited set of test cards
that covers the possibilities adaquately.
The test cards should be created, then listed.
For each set of test data, a "prediction" of the results that will appear on the output forms or cards
should be made. Then, when actual testing is performed, your programmer cannot be easily misled
into believing that his output is correct when it is
not.
The first data in the test deck should test only the
ordinary, easiest, most straightforward conditions.
Next, multiple conditions can be combined on one
card or record. Finally, error conditions can be
tried. The reason for this careful progression is
that unless the simple situations are proved first, it
is possible to spend many hours trying to determine
which of several possible causes for a "bug" is the
true one.
Avoid setting up your tests in such a way that you
count on the output of one program to act as input to
another. Have at least one independent set of test
data for each program you are testing. "Merged"
or "linked" testing is a valuable means of proving a
system's overall validity, but it should not be done
until each program is individually tested.
After a successful test, both the test input and
output should be retained, as part of program documentation, to make future testing easier. Also,
when testing program modifications, test not only the
modifications but the entire program. In other words,
your sample test data should expand with each modification, so that the entire system may be tested at
any time.
Section
30
TESTING TACTICS
Many techniques exist to assist your programmer
during the checkout phase of a program. Each has
its own advantages and disadvantages. The one to
be used for a particular problem will depend on
your programmer's thoughts as to what area of his
program is in error. Some very useful techniques
are:
1. Core Storage Dump. This is a printout of the
contents of core storage. There are two methods of
producing it.
The first is with one of the utility programs supplied with the 1130 Programming Systems. These
utilities will produce a core storage dump in hexadecimal.
Since manual hexadecimal-to-decimal conversion
is very tedious and time-consuming, this method is
not recommended.
The recommended method of dumping core storage
is with the dynamic DUMP facilities of FORTRAN
and the Assembler Language. The information
dumped with this method can appear in hexadecimal,
integer, or real format.
In FORTRAN, the DUMP facility is accessed
through use of the PDUMP subroutine. You would
write CALL PDUMP (A1, B1, F1, ... , An, Bn, Fn).
Blocks of core storage are dumped. A1 and B1
are variable data names, subscripted or nonsubscripted, indicating the inclusive limits of the first
block of storage to be dumped. Similarly, An and
Bn indicate the inclusive limits of the nth block of
storage to be dumped.
The format of a block is determined by the Fx
associated with that block. F1 through Fn are integers and are assigned in the following manner:
o = Hexadecimal
4 = Integer
5 = Real
The Assembler Language dump facilities, DUMP
and PDMP, are used in a similar fashion.
All of the core storage dump facilities will produce a printout of core storage, by address. You
should use these facilities when a program "bug"
requires, in the judgment of your programmer, an
examination of all or part of core storage.
2. Ari thmetic Trace. The use of this technique
involves subroutines that are executed whenever a
value is assigned to a variable on the left of an equal
sign. If Console Entry Switch 15 is turned on at
execution time, and the *ARITHMETIC TRACE
FORTRAN control record is used, the value of the
assigned variable is printed, as it is calculated, with
one leading asterisk.
Subsections
Page
I
01
20
00
As an optional use, you can elect to trace only
selected parts of the program by placing statements
in the source program to start and stop tracing.
This is done as follows:
CALL TSTOP (to stop tracing)
CALL TSTRT (to start tracing)
Thus, tracing occurs only if:
• The trace control record is compiled with the
source program.
• Console Entry Switch 15 is on (can be turned
off at any time).
• A CALL TSTOP has not been executed, or a
CALL TSTR T has been. executed since the last CALL
TSTOP.
If tracing is requested, an *IOCS control record
must also be present to indicate that either typewriter or printer is needed. If both typewriter and
printer are indicated in the *IOCS record, the printer
is used for tracing.
Use of this facility will increase execution time
considerably. The trace facility should not be present in a production program; if it is, you should
recompile the production program after testing is
complete, leaving out the trace.
3. Transfer Trace. In this case, the FORTRAN
compiler generates linkage to trace routines which
are executed whenever an IF statement or Computed
GO TO statement is encountered. If Console Entry
Switch 15 is turned on at execution time and the
*TRANSFER TRACE FORTRAN control record is
used, the value of the IF expression or the value of
the Computed GO TO index is printed. For the
expression of an IF statement, the traced value is
printed with two leading asterisks. The traced
value for the index of a Computed GO TO statement
is printed with three leading asterisks.
The optional use of trace explained under Arithmetic Trace also applies to Transfer Trace (use of
TSTOP and TSTRT), as does the information following optional use.
4. Extensive Use of PAUSE. It may turn out that
some parts of your program execute correctly and
some incorrectly. What you would like to do is to
check the progress of the program while it is running. A very useful technique is to place PAUSEs
at strategic places throughout your program. In
order to know where the program is at any point in
time, number the PAUSEs consecutively:
C-----READ INPUT
PAUSE 1
CALL READ(IN, 1,80, N)
C-----IDENTIFY INPUT
PAUSE 2
Section
30
Subsections
Page
I
02
20
00
IF(IN(22)-1) 3,4, 5
CALL MOVE (IN, 1, 27, IWK, 1)
C-----TypE ZERO CARD
PAUSE 3
etc.
The PAUSE number will be displayed in the
accumulator. Use of this technique will let you follow the logic of the program (IFs and GO TOs) wi th. out severely slowing its execution.
5. Additional Print Lines. This technique is
sometimes called" selective tracing". Again, rather
than severely slowing the execution of a program and
printing the result of every replacement operation,
3
only selected variables and/or fields will be printed.
Use of the FORTRAN WRITE statement or the 1130
Commercial Subroutine Package PRINT subroutine
will allow you to follow the progress of variables
and/or fields as their contents change during program execution.
6. Console Debugging. This technique should be
used only as a last resort. It involves manual inquiry into the system via the console switches, dials,
and keys. In most cases, the previously mentioned
techniques will provide you with all the information
necessary to debug.
Section
30
TESTING HINTS
1. To test the logic in a program that uses
Commercial Subroutine Package I/O, use standard
FORTRAN READ and WRITE for 1/ O. This makes
the trace facility available. When finished, use
Commercial Subroutines READ and PRINT for
overlapped I/O.
Subsections
Page
I
01
30
00
2. Ask yourself: What must be done to recreate information if the disk cartridge is lost?
How long will it take?
3. Keep testing in mind when planning the
development of various runs. That is, write the
file creation and maintenance programs before the
report programs that use the files.
Section
30
Subsections
Page
I
01
40
00
SUMMARY
If program testing techniques are properly planned,
a minimum amount of machine time is consumed
during program checkout. Manual inquiry into a
system via the console is extremely expensive in
machine and operator cost; little is learned in return for dollars expended. Time spent desk
checking is well invested, since most of the logical
errors may be detected before the program actually
enters the computer testing phase.
In trying to make the maximum number of runs
during a test session, your programmer may be
tempted to make rapid patches without pausing to
annotate such changes thoroughly. Such urgency is
seldom fruitful in the end.
The program testing phase should be carefully
and thoroughly planned, executed, and documented.
The following checklist should be used as a guide to
ensure maximum productivity for program testing.
Mter coding the program and preparing revised
flowcharts and other supporting documentation, the
testing procedure begins.
1. Prepare test data and precalculate results.
2. Punch and verify program cards.
3. List program cards.
4. Desk-check the program. Look for:
a. Errors in logic
b. Endless loops
c. Incorrect use of program switches
d. Unsatisfied or incomplete coding for
the problem definition
e. Inefficient program (time and storage)
f.
Incorrect data field lengths
g. Improperly signed fields
h. A name for each variable
j. Initialization of routines and storage
k. Duplicate names
1. Misspelling and punching errors
m. Invalid operations
n. Necessary control cards
o. Improper alignment of card columns
5. Manually simulate the computer process
using te st data.
6. Compile the program.
7. Perform error analysis with error listing
and program printout.
8.
Correct the program.
a. Card programs. Correct the source
deck and recompile the program. To
facilitate card handling with object
decks, label the object deck with a
marking pen. The first and last card
of the object deck should be so labeled.
The top edge of all such cards may also
be marked.
b. Disk programs. When the program is
prepared on disk, corrections are made
to the source deck. This is accomplished by placing the corrections in the
source deck and then recompiling and
restoring the program. Alter the program listing and update the program
flowchart to reflect source deck
corrections.
9. Prepare detailed instructions for machine
operation during the test session.
10. Pre-test-session familiarization.
a. Console operation
b. Input/output devices
c. IOCS
d. Utility routines such as clear storage
and load programs, file generators,
trace programs, storage and disk print
programs, sort and merge programs,
and check point and restart programs.
11. Test documentation and materials. To reduce confusion, all materials should be clearly
labeled with the name of your organization, program
name, content, and date. Each person should have
a list of items for which he is responsible:
a. Program flowcharts
b. Compiled program listings
Test data dccl(s and disl~s \"lith test duta
listing (a duplicate copy may be
desirable)
d. Precalculated results of test data and
listing of expected output with each test
case
e. Card and disk record layouts
f.
Internal storage map
g. Printer carriage control tape
h. Operator checklist, providing all the
information the operator needs to set
up the data processing system for the
running of each program:
Section
30
(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. Decide upon the sequence in which programs shall be tested. Programs
should take precedence in testing
according to their importance, and the
most important programs should be retested as often as possible until they are
completely debugged. Schedule a workload 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 twohour 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 higherpriority 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.
f.
g.
h.
i.
j.
Subsections
Page
I
02
40
00
Debugging at the console is timeconsuming, 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 causing the original hangup would then be
destroyed.
Label all core storage dumps, disk
dumps, console sheets, etc., with date,
time, and program identification.
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.
Note all corrections on the program
listing. Corrections that affect the halt,
switch, or index listings should be updated accordingly.
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 reference when correcting the source deck.
Section
30
Subsections
40
k.
I
00
Page
03
Generate a new program listing after an
appropriate number of cards have been
added to the program. Update the program flowchart to reflect the current
status of the program.
1. Keep documentation current. This
eliminates the waste of time and effort
trying to pick up changes during testing
or debugging.
13. Post-test evaluation. Every test session
should be followed by a thorough evaluation:
a. Was the pretest preparation adequate?
b. Were there any areas of preparation
that could be improved to yield a more
effective test?
c. Were there areas of preparation in
which you spent too little?
d. Did the test point up any areas of weakness in the coding? If so, are these types
of errors documented so that stronger
emphasis can be placed on them during
future coding and desk checking?
e.
f.
g.
h.
Was each machine session used
effectively?
Are there any corrections to the testing
techniques that would make the next test
mbre fruitful?
What is the status of each program
tested?
(1) Is it completely tested? That is,
has every program loop been
tested, and do you have any reservations about calling this program
complete?
(2) Is it tested to the stage where the
only changes left are in spacing and
editing of the output data?
(3) Are there logic errors left in this
program?
Did the test session achieve its objectives? If not, what adjustments in
present scheduling are necessary?
Section
35
Subsections
00
I
00
Page
01
Section 35: PROGRAM DOCUMENTATION
CONTENTS
Introduction .....•..................
Installation Manuals ................ .
Program Information Manual ...... .
Operation Manual ................ .
35.01. 00
35.10.00
35.10.10
35.10.20
Documentation Examples ............ .
Payroll System - Program
Information Manual .............. .
Payroll System - Operation
Manual ......................... .
35.20.00
35.20.10
35.20.20
Section
35
INTRODUCTION
The final step in your installation program is to
document everything you have done. Let us quickly
review the importance of adequate documentation
before discussing the form that your documentation
may take.
The package of materials describing each program will become:
1. A source of information for implementing
future changes.
2. An education device for familiarizing new
operators and management personnel with the procedures.
3. A means of describing control procedures to
your auditors.
It is a modern but well proven adage that a well
documented installation is a sure sign of a smoothrunning operation.
Subsections
Page
I
01
01
00
You should develop two manuals: the program
information manual and the operation manual. Your
basic library will consist of these two manuals together with this 1130 User's Guide, physical planning manual, the 1130 functional characteristics
manual, the programming system reference
manuals for FORTRAN and Assembler Language,
the machine reference manuals for the I/O units
you have ordered, and operating procedures manual
for FORTRAN, Assembler Language, and Disk
Monitor System. If you use the Commercial Subroutine Package, you will also want reference
manuals and operating procedures manuals for that
system. Consult the 1130 SRL Bibliography for
descriptions and form numbers of the manuals, and
for information about other IBM publications that
provide further details on the subjects covered in
this guide.
Section
35
Subsections
10
I
10
Page
01
INSTALLA TION MANUALS
Program Information Manual
Each application should have its own binder, which
will be used by management, systems analyst, or
programmer, and will contain:
1. Job description. This is the same for all
programs with a job or application. It is a brief
abstract.
2. System flowchart. This is also the same for
all programs within an application, and shows how
each program fits into the larger picture.
3. Record layouts. All record formats for the
application are shown.
The three items above appear once for the application, whereas the items below are necessary for
each program (you may want to place dividers,
labeled with the program names, in front of each
group of these):
1. Form layout.
2. Variable Summary Sheet. The purpose for
which program variables are used is apparent at
the time of writing, but again, as with program
logic (of which variables are an integral part), the
programmer rapidly forgets how he used them. The
Variable Summary Sheet (see Section 25) will serve
as a testing and program modification aid.
3. Program flowchart. Experience has proved
that logic which is clear to the programmer at the
time of writing is difficult to recall a short time
later. The logic must, therefore, be documented
in such a manner that testing will be accomplished
in a minimum amount of machine time. Well documented logic is also valuable when the program is
changed from time to time, either by the author or
by another programmer who may be completely unfamiliar with it.
4. Coding sheets or program listing. To avoid
confusion, the coding sheets should be discarded
after the program listing is produced.
5. Test data listing. Test data should be listed
and retained. As changes to the program are made,
they may unintentionally affect parts of the original
program. All original test data, therefore, along
with any additional test data necessary for the
change, should be processed to ensure that the program is operating properly.
6. Test output. This includes sample reports
or cards, as produced by the test data.
7. Machine setup sheet. This is a guide to the
operator, describing machine setup, source of input,
disposition of output, and actions to be taken at
machine halts.
8. Detailed program flowcharts. These must
be included if the programmer is using Assembler
Language. Since programs written in Assembler
Language are not as easily read, or as clearly related to the job as FORTRAN programs, it is vital
that your programmer draw a detailed program
flowchart that carefully documents the program
steps he has taken. Each block should cover only a
few program steps, and should be cross-referenced
to the program. It is advisable in most cases to include a general program flowchart, which provides
a quick means of introduction to the logic and is exploded by the detailed flowchart.
Section
35
Operation Manual
Intended for use by the operator, the operation
manual is arranged so that each application has its
own section. Usually, these materials are all kept
in one book, at the 1130 console. In addition to the
materials suggested below, the operation manual
should include a copy of the operating procedures
manuals supplied by IBM for the programming
system being used.
Dividers of two kinds should be used: one for
applications and one for programs within applications.
Subsections
Page
I
01
10
20
Behind each application divider should be a job
description followed by a system flowchart of the
entire application.
Behind each program divider should be all instructions to the operator. These may include (1)
procedures to be followed to accomplish accounting
controls, such as recording totals on a control
sheet, checking critical items, and noting crossfooting messages, (2) recovery procedures -- that
is, procedures for reconstructing or continuing a
run that has been interrupted as a result of an operator, machine, or program error, (3) initial switch
settings and their meaning, (4) halts, error messages
and their meaning, and (5) I/O considerations.
Section
35
Subsections
Page
I
01
20
00
DOCUMENTATION EXAMPLES
The examples in this section show the necessary
documentation for those runs in the Payroll System
which were coded under Section 25. Note that these
examples are illustrations and, therefore, may not
be considered complete, usable programs.
Section
35
PAYROLL SYSTEM
Program Information Manual
Subsections
Page
I
01
20
10
Section
35
Subsections
Page
I
02
20
10
Section
Subsections
Page
I
03
20
35
CONTENTS
Payroll Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Job Description .......................
System Flowchart .
Narrati ve ...........
Payroll File Create (PAYOl, PAY02, PAYI6) .............
Payroll File Changes (PAY03, PA Y16) .
Payroll Calculations and Register (PAY04, PAYI6)
Print Payroll Checks (PAY05, PAY06) ......................................
Payroll Check Voiding (PA Yll)
Payroll Deduction Registers (PA Y12 thru PA YI5). . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Payroll File Audit, 941, and Tax (PA Y07, PA Y09, PA YI0) ..
Print W-2 Reports (PA Ynn) .....
o.
Error Dete,ction and Correction (PAY09) .... '.' .
Payroll Record Layouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Card Forms and Console Keyboard Input ...
Console Printer and Line Printer Forms for Output
Disk Record Formats
Payroll Programs ....
PAYOl: Payroll File Create ...
Variable Summary Sheet .
PA YOI General Program Flowchart .
Program Listing .....
Test Data Listing ..........
Test Output o.
Machine Setup Sheet
PAY02: Add Names to the File ...............
Variable Summary Sheet ......
PA Y02 General Program Flowchart .
Program Li sting ..
Test Data Listing, .......
Test Output ...
Machine Setup Sheet ...
o. . . . . . . . . . .
PAY03: Changes to the File.
Variable Summary Sheet ......
PAY03 General Program Flowchart ..........................
Program Listing .....
Test Data Listing ......
Test Output
Machine Setup Sheet
PA Y04: Calculations and Payroll Register
Sample Payroll Register .........
Variable Summary Sheet
o.
PAY04 General Program Flowchart
Program Listing.
Test Data Listing ........
Test Output .....
o.
Machine Setup Sheet
0
0
•
0
0
0
0
0
0
0
•
0
0
•
0
•
00
00
0
0
••
0
0
•••
0
0
00
0
•
0
•••••••••••••••••
0
•••••••••••••••••••••
0
•
0
••
0
•
0
••••••
0
0
0
0
0
0
0
0
0
000
0
•
0
0
0
•
0
0
000
•••••
0
.0.
•
•
•
•
•
•••••••••••••••••••••••••••••
0
0
0
0
'0
0
••
0
0
0
0
0
0
••
0
••
00
••
0.......
0
0
0
0
•
0
0
0
0
0
0
0
0
0
0
0
0
0
•
00000000000000000000000000.
0
0
••
0
0
0
•••
0
••••
0
0
0
0
0
0
0
0
•
0
0
0
0
0
••
0
•••••••••
0
••••••••••
•
0
0
0
0
••
0
••
••
0
00000
0
0
0
••••
•••••••••
0
0
0
0
•
0
0
••••••••
00
••••••
0
0
•
•
•
•
•
•
'0'
0
••••••••
0
0
••
0
000000000000
0
0
0
0
0
0
•
0
•••••
0
0
•
•
0
0
0
0
00.00000
0
0
••
•
•
0
0
•
0
0
0
•
•
•
•
0
•
0
•
•
•
•
•
•
•
•
•
•
'0...
•
•
0
0
0
0
0
0
0.0
••
00.
•••
0
•
••
0
••
0
•
•
•
0
•
•
•
•
•
•
•
•
•
•
•••••••••••••••
•
0000
0
•
•
•
•
•
•
•
0
•••••••
0
•
0
•••••••
0
•
0
0
•
0
0
•
0
0
0
•••••
0
•
0
0
0
0
0
0
0
0
•
0
0
0
0
0
0
0
0
••
0
•
0
0
0
0
•
0
•
0
0
0
0
••
0
0
0
•••••••••••
0
0
•
0
••••••
0
•
0
••
0
•
•
•
•
•
•
•
•
•
•
•
•
•
0
•••••••••
0
•••••••••
0
••••
0
0
•••••••••
0
0
0
••••••
0
0
0
••
0
0
••
0
0
0
0
0
••••
•••
0
0
0
•••••••••
0
0
••••
••
0
0
•
0
••••
0
0
••••
0
•
0
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•••
0
0
••
•••
•
•
•
•
0
•
•
•
•
•
•
•
•
•
•
•
•
•
•
0
0
•
0
0
••••••••••
0
•
•
•
••••••••••••••
0
••
000.0.0
•
•
•
"
••
0
•••••••••••
0
0
0
•••••••••••••
•
0
0
••
0
0
0
0
0
0
••
•
•
0
••••••
0
0
•
•
•
•
0
••
0
00'
.00000000000.000000.
0
0
0
0
0
0
•••
0
0
0
••••••••
0
•
0
••••
0
0
•••
0
•
0
0
0
••••••••••
0
•••••
0
•
•
•
•
•
•
•
•
•
•
•
•
•
•
••
0
0
0
•
•
•
•
•
•
•
0
0
.00.0.0
•
•
••
0
••••••••
0
0
0
0
0
0
0
0
0
•
•
•
0
0
0
• • • • .'
0
0
••
•
0
•
0
••
0
0
0
••
0
0
•
0
•••
0
0
0
0
••
0
0
0
0
'0'
0
0
0
0000000
0
•
•
•
•
•
•
•
•
•
•
0
0
•
•
•
•
•
•
•
••
••
0
••••
00000.
0
0
•••
0
0
0
0
0
•
0
•
0
0
0
•
0
0
0
0
0
0
0
•••
0
0
0
•
0
0
••
0
0
0
••••
0
0
•••••
0
0
•••••••
•
•
••••••••••••••••
0
0
0
0
•••
i
0
•
•••••••
00000.0000
000.0.00000.
•••••••••••••
0
000
•
••
•
0
0
0
•
•
•••••••••••••••••••••••••••••••
0
0
•
•
0
••
•••
•
••••••••
0
0
00.......
•••••
0
•••••
•
0
0
•
•
0
0
0
•
•••••••••••••
0
•
•
•
0
•
••
•
0
0
•
0
0
••••
0
•
0
0
•••
••••••
0..
•
•••••••••
0
0
•
•
0
••
•
•
•
'.'
0
0
•
0
0
0
•••••••
0
••
•••••••••••
•
0
•
0
••••••••••••••••••••••
•
•
0
•
••
0
0
0
•••••••
•
•••••••••••••••••••
0
•
0
0
0
••••••••••••••••••
•••••••••
•••••••
0
0
0
•
000.0
•••••••••
•••••••••
•••••••
••
0
000
•
0
••••
0
•
••
•
0
0
0
•
0
••
0
•
0
0
.0.00
•
•
•
0
0
0
0
0
0
•
0
••••••••••
0
0
•
••••••
0
0
••
0
0
0
0
0
0
•
••
0
•
••••••••
••
0
0
0
0
0
0
•
0
0
0
•
0
0
0
0
0
0
0
0
0
0
0
••••
•
0
0
0
0
0
•
0
•
•
•
0
•••••••••••
0
••••••••••••••••••••••
•
0
••
0
•••
0
0
0
0
0
•••••••••••••••••
•••••••••••••••••••••••
0
0
•••
0
••
0
0
••••
0
0
••••
••
0
0
0
••
•
0
••
0
0
0
0
•
••
0
••••
•
0
0
0
0
0
0
0
0
0
•
0
0
•••••
0
0
0
0
0
0
•••
0
0
0
','
0
0
00
0
0
0
0
0
0
0
•••
0
•
0
•
0
0
0
0
0
0
0
0
0
0
•
0
•••••
0
0
••
0
0
...
0
•••
0
0
•••••
•••
0
00.0
••
•
0
0
o.
1
1
1
1
2
3
4
5
6
7
8
9
10
11
11
12
12
34
34
34
37
38
43
44
45
47
47
50
51
55
55
56
57
57
60
61
67
68
69
70
70
71
77
78
92
93
95
10
Section
35
Subsections
Page
I
04
20
10
PA Y05: Check Writing ......................................................
Sample Check ............................................................
Variable Summary Sheet ..................................................
PA Y05 General Program Flowchart ....................................•...
Program Listing .........................................................
Test Data Listing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..
Test Output ..............................................................
Machine Setup Sheet. . . . . . . . . . . . . . . . . . • . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..
PAY06: Check Register .....................................................
Sample Check Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..
Variable Summary Sheet ..................................................
PAY06 General Program Flowchart.. . . . ... .. . . .. .. .. ...... .. .. . .. ..... . ....
Program Listing .........................................................
Test Data Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..
Test Output ...............................................................
Machine Setup Sheet ......................................................
PAY09: 941 Report .........................................................
Sample 941 Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..
Variable Summary Sheet ..................................................
PAY09 General Program Flowchart ........................................
Program Listing .........................................................
Test Data Listing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..
Test Output .......................... ,...................................
Machine Setup Sheet ......................................................
ii
96
96
97
103
104
111
112
113
114
114
115
121
122
126
126
127
128
128
129
133
139
140
140
141
Section
35
Subsections
Page
I
05
20
10
PAYROLL APPLICATION
JOB DESCRIPTION
The Payroll System is composed of 16 different runs. From the source documents, produced
at the six plant sites, cards are punched. These cards are used to store the payroll information on the disk cartridge.
At this point the system uses cards only for transition between jobs. The input data,
employee records, is read from the disk and updated before being written back. This gives a
highly flexible system, in which I/o, because of the disk, is very fast.
The system produces the following reports:
• Checks and check stubs
• Check register
• Payroll register
• Deduction registers for
1. Union dues
2. Credit union
3. Stock
• 941 quarterly report
SYSTEM FLOWCHART
Narrative
The system consists of 16 programs.
The Files Creation program is first. Data decks are keypunched for each individual, in sets,
by plant. The data is edited and, when correct, loaded on the disk by PAYOl. Three files are
created: a master file, an index file, and a plant information file. A second data deck with
employee clock number and name is loaded onto the master file by PA Y02.
Changes to the disk information are made by PAY03. Documents, received from personnel
departments at the individual plants, are checked, summarized, keypunched, and verified.
Time sheets, submitted by the plant payroll departments, are keypunched and verified. All
of these cards are processed by PAY16 , which edits and generates control totals. PA Y04
then processes these cards, performing all payroll calculations. Cards are read, pay computed, disk files updated, and cards extended with current pay figures. After all cards are
processed, a payroll register is printed.
Checks are printed by PAY05. A header card is read and the checks are printed from the
disk file. PAY06 lists the check register from the disk file. In the event of an error in
computing pay, PA Y11 provides the means of voiding checks. The extended time cards from
PAY04 are read in and the affected employee records are reset. The above are weekly runs.
At month end, registers are prepared showing each individual's deductions for the month:
PA Y13 writes union dues register.
PAY14 writes credit union register.
PA Y15 writes stock deductions register.
PAY12 resets charity deductions code.
At the end of the quarter and at the end of the year PAY07 and PAY08 are used to balance
the disk files to control totals.
PA Y09 produces the 941 tax report.
PAY10 produces a tax worksheet used to determine tax reliability.
At the present time the program for W2 reports has not been written.
1
Section
35
Subsections
Page
I
06
20
10
Employee
Earnings
Record
TAPE
Clock No.
and
Name
All but
Name
Zero Balance
Totals
f8.Y.J.ft
INPUT
EDIT
Out of Balance
EAY..!l2..
/
(
7
Control Totals
/
fA.Y.JU
FILE
CREATE
ADD NAMES
2
All but
Name
/
Section
35
Total on
Adding
Machine
Subsections
Page
I
07
20
~--------. .~ TAPE
Changes
Control
Total
Zero
Balance
Total
~
INPUT
EDIT
Out of Balance
O.K.
Changes
Control
Total
~
FILE
CHANGES
Changes
3
10
Section
35
Subsections
Page
I
08
20
10
Weekly
Time
Sheets
Totals on
Adding
Machine
Details
Zero Balance
Totals
PAY 16
INPUT
EDIT
Control
Totals
Out of Balance
Payroll
Register
Zero Balance
Totals
PAY 04
CALCULATION
Details
Control
~
~_____T_o_ta_ls______~ ~
4
Section
35
Subsections
Page
I
09
20
Control
Totals
Calculated
PAY 05
PAYROLL
CHECKS
Only When
Pay Checks
and Stubs
Totals Balance
Control
Tot
V>
Pay
Rate
" c0
'0
5;§
.~
«
u
Vi
-
~
u
Blank
DO 0 0 000000000000000000 000 DO DO 0 0 o 0 o 0 00 0 0 00 0 0 000 0 o 00 0 o 0 0 0 o 0 0 0 o 0 0 000000000000000000
1234 5678910111213141516171819202122 232425 262 28293031 3133 3435 36373839 40414143 «45%47 48495051 51535455 56575859 606161
~~~~D~~ronnnMHHnn~~
1111 111111111111111111 111 11 1111 11 11 1111 1111 1111 1111 1111 1111 111 111111111111111111
2 2 2 2 222222222222222222 2 2 2 22 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 222222222222222222
3 3 3 3 333333333333333333 33 3 33 3 3 3 3 3 3 3 3 3 3 33 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 33 3 3 3 3 333333333333333333
4444 444444444444444444 444 44 4444 44 44 4444 4444
e
e
reI: c: I:
5 5 5 5 ;JaaaaiJiJiJ"''''''''''''''tJ''''''
~
I"
,.
I"
I"
II!
I!'
I:
I:
I:
I:
.,
c. c.
<
< < < < c.c
\J o,JtJo,J
~ ~ ~
~
, .. '14444 4444 4444 444 444444444444444444
5 5 5 5 5 5 55 5 5 5 5 55555555 5 5 5 5 5 5 5 5 5 5 5 555555555555555555
6 6 6 6 666666666666666666 6 6 6 666666 66 6 6 6 6 66 6 6 6 6 66 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 666666666666666666
7777 777777777777777777 777 777777 77 77 7777 7777 7777 7777 7777 7777 777 777777777777777777
8 8 8 8 888888888888888888 888 888888 88 8 8 8 8 88 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 888888888888888888
9 999 999999999999999999 9 9 9 999999 9 9 9 9 99 99 9999 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 999999999999999999
1234 5678910111213141516171819202112 232425 1627 18293031 3133 3435 36373839 40414143 «454647 48495051 5153M55 56575859 606161 636465666768697071 n73747576n 787980
Figure 4.
14
Section
35
Subsections
Page
I
19
20
Blank
0000000000000.000. 0. 0. 0. 0 0. 0000000000. 0. 0. 0. 0 DODD 0. 0. 0. 0. 0. 0. 0 0 0 0 0 0. 0. DO. 0 0 0 0 0 0 0 0 0 0 0 0.0 0 0 0 0 0 00000000
12345678 91011121314151617181920212223242526272819303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980
11111111111111111111111111111111111111111111111111111111111111111111111111111111
22222222222222222222222222222222222222222222222222222222222222222222222222222222
33333333333333333333333333333333333333333333333333333333333333333333333333333333
44444444444444444444444444444444444444444444444444444444444444444444444444444444
55555555555555555555555555555555555555555555555555555555555555555555555555555555
66666666666666666666666666666666666666666666666666666666666666666666666666666666
77 77 7 7 77 77 7 7 77 7 77 7 77 7 77 77 7 77 7 7 7 7 77 7 7 7 77 7 7 77 77 7 77 7 7 7 7 77 7 7 7 7 7 7 7 7 77 7 7 7 7 7 77 7 7 7 7 7 7 7 7 7
88888888888888888888888888888888888888888888888888888888888888888888888888888888
9 9 9 9 9 9 99 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9
12345678 91011121314151617181920212223242526271829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980
Figure 5.
Total
Plant
No
Check
Date
EJrnings
Date
Clock
Numbers
Total
Regular
Hours
Total
Overtime
Hours
Total
Bonus
Hours
Total
Special
Earnings
Blank
0000000 0.0.00.00. 0.0.00.000 00.000.0.0. 0.0.0.00.0.0. 00.0.000.0. 0.0.0.0000 00.0.00.0.000000000.0.0.0.000.000000.00.000
1234567 8910111213 14151617181920 21222324252627 28293031313334 35363738394041 41434445464748 4950515253545556575859606162636465666768697071717374757677787980
1111111 111111 1111111 1111111 1111111 1111111 1111111 11111111111111111111111111111111
2222222 222222 2222222 2222222 2222222 2222222 2222222 22222222222222222222222222222222
3333333 333333 3333333 3333333 3333333 3333333 3333333 33333333333333333333333333333333
4444444 444444 4444444 4444444 4444444 4444444 4444444 44444444444444444444444444444444
5555555 555555 5555555 5555555 5555555 5555555 5555555 55555555555555555555555555555555
6666666 666666 6666666 6666666 6666666 6666666 6666666 66666666666666666666666666666666
7777777 777777 7777777 7777777 7777777 7777777 7777777 7 7 7 7 7 77 7 7 7 7 7 7 77 7 7 7 77 7 7 77 7 7 7 7 7 7 7 7
8888888 888888 8888888 8888888 8888888 8888888 8888888 88888888888888888888888888888888
9999999 999999 9999999 9999999 9999999 9999999 9999999 99999999999999999999999999999999
1234567 8910111213 14151617181920 21222324251617 18293031313334 35363738394041 42434445464748 4950515253545556575859606162636465666768697071727374757677787980
Figure 6.
15
10
Section
35
Page
Subsections
I
20
20
10
Clock
Regular
No.
Hours
Overtime
Hours
Bonus
Hours
u
Special
Earnings
-g
u
Spec~al
Earnings
~~
-0
U
Special
Earnings
Blank
Ol
00 0 0 00 0 0 0 o 0 0 0 00 0 0 0 0000000 000000 000000 0000000000000000000000000000000000000000000
1234 56789 10111213 1415161718 19202122232425 262728293031 323334353637 38394041424344454647484950515253545556575859606162636465666768697071727374757677787980
1111 11111 1111 11111 1111111 111111 111111 1111111111111111111111111111111111111111111
22 2 2 222 2 2 2 2 2 2 22 2 2 2 2222222 222222 222222 2222222222222222222222222222222222222222222
3 3 3 3 33 3 3 3 3 3 3 3 3 3 3 3 3 3333333 333333 333333 3333333333333333333333333333333333333333333
4444 44444 4444 44444 4444444 444444 444444 4444444444444444444444444444444444444444444
5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5555555 555555 555555 5555555555555555555555555555555555555555555
6 6 6 6 66 6 6 6 6 6 6 6 66 6 6 6 6666666 666666 666666 6666666666666666666666666666666666666666666
7777 77 77 7 7777 77 77 7 7171717 177717 717777 7777777777777777777777777777777777777777777
8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8888888 888888 888888 8888888888888888888888888888888888888888888
9 9 9 9 99 9 9 9 9 9 9 9 99 9 9 9 9999999 999999 999999 9999999999999999999999999999999999999999999
1234 56789 10111213 1415161718 19202122232425 262728293031 323334353637
~~~~Gg44~%~~~~~D~54~~n~~W~~~~~~n~~ron72nMmM77nm~
Figure 7.
Clock
No.
Regular
Overtime
Hours
Hours
Bonus
Hours
-0
u
Special
Earnings
Special
u
Earnings
0
u
Specii::!1
Earnings
Pay
Rate
Gross
Net
FIT
0000 00 0 0 0 00 0 0 000 0 0 0000000 000000 000000 00 0 000000 000003 00 000
FICA
Local
Tax
Credit
Union
Union
Dues
Total All
Other
Deductions iii
~~
m
o0 0 0 o0 0 0 o0 0 0 0000 o00 0 0 o0
1234 56789 10111213 1415161718 19202122232425 262718293031 323334353637 383940 4142434445% 474849505152 5354555657 58596061 62636465 66676869 70717273 7475767778
79~
1111 11111 1111 11111 1111111 111111 111111 111 111111 111111 11111 1111 1111 1111 1111 11111 11
22 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2222222 222222 222222 22 2 222222 222222 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 222 2 2222 2 2 2
33 3 3 3 3 3 3 3 3 3 3 3 3 33 3 3 3333333 333333 333333 33 3 333333 333333 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
4444 44444 4444 44444 4444444 444444 444444 444 444444 444444 44444 4444 4444 4444 4444 44444 44
55 5 5 5 5 !i
!i !i !i 5 5 5 5 5 5 5 5 5555555
555555 555555 55 5 555555 555555 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5
66 6 6 66 6 6 6 6 6 6 6 6 6 6 6 6 6666666 666666 666666 666 666666 666666 6 666 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6
7777 717 77 1777 717 7 7 1777717 717777 717177 777 777777 177717 77 77 7 7777 7777 7777 7777 77 77 7 77
88 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8888888 888888 888888 8 8 8 888888 888888 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8
9 9 9 9 9 9 9 9 9 99 9 9 9 999 9 9999999 999999 999999 999 999999 999999 9 999 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9
1234 58789 10111213 1415161718 19202122232425 262728293031 323334353637
3839~
414243444546 474849505152 5354555657 58596061 62636465 66676869 707172n 7475767778 7980
Figure 8.
16
Section
35
PIJnt
No
Subsections
Page
I
21
20
Blank
OOOOOOOOOOOOOOOOOOOL~i.~~,noooooooooooooooooooooooooooo00000000000000000000000000
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
23 24
111111111111111111111 i
1
1
,~
,& 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80
11111111111111111111111111111111111111111111111111111111
22222222222222222222222222222222222222222222222222222222222222222222222222222222
33333333333333333333333333333333333333333333333333333333333333333333333333333333
4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 44 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4
55555555555555555555555555555555555555555555555555555555555555555555555555555555
66666666666666666666666666666666666666666666666666666666666666666666666666666666
7 17 7 17 17 7 7 17 17 17 7 7 7 7 17 17 7 17 7 17 7 7 7 7 17 17 7 17 7 7 7 7 7 7 17 7 7 7 7 7 7 7 7 7 7 7 17 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 77 7
88888888888888888888888888888888888888888888888888888888888888888888888888888888
9999999999999999999999999999999999999999999999999999 9 9 99999999999999999999999999
12345678 91011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980
Figure 9.
Clock
No
Blank
00000000000000000000000000000000000000000000000000000 0 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 000
12345678 91011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980
11111111111111111111111111111111111111111111111111111111111111111111111111111111
2222222222222222222222222222222222222222222222222222 2 2 22 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2222
3333333333333333333333333333333333333333333333333333 3 3 33 3 3 3 3 3 3 3 3 3 333333333333333
44444444444444444444444444444444444444444444444444444444444444444444444444444444
55555555555555555555555555555555555555555555555555555555555555555555555555555555
66666666666666666666666666666666666666666666666666666 6 66 6 6 6 6 66666666666666666666
7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 71 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7
88888888888888888888888888888888888888888888888888888888888888888888888888888888
9999999999999999999999999999999999999999999999999999 9 9 99 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 999999999
12345678 9101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798C
Figure 10.
17
10
Section
35
Subsections
Page
I
22
20
~
£
10
Delte for
Reporting
Period
0000000
0
Z
Blank
l
o 0 00000000000000000000000000000000000000000000000000000000000000000000000
1 2 3 4 5 6 1 89 10111213141516171819202122232425262128293031,32333435363138394041424344454641484950515253545556515859606162636465666168691011121314151611181980
1111111 11 11111111111111111111111111111111111111111111111111111111111111111111111
2222222 2 2 22222222222222222222222222222222222222222222222222222222222222222222222
3333333 3 3 33333333333333333333333333333333333333333333333333333333333333333333333
4444444 44 44444444444444444444444444444444444444444444444444444444444444444444444
5555555 5555555555555555555555555555555555555555555555555555555555555555555555555
6666666 6 6 666666666666666666666666666666666666666666666666666 66 6 6 6 6 6 6 6 6 6 666666666
7171717 7777777777777777777777777777777777777777777777777777777777777777777777777
8888888 8 8 88888888888888888888888888888888888888888888888888888888888888888888888
9999999 9 9 99999999999999999999999999999999999999999999999999999999999999999999999
1 2 3 4 5 6 7 8 91011121314151617111920212223242526272829303132333435363138394041424344454641484950515253545556515859606162836465666168691011121314151611181980
Figure 11.
Blank
Company Name
00000000000000000000000000000000000000000000000000000000000000000000000000000000
1 2 3 4 5 6 1 6 9101112131415161718192021222324252621282930313233,3435363136394041424344454641484950515253545556515859606162636465866168691011121314151611187980
11111111111111111111111111111111111111111111111111111111111111111111111111111111
22222222222222222222222222222222222222222222222222222222222222222222222222222222
33333333333333333333333333333333333333333333333333333333333333333333333333333333
4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 44 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 44 4 4 4 4 4
55555555555555555555555555555555555555555555555555555555555555555555555555555555
66666666666666666666666666666666666666666666666666666666666666666666666666666666
7 7 7 7 7 7 7 7 17 17 7 7 17 7 7 7 7 7 7 17 7 17 7 17 7 17 7 17 7 17 77 7 17 7 7 77 7 7 7 7 7 17 7 17 7 7 71 7 7 71 7 17 7 17 7 7 17 7 7 17
88888888888888888888888888888888888888888888888888888888888888888888888888888888
99999999999999999999999999999999999999999999999999999999999999999999999999999999
1 2 3 4 5 6 1 8 91011121314151611181920212223242526272829303132333435363138394041424344454641484950515253545556515859606162636465666168691011121314151611181980
Figure 12.
18
Section
35
Subsections
Page
I
23
20
Street Address
00000000000000000000000000000000000000000000000000000000000000000000000000000000
1 2 3 4 5 6 7 8 91011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980
11111111111111111111111111111111111111111111111111111111111111111111111111111111
22222222222222222222222222222222222222222222222222222222222222222222222222222222
33333333333333333333333333333333333333333333333333333333333333333333333333333333
4 4 4 4 44 44 4 4 4 4 4 44 4 4 4 4 4 44 44 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4
55555555555555555555555555555555555555555555555555555555555555555555555555555555
66666666666666666666666666666666666666666666666666666666666666666666666666666666
77777777777777777777777777777777777777777777777777777777777777777777777777777777
8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8"8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8
99999999999999999999999999999999999999999999999999999999999999999999999999999999
1 2 3 4 5 6 7 8 91011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980
Figure 13.
Blank
City and ZIJ) Code
000000000000000000000000000000000000000000000000000 0 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 2 3 4 5 6 7 8 91011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980
11111111111111111111111111111111111111111111111111111111111111111111111111111111
22222222222222222222222222222222222222222222222222222222222222222222222222222222
333333333333333333333333333333333333333333333333333 3 33 3 3 3 3 3 3 33333333333333333333
44444444444444444444444444444444444444444444444444444444444444444444444444444444
55555555555555555555555555555555555555555555555555555555555555555555555555555555
66666666666666666666666666666666666666666666666666666666666666666666666666666666
7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 77 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7
88888888888888888888888888888888888888888888888888888888888888888888888888888888
999999999999999999999999999999999999999999999999999 9 99 9 9 9 9 9 9 9 9 9 99999999999999999
1 2 3 4 5 6 7 8 91011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980
Figure 14.
19
10
Section
35
Subsections
Page
I
24
20
10
StiJte
Account
No.
Blunk
FcdcriJl
Accounl
No
BieHl"
0000000000 0000000000000000000 0000000000 00000000000000000000000000000000000000000
1 2 3 4 5 6 1 8 9 1 0 11121314151617181920212223242526272829 30313233343536373839 4041414344 45 46 47484950515153545556575859606161636465666168691011 1113 14151611 181980
1111111111 1111111111111111111 1111111111 11111111111111111111111111111111111111111
2222222222 2222222222222222222 2222222222 22222222222222222222222222222222222222222
3333333333 3333333333333333333 3333333333 33333333333333333333333333333333333333333
4444444444 4444444444444444444 4444444444 4 4 4 4 4 4 44 4 4 4 4 4 44 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4
5555555555 5555555555555555555 5555555555 55555555555555555555555555555555555555555
6666666666 6666666666666666666 6666666666 66666666666666666666666666666666666666666
7777777777 7777777777777777777 7777777777 77777777777777777777777777777777777777777
8888888888 8888888888888888888 8888888888 88888888888888888888888888888888888888888
9999999999 9999999999999999999 9999999999 99999999999999999999999999999999999999999
1 2 3 4 5 6 1 8 9 1 0 11121314151617181920212223242526211829 30313233343536313839 4041414344454641484950515153545556515859606162636465666168691011111314151611181980
Figure 15.
20
IB~
INTERNATIONAL BUSINESS MACHINES CORPORATION
LINE DESCRIPTION
PRINTER SPACING CHART
IBM 407, 408, 409, 1403, 1404, 144::', and 2203
8 lines Per Inch
FiElD HEADINGS/WORD MARKS
Print Span:
.~
-H
IBM 1403 Models 1 & 4
, I
,
Ii
I
1
I
IBM 1403 Models 2, 3, 5, N1 and 1404
IBM 1443 Models 1, N 1,
GL UE
ttl
m o,J
"
~
!:
J~ ~-:
'."
,~~
;;
""""
1
0
~
C'lL,.r:o.WN_
I
I
-
1
12
3
4
5
6
7
8
9
10
11
12 '13
14'
I
-T ITTTTT -nTl[
hTTTTrTT nT!T
;;;: (5
I
IBM 407, 408, 409, and 1403 Models 6 and 7
II
2
231456789 01 234151678 9 0,1 2 3 4 5,6 7 8 9
I
I ,
f
~
~
I
I~
I I~ I
~
5
3
4
o 1 2 34 5 6'7 89 o 1 23,4567 89012:314'56,7890 ,1
..
•
I
j,.
-i-
I
I
I
i
I
I
,
! i,
I
I
I
i
I
j
, I
I
I
~
~
I
"'-b.
11
l
,
,
It
10
8901234567890123456789~
I
jl
- -
:
9
I
I
.1
"
I
I
I
8
7
6
2 3l4'sT617 8 9 0' 1 2 3,4 5 6 7 89 01234,567890 1234567
I
an~ 2203
trl IXI
i
'
II
iT1~
:d'i,
I
I
'i
,.v
Figure 16.
~!
INTERNATIONAL BUSINESS MACHINES CORPORATION
IB~
8 lines Per Inch
FIELD HEADINGS/WORD MARKS
LINE DESCRIPTION
PRINTER SPACING CHART
IBM 407, 408, 409, 1403, 1404, 1443; and 2203
Print Span:
+-i
IBM 1403 Models 1 & 4
I
IBM 407, 408, 409, and 1403 Models 6 and 7
TTTT TTTTTT
I~M
1403 Models 2, 3, 5,
IBM 1443 Models 1, N1,
o
1
2
1 '1,1 2 3456789 01 234'567890 1 2 3 4567
3
4
5
6
7
8
N~T-T\~~~41 ITTTTTTTTT
an~ 2203
9:
10
11
Ii 9 0 1 234567890 1 234567890 1 2345 67 8901 1 34,5:6789 0 1 23 4 , 516 7'8,9 0 1 23;4;567 890 1 234 5678,90 1 2·3456,7 890 1 2,34 5!>-jZ 890
1
I
2
4
5
I I
~
a:
I
'
I
I
r~~
I
..
Cf)
CD
W
01
()
r-+
o·
:::J
t>:l
0
r-I-'
0
Cf)
C
0"
CIl
CD
()
r-+
o·
:::J
CIl
Figure 17
t>:l
01
"iJ
Q)
co
CD
en
CD
C;.:l
01
(')
.....
O·
::l
~
0
i--I-'
0
~
~
INTERNATIONAL BUSINESS MACHINES CORPORATION
IBJ.t
PRINTER SPACING CHART
LINE DESCRIPTION
8 Lines Per Inch
FIELD HEADINGS/WORD MARKS
IBM 407, 408, 409, 1403, 1404, J443, and 2203
Print Span:
1403
I
Aadels 1 & 4 .}
407, 4J8, 409, and 1 ~q3 Models 6
I
IT
I
•
)
GL' :UE
I
I
.
;1.,
E
I II I
~~
I~
I
~
"""'"
Figure 17. (Cont)
I II II
~
I
)
II
!
11
I
I,
I;
1403
Aodels 2. 3, 5,
~443
Aoje-,,-
i
'
I
)
I
II
I
:
I
I
I,
i
I
!
I
I
.1
,
i
!
I
I
I
I
I
I
N1. c d
I
7
i
I
I
I]
I
i
I
and
nd
·1
en
c
0'"
en
CD
(')
.....
O·
::l
en
""tJ
Q)
to
CD
IBr.,
INTERNATIONAL BUSINESS MACHINES CORPORATION
LINE DESCRIPTION
FIELD HEADINGS/WORD MARKS
PRINTER SPACING CHART
IBM 407, 408, 409, 1403;1404, 1443, and 2203
8 lines Per Inch
Print Span:
IBM 1403 Models 1 & 4
t-l
II
IBM 407, 408, 409, dnd 1403 Models 6 and 7
I
ITTTIT tiTTITT IBM 1403 Models 2, 3, 5, Nl and
II
II
II
1
4
1~04
IBM 1443 Models 1, N 1, an~ 2203
0
.: 1 2 345678901 2345678
,
2
3
4
5
6
7
8
9:
10
11
01 234567 B 90 1 2,3'4567 B 9 0 1 234567890 1 23145 678901 2 314567'89 0 1 234156789 0 1 234·567890 1 2345678901 2345678901 234567 '8 90'
1
•
•
•
II
1 1
1
i
I I
I
I
!
1
Figme 18.
(f)
CI:l
OJ
(1)
(')
r-+
O·
~
~
0
~
(f)
c
0"
(I)
(1)
(')
r-+
~
0
~
-1
O·
~
(I)
"1J
OJ
CO
(1)
en
CI)
V.:>
01
(')
.-+
o·
:::J
IB,.,
LINE DESCRIPTION
I
I
INTERNATIONAL BUSINESS MACHINES CORPORATION
PRINTER SPACING CHART
FIELD HEADINGS/WORD MARKS
8 lines Per Inch
IBM 407, 408, 409, 1403, 1404, 1443, and 2203
I
Print Span:
,IBM 1403
~odels
1 & 4
1
407, 408, 409, and 1 13 Models 6
IR,
1403
~odels
1443
~odels
2, 3, 5,
~
J
I
I
c~nd
0
-
CI)
(')
.-+
.....
II' and
0
~
II
.2
8.
~
.2
~]
8~ oH++H~H++HI~----~~~
'.
2~
~
.~ ~
.s~
11
1
~
jl
Figure 19.
"H++H~H++H!~-----~~~
I
o·
:::J
en
N1 c
1
4
en
c
0en
.!iii
~ H-t+H'ff-tt-tTtir------T.-';'-t-+-t0; H-t++t+t-t+++Hf-------+i*H_1~H-t++tI~"t+++Hf------~H_I_H~~++-~~HH~++++++HH~++++++HHrlH~~+++++HHHrl++++++HHHrl~++++~HH~++++~HH~++++++nrHrl+++++THHHH~+++Trr~
.~H+HI'.rt+++Hr-----~H-I-H~~++-~~HH~++++++HH~++++++HHrlH~++++++HHHrl+++++THHHrl~+++TrrHH~++++rrHH~++++++nrHrl+++++THHHH~++++rr~
00
iJ
Q)
to
CI)
,
!
IB~
LINE DESCRIPTION
I
INTERNATIONAL BUSINESS MACHINES CORPORATION
fielD HEADINGS/WORD MARKS
8 Lines Per Inch
PRINTER SPACING CHART
IBM 407, 408, 409, 1403, 1404, 1443, and 2203
Ii
I'
Print Span:
t
1403 r\odels 1 & 4
I
I
407, 4 )8, 409, and 1 13 Models 6 c,nd
~
1403 r\odels 2, 3, 5,
nand
1443 Aodels 1 Nl
?
a
t :HH++HH~+H,~----~~~~-rHrl~Hrl~-H~~~-HHrl~~~~~~~~~~~~~~~~-rI-H~-~~~~~~1~~~~~~~~~~~~~~~~~~~~++++~
tl
:HK+H~H++HI~----~~H
8 ~ ~ HH++HH~+H,~----~7<++__I'_
:~ :HK+H~H++HI~----~~~
,~ ~
;; H-tt+tffl-t-t1H-if--------+m-H--
.51
11
~
j
~ HH++HH~+H-t~----~~_tt_+_c
5' ~HH++HH~+H,~---~-:-:T++-!
1 ;HH++HH~+H,~----~~+__I'_
j ~
.HH++HH~+H,~----~~~
s f-t-t-H-t.-t-t++H--jf-------t-ffi+t_'
~l:~~,~~~~~~~~~~~~~~~~~~~~~~~
~~
Figure 20.
CJ)
CD
CI:l
CI
(")
.-+
o·
::J
~
0
CJ)
c
0(I)
-
CD
(")
.-+
I-'
o·
0
::J
~
~
(I)
"0
Q)
co
CD
CJ)
""
01
IB,.,
INTERNATIONAL BUSINESS MACHINES CORPORATION
LINE DESCRIPTION
fielD HEADINGS/WOlD MARKS
PRINTER SPACING CHART
IBM 407, 408, 409, 1403, 1404, 1443, and 220'3
8 lines Per Inch
+-:
I\:)
0
J
Print Span:
IBM 1403 Models 1 & 4
I
I
I
-
r+
o·
::J
CJ)
C
0en
ct)
()
r+
I-'
IBM 407, 408, 409, and 1403 Models 6 and 7
0
!T
ct)
()
o·
::J
en
IBM 1403 Models 2, 3,5, N 1 and 1404
IBM 1443 Models 1, N1, an~ 2203
o
GL UE
!
2
3
4
5
6
7
8
9:
10
'12345678901234567890J234567890123456789012345678901~34567~9012345~7890123~56789012345678901234567890123456789
;;::01001"
~
1
11
12~4S6789
:H4++~++~~~----~~~~~~-H~~-H~-H-H~~-H~~~~~~~4444~444444-H-H-H-H-H-H-H-H-H-H44-H-H-H-H-H-H-H-H-H-H-H-H-H-H++++++++-H++++++++~
tl :~tt~jt~~~====~~I~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~++++++++++~
: ~a
~~
.~
.~
13
14
"i
~!
11
l 5
17
11
j
::
IXIXIXIX
~~
1
:
!~
~~ :HH++~++~~~-----4~24H1-H-H-H~-H-H-H-H-H-H-H-H-H-H1H-H-H-H-H-H-H-H-H-H-H~-H-H-H-H-H-H~++++++-H-H-H++++++++++++-H-H-H++++++++++++++~++++++~
~~ ~HH++~~+HH~----~~~:~~~~~~~~~~~~~~~~~~~~~HHHHHH~~~~~~~HHHH~~-H-HHHHHHH-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H~
~~2~ ;HH++~+++HH~----~~~~~~~~Hr~~~~~~~H-H-~-HHHH-HHH--HHHHH-HH-H-H--HrHH-~HHHH-H~-H-H-HHHHH-HHH-HHH-H-HHHHHHHHH-HHH-H-HHHHH-H-H-H-H-H~
:~_~_~~~LU~~----~429~~~~~~~~~~~~~~HHHH~~HHHHHHHHHH-HHHHH~~HH~HHHHHHHH-H-H-H-HHHHH-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-rn.
!l f"ou.
~!
.~1 EHH++~+++HH~----~~~!~~~~~~~~~~~~~~~HH~~HH-H~-HHH-H~-H~rH-H~~HHHH-H~-HHH-HHHHH-H-H-H-H-H-H-H-H-H-H-HHH-H-H-H-H-H-H-H-H-H~
{i ~HH++~+++H~~----~~~~~HH~~~~~~~~~HH~~HHHH~HHHH-HHH-HHH-H-HHH~HH~~HHHH-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H~
~1 ~HH++~+++HH~----~~~:~~~~~~~~~~~Hr~~HHHH~~HHHH-H-HHH-HH-HH~~HH~HHrHHH-H~-H-H-HHHrlrlrlrlHH-H-H-H-HHHHH-H-H-H-H-H-H-H-H-H-H-H-H-H~
.1 ~
~!
!H4++HH++~~~-----4~:~~-H-H-H~-H-H-H-H-HHH-H-H-H-H~-HHHHH-HHHHHHH-H-H-H41HH-H-H-HHHHH~~HHHHHHHHHHHH~~++~HHHHHH++++++++++~~++++++++++~
:
~ ~ HH-t+~-t+t+t-Jr------t7.:~H-It-HHH-HiH-H-HHH-H-H-H--,--j-H-H-H\H-H-H-H--t-:~--I+H-~H-~~tIt-~~~~~~+-I--~~~~rr~~H--HHH~H-rr~H-H-HHHH~~HHHHHHHHHHHHf-:-t
11
:48
co...
I~
~
~ .~
50
~ ~ ~H4++HH++~~~-----4~~~~-H-H-H4H-H-H-H-H-H-H-H-HHH-H~-HHHHHHHHHHHHH-H-H-H~-H-H-H-HHH++~~~HH~~++~++++++++++~~~++++++++++++++++++++++~
~i ~HH++HH++~~~-----4~~!~-H-H-H4H-H-H-H-H-H-H-H-H-H-H1H-HHHHHHHHHHHHH-H-H-H~-H-H~~~-H~++++HH~++++++++++++++++~-H++++++++++++++++++++ft++~
i~~~
~~~~~LU~~----~~55~~~-H~~-H-H~-H~~-H-H-H~~-H-H-H-H-H·~~+t-H~~-H-H-H-H-H-HH4·-H-++++-H-H-H++++++++-H++-H++++++++++++++++++++++++~
~~::o~m~
~~
1~:
I~
~~L~~·;~~±t~±±ta~~~~~~~~~333J~33jj:833~J33333~~3j33~3j~~~~ji~~~jj~~~~~~~**~~~~~llllllllll11llll~~i!!!iiii!IIiii~!i!!!E
~~~,~~w-~~-~-. ~
Figure 21.
""
0
"
Q)
co
ct)
.,
IB",
:
INTERNATIONAL BUSINESS MACHINES CORPORATION
PRINTER SPACING CHART
LINE DESCRIPTION
IBM 407, 408, 409, 1403, 1404, 1443, and 2203
8 Lines Per Inch
FIELD HEADINGS/WORD MARKS
I
Print Span:
.In
1403
hodels 1 & 4
I
I
.J-1
I
~4 )8,.409, and 1~q3 Models 6 c!nd
I
1403 hodels 2,3, 5, .N1 and'
I
1443
2
GL tUE
t:
t8 f~ :
~
2
~ ~
.:
-
.~ g r:;
~...-
l"
.......
••
~
~
I
~
16
1 N1. c .~
11
I
~
~odels
~
I
I
•
•
•
I
1
~
,....
.J.o
...,
..
FiglU'e 22.
en
CD
CI:I
01
(')
.-+
o·
:J
I:\:)
--0
.....
0
CI:I
.....
en
c
C"
en
CD
(')
.-+
o·
:J
en
""0
Q)
CO
CD
(f)
en
CN
C1
n
.....
o·
~
LINE DESCRIPTION
~
INTERNATIONAL BUSINESS MACHINES CORPORATION
IB"1
0
PRINTER SPACING CHART
8 Lines Per Inch
IBM 407, 408, 409, 1403, 1404, 1443, and 2203
Print Span:
I
1403 Aodels 1 & 4
407, 438, 409, and 1 13 Models 6 c!nd
1443
00dels 1 Nl
c ~
~
I
Figure 23.
n
.....
I-"
o·
0
VI
CN
~
! i
(f)
C
cr
VI
en
~
."
Q)
to
en
INTERNATJONAl BUSINESS MACHINES CORPORATION
IB"1
LINE DESCRIPTION
FielD HEADINGS/WORD MARKS
8 lines Per Inch
PRINTER SPACING CHART
IBM 407, 408, 409, 1403, 1404, 1443, and 2203
Print Span:
1403 \.Iodels 1 & 4
g
I
407, 408, 409, and 1403 Models 6 ,;nd
1403 Ylodels ~3.5, :N1 and
,IBM 1443
GL~UE
lIodels
N1 c
1
Figure 24.
U>
CD
C.:l
0
C1
o·
~
::J
t\:)
0
U>
C
0CIl
~
CD
.....
0
0
0
~.
::J
CIl
"'tl
C.:l
C.:l
C)
<0
CD
CJ)
CD
C;.:J
<:Jl
()
.-+
O·
::::l
IB~
:
INTERNATIONAL BUSINESS MACHINES CORPORATION
PRINTER SPACING CHART
liNE DESCRIPTION
FIELD HEADINGS/WORD M,\RKS
IBM 407, 408, 409, 1403, 1404, 1443, and 2203
8 Lines Per Inch
~
Print Span:
1403
-,adels 1 & 4
, I
+
407, 4 )8, 409, _and 1<1
I
~3
Models 6
2
I
I
1403
Aodels 2, 3, 5,
1443
Aodels 1 Nl, c
1
FiglU'e 25.
INTERNATIONAL BUSINESS MACHINES CORPORATION
FIELD HEADINGS/WORD MARI:S
PRINTER SPACING CHART
IBM 407, 408, 409, 1403, 1404, 1443, and 2203
8 Lines Per Inch
Print Span:
lh-rr"-"-rl-"-"-""-rl-""rr"rl-rr"--r,'--'--rl-,,rrrr"--rl-,,-'--'''---''--rl-rTTTrr!~Ti:r:-~';::::;:::1i;:::I;:::;:::~~I~BM~I~4~0~3~M~~o:.c:d~el~s';I~&,'4~rti
-H'-;I_,---,--,---,--,---,--,---llh-.--,-,--.--r--'-'-.-l~
IBM 407, 408, 409, and 1403 Models 6 and 7
!Ii TI
I
fi ! Tl T ' I 1T I I TTrni T I
IBM 1403 Models 2, 3, 5, N 1 and 1404
'r
,
'! I
,I
i
I
I
IBM 1443 Models 1, Nl,
o
2
3
4
5
7
6
8
9
an~
2203
10
11
, 1 2345678901 234 ! 678901 2 3 45167890,1 234,5,6:71890 1 2'3 4567890 1 2.3:4.5 6,7 8901 2 3:4,5,617'8,9 0 1 213,4'5,67819 0 1 '234567 890 1 234567890 1 2345678901 234567890
1
I
I
: II
.!
'
II
i:
3
4
FiglU'e 26.
I 1
i
l I
I
VI
CD
.-+
O·
::::l
VI
II and
" :!
LINE DESCRIPTION
()
C
I
6
IB"1
~
0
Ii
I
0'
t-'
nd
CJ)
t-..?
0
•
I
!
J
"'C
C;.:J
Q)
fI::>.
<0
CD
r-------
'":t1
QQ.
!;
(l)
IV
;'-l
~
u;
FIT
Processing Status
0
Local Tax
Oed. Code
~
Credit Union
Charity
Union Dues
u;
U1
Stock
Misc.
~Q
:lJ G>
til
C)
...
en
(11
~t-
en I-en I-
0)
o r-
OT Rate
u;
c;;
Regular Hours
~
0
a.~
OT Hours
~
~
o
~
-
t
Gross
Avg. Pay Rate
Insurance
U;
0)
---,
.-
~
-.j
o
::!
t
:r
::J
Clock No.
~r
~
Regular Earnings
ffi
~t:..
Check No.
en
Ins. Oed.
Other Earnings
I
Misc. Oed.
Char. Oed.
~
U1
~
Code
Holiday Pay
co
U1
t
~
-
Sick Pay
I
~
8tt-----~
o
~
t-
~
-
-
Net Pay
o
FICA
~
t
I
~
:lJ
'"a:
~
~
~.
Union Init. Fee
~t
~
o
~
t
;b
~.
t
Vacation Pay
g.~
t-I_ _ _ _ _ _ _
~
::::
Social Security
Number
Status
u;
Union Dues
C;;
Weeks Employed
Weeks Paid
Cil
<
w
~
z
~
"tI
co I-en I-
o
a
(111-0)
0t--
Stock Oed. Month-to-Date
w
en
~
o
Stock Oed.
~
t
8
~
Additional WH
Bonus Earnings
0(
~
o
Credit Union Month-to-Oate
~
U1
a
w
01--
OT Earnings
w
~ co
en
Credit Union Oed.
-
j
-'
U1t--
~
0
..,
g ~. ~
00
0)
~
a
w
YTO Hrs.
C;;
t
;
~ cu
~ a~
3: g ~.
o ... 0
I-
Bonus Hours
~
.....
0(
_.... m
0) III
~
g. ~
m
gg~
~1-
~
III
0';1
3~
::l
~
=fillS:
c ~ "tI
-:i" r
U1 co 0
t
II--
(11
c-"
r+
I-
J
L
~
~
I
.-
Marital
Fed. Xmps.
State Xmps.
CJ)
Sex
c-"
Pay Rate
01
-- --
N
0
(1)
(")
r-+
o·
::J
CJ)
c
0(I)
~
.....
0
c-"
01
(1)
(")
r-+
o·
::J
(I)
""tJ
Q)
CO
(1)
Section
Subsections
Page
I
36
20
35
10
Each record is composed of 1 word,
The number of records in the file is
the number of employees in the
plant plus 25%, The last entry is
the record number of the last clock
number entered,
o
z
tl
c3
(
)
l
~
(
(
)
Year-to-Date Information
)
(
I
I
I
I
I
I
30 31
35 36
I
25 26
I
I
I
I
)
(
I
-g
Quarter-to-Date
Information
~
0
e
0
'0:
l-
::::>
0
>-
~
()
I
I
I
I
65 66
70 71
7576
8081
(II
~
:l
en
::l
a:
I
I
e
g.
(!)
0
«
(l.
:x:
0
.~
:x:
w
l0
e
:x:
:;
'"
g>
a:
I-
I II
::l
0
IX!
::::>
Z
.>t:
~
~
()
-g
'" -g0 0 -g0
0
e
0
';:;
tl
9
'5
'0 en
«
W
:;
'"
g>
a:
~
I-
u:: 130
-'
e
0
'0:
::::>
~
()
,~
~
[q,
e
.~
w
()
~
~
e
::l
e
0
IX!
II
tl0 ~
cil ~
130131
For Growth
of Record
(
I
150151
155156
I
'"
~
()
~
W
'"
'0:
e
0
'0:
Overtime
Rate
Previous 13 weeks
:2
-g
0
::::>
I
I
I
I
I
~
'"
't.l
0
()
~
(l.
~
:2
'0
:x:
0
I
I
I
I
105106
100101
95 96
[q,
e
.~
'"
..:
'"
u..
0
~
e
(l.
0
'N
>'"
~
(l.
.>t:
u
en
~
(l.
z'"
I
160
Figure 28.
32
135136
«
()
u::
)
I I~
II
125126
::::>
/
~
~
(II
~
e
'0:
0
)
I
60 61
-5e
I
(II
'" '"ue
0
I
I
55 56
9091
l-
0
I
I
tl0
cil
)
l-
~
~
U
[q,
e
I
'"
:x:
;:: -0
-5e
ci iii
0
e
0
'0:
I
9'"
6
';'
.~
(II
120121
115116
110111
g,
~
0
~
:2
I
50 51
'85 86
0
~
0
1ti'"
~ a:
(l.
III
()
e
~
~
'"0
'"e
'~ -g
'0
~ I II
)
I
'"
)
~
I
45 46
(
i
I
••
40 41
140141
145146
Section
35
Subsections
Page
I
37
20
10
ci
z
ci
~ z
~
This is the plant information record.
Plant Name
U
~
(l)
.~ ~
u..
I
I
I
5 6
10 11
15 16
Trade Association Information
I
.c
>
<:
;:J
u
0
~
«
. E
:a;
~
~ 0
~t5
0
f-
ci
>
~
s:~ ~
(l)
(ij
z
0
f-
I
I
I
I
I
I
I
I
25 26
30 31
35 36
40 41
45 46
50 51
55 56
60 61
Available
for
I
65 66
~
General Ledger
Account Numbers
for Posting
70 71
75 76
80 81
I
85 86
Figure 29.
33
Expansion
I
I
I
90 91
95 96
I
100101
105106
z
~
"
(l)
.c
u
~
u::
Section
35
Subsections
Page
I
38
20
10
PAYROLL PROGRAMS
PAY01: PAYROLL FILE CREATE
VARIABLES
I
IBM
1130 COMPUTING SYSTEM
VARIABLE SUMMARY SHEET
"C
0..
:2:1-
s:
---I-
V>
0
NAME
*U.J
0
0
:2:
'0
U.J::)
1-0.. MAX.
1-::) VALUE
c:i ~o
~
MIN.
VALUE
Application
PAYRoLL SYsrEA?
Program Name
File C/'ea/e
z
ap...:S707
No./3IYO/
K.fiC~
Programmer
FUNCTION OF VARIABLES
R ~ T /N~~ ¢.¢(/ Mt:?K/;npm c.4ecL
Ck";14AX
Date
c7/YJOV/7~
/brt:? /J/e,
-
11ft' I~ J;~
Ct)n?/a.n.;/' bda-7C?,
P8PE R ~4 0 ,~rI~ ¢,¢¢ Trdk .1?SSoc/'.:7~on r'eptCJrh.
COA4P
Z
I
Ie
/
r
vsecl
-
Z / A/
.r / r
I;CIIC/c
Ieo!..
I
fA/v
-
.l
-
T
.2)0 /C)O~
E~v/~aka~
Se" ,t'Jor
each rc./a
I-CJ ZN../
..8e.q/~n//;q c,4~c.l;;..
/7",nl(;',-,-.
/O(I, /¢/
"PL4n7'"&/Ie "Llmbe'" t::?~ ,";""dt!!?'x
,,t.:?,,,......
.L,A/LJEX Z ~ T
Z/\/ZT I I 0
>(X}(X
/~td{i
¢
¢
(//7/t:;',., 1/)/rI~"'/::'n .,t'ee
r
250
:f
Pece:;rd ;?vh?k,... /~
.EAlI
I
Z#Z
.r /
INS
.z
I
f/7dex
to ?/4~/ /?~t.V
E;PI'v~k~/ To fA/L
-
Ei'VI'v4/~n;': 7"'0 .LA/.t
.J' A/4 7
INS .E / AI I/./6 ~ I AI
LPL/ Z I 0 t»
.T5{/~'p If" 1.3 0 ¢
-
~/I;'/A/#nl.~,
---z"""'.,
...... "-'"''
-
E~vI;"'dk/?r 7'0 Z /1/1
~
-
-
.zTt:JT lL /1 r 1172.3
£I1/EEK
*Mode: I
=
I
I
integer, R
T
= real,
SD
Ch~~es.
.6,::1
,Prt:7c~s.se'/
Jnd~xe:5 ~Erlj/o]/;;':lee"&;k
-
-
U//"/l'/N9
a /,/4.-?r. ,.0# -I- /CJO
6(!"/",,=,
--
N
I IV'
I J./
t:.t.//'~/7
Recor.:-J nLlrn~erl;"'; E/J/;7/05/~e A/es,. se~~
/ T 250 1
I
I'n
A /;/
.....;r,""
...
¢
hd;c-4~.s S1-Cllps 01'~cod/;',Prarc~.ssl-":1 ~c~
¢
S'1./,Pr)/~I'?7~~,,;l4/ SI'c./:
~
.f
= decimal,
A
E'2(./ / Vc7 /~/JT 7'C).zN:f
. ;/Ccovn r /1vR1~~r
'p4,tf
,t;,-'posltl1.ff rc /;' ~~~r",//eo!J~1'
~e'£:: (/)1' ;/A ~ /J?~"rh
= alphabetic
34
Section
IBM
I
Page
I
39
20
35
VARIABLES
Subsections
10
1130 COMPUTING SYSTEM
VARIABLE SUMMARY SHEET
Vl
"0
0
NAME
*LU
0
0
2:
Z
£)1/1/A
S
'0
0
z
J
c..
2:~
LU:J
~c..
--~
~:J
~O
MAX.
VALUE
MIN.
VALUE
/
-
-
IV
/
tf/AM£
-
;VC/-lC~
~/ /e C/'('4,;-'/"e
~U/v.:?~;;;,.//' ,~.,
/'
AI~tJw/i Z
/
AI
,c.:'Y5//c,A4'
FUNCTION OF
¢
MI/,1/C E
Program Name
~
¢
9
Z / 7 XxX ¢
L~.57
z / AI - L'80
L.BT .L I N LklC
£ / AI L57
.L / T 2&:J ~5(2f
¢
(2f
LYA~WR I
J 0
r / T
/W
/
/WAR L I ~6 2
I
/-('
Application p4YROL~
/ 0
lit 9 ~o
£ I 0 (25
Date
8j/sA;7
YC/
No./??
K//cK.
Programmer
VAR~ABLES
ICOL
LQS/ ~r€'7" /~.s/
Lt?s/ /~cort!/ nVP/tber /~
E?/.//J/U/c::'/7/ ~o
qC//Vc7~///
/3/e
zeoL
7.0 feeL
E?,u/v?/k~~r" /:? ZG'(::7L
L't?.5"/ recor//7t../n-;t6..":?r /r, Q/J/e
Til 1'5
J"-'br
';;je/1r's
d CCt/rr-?u/4hor?
V(7qd~/o;?
(/~ec/ /"
:Do
CJr hOd,..S UJttJr~~t7'
?Qy
loop
A44r'//a I S-/dt'vS"'-(I-S/ag/ehr?-.r1'?/2rr/·edj
-
qv,'vel/enf ~o.LCaL
;;d
4c1d/~'c>/?4/ 1.{}':/hA~M/?9 4/?'7PU/7~
.
\
(2/
~d'mn';lo/' 4r~t? ~~/4.,cd~d s;t.;)~ce /or .ndnJe
CAeck. /7orrl.6er vs-e./ ~I" 7A/s t?h:7p/oyee
A/cu L / t~ xx. xx af c ;-c>~;t y,.., / ~04 cks---;,{-/c ~ 0 n
N'C(/~£ Z I C)
aJ ¢' ;Y/O"/hy c,.~~/// (//1/orJ 4f---7t!vc ~ons (;n c/'mes)
t!?
NOvE'S
M~_s-
r
/ ~tJ XX-xx ¢
I / ~t xx. xx (2J
Z J
N/f4/S{,!
If/ap.lT £ /
*Mode: I
=
integer, R
CJ
a1
¢
r
~
I
= real,
D
= decimal,
Ch?/C;1"1 elves d't#dvcr/on
.Tr1svrt://)ce d~t"/vch&'7
I'/?/sre / /t:;,..., C't'vs d'~c/uc l/or7S'
P/.c:?nr ht./,nber
A
= alphabetic
35
Section
35
Page
Subsections
20
I
40
10
VARIABLES
IBM
1130 COMPUTING SYSTEM
1
VARIABLE SUMMARY SHEET
NAME
.
w
0
0
~
III
"0
(;
s:
0..
~I-
w::::>
1-0..
Application
MAX.
'0 ;::~ VALUE
0 ~o
z ~
.z
#,';'"e-x
Z / (,tJ ..3
A/5sAN'
.z
WST.45
Z
ll;O
PA yROL L SYSTf;--vt
Program Name
,rC'/ /e
C /' e t7/e
Date
Clj/S/6 7
f//;';;-/c::..
No./?4 ;/0/ Programmer
FUNCTION OF VARIABLES
.1/R/lT.c
/
MIN.
VALUE
3y1~
-'
3 Z;o 4/t(lA~S
/25 Ep1P/C'!;1'I!?c::.::?
/
9(~11/S
'p4y ,. :':7/c.;"
Sex -(/-/er.r7??/e) ,(2-/)h:l/e))
~oc/t?/ SecL/"''';'/~
(.3-Ir"?/CKer)
nd/:)'/.6~/7
f
Efl"?p/o~ee sldr~:s -(/-C//J;o,v; (2- ';''''~t:lc.e'''.J.,(t3-r7or?'Ur7ior?)
rv/I -hme),c4-r1t:>r1-ur7/t:>"j j:Jdr! hh/e))(2)-:'r-~r'n}/r,~I-~d)
cJ1
Slock
A/ST;k"z;J
/ U SZ / V;O xx. xx.
r;j
..E I 0
¢
M~/?/Ao/ s/oc,t;. e!ec!uc/'a;'?s
Nt/A
Z I
af
(/rJ//ec/ a//et.?/ c/edvcr/Clr7S
;1ISTCK
It) X)(.XX
c'/6?civc//on
L / ?;a XX-XX 1~11¢ CL'c;cL /? t./ /Y) be".,
¢ ~ffJ~t!"r t?/ ~e.f:;k's e?;7//.J£oye./
¢
AlWKAfP .£ / 0
,A/J1/~R£) r /
0 ¢
rd ¥vn-lbe/i f!),/ ('~Jt"'~e"-:s ~a/C/
Nt/M
1;0 /7
N'xIWPS I / 0 /7
4JRTD R ~ 0
yrD
R 1;0
NKAI'Pr .E /
X)<>(X~
t
~)()C")(.XIC
¢
¢
¢.¢1¢
~~(/J
.f="'eqle,......~/
eX
~tI'Y1,P~/o,,~ oS
Sldl'e exe~l1p~/~/.;IScpt../Qr;er-f,,-d'tl!e /n/or/77Q",.on(i)9;-~$S/2)r£7;(.3)rIC/l-,
('1)Loc:m.><',(SJ~IC.4 WQ9..es~ (~)s/ck t9,.t:1tj.. ....
Yet7/'1-t~-~~;~ /,,/a"A'7q~Qn(i)9"'''SS7(?) FIe ~(.3) F17)
(4) /,fC/J aJilt:leS (S)s/ck poc.J~ ('It) spec. A,(';I) spec. B~
(/J)/Qc. rlfl)(~(9) rtej7. hrs.,) (/"J o r hrs~(I/) ~~,.,GtlS /'r.$'.,
'1Z)"'e!1' er"s:, (/.iJ 0
erns ... {/t4) bD"''''$ err7S.
r
*Mode: I = integer, R = real,D = decimal, A = alphabetic
36
--
Section
35
Initialize
Variables
Setup
Name
Field
Retrieve
Company
Name
Yes
Initialize
Trade
Association
Information
Setup
Quarterto-Date
Information
Check the
Data for
Reasonableness
37
Subsections
Page
I
41
20
10
Section
35
Subsections
20
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
I
10
Page
42
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYROLL SYSTEM - FILE CREATION
C----- JOB NAME
PAYOl
PAYOl
C----- JOB NUMBER
PAYOl
C----PAYOl
C.R.KLICK
C----- PROGRAMMER
PAYOl
12123/67
C----- DATE CODED
PAYOl
DATE
UPDATED
C----PAYOl
C----RECORDS PAYOl
FILE RECORD NO. OF
FILE
C----NUMBER LENGTH RECORDS PER SECTORPAYOl
NAME
C----PAYOl
NONE
C----- INPUT FILES
PAYOl
C----PAYOl
250
2
1
160
1. COLFP
C----- OUTPUT FILES
PAYOl
90
2
2
160
2. WVAFP
C----PAYOl
2
200
3. MNCFP
3
160
C----PAYOl
4
50
4.
LBOFP
160
2
C----PAYOl
150
2
5
160
5. LBTFP
C----PAYOl
2
30
6
160
6. LMCFP
C----PAYOl
25
6
3
106
7. PINFO
C----PAYOl
250
320
101
1
8. INDXl
C----PAYOl
90
320
102
9. INDX2
1
C----PAYOl
200
320
103
1
10. INDX3
C----PAYOl
104
50
320
1
11. INDX4
C----PAYOl
105
150
320
12. INDX5
1
C----PAYOl
30
320
13. INDX6
106
1
C-----PAYOl
C----PAYOl
C----PAYOl
C----- ALLOCATE ARRAY STORAGE
PAYOl
C----PAVOl
INTEGER COMP(16)
PAYOl
DIMENSI~N FIBRE(8), INDEX(250) , ISUPP(13) , I TOT ( 11), NAME (9) ,
PAYOl
NSSAN(3), QRTD(6), YTD(141
1
PAYOl
C----PAYOl
C----- DEFINE THE FILES FOR THIS PROGRAM AS DESCRIBED ABOVE, AND
PAYOl
C----- EQUIVALENCE THE VARIAALES FOR NEXT RECORD NUMBER
PAYOl
C----PAYOl
1(2S0,160,U.ICOL), 2(90,160,U,IWVA),
DEFINE FILE
PAYOl
3(200,16Q,U.MUNC), 4(50,160,U,LBO),
1
S(lSO.160,U.LBT), 6(30,160,U.LMC). 2S(6tl06,UdC), PAVOl
2
lOl(250,1,U,IN1). 102(90tl,U,IN2), 103(200tl,U,IN3) ,PAVOl
3
l04(50tl,UtIN4) , lO5(150.1.U.IN5), 106(30tl,UtIN6) PAYOl
4
PAYOl
EQUIVALENCE (ICOL,IWVA,MUNC.LBO,LBT.LMCI,
PAYOl
(IN1,IN2,IN3,IN4.IN5,IN61
1
-PAYOl
C----PAYOl
C----II
FOR
*** IOCS(CARD,
PAYOl PROGRAM
* NAME PAYOl
* ONE WORD INTEGERS
* EXTENDED PRECISION
* LIST ALL
~
- ---- ---
,DISK)
KEYBOARD
- ----
- - - - ---- --- - - - - - - --- - - -- -- -- - - --
-----------
38
I
Section
35
PAYOl PROGRAM
•
•
•
•
•
•
•
•
•
•
•
PAGE
C----- INITIALIZE VARIABLES
C----- CKMAX=25000.
IC=l
ICOl-l
IN n-o
IN1-l
IPD-O
DO 68 1.. 1.13
68 ISUPPIII=O
ITOTIll-111
ITOTl2 I =620
ITOT 13 I =620
ITOT151=625
ITOT161=626
ITOT171=627
ITOT181=628
ITOT(9)-0
ITOTIll)-635
lYRHR=O
NADWH-O
NCHCK=O
NCUDO=O
NMISC=O
NSTKD=O
NWKMP-O
NWKPD=O
QRTDISI=O.
QRTO(6)=0.
DO 69 Mal.14
69 YTDIMI=O.
•
C-----------------------------C----C----- READ PLANT NUMBER, WEEK NUMBER. AND CHECK NUMBER
C----- READ(6.41 NOPLT
•
C----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - C----C----- CALCULATE THE FILE NUMBER OF THE INDEX FOR THE CURRENT PLANT.
•
•
•
•
READ(6,4) IWEEK
READI6.5IICHCK
4 FORMAT Ill)
5 FORMATII21
C----- FINISH INITIALIZING VARIABLES - ITOTI41. ITOT(10). LST
c-----
IND=lOO + NOPLT
GO TO (Cl.52,53,54.55.561,NOPLT
51 LST=250
GO TO 57
39
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
-PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
-PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
Subsections
Page
I
43
20
10
Section
35
Subsections
20
I
10
Page
44
PAYOl PROGRAM
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
PAGE 03
52 LST=90
ITOT(10)=O
GO TO 58
53 Lsr=200
ITOTI10)"1723
58 ITOr I 4) =621
GO TO 60
54 LST=50
GO TO 51
55 LST=150
ITOT(4)=0
GO TO 59
56 LST::30
57 ITOT(4)=622
59 ITOT(10)=0
PAYOl
PAY01
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
- - - - - - -PAYOl
PAYOl
C----- SETUP THE .NAME FIELD AND RETRIEVE THE COMPANY NAME.
PAYOl
PAYOl
60 READI6,)1 NAME
PAYOl
3 FORMATI9A2)
PAYOl
READI6,ll COMP
PAYOl
1 FORMATI16AZ)
PAYOl
- - - - - - -PAYOl
PAYOl
C----- READ ALL INFORMATION FOR ONE EMPLOYEE AND CHECK FOR LAST CARD.
PAYOl
PAYOl
500 READI2,ZI NUM, NRATE, NSEX, NSSAN, NXMPF, YTD(1), YTDIZJ, YTD(3), PAYOl
1
YTDI81, NCU, NINS. NSTCK, NUA. NDUES. MAR. K
PAYOl
Z FORMATI1X.I4.13.Il.13.IZ.14.1X,IZ,F7.0,3F5.0.15.Z14.I3,I4.6X,IZ. PAYOl
1
8X.Ill
PAYOl
PAYOl
C----- IS THIS THE LAST CARD
PAYOl
C----- YES - GO TO 600
PAYOl
C----- NO - GO TO 10
PAYOl
PAYOl
IFIK-9) 10,600,10
PAYOl
- - - - -PAYOl
PAYOl
C----- SETUP EMPLOYEE STATUS CODE. STATE EXEMPTIONS, AND Q-T-D INFORMATNPAYOl
PAYOl
10 NSTAS=l
PAYOl
NXMPS=NXMPF
PAYOl
QRTDIll=YTDlll
PAYOl
QRTDIZI=YTD(3)
PAYOl
QRTD(31=YTDIZ)
PAYOl
QRTO(4)=YTDI8)
PAYOl
-PAYOl
PAYOl
C----C----C-----
C----- - - - - - - - - - - - - - - - - - - C----C----C-----
C----C----C----C-----
------
C----- - - - - - - C-----
40
Section
35
PAY01 PROGRAM
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
C----- IFCMARI
101,101,100
100 IFCMAR-21 102,102tlOl
101 MAR:1
CALL STACK
102 IF(NDUESI 103,104,106
103 NDUES=O
CALL STACK
104 NSTAS=3
106 IFCNOPLT-31 120,115,120
115 NDUES=O
120 IFCNSEXI 109,109,107
107 IF CNSEX-3 I 110,108 tl09
108 NSTAS=2
NSEX=2
GO TO 110
109 NSEX=2
CALL STACK
c----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - C----c----CREATE THE INDEX ENTRY FOR THIS EMPLOYEE AND WRITE HIS RECORD
C----- ONTO THE DISK. THEN GO BACK TO THE READ STATEMENT TO GET
C----- INFORMATION ON THE NEXT EMPLOYEE.
C----110INDEXCICOLI=NUM
C----C----- WRITE TO THE DISK.
C----- WRITECNOPLT'ICOLI NUM,
NAME, NSSAN, NSTAS, NDUES, NwKMP. NWKPD,
MAR. NXMPF. NXMPS, NSEX, NRATE, YTD, QRTD.
LYRHR, NCU, NCUDD, NCHCK, NADWH, NSTCK, NINS,
NMISC, NUA, NSTKD, ISUPP, INIT. IPD
C----C----- GO BACK FOR ANOTHER EMPLOYEE'S INFORMATION
C----- GO TO 500
C----- - - - - - - - - ---- ---- ---- -- - -- --C----C----- LAST CARD HAS BEEN READ.
C----- INITIALIZE THE TRADE ASSOCIATION INFORMATION.
C----600 DO
650 1=1.8
650 FIBRECII·O.
c----c----C----c-----
Page
I
45
20
PAGE 04
C----- EDIT MARITAL STATUS, UNION DUES DEDUCTION, SEX CODE, AND IF
C----- NECESSARY, MODIFY EMPLOYEE STATUS CODE.
1
2
3
Subsections
-----------
-- -- - -- - --
WRITE THE INDEX OF EMPLOYEES FOR THIS PLANT TO DISK.
41
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAYOl
PAVOl
PAVOl
PAY01
PAVOl
PAVOl
PAVOl
PAVOl
PAVOl
PAVOl
PAVOl
PAVOl
PAYOl
-PAVOl
PAVOl
PAVOl
PAYOl
PAVOl
PAYOl
PAYOl
PAVOl
PAVOl
PAYOl
PAVOl
PAYOl
PAVOl
PAYOl
PAYOl
PAVOl
PAVOl
PAVOl
-PAVOl
PAVOl
PAYOl
PAVOl
PAVOl
PAVOl
PAYOl
-PAYOl
PAYOl
PAYOl
PAYOl
10
Section
35
Subsections
20
1
Page
46
10
PAGE 05
PAYOl PROGRAM
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
I
PAYOl
PAYOl
(INDEX( I) ,1-l,LAST)
-PAYOl
PAYOl
C----- WR I TE 1~E RECORD FOR TH IS PLANT TO 01 SK, THE NUMBER OF EMPLOYEES PAYOl
PAYOl
C----- I N THE PLAN T TO THE I NO EX AND STOP.
PAYOl
PAYOl
WRITE(25'NOPt..Tl eOMP, ICHCK, IWEEK, FIBRE. ITOT, CKMAX
PAYOl
PAYOl
WRITE(IND'LST) LAST
-PAYOl
PAYOl
PAYOl
C----- STOP
PAYOl
PAYOl
CALL EXIT
PAYOl
END
LAST-ICOL-l
WRITE( IND'l)
C----C----- - - - - - - - - - - - - -
------------- ---
C-----
e----C----C----C-----
-- -- ------------- -
VARIABLE ALLOCATIONS
I COL -005B
IWVA -005B
.005C
-005e
IN5
IN6
COMP -OlEl
NSSAN·01Dl
NMISC .. 01EA NSTKO·01EB
NUM
-01F4 NRATE-01FS
K
-OlFE NSTAS"OlFF
MUNC -005B
FIBRE-0072
,,01E2
IC
N\f/KMP-01EC
NSEX .01F6
NXMPS-0200
STATEMENT ALLOCATIONS
4
-022F
5
·0231
=0343
54
58
"0346
101
-030B
102
"O"lEl
.. 0461
=0417
600
110
3
55
103
650
.023,
"0351
-03E7
=0465
-005B
LBO
QRTD -0084
INIT "01E3
NWKPD.O lED
NXMPF=O 1F7
LAST "0201
LBT
YTD
IPD
M
NCU
-005B
-OOAE
·01E4
.. OlEE
=01F8
LMC
-005B
CKMAX·OOBl
-01E5
I
NOPL T.O lEF
NINS .01F9
-005C
Ii'll
INDEX-01AD
LYRHR.01E6
IWEEK-01FO
NSTCK=OlFA
-005C
IN2
ISUPP-01BA
NAOWH=01E7
ICHCK"OlFl
-OlFB
NUA
IN3
·005C
ITOT "01C5
NCHCK·01E8
INO .01F2
NOUES=OlFC
IN4 "005C
NAME ·OlCE
NCUOO=Ol E9
LST
-01F3
MAR
-OlFO
-0236
-0350
"03EO
2
57
106
-0239
-0361
-03Fl
68
59
115
69
60
120
51
500
107
52
10
108
53
100
109
1
56
104
*0280
-0367
.03F7
·02F7
-0360
-03FB
-0327
-0379
-03FF
·0320
-03AB
·0407
·0339
-0305
-0411
FEATURES SUPPORTED
ONE WORD INTEGERS
EXTENDED PRECISION
10CS
CALLED SUBPROGRAMS
ELOX
ELD
STACK
SDAF
SDAI
SOCOM
I
TYPEZ
SOl
ESTOX
SOF
ESTO
SOIX
REAL CONSTANT S
.250000000E 05,,020E
.OOOOOOOOOE 00-0211
INTEGER CONSTI HS
1-0214
0"021$
14.021E
6-021F
622-0229
30·0228
13"0216
100·0220
2"022A
CORE REQUIREMENTS FOR PAYOl
VARIABLES
COMMON
0
526
111-0217
250-0221
9·022B
PROGRAM
SREO
SFIO
SIOAI
SIOFX
SIOI
SUBSC
CAROZ
SOFIO
SOWt VALUE
MIN.
VALUE
~o
Program Name
Add
~
I
ICLCJ<
I
I 250
I ! x>"e
/
/;0/(/1/7,1-
(NAME.l~LOCK
NO. CARDS
f--
/
(/ I X E:Q PAY02f----!.
1/ JOB
I.
SOURCE OF INPUT:
DISPOSITION OF OUTPUT:
l-
/. CL?r-d t../?~C/f TOr- a svccess/u/ PA y/~ ec7/T run.
2. .o/$K /?;t;sr b~ lZt::1.;f1.r-t:)// ~:Sk /'rt?rr? P4YO/.
/. #~le PI'?6'l'C/OCk:. /t.0. Ctlr45 &?re ~/&e///; /}/e 8.
£ . .£)/sk yo ~t::. ~S'(!;r::Z.. //7 PAYO~ (;U/I/en S~t!::IU/d
6~ C
w
0
ci
Z
0..0
~
Cl
~
PAYROLL
Application
S t:~ MAX.
'0 ~:::> VALUE
MIN.
VALUE
Program Name
Date
Chonges 10 lite {;'1e
No.
PA YO.3
8/Z .5/~ 7
C.~.~//cl(
Programmer
FUNCTION OF VARIABLES
-
-
E~t/iJ/Qlel7f
-
-
£ ~(//J/(1le'7f 1'0 IeoL
T
250
3¢
/vIox/mt//l'l /it.//T7be, 01'
/
r
3¢¢¢
¢
Th/s years O'cC(..I/f1(1/ollorl
I
/
7
2-
I
)jor.:ldl 5101(/$ - (/ - .s//1J/~), ( 2- mor,;'ed.)
MI.INC
I
I
N
-
-
£"~t//J/o/e/'1f fo ICOL
NADWfl
I
I
T
XXXX
¢
A del/I;or/ol wilhold//,g
A2 9
T
-
-
£ml'lo;tee
LB7"
I
/
N
L,Me
I
/
N
LST
I
/
L YRfiR
:l
MAR
NAME
f"a ICOL
II Cl!11
records
of hoW"S
-I'//e
1/7 0
(J.;crhd for ,/ocaf;'on ?0,J
0/770 t//7
f
e
II/CliCK
J:
/
T
xxxxx
¢
C nee J.~ /7t//7'l.oe, (.loSea' .f'or -/11/'s e 117f' IO.;t1 e e
NCU
I
/
T
XX.XX
¢
Cred/I- t//1/017 c/edt/cf/ol7 amot/nf
)./CI.IDD
Z
I
T
xxx.XX
¢
MOr7f/,j cred/of (//7/on
ND{/['S
I
I
T
xx,xx
¢
(/11;017
NEW
I
I
I
xxx.XX
¢
New
NINS
I
/
T
XX.XX
¢
I/7st/ral7c~
NMI5C
I
/
T
xxxx
¢
IvI/.sc~/lol7eo(..ls
NOPLT
I
I
I
~
I
P/cll'7i /7(/mber
NRAT£
I
I
T 3.¢¢
NSEX
I
/
T
NSSAN
L
3
T
I
II/STAS
*Mode: I
=
I
integer, R
T
;j
/,25
I
j/Wt1Ss ~ d'sits
5
I
dt/€£
d~d(/cf/()/7s
(/n d/l77es)
de ducl/ons om 0 (./1'7;'
/"f"rmol-/ol7 (/sed in eho17gc S'p~cJ;ed iJ!J coole (ICIi/lG)
dedt/clion
01770(.1171
~ due 1/017..5
O/77o(.ln.f
Em"%gee. ;;0!l rale
.5e x - (1- -f4!l77o/e), (z- /77Q/~), ( 3 - fr(/cKer j
Soc/oj
5 ect./r't'ly
/1(/mt;t!r
.£m'p/ogee .sft:d'tlS,(f-(.Il7ion); (2-l'rucker), (3-/TOI7-(/I7;on
.t,,// flme\(4-ilcn-vn/ol7)/,Qrl flmt:)J (.5-f~rmi;7ld~d) )
= real, D = decimal, A = alphabetic
58
Section
35
VARIABLES
I
ISM
Subsections
20
I
10
1130 COMPUTING SYSTEM
VARIABLE SUMMARY SHEET
0...
'" ::::EIw::::>
0 1-0...
"0
NAME
*w
0
'0
0
ci
~O
MIN.
VALUE
Date
e/2 5/ ~ 7
No.PAY03
Programmer
PAYROLL.
Application
MAX.
;:::~ VALUE
:s:
Program Name
Chan~e.s
~
10
I/;e
F//e
::::E
z
115TCK
I
/
7
XX.XX
¢
Stoc.k d4dvc!/O/l amov17f
NsrK.O
I
I
T
XX.XX
¢
)40171/,1!:I slock ded(/ci/ol7s
J./tJA
I
/
T
XX.XX
¢
t/n/tecl o'p'peo/ deduCT/on Ql71o///71
NtJM
Z
/
FUNCTION OF VARIABLES
7- XX.XX
,
xxx
IvtJM13
I
I
7
NWKh1P
I
/
T XXXX
IVWI
501
=0247
="lCB
=037C
=u3eo
=045E
=0521
FEATURES SUPPORTED
ONE WORD INTEGERS
EXTENDED PRECISION
10CS
CALLED SUBPROGRAMS
STACK
ELO
ESTO
SDWRT
SDCOM
SDA I
ESTOX
SOAF
TYPEl
SO IX
SREO
SO I
SWRT
SCOMP
SFIO
SIOAI
SIOI
SUBSC
CAROl
SDF 10
SDRt::O
REAL CONSTANTS
.OOOOOOOOOE 00 .. 01C8
INTEGER ~ONSTANTS
1-01CB
2-01CC
1000-01D5
16=0106
CORE REQUIREMENTS FOR PAY03
COMMON
0
VARIABLES
100-01CD
14"0107
456
250=01CE
6"0108
PROGRAM
90-01CF
0 .. 0109
200,,0100
13.010A
50=0101
858
END OF COMPILATION
L---
I
-
-
66
150=01D2
9=0104
Section
35
•
•
•
.
Subsections
20
I
JOB
XEQ PAY03
2
*FILES(1.COLFPI.(2.WVAFPI.(3.MNCFPI .(4.LBOFPI.(5,LBTFPI ,(6,LMCFPI.
*F I LE 5 ( 101, I NDX 11 , ( 102, r NDX2 I , ( 103. I NDX3 I , ( 104, I NDX4) , ( 105. I NDX 5 I , ( 106, I NDx6 I
II
/1
1
10010100261
10040600004
10160500002
10170100261
9
Input cards
67
I
10
Page
71
Section
35
Subsections
20
•
•
1
10
Page
72
JOB
xEQ PAVO!
2
*FILESC1.COLFP).12.WVAFP).C3.MNCFP).14.LBOFP).CS.LBTFP).C6.LMCFP).
*FILESCI01.INDX11.CI02.INDX2),CI03.INDX3I,II04.INOX4).CIOS.INDXS).II06.INDX6J
II
II
~
-
Printer output
68
Section
Subsections
Page
I
73
35
20
IBM 1130 MACHINE SETUP SHEET
PROGRAM
NAME:
CAdr.7.J1&S /~ rAe /3/'c:'"
/
PROGRAM
NUMBER:
APPROXI MATE
RUNNING TIME:
PROGRAM
DESCRIPTION:
TYPE OF PAPER
PRINTER
DISKS
NO. OF COPIES
S~~~4rd
DRIVE NUMBER:
0
CARTRIDGE
Pt79r(:J//
SWITCH
UP
DOWN
CARRIAGE TAPE
/
10:
SWITCH
SETTINGS
PAY03
S!4"dqrd'
1
#o/'7e
3
2
X X IXX
N~/?e
SWITCH
UP
DOWN
SWITCH
DOWN
(
9
q
(
(MORE
q
(
':Forfi7r7 e
/~/q~
(CHANGE.
e4ch p/t/?/Jl"
4'/ jJ,h
C"""''''J~S'
A/O/7:>
0
!I
("')
!:!'.
0
O·
:J
CII
1 ~~4,5 6 7 8'9 0 1 234567 8901 234567890
Ii"!'
'
I
,
I
-:]
~
iJ
Q)
CO
(1)
jxi
[X
I
DC
dr-
...1
i"!1
71,
.{j:
2l
.I'i
(
'
'
I I
I
+
I I
--.- ... -------.-- - - .. --------------.---~-----c_ ..---------------------~-----------+1,
IBM,
I
I
INTERNATiONAL BUSINESS MACHINES CORPORATION
LINE DESCRIPTION
fiELD HEADINGS/WORD MARKS
PRINTER SPACING CHART
IBM 407, 408, 409, '1403, 1404, 1443, and 2203
8 lines Per Inch
IBM 1403 Models 1 & 4 ~
I
1h-T.,-,,,,,-!-,,rTT·l-TTT+,..,..-rTTT.,-,rn,..,-rrr,,,rl-,-. . .,-',TTl-+-rTTT-"-rTT+-.rTTT
rT IT
I
Print Span:
IBM 407, 408,
-n T !T HTT ... nnnnTi
409, and 1403 Models 6 and 7
.
IBM 1403 Models 2, 3, 5, N 1 and 1404
TtnTH
IBM 1443 Models 1, N1, an? 2203
o
2
3
4
5
6
7
8
9
:10
11
i: 1 234 5678901 2345678901 2 3 4567 890 1 234567'890 1 2345678,90 1 2'3,4 5 6 7 8.9 0 1 2 34 5i6 789 0 1 23 456789 0 1 234,567 890 1 234567890 1 2345678901 23456789 O'
I I
3
I
I'
I'
II
'...,
Section
35
VARIABLES
I
IBM
Subsections
20
I
10
1130 COMPUTING SYSTEM
VARIABLE SUMMARY SHEET
II>
"0
NAME
0
a..
2~
w:;:)
~
~a..
:s: ;:::5
'0
2
z
*
0
ci
~O
~
A
R .3
{J
AD
f.(
T
3
MIN.
VALUE
PA r R 0 L L
SYS7eM Date 8/29/&7
Program NameCq Ie U/d t'-ohS &. P/RNO. PAYOI-Pr~ff~~er
Application
MAX.
VALUE
.,
FUNCTION OF VARIABLES
tJ.fj(J _.f1JfI
UJ'6ltl
~()r z~ro ,6q ICll7ce
check
xxx.xx rI,;; UseJ to cdlcu/dte overt/me rd1-e
XXx ¢I¢¢ (J.t'ed fa cd/l'IJ/a'te overT/me rei re
XXAA.~ ti. ¢ (#
A .f r~r- - 'fa x /n c "I'M e
AoR£t; R 3 7
lirA x f{ 3
8
R 3 T ~.~rj '.;;$ IJsel A,,.. z ere it/It/l'Jet:: cAecK
8NERN R .3 0 xxx.)()( (I.. ¢I/J B (lhl.lS erJrn/ngs
8NHR,S p. 3 IsO )()(X. ")(JC ¢.¢; goII v or J h 0 IJ r oS
r'
R 3 0 ¢.¢~ ¢.¢¢ Vse d .f1or zero-Ja Idhce ch~ck
,.
I...~--
~i,.(Jt; ¢.~¢ Md ximuht c IJ ack dmtJtll) 1- I'()r d 1',' Ie
CKMAX I~ J'I
CNE:T P, 3 0 Xj(){X.xx ~. ¢ fi lie -r qmo (lifT 0 -I /~di~idt.ld / C' ,,~C k
CcMP A2 16 1#0
C oPl'pci ~ y n t:/I?'fe
p
R 3 0 ().¢¢ ~, ;¢ Use' !'or zer"O- bd 1411c~ checi
-
ER/'IaS R 3
.,
XI.
)(.1((
-
~ .. (j~
Flcd fdKdb/e wdfes
~. ¢f/; Tt"dJe drroc;d f;o/7 re porTS
¢,¢¢ Gross dhffJV"1" ~.; /I?I/~/'(/d / c4~cK
8 0 XXXlCtQ
f'lBRC R ~
'''''R.0...t S p. 3 0 xxx. )(l(
'?
l-l (J i, f) Y R 3 0 xx:)()( ¢. ¢rJ Il1d/vt'J(ldl's- Aol/tldY ,Ptly
I
1 I ;
U.red /n DO lo()p
I I N
E1v/vcilenr -I-~ IN1
Ie
se1- -I't1r
.TCIfCI{ 1 I
8e9'/""' tnf c h(!'ct 11(/I1!J~1"" wAe/1 wr,-f,;'f ciecir
led~h ,.. (In
ICLCf( 1 I T 6
I
h ~.r -t- c.£"d,cd res de civcT/O;1 noT mdde
I"t:!,'v,",!v d l's /l1slIrd../)c e de dvc f /011
I 0 xx
LdsT rec(>;-d I1vmj;,~,.. ,-"'d-{,,'/e
I r 250 5
I"/'-,,id vd l's hU·SC. d@dvc -f'ion
I 0 'Xxx XX ¢
I r I " /~I h'/e nt/m6~r C)/ ;ntleJ( A,r d /1(/1'11: f#.,JoO
2!O
-r
xxx x
/~¢¢
Inei@K fa ,/dl?7-
I
r
1#'
/ tI /
I,,/eJr jl,'/e '1u",6er
/(!l¢
¢
t/n;" 11
1.
Recorcll1v"",ber /,., /i1.dekt!lS ~Q ~h')~/(},.pt!'
I
I
I I
I
I I
J I
I I
,
PAYROLL· SYSrcM Date8/2~7
~
)('1" k
Program NameC
0
MAX.
~ I-c..
'0 ;:::5 VALUE
ci ~O
z
FUNCTION OF VARIABLES
1 I T 5¢¢
IPA~~ I
I 0 20
IPD
1 I 0 ¢
ISTC'1( I I 0 2p"
(J
Ove,,...Ti'me
I
/?t.fe ,,(/"'" /, e;-
¢
Intl'/ Cd"" e s
(/;
In,lv//cJr2/'s s~cK d'edvc 7-/,;;-'7
S t/f'?le 1?'1 e 11 rd I .s /c k.. ~tly
II T /723
¢
¢
IUA
1 I 0 3rJt/J
~
Iv/)
1 I
1
;rOT 1
/3
0
xxx.~
15,;
¢
IVAAT :I I 0 S~¢ ¢J
rWEEI< 1 I T S
2
IWVI1 I I N I<
0
r
1<0
I I
1 I 1
Al I 0
kOD£
I .31- 1
IfAIfD
...
kPLNT J. I
.I
Program
~
rOTR7
.lSIIPP
PA YR 0 L L sYS'TGM DateS!2,!G7
NameC?dk(/4~~~! ~ &NO·?Ar~?~~f:tmer
Application
MIN.
VALUE
-
I
LBr
I I N
'-/N~
1
I
I N
1~cOVr1r
,s1""d to tI.f ,,~
c.>,~/e
nv,.".6e",. ~r
/ed'3fe-
enertl/
r @co,.d
l~
9'
L/7//V /dtlci /1-
c A'd r/
];;c/;'v /cI~ d/'.f (/n/c;n
A veY'd tje ~dy
/41//111 -ro
rd
"Te
/1/ee~ .;J I' n7 ""r.4
£1"" /Y rl Ie .., -r -r-() ..L COL-
¢
9
¢
Lds-I-C4rd 7-re..rr
dr dJI- c" rd / TesT
C.C. 8 ¢,- ;i'7!c'
5
¢
Specl'd/ e arn/n.f J
,
9
-
-
I T 50
,/
SP~C/~)/
l
./
c"
e
c·~/e
/JVm~er
//d/7-r
J. fis7
edr/?ll)t7s
reCDrd 1J1IJ7).Jer
-
Ey'~/"Yci'/ehT
¢
L/~e
-
/4
'l d?/Glc7'i '&)n
cll/~S deduc. -!-/o Yl
<1
¢
¢
1
..,.
xxx ¢
I
LAST
LBO
proces.s/~
'pdt rtfr~
c1 v/ 'rei /e 117'
70
""/# .TeOL-
CQ"h-r
*Mode: I = integer, R = real, D = decimal, A = alphabetic
73
JcoL
/1'7
~!e
Page
77
Section
35
Page
Subsections
20
I
10
78
VARIABLES
IBM
I
1130 COMPUTING SYSTEM
VARIABLE SUMMARY SHEET
a..
'" ~ Iw::>
0 1-0..
MAX.
s:
-0
NAME
*w
0
a
~
'0 ~~ VALUE
c:i ~o
z
ApplicationPAYR
Program Name
-
I
N
I.. ()CAI-
.J.
.".
I
0 xxxx
-
0
0
¢
¢
~()
2
/
MAR
Iv!(,/NC
1 I N
1'/'I?
No.
Date
8/29/~
-
}
~O 'tX xx
orHIfS
R 3
Ql?7D
R. .i..
18 0
,~;'ERN
1< .3 0
XXXl(.)(lc
de dvcr/on
Un; tr::J A 'pp~t:i /
C/o,/( n (/ 11?6f!: r
()i'
NUhlber
week~
N(.Ihiber 0'; weeks-
Fe de rei I
~""f'lo/,el
?Q/c"/
~xemo1"/ons
,.
S-rdre ex~,-n/,ii'"'' s-
0 xxx. Xl( ¢. ¢¢ Over-r,'n1 Ii?
OTHeR A. 3 0 x>O:
I, ~~
SPA
I? .3 I
R 3 r
xxxx.x,<
¢.¢¢
S/(~ ,Ptly
S"l'ec ,'(j/ eql"l"1//l1! t:lccvMI, I'er
)(XX!(,XJ(
/.¢¢
S!,f?c/cl/ C'irnil1j.f' dccvm/
3
R '9 I
XX)(.~'(
¢.¢¢
jjP~C /d
I eel r/1/".1.r
~
It)l.X)(X)()(.
~.¢¢
C!s@1
f6 -r-tJ
SPS
SPSC't...
r
R
0
7r.X
1 I 0
IA)(8L.
R 3
*Mode: I
=
integer. R
r
= real.
.5l'ec;'d /
/"r Il1d,
e qrh/'lf'·(
Ft!!der a I ;v/ "fAl;ol/,~.1 701.'(
¢# ¢¢ 7d )(' ct J,/~ e Q r /11'1'1 l'.s
xxxxx ~.¢¢
'X x x.X)(;
reI I
D = decimal. A
= alphabetic
75
/I"]d.
Section
35
Subsections
Page
I
80
20
10
VARIABLES
I
IBM
1130 COMPUTING SYSTEM
VARIABLE SUMMARY SHEET
VI
~
21w:::J
1-0.. MAX.
0
ito
"0
(;
NAME
*W
0
0
2
a..
....0
z
;:::~ VALUE
-rN£T
7-07"
R
21
6~
PArf( 0 L L S YSr£k/DateS/2 '/67
Gcl/cvlt'lf/c?/'i.J
Program Name
0
~
,/. /?ftca4
fJ'If
No.
'1(KX)(XX.
Xiii:
¢,¢¢
XXXX"Xl(.
¢. t/J rf; TbTd/ /"lei
r/J. ¢ (j To-t-d I drrc) y
¢.¢¢ 8cJl1V1,f J e? tJ r to fd. I 1'1"'/1,""
d. ¢ cd o T ~ ~cJl' rot:SP
riD
err!>"""
-to-rd /
·/;cJ();-S ~rror
'1-0 tq /
XXXlCt.)(l(
(7) s?et:'. 8) (8) Icc. +q'K , (9)rej" /irs,
0/) ~t:l17 v'J ~ r,f (/z.)/'"e~- ('1'"/1 S') (1.1)
(0)
0<;) b()"~J ~r/1s.
=
integer, R
= real, D = decimal, A = alphabetic
76
(3)FICA,
OT 1t~$1
or ~rl?.!
*Mode: I
doc.
'p~y
i?O()Y's
-f/rr. e
I
R. 3 0 XX)(.)Ol 1(;. ;CP Ref- ;'~I,/r~ err ",.. -to Td /
R ,;;;;;;. 0 ~X)t.X)( ¢. ¢ r). S?ec;q/ edrl1/n r f
Yedr-To-dtire ;",.f'"rmd'ti·o". (l)yrOSSJ (z.);t:;1j
14- IjO
R 92
f/J. ~¢ (4)F"/('A
IVdtf~s, (S)slck ,.pdy, (6)Sl'ec. A,
'tl?£~
//I'CK
Programmer
FUNCTION OF VARIABLES
X)(,c""xx.
~
.;,J
Application
~
R 3 I'"~
R 3 7
r~li'S'
MIN.
VALUE
Section
35
Initialize
Plant
Variables
Initialize
Variables
Initialize
Individual
Variables
Subsections
Page
I
81
20
Calculate
Any
Special
Earnings
Calculate
Net
Earnings
Calculate
Overtime
Earnings
Check Net
Against Max.
Check Amt.
Sum Regular,
OT and Bonus
Earnings to
Earnings
Update
Year·to·Date
Information
Update Past
Quarter's
Earnings
Update Quarter·
to·Date
Information
Calculate
FICA
Update
Plant
Totals
Calculate
Federal
Income
Tax
Locate
Employee
in Index
Calculate
Local Tax,
If Any
Calculate
Regular
Earnings
Calculate
Net
Earnings
Calculate
Bonus
Earnings
If applicable,
calculate
voluntary
deductions
77
Setup
Control
Information
10
Section
35
Subsections
20
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
I
10
Page
82
II FOR
PAY04
IOCSICARD,TYPEWRITER,KEYBOARD,1132 PRINTER,DISK)
PAY04
PAY04
LIST ALL
PAY04
** PAY04 PROGRAM
PAY04
* NAME PAY04
PAY04
* ONE WORD INTEGERS
PAY04
* EXTENDED PRECISION
PAYROLL SYSTEM - CALCULATIONS + PAYROLL REGISTER PAY04
C----- JOB NAME
PAY04
PAY04
C----- JOB NUMBER
PAY04
C.R.KLICK
PAY04
C----- PROGRAMMER
01/13/68
PAY04
C----- DATE CODED
PAY04
C----- DATE UPDATED
PAY04
RECORDS PAY04
FILE
FILE RECORD NO. OF
NAME
NUMBER LENGTH RECORDS PER SECTORPAY04
250
2
PAY04
1. COLFP
160
C----- INPUT FILES
1
2. WVAFP
2
PAY04
2
90
160
3. MNCFP
200
2
PAY04
160
3
4. LBOFP
2
PAY04
4
160
50
5. LBTFP
5
2
PAY04
150
160
6. LMCFP
2
PAY04
6
30
160
7. PINFO
25
3
PAY04
106
6
320
PAY04
8. INDX1
101
1
250
320
PAY04
9. INDX2
1
90
102
10. INDX3
320
PAY04
103
200
1
104
320
PAY04
11. INDX4
1
50
320
PAY04
12. INDX5
105
1
150
13. INDX6
320
PAY04
1
30
106
PAY04
PAY04
160
250
1
2
C----- OUTPUT FILES -- 1. COLFP
PAY04
C----2. WVAFP
90
2
2
160
PAY04
C----3. MNCFP
3
160
200
2
PAY04
4
160
2
C----4. LBOFP
50
PAY04
C----5. LBTFP
5
160
150
2
PAY04
6
160
30
2
C----6. LMCFP
PAY04
25
3
C----7. PINFO
106
6
-PAY04
PAY04
PAY04
C----- ALLOCATE ARRAY STORAGE.
PAY04
PAY04
INTEGER COMP(16), TAX
DIMENSION FIBRE(S)' IDATE(3), INDEX(250), ISUPP(13), ITOTlll)'
PAY04
1
KODE(3), NAME(9), NDWK(3), NSSAN(3), QRTD(6), SPECL(3), PAY04
PAY04
2
TOT(21), YTD(14)
PAY04
PAY04
DEFINE THE FILES FOR THIS PROGRAM AS DESCRIBED ABOVE, AND
PAY04
EQUIVALENCE THE VARIABLES FOR NEXT RECORD NuMBER.
PAY04
11250,160,U,ICOL), 2190,160,U,IWVA),
PAY04
DEFINE FILE
31200,160,U,MUNC),4150,160,U,LBO),
PAY04
1
*
*
C-----
C----C----C----C----C----C----C----C----C----C----C----C----C----C----C----C-----
C----- - - - - - - - C----C----C----C----C----C-----
78
Section
35
PAY04 PROGRAM
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Subsections
20
PAGE 02
5(150,160,U,LBT),6(30,160,U.LMC),
101(250,1,u.IN1), 102(90,1,U.IN2),
104(50,1,U,IN4). 105(150,1,U,IN5),
IICOL.IWVA,MUNC,LBO,LBT,LMC).
IIN1,IN2,IN3,IN4.IN5.IN6)
- - - -
2516.l06.U.IC). PAY04
2
l031200tl.UtlN3) ,PAY04
3
106(30.l.U.IN6) PAY04
4
EQUIVALENCE
PAY04
PAY04
1
- - - - - - - - -PAY04
PAY04
DEFINE ~N ARITHMETIC STATEMENT FOR HALF ADJUSTING.
PAY04
PAY04
PHILIBET)=WHOLE( IBET + 5.) I 100.)
PAY04
- - - - - - - - - - - - - - -PAY04
PAY04
C----- INITIALIZE VARIABLES
PAY04
PAY04
ICOl=1
PAY04
IN1=1
PAY04
T=O.
PAY04
XTOT=O.
PAY04
XBN=O.
PAY04
XREG=O.
PAY04
XSP=O.
PAY04
DO 50 1=1.21
PAY04
50 TOTII)=O.
PAY04
IPAGE=O
PAY04
PAY04
LINE-50
- - - - - - - - - - -PAY04
PAY04
C----- READ PLANT NUMBER. DATE, AND CONTROL TOTALS
PAY04
PAY04
99999 READ(2.1) NOPLT, IDATE. NDWK. TOTRG. TOTOT. TOTBN, TOTSP, KARD
PAY04
1 FORMATII1.6A2.7X.4F7.0,31X.Il)
PAY04
PAY04
C----- VALIDATE KARD AND NOPLT.
PAY04
PAY04
C----- IF VALID
- 60
PAY04
C----- IF INVALID - 55
PAY04
IFCKARD) 55.51,55
PAY04
51 IF(NOPLT) 55,55,52
PAY04
52 IFCNOPLT-6) 60,60,55
PAY04
PAY04
C----- FIRST CARD IS INVALID.
PAY04
PAY04
55 WRITE(1,2)
PAY04
PAY04
2 FORMAT('CHECK CC 1 AND 80 ON FIRST CARD')
PAUSE 1
PAY04
GO TO 99999
PAY04
- - - - - - - - - - - - - - - -PAY04
PAY04
C----- READ THE PLANT INFORMATION RECORD FROM DISK.
PAY04
C----- - - - - - - - - - - - - - - - - - - - C----C----C----C----- - - - - - - - - - - - - - - - - - C----C-----
C----- - - - - - - - - - - - - - - - - - - - - - C----C----C-----
C-----
C----C-----
C----- - - - . - - - - - - - - - - - - C-----
79
I
10
Page
83
Section
35
Subsections
20
1
10
Page
84
PAY04 PROGRAM
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
PAGE
C----60 READ(25'NOPLT) COMP, ICHCK, IWEEK, FIBRE, ITOT, CKMAX
C----- - - - - - - - - - - - - - - - - - - - - - - - - - - C----- WRITE THE PLANT INFORMATION FOR CONTROL PURPOSES AND ACCEPT
C-----
PAY04
PAY04
-PAY04
PAY04
ANY PAY04
C----- CHANGES TO IT THRU DATA SWITCH SETTINGS.
PAY04
PAY04
62 WRITE(l,]) COMP, IDATE, ICHCK, IWEEK, NDWK, CKMAX
PAY04
] FORMAT(//16A2,3A2/'CHECK NO 'I5/'WEEK NO 'I1/'W/E '3A2/'NET MAX' PAY04
1
F6.0//'MAXIMUM CHECK AMOUNT MAY BE CHANGED BY SW ITCH 14. 'PAY04
2
/ 'SWITCH 15 WILL CHANGE THE CHECK NO AND THE WEEK NO. SET' PAY04
3
'SWITCHES'/'REQUESTEP AND PRESS START')
PAY04
PAUSE 1111
PAY04
CALL DATSWCl5,I)
PAY04
GO TO (70, 71 It I
PAY04
70 WRlTEC1,4)
PAY04
4 FORMATI'ENTER CHECK NO. FIVE DIGITS')
PAY04
READI6,22) ICHCK
PAY04
22 FORMAT(IS)
PAY04
WRlTECl,23)
PAY04
23 FORMATC'ENTER WEEK NO. ONE DIGIT')
PAY04
READC6,2'4) IWEEK
PAY04
24 FORMAT C11 )
PAY04
GO TO 62
PAY04
71 CALL DATSWC14,1)
PAY04
GO TO 172,75)'1
PAY04
72 WRITE(l,25)
PAY04
25 FORMATC'ENTER MAXIMUM CHECK AMOUNT. FIVE DIGITS')
PAY04
READC6,211 CKMAX
PAV04
21 FORMATIF5.0)
PAV04
GO TO 62
PAY04
- - - - - - - - - - - - - - - - - - -PAY04
PAV04
C----- INITIALIZE PLANT VARIABLES
PAV04
PAY04
75 INDX=NOPLT + 100
PAV04
GO TO (76.77.78,79,80,81),NOPLT
PAY04
76 ILST=250
PAY04
GO TO 83
PAY04
77 ILST"90
PAV04
GO TO 83
PAV04
78 ILST=200
PAY04
GO TO 83
PAY04
79 lLST=50
PAV04
GO TO 83
PAV04
80 ILST-150
PAY04
GO TO 83
PAY04
81 ILST=30
PAY04
-PAY04
C-----
C----- - - - - - - - - - - - - - C----c-----
c----- - - - -
80
Section
35
PAGE 04
PAY04 PROGRAM
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
C----C----- READ THE EMPLOYEE INDEX FOR THIS PLANT.
C----83 READ(INDX'ILST) LAST
READ(INDX'1) (INDEX( II. I-l.LASTI
C----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - C----C----- READ A WEEKLY EMPLOYEE RECORD.
C----90 READC2.5) KPLNT. ICLCK, RGHRS. OTHRS. BNHRS. (KODEII).SPECLCI).
1
5 FORMATCl1.I3.FS.O.F4.0,FS.O.I1,F6.0,2CIl,FS.OI,42X,I11
C----_ _ _ _ _1=1.3).
_ _ _ _KARD
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _
C----C----- INITIALIZE INDIVIDUAL VARIABLES
C----- ADREG=O.
AD-O.
HOLDY=O.
IFILL-O
KO=16448
OTHER-O.
SICK"O.
SPA"'O.
SPB=O.
TAX-O.
VACA=O.
C----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - C----C----- LAST CARD CHECK AND VALIDATE PLANT NUMBER
C----- IF KAR~ EQUALS 6. PROCESS IT.
C----- IF KAR[ EQUALS 9, LAST CARD
C----- OTHERWISE. ERROR
C----- IFCKARD
- 6) 100,110,103
103 IFCKARD - 9) 100.500,100
C----C----- PLANT NUMBER
C----110 IFIKPLNT - NOPLTI
100,105.100
100 WRITEC1.61 KPLNT, ICLCK
6 FORMAT('CHECK CARD WITH CLOCK NUMBER '11,131
PAUSE 100
GO TO 90
C----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - C----C----- LOCATE EMPLOYEE IN INDEX
C----105 ICLCK=ICLCK + KPLNT * 1000
81
PAY04
PAY04
PAY04
PAY04
PAY04
-PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
-PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAV04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
-PAY04
PAY04
PAY04
PAV04
PAY04
PAY04
PAY04
PAY04
PAY04
PAV04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
-PAY04
PAY04
PAY04
PAY04
PAY04
Subsections
20
I
10
Page
85
Section
35
Subsections
20
I
10
Page
86
PAY04 PROGRAM
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
PAGE OS
DO 115 IND=l.LAST
IFI INDEX( IND) - ICLCK) l15tl25.11S
115 CONTINUE
PAY04
PAY04
PAY04
PAY04
PROGRAt COMES THRU HERE ONLY WHEN NO MATCH FOUND.
PAY04
PAY04
WRITEll,7) ICLeK
PAY04
7 FORMATI'CLOCK NO '14' IS NOT IN THE FILE')
PAY04
PAY04
C----- UPDATE ERROR TOTALS
PAY04
PAY04
120 XREGaXREG + RGHRS
PAY04
XTOTaXTOT + OTHRS
PAY04
XBN-XBN + BNHRS
PAY04
XSP.XSp + SPEe~ll) + SPECL(2) + SPEC~(3)
PAY04
CALL STACK
PAY04
GO TO 90
PAY04
- - - - - -PAY04
PAY04
PAY04
READ THE EMPLOYEE RECORD FROM DiSk AND VALIDATE CLOCK NUMBER.
PAY04
125 READINOPLT'IND) NUM. NAME. NSSAN. NSTAS. NDUES. NWKMP. NWKPD. MAR.PAY04
NXMPF, NXMPS. NSEX. NRATE. YTD. aRTD. LYRHR. NCU. PAY04
1
2
NCUDD. NCHCK. NADWH. NSTCK. NINS. NMISC. NUA.
PAY04
3
NSTKD. I SUPP. IN IT
PAY04
PAY04
C----- VALIDATE CLOCK NUMBER
PAY04
PAY04
VALID
- 136
C----- INVALID - 135
PAY04
PAY04
PAY04
IFINUM - ICLeK) 135.136.135
135 WRITE(1,8) NUM. ICLCK
PAY04
8 FORMATI'FILE NO '14' AND INDEX NO '14' DO NOT AGREE')
PAY04
GO TO 120
PAY04
- - - - - - - - - - -PAY04
PAY04
C----- CALCULATE REGU~AR EARNINGS AND HALF ADJUST
PAY04
PAY04
136 RGERN.PHILIRGHRS * NRATE)
PAY04
- - - - - - - - - - - - - - - -PAY04
PAY04
C----- CALCULATE BONUS EARNINGS AND HALF ADJUST
PAY04
PAY04
BNERN.Pt ILIBNHRS * NRATE)
PAY04
-PAY04
PAY04
C----- CALCULATE ANY SPECIAL EARNINGS. USE CODE TO DETERMINE TYPE OF
PAY04
C----- EARNINGS.
KODE
TYPE
KODE
TYPE
PAY04
PAY04
C----1
SPA
5
SPB*NRATE
C----e----e----e----C-----
C----- - - - - - - - - - - - - - - - - - - - - - - - e----C----C----C----C----C-----
C----- - - - - - - - - C----c----C----- - - - - --------C----c-----
c-----
C-----
82
Section
35
PAGE 06
PAY04 PROGRAM
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
C----C----C----C----C----- DO
600
601
602
603
610
604
605
606
607
608
611
609
139
2
3
4
SPB
SPB*NRATE
SPB*NRATE
6
7
8
9
139 1=1,3
K=KODEtI)
IF tK) 100d39,600
GO TO t601,602,6U3.604,605,606,607,608,609),K
AD=SPECLtI)
OTHER=OTHER + AD
SPA=SPA + AD
KO=-3776
GO TO 139
OTHER=OTHER + SPECLtl)
SPB=SPA + SPECLtl)
KO=-352(
GO TO 139
KO=-3264
OTHER=PHILtSPECLII) * NRATE)
SPB-SPB + SPECLII)
GO TO 139
KO=-3008
GO TO 610
KO=-2752
GO TO 610
VACA=SPECLII)
SPB=SPB + VACA
GO TO 139
SICK=SPECLII)
GO TO 139
HOLDY=8. * NRATE
AD=AD + HOLDY
SPB=SPB + HOLDY
ADREG=800.
GO TO 139
HOLDY=16. * NRATE
AD=AD + HOLDY / 2.
GO TO 611
CONTINUE
C----- - - - - - - - - - - - - - - - - - - - - - C----C----- CALCULATE OVERTIME EARNINGS IF APPLI CABLE.
C----- TO DETERMINE APPLICABILITY.
C----- IFINSTAS-2) 141,131,141
C----- NOT APPLICABLE. USE STANDARD RATE.
C----C-----
83
VACA
SICK
HOLDY
HOLDY * 2
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
-PAY04
PAY04
AND HOURS PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
--- ----USE
~TATUS
Subsections
20
I
10
Page
87
Section
35
Subsections
20
I
10
Page
88
PAGE 01
PAY04 PROGRAM
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
137 IOTRT-NRATE
GO TO 150
C----141 IFCRGHRSI 137.137.142
C----C----- OVERTIME APPLIES. CALCULATE OVERTIME RATE.
C----142 IOtRT=(RGERN + BNERN + ADI * 100. I CRGHRS + ADREGI + 0.5
C----C----- CALCULATE OVERTIME PAY
C----150 OTERN=PHILCOTHRS * IOTRTI
C-----------· ---------------------C----C----- SUM REGULAR. O.T •• AND BONUS EARNINGS
C----- ERNGS=RGERN + BNERN + OTERN
C----- - - - - - - - - - - - - - - - - ---------C----C----- CALCULATE AVERAGE RATE AND UPDATE LAST QUARTER AVERAGES.
C----- IFIRGHRSI 143.143.144
143 IVRAT=NRATE
GO TO 160
144 IVRAT=ERNGS * 100. I RGHRS
160 DO 165 1-1.12
165 ISUPP( Il=ISUPP( 1+1)
ISUPP(l~I=IOTRT
C----- - - - . - - - - - - - - - - - - - - - - - - - - - - - - - - - C----- CALCULATE FICA TAXABLE EARNINGS
C----C----- ERNGS=ERNGS + VACA + HOLDY + OTHER
C----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - C----C----- CALCULATE FICA AND GROSS PAY AND TAXABLE PAY
C----- IFICA=0.044 * ERNGS + 0.5
IFIIFICA + YTD(2) - 29040.)185.180.180
180 IFICA=29040. - YTO(2)
C----185 GROSS=ERNGS + SICK
C----- TAXBL=GROSS - NXMPF * 1350.
C----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - C----C----- CALCULATE FEDERAL INCOME TAX
C----- CALL ITITAXBL.MAR.TAX)
84
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
-PAY04
PAY04
PAY04
PAY04
PAY04
-PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
-PAY04
PAY04
PAY04
PAY04
PAY04
-PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
-PAY04
PAY04
PAY04
PAY04
PAY04
Section
Subsections
Page
20
89
35
PAY04 PROGRAM
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
PAGE 08
TAX"TAX + NADWH
PAY04
-PAY04
PAY04
PAY04
PAY04
PAY04
230 LOCAL"PHILIGROSSI
PAY04
GO TO 250
PAY04
PAY04
235 I=12S0. * NXMPS + O.~
LOCAL"O.OlOS * IGROSS-Il
PAY04
GO TO 250
PAY04
240 IF(NXMPSI 241.241.242
PAY04
241 LOCAL-0.02 * GROSS
PAY04
GO TO 250
PAY04
242 I=NXMPS * 153S.5 + 961.5
PAY04
LOCAL.IGROSS - II * 0.02
PAY04
250 IFILOCAL) 246.247.247
PAY04
246 LOCAL-O
PAY04
-PAY04
PAY04
CALCULATE NET EARNINGS
PAY04
PAY04
247 ATAX-GROSS - TAX - LOCAL - IFICA
PAY04
-PAY04
PAY04
C----- CALCULATE VOLI INT ARY DEDUCT IONS.
PAY04
PAY04
INITIALIZE.
PAY04
PAY04
IUD=O
IUA=O
PAY04
ISTCK-O
PAY04
PAY04
IINS"O
ICU=O
PAY04
IMISC=O
PAY04
PAY04
C----- IF THE EMPLOYEE RECEIVES SICK PAY. VOLUNTARY DEDUCTIONS ARE NOT PAY04
PAY04
TAKEN.
PAY04
C----IF(SICK) 252.253.252
PAY04
252 CNET=AT~X
PAY04
PAY04
GO TO 3t S
PAY04
PAY04
OTHERWISE. DEDUCTIONS NECESSARY ARE TAKEN.
PAY04
C----- TAKE UN I ON DUES ACCORDING TO PLANT
PAY04
253 IFIIWEEK - 31 255.255.251
PAY04
PAY04
251 IFINOPLT - 31 280.255.280
255 IF(NSTAS - 21 260,260,282
PAY04
260 IFIGROSS - VACAI 261,295.261
PAY04
C--------------------------C----C----- COMPUTE LOCAL TAX BY PLANT LOCATION
C----- GO TO 1230.235.240.230.246.2301.NOPLT
C----- - - - - ------------------------C----C----C----C----- - - - - - - - - - -------------------C----C----C-----
C----C-----
C----C----C-----
~
-
85
I
\
I
I
1
10
Section
35
Subsections
Page
I
90
20
10
PAGE 09
PAY04 PROGRAM
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAV04
PAY04
CHARITIBLE CONTRIBUTIONS
PAY04
PAY04
IFI.WEEK - 2) 290,285.285
PAY04
IFINUA - 10000) 286,290.290
PAY04
IUA=NUA
PAY04
NUA=NUA + 10000
PAY04
GO TO 295
PAY04
IUA=O
PAY04
TAKE STOCK. INSURANCE, CREDIT UNION. AND MISCELLANEOUS DEDUCTlONSPAY04
PAY04
PAY04
ISTCK=NSTCK
PAY04
IINS=NINS
PAY04
ICU=NCU
PAY04
IMISC=NMISC
- - - - - - - - - -PAY04
PAY04
PAY04
CALCULATE NET. AT ALL TIMES CHECKING THAT NET IS NOT NEGATIVE.
PAY04
PAY04
IFIATAX - IUD) 300.310.310
PAY04
IFINOPLT - 3) 305.301.305
PAY04
NOUES- NDUES - IUD
PAY04
GO TO 309
PAY04
NOUES=NOUES - 10000
PAY04
IUO=O
PAY04
IFILL=l
PAY04
CNET=ATAX - IUD
PAY04
IFleNET - IINS) 320.325,325
PAY04
IINS=O
PAY04
IFILL=2
PAY04
CNET=CNET - IINS
PAY04
IFICNET - ISTCK) 330.335,335
PAY04
ISTCK=O
PAY04
IFILL=3
PAY04
CNET=CNET - ISTCK
PAY04
NSTKO=NSTKD + ISTCK
PAY04
IFICNET - leU) 340,345,345
261 GO TO 1265.265.275.265.265.280).NOPLT
265 IFINOUES - 10000) 270.270.280
270 IUO=NDUES + INIT
NOUES=NOUES + INIT + 10000
INIT=O
GO TO 290
275 IUO-PHILIGROSS - VACA) + INIT
NOUES=NOUES + IUD
INIT=O
GO TO 282
280 IUO-O
C----C----C----282
285
286
290
C----C----C----295
C----- - - - - - - - - C----C----C----300
301
305
309
310
320
325
330
335
86
Section
Subsections
35
PAY04 PROGRAM
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
PAGE 10
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
PAY04
-PAY04
PAYC4
C----- CHECK NET AGAINST MAXIMUM CHECK AMOUNT AND AGAINST A MINIMUM OF PAY04
C----- ONE DOLLAR
PAY04
PAY04
C---"366 IFICKMAX - CNETI 367.368.368
PAY04
367 WRtTE(1.121 CNET. ICLCK
PAY04
12 FORMAT('NET OF ' F7.0' FOR CLOCK NO '141
PAY04
GO TO 120
PAY04
368 IF(CNET - 1001 370.375.375
PAY04
370 TAX=TAX + CNET
PAY04
CNETIIO
PAY04
IFILL.7
PAY04
-PAY04
PAY04
C----- UPDATE YEAR-TO-DATE INFORMATION
PAY04
PAY04
375 YTO(ll-YTO(ll + GROSS
PAY04
YTO(2)=YTO(21 + IFICA
PAY04
YTOI31=YTO(31 + TAX
PAY04
YTO(4)=YTO(4) + ERNGS
PAY04
YTO(5)=YTOIS) + SICK
PAY04
YTO(6)=YTO(6) + SPA
PAY04
YTO(7)=YTO(7) + SPB
PAY04
YTO(81=YTO(8) + LOCAL
PAY04
YTO(9)=YTO(9) + RGHRS
PAY04
YTO(10)·YtO(10) + OTHRS
PAY04
YTO(11)-YTO(11) + BNHRS
PAV04
YTO(12)=YTO(12) + RGERN
PAY04
YTO(131=YTO(13) + OTERN
PAY04
YTO(14)=YTO(14) + BNERN
PAY04
-PAY04
PAY04
e----- UPDATE QUARTER-TO-DATE INFORMATION
PAY04
QRTO(l)=QRTO(l) + GROSS
PAY04
QRTO(2)sQRTOCZ) + TAX
PAY04
340 ICU"O
IFILL.4
345 CNET=CNET - ICU
NCUOO=NCUOO + (leu I 101
IF(CNET .. IUAI 350.355.355
350 IUA-O
IFILL=5
NUA-NUA - 10000
355 eNET=CNET - IUA
IF(CNET - IMISCI 360.365.365
360 IMISC-O
IFILL .. 6
365 CNET=CNET - IMISC
c----- . . - - - - - - - - - - C-----
C----- - - - - - - C----c---..-
----------------------
C----- - .. - - - - - - - - - - .. - - - - - - .. - - - - - - - - - - - C-----
87
20
I
10
Page
91
Section
35
Subsections
Page
I
92
20
10
PAGE 11
PAY04 PROGRAt
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
PAY04
PAYC4
PAY04
+ ERNGS
PAY04
+ SICK
- - - - - - - - - - - - - - - - - - - - -PAY04
PAY04
PAY04
C----- UPDATE PLANT TOTALS
PAY04
PAY04
TOTlll=TOTI11 + RGHRS
PAY04
TOTI21=TOTI21 + RGERN
PAY04
TOTI31 = TOTI31 + OTHRS
PAY04
TOT(4)=TOTI4) + OTERN
PAY04
TOTI51=TOT(SI + BNHRS
PAY04
TOT(6)=TOT(6) + BNERN
PAY04
TOTI71=TOT(7) + OTHER
PAY04
TOTI81=TOTISI + HOLDY
PAY04
TOTI91=TOTI91 + VACA
PAY04
TOTI101=TOTI101 + SICK
PAY04
TOTIlll=TOTllll + CNET
PAY04
TOTI121-TOTI121 + TAX
PAV04
TOT(13)=TOTI131 + IFICA
PAY04
TOT(14)=TOTI141 + LOCAL
PAY04
TOTI151=TOTI15' + ICU
PAY04
TOT(16)=TOTI161 + IUD
PAY04
TOT(171=TOTI171 + IUA
PAY04
TOT(18)=TOTI181 + ISTCK
PAY04
TOT(19)-TOTI19) + IMISC
PAY04
TOT1201-TOT1201 + IINS
PAY04
TOT(21)=TOTI211 + GROSS
c--.. . -- - - - - - .. - - - - -PAY04
PAY04
PAY04
C----- SUM sPECIAL EARNINGS. SUM DEDUCTIONS. AND ExTEND THE EMPLOYEE
PAY04
C----- WEEKLY CARD
PAY04
PAY04
T-T + SPECLlll + SPECLI21 + SPECL(31
PAY04
IDED=IINS + ISTCK + IUA + IMISC
WRITEI2.91 NRATE. GROSS. CNET. TAX. IFICA. LOCAL. ICU. IUD. IDED PAY04
PAY04
9 FORMAT(, 1x.!3.2F6.0.I5.414.151
- - - - - - - .. - - - -PAY04
C----~
PAY04
C----- SETUP CONTROL INFORMATION. AND WRITE UPDATED EMPLOYEE RECORD BACKPAY04
PAY04
C----- TO THE DISK.
PAY04
PAY04
LYRHR=LYRHR + RGHRS
PAY04
NWKPD=NWKPO + 1
PAY04
IPD-l
PAY04
PAY04
WRITEINOPLT'INDI NUM. NAME. N$SAN. NSTAS. NDUES. NWKMP. NWKPD.
1
MAR. NXMPF. NXMPS. NSEX. NRATE. YTD. QRTD. LYRHR. NCU. NCUDD. PAY04
QRTD(3)=QRTOI31
QRTD(4)=QRTOI41
QRTD(5)=QRTO(SI
QRTDI61=QRTOI61
+ IFICA
+ LOCAL
C----- - - - - - - - - - C----C-----
C-----
C----C"----
---------------------
C-----
C-----
88
Section
35
PAY04 PROGRAM
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
2
3
4
5
C----C----C... ----
NCHCK. NADWH. NSTCK. NINS. NMISC. NUA. NSTKD. ISUPP. INIT.
IPD. IFILL. GROSS. IVRAT. IOTRT. RGHRS. OTHRS. BNHRS. RGERN.
OTERN. BNERN. OTHER. KO. HOLDY. VACA. SICK. CNET, IFICA. TAX.
LOCAL. ICU. IUA. IUD. 1 INS. ISTCI(. IMISC
GO BACK FOR ANOTHER WEEKLY EMPLOYEE CHECK.
GO TO 90
C----- - - - - - - - ~ - - - ~ - ~ - - - ~ - ~ - - - - - - - - - - - C----- WRITEi~E PAYROLL REGISTER.
C----C----500 ICNT=ICHCK
DO 510 I-1.LAST
READtNOPLT'II NUM. NAME. NSSAN. NSTAS. NDUES. NWKMP. NWKPD. MAR.
1
NXMPF. NXMPS. NSEX. NRATE. YTD. QRTD. LYRHR. NCU. NCUDD.
2
NCHCK. NADWH. NSTCK. NINS. NMISC. NUA. NSTKD. ISUPP. INIT.
3
IPD. IFILL. GROSS, IVRAT. IOTRT, RGHRS. OTHRS. BNHRS, RGERN.
4
OTERN, BNERN. OTHER, KO. HCLDY. VACA. SICK. CNET. IFICA. TAX.
5
LOCAL. ICU. IUA. IUD. IINS. ISTCK. IMISC
C----C----- CHECK
C----- IFtIPD
PAID INDICATOR TO SEE IF COMPUTATIONS WERE PERFORMED.
- 11 510.515,510
515 RGHRS=WHCLE(RGHRS + tRGHRS 1 ABSCRGHRSII * 0.51 / 100.
OTHRS=WHOLEIOTHRS + tOTHRS I ABSIOTHRSII * 0.51 1 100.
BNHRS=WHOLEIBNHRS + CBNHRS 1 ABSIBNHRSII * 0.51 / 100.
RGERN=WHCLEIRGERN + CRGERN 1 ABSCRGERN1) * 0.5) 1 100.
OTERN=WHCLEIOTERN + 10TERN 1 ABSIOTERN) I * 0.51 1 100.
BNERN=WHCLE(ANERN + (BNERN / ABS(BNERN» * 0.5) 1 100.
OTHER=WHOLE(OTHER + COTHER 1 ABSCOTHER)I * 0.51 1 100.
HCLDY=WHOLECHOLOY + CHOLDY 1 ABSCHCLDY» * 0.51 I 100.
VACA=WHOLECVACA + CVACA 1 ABSIVACA» * 0.5) 1 100.
SICK=WHOLEISICK + (SICK 1 ABSCSICK)1 * 0.5) 1 100.
GROSS=WHOLEtGRnsS + tGROSS 1 ABSCGROSS) I * 0.5) I 100.
CNET=WHOLEtCNET + (CNET 1 ABSICNETI) * 0.5) 1 100.
IF(LINE - 50) 385.380.380
380 IPAGE=IPAGE + 1
WRITE(3.19) COMP, NDWK, IPAGE
FORMAT('1'20x.'FACTORY PAYROLL'.5X,16A2.5X.'W/E ',A2,2C'-',A21.
19
1
10X.'PAGE NO ',12/1
WRlTE13,101
FORMATI' NUMBR'5X,'NAME'17X,'REG HRS OT HRS BNS HRS REG ERN OT
10
lERN BNS ERN SPECIAL HOLDAY VACATION
SICK
GROSS'I
WRlTE(3.20)
NET'I
FWT LOCAL C.U. U/D U/A INS STCK MISC
20 FORMAT(' FICA
LINE=O
385 WRITE(3,111 NUM, NAME. ICNT. RGHRS. OTHRS. BNHRS. RGERN. OTERN.
1
BNERN. KOt OTHER. HOLDY. VACA. SICK. GROSS. IFICA.
~
89
Subsections
Page
I
93
20
10
Section
35
Page
Subsections
20
I
10
94
PAY04 PROGRAM
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
PAGE 13
2
TAX, LOCAL, leu, IUD, IUA, IINS, ISTeK, IMISC, eNET
PAY04
FORMAT(/,lX,I4,2X,9AZ,15,6(ZX,F6.Z),lX,Al,5C2X,F6.2)/1x,I5,2X,815,PAY04
11
1
Fe.2)
PAY04
FIBRE(NSEX)=FIBREINSEXI + 1
PAY04
LINE=LINE + 3
PAY04
leNT=leNT + 1
PAY04
510 CONTINUE
PAY04
C----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - .PAY04
c----PAY04
e----- WRITE CONTROL TOTALS
PAY04
C----PAY04
TGRS=TOTIZ1)
PAY04
TNET=TOTI1I)
PAY04
WRITEI1,15) TOTRG, TOTOT, TOTBN, TOTSP
PAY04
15 FORMATI'INPUT TOTALS
',413X,FS.0»
PAY04
WRITEI1,16) TOTI1', TOTI31, TOTI51. T
PAY04
16 FORMATI'PROCESSED TOTALS '.4IFa.0,3XI I
PAY04
WRITEll,17) XREG, XTOT,XSN, XSP
PAY04
17 FORMATI'ERROR TOTALS
',413X,FS.OII
PAY04
A=TOTRG - TOTll) - XREG
PAY04
B=TOTOT - TOT(3) - XTOT
PAY04
~=TOTBN - TOT(5) - XBN
PAY04
D=TOTSP • T - XSP
PAY04
~RITEI1,18) A, B, e, 0
PAY04
18 FORMATI'THE DIFFERENeES',4(3x.Fa.0»
PAY04
C----- - - - - - - - - - • - ~ - - - - - - - - - - - -PAY04
C----PAY04
e----- wRITE THE PLANT GENERAL LE~G(R INFORMATION AFTER THE TOTAL LINE PAY04
e----PAY04
FIBRE(3)=FIBRE(3) + TOTll)
PAY04
FIBRE(4)=FIBRE(4) + TOT(2)
PAY04
FIBRE(5)=FIBRE(51 + TOTI31
PAY04
FIBRE(6)=FIBRE(61 + TOTI41
PAY04
FIBRE(71=FIBREI71 + TOT(9)
PAY04
FIBREISI=PIBREISI + TOTI81
PAY04
DO 520 1=1.10
PAY04
520 TOTIII=WHOLEITOTIII + ITOTIII / ABSITOTIIIII * 0.51 / 100.
PAY04
WRITEI3,l3) (TOT( I) ,1=ltlOI
PAY04
FORMAT(I,' ','FST LINE TOTAL'tlOFIO.2)
PAY04
13
TOTI211=-TOTI211
PAY04
IPAGE=IPAGE + 1
PAV04
WRITEI3,19) COMP, NDWK, IPAGE
PAY04
DO 5S0 1=1,11
PAY04
TOTCI+I01=·wHCLEITOTII+I0) + CTOTII+IOI/ABSITOTII+IOI I 1*0.51/100. PAY04
550 wRITEI3,14) ITOTIII, TOTll+101
PAY04
14 FORMATI/,20X.I4,5X,F9.Z1
PAY04
C----- - - - - - - - - - - - - - - - - - - - -PAY04
c----PAY04
c----- wRITE THE PLANT INFORMATION BACK TO DISK.
PAY04
L!----
90
\
Subsections
Section
C----v,'R I T E ( 25 ' NOP LT ) COMP,
TNET,
1
C----C----C----- STOP
C----CALL EXI T
C----- END
IWEEK, FIBRE,
ICHCK,
ICNT
ITOT, CKM"X,
- - ------- - - -------
-
10
PAGE 14
PAY04 PROGRAM
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
I
20
35
---
- -- - -
VARIABLE ALLOCA T IONS
IWVA "'005B
ICCL &005B
-005C
IN5
IN6
"'005C
XSP
XREG "0102
"'0105
ADREG=0120
A::>
=0123
ERNGS=O 141
OTERN"013E
=015F
=015C
0
C
COMP =02Al
TAX
=02A2
IN::>X =02AB
ILST =O,AC
NOUES=02B5
"WI<.r~P=028b
;,CHCK=02CO
,\iCUDD"02BF
I V~AT=02C,\
IOTRT=02C9
IPO
IDEO =02::>3
"0204
STATEMENT ALLOCA T IONS
",034A
PHIL =0338
1
=0412
=0420
5
b
16
-0515
15
"'0507
=05C5
bO
55
"05CO
=0649
80
79
"064F
=0738
120
"'0712
125
=0820
b05
=0819
60b
=08Ao
150
~ 43
"0894
: 42
241
=094C
"0955
=09C2
265
=09CC
2bl
~OA43
301
300
"OA30
=OABC
345
"OAA4
350
500
515
=009C
"OD1E
-
------- -------------
MUNC =005B
F18RE"'0072
TOTRG"O 108
HOLDY=0126
GROSS=0144
IDATE"016D
IC
"02A3
LAST =02AO
NwKPD"C2B7
NAOWH=02Cl
IFICA=02CB
ICN T "02D5
=0353
=0433
=0524
=050F
"Ob55
=077A
=0831
=08B3
=09b9
=0902
=OA4B
=OACA
=OE7A
2
7
17
b2
81
135
607
144
250
270
305
355
380
TGRS,
------ -
LBO
"005B
QRTD =0084
TOTOT=O lOB
CTHER=O 129
TAXBL=0147
INOEX=0267
-02A4
I
KPLNT=02AE
MAR
"02B8
NSTCK"02C2
LOCAL"02 CC
L8T
=0058
SPECL=0080
TOTBN=010E
SICK .. 012C
ATAX =014A
I SUPP .. 02 74
IPAGE=02A5
I CLCK=02AF
NXMPF"02B9
NINS "02C3
=02CO
IUD
PAY04
PAY04
PAY04
-PAY04
PAY04
PAY04
PAY04
PAY04
-PAY04
PAY04
LMC
"0058
TOT
-OOCC
TOTSP"Olll
SPA
=012F
CNET ",0140
I TOT =027F
LlNE :02Ab
IF ILL"02BO
NXMPS"02BA
NMISC"02C4
IUA
=02CE
)
=005C
INl
YTO
-00F6
CKMAX"'01l4
-0132
SPB
TGRS =0150
KOOE =0282
NOPLT,,02A7
,,02B1
KO
NSEX ,,02BB
,,02C5
NUA
IsTCK=02CF
=005C
IN2
T
=OOF9
RGHRS"'0117
VACA "0135
TNET "0153
NAME =028B
KARD =02A8
=0262
INO
NRATE:02BC
NSTKO"02Cb
I INS =0200
IN3
"'U05C
XTOT -OOFC
OTHRS"'Ol1A
RGERN"0138
A
-0156
NOWK =028E
ICHCK=02A9
NUM
"02B3
LYRHR"02BD
11'111 T =02C7
ICU
"'0201
IN4
"005C
=OOFF
XBN
BNHRS=O J.l0
BNERN"013B
=0159
B
NSSAN"0291
IvlEEK-02AA
NSTAS-02B4
NCU
"02BE
=02CIl
K
IMISC=02Dl
23
19
50
75
110
b02
139
185
253
2B5
325
3b7
550
24
"03F8
10
=0499
99999=05A2
76
=Ob37
100
"ObEO
=07F2
603
137
=0874
=092A
230
=09AF
251
286
=OA15
zOA7F
330
3b8
"OAF9
25
20
51
77
105
bl0
141
235
255
290
335
370
21
11
52
78
115
b04
142
240
2bO
295
340
375
)
-0365
"044b
=0532
=OHE
=Ob59
=0784
=083C
=OBBC
=0960
"09Eb
"OA51
=OAD9
=OE98
3
8
18
70
83
13b
b08
160
24b
275
309
3bO
385
4
12
13
71
90
600
bll
lb5
247
280
310
3b5
510
=0308
=045E
=0540
=Ob12
=0674
=07AF
=0849
=08CO
=0971
=OA05
=OA59
=OAEl
=OEE7
22
9
14
72
103
bOl
b09
180
252
282
320
36b
520
=03E8
=046E
=054E
"OblC
"Ob02
"07BC
"0855
"08FO
=09A3
=OA09
=OAbS
"OAE8
=OF9F
=03EA
=0477
=0589
=Ob27
=ObOA
=0708
=08bb
=090b
=09A9
=OAOF
=OA70
=OAEF
=103E
"03FA
=0400
"05BB
=Ob30
=06EC
"07F7
=087A
=0932
z09B5
=OA21
=OA87
:(JBOl
=0410
=04EE
=05BF
=Ob43
=0704
=0812
=087F
=0948
=09SB
-OA25
=OA9C
=OB12
)
FEATURES SUPPJRTEO
O",E
SOURCE OF INPUT:
4 tJrd'//t,PuC&4n1 t:I S4t-'Yes £Iu/ ePA Y/@ ed/t Cd/2
.e ihsl<
azu-rf
ae1 Payca/l ,.p's:J-
FOR PAUSES AND ERROR MESSAGES SEE ERROR RECOVERY SHEETS
95.
tY-A'ff
6ks-
10
Page
99
Cf)
c,.,
c.n
('D
(')
~
o·
::s
lil4
l\:)
INTERNATIONAL BUSINESS MACHINES CORPORATION
FIELD' HEADINGS/WORD MARKS
PRINTER' SPACING CHART
IBM 407, 40B, '409, 1403~ '1:404, 1443, and 2203'
8 Lines Per Inch
0
+-l
1
IBM 407,408, 409, and 1403 Models 6 and 7 -
;
(')
~
I-'
0
IBM 1403 Models 2, 3, 5, Nl and'I,404
C"
~
-
Print Span:
IBM 1403 Models 1 & 4
",:'
Cf)
c:
o·
::s
en
IBM 1443 Models 1, Nl, an!l 2,203
o
GL UE
;;=011101 ...
• 123 4 5 678 9
lJIa"'WN"
1
a 1 2 3 4 5 6 7 8 a 1 23 456 7
3
890 1 2345 6 7 89
4
6
7
8
9:
a 1 2 3 4 5 6 7 8 9 a 1 2 3 4 5 67 89 a 1 2 3 4 5 6 789 a 1 23 4iS 6 7 89 a 1 234 567 8 9 a 1 234 5 67 890 1
10
345 6 7 89
11
1 2 34 5 6
89 .'
~ a~~~~~~~~~~~~~~~~Jf~~~~~~~~~~~ff~~~~~rr~it~~it~~it~~it~~1J~~rr~itff~~~~l!fI
Ii :
~
1t!H+H+~+H~~-----tt~~:~++~H+++HH~++HH~++HH~++HH~++HH++++HH++++HH~~H+++~H+++~H+++HHH+++HH~++HH~++HHH+++HH++~HH+++R
l
__" _ "
li~~~~~~~~~:ti:~~~~~~~~~~~~~if~~~~~EE~lj~~~fE~jftE~fffE~~~~ff~~jt~~~~~~~lf~~~t!
i:~
~
!Hjl;.~::"
~
..
li'!;~:~ot..~.t.~.+.~.+-t=====~i~;~~++~~+t~~+t~4++t~++~~++~~++~~++tH~tt~~+t~1++t~4+tt~+++t~+++t~++~~++~~++~4+~
j!iH++H+H+H~r-----n:m:HH++++HH++++HH++++HH++++HH++~HH++~H+++~HH++~HK++HH~++HH~++HHH+++HH++~HH++++HH++HH~++HHH+++HH~~
___
~!
Ii :
37
38
~
39
I-'
0
0
'"C
Q)
CO
('D
Section
IBM
1
Page
I
101
20
35
VARIABLES
Subsections
10
1130 COMPUTING SYSTEM
VARIABLE SUMMARY SHEET
'"
a..
~f-
:s:
f-a..
z
~
-0
NAME
0
*w
Cl
0
~
w:::>
'0 ~~
ci ~O
A
R 3
0
..3
I? .3.
r
8,1/?"fJ"r/ ;f .3
MAX.
VALUE
MIN.
VALUE
Application
,0,4 Y/?~LL ....<:VS/cM
Program Name C.l;ec~
Ilk" ~'
7/79
Date
.9/0/~7
~
k'''C~
?4Y'tJ..~Programmer
No.
FUNCTION OF VARIABLES
lai11 iIi{lf;P
(J. (lrJI
t) ~xxx.~
Used /::Jr :zero bdk7/7Ce cAece:.
, # t/s-ed 4". .2~rt?
dr:JdJ
8~"'vf
/.J4Id,4~e Ch6'C.e..
e4//?//15S'
.3 I~Ll ~x.xx ¢r:1;1f g()I'lt./S' h~vr.5
8R
~ -"....." 0 XXX.Jj, ~l1tt' fo//7/c:J1'//CJ/p?~,¥"//?7u"-? e k e k t:?A?O~~,tCK,#/lx J? i3 T ~I~~ ~(J~ A/4J"/~L/m cj~d d#7.c?U4r ,i'or d ,,1/e
cl/£j k 3 0 ~tx Id/~ #81?lmoL//J1 d'/~c://v////d/ c.d'ed
18#'h'RS R
CCIJ4P ~2 /~ iI;o ;:18kJ£ R %~ t)
" ~I.h"",
IYVXXXXA
' ......
'V"
-
Com~p",~
nOrY7e
tftJ¢ Trdde 4SSoC.
re/o/"/s
XXx'XX ~tP~ GrosS- ?1mt?t://7/' c1/ /;,d0dC/tf//C/Jt!?c~
#OLLJY W 3 0 xX.XX ~~af Lb7d;'//c/t1/s AClh?/~0' PO'l?
v
'
V / T C/5ec/ //7 2)0 /00/
Z
r./{}
/ /1/ - L5;t//vak/J/ro .L/t/./
~
GRoss ~ 3
0
-
r
~o/'
58f
lTCh"Ck Z /
edch /'th7
LrCAIT f / tl ~X.YXX ~
VCOL L / T 250 .1
JCt/ I / 't/ ~x tP
ID4Tc ~e %~O IDt
I I 0 ~
ZD2 I / 0 xxxx 0
iJ
-./
..8e!Z~;;nl;';q eject /1t///7~e/' u/herJ UJr/I/II7Cj check
Se~C/e/7c!e ~~.6e,,- /br ,{ovr/?,:?/(SAou/c/
. Co
.respo ~
To Cnec;.L:::.. #
R.ecttPrd /?v/?l~r 0:1 e'fl?~/c;/pe ~'/eJ Sf!? r
bu.O/d"
f ._
l71'7~v-/~~~ cre~ '/ U/l/~/J de'dtlc~tf)/7
~'1 Q'q/e
.1ST Chec~
r7C/;??ber
.fdchd /7 C//r7.be.,..,
*Mode: I = integer, R = real, D = decimal, A = alphabetic
97
vp
Section
35
Subsections
Page
20
102
1
10
VARIABLES
IBM
1130 COMPUTING SYSTEM
J
VARIABLE SUMMARY SHEET
II>
a..
"E :EIw:::>
NAME
*w
~
Ca.. MAX.
C
'0
1-1- VALUE
:::>:::>
:E
Z
0
~
0
a.. 0
.l I t:l rlXXX
7
.T~/LL lL-- / T
.7.£#5 I / 0 XX
lTLST I / T 25"0
[TAfZ5C .L / k? xttfx
II/OX I / T /~0
I;..I/T Z / 0 lXX'x.xX
.INI I / T 250
f
I AI
-
I I AI
IN4 I I 11/ ZA/5 z I AI 7;1/0 z I AI / T s¢'~
Z07RT
2
.LPO I / 0
.zPN'T I / T 2
if5TC/C- lL / V ~~
l{2/P.P I 13 0 XXXI'I
Z;V3
z
..L-Tar
If/A
Date~/a7
P4YRt:?.lL SYSTEM
No,PAWS ~/C..£
rogrammer
Name checi:.. J1/r/h/1~
Application
Program
FUNCTION OF VARIABLES
IFZ?/;
TN!!
MIN.
VALUE
if
rZf
~
s¢
kd'v//u ///!5 ;Z?4 ~PfX
kJdC--L?/e-5 ~~c~~~ /)C'/ hlt?&
.Z"/;d/v/;'bt:?/S /a.su/d/l~e 4'E4'UC/;,~/7
Lt?sl record /?ul7Jber /n &'//:/e
~
.z;Jd/v/df/4,/$
/#/
Z/;&y r)k
/n/S"C.
dfo4i./c~Or7S"
/)t//)/~&/> /P./4/j//Jo. ~./..oo)
~
U/7/0/7 1/;;~2h"cJ/? ~e
.1
#cord//('/I"?t6~r/;".//}d'e)(e5 ~&~h:/~~k
qv;"vc?k/?/ ;Ib .2/V.I
-
-
q~//vdk/J/- /G? ZA./L
-
4U/Vc7ka/ -Td .IN.:!
Lj'd/ I/~k?/;l/ /t1 IN'.:I
q t//ya k4.//af/v:1'
¢
Ot/er~me ~dq/C7k
-
lI/Jdc4b .s6?bs t1//'~c/J,rd;;; j)/.tJ(!~'>57/;g cqc4
.
/
5///~t/ dtd? 511/1;fA..I1'd/J;;'d~ fJ/Jd$eskll!/~e/J o/"/;';t
v
"."
~ hd/j//dl/d/f s~c~ d'e'd'4/cQP/J
~
~
;'
{J'
.z VI T 1I723 ¢f
17 / k? 15t?t?
,/
fdppk;;)e/l~/
$;'::--" Pdt/
~c~O'/l/4U//lj/,/, ~r PP'~/1~ ~ /; tf~/lt1/'/.?/#4~
v
bd~//utf//J /M/*;;f d~~~~~/7
~
*Mode: I = integer, R = real, D = decimal, A = alphabetic
98
Section
I
IBM
Page
I
103
20
35
VARIABLES
Subsections
10
1130 COMPUTING SYSTEM
VARIABLE SUMMARY SHEET
V>
"0
(5
NAME
3:
~Iw:J
I-~
MAX.
'0 ;:::~ VALUE
ci ~O
*W
0
0
~
tJ #/ ;/
5 1
I /
/
-
-
/3
l£
/ AI
/ ~ WXIXXX
/ kJ ~,«
/ () ~
£4
~.,.-
/
.1p
V
/
tl xxxxx tJ
Ze:
£
/
()
:7
£~
Z
.t
/ CJ
I l)
/5/
.£ /
(/ ~j
c)
Date9/~/~7
PI'fY..(Jt:Jii SYSTE#/
Name CAd'~A ~/ I//Jq
Application
Program
NoAVd5
Ir: I/! 7 7 ~d(ttrx 0
J?/(/// 4/ Is £} ~Xi· JlJil7'P' JI/ 7 t:J ~t1fjm -
J//,4?A IJ/ s T ~ 0
/~ARf}
.t I .L 9
~
cJ
/(cJ
S ~
v:J/ /
i,45T £ / T xxx ~
u/l~/'Itfl#g', l~11''1,il1g5 fi1.PJ1hbb/~ kr'kJ
~/JJ/4'/'/AC7//d/¥/d// 7b//,/;/'&P.d?
/J,/'P?
C##~e// .5/Ck Pdt! It',.£l/'//Ii:t~4? /c/',?/
I
"
hr /dClJ/e'/9'/'&.5'5
A1~ ed/C7./ J/#?tt?6,i;/p P#L/
-~
lir ~~k/4'/#55'~~q
mr /d#J/~;;j/#~;It~
c.c: 8(7 4?r 1t?5/~,///i!?.5/
5)~c/// t?dri;/~t1s
Lt?sl re'ct?r~;UQ/~6'/' /4 /}k
*Mode: I = integer, R = real, D = decimal, A = alphabetic
99
Section
35
Subsections
Page
20
104
1
10
VARIABLES
J
IBM
1130 COMPUTING SYSTEM
VARIABLE SUMMARY SHEET
VI
NAME
*w
0
0
~
~
"E ~Iw:::>
~ I:::~ MAX.
'0
0
Z
1-1- VALUE
:::>:::>
~O
-
i~T
£ / #' -
/Jle-
E
/ II
1/
-
L't:C.4L Z / ~ IXXi
LY~;!~ .I / () ~~X
AI..4f
I I. ~() Z
#,f5~
W'I 7 T -
-
-
~
¢
I
-
r -
-
r W-
-
/l/4LJ11111 Z / 0 rx.~ ¢
#/1#£ lit 9 .l,tJ -
r
/ tJ 'IxXXX
A/CC/
~ / r,~ XX-XX
WCl/LJ?7 I / tJ 'Xxx. X
Ait')/ck
"Mode: I
f /
Program Name
.r;tJ
SY57EA4
a~.£- ~/1/~
Date
~~7
No.~)f;5 P~ff:~er
EI/U/Vd"n! II ..r(Jill
4'd/~/d .. ECt?i
~wlR/k/// h /GtJL
~.
NCd/ /Q'%
7)#/r
L.N%
dC.(U#p. ??nt!)~
_.L
,~~
,;~'::"-..
Mu dr A'd/,S
,jQIJI
1_,
#///-/y/ .sI~k5 - (/-S';;;9~)) (2-//I4/'r/;:'~
,Ed/i' /1'/45.1. C.st:)
Cd// ,#~S'..( (zero so/press)
q't//if/IJt'//:f ~ E coL'
~;~;/1t:1/ /P/dAJtJ/hd~ ~/J1/J///l/
Em/J/Pl/e'~ /1"$~
¢
¢
ac'; /.1##/.J&'/ P':7Ufr/, #5 6?~~9f:?c?
¢
Jit1I1IJ4 c/R~Itf//J/tf)/J ~ht?~~//5;:hddt~?J
XX,XX j!l
A/£)Jt/..I: ~& 3 .z;tJ ,1/cR' 'f1/ 7 0 ~~ ~CJtJ
A/ET .I ~/ 7 LJ ~/~ A/£TZ' ~ 7 C ~t?~ W£74 ~/ 7 ~. ~t:'~ 0
A!JI/t"j'
~YRt1/1
FUNCTION OF VARIABLES
II
#A5KZ; 1// 7
/
,#//#c
Application
~
!~Q'
I
MIN.
VALUE
c:;-~~;/&//1/;'/7 ~c/t/~~;:;/7.
C#;/;'/J" dl/t!'f ~/ut::'~t1/J
htl Pe?/'//d hk
E~/6?c/ 4e'/c~le~ /l(!!'/
.Edl/c;//Jt?/,#t?I'6'//If?/
= integer. R = real. D = decimal. A = alphabetic
100
Section
I
IBM
Page
I
105
20
35
VARIABLES
Subsections
10
1130 COMPUTING SYSTEM
VARIABLE SUMMARY SHEET
U'l
"C
NAME
*w
0
0
~
A//A!5
Ai#/.?c
~/j/
W,f'J47E
#J//TE
Als£x
#55/1;'/
W.sM5
AI-,7ce
Q..
~~
0 w:::>
~Q.. MAX.
'0 f::S VALUE
ci ~O
3:
MIN.
VALUE
Application
,L)A'Y~U'LL
Program Name
z z
xx. xx /
A/5'/,-<'0 I
1
0
!tit//!
f
/
it;/J xX-XX rP
}/!/Aj
Z
I
/
Date
No."tj4.
Programmer
OF VARIABLES
.l1J5t1rd/JCe kkCOO/7
ffi5Cd'Ik//~?J£/5 d4?/uC/?L:;/.l5
~4/ /7o/?/~er
E/JfF'~y~e /?d'tj /"t:?k?
ack /.1O'/d.Je~ /br /4 ~~/p/'//?~/:?~
.78X -(/-k,m4~J(?-~4k~L~rr.!/c~eij
.5&C/4/~Cd~//;/ /1t1/J1/~/
6?7~~ec)sr4rC/s-O-~/J/'t:J0/ ('z7/,ucKer ,J(.3 /ltl/N//J/f)
I'd// ~e(4-/JrJ/1-t//7ICJ/7PdrT-f//7?r?) /~-;e/'A?//Jd/ted
r
'/
5/f:;C-k ~~C~;4
#t7/?i//c, .51i:7?L ~~~~jJ//s-
O'/,?/kY/I//~d/ c/edvc~~/7
rt? ,{',vXX 1/// aCk..
0 XX
W#//JI?' £
/Y'J¥R'P£J I I 0 XX
;V.1A4~r ;- / ~t> /7
#AAf~5 I / 0 17
OT£R/V'
3 0 ~.«~
W
W3
aec-l:. ~/Y//;f/
FUNCTIO~
£ / l(t> XiXf I
.L / 0 Kxx.~ ~
;r / -; b 1
Z / ~t' A;ffl /.~5
I / ~T xxXx' ,t
.I
Z / l;t1 -3
L .3 ll.,tJ ~/IJIQtls 9th~ll.s
/
f / tJ 5
.£ / l1;tJ KX.XX ?
%#7
7JIt'l.5
~/c.£
~
5Y57E#
~
r
~ t://»t3e'/'
If
A&/%;ft1"/' ~/a/(!£?eks Rm~,0'Y'e;-7/
,
?
j!5
A$#Jtfe'/C7/tfV~eKs .;t?4/P/
~/e-/c:7/ c?x--eq?,obas
/
Sf-41/eex~/7¥hb/)5
~¢¢
Of/erhme e~,n//7q5
0 ~XK l#.~aI .5;oec/a/ e~//7/:a9:5
~7#ER
(J7}1ft?5 k 3 Vt' XXXX' iI~/' (JY~rhP1~ hCl(/~5
4'Od/: e'r-/t7-/d/e //J/br/7747/CJ//@groSs{.2)FIT
I47KlP R ~ 0 ~XX IfJyi V:?JfiCfif.4)
/ dc. jd x[S}r'/cA CV.4dl'?S.(6) S/Ck, oou./
~
*Mode: I = integer, R = real, D = decimal, A = alphabetic
101
Section
35
Subsections
Page
I
106
20
10
VARIABLES
I
IBM
1130 COMPUTING SYSTEM
VARIABLE SUMMARY SHEET
Cl..
'" :::?!I"E
w::::l
NAME
a
:::?!
z
0
~ERA/
RcfJ!RS
~
*w
c
.!::::Cl.. MAX .
1-1- VALUE
::::l::::l
0 Cl..O
R3
Application
P/lYROLL SYST.EN'f Date9foJ~7
Program Name
Ch6?C k
~
M:1""/0'
"//k7
'1<7/c~_
N0/ftlYo5 Programmer
.J
FUNCTION OF VARIABLES
CJ ~X'f,~
/-r/;I
lR 3 ~tJ XKX.~ #~(I'
5ICK' R 3
h '. "t./tq s
Pt!'tf/v~r t!'t?/'/J I
,r/
Re4{/H?r'
0'.(//,5
5~k .,At'dq
.' .....
klP/ q,t:J.5~ ~q CdP7pe?4¥
rI.¢f¢ kd/g;/!fj/,4Jc;k:;1/?;' 1d;
0 ~XX~ ltf.~~
0 ~XXXx ~(I(I
TA
~3
m
L I 0
R' 3 0
T4X
MIN.
VALUE
~XXXX
.. A.t~A
rI?/
l7
X;~/ /1e/ /;w C'tf)~d//U'
v
..1 T ~.xx (f.(/r/ rom/ qrt!7;'S
If .3 T rvrxxn ¢~~ 7b1d/~/}e/
Ik'
7G/?5
t«WXM
.,.
,
,,,~~AI,
WET
'Y
~TgA.l
1/ lB f
lCJTOT R 3 Z
dtfl¢!
3t1l?tlS i(jt/rs
h,lkl/tt!J/?/ .5'~t/ffe a0c,
Pt/~ tJT~d~r5 ;fp,fp/ ~.t//Q s~///ce~c.
lZ'ifr/6 p 3 I ~- pf,¢¢ ~4 ht1.1//'.5' J1,b/ ~~/7/ 5t1#/.c~ ~t:'.
~/5,£J ,() 3 .£ ~. ~/f/ ~e?c/t?/C?4'/'/-'/~4S *?b/ ~tt?/ff .5~~rG~ abe.
I( 3 0 rlX:Y% (/,~~ f{,Ctf/;;~/? ~e?;
jlA~/i
Y/I/!
Y.z;{/~
~.
~/
7 T ~~
VJ/ 6 T ~
IY~tI/d ~/ 7 1/ ~
'/t'JI/TZ ~/ t::, 0 ~
Yi£) k1 v~ ~t 1~'A)j
l.tA
-
-
-
/
,.,
~;6'/4'rtP.>s
YT.sf?
~I/~;~~rd/ M.K YTLJ
Ed-/iJPd tq".~.s.s Yr.o
c;;....r
- M?f?~~deTd/ 7#x YT£J
//1/brn7pnbr?- ~)!I;'()S'; (2)nc/l.,(3.JrIJ;
¢.citd 1('4-)Yedr-/o-ddre
,FIC,.q _A'_~ .(5') s/ck. OdLA./~) ~;'p/,:. A (7) Spc!?c.. 8,
(8) It/c.
r-dX, ?9)/e~. ;'ot.lrs'l~~o)OLAfv/"sP/) CJtJ/ltl.r .nt/tlrs.,
V/2L&?e4 erl'1's.a3)t:JT
~rds{/¢)'
.,
-,
t/
"Mode: I
= integer, R = real, D = decimal, A = alphabetic
102
,~~ ~,.n.<:;,.
Section
35
Subsections
Page
I
107
20
Initialize
Variables
Yes
Calculate
Control
Totals
No
Stop
103
10
Section
35
Subsections
Page
I
108
20
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
10
PAYOS
PAYOS
PAY05
PAY05
PAY05
PAYOS
PAYOS
PAYOS
PAYOS
PAYOS
PAYOS
C.~.KLICK
C----- PROGRAMMER
PAYOS
01120/68
C----- DATE CODED
PAYOS
C----- DATE UPDATED
PAVOS
RECORDS PAYOS
FILE RECORD NO. OF
FILE
NUMBER LENGTH RECORDS PER SECTOI~PAYOS
NAME
250
2
PAYOS
1
160
C----- INPUT FILES
1. COLFP
90
2
PAYOS
160
2
2. WVAFP
2
PAYOS
160
200
3
3. MNCFP
2
PAYOS
4
SO
4. LBOFP
160
2
PAVOS
5
1S0
160
5. LBTFP
2
PAY05
6
30
6. LMCFP
160
3
PAVOS
7. PINFO
6
106
2S
320
PAVOS
2S0
101
1
8. INDXl
90
320
PAYOS
102
9. INDX2
1
320
PAYOS
103
1
10. INDX3
200
320
PAYOS
SO
104
1
11. INDX4
320
PAYOS
150
lOS
1
12. INDXS
30
320
PAYOS
106
13. INDX6
1
PAY05
PAY05
2S0
2
1.
COLFP
1
160
C----- OUTPUT FILES -PAY05
90
2. WVAFP
2
2
160
PAYOS
200
2
3. MNCFP
3
160
PAYOS
50
4
2
4. LBOFP
160
PAYOS
S
ISO
2
160
5. LBTFP
PAYOS
30
160
6. LMCFP
6
2
PAYOS
7. PINFO
6
3
106
2S
-PAVOS
PAV05
PAY05
C----- ALLOCATE ARRAV STORAGE
PAYOS
PAY05
INTEGER COMP(l6), TAX, YINl(7), YIN2!61, YOUTl(7), YOUT2(6)
PAY05
DIMENSION FIBRECS" IDATE(3), ISUPP(l3), ITOTClll, JGROS(7),
1
JOUTlIS), JOUT2(7), JVACA(S), MASK(7), MASK2(7),
PAVOS
PAVOS
2
NAME(9), NDWK(3), NETO(7), NETl(7), NET2(7), NET4(7),
PAY05
3
NSSAN(3), QRTD(6), YTD(14)
PAYOS
C----- DEFINE FILES FOR THIS PROGRAM AS DESCRIBED ABOVE, AND EQUIVALENCEPAY05
PAYOS
C----- THE VARIABLES FOR THE NEXT RECORD NUMBER.
PAY05
PAY05
lC250,160,U,ICOL), 2(90,l60,U.IWVA),
DEFINE FILE
II FOR
* IOCS(CARD,TYPEWRITER,KEYBOARD,1132 PRINTER,DISK)
.
*LIST ALL
** PAYOS PROGRAM
* NAME PAY05
* ONE WORD INTEGERS
* EXTENDED PRI :ISION
PAYROLL SYSTEM - CHECK WRITING
C----- JOB NAME
PAYOS
C----- JOB NUMBER
C-----
C----C----C----C----C----C----C----c----C----C----C----C----C----C----C----C----C----C----C----C----C----C----- - - - - - - - c----C----c-----
c-----
C-----
104
Section
35
PAGE 02
PAYOS PROGRAM
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
3(200,160,U,MUNC),4IS0,160,U,LBO),
PAYOS
~(lSO,160,U,LBTI, 6t30,160,U,LMCI, 2S16,106,U,ICI,
PAYOS
101t250,l,U,IN1), 102(90,1,U,IN21, 103(200.1,U,IN3).PAYOS
3
104tSO.l.u.IN4). 10SI1SO,l.U.INSI, l06130.1.U.IN6) PAYOS
4
t ICOL. IWVA.MUNC .LBO ,LBT .LMC) ,
PAYOS
EQUIV.~LENCE
(IN1.IN2,IN3,IN4,INS,IN6)
P~Y05
1
- - - - - - - - - - - - - - - - - - - - - - - - - - -PAYOS
PAYOS
PAYOS
C----- INITIALIZE VARIABLES
PAYOS
PAYOS
DO 4 I=lt7
PAYOS
MASK2tI)=16448
PAVOS
4 MASK(I)=16448
PAYOS
MASK2(7)=-4032
PAYOS
MASK(4)=23360
PAVOS
MASKtS)=-19264
PAYOS
ICOL=l
PAY05
INlal
PAYOS
TA-O.
PAYOS
TB=O.
PAYOS
NRITE=O
-PAYOS
PAYOS
C----- READ PLANT NO., DATE. AND CONTROL TOTALS, AND VALIDATE CC 80 AND PAYOS
PAYOs
C----- THE PLANT NUMBER.
PAYOs
PAYOS
TOTRG,
TOTOT,
TOTBN,
TOTSP,
KARD
99999 READt2,1) NOPLT, IDATE, NDWK,
PAYOs
1 FORMATtIl,6A2.4F7.0.38X,I11
PAYOs
PAY05
VALIDATE KARD AND NOPLT
PAYOs
IF VALID
- 60
PAYOs
C----- IF INVALID - 55
PAYOs
PAYOs
IFIKARD) 55,51,55
PAYOs
51 IF(NOPLTI 55.55,52
PAYOS
52 IFtNOPLT - 6) 60,60.55
PAY05
PAY05
5S WRITEIlt2)
PAYOs
2 FORMAT('CHECK CC 1 AND CC80 ON FIRST CARD')
PAY05
PAUSE 1
PAYOs
GO TO 99999
- - - - - - - - - - - - - - - - - - - - - - - - - - -PAYOS
PAYOS
PAYOs
C----- READ THE PLANT INFORMATION RECORD FROM DISK.
PAY05
60 READ(25'NOPLT) COMP, ICHCK, IWEEK, FIBRE. ITOT, CKMAX, TGRS, TNET,PAYOs
PAYOS
1
ICNT
PAYOs
C----- wRITE THE PLANT INFORMATION FOR CONTROL PURPOSES AND ACCEPT ANY PAY05
1
2
C----- - - - - - C----C-----
C----- - - - - - - - C----C----C----c----C----C-----
C-----
c-----
C----C-----
C-----
105
Subsections
Page
I
109
20
10
Section
35
Subsections
Page
I
110
20
10
PAGE Ol
PAves PROGRAM
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
c----- CHANGES TO IT THRU DATA SWITCH SETTINGS.
PAYOS
c----PAYOS
62 WRlTEtl.3) COMP, IDATE. ICHCK. IWEEK. NOWK, CKMAX
PAYOS
FORMATII16AZ' '3A2I'CHECK NO 'IS/'WEEK NO 'Il/'W/E '3A2I, 'CHECK PAYO;
3
lMAX',F8.011'MAXlMUM CHECK AMOUNT MAY BE CHANGED By SWITCH 14.'/ 'PAYOS
2SWITCH 15 wI~L CHANGE THE CHECK NUMBER'I'SET SWITCHES REQUtSTEO ANPAY05
3D PRESS START')
PAY~S
PAUSE 1111
PAYOS
BR=wHOLEICKMAX + ICKMAX I ABSICKMAX)) * 0.5) I 100.
PAYOS
CALL OATSwi15,I)
PAYOS
GO TO 170,71),1
PAYOS
70 WRITEl1,Zl)
PAYOS
21 FORMATI'ENTER CHECK NO - FIVE DIGITS')
PAVOS
READI6.22) ICHr.K
PAYOS
22 FORMATII;)
PAYOS
GO TO 62
PAVOS
71 CALL DATSWI14.I)
PAVOS
GO TO 172.75),1
PAYOS
72 WRITE(1.23)
PAYOS
23 FORMATC'ENTER MAXIMUM CHECK AMOUNT - FIVE DIGITS')
PAYOS
REAOI6.24) CKMAX
PAYOS
24 FORMATIFS.O)
PAYOS
GO TO 62
PAVO;
PAVOS
C----- COMPLETE VARIABLE INITIALIZATION
PAYOS
PAYOS
75 INDX=NOPLT + 100
PAYOS
GO TO 176.77.78,79,80.81),NOPLT
PAVOS
76 ILST=2S(
PAYOS
GO TO 83
PAYOS
77 ILST=90
PAYOS
GO TO 83
PAYOS
78 ILST=200
PAVOS
GO TO 83
PAYOS
79 ILST=SO
PAYOS
GO TO 83
PAYOS
80 ILST=lSO
PAYOS
GO TO 83
PAVOS
81 lLST=30
PAYOS
~
~
~
~
-PAYO;
PAYOS
e----- READ AN EMPLOYEE RECORD FROM DIS~. AND USE THE PAID INDICATOR TO PAYOS
PAYOS
c----- OECIOE IF A CHECK SHOULD BE WRITT£N.
PAYOS
c· .. • ....
PAYOS
83 REAO(INDX'ILST) LAST
PAYOS
lCHCK-ICHCK - 1
PAVOS
870 00 700 I-1,LAST
READINOPLT'I) NUM. NAME. NSSAN. NSTAS. NDUES. NWKMP. NWKPO. MAR, PAYOS
PAYOS
1
NXMPF. NXMPS. NSEX, NRATE, YTO. QRTO, LYRHR, Neu, NeUDO.
C----C-----
c-.--- - - - - - - - - - - - - · - - - - - · · - - - - - - - C-----
106
Section
35
PAY05 PROGRAM
•
•
•
•
•
•
C-----
C----C-----
•
C-----
•
•
•
•
•
•
•
NCHr~.
C----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - C----C-----
•
•
•
----------------
C-----
C-----
C----C-----
Page
I
111
20
PAGE 04
NADWH. NSTCK. NINS. NMISC. NUA, NSTKD. ISUPP. INIT.
IPD, IFILL. Gr~oss. IVRAT. lOTRT. RGHRS, OTHRS, BNHRS. RGERN.
OTERN, BNERN. OTHER. KO, HOLDY, VACA, SICK. CNET, IFICA, TAX.
LOCAL, ICu, IUA, IUD, IINS, ISTCI(.. IMISC
PAY05
:3
PAY05
4
PAY05
5
PAY05
PAY05
IF(IPC - II 700,505,860
PAY05
860 IF(NRITE - NUMI 700,875.700
PAY05
875 wRITE(1,251
PAY05
25 FORMAT('ENTER CLOCK NO.' I
PAY05
READ(6.261 NRITE
PAY05
26 FORMAT(I41
PAY05
GO TO 500
PAY05
-PAV05
PAY05
C----- CALCULATE CONTROLS
PAV05
PAV05
505 TA=TA + GROSS
PAY05
TB=TB + CNET
PAV05
PAY05
500 IPD"'2
ICHCK=ICHCK +
PAV05
NCHCK=ICHCK
PAV05
-PAV05
PAY05
C----- wRITE UPCATED EMPLOYEE RECORD BACK TO DISK.
PAV05
C----- CHECK FOR DEDUCTIONS AND MARITAL STATUS
PAV05
PAV05
WRITE(NOPLT'II N~M, NAME, NSSAN. ~STAS, NDUES, NWKMP, NWKPD. MAR, PAV05
1
NXMPF. ~XMPS. NSEX. NRATE, YTD, QRTD, LYRHR, Neu, NCUDD.
PAV05
2
,'KHCK. NAD\oJH. NSTCK, NINS, !'IlMISC, NUA. NSTKD, ISUPP, INIT.
PAV05
3
IPD. IFILL, GROSS, IVRAT, IOTRT, RGHRS. OTHRS, BNHRS. RGERN, PAY05
4
OTERN, HNE~N, OTHER. KO, HOLDY, VACA, SICK, CNET, IFICA, TAX, PAY05
:.
LOCAL, ICU, WA, IUD, I INS, ISTCK. IMISC
PAY05
PAV05
IF(IFILll 550,550.510
PAY05
510 WRITE(1,201 IFILL. NUM
PAV05
20 FORMAT('DEDUCTION NO '11' NOT MADE FOR '141
PAY05
550 IF(MAR - 11 5.10,5
PAY05
PAY05
10 MAR=-7616
GO TO 15
PAV05
PAY05
5 MAR=-1l700
-PAY05
PAY05
C----- WRITE FIRST LINE OF CHECK AND PUT TOGETHER SECOND LINE OF CHECK. PAV05
PAY05
15 WRITE(3,50001 NUM. NDWK, NAME, NSSAN. MAR, NXMPF. NRATE, lOTRT,
PAY05
1
IVRAT, BR
PAY05
5000 FOR~AT(:3H1
,I4,lX.3A2.3X.9A2.1X.l3,l2.l4.1X.Al,l2.3l3,50X.F6.21 PAY05
CALL DATSW(15,IPNTI
PAY05
GO TO (90,911,IPNT
PAY05
2
Subsections
-----
------------
107
10
Section
35
Subsections
Page
I
112
20
10
PAY05
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
PAGE 05
p~OGr~AV:
')0 PAUSE 2
PAros
PArOS
PArOS
91 11=RGHRS
10. + O.OS
10. + O.OS
PAYOS
I2=OTHRS
PAYOS
13=BNHRS
10. + O.OS
PAYOS
14=RGERN
15=OTERN
PArOS
I6=!3NERN
PArOS
PArOS
I7=OTHER
PAroS
18=HOLDY
I9=SICK
PAYOS
CALL PUTIJVACA.l.5.VACA * 10 •• 5 •• 11
PAY05
CALL PUT(JGROS.1.7.GROSS * 10.,S •• 11
PAYOS
CALL ~O\ -;: I MASK2 d. 7, JOUTl tll
PAYOS
CALL MOVEIMA~K2,1.7,JOUT2,11
PAYOS
CALL EDITIJVACA,1.~,JOUT1,1,51
PAYOS
CALL EDITIJGROS.l,7,JOUT2,1,71
PAYOS
-PAY05
PAY05
c----C----- WkITE SECOND LINE OF CHECK AND PUT TOGETHER THIRD LINE OF CHECK. PAYOS
PAYOS
WRITE(3,SOOll 11, 12, 13, 14, IS, 16, 17. KO. 18. JOUT1. 19.
PAY05
1
JOUT2, NAME, IDATE, ICHCK
PAY05
SOOl FO~MATI' I .314,2I5~lX,215,2X,Al.I4.SA1,15,7Al,8X,9A2.8X,3(A2.1X). PAros
1
14Xtl51
PAYOS
PAYOS
c----CALL DATSW(15,IP~TI
PAYOS
GO TO (92.93) ,IPNT
PAY05
92 PAUSE 3
PArOS
PAVOS
93 CALL PUTINET4.l,7,CNET * 10.,5.,11
PAY05
CALL MOV[IMASK2.1.7,NETl.11
PA.YOS
PAYOS
C
CALL MOVEIMASK2,1.7.NET2,11
PAV05
CALL MOVE:MASK.l.7,NETo.11
PAVOS
CALL EDIT(NET4,1,7.NET1,1,71
PArOS
CALL f.DIT(NET4,1.7,NET2.1,7)
PAYOS
CALL £DITINET4.3.7,NETO,1,71
PAYOS
-PAYOS
:----PArOS
c----- wRITE THIRD LINE OF CHECK AND pur TOGETHER FouRTH LINE OF CHECK. PAYOS
PAY05
WRITE(3,S002) IFICA, TAX, LOCAL, ICU. IUD, !UA. IINS. ISTCK,
PAYOS
1
IM1SC. NET1, NET2. NETO
PAY05
5002 FORMAT( I '.21 14,IS) ,3I4.4X,215.6X,7A1.19X.SA1,10x,2Al,20X,7All
PAY05
PAYOS
CALL DATSWllS,IPNTI
PAYOS
GO TO 194.9S),IPNT
PAYOS
94 PAUSE 4
PAY05
C-----
C-----
--------------------
C-----
C-----
C-----
--------
----------------
C-----
C-----
108
Section
35
PAGE 06
PAY05 PROGRAM
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
C----
PAV05
PAY05
95 CALL PUTCYIN1.1.7.YTO(1) • 10 •• 5 •• 1)
PAVO'
CALL PUTCVIN2.1.6.VTO(3) • 10 •• 5 •• 1)
PAVOS
CALL MOVECMASK2.1.7,VOUT1.1)
PAVO'
CALL MOVECMASK2.2.7.VOUT2.1)
PAV05
CALL EDIT Cv IN1, 1.7 .VOUTh 1. 7l
PAV05
CALL EOIT(VIN2.1.6.YOUT2.1.6l
PAVOS
101-VTO(2l
PAV05
102-YTO(8l
- - - - - - - - - - - - - - - -PAV05
C~-~-- - - .. - - - .. - - - PAY05
PAY05
C----- WRITE FOURTH LINE OF CHECK AND GO BACK FOR ANOTHER EMPLOYEE.
PAY05
PAY05
WRITEC3.5004l YOUT1. VOUT2, ~. 102
PAY05
5004 FORMATC' '.13A1.2I5)
PAV05
PAV05
CALL OATSWC15.IPNT)
PAVOS
GO TO (96.700l.IPNT
PAV05
96 PAUSE 5
PAVOS
PAV05
C---- GO BACK.
PAV05
c-......·
PAY05
100 CONTINUE
- - - - - - - - - - - - - - - - - - - - - - - -PAY05
PAV05
C---- WRITE .1 ~V SPECIAL CHECKS. SIGNAL THIS CONDITION WITH DATA SWITCHPAYO'
PAVOS
C----- ZERO.
PAV05
PAV05
CALL OATSWCO.II
GO TO C850.855).1
PAVO'
PAV05
850 WRlTECl.25)
PAV05
REAOC6.26l NRITE
PAV05
GO TO 870
- - - - - - - - - - - - - - - - - - - - - -PAVO'
PAV05
PAV05
C----- WRITE CONTROL TOTALS
PAVO'
PAV05
855 ICNT-IeNT - 1
PAV05
IFCICHCK - ICNT) 800,801.800
PAV05
800 WRITEC1.100l leNT. lCHCK
100 FORMATC'REGISTER CHECK NO '15' DOES NOT AGREE WITH THIS RUN CHECK PAVOS
1NO '15)
PAVO'
PAVOS
GO TO 802
PAVO'
801 WRlTECl.101l
PAVOS
101 FORMATC'CHECK NUMBERS AGREE')
PAVO'
802 AaTGRS - TA
PAV05
B-TNET - T8
PAV05
WRITEC1.102) TGRS. THET. TA. TB. A. B
'2C3X.F9.0)/
PAV05
102 FORMATC'REGISTER TOTALS'2C3X.F9.01/'CHECK TOTALS
c-----
C----
C-----
C----
C----C----
C-----
C----C---C----
----.
109
Subsections
Page
I
113
20
10
Section
35
Subsections
Page
I
114
20
10
PAY05 PROGRA~
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
1
PAGE 07
'DIFFERENCES
'2(3X.F9.011
C-------------------------C----C----+
C------ ------------ ------C----C----C----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
C----- WRITE UPDATED PUNT RECORD TO DISK
I WEEK-I WEEK
1
WRITE(25'NOPLTI COMPo
ICHCK. IWEEK. FIBRE.
ITOT. CKMAX
C----- STOP
CALL EXIT
END
PAY05
-PAY05
PAY05
PAY05
PAY05
PAY05
PAV05
-PAV05
PAY05
PAY05
PAY05
PAYO"5
-PAY05
PAY05
I
VARIABLE ALLOCAT IONS
I COL -005B
IWVA -005B
INS
-005C
-005C
IN6
TOTSP=OOCO
CKMAX-00C3
OTERN-OOOE
BNERN-00E1
ISUPP-010B
ITOT -0116
NETO =014F NET1 -0156
YOUT2=0192
-0193
IC
ILST -019C
LAST =0190
NSEX -01A6
NRATE=01A7
NUA
-OlBO
NSTKD-01Bl
ICU =OlBA
IUA
=OlBB
14
-01C4
IS
-01C5
MUNC -005B
FIBRE-0072
TGRS -00C6
OTHER-00E4
JGROS=Ol1D
NET2 -0150
=0194
I
NUM
"019E
LYRHR=01A8
INIT "OlBl
IUD -OlBC
16
-01C6
LBO -005B
QRTD -0084
TNET =00C9
HOLDY=00E7
JOUTl"O I I I
NET4 -0164
NRI TE"0195
NSTAS"019F
NCU
-01A9
IPO =01B3
IINS =OlBD
17
=01C7
-005B
LBT
YTD -OOAE
.. OOCC
BR
VACA -OOEA
JOUTl=01l9
NSSAN-0167
NOPU-0196
NOUES=OlAO
NCUDD=OlAA
IFILL=01B4
ISTCK=01BE
=01C8
16
LMC -005B
TA
-00B1
GROSS=OOCF
SICK -OOED
JVACA=OllE
COMP -0177
KARO =0197
NWKMP .. 01A1
NCHCK=OlAB
IVRAT=01B5
IMISC=OlBF
19
=01C9
-005C
IN1
=00B4
TB
RGHRS-00D2
CNET -OOFO
MASK =0135
=0178
TAX
ICHCK=0198
NWKPO=01A2
NADWH-OIAC
IOTRT-01B6
IPNT =OlCO
-OlCA
101
STATEMENT ALLOCATIONS
1
=OlFC
-0204
2
5001 -02E2
5000 "02CC
-03E9
52
55
"03EF
,,0482
78
-047C
79
510
=05B9
=05Cl
550
95
=0705
=0769
96
3
5002
60
80
10
700
21
5004
62
81
5
850
22
100
70
83
15
855
23
101
24
102
72
860
91
801
-Ol17
"02FE
-03F7
"0488
=05C7
-076B
"0283
-0316
"040F
=048E
=05CE
·0770
"0293
-0310
"0440
=0492
=0503
.0788
71
87u
90
800
-0295
-033F
.. 044B
c049D
"05F8
=0794
-02AB
-034B
.. 0455
=0519
"05 FA
-079E
IN2
"005C
TOTRG-00B7
OTHRS-00D5
A
=00F3
MASKl-013C
Y INl -017F
IWEEK=0199
MAR
-01A3
NSTCK=OlAO
KO
=01B7
=01C1
Il
102 =01C6
-005C
IN3
TOTOT-OOBA
BNHRS-00D8
B
"00F6
NAME -0145
Ylilil -0185
ICNT =019A
NXMPFc01A4
NINS -OlAE
IFICA-OIB8
=OlCl
Il
IN4
-005C
TOTBN-OOBD
RGERN-OODB
10ATE-OOFE
NOIo/K -0148
YOUTl"018C
INDX -019B
NXMPS=O lAS
NMISC=OlAF
LOCAL-01B9
13
=01C3
25
4
75
875
92
802
-OlB7
l6
99999-03CC
-0470
76
505
"052A
93
·069F
20
51
77
50u
94
-OlAD
"0397
-0460
c051F
-0690
"07A2
-OlB9
-03E5
-0476
=053b
=0703
FEATURES SUPPI UED
ONE WORD INTEGERS
EXTENDED PRECISION
IOCS
CALLED SUBPROGRAMS
WHOLE
DATSW
EABS
TYPEZ
SRED
SWRT
SDCOM
SOAI
SDAF
PUT
SCOMP
SDF
REAL CONSTANTS
.OOOOOOOOOE 00-0100
MOVE
SFIO
501
EDIT
SIOAI
.500000000E 00-0103
EADD
SIOF
ESUB
SIOI
EMPY
SUBSC
.100000000E 03-0106
EDIV
PAUSE
ELD
CARDZ
ELDX
PRNTZ
ESTO
SDFIO
EDVR
SDRED
IFIX
SDwRT
.100000000E 02"0109
• 500000000E-OI-0 IDC
0=01E8
lOO=OlFl
b·ulEA
150=01F4
.500000000E 01-01DF
INTEGER CONSTANTS
l=OlEl
7-01E3
l111=OlEC
15-01ED
7616=01F6
11200 a 01F7
16446=01E4
14=01EE
3=01F8
CORE REQUIREMENTS FOR PAY05
COMMON
0
VARIABLES
4b4
4032-01E5
100-01EF
5·0 1F9
PROGRAM
23360=01E6
250=01FO
4=01FA
19264=01E7
90=01Fl
43b9-01FB
l=01E9
50=01F3
1544
END OF COMPILIITION
L!---- -
-
-
110
-
~5=v1EB
.10=01F~
I
I
I
Section
35
•
•
II
II
Subsections
Page
I
115
20
I
JOB
XEQ PAV05
3
*FILES(1,COLFPI,(2,WVAFP),(3,MNCFP) ,(4,LBOFP),(5,LBTFP),(6,LMCFP),
*FILES(2S,PINFOI,
*F [LES( 101, INDX11, (102, INDX21 ,( 103, [NDX3), (104, INDX4), (105, INDXS), (106. INDX6)
1022168021568
0040000000165000010500012100
9
V-
-
Input cards
111
10
Section
Subsections
Page
I
116
20
35
•
•
•
10
THE Co.NTAINER Co.M!'ANY
26-3
4'i'2
THE Co.NTAINER Co.MPANY
93
ORDER OF
•
•
PHECK NO.
DA.TE
PAY TO THE
ROB T B BADEN
EXACTLY
86
02:21: 68
DOLLARS AND 08
CENTS
I"'0'1'0",."'.0,"'
I
D'Y'I
10.
I ROBT
~DN'"
",G.
I
1°.104,40.
aA"
B BADEN
O.Y. I
,0.
.:::~
AVO.
I
I
YOU ...N'DAND YOU'CO."N".,D YOU
AYg;"
,roo::. 10y.,",.,N·I:a·o"DAYIVACAYOONI "" ,
,
2,61. 12 1°°
.:(]
I
$86.08
PAYROLL ACCOUNT
o.F Co.LUMBUS, WASH.
• .~~~~~~~~~~~~~~~~~~~~I
II!!··
.0,,"NO
100110215681
. 4010.
TO THE NATlo.NAL BANK & TRUST co..
•
r
THIS IS YOUR EARNINGS STATEMENT - DETACH AND RETAIN
.
I
.
I
119 1°1
•
•
•
•
•
•
•
.f---------------------------------------------.
THE Co.NTAINER Co.MPANY
25-3
412
THE Co.NTAINER Co.MPANY
NOT GOOD
AFTER 46 DAYS
OROVER $
250.00
PAY TO THE
ORDER OF
•
•
•
•
93
CHECK NO.
DATE
JOHN A HORN
EXACTLY
02:21: 68
83
DOLLARS AND 55
TO THE NATlo.NAL BANK & TRUST co..
CENTS
$83.55
PAYROLL ACCOUNT
o.F Co.LUMBUS, WASH.
THIS IS YOUR EARNINGS STATEMENT - DETACH AND RETAIN
Printer output
•
•
•
•
•
THE CONTAINER CORP.
CHECK NO
1
WEEK NO 1
W/E 021568
CHECK MAX 2~000.
022168
MAXIMUM CHECK AMOUNT MAY BE CHANGED BY SWITCH 14.
SWITCH 15 WILL CHANGE THE CHECK NUMBER
SET SWITCHES REQUESTED AND PRESS START
CHECK NUMBERS AGREE
REGISTER TOTALS
134121.
99685.
CHECK TOTALS
134121.
99685.
DIFFERENCES
o.
o.
•
•
Console Printer output
112
•
•
•
•
•
•
•
Section
35
Subsections
Page
20
117
1
IBM 1130 MACHINE SETUP SHEET
PROGRAM
NAME:
PROGRAM
NUMBER:
ChdC/<. ~/'/'/~//;'a
-.../
APPROXI MATE
RUNNING TIME:
PROGRAM
DESCRIPTION:
TYPE OF PAPER
PRINTER
NO. OF COPIES
CARRIAGE TAPE
CAecks
Chec~.s
0
DRIVE NUMBER:
DISKS
CARTRIDGE
10:
SWITCH
SETTINGS
INPUT
CARDS
,PAYOS
197...9'/"0//
C)
v
SWITCH
UP
DOWN
3
4
XRRX
SWITCH
UP
DOWN
SaJ/rc.h (tJ/s (/sed
2
1
/4
-
SWITCH
UP
DOWN
/Sv
r~ rnt:l.l:e· cA~c,l:..s· ",....e//"/~r 4/,he..-? ,,"h~!1' 4"~
/'Jor ct:J/"/'e'cl;
St:u/~cA /4/$ (/Jed' Tt:J s~r r~e tr7e?.x/m~~ c:A~c.L nrne;:;un;t.
SIVI/cn /5/s «seq' rtJ .seT rAe
t:?"d I'ttJ $:f~ ~e .5":I$;/~~ r~
CAt!?Ck
~v~6er
/-0
.r/~,..r t:v/I~/
(7/:j"" rAe ?r/~;t-~r-.
(CONT$20L
TOTALS
(//XEQ PAYO':
/ 1/ Jo~
SOURCE OF INPUT:
-
f---
hie.
/. C~rJ-IC{2 L. ;I"r'd(~ '#""~h7
2),
2)", s-~ !Z2.fL.~t. .&e. .a12Y-C.12L/~/j~~ ~/'a.a:2 hY~~
7
2
DISPOSITION OF OUTPUT:
/. P'YI-c,ll~&r.s. ~ e ~12.(~ee S
'to. tilt:!. (;,L.5tDd ~i.zf4.. ..D&:Ya:6
Z Z2t. I~ 'Y"'E ~d~aL. 62 r4.1.s.
FOR PAUSES AND ERROR MESSAGES SEE ERROR RECOVERY SHEETS
113
10
VJ
Cr.:l
c.n
IB~
INTERNATIONAL BUSINESS MACHINES CORPORATION
8 lines Per Inch
PRINTER SPACING CHART
IBM 407. 408. 409. 1403. 1404. 1443. and 2203
t-,:)
0
CD
....
o·
::::J
(')
VJ
c
0-
-
....
0
::::J
.....
.....
c.o
.....
00
en
CD
(')
o·
en
-0
m
CD
Section
I
IBM
Page
I
119
20
35
VARIABLES
Subsections
10
1130 COMPUTING SYSTEM
VARIABLE SUMMARY SHEET
VI
"0
NAME
0
*UJ
Q
0
:::a:
f3I\1ERAI
~
....0
~
:::a: IMAX.
;::::~ VALUE
ci ~o
~
X~XX
R 3 ()
12. II, 1;IJ
EItJRE R ~ tJ
C()I'IP
3 0
¢.¢¢
£
I
Ie
.z
/ AI
r
/
I
T
-
A
zjCJI7t/S
T £),.t;TE I
I~
¢.I~ AIel"
A
,
.
groSS dn70U/l/ o/' //7 ~Yiq¢dl
cAfRe;
I/?cI/l/iq~o/s .,?o;/dt7~ /,Qy
,
-
/00".0
E91.//i/o/eal
r:o rAl.?
,
TOr.
se':s run
8e~//7/7;/7~ ch~c.t nl//77b~r when #r';I;;'~cjt'e.ks
xxxxx
5e~v~/lCE /ll/m6e'r~"'/ov/"/?I//6AtJdI¢I
//seq in Po
-
"/Indv/dvdl
COnJPOA!/ nome
xx. xx ¢.lrI
() xxXXX
0
o/l7()L//J1
Tal(:/e t:7ssociQi;O/7 /1!'p(.)rTs
£02
t
Programmer
hours
¢;{I~
£" / 0 xxxxx (I
L / 0 X'xxx ¢
£O.z
K11C5
No·;:'AYtJ~
ChecK keqlsteR
(I·¢I HOXlmilnJ cIJec/c o/71()u/Jffl4 a (}le
IeNT
/
reoL £ / T 250 .1
.TeL!
Z / 0 )(}(X)()( 0
0
9/1.3/~7
Date
Bon/./S etl;a//7?S
T
I
ZCf/cK
WXXJ«
R .7 0 XXX.x>,
#OLPY R
Program Name
.3 LO X,«,YX rJ.lj¢
CKHAX R :3 T /¢#.I~
q~CJSS
P,l1YROLL SYSTEM
FUNCTION OF VARIABLES
/
C/IIET
MIN.
VALUE
z
R .3 0
BAlIt,
I-~
-
I
,
Rec"X./111116er //J e/71p/oj'ile'/I/e~ set' U/,
Au.o,
'/1
/
.L/lr//J//t/vq/y c/~d/·I L.//7io/J o{:duc17on
i
TorQ/ 0l/r;c//,//d.t/Q/~ //l5~,rQ';'Ci=} STo~cht?r/r"
4' /77/.5C_· d~duc~on.5 /o~r pt:l~ )J~r/b
/
/8' Cft~cK /7um.6~r
Is-I c:lock nl/n,.6er
-
/~r
~
~11 ~Aeci I7L//77b~r
2nd C/()CK nU/l1Qer
rJ
/llJll7e
*Mode: I = integer, R = real, D = decimal, A = alphabetic
115
/
Section
35
Subsections
Page
I
120
20
10
VARIABLES
I
IBM
1130 COMPUTING SYSTEM
VARIABLE SUMMARY SHEET
~'I"E0 w::J
;: 1::::.0..
III
NAME
*W
0
0
::i
a
0
z
MAX.
1-1- VALUE
::J::J
0..0
~
q
-
fLJtP
-42 "7? 0
fLJl
I
/
()
IO&
./ I
t}
xxxxx
xXXX
f
tl
-
MIN.
VALUE
r'
rJ
-
A~
I~ICA
Z / 0 X,KXXX 0
()
Z I T 7
()
I 0 xx
250 30
fiST .1 /
IH.ISC Z / 0 xxxxx 0
.1"/v,£;X I / T 1(16 171
.7'£1(.5
Z
r
Z I AI
J#~
L / IV
£/1/2
/
-
-
-
-
-
IOTR.T Z / T 1"~P ~
.L~tJ
I / 0 2
~
ESTel( £ / ~ ?¢¢¢ ;1
-Mode: I ::: integer, R ::: real, D
1!?4 'I ()~ 'P~/r'~~er
2 nd /7tlme
.3 c.d chec.K /JL//TliJ~r
3P" clocK
I7tl/l7iP~;
nl
3
/7ame
..7nchvic/vt7/J 7IC'A rox
Z/? cI;'ct1/~.s ckt/uc.ion
mtl~
L/JQ/J;/C/41QIs !/?.5I//(1/lCe ~r/.t/c;fca
/7()j
L Qsf record' /7~m,6~r ;",
0
///t::
Z/)d;vlt/vlJl~ /77/5C. ~c/vc.IJOI7
f/itl~x
//k
/JLlmb~r (/;I()nl- /70. r- /00)
EC;v if/a k/7
Ziti,
;-
No.
-
2.
IN.3
l"/J/'¢
T 250
Z / /II I J N / I /II -
fN.1
cAt'c~ hflsler
r)~#7
.-
rI
Z /
Program Name
Date
Inll/alio/') /~e
R~corcl/?tI/?J~er //7 //?d~x~s ,f:, C'/l1'p/oyee /tks
E 9'4IIV(7 k/71 10 .7AIL
;r;v,'pa/~/7T 10 J;V.z
() xXx'X'X
.T,NZT
'pAYRa,L ..sy.s TEM
FUNCTION OF VARIABLES
/0'1
I~ILL
Application
l//)iOrJ
f
~ .//1/2
EtJf/ii/tl/~l7f 10 ZAIZ
E91/1~(7k/l1-
ro
Z;V.1
c/~er Ii /7'1 e- Pel y
f~
7aC/;(:-Cl~.s slblv$ c;! record /17 /t'Jr()(,t"S.fI/if (.,/c/e
ZndlvlC!vals slcck. q"~ ~uc ~ 0.1'7
= decimal, A = alphabetic
116
,(l
Section
35
VARIABLES
I
IBM
Subsections
Page
I
121
20
10
1130 COMPUTING SYSTEM
VARIABLE SUMMARY SHEET
0..
III
"0
(5
NAME
*W
Cl
0
~
~I-'w::J
1-0..
3:
'0 ~S
~o
ci
MAX.
VALUE
MIN.
VALUE
Application
?AYROLL SYSTtfH
Program Name
N0."pAV" &, Programmer
FUNCTION OF VARIABLES
I5UPP .T 13 0 )()(XX
ITOT r 1/ T 171'3
ILIA z / 0 3{!/J
Z / 0 /5(1~
.TL/O
Z//RAT Z I 0 5f1¢
s
.T 11IEEK £ I T
Z N/l1l Z / IV / T
J
9
9
KC,4RIJ E / I
(I
Sl./p~/~m('/)/Q/ s/("k 'pelf'
?
4 CCOV/J! /Jvm64'rjf;r I'O$tt??
¢
/ac/IVI ¢VeJ/:S- ChOrll¥ ckdl.lc-fiO/i
¢
.7/7d1V'It!pt7/.~
¢
4J/eroClt!' pay-'
L
Mei cJ/IAe /Tl~I?;,4
-
,
uO/I)/}
~/t'S
ro 1/7 f~/7!'nfI/
I
ckt:lur::-lio /)
,ale
KO
~I /
0
5
¢
E9t1ivdka!1o .zeoL
I nclt!'X lor l)() /atP~
C. C. 81 frr las!- t:L7rd 7;.515~t!'C/C7 / ~Clr/7//J9s code
L
Z /
T
Z5¢
~
C'ov/lkr ~ ,cJcct!'s.s /"~c~/d$
L,45T
E /
r xxx
~
L80
.z
/
AI
-
-
Eqt/it/olen! /t> .TCOL
L8T
I
I II
-
-
E9f/1C/C1knf 10 reoL
Ec;v/va /,n f fi, ECOL
Locol7t7x
.z
L OC/lL
0 X;(xxX
LYRflR Z /
l!o
Z /
Itt/Nt'
L / IV I / 0 xxxX
//,4LJVIh"
= integer,
R
¢
. L tlS I /'/!'c()rc/ /?vm~er
//) ~:,t/!d
TIJI s r:ar/s acct//7lt//C7T/O/7
.j:'c;r
tlCd riO/? J?ClI/
/
;i
= real, D = decimal, A
/
01 /?t::Jurs
'/l1ari1iJ / 5" fo 1t/.s
..5//?~
I~ ) (2,
Epv;'vokntlo ZeOL
l
2
/1.4R
*Mode: I
/
}1
Z / IV' I / 0 xxxx ¢
L'#C
~ '13/~7
.~//C~
CA~CK R4-~/skr
~
z
Date
• (/-
~ tiel! lio"o / hltA/;()/~/l9
,
= alphabetic
117
l1/"r,f'~q
l7lorr/ e cl)
C//lltJtI/l!
Section
35
Subsections
Page
I
122
20
10
VARIABLES
I
IBM
1130 COMPUTING SYSTEM
VARIABLE SUMMARY SHEET
NAME
."
a..
.
"E :!!Iw:;:)
0
MAX.
:i: J::::a..
1-1-
:!!
Z
w
0
0
a
ci
:;:):;:)
VALUE
MIN.
VALUE
a.. 0
~
FUNCTION OF VARIABLES
#A#e
Vl2 9 1;1) -
AiC/{CJ(
Z / 0
-
xxux ¢
.z /
1;1) KK.XX rI
AI,~tJLJ V I 0 X'xxx (I
!V/)v£5 Z / J;(j xx. xX rI
,A/,I/
/V'/)PJK .1// J
;VIAlS Z /
#/{/JC I /
/YO"o/T Z /
)/RRTE E /
It)
,
II)
;:?t;YR()Lt :5Y5TE"H
Date ~ 'I.1/b7
No.&y O~ P:rfr~~er
Program Name L/e~k ,&,f/Skr
Application
-
xx. XX I
0
X)(~X
~
T
tp
1
.E/77~/oY'4'1!' /lQ/71e
~hecf ;/lmbt'r bfed'/ir
~iS ct'mpdJY'~~.
,
,
Creekl un/I)/) 4d'vcAon
)lpn/AI" C'ret:l'// v/);(?/) ~/vctiJl?-S
t//JI't;/1'46'~S ck/vc,fo/J
hv P£'/'/btl dt?k
' ,
L/15v/,Qnce
q~~I/C 7f..
'/tJ/]
/I;'.sce Ild/le~l/.5 c/e¢'vc i-tJh5
,P/d/1" /1(//l7be'r
£177~k;fee pt'lr /'d~
1
5ex. (1:;emtJIeJ (z .. mt:l~j (J- f,./lcfl'r)
/
9dtf 1 h JOCIO I~c(/;Jt. /J{//71Je"
~o 3.1¢ /.25
f / ~t1 .3
#.5.5,4N .T 3 ~~ Ilw.tlYS
#STA.5 I / () f
1
/l5TCK V- I I;O xx. xX II
/V'5TKO Z I 0 XXx X (i
/l/SEX
,
EmfJ~%4e sto/~.s .. (I-t/l7io/}), (.8-~.r:Kt'~1
tElI/llm~),h-/l()/I-U/}IOI1A:1/,T~l71e
" / '
s loci: ~g't/~ ion
Hon/~/q ~/()~)
~
"'
eledPctiJas
1!n/J1,/ A~peq/ de~clib/)s
Z / 1;0 xx.tx
/VI/If Z I if) x'Xxx. I{)I¢ CloeR /ll/l77ot'r
{I #vl77Jl'r 0/ tt/~ek.s t!'171~/c>~tt'cI
I 0 xX
/I/4/,KI1P
(I Altlm/Jer of 411't'ls fold
;V/Uk',Pt? V I 0 xx
/Vu,l/
.z
;VXIt,P~
*Mode: I
Z / it) 17
P
;;~/tl/ ~e/77PI;;'/J..s
= integer, R = real, D = decimal, A = alphabetic
118
z-n"n'P7A:J~q'J
r.s--!tr,.,171//7d ~
--
Section
35
VARIABLES
I
IBM
Subsections
Page
I
123
20
10
1130 COMPUTING SYSTEM
VARIABLE SUMMARY SHEET
II>
NAME
a..
~I"E w:::>
0
MAX.
0
;: Ca..
1-1'0 :::>:::>
~
Z
*w
0
ci
VALUE
MIN.
VALUE
a.. 0
~
;YXHP5 I 1 0
t/TERN ,e J 0
Application
,P,.L?YROL'SVSTEM
Program Name
CAecf &f/f/e-r
Date
.
N0·,PAy'Cl~
9;'lJ/6'7
-,~/ICK
Programmer
FUNCTION OF VARIABLES
17
~
xxxx% 1-J1t1
J'?b# e'xempl/ons
CJ'I'rlime Eora/nqs
. '
OTHER R .3 0 'txXJnv.s hrs '
~.J nt;. t!"pJ.~!i.
,/
7
*Mode: I .. int.r. A .. real, I) -= decimal, A -= alphabetic
120
'/.47 ' 1/1.
~/'n!J~
II'll)
,
, 'i..
- ~rl1s
Section
35
Start
Inltiali;te
Variables
Put together
Check Register
Information
No
No
Initialize
Plant
Variables
StOP
121
Subsections
Page
I
125
20
10
Section
35
Subsections
Page
I
126
20
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
10
PAYOo
PAYOo
PAYOo
PAYOo
PAYOo
PAYOo
PAY06
PAY06
PAY06
PAY06
C.R.KLICK
C----- PROGRAt ~ER
PAY06
01/27/68
C----- DATE CODED
PAVOo
C----- DATE UPDATED
PAY06
RECORDS PAY06
FILE RECORD NO. OF
FILE
NUMBER LENGTH RECORDS PER SECTORPAY06
NAME
c~---
2
PAY06
250
160
1
INPUT FIL.ES -- 1. COLFP
2
PAY06
90
2
160
2. WVAFP
2
PAY06
200
160
3
3. MNCFP
2
PAYOo
50
4
160
4. L.BOFP
2
PAY06
150
160
5
5. LBTFP
2
PAY06
30
160
6
6. LMCFP
3
PAY06
6
106
25
7. PINFO
320
PAYOo
250
1
101
8. INDXl
320
PAV06
90
1
9. INDX2
102
320
PAV06
200
1
103
10. INDX3
320
PAY06
50
1
104
11. INDX4
320
PAV06
150
1
105
12. INDX5
c--~320
PAY06
30
1
106
13. INDX6
PAV06
PAV06
OUTPUT FILES -- NONE
-PAY06
PAV06
PAY06
C----- ALLOCATE ARRAY STORAGE
PAY06
c· ..--PAY06
INTEGER (OMPC16). TAX
DIMENSION FIBRE(8). IDATE(3), 103(9), 106(9), 109(9), ISUPP(13), PAY06
1
ITOT(11), NAME(9), NDWK(3), NSSAN(3), aRTD(6), YTD(l~) PAV06
PAY06
C-"--PAY06
C----- OEFINE THE FIL.ES FOR THIS PROGRAM AS DESCRIBED ABOVE, AND
PAY06
C----- EQUIVALENCE THE VARIABLES FOR THE NEXT RECORD NUMBER.
PAY06
1
(250.160.U.
H:;OLl.
2
(90.
160
.U.
I
WVA~
•
PAVOo
DEFINE FILE
3C200.160.U.MUNC),4C50.160.U.LBO).
PAY06
1
5(150.160.U.LBT). 6C30.160.U.LMC), 25C6.106.U.IC), PAY06
2
101C250.1,U.IN1), 102(90,1.U,IN2), 103(200,1,U.IN3),PAV06
3
104(50.1,U,IN4), 105(150.1,U,IN5), 106C30.1,U,IN6) PAY06
4
PAY06
EQUIVALENCE CICOL.IWVA.MUNC,LBO,LBT,LMC),
(IN1,IN2,IN3,IN4.IN5,IN6)
PAY06
1
- - - - - - - - - - - -PAYOo
PAY06
PAY06
INITIALIZE VARIABLES
FOR
1132 PRINTER,DISK)
IOCS(CARD.TYPEWRITER.
NAME PAY06
ONE WORD INTEGERS
EXTENDED PREcISION
LIST ALL.
PAYROLL SYSTEM - CHECK REGISTER
C---- JOB NAME
PAV06
C----- JOB NUMBER
II
*
*
*
*
*
C-----
C----C-----
c;:---.C--C---C-----
C----C----C----C----C----
C---C-----
C----C----c-----C----- .. - - - - - - - - - - C-----
C-----
C----- - - - . - - - .. - - - - - - - - - - - - C----c---·-
122
Section
35
Subsections
Page
I
127
20
PAGE 02
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
C---- ICOl-l
PAY06
PAY06
PAY06
INl-l
PAY06
TA-O.
PAY06
TB-O.
-PAY06
PAY06
C----- READ PLANT NO., DATE, AND CONTROL TOTALS, AND VALIDATE CC 80 AND PAY06
PAY06
C----- THE PLANT NUMBER.
PAY06
PAY06
99999 REAQC2,l) NOPLT, IDATE, NOWK, TOTRG, TOTOT, TOTBN, TOTSP, KARO
PAY06
1 FORMATCI1,6A2,4F7.0,38X,Il)
c-_.......
PAY06
PAY06
C----- VALIDATE KARD AND NOPlT
PAY06
C----- IF VALID
- 60
PAY06
C----- IF INVALID - 55
PAY06
PAY06
IFCKARDI 55.51.55
PAY06
51 IFCNOPLT) 55,55.52
PAY06
52 IFCNOPlt - 6) 60.60,55
PAY06
PAY06
55 WRITEC1.2)
PAY06
2 FORMATC'CHECK CC 1 AND CC 80 ON FIRST CARD')
PAY06
PAUSE 1
PAV06
GO TO 99999
- - - - - - - - - - - - - - - - - - -PAY06
PAY06
C----- READ PLANT INFORMATION RECORD FROM DISK, AND FINISH INITIAlIZING.PAY06
PAY06
60 READ(25'NOPLT) COMP. ICHCK. IWEEK, FIBRE, ITOT, CKMAX, TGRS, TNET,PAV06
PAY06
1
leNT
PAY06
PAV06
INDX-NOPLT + 100
PAY06
GO TO C76,77,78,79.80.811.NOPLT
PAY06
76 ILST-250
PAY06
GO TO 83
PAV06
77 ILST-90
PAV06
C
PAV06
GO TO 83
PAV06
78 ILST-200
PAV06
GO TO 83
PAV06
79 ILST-SO
PAY06
GO TO 83
PAY06
80 ILST-150
PAV06
GO TO 83
PAV06
81 I LST-30
-PAV06
PAV06
c----- INITIALIZE PLANT VARIABLES AND READ AN EMPLOVEE RECORD FROM DISK.PAV06
C----c-----
C----
C----e-----
C----- - - - - - - - e---C----C-----
C----- - - - - - - - - - - - - - - - - - C-----
123
10
Section
35
Subsections
Page
I
128
20
10
PAGE 03
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
PAY06
PAY06
PAY06
PAY06
5
PAY06
PAY06
PAY06
1.-1
PAY06
1-0
655 REAO(NOPI.T'LI NUM. NAME. NSSAN. NSTAS. NOUES. NWKMP. NWKPO. MAR. PAY06
PAY06
1
NXMPF. NXMPS. NSEX, NRATE. YTO. QRTO. LYRHR, NCU. NCUOO.
PAY06
2
NCHCK. NAOWH. NSTCK. NINS. NMISC. NUA. NSTKO. ISUPP. INIT.
3
IPD. IFILL. GROSS. IVRAT. IOTRT, RGHRS. OTHRS. BNHRS. RGERN. PAY06
PAY06
4
OTERN. BNERN. OTHER. KO. HOLOY. VACA. SICK. CNET. IFICA. TAX.
PAY06
5
LOCAl.. I CU. I UA. IUD. I INS. IS TCK. I MI SC
PAY06
PAY06
C----- CHECK PAID INDICATOR TO SEE IF CHECK WRITTEN.
PAY06
PAY06
IFIIPO - 21 650,651.650
- - - - - - - - - -PAY06
PAY06
PAY06
PUT TOGETHER CHECK REGISTER INFORMATION.
PAY06
PAY06
651 T-T + CNET
PAY06
1-1+ 1
PAY06
GO TO (601.602.6031.1
PAY06
601 I01-NCHCK
PAY06
ID2-NUM
PAY06
CALL MOVECNAME.l.9.ID3.1)
PAY06
RNET1-WHOLE(CNET + (CNET I ABSCCNETI I * 0.51 I 100.
PAY06
GO TO 650
PAY06
602 104-NCHCK
PAY06
I05-NUM
PAY06
CALL MOvECNAME.l.9.I06.11
PAY06
RNET2.WHOLECCNET + ICNET / ABSCCNETl) * 0.5) / 100.
PAY06
GO TO 650
PAY06
603 ID7-NCHCK
PAY.06
IDS-NUM
PAY06
CALI. MOVE(NAME.l.9.ID9.1)
PAY06
RNET3-WHOI.E(CNET + ICNET / ABSCCNETl) * 0.5) I 100.
- - - - - - - - - - - - - - - - - - - -PAY06
PAY06
PAY06
C----- WRITE A LINE OF CHECK REGISTER FOR THREE EMPLOYEES.
PAY06
C"'---· WRITEC3.1101 101. 102. 103. RNET1, 104. 105. 106. RNETZ. 107. I08.PAY06
PAY06
1
109. RNET3
PAY06
110 FORMATC3C3X.I5.1X.I5,lX.9A2.1X,F6.21)
PAY06
1-0
C--"'-- ... - - - - - - - - - - ... - - - ... - ... - - - - - - - - - - - - - - -PAY06
PAY06
C----83 REAOIINOX'ILSTI
LAST
WRITEI3.51 COMP. NOWK
FORMATI'1'.50X.'CHECK REGISTER'//ZOX.'FACTORY PAYROLL '.16AZ.5X.
1 'W/E '.ZIA2.'-'I.A2/13(' CHECK NO'7X'NAME'14X'AMOUNT'1/1
T-O.
C----
C----C----C----C----C-----
----------
C----- - - - - - - - C-----
C-----
124
Section
35
Subsections
Page
I
129
20
10
PAGE 04
e----- HAVE WE PRoeESSEp THE L.AST EMPL.OYEE RECORD
e----- YES - 657
e----- NO - 655
• e----• e----- --------------------• e----• e----• e----- --..
. ----• C----•
C----- -----------------------------.. -• e---• C----C----- ----- ---------------.. ------- -•
•
•
•
•
•
•
•
•
650 L..L. + 1
IFIL. - L.AST! 655.655.657
e----- IF THERE IS A PARTIAL. L.INE TO WRITE 16151. WRITE IT.
657 IFIll 604.604.615
615 GO TO 1605.6061.1
605 WRITE13,1101 Iplt 102, 103. RNETl
GO TO 404
606 WRITE13,1101 101, 11'2, 11'30 RNET1,
104. 105, 106, RNET2
c-..---
e----- WRITE THE PL.ANT TOTAL.
604 T-WHOL.EIT + IT I ABSITII
*
0.51 1100.
WRITE C3 ,1111 T
111 FORMATII/50x.·TOTAL. • .F9.21
C----- STOP
CAI.I. EXIT
END
VARIABL.E AL.L.OCATIONS
IWVA .0058
ICOL. .005B
IN5 .OOSC
IN6
.005C
TOTSP.OOCO CKMAX.OOC3
OTERN.OOpE BNERN.OOE1
IpATE .. 0101
11'3
.010A
TAX .OU4
IC
-OU5
L.
.OlSE
I
.015F
NSEX -0168 NRATE.0169
NUA -0172 NSTKp.0173
ICU .017C
IUA
.0170
11'7 .0186
108
.0187
STATEMENT AL.L.! ::ATlONS
1
"019F
2
·OlA7
76
-0280
77
,,0286
602
.0369 603
.038C
PAY06
PAY06
PAY06
PAY06
PAY06
PAY06
-PAY06
PAY06
PAY06
PAY06
PAY06
PAY06
PAY06
PAY06
PAY06
-PAY06
PAY06
PAY06
PAY06
PAY06
PAY06
PAYOI>
-PAY06
PAY06
PAY06
PAY06
PAYOI>
-PAYOI>
PAY06
I
MUNC .0058
FIBRE-oon
TGRS .OOC6
OTHER.OOE4
106 ·0113
NOPL. T.01!>6
NUM .0160
L.YRHR-014A
INIT .0174
IUD .017E
L.80 ·0058
QRTO -0084
TNET .. 00C9
HOL.OY.OOE7
109 ·OllC
KARO -OH7
NSIAS=0161
NCU .014B
IPO =0175
1 INS .017F
L.BT
-005B
YTp .OOAE
.OOCC
T
VACA =OOEA
I SUPP"0129
ICHCK=01s6
NOUES=0162
NCUOO-016C
IFIL.L.=0176
ISTCK-0180
L.MC
=005B
TA
-00B1
GROSS=OOCF
SICK .OOEO
I TOT .. 0134
IWEEK·0159
~WKMP .. U163
NCHCK=0160
IVRAh0177
IMI S(=0181
INl
=005C
.OOB4
TB
RGHRS-00p2
CNET "OOFO
NAME .. 0130
ICNT =OlsA
NWKPO=0164
NAOWH=016E
IOTRT.0178
101
=0182
.005C
IN2
TOTRG-00B7
OTHRS.OOOs
RNETl-00F3
NOWK =0140
INOX =0158
MAR
=0165
i1iSTCK.016F
-0179
KO
102
=0183
5
78
110
79
657
111
80
6l!>
.01FF
,,0298
-03EO
99999=0220
81
·029E
60!>
-03E6
51
83
606
52
655
604
·018A
"028C
-0300
650
·OlF3
·0292
-030C
=0246
=02A2
~03F5
-024A
,,0280
=()408
IN3
"OO,C
TOT01·OOl:\A
BNHRS-0008
RNET2.00F6
NSSAM"'v143
IL.ST =015C
NXMPF·v166
hliliS =0170
IFICA=017A
104
"U184
-U2,O
"
-O3~3
6,1
11~4
-Oil,C
TOTI:IN"OOBO
RGEKN=Ou08
kNEU·OOFIi
COMP "'\)153
L.AST =0150
NX~lPS=0167
Ni"ISC"U1 H
1.0(AL.-0178
=0185
IDS
bO
601
'd
"02
=Oj46
FEATURES SUPPORTEp
ONE WORD INTEGERS
EXTENpEp PREC I S ION
loes
•
•
•
•
•
CAL.L.EO SU8PROGRAMS
MOVE
WHOL.E
EA8S
SIOF
$101
PAUSE
EAQO
CAROZ
REAL. CONSTANTS
,OOOOOOOOOE 00-0188
EMPY
PRNTZ
EOI V
SOFIO
.500000000E 00-0188
EL.O
SOREO
lOS TO
SOAI
EPVR
SOAF
WRTYZ
SOF
sREO
SOl
SwRT
SC()MP
SF Iv
SIUAI
.100000000E 03=018E
INTEGER CONSTANTS
1-0191
2-0192
30.0198
3-019C
CORE REQUIREMENTS FOR PAY06
COMMON
(I
VARIABI.ES
6·0193
0-0190
392
PROGRAM
100=019!>
90-0197
250-0196
200-0198
50"'U199
668
END OF COMPIL.ATION
-
125
-
1;.0=019A
I
Section
35
Subsections
Page
I
130
20
10
I I JOB
I I XEQ PAV06
3
*FILES(1,COLFP),(2,WVAFP),(3,MNCFP),(4,LBOFP),(5,LBTFP) ,(6,LMCFP),
*FILES(25,PINFO),
•
•
*FILES(101'INOX1),(10~,INDX2).(103,INDX3),(104,INDX4),(105,lNDX5),(106.INOX6)
1022168021568
0040000000165000010500012700
Input cards
•
•
•
•
•
•
•
•
CHECK REGISTER
FACTORY PAYROLL
NAME
CHECK NO
4
7
10
1001 ROBT B BADEN
1004 JOHN W CUSSEN
1107 A E TAYLOR
1603 'L. REYNOLDS
\II/E 02-15-68
THE CONTAINER CORP.
AMOUNT CHECK NO
86.08
86.26
113.63
123097
NAME
1002 JOHN A HORN
1005 JOSEPH MONT ANO
1218 DAVID A HUBBARD
TOTAL
AMOUNT CHECK NO
83.55
142.58
88.48
996.85
1/ JOB
1/ XEQ PAY06
3
*F lLESI ltCOLFP) • I Z.WVAFP). 13 .MNCFP) .14 .LBOFP) • I !;'L.8TFP) .16 .LMCFP) •
*F lL.ESI 25 .PINFO).
*FILESI 10ltINDX1).1 102.INDX2). II03.INDX3). 1104.INDX4). I lOS. INDX5) .ll06.INDX6)
Output on printer
126
3
6
9
NAME
1003 ROBT L. SHORES
1016 DONAL.D MI LL.ER
1347 FRANK T DOL.EN
AMOUNT
61.44
129.33
81.53
Section
35
Subsections
Page
I
131
20
IBM 1130 MACHINE SETUP SHEET
PROGRAM
NAME:
Chec~
Reg/'s re.,-.
PROGRAM
NUMBER:
APPROXIMATE
RUNNING TIME:
PROGRAM
DESCRIPTION:
TYPE OF PAPER
PRINTER
DISKS
NO, OF COPIES
Srp;?dd".q
DRIVE NUMBER:
0
CARTRIDGE
/b!l/"~//
SWITCH
UP
DOWN
CARRIAGE TAPE
./
10:
SWITCH
SETTINGS
PAYO~
S,l-d4c?d r /
1
/V~...-?~
3
2
X X 2
s:
'0 ;:::5
1-0..;
0 ~o
~
0
~
0..;
Application
MAX.
VALUE
MIN.
VALUE
941
Program Name
Z
i? g 0 xx. xx ¢J.¢¢ "rZCA TC1YcJ/;/e
Z / T
L 1 T
£ / T
I
.Te.
ICOL
9
ZIJATE .1' "3 .(0
Z~lItJ1 42 22 To
No.
!/secl At ("'Q/ct/6/e t?t/er!;me
XX)(X
7".lCA
flA Y 09
9/Zt);i7
K//CK
Programmer
;4k
ItA~f~.5
L/$4'd //7 LJO /oo~
-
E9///V t2Ie/JI/;; £/112
25{)
.1
Fece>rd nV/TlL;t:'r
-
-
-
-
/-!.t h;'e 0/ ht'dd//)?
2(!..d fiae eJ/ heoq;/,g
3 Cd p/?e o//;ead/~j'
-
L1/o/, r
' ""
'ptu/
dQ~
L/Jf3
j~1.I
//7 t!'m/'/"'yI?~ ;tIle
Zlf02
('12
22 Z;O
-
£#£)3
't12 2~ J;O
42 22 f,(J
-
-
-
-
4 ~ /tne. 0/ h~"t:hn9
~/ 1
0
I
~
CQrrlt1pe
/
T
1(1(,
I~/
Z /
0
~
I
.T / T 2,0
.£ 1 #
£/'13 .z / IV' Zlv'4 .l / ,AI £/'/5 Z / II
-
1
ZlfOtf.
Date
FUNCTION OF VARIABLES
R 3 0 66Jf/t14 ~ {J1(1~
A
;7AY'£?tliL sY5TE#
set'
r
IL
INtJX I
INIT
.TN.1
IIv'£
I / AI
IiJA1E 1" / 0 20
Index f'//e /It//77~~/ ~/"nl Of),
!/aloa 1/?/ItC//0I7 /ees
E9t1I~Qk/1f 10 ZAIZ
-
E~I/Ivq/t'nf Ii> ..tN.!
-
1
EjFt//t/d/eal ~
./11/.?
/0
fAI.!
Et?t/1t/tlff/?7
Pt?ge /ltY/77~er
/
7
*Mode: I
=
integer. R
= real, D = decimal,
A
-I- 1(0)
hcor¢a(/m~t'r //1 /a4ex~J 10 emf?1oyee ;;les
Et;(/i{/(/ lea I /c; .Z'IV.1
-
- -
IN(P
con/ra/
= alphabetic
129
Page
133
Section
35
Subsections
20
I
Page
10
134
VARIABLES
I
IBM
1130 COMPUTING SYSTEM
VARIABLE SUMMARY SHEET
c..
Vl
~I-
"E
w;:)
I-c.. MAX.
;:::~ VALUE
0
NAME
*w
Q
0
~
IjJtJ
~
'0
~o
ci
T
Z /
(J
¢
/lLI4 'At'S
912 ~/TS
~
#/IR £ I ~() 2
IIPCO Z / 0
/t.£JLY .z / 0 tI/
Z"
"'V
SdC/q! Sect.//;r~
,
I
E 9V'/(/qknllo .zC()L
XXX r;J
0
/
/acltCtlie.s slolts 0/ record //lj'Jl-oe-ess//7tl cY'c/e
SOt./~;t:>/e/TJtf'/1/o /
Z / N' LBT I / AI L/IV'E 1" / T 5tJ If
fllC Z / Iv' L5T ..T I T ESt) ESp
.z
94/
{I
/BO
LYR/-IR
f/Zf?/G7
No. ~yOfpr/fr{/n~~r
Date
FUNCTION OF VARIABLES
I51.1,P'p ./ 13 0 {IJ
EIY'YA I I T 2~¢
L,4ST
'p/lYRtJ/L SYSTE#
Program Name
~
z
£ / 0
AI 9 0
I.5'S~/t/
Application
MIN.
VALUE
,
S/CR- ~Q~
,
Losl rectJn:i /It/m.6er
In (lIe
Etjl//~t?k/7/
/0 /CtJt.
E9V/VOk/l;l ~ .zC~L.
L Il?e ctJl//? f
Eq(//{/Q/e/J
I- If, ZeaL
,
LC15"1 record /It//77Jt'r //7 q ///e
Th/S f(~Qr/,s c?CCV/77v/q;/t:)/J 0/ /7ovr5
LU~rlf4d ./'O/' &/~('q"b/] .oQV
I
/¥Qr/$,/ ~/Qlvs .. (i-sl;'9!e,
, , J. (2 - mor/'I/~e:I)
{lJ
#um~C'r 0/c!'mp4:Jf'ee.s rl!/'?~/~d~~r C't:7/77Ptl/1Y
,
I
#L/m.b~r 0/ emf//c;y~e5 rer'orkq"?~r .f't1~e
/tf//;V, Z / AI ;V'
.E / Z ~
/V"ft'JN/I I I 0 (I
I
E9v/vokn! /0 .zeOL
jJ/()/lf /7t//?7.,6er
~
/fddl 1iol?o / k//~~lJld/)? ~m?'t//JI
#.4#E A2 9
'i;()
-
-
j)V/77/77t,/ t7reQ)g
/VC/fCK I
0
~
(J
C),4'~) /)t//l76er I./s~cI ,feJr;%ts e/l7/l/t:J,Y4'1!'
/VC'tI
*Mode: I
I
I / Z;o
= integer,
R
= real,
xx. X)
D
(I
d/!d,ClI:c/ :>/JC1ce fir /lC//1?e
~r~cItl pni()n q".t"q't/cf;o~
= decimal, A = alphabetic
130
Section
I
IBM
Page
I
135
20
35
VARIABLES
Subsections
10
1130 COMPUTING SYSTEM
VARIABLE SUMMARY SHEET
"E'"
0
NAME
*W
~
0
'0
0
:2
ci
z
.r /
a...
:21w:J
I-a... MAX.
f:::~ VALUE
~O
/vRfi'TE £ I
A/SEX
#55.4!t1
;V.5TAS
Program Name
~
q~.t.
Date
No.I'AYtJ9
9}?O~7
Pr6ffa';;'r
FUNCTION OF VARIABLES
¢
¢
/V1JLlE5 Z I !;IJ Xx.x'X ~
/VIAl5 V / Vti XK.XX (i
(I (J
;1/IYISC L / 0
;VCU~t}
PAYROLL sYSTEH
Application
MIN.
VALUE
t)
1;0 3.¢~ /.fJ5
)vftf)n~/,/ cre~/
UnIt//?
dv~ ckdvc!5ol')
..tasvrdnce dedc?f~//
Hisce //qaet:JtI s de&c//o/'lS
Emr'/"yee jJQ~ /'4~
JeK-('/- fol71q~14-mqkl.(.}-lrl/cKer)
"'
')
£ 3 to ,ftWAYS tJj)jyiis Employee sla/vs-(i- U/Jlbn1 (z./rtlckt'r
El77jJ/(;y~e .s-Ioltts -(/- U/7/0/1~ (2 /("vc~r )%-/1Q/1- ~;'J~
6"
.7 / 0
1
./u// i'lme, 1. /4-/7t//l-UI7/on a7rrhme, 1.. '5-knn/nf/. , rJ
"
SloCK de dUG/ion
L / 1;0 xx. XX ¢
#t//l~/V .5;0ci' det:/l./c~On.s
Z / 0 (I
~
!/aIle;; ~/-,eo/
~d/./c;fp/7$
£ / [0 XX.KX {JJ
,
;- / f(O X'XX'X /~rP¢ cloeR /Ju/77bt!'r
Z /
~()
3
L
\
/VSTcK
NsrKO
#I/A
#L/N
,,
/ 0
I
/ 0 ¢
AlIYKflO
;VXNP,c .£ / Il~ 17
/VXH.P5 I / () 17
##,{'HP
~
;Y~m6e/"
t
¢5
c:;/ tveeh e/77,P/of'e4
,
Alum~er 0/ UleeK:.s PQ/c/
,
77'
hd'"rtl I e,Yl?/77,P. '/ bas
~
.51c1re
~
exe/77,PTio/1s
y;(./qrt~r-ro-.oo;~ //J7/Cl'"l77dTlOn (11.fr"s~ (e);:Il/(3)j:'/~A
R 78 0 xm-.x~ IrlrI (4)loc./bx if) F/C"'tvtJ(j~S
f~)5Ick ,- VALUf,:
~
z
0
NAME
*w
0
TOTt)
VTLJ
MAX.
3:
0
~o
Application
MIN.
VALUe
PrClgr4lm Name
~
Dat~ ~Ofi:7
pAYRO!.L S'ls rl:'i'I
f4/
No. PAY
r; 9
·K//(j,/(
Programmer
FUNCTioN OF VARIABLES
xx;k ;:)&;(/, t1'-JSPt.'IC. A. /'/) .s~"c.8
~.It.f}/Vi
I--
erie/)
(PLAN""
HG'lijEI?
I--
CAR
[II XEtp PAY09 I--/
/1 '/08
SOURCE OF INPUT:
DISPOSITION OF OUTPUT:
4
X XL X
PAYROLL
10:
SWITCH
SETTINGS
CARRIAGE TAPE
941 FORMS
DRIVE NUMBER:
DISKS
PAY09
f--
/- PI ant i(Jformd:f.iol'1 C4.ro's FraN? File. E
Z- Pd.¥-roll cluj( {rom J',(~C~ ~
I- J4/ ;e.~",.t it> #~Vgr;r;:y:
:::
I.s ~e-tura. - ~o::io
3- p, rLh't l,,'(),.C!1.~ {oQ. ~~~ ~Q ;iI~ E
2- f;h:s/(
FOR PAUSES AND ERROR MESSAGES SEE ERROR RECOvERY SHEETS
141
10
Section
35
PAYROLL SYSTEM
Operation Manual
Subsections
Page
I
01
20
20
Section
35
Subsections
20
I
20
Page
02
Section
35
Subsections
Page
I
03
20
CONTENTS
Payroll Application .........................................................
Job Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
System Flowchart ........................................................
Narrative .............................................................
Payroll File Create (PAY01, PAY02, PAY16) ...................... .......
Payroll File Changes (PAY03, PAY16) ...................................
Payroll Calculations and Register (PAY04, PA Y16) ...... . . . . . . . . . . . . . . . . . .
Print Payroll Checks (PAY05, PAY06) ...................................
Payroll Check Voiding (PAY11) .. .. . . . . . . . . . .. . . .. . . .. . .. . . . . . . . . . . . .. .. .
Payroll Deduction Registers (PAY12 thru PA Y15) .........................
Payroll File Audit, 941, and Tax (PAY07, PAY09, PAY 1 0)
...............
Print W-2 Reports (PAYnn) .............................................
Error Detection and Correction (P AY09) . . . . . . . . . . . . . . . . . . • . . . . . . . . . . . . . ..
Payroll Programs ..........................................................
PAY01: Payroll File Create... .. ................................. .........
Accounting Controls. . . . . . . . .. . . .. . .. . . . . . . . . . . . .. . .. .. . .. . . .. . .. . . . . . ..
Error Recovery Sheet ..............................•...................
Machine Setup Sheet ...................................................
PAY02: Add Names to the File ............................................
Accounting Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..
Error Recovery Sheet.. . . . . . . .. . . . . . . . . .. . . . . .. .. . .. .. . .. . .. .. .. . . .. . ..
Machine Setup Sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..
PA Y03: Changes to the File ................ ··· .. ···················0·······
Accounting Controls. . .. . .. .. . .. . . . .. .. . .. . .. .. . . . . .. . . . .. . . .. . . . . .. . . ..
Error Recovery Sheet. .. .. . . . .. . .. . . . . . .. . . . .. . . . . .. . . .. . . . .. . . . . . .. . ..
Machine Setup Sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..
PAY04: Calculations and Payroll Register ........•.•..••............•.....
Accounting Controls. .. . . .. . .. .. .. . . . .. . . . . . . . . . .. . .. .. . . . . . . . . . . . . . . . ..
Error Recovery Sheet ..................................................
Machine Setup Sheet ...............................•...................
PAY05: Check Writing ...................................................
Accounting Controls ...................................................
Error Recovery Sheet. . . . . . . . .. . . . . . . . . . . . . . . . .. . . .. ... .. . . . .. . . .. . .. ..
Machine Setup Sheet ...................................................
PAY06: Check Register......... ....................... ...................
Accounting Controls .......................................•...........
Error Recovery Sheet. . . .. .. . .. . .• .. . .. . . . . . . . . . . . .. .•. .. . • . .. .• . . . . . .•
Machine Setup Sheet . . . . . . . . . . • . . . . • . . . . . . . . . . . . . . . . • . . • . . . . . . . . . . . . . . ..
PAY09: 941 Report ......................................................
Accounting Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..
Error Recovery Sheet ..................................................
Machine Setup Sheet ............................... . . . • . . . . . . . . . . . . . . ..
1
1
1
1
2
3
4
5
6
7
8
9
10
11
11
11
12
13
14
14
15
17
18
18
19
25
26
26
27
37
38
38
39
50
51
51
52
53
54
54
55
56
20
Section
35
Subsections
Page
I
04
20
20
Section
35
Subsections
Page
I
05
20
20
PAYROLL APPLICATION
JOB DESCRIPTION
The Payroll System is composed of 16 different runs. From the source documents, produced
at the six plant sites, cards are punched. These cards are used to store the payroll information on the disk cartridge.
At this point the system uses cards only for transition between jobs. The input data,
employee records, is read from the disk and updated before being written back. This gives a
highly flexible system, in which 1/0, because of the disk, is very fast.
The system produces the following reports:
• Checks and check stubs
• Check register
• Payroll register
• Deduction registers for
1. Union dues
2. Credit union
3. Stock
• 941 quarterly report
SYSTEM FLOWCHART
Narrative
The system consists of 16 programs.
The Files Creation program is first. Data decks are keypunched for each individual, in sets,
by plant. The data is edited and, when correct, loaded on the disk by PAYOl. Three files are
created: a master file, an index file, and a plant information file. A second data deck with
employee clock number and name is loaded onto the master file by PA Y02.
Changes to the disk information are made by PAY03. Documents, received from personnel
departments at the individual plants, are checked, summarized, keypunched, and verified.
Time sheets, submitted by the plant payroll departments, are keypunched and verified. All of
these cards are processed by PAYI6, which edits and generates control totals. PAY04 then
processes these cards, performing all payroll calculations. Cards are read, pay computed,
disk files updated, and cards extended with current pay figures. After all cards are processed,
a payroll register is printed.
Checks are printed by PAY05. A header card is read and the checks are printed from the
disk file. PAY06 lists the check register from the disk file. In the event of an error in
computing pay, PAY11 provides the means of voiding checks. The extended time cards from
PA Y04 are read in and the affected employee records are reset. The above are weekly runs.
At month end, registers are prepared showing each individual's deductions for the month:
PAY13 writes union dues register.
PAY14 writes credit union register.
PAY15 writes stock deductions register.
PAY12 resets charity deductions code.
At the end of the quarter and at the end of the year PA Y07 and PAY08 are used to balance
the disk files to control totals.
PAY09 produces the 941 tax report.
PAYI0 produces a tax worksheet used to determine tax liability.
At the present time the program for W-2 reports has not been written.
1
Section
35
Subsections
20
I
20
Page
06
Employee
Earnings
Record
TAPE
Clock No.
and
Name
Zero Balance
Totals
fAY....1ft
INPUT
EDIT
Out of Balance
fAY...Q.1
FILE
CREATE
.fAX...Q.2..
ADD NAMES
2
All but
Name
Section
Subsections
Page
I
07
20
35
Employee
Payroll Change
Authorizations
Total on
Adding
Machine
~--------. .~ TAPE
Changes
Control
Total
Zero
Balance
Total
~
INPUT
EDIT
Out of Balance
O.K.
Control
Total
Changes
Control
Total
.fAY....Q.J
FILE
CHANGES
Changes
3
20
Section
35
Subsections
20
I
20
Page
08
Weekly
Time
Sheets
Totals on
Adding
Machine
Details
Zero Balance
Totals
~
Control
Totals
INPUT
EDIT
Out of Balance
Payroll
Register
Zero Balance
Totals
PAY 04
CALCULATION
Details
Control
~
~_____T__o_ta_ls______~ ~
4
Section
35
Subsections
Page
I
09
20
Control
Totals
Calculated
PAY 05
PAYROLL
CHECKS
Only When
Pay Checks
and Stubs
Totals Balance
Control
TotDls
PAY 06
CHECK
REGISTER
Check
Register
Control
Totals
5
Total on
Adding
Machine
20
Section
35
Subsections
20
1
20
Page
10
Only When Totals Do Not Balance
Control
Totals
Details
PAY 11
VOID
CHECKS
Control
Totals
Details
6
Section
35
Subsections
20
I
20
General
Ledger
Union
Dues
Register
Credit
Union
Register
Stock
Deduction
Register
PAY 13
UNION
DUES
PAY 14
CREDIT
UNION
PAY 15
STOCK
DEDUCTION
PAY 12
RESET
MONTHLY
TOTALS
7
Page
11
Section
35
Subsections
20
I
20
Page
12
General
Ledger
Totals
PAY 07
AUDIT FILE
BY COMPANY
TAPE
Plant
Numbers
Calculated
Control
rotals
PAY 09
941
REPORT
941
Report
Tax
Worksheet
PAY 10
"""'fAX
WORKSHEET
Plant
Numbers
8
Section
35
Plant
Numbers
W-2
Reports
PAYnn
wr
REPORTS
Disk
Payroll
File
Plant
Numbers
9
General
Ledger
Subsections
20
I
20
Page
13
Section
35
Subsections
Page
I
14
20
20
Disk
Payroll
File
Select Desired
Clock Number
Card
Clock
Number
Individual
Payroll
Record
PAY 08
INQUIRY
Last Week's
Payroll
Register
Use PAY 16
& PAY 03
to Change the
Disk Payroll
Record
Only when
entire original
error has been
corrected
Return to
Print Where
Error
Occurred
10
Section
35
Subsections
20
I
20
PAYROLL PROGRAMS
PAYOl: PAYROLL FILE CREATE
Accounting Controls
Balance total gross ($) and total tax withheld YTn ($) from the preceding PAY16 to the general
ledger.
11
Page
15
Section
35
Subsections
Page
I
16
20
20
IBM 1130 ERROR RECOVERY SHEET
JOB
Pd.y.rO// ~qSTt:=""m
PAYO/
PROGRAMMER NAME C/2,c //'C k-
PROGRAM NAME
PAUSE - DISPLAYED IN ACCUM:
MESSAGE TYPED:
IHI I ~I£ I
#'0/\/£
0
AFTER PAUSE, CONTROL TRANSFERS TO STATEMENT
__ ___N:ttt!'2e______
DESCRIPTION OF WHAT IS WRONG:
~n-e------
-
PROBABLE CAUSE:
; ( /Q.N"e
RECOVERY PROCEDURES:
A/<2Ne·-
COMMENTS;
Zh~~~
a~L"3'
/)
SOURCE OF INPUT:
DISPOSITION OF OUTPUT:
-
t. Card /ne..u.t!..
7
.£rQt2!
a sC/cce5s/'c// ~d~ &a/~
/tva.
.z. >O/~.!r:. u:::z«..-;-/ Iz~ 7. e..~c.(2t1 d/S!:;. ~t:.th. ac.~t2. s:. :/0,.
e4.c/t ~/k'H/' t?//c;cc?",£ed.
L»~,t-t:?t:.L k/'..s.
/$
PROBABLE CAUSE:
LT/;~
e~~~.~
e7h~
c. L"'2.c.~
t2./'
/'~C(2,-d
/7 &,Lt!Z2.L;er~
in tJ~rt!?ar.
/h rAe
RECOVERY PROCEDURES:
A7'- f-he.. t?.n d
at2ied
~/'nA?
u~d~
;?{2t!
Lad'ded.
/r7L?V~ C.::;;;7/'d,/s
r-
ttl7- r /u? r'L/n. r'ea:? QlL.e r-,,~~ c.::;?/'d(,s l
rAe da.r~ d~a~ c:7/7d cA~G~ rhP..
J
So
~C1L~~~~~~?h~~~~/~~~~
L?card an The .,..r?/Le f~
~pun~h
rAe.
ca""d
7-..hc!?
Ct2..cd..dnLT r"B/'~a..
LS
//.?car/'eaC;
COMMENTS;
SCORESHEET
I
DATE
INITIALS
I I I I I
15
I I I I
20
Section
35
Page
Subsections
I
20
20
20
IBM 1130 ERROR RECOVERY SHEET
JOB
rb'-!J..r~t/ 1/ ~.$"feh7
?AY02
PROGRAMMER NAME CR.C//c£
PROGRAM NAME
PAUSE - DISPLAYED IN ACCUM:
MESSAGE TYPED:
c-~OG.K::" L1LCJ, )(
>< X / A/
r-/~E
A/c)T c1.~PEE
'TJa.rs..
I NI IMIL I
><
0
W/ZH C~aC-k A/o. XX-XX
,LA/ C /J,t!D
AFTER PAUSE, CONTROL TRANSFERS TO STATEMENT
:;;ref
£'
DESCRIPTION OF WHAT IS WRONG:
~.~~
57_ ~
~e.
/e:?O
/.he ~s~ fi(? /$ ;> .P4YO/. .
....",.....
~/ec/>/t ///e 8.
2. L)/sk To.be ~..red //7 PAY03.,.. u./n/ch s/7t?~/c/
6~ ,t:~-'2. n ~ lS:./'
/. ,¥O'n?e c7/J4 C/o c."=. /110. cclr4s a,e
FOR PAUSES AND ERROR MESSAGES SEE ERROR RECOVERY SHEETS
17
20
Section
35
Subsections
Page
I
22
20
20
PAY03: CHANGES TO THE FILE
Accounting Controls
Hash totals of clock numbers, change codes and new fields from preceding PAY16 should
balance to control totals prepared manually.
18
Section
35
Subsections
Page
I
23
20
IBM 1130 ERROR RECOVERY SHEET
PROGRAM NAME
.DA Y 03
PROGRAMMER NAME
Ck.K//cA-
PAUSE - DISPLAYED IN ACCUM:
AFTER PAUSE, CONTROL TRANSFERS TO STATEMENT
/00
/he- c-o/'d /~ ~,r/~,r: a/,/// ~~ ~e~c-?1....qd
To r:6e o//e/'/.?C7/e s/-Qc&2:er. ke.-??o/:-?,r.he card'
RECOVERY PROCEDURES:
7A /< ~r/'V7/' /YJfi('/ /'e.C"o/:r ,/Y?"? s-'L/<,reO? F0c23
c:rro/'?, Kee.x :pc~~t==>.. '%e A7POQ/"Lj/?-J .·~g/'b/?4 LU//h
//),q v/d/7/ /;;J/Jd cc//d ~/fd~ /./~&?_< Ae//?a Dr2:f'cessed
wAd/? rbe Od/~ c>ccc/,,,--c;d Lr1 me e~occc;./"r\S a
SecQ/)d b;"n " q , /7<2,,0'ty. (jove ~q:ppcV/:ser.
COMMENTS;
SCORESHEET
I
-DATE
INITIALS
I
19
20
Section
35
Subsections
Page
I
24
20
20
IBM 113l ERROR RECOVERY SHEET
JOB
Po/~// £:l.S/e"",
\OJ
PROGRAM NAME
PA.YO~
PROGRAMMER NAME c.R.C~Ck..
PAUSE - DISPLAYED IN ACCUM:
MESSAGE TYPED:
&~ (/ir2j/6~'
Ft2A?'xxxx
I /11
C£20£
AFTER PAUSE, CONTROL TRANSFERS TO STATEMENT
t.?
1// Ir- I
/00
DESCRIPTION OF WHAT IS WRONG:
Lh,.o ('l2d~~ COrne
c.t2.~~ LL- ~l.
£5 n,:2r ~L//)/h
-rh~
VtZL/d
PROBABLE CAUSE:
I<'~
......7 t2c.LL2 c..6.
e. c. CI":J·/'
RECOVERY PROCEDURES:
kkru/"/? co/"'d /,2/?d a?:2c.V/?7L!'?~r
m
k~I2u.C?c:.a
C),C?p/"'c7~L2L.-"/
COMMENTS;
SCORESHEET
I
DATE
INITIALS
I I I I I I I I I
20
Section
35
Subsections
Page
I
25
20
IBM 1130 ERROR RECOVERY SHEET
JOB
P4&,/'~/
PAYc:?3
PROGRAMMER NAME C RCL>ck
S.7ls7'efl?
PROGRAM NAME
PAUSE - DISPLAYED IN ACCUM:
MESSAGE TYPED:
CLOC~
/\/a X
x25:..,x
I h~1
.A/~T
LN~~£
~
AFTER PAUSE, CONTROL TRANSFERS TO STATEMENT
lA' 1£ I
a
/00
DESCRIPTION OF WHAT·IS WRONG:
7?,£ L/:?L?LJ/- c/?~d G'MC,k. L2::Yn2c2c~ L~~
. d
7
/J
Q:r
~a
t;IJ,e:7-
//J_eK.
PROBABLE CAUSE:
~T/J~ P~C2~r-?~
L/.2~d.
/'I'2C Q / " d
6 C2 s: a. t2. r'
I)/'
?7/Je c./ac..k tt!2. L:/~./J e / l .a.a. ;//5~
PL'l/?ch e 4 L~2Ct"/r,..c?Cc.r'o/
7
C"c?/'d
//p~/?
,
L . . "S..
RECOVERY PROCEDURES:
TI1~ CClt::.d /$ sl.:::1c.~ ec.. Sg/ect:e.c/. P8/7/~E/B :f~ r:2:7/'?:/
c2L2 d
~~ ~ /J~1~ ~q ~e~~t2/Jr:Je/
L~c£)r£/;;I;4,c> Ch~~/?~;';;L>:;/, ~~s:: l"!.dr:;'~c~ L~~d
Me. R~~eel:: /'c;?c?/' ,1~ ~e -//L.~ ~ OT/7p/a//Se
r=1%Ck-.s.
CQI"'/
cr
1'A6? c.p/"'d
,d/1&7
L.tc>,r-'ljI/?
COMMENTS;
SCORESHEET
I
DATE
INITIALS
I I I I I I I I I
21
20
Section
35
Subsections
Page
I
26
20
20
IBM 1130 ERROR RECOVERY SHEET
JOB
Pd~rt.?// .S~~?'e41
PA'YOd
PROGRAM NAME
PROGRAMMER NAME
c,R,C//cl'f
PAUSE - DISPLAYED IN ACCUM:
MESSAGE TYPED:
C/Or":k" A/V.d4&EPS .,./)o
l,vl I #'1£ I
A/~7 .A1MR~,,~~.RXXXX,
C)
AFTER PAUSE, CONTROL TRANSFERS TO STATEMENT
/c::/O
DESCRIPTION OF WHAT ISWRONG:
,:;:;nec/:§:'5g:~5:;~;~~~~ 9~
~s/?~r~
i/J rh,P ~I2U~ C;2rd.
~Aa
PROBABLE CAUSE:
»is~
da.l"'..:Z '/'4."'< heE!'-2
g/?~/,,~d.
RECOVERY PROCEDURES:
Cd.rd 4s:
L A"}a::1. e~dLe{:t
sUck~;" . . S'=:'t!~ctt£?d.
r~o~rr.. rAe? ~cC.::L/"'/e/;7Ce ,0)~
-m/,$ 1"?'c:.L2t2/' "/7:) ~a~c .~~~c::.-'CYLSOL:.
COMMENTS;
/)/Sk d/7//:7
SCORESHEET
I
DATE
INITIALS
n/.2S
L)r/)~~'" "'<./.bI'
7
C7
h~
--
desr-.rowed
..,/
I I I I I I I I I
22
Section
35
Subsections
20
IBM 1130 ERROR RECOVERY SHEET
JOB
;::b-!:fE~// ~sle~
PROGRAM NAME
PAY03
PROGRAMMERNAME~A?~//C~
PAUSE - DISPLAYED IN ACCUM:
MESSAGE TYPED:
ENrER SSAN
I~I I NIE I
~OA? X YX~
CJ
AFTER PAUSE, CONTROL TRANSFERS TO STATEMENT
k~Aaq.cd spLpcr.
DESCRIPTION OF WHAT IS WRONG:
MQ~>t? L /7 t=
L:5
~$'7t>Lf:!J ~or_~;Oor /r'(2a2.
.£0b t!2?2.Ld
PROBABLE CAUSE:
L~e.
r? CO.g. Ct:Za-z
,-
h4S c::.~/~d /~/' ~q/-JL/r.
RECOVERY PROCEDURES:
£/7i:e.r
t/;.e
~~ SO..c'~/ SeC't./".,/'r~ .a.u/rlt6er
mdl.'c.czied eo/L~E? ...r
h"
COMMENTS;
SCORESHEET
I
DATE
INITIALS
I I I I I I I I I
23
I
00
Page
27
Section
35
Page
Subsections
I
20
20
28
IBM 1130 ERROR RECOVERY SHEET
JOB
p~~// ~s/ea?
PROGRAM NAME
P~YCJ3
PROGRAMMER NAME
C.RC//CK
PAUSE - DISPLAYED IN ACCUM:
MESSAGE TYPED:
CI:. !?CLc"
l1L(/ff18£R
L:5: ./)~/ LCdrp"".£)
I A/I I~I£ I
X~kX
0
/00
AFTER PAUSE, CONTROL TRANSFERS TO STATEMENT
DESCRIPTION OF WHAT IS WRONG:
a
.t::Z(Ln?hp-C. L/-/_ rd~ La L?V~ c:c?r~ ~.o"""
~/;r~Q~e. / 5 /.?L/~L7d~ da ~ d~5:.~ hLP.
The c Lt2r:p
oe~
PROBABLE CAUSE:
L
/he Cc::7rd at:?:2: /Jec?/7 -c?aTc:::'/c="d
b~eco/?d
~Lh/c:o.
a
I"J/'
~~/7'?.6e'" L./7
/I. L,he CL"2. r k
RECOVERY PROCEDURES:
T/;p
C/C'c&;
c::. '/
TA~ //7.::2..:2/
7
//lCC2.L!/,c?cr-
L2
,:7d'(-k'e/"' -St?
,/''::2/-':;/ ~:LcZ. . t.,<) '''-
~£'Fi
t!:!/ L ' /~i.'
,.,.,
',::
',/~' / / /
", ..
,
/
f
/ec..r-e(z"J
/ " __ ,,,:,- ' ' 7 / '
cc7/'d
r:::~ec::.k ~7
.r"'!" £.'.t..: /~
CLJa·c7.i:~ rdse
.--<~-.
/'~~~ ~d_W~~' n ~
;;L/?C!o.nec.t",
~~~"
~f!'a57i~Yf~V?
PBjj:...e,f~ T~I J?f:Tf ct' ~e,
e
/s
c:o
, I t e:lf,.
I
j-
~":.,
j
~r
"r i }(') -f J-
<"'
~Qt::reci::.·
COMMENTS;
SCORESHEET
I
DATE
INITIALS
I I I I I I I I I
24
Section
35
Subsections
Page
I
29
20
IBM 1130 MACHINE SETUP SHEET
~~~~~AM C~.t?0.!l~S /~ rAe /;/~
PROGRAM
NUMBER:
PROGRAM
DESCRIPTION:
APPROXIMATE
RUNNING TIME:
TYPE OF PAPER
PRINTER
DISKS
NO. OF COPIES
S?'arnMrd
DRIVE NUMBER:
0
CARTRIDGE
Pt7~rt:)//
SWITCH
UP
DOWN
CARRIAGE TAPE
S!g"eTqrd'
/
10:
SWITCH
SETTINGS
PAYO,3
/'\/oae
1
2
[)( X
IXX
/i/t:'"., e
SWITCH
UP
DOWN
INPUT
CARDS
SWITCH
UP
DOWN
(
q
>--
(MORE
"R/7e
(CHANGE..
r-ar e4ch ,P/'?/Jr
4//rh Ct"74nyC"s
-
q
JC"'or
/",%a
CARDs
(
~or &:7he /
/
qv
#~/?~
9
(
{
4
3
f---
r--
r--
/P/dh~
(CHAt-.JGE
r--
CARDS
(II XEQ PAY03
/ // JOe::.
~v
~
SOURCE OF INPUT:
DISPOSITION OF OUTPUT:
/rf2.trJ. r:2 ~u.c.ces:.
t'~ r/G:i ~~ i' /'L./a.
ttz.fLd- be. ~~t.Ct2..t/ @'s'k. u.t2a:J. ~'(~~.
r--£d.
t. Ctt::1rd /!?av"L
2.2)/sk
7
J
cZ/'e ~'/ed /Q. i//e. C
~ .2)t..s.;C /$ L:.t:!t~Ct2e.d.. rl'!'J s~or't:2.f}e. r?~.c
PA'C:a4
t.. C/)/?/7oe Cd.....A
FOR PAUSES AND ERROR MESSAGES SEE ERROR RECOVERY SHEETS
25
u..~t:::.. U//rh
20
Section
35
Subsections
20
I 20
Page
30
PAY04: CALCULATIONS AND PAYROLL REGISTER
Accounting Controls
Machine totals (regular hours, OT hours, bonus hours, special earnings) must be balanced to
the control totals from the preceding PAY16 run. Information is found on console printer for
this zero-balance check.
26
Section
35
IBM 1130 ERROR RECOVERY SHEET
JOB
ptJyro/1 Sy.srem
PROGRAM NAME
PAY04-
PROGRAMMER NAME
IIC
k
PAUSE - DISPLAYED IN ACCUM:
MESSAGE TYPED:
CHECK
C. R. k
CC
ON ,c/;rsr
.J rt4N J) 80
0
0
0
J
I I I I I
C'AR~
AFTER PAUSE, CONTROL TRANSFERS TO STATEMENT
DESCRIPTION OF WHAT IS WRONG:
I. Cdrd
99999
colvnln I
&(lS d'l
"P / 4t ", '" ;,vh76er,.
it:1.'" f!./ltl'
01-
2. Cdrd
PROBABLE CAUSE:
£/"~.r d
A q oS De.-tl
d~ck
RECOVERY PROCEDURES:
~~/1It:!::111. 80
bLdn/(
~ It'/.
ce f:I
;s
'70"1-
h' " H
NtlM8EIl
0
0
I
0
I I I I I
AFTER PAUSE, CONTROL TRANSFERS TO STATEMENT
90
DESCRIPTION OF WHAT IS WRONG:
/. /~ ,t'/rs+ J"~J~ c~ ""he ~/Q~.4: hVhlb .. ~
t/oe~ naT d~ree .h//..~ ~Ae p/t::t;,r
it? +he A~'tlcler cd. Y' eI.
hVnl6er
or
2. CdI'd
PROBABLE CAUSE:
dd -rd.
/. Tile
#/-r~
or
t?,
c<'/~,."."
~nflt
Cdrd
dti1'cI
:,s
t?r1e
;01hO-t'
p/CZnr
/4
d n(J
ton er
.5'e -I-
l/p
lh C
I
II t/filc/
~/d"T.
c:
o"'r~ c.
r/y.
cctrd r~dcler. The ,t'l/,.. s-t- Cd.".c:/
... " errt:Jr. COl-rec T -I-Ae cdral
(fir /'" el"'hove /7- ."t"r()M -J-A ~ c(ec ~ _
;~ I'lecessdry"
r ect t/'y -I-Ae cdrtl r e d dt!? "... Pr e & S
A'~/#t:iel d;Jq'
.'7'-.Ae ~(lt!!!.~~ /~.
,,0,-6 t:.r ri.h1
S"l-~I'" r
~"
C
7t:'
-
,,~,..
dec.~
RECOVERY PROCEDURES:
eo l ... l" vtlllcl.
c /~dr
COMMENTS:
7'ht?
+-ht2
SCORESHEET
I
/< )( >( It ANP
/Nllrx Na. XJt' >tk. DQ
A&RFIF
h~r
IN I IN IE I
(J
AFTER PAUSE, CONTROL TRANSFERS TO STATEMENT
/2. 0
~iI
rA e c.loc A: ; , ' " /')? 6. c ,..
c«I"J ~t:1~.s a.t1~ d,:rIPe
DESCRIPTION OF WHAT IS WRONG:
/"-,v -r
c,/t:)ck
11 VAl J:i II ~
1/1
+Ae._.
6? I'n ' / 0 it..
Tb.1!!
+A~
"'~cord.
wl"l-J,
e fr
PROBABLE CAUSE:
p,'sl:::.
dC;t: No x)('x><
I I I Ie: I
N
AFTER PAUSE, CONTROL TRANSFERS TO STATEMENT
0
N
120
DESCRIPTION OF WHAT IS WRONG:
H~'"
qmlflu~""
~~
cA~cl: f!~ C
fie clr
Ii",,; "'"-
PROBABLE CAUSE:
i·
pr
t. /",,'r
.re of-
2.Errt:Jn~D~J
Tot:J
IDW
in
~qrtl
(!J
m ~/(J Jt' ee rec..o,..t:I
RECOVERY PROCEDURES:
I.
t:?r
2.
C/',z" ~e
C~r're
///17;
r arltl
ret::.tJl?
cT- e.,," eA>y ee re co".. t:/ fin d'
r e..'" i/I't •
COMMENTS;
SCORESHEET
I
DATE
INITIALS
I I I I I I I I I
32
Subsections
Section
20
35
.·8M 1130·ERROR RECOVERY SHEET
JOB
?dyr,,//
..)y~re'h
PROGRAM NAME·
~,I1Y()4-
PROGRAMMER NAME
"t"~Ck
C', R
PAUSE - DISPLAYED IN ACCUM:
MESSAGE TYPED:
XXXXX)c:'X~
INf'Ui' T071J1.5
I
XXXXX)(~.
IV
~~)()(~~K. ~~~X~XX·
I I~ I I
0
E
AFTER PAUSE, CONTROL TRANSFERS TO STATEMENT
Ne~
/n
Sc:- '1.. lJ el'lC
+
e
/V'orlli~f.
DESCRIPTION OF WHAT IS WRONG:
.-.
£,,~-
PROBABLE CAUSE:
C.dnTro/
(J
T~rdl.r
~-
,L'."
~,..~m
rouT i/le
A~da'e,..
/or
c~,..d.
""'1'"/'7 r~'A t;"
t:'t/
r
RECOVERY PROCEDURES:
COMMENTS;
SCORESHEET
.
I
DATE
INIT·IALS
I I I I I I I I I
33
I
20
Page
37
Section
35
Page
Subsections
20
1
20
38
IBM 1130 ERROR RECOVERY SHEET
PROGRAM NAME
,P~ Y () 4-
PROGRAMMER NAME
C.K! r';''c,t
PAUSE - DISPLAYED IN ACCUM:
MESSAGE TYPED: =--_______- - -
PRoc€'"S"r£P rorl4£
XXXXx'Xx.
~
X XXXX)()(.
AFTER PAUSE, CONTROL TRANSFERS TO STATEMENT _ _ __
Nex T
/n
S' e f!"t./enc.e.,
DESCRIPTION OF WHAT IS WRONG: -"N.--=.......;,,::....-r-.~A-'-"~---::.·/1..,fil-_ _ _ _ _ _ _ _ _ _ _ _ _ __
---------------------------_.-------------------
PROBABLE CAUSE:
End-ol'-lr;i> rDIJ'7,'l'1e
.t2cct./h1vl"r-~cI C"CI""h't-r,,/
ir
/r//1r~';,7'
(1vT-
7-Cl7-Q/r.
RECOVERYPROCEDURES: __________________- - - - - - - - - - - -__
COMMENTS; _______________________________________
SCORESHEET
I
DATE
INITIAL~
1
34
Subsections
Section
35
20
IBM 1130 ERROR RECOVERY SHEET
JOB
Pd-!7'-rC)// ~s/e~
lDAYCJ4
PROGRAMMER NAME c. /?, K/;ck.
PROGRAM NAME
PAUSE - DISPLAYED IN ACCUM:
MESSAGE TYPED:
E,f?R(2R L~uL:£
~J!(~K..~~ )l, i{.t!!X.J!!.~"~~,,
ICY;:; ~)it x
I~/
II
~ "J.,K..l!!.l! ~ 1(.
A/
t2
1£ I
AFTER PAUSE, CONTROL TRANSFERS TO STATEMENT
,..-tLex r
//-; . '5.ec-Zt"/~,rJc:;re.
7
DESCRIPTION OF WHAT IS WRONG:
A/o/h/r-.Jq
V
--_.-
PROBABLE CAUSE:
E/2.cJ. 07"'- ; 0 6 rCJt.Ji..;'rl..t!? tt..s.. .i2rMr;~C; Lldr
4c:.c..ul!2:2uL4l!.ed.. roz!(XXKJ(;(X.xxxxxx><.
C:R. ~I/ck-
PAUSE - DISPLAYED IN ACCUM:
KXX xxXX.XIO(R
/6
SWITCH
UP
DOWN
V"
Srd/Jde?rd
1
/by/'t:///
L4
SC/,N/ch /4
v
x//;)7C-/r?? cA~cA:.-
4
X [>(
SWITCH
UP
DOWN
Alt'/.1e.
Qrntt:'v/)"
/;;',-74' /'0',-/7
~//)
q
/COr
C'/7(!'
/~~t'7r
(WEEKLY
~~~g1E
(CONTROL
TOTALS
(IIXEQ PAY04
/11 JOE:>
DISPOSITION OF OUTPUT:
3
c~ec/c::.. /?v~7oe" 4/)4 ?Vee/' nUhl6er'"
[
SOURCE OF INPUT:
CARRIAGE TAPE
/
DRIVE NUMBER:
SWITCH
SETTINGS
I
20
APPROXIMATE
RUNNING TIME:
TYPE OF PAPER
DISKS
Page
IBM 1130 MACHINE SETUP SHEET
PROGRAM
DESCRIPTION:
PRINTER
Subsections
/
~
_V
-
f---
~ CArd c.qocd:.....4-<1az. t:? ~.({cce:s £~~L L?~ OG2 ~~ t.. CULl.
Z j)/.~Is.
d2.u..~~
/.un/rat..
.?.D..... C~L.;::.
ae. 7 t2~L?c2L/ ~ .:;-k
b-/tf2.L~
to
~Le:.
to. £/U! :;]
/2
zY-1f!J.d:L
~~,,~~ t~~dtLs~cl>an
FOR PAUSES AND ERROR MESSAGES SEE ERROR RECOVERY SHEETS
37
~/es:
20
Section
35
Subsections
20
I
20
Page
42
PAY05: CHECK WRITING
Accounting Controls
Disk-stored totals -- gross ($) and net ($) -- are balanced to machine-calculated total of checks
for zero-balance test. This should also be compared with the adding machine tape of checks.
38
Section
35
Su bsections
Page
I
43
20
IBM 1130 ERROR RECOVERY SHEET
PAYOS
PROGRAMMER NAME c.~ i:::hckPROGRAM NAME
MESSAGETyPED: ___________________
PAUSE - DISPLAYED IN ACCUM:
Cl-lrCK e e L AA./Q CCC3Q
c2N' r / R S r C&,RO
AFTER PAUSE, CONTROL TRANSFERS TO STATEMENT.99 999
DESCRIPTION OF WHAT IS WRONG: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _-,--_ _
L: CLV:d Ca/qmn.l lu?,,:- do /Ol/c?//d/z/,:?h.t:
or
PROBABLECAUSE:~---~~------~----~-----~~------
EI/h(?r
C2 d/t20K.
Card or
4
d4rd C~/'d h4S
COMMENTS; ___________________________________________________
SCORESHEET
I
DATE
!NITIALS
I
39
20
Section
35
Page
Subsections
20
I
20
44
IBM 1130 ERROR RECOVERY SHEET
JOB
P~L/ 0#51&07
PROGRAM NAME
PAYOS
PROGRAMMER NAME
cc:Ju;J.,fA/YA/~A4& .1)'97"£
MESSAGE TYPED: C/'IECK NC). XXXXX
I'VE£K /170.
I<'.. ~~
C. R.C//Ck-
PAUSE - DISPLAYED IN ACCUM:
:x
~::H ~t! ~~jI(.
xx XXl5..
M;4X/MPAf!
A-?A Y8e
cRAlV'delC' Il$.,.... 3W77?:N7<;t, JW/7CH7$.
1!Jt:.~~1,. CN.t!!1.fJL.a:6. Z)%II. t:::.N.4-C..I;:. .du..,~~
c.~ect:.. ffJt!1.!?S.
c#£c.K. A~OI/,vT
I I I I I
/
~~~/kN4S RG"t:!fJv~sr~~/lA/b-~-:Ss
/
/
/
AFTER PAUSE, CONTROL TRANSFERS TO STATEMENT
&Le.X~ /a Set2.Ue.dC ~
~
DESCRIPTION OF WHAT IS WRONG:
tf?pe/'t:2.~Q.r &jL)b~C2
7
ro
CAd4r:ff-e!
C!e:J/J~t!~tI'? t!'~ .
PROBABLE CAUSE:
P~aa.t:b.
a L/.L2«L. .&,t:'2 .zll.;S
.,t2..0$~./LJ/ h:~
RECOVERY PROCEDURES:
.,~L/t2.~
a::zACh/'n('?
r~~d L:,;";;.s ~,..u t:;."'~t:2a.s.
COMMENTS;
SCORESHEET
I
DATE
LNITIALS
I I I I I I I I I
40
Section
35
Subsections
Page
I
45
20
IBM 1130 ERROR RECOVERY SHEET
JOB
7P~c:.~t/ ~$te*'.27
PROGRAM NAME
P~Y'c(JS
PROGRAMMER NAME
C. ,+?C//c-':..
PAUSE - DISPLAYED IN ACCUM:
MESSAGE TYPED:
ENrE,;tI~-d/~/'r "-Loc.~ ~tJ.02J.t!!!!.~ ,ec::>"-' ~~
~S~~£~ ~~~~~htla
CJCCdr~ T-ULCl. orr'
COMMENTS;
ZhiS
/t!)L/?
(2/'"
SCORESHEET
I
S-wt..rch
zera
&7/J~..or~ss
,---
EOr'.
/'t:J)w'//?l!!! 4..L/<2.IWL,S ~t2r /eya.r"'/4r~1Y ~r
A1LS~L,&~r='d ch"'G~s.
DATE
INITIALS
I I I I I I I I I
41
20
Section
35
Subsections
Page
I
46
20
20
IBM 1130 ERROR RECOVERY SHEET
JOB
P~~rcJ// ~S ftGJ/Y.7
PAYGJ6-
PROGRAM NAME
PROGRAMMER NAME
C.
Ie Click.
PAUSE - DISPLAYED IN ACCUM:
MESSAGE TYPED:
.1-:2£D UC7/t::>N VdY //OT
INI
/V1'AaF' ."cDR XXXX'
AFTER PAUSE, CONTROL TRANSFERS TO STATEMENT
I~/
0
1£ I
..5SCJ
DESCRIPTION OF WHAT IS WRONG:
The. &t::Q~S ,?)/not..//7~' 0/ /6../!!!?' Check-. ~Qr rh~~
e~LJ/Q-!:t.ee-~ {~>/?2 na.T-- 5'.t..!.~//c:/'et!.2.r r a c2.U<;2~ 7'&/'5
LZu.rb. (2c..'-i:.~d ded~c::.6.·a.t:::2.
PROBABLE CAUSE:
c~2L~t~&
d~d
at?/- a2.C1rK a~L/ ..~/e@k--.-!.
RECOVERY PROCEDURES:
A/of;~
COMMENTS;
r~L.s:
eh'll2L~etii?
.
7
L~
J
.,.',[(./.,p~rl//~CJ£1
Ua~j""
ro .at?
re~ 0 r
7
z!.-t<=?d' -Lo
~e
SCORESHEET
I
DATE
INITIALS
I
I
I
I
42
I
I
I
I
I
Section
35
IBM 1130 ERROR RECOVERY SHEET
JOB
P~ro// S~";d>":'8~
PrlYOSPROGRAMMER NAME c. K. ,.t::'//C k.PROG RAM NAME
PAUSE - DISPLAYED IN ACCUM:
MESSAGE TYPED:
#0/\./£
I
AFTER PAUSE, CONTROL TRANSFERS TO STATEMENT
0
I
0
I
a
I
2
I
9/
DESCRIPTION OF WHAT IS WRONG:
p~~~ t:a I'2L(t~ Y~~.a~·¥Llt!Z,~ar
t:2 e~r"
//?r/~7-I-= 'e S~
7L'/7@
===
=/?d
c!J~ c j; e c:K..:i
PROBABLE CAUSE:
:.. S=-LdL L
i.e b.
t2 t!? &.1"7 ser~ I-h<:;!
LS- h(l..s:.
~.t?~rL2r..t'>r.
RECOVERY PROCEDURES:
N~PCL
COMMENTS;
Pre.$.~
C
Sr{{l~f- ~o
P/'1LqLt::lQl
b..-c:'ci::.:s aM. a .t:j-~e~ r.ur"n
St:&t.Lz!.~h
/,:;
~L// .h~/r
,
rJh Su.,I/'-rr/'y L...57'
or'~ardt!2:::J
7~
~
eh'te~e.ar~ ?-~or-/Y7 r/a~~.a~e_~.)
_
Ca/?r/~e...
~~r
dnff
SCORESHEET
I
DATE
INITIALS
I
I I I I I I I I
43
Subsections
Page
I
47
20
20
Section
35
Subsections
Page
I
48
20
20
IBM 1130 ERROR RECOVERY SHEET
JOB
P£?~~// S:§:t:<).i~
PROG RAM NAME
PAY~S
PROGRAMMER NAME
C. R Chc,t.,
PAUSE - DISPLAYED IN ACCUM:
MESSAGE TYPED:
A/OA/c
I
AFTER PAUSE, CONTROL TRANSFERS TO STATEMENT
0
I
0
I
3
0
1
I
93
DESCRIPTION OF WHAT IS WRONG:
P4.(./se t~ c2.//L:)~
AC!.t!'/.2L::t::;;::.
7
t!2/""/ /.7 /~~-?:!1-
PROBABLE CAUSE:
~ ");~~·rt:;:.h
-rheL .o~/.lh7~L2~ ~ /:d~c..LS
the Lh/rd I/'rJe.
L. •.1:) A£~
be.e.t:z. .:se/
~
T~e O£?~/4~eJ~
7
RECOVERY PROCEDURES:
CAe~ ~~~ S;',~~~~.rC:;:::2;;~~ea .
COMMENTS;
SCORESHEET
I
DATE
INITIALS
I I I I I I I I I
44
Section
35
Subsections
20
IBM 1130 ERROR RECOVERY SHEET
JOB
P~C?<2//
P~YO~
PROGRAMMER NAME c.P.,t::/./Ck-
SJ1S.le t??
PROGRAM NAME
MESSAGETYPED: ___________________
PAUSE - DISPLAYED IN ACCUM:
AFTER PAUSE, CONTROL TRANSFERS TO STATEMENT
9S
DESCRIPTION OF WHAT IS WRONG: _______________________________________
PROBABLECAUSE:~~--------~----------------~------~----------
Se,v/rch
l,j-
hAS
&~t';2 \5er
4::1
rAe
RECOVERYPROCEDURES: _______________________________________________
COMMENTS: ________________________________________________________
SCORESHEET
I
DATE
INITIALS
I
45
I
20
Page
49
Section
35
Subsections
Page
I
50
20
20
IBM 1130 ERROR RECOVERY SHEET
JOB
Pa.y.r'~L/ S7~/e.n--7
PAYC}!:>PROGRAMMER NAME C. R. C//c.L
PROGRAM NAME
PAUSE - DISPLAYED IN ACCUM:
MESSAGE TYPED:
NOA/£
I
AFTER.PAUSE, CONTROL TRANSFERS TO STATEMENT
0
I
01 Is I
0
700
DESCRIPTION OF WHAT IS WRONG:
to.
£a./LSP
d!..e/b re
7
L ) , ' // /
~>
oL/~..!.
;"y;.
Me_--L2/L§1- r.; '~7e'7;1-
~~ C/Jt!PC~S
The. ·,!!/r~r.. ~/ C2.~
PROBABLE CAUSE:
S
U/ t!.
'Lc:./2
/~- hd;;.
ato
P£';2
~r:e~ ~ ;//7 e q.t2.~ri:7Tt::J /'? •
RECOVERY PROCEDURES:
C26.ec
h--P~S P"'C/t1[Jde.l sz!:.~~·r ~-2 C;2~lba.;:'.,Le
k'<)' tZre ~~qrleai
.c4,Lra. t:2.&"~/Yc::h
.::;7
k///e/7
L~
COMMENTS;
SCORESHEET
I
DATE
INITIALS
I I I I I I I I I
46
Section
Subsections
Page
I
51
35
20
IBM 1130 ERROR RECOVERY SHEET
PROGRAM NAME
PA Yo-S
PROGRAMMER NAME C
MESSAGE TYPED: _ _ _ _ _ _ _ __
/i?C//C.e:,
PAUSE - DISPLAYED IN ACCUM:
Me? xxx xx
AFTER PAUSE, CONTROL TRANSFERS TO STATEMENT
80e
DESCR I PTION OF WHAT IS WRONG: _---:-_ _ _ _ _ _-----,;-_ _ _,-;--_ _ _ _ __
~%!f;r~f~~t~;;£~3!~
PROBABLE CAUSE: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __
COMMENTS; _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __
SCORESHEET
47
20
Section
35
Subsections
I
20
20
Page
52
IBM 1130 ERROR RECOVERY SHEET
JOB
?t:?~ro// S~/t9#l
PAYOS
PROGRAM NAME
PROGRAMMER NAME
C. "eC//cL
PAUSE - DISPLAYED IN ACCUM:
MESSAGE TYPED:
ChECK:' /l/vNL[YR...1£ .4GR~
INI IN 1£ I
0
AFTER PAUSE, CONTROL TRANSFERS TO STATEMENT
BoZ
DESCRIPTION OF WHAT IS WRONG:
NOLhL~
PROBABLE CAUSE:
En~CJ/-
v ioh
/:"c?az!"ne
RECOVERY PROCEDURES:
A/oae
COMMENTS;
SCORESHEET
I
DATE
INITIALS
I I I I
48
I
I
I
I
1
Section
35
Subsections
Page
I
53
20
IBM 1130 ERROR RECOVERY SHEET
PROGRAM NAME
PA y
PROGRAMMER NAME
MESSAGETYPED: ___________________
REd'/.STfR
OS-
c: R. L:£/€~
PAUSE - DISPLAYED IN ACCUM:
7lJT~~~ X.J()()(~~XX; ~)()(~)(.
CH£CK rorAL oS'
X)(J('Xl('X~x.X)()(~)"(KI( •
.J)lrrf~&AK:.I!'S
X)(XX~)J()(X. )()("I()(.~K~·.
AFTER PAUSE, CONTROL TRANSFERS TO STATEMENT
~X"+
PROBABLECAUSE: ____~--~~~--------____________- - - - - - - - - - - - - - - - -
end ttl!
v
/oh
RECOVERYPROCEDURES: ______________________________________________
COMMENTS; ________________________________________________________
SCORESHEET
I
DATE
INITIALS
I
49
20
Section
35
Subsections
Page
I
54
20
20
IBM 1130 MACHINE SETUP SHEET
PROGRAM
NAME:
Ch8C/<
PROGRAM
NUMBER:
#/,/f//~
APPROXIMATE
RUNNING TIME:
PROGRAM
DESCRIPTION:
TYPE OF PAPER
PRINTER
NO. OF COPIES
CARRIAGE TAPE
C~ec./cs
Chec.£"s
0
DRIVE NUMBER:
DISKS
C)
v
SWITCH
UP
DOWN
St:,U/rch (Z)/S
1
3
2
[>(X
197-..9',,0//
CARTRIDGE
ID:
SWITCH
SETTINGS
INPUT
CARDS
?AYG?S
SWITCH
UP
DOWN
C/sed' ;-" n-lt:7ke
/4
v-
4
C0:X
SWITCH
UP
DOWN
/S"
v
che'c.kS," r'e~/'/~"-:- 4/-he/7:/-6e!:t' t:::('/e
/'101 ?tCJ/'/'ecl:
Su//:l-C.h /4/~') (/Se!d TO s&r /-~e?' OJt:?.x/~;;.:.;/?;·
Sun/en /S/5
c./se4"
rc; seT
4nd ~CJ .s7'CJ/, rle -5"ys/~~J
cAc:>cL ,q"?7t::::J~",_r.
rAe check nv~,6er J-c
/0 a/j'n
s/arr U//IA',
r/:e ~r/r/~e,. .
(CONTROL.
TOTALS
(IIXEQ
/ 1/ Jo~
SOURCE OF INPUT:
PAY05 I - - -
-
/. Cor.'lco l /C;ldi.r.
//"".:;);?-7
//i~ ..2).
2,»./$,~ cZ2~~t. ~~ .a 2Yr dL/ rd/~I:.
7
DISPOSITION OF OUTPUT:
~r' am.- ~~~s..
/. P~C-A¢X.k,s. i~ e ~Qh.:.f.IPe S
7)£. ~ ...
E c.a~ Irt::.'aL 6:J. i!4/~ "-'/~ ~e c<..s:.e.d ?Ut...th. JD~O~
2.
FOR PAUSES AND ERROR MESSAGES SEE ERROR RECOVERY SHEETS
50
Section
35
Subsections
20
I
20
PAY06: CHECK REGISTER
Accounting Controls
Pla.nt total (net) from payroll register is balanced to total on check register, and check register
total (net $) is balanced to adding machine tape of checks.
51
Page
55
Section
35
Subsection.s
Page
I
56
20
20
IBM 1130.RROR RECOVERY SHEET
JOB
~C/2tL. ,.'Sf:st.:s..t~q7
PAYL/(&J
PROGRAMMER NAME c: P. ,I'://c.£
PROG RAM NAME
PAUSE - DISPLAYED IN ACCUM:
MESSAGE TYPED:
C#cC.L~
cc.~a
t.
CC
t!?N..
AA/(2
~~rCL.2R.a
I
0
0
01
I I/
1
AFTER PAUSE, CONTROL TRANSFERS TO STATEMENT ..9~.99";;
OESeR t·PTION OF WHAT IS WRONG:
L. C tt?r'c?
M
a ua:1.,a ec!.
a t2. L<'l~l:.l a i
A~~
...
j
C'/'"
:?e CaGd CaLu. r h tt;2
~-
Ao.
4..a //JYd..L/d ..t2.t'~d..r
....
£1'
r t2. t:2. ",t- zer"o
PROBABLE CAUSE:
£.i ~ e.t:::.
1J.t2..r:.
.ae.e.~
"7
d
..6/4..a.k
aL~,.,-.pd
(;'d.rd
vyuaa:r
t::;~.t:2.
d~t<2.
c-t2./'d
e!?:/' deGL .
RECOVERY PROCEDURES:
r/eA.r'
7'-he.. c.a.t::d
~~Adl!!?""·c ~/4C.e.
a
~#e~.t;A::!;~~':-~~P;;'~r4~
~~,: -"" a Ia ,t-&.~ . t:::.t2.b. ~a 6te.
It
.
.....r
COMMENTS;
SCQRESHEET
I
DATE
INITIALS
I I I I I I I I I
52
Section
35
Subsections
20
IBM 1130 MACHINE SETUP SHEET
PROGRAM
NAME:
Chec~
PROGRAM
NUMBER:
-Pc=y/s .f-er
APPROXIMATE
RUNNING TIME:
PROGRAM
DESCRIPTION:
TYPE OF PAPER
PRINTER
DISKS
SWITCH
SETTINGS
PAYOCP
NO. OF COPI ES
S/Qr.;ddtl"'.?
/
DRIVE NUMBER:
0
CARTRIDGE
ID:
/b:f/'~//
SWITCH
UP
DOWN
CARRIAGE TAPE
S,l-d/7de:?'-c/
1
No/?e
3
2
X XX X
-',,-
SWITCH
UP
DOWN
SWITCH
UP
DOWN
INPUT
CARDS
(CONTROL
TOTALS
(//XEQ PAY~ f - - -
/// JOB
SOURCE OF INPUT:
DISPOSITION OF OUTPUT:
-
/. .D'
_/.5!:;, t:I
C QCl.
4
t.eaL
.,t.ot~Ls
./rorQ PAYcJ.. ~-
l C-~ .... c k
Lf7!s/e,-, /~ /::Jo'§jro// ....5"&C /~on
r1.. c:.-~aa::.aL~?2.~~/";- LQ tc./c:::. l)
J . .2:J/si: t:..... /'~tt:£:.~C2 ~~LQ
sic,t::.·t::if!f-e.
FOR PAUSES AND ERROR MESSAGES SEE ERROR RECOVERY SHEETS
53
I
20
Page
57
Section
35
Subsections
Page
I
58
20
20
PAY09: 941 REPORT
Accounting Controls
941 total per plant (Gross $) is balanced to general ledger.
54
Section
35
IBM 1130'ERROR RECOVERY SHEET
JOB
P~r~// ~..s::/e-'22
PROGRAM NAME
~1l.~9
PROGRAMMER NAME
CR K//cA:-
PAUSE - DISPLAYED IN ACCUM:
MESSAGE TYPED:
INI IN Ie I
CJ
A/a~~LE
AFTER PAUSE, CONTROL TRANSFERS TO STATEMENT
.Alt2a~
DESCRIPTION OF WHAT IS WRONG:
N£:?/Je
_.-
.
PROBABLE CAUSE:
A/o.l?e
RECOVERY PROCEDURES:
N/2/7e
COMMENTS:
Nr2/7t52
SCORESHEET
I
DATE
INITIALS
I I I I I I I I I
55
Subsections
Page
I
59
20
20
Section
35
Subsections
20
I
Page
20
60
IBM 1130 MACHINE SETUP SHEET
PROGRAM
NAME:
PROGRAM
NUMBER:
J41 REPORT
APPROXIMATE
RUNNING TIME:
PROGRAM
DESCRIPTION:
TYPE OF PAPER
PRINTER
NO. OF COPI ES
94/TAPE
CARTRIDGE
SWITCH
UP
DOWN
1
0
PAYROLL
10:
SWITCH
SETTINGS
CARRIAGE TAPE
941 FORMS
DRIVE NUMBER:
DISKS
PAY09
/VOA./£
2
3
XXXX
SWITCH
UP
DOWN
INPUT
CARDS
SWITCH
UP
DOWN
(
9
( MDRE
PL,qNTS
f(LFlNT
lJ5.ft%1VT NO,
'(;iRNT
For t:)ne "p/4rJ.f
CIT~ -
.5 r~T£
CR/flD
( PLPiN-r
~'jfJjf5J
( ,Pt.ANT
NAME
CRRb
(.PLAN7
H~1tER
CAR
I---
I---
-
-
r-
fl XEty PAY09 I--/
II C/08
SOURCE OF INPUT:
DISPOSITION OF OUTPUT:
-
!- PI Clnt
z.- Pd..~rOn
4
inf'()I"ma.:t.ion
ellS/(
C4.rds Froln
{jom stor~ ~
=:
f- J41 ,...~"rt io #Overll.~i
2- J)/$!c I.s ,..e-tu,..l1.~= ~o st;;3- p, «-not {/?~o,.m~ loa a«tTI~ s!Q .file £"
FOR PAUSES AND ERROR MESSAGES SEE ERROR RECOVERY SHEETS
56
File £
Section
40
Subsections
Page
I
01
00
00
Section 40: CONVERSION
CONTENTS
Introduction
Planning for Conversion ............ .
40.01. 00
40.10.00
Preparing for Conversion ............ .
Conversion Methods ...............•..
40'.20.00
40.30.00
Section
40
INTRODUCTION
For each application, there will come a day when all
your programs are written and tested, and you will
be ready to convert from your old system to the new.
Subsections
Page
I
01
01
00
Will you be ready? Not unless you have planned
and prepared for conversion. Conversion involves
three major elements, of which the conversion itse If is the last step.
Section
40
Subsections
Page
I
01
10
00
PLANNING FOR CONVERSION
As h:a:s been.tressed, the first step is planning.
This involves two basic items:
1. Make a schedule indicating when you will
start conversion of each application and when conversion will be complete. After you have completed
conversion of your first application, you will have a
better feel for what is involved, and will want to review the schedule for the remaining areas. You may
also want to reevaluate the conversion techniques
you chose originally.
2. Decide which conversion technique you will
use for each application area. As above, you will
want to periodically reexamine your deCisions as
you become more experienced with each technique.
Section
40
PREPARING FOR CONVERSION
After making up conversion schedules and choosing
techniques, you should be able to see what must be
done to prepare for the actual conversion. Ask
yourself these questions:
1. Is the old system documented accurately and
completely? (See Section 10.) If it isn't, a smooth
conversion will be difficult.
2. Can the controls of the two systems be compared? If not, it will be difficult to compare the
two systems. The new system should have the same
controls as the old, and you may even want to add
controls to the old system to ease conversion.
Subsections
Page
I
01
20
00
Such controls as grand totals, subtotals, document
counts, etc., will bring quick attention to discrepancies between the two systems.
3. Is everyone who is involved in the conversion
familiar with both the old and new systems? Misunderstandings regarding the differences between the
old and new can seriously interfere with and delay
the successful completion of even the best planned
conversion effort. Communications should be maintained with the people involved during the entire
application design and program development phases.
A few weeks before the conversion period, all those
who will be involved indirectly or directly in preparing input or using output from the new system
should be taught both systems, in general--and their
particular areas of responsibility, in detail.
Section
40
Subsections
30
I
00
Page
01
CONVERSION METHODS
There are three common methods for conversion:
1. Parallel operation. With this method, the same
transactions are entered into both the old and the
new systems, and the controls are compared. This
process is continued over a predetermined (usually
short) period of time, until a responsible executive
is satisfied that the new results are accurate.
Make sure that the time period of parallel
operation is one during which a wide variety of
transactions occur. Large volume is not important,
but variety is, since you want to test as many aspects of the new systems as possible. Pick a slow
time in your business cycle to effect conversion.
Before starting parallel operations, obtain a'
clear understanding of what is to be checked, and by
whom. Since additional personnel or man-hours
will be needed during this period, avoid conflicts
with vacation and holiday schedules.
As far ahead of the parallel period as possible, the personnel who will be preparing the input
cards for the new system should gain experience in
using the new input document and card formats.
This is one of the most common areas of difficulty,
and many "computer" mistakes are eventually traced
back to faulty document preparation, accumulation
of controls, or card punching. Often it is possible
to use new formats exclusively some time before
the computer system arrives, by preparing cards in
the computer-required formats and then reproducing
them into the old formats for use by the current
system.
Parallel operations often encounter problems
that result from significant differences between the
procedures used in the old system and those in the new.
It may be quite difficult to compare results produced
by the two systems, since the important totals in the
new system may not have been prepared previously.
Or you may find it possible to print reports in a
desirable sequence which is not feasible currently,
but which will make it impractical to cross-check
line-items against reports in the old sequence.
Another problem inherent in parallel operations is the doubled probability of errors. There
are twice as many chances for errors to occur, and
when making up a schedule, you must consider the
time spent in tracking errors down and deciding
which system, if either, was right.
2. Pilot Operation. In pilot as in parallel operation, an application is run under both the old and the
new systems. The difference lies in selecting only
one or a few easily observed locations or departments within the company, and performing the
operation only for those sections rather than for the
entire company. The same care must be taken in
setting up controls, scheduling the period during
which the pilot operation is to take place, and training those who prepare the input. In regard to this
last problem, the pilot method offers a training
ground for those who prepare and punch the data, by
allowing different people to get experience every day
or every few hours.
Care should be taken in determining which
part of the job is selected for pilot running. It
should be completely independent and self-contained,
if possible. Therefore, pilot operations may be the
ideal choice for organizations that are divided into
fairly independent units or locations. In any case,
the effect of the pilot run on departments other than
the data processing department must be carefully
analyzed, and those who are affected should be notified we 11 ahead of time.
Again, you must carefully establish who is to
do what and when, if an adequate analysis of the progress and success of the operation is to be made.
3. One-time cutover. As of a given date, the
old system is discontinued and the new system is put
into operation. Careful planning is necessary to
make the transition smooth. For one thing, files
can be built up during a fairly extensive period beforehand and checked with control figures for accuracy and completeness while being created .. A
master file of customers can be card-punched
during the month before the preparation of statements. Alternatively, only new customers' cards
can be punched, while operations are performed on
the old file to convert them into the new format.
Then both the old and new cards are merged at
month end to create an updated master file ready for
use by the new system. It is often desirable to write
one-time programs to do these file conversions.
Whether the computer or other equipment is used,
time must be scheduled for the coding or procedure
writing, as well as for the operation itself.
Where some data is to be recoded, or coded
for the first time, as in the assignment of a new or
better set of customer numbers, you should get the
job done and checked out in advance.
Another way of smoothing the cutover is to
maintain control procedures that will be required
for both the old and new systems some time before
the critical date. This will eliminate the possibility
of errors in the execution of these procedures.
Section
40
Cutovers are never truly "one-time" in the
sense that no parallel or pilot operations are performed. The difference is in the time at which
these operations are done. With the cutover method,
parallel and pilot operation take place with data that
has already been processed. For instance, after an
accounts receivable procedure has been processed
under a current system, the entire procedure is run
again on the computer. Controls are checked and
errors are cleared up. The accounts receivable
may then be run once more on the computer, and
this process may be repeated, perhaps over more
than one month, until management is satisfied that
it is running correctly.
Although some double manpower requirements
may be eliminated by using the one-time cutover
method, extra man-hours will still be needed--for
example, when a weekend immediately precedes the
cutover date, or when card files are being converted
from one format to another.
****
Subsections
Page
I
02
30
00
You can see 'that no one of the conversion methods
discussed here stands alone and independent of the
others. Use the elements of each that suit your
situation, but develop a realistic plan that will consider these factors:
1. Manpower must be available at the right time
to manipulate old data into new formats.
2. Control procedures must be developed and, if
possible, tested ahead of time.
3. Detailed document preparation and cardpunching procedures must be developed, and a
reasonable amount of time must be reserved to
practice them before conversion.
4. Procedures must be written for the one-time
aspects of the job, and manpower must be available
at the right time to do so.
5. The word must be spread; education for those
in other departments must be done thoughtfully and
carefully.
It is almost impossible to plan a conversion too
carefully.
Section
45
Subsections
Page
I
01
00
00
Section 45: 1130 COMPUTING SYSTEM
CONTENTS
Introduction. . . . . . . . . . . . . . . . . . . . . . . . ..
The 1131 CPU .......................
Console Printer and Keyboard. . . . . ..
Data Switches. . . . . . . . . . . . . . . . . . . . ..
Console Display Lamps ............ ,
Disk Storage ........................ ,
Printers. . . . . . . . . . . . . . . . . . . . . . . . . . . ..
Card Readers and Punches ............
45.01. 00
45.05.00
45.05.10
45.05.20
45.05.30
45.10.00
45. 15. 00
45.20.00
Paper Tape Readers and Punches .......
Plotter ...............................
Graphic Display .......................
Optical Readers .......................
Storage Access Channel ................
Teleprocessing ........................
The 1130 Configurator .................
45.25.00
45.30.00
45.35.00
45.40.00
45.45.00
45.50.00
45.55.00
Section
45
INTRODUCTION
The IBM 1130 Computing System is a flexible,
modular, and modern data processing system. In
capability, it can range from a small paper-tapeoriented system to a large, multiple-disk system,
with a powerful complement of input/output devices.
Subsections
01
I
00
Page
01
This section describes the system components in
general terms, stressing their potential use, the
various possible combinations of units, and their
corresponding throughput capabilities. For more
detail see IBM 1130 Functional Characteristics
(A26-5881) and IBM 1130 Input/Output Units
(A26-5890).
Section
45
Subsections
Page
I
01
05
00
1131 CENTRAL PROCESSING UNIT
The 1131 CPU is available with three options:
• With or without disk storage
• 3.6- or 2. 2-microsecond core storage access
time
• 4096, 8192, 16,384, or 32,768 words (16 bits)
of core storage
Although this yields 16 possible combinations, only
9 are currently available, as shown in Figure 45.1.
All 1131 CPUs, regardless of model, have as
standard components:
• A console printer
• A console keyboard
• 16 data switches
• Console display lamps
• Processing functions (index registers, indirect addressing, multiply/divide, etc.)
Without
Disk
Storage
With Disk Storage
3.6
Microsecond
Core
Storage
Capacity
Model
Designation
Figure 45.1.
2.2
Microsecond
3.6
Microsecond
4K
8K
4K
8K
1A
18
2A
28
16K
32K
8K
16K
32K
2C
2D
38
3C
3D
Available 1131 Processing Unit Configurations
The first four components are described below in
more detail, since they may be directly used by
the programmer.
Section
45
Console Printer and Keyboard
The console printer is a modified SELECTRIC®
typewriter printer and can provide output at 15. 5
characters per second. If it is the primary (only)
printing device on the 1130, it must be used for all
printed output; however, if the system includes an
1132 or 1403 Printer, the console printer will normally be used only for error messages, operator
instructions, etc.
Subsections
Page
I
01
05
10
The console keyboard resembles a standard
typewriter keyboard and allows the 1130 operator to
enter data into the system.
Because it is a manually oriented device, the use
of the keyboard will usually be limited to small
quantities of data (today's date, starting check number, etc.), with the card or paper tape readers used
for more vol uminous data.
Section
45
Subsections
Page
I
01
05
20
Data Switches
Mounted on the front face of the console printer is
a row of 16 toggle switches, called data switches.
They may be used by the programmer for the entry
of yes-or-no type information into the system. For
example, one payroll program might handle both
factory workers and office workers, with each group
processed separately. The program could be
written to read, say, data switch 6, treating the input time cards as factory workers if that switch is
on, and as office workers if it is off.
other uses of the console switches are to bypass
certain portions of a program, activate the
FORTRAN TRACE, etc.
Section
45
Console Display Lamps
Above the console printer is a panel containing a
large number of indicator lamps (or lights). These
lights indicate the internal status of the 1130 Computing System. While most are of little use to the
average programmer, he does have access to one
set of lamps: the accumulator.
The accumulator is displayed as a series of 16
numbers, in four groups of four, which are either
illuminated (backlighted) or not. For example, suppose the accumulator indicates the status shown below, where the underlined numerals are lit:
10 ! 2 31.1.
5 6
71 ~
9
10
11
Ig
13
14
121
Since the accumulator displays a binary number,
this example means that it contains 0100 1000 1000
1001, or 18569 in decimal. An easier way to represent the number is to use the hexadecimal notation,
IBM 1131 Central Processing Unit with disk drive
Subsections
05
I
30
Page
01
where each group of four "bits" is taken as a hexadecimal nu mber, obtaining 4889. (For further detail
on number systems, see Appendix A of A26-5881. )
The programmer can use the accumulator
display feature by appending a four-digit number
(from 0001 to 9999) to the FORTRAN PAUSE or
STOP statements. If the programmer inserts a
PAUSE 3322 statement in his program, the CPU will
pause and display 3322 in the accumulator (as a
hexadecimal number) when it executes the PAUSE
statement:
10 .1 2 ]3.1 4
§. 6
1.1 8
9 .!Q
11112 13
14 151
If the program contains many PAUSEs, each may
be given a different number, and the operator can
determine which PAUSE caused the CPU to halt its
operations.
This facility is useful for indicating error conditions, tracing progress through a program, etc.
Section
45
Subsections
10
I
00
Page
01
DISK STORAGE
Models 2 and 3 of the 1131 CPU contain a disk storage drive as an integral part of the console unit. In
addition, these models may contain up to four additional disk drives, mounted in separate enclosures
(the IBM 2310 Disk Storage).
Each disk drive will hold one IBM 2315 Disk
Cartridge. Because the cartridges are removable,
the user may have an unlimited amount of data on
them; only one, however, may be mounted in a disk
drive at anyone time.
The 2315 cartridge consists of a single metal
plate, coated on both sides with magnetic material
and enclosed in a plastic container. When mounted
in an activated disk drive, the metal plate is driven
through a clutch mechanism at 1500 revolutions per
minute. The recording plate never leaves its container, as it does in the case of some other disk
devices.
Each cartridge is divided into 200 cylinders, in
concentric circles, with each cylinder further divided into eight sectors - four on the top surface
and four on the bottom. Since each of the 1600
sectors contains 320 words, each disk cartridge can
hold 512,000 words.
Data is read or written on the disk by two readwrite heads attached to a movable arm. One setting
of the arm gives the 1130 access to one cylinder, or
eight sectors. One head reads (or writes) the top
four sectors; the other, the bottom four sectors.
The two heads cannot move independently, since they
are fixed to the same arm.
Because one setting of the arm gives access to
only one cylinder, the arm must be moved in order
to read or write on a different cylinder. For example, to read from cylinder 10 and then write on
cylinder 15, the arm must move, or "seek", from
cylinder 10 to cylinder 15. Since the arm moves in
steps of one ortwo cylinders, this would require two
2-cylinder moves (from 10 to 12, and from 12 to
14) and one I-cylinder move (from 14 to 15).
Each move, whether one or two cylinders in
length, takes 15 milliseconds (0. 015 seconds). A
five-cylinder "seek", as shown above, would take
45 milliseconds (15+15+15). A six-cylinder seek
would take the same length of time.
Because this can be a relatively lengthy operation (compared with other 1130 functions), you
should attempt to minimize the need for disk arm
movement. Many hints on how to do this are given
later in the manual (Sections 55, 60, 65, 70, 80,
85, and 90).
Having reached the desired cylinder, the arm
takes another 25 milliseconds to stabilize. After
the stabilization period, data may be read or written;
because the disk is rotating, however, it will be
.quite unusual for the desired sector to be passing
under the read/write head at the precise time you
want it. You will have to wait an average of half a
revolution (20 milliseconds) for the sector to reach
the heads, and then 10 more milliseconds for it to
actually be read or written.
Figure 45.2 gives some examples of how long it
takes to move n cylinders, then read one sector.
Move This
Many Cylinders
Seek
Time
Stabilization
Time
Average
Rotational
Delay Time
None
0
0
20
Read
or Write
10
1 or 2
15
25
20
10
70
10
85
Total
30
3 or 4
30
25
20
5 or 6
45
25
20
10
100
1500
25
20
1'0
1555
199 or 200
(maximum)
Figure 45.2.
Section
45
IBM 2310 Disk Storage Drive
IBM 2315 Disk Cartridge
Subsections
Page
I
02
10
00
Section
45
Subsections
Page
I
01
15
00
PRINTERS
In addition to the console printer, which is standard,
the 1130 system can be configurated with four combinations of line printers:
No line printer
An IBM 1132 Printer
An IBM 1403 Printer
Both an 1132 and 1403 Printer
The 1132 and the 1403 Printers have many mechanical differences, but the primary difference is
IBM 1132 Printer
in printing speed. Both print a line at a time, 120
characters wide; both have a carriage control tape
that controls the vertical movement of forms.
The 1132 has a rated speed of 110 lines per minute when printing purely numeric and 80 lines per
minute when printing alphameric information.
The 1403 prints both numeric and alphameric
information at the same speed; 340 lines per minute
(maximum) in the case of the 1403 Model 6, 600
lines per minute (maximum) for the Model 7.
Section
45
IBM 1403 Printer
Subsections
Page
I
02
15
00
Section
45
Subsections
Page
I
01
20
00
CARD READERS AND PUNCHES
Five card readers and/or punches are available for
attachment to the 1130 system.
The IBM 1142 Card Read Punch, Model 6, reads
and punches cards, with all input from a single
hopper. It reads at a rated speed of 300 cards per
minute, and punches at 80 card columns per second.
The IBM 1442 Card Read Punch, Model 7, is
similar to the Model 6, but faster, reading at 400
cards per minute and punching at 160 columns per
second.
The IBM 1442 Card Punch, Model 5, cannot read
cards; it can only punch. Its punching speed is 160
columns per second.
The IBM 2501 Card Reader, Model A1, will read
cards at a rated maximum speed of 600 per minute.
It is not able to punch cards.
The IBM 2501 Card Reader, Model A2, is similar to the A1, but operates at 1000 cards per minute
(maximum).
Disregarding speeds for the moment, there are
four combinations of card readers and/or punches
for the 1130:
IBM 1442 Card Read Punch
No card readers or card punches
2. An IBM 1442 Card Read Punch
3. An IBM 2501 Card Reader and the IBM 1442
Card Punch, Model 5
4. An IBM 2501 Card Reader and an IBM 1442
Card Read Punch
Aside from speed, the main difference between
combinations is capability - the number of card
paths available.
Configuration 2 (1442 Model 6 or 7) gives the
user only one card path. This means that cards to
be read and cards to be punched must both be placed
in the same input hopper in the proper order.
Configuration 3 (2501 and 1442 Model 5) has separate paths for reading and punching, which simplifies programming and operating in certain types of
applications.
Configuration 4 (2501 and 1442 Model 6 or 7) also
has two card paths, differing from configuration 3
in that one path can both read and punch. In certain applications this can be very useful. For example, you could put a master card deck in one
reader and a detail deck in the other reader, eliminating the need to collate (merge) the two together.
1.
Section
45
IBM 2501 Card Reader
Subsections
Page
I
02
20
00
Section
45
Subsections
Page
I
01
25
00
PAPER TAPE READERS AND PUNCHES
The 1130 system may include the IBM 1134 Paper
Tape Reader and/or the IBM 1055 Paper Tape
Punch.
IBM lOSS Paper Tape Punch
The 1134 reads punched tape at 60 characters per
second; the 1055 punches tape at 15 characters per
second.
IBM 1134 Paper Tape Reader
Section
45
PLOTTER
For hard-copy graphic output, the IBM 1627 Plotter
may be attached to the 1130 system. Bar charts,
flowcharts, organization charts, engineering drawings, and maps, in addition to graphs or drawings
that depict financial, scientific, or technical data,
can be plotted on the 1627 Plotter.
Two models are available:
Modell
11 inches by 120 feet
Plotting area:
Step size:
1/100-inch increments
300 steps per second
Speed:
IBM 1627 Plotter
Subsections
30
I
00
Page
01
Model 2
Plotting area:
29-1/2 inches by 120 feet
Step size:
1/100-inch increments
Speed:
200 steps per second
The 1627 can plot curves, straight lines, alphameric headings, etc., by a series of steps in which
either the pen, the drum, or both, move in
1/100-inch increments.
Section
45
Subsections
35
I
00
Page
01
GRAPHIC DISPIA Y
A second means of graphic display may be obtained
by attachment of the IBM 2250 to the 1130 system.
The 2250 is an electronic (cathode ray tube) device,
IBM 2250 Display Unit
and therefore capable of faster speeds than the
1627 Plotter, a mechanical device. A "light pen"
enables the operator to communicate with the
system by interacting with the display on the face
of the tube.
Section
45
OPTICAL HEADERS
The IBM 1231 Optical Mark Page Header reads
positional marks made by an ordinary lead pencil
on paper documents, such as test scoring sheets,
etc. The data contained on these documents can be
IBM 1231 Optical Mark Page Reader
Subsections
Page
I
01
40
00
read into the 1130 system at a rate of 2000 sheets
per hour.
The 1231 is especially suited for applications
such as examination grading, surveys, order entry,
etc., where variable information may be entered by
hand on preprinted forms.
Section
45
Subsections
Page
I
01
45
00
STORAGE ACCESS CHANNEL
The storage access channel provides an input/ output "path" that allows nonstandard components to be
added to the 1130 system. These components may be
IBM - supplied, or user-supplied. Since the
SAC is merely a general purpose input/output
channel, control of the nonstandard component
must be handled by user-supplied hardware and/or
programming.
Section
45
TELEPROCESSING
By means of the Synchronous Communications
Adapter (SCA), the 1130 may communicate, over
Subsections
Page
I
01
50
00
telephone lines, with another 1130, an IBM
System/360, and/or other devices.
Section
45
Subsections
Page
I
01
55
00
THE 1130 CONFIGURA TOR
The accompanying schematic is a copy of the 1130
Configurator (A26-5915).
1130 Configurator
Model I,
Mode I 2,
A = 4k, B = 8k
3.6 Microsecond Core Storage
A = 4k
3.6
B = 8k C = 16k D = 32k
M(croseco~d Core St~rage
(Includes Single Disk Storage Drive)
Model 3,
B = 8k, C
= 16k,
D = 32k
2.2 Microsecond Core Storage
(Includes Single Disk Storage Drive)
Sto"dard Features:
Attachment
'7923
: Attachment
1627 Attachment
1627 Attachment
'7187
'7189
'3623
Bose Unit
1134 Paper Tape
May only be installed
on 1131 Models 2 and
3, 208/230 volts power
Reader
60 Ch/Sec
Model 2 has
Supply and
Take-Up Reels
Requires Channel
Multiplexer
1627 Plotter
Modell
300 Pts/Sec
12" Chart
1627 Plotter
Model 2
200 Pts/Sec
30" Chart
Section
50
Section 50: 1130 DISK MONITOR SYSTEM
CONTENTS
GENERAL ••.•••••••••••••••••••••••
50.01.00
Subsections
Page
00
01
00
I
Section
50
GENERAL
This section consists of a general discussion of
the 1130 Disk Monitor System and serves to introduce the next three sections:
• Job Management - - how the Monitor helps
you achieve smooth, orderly, automatic transition
from each job to the next.
• Disk Management - - how the Monitor helps
you manage the disk and use it efficiently.
• Core Storage Management - - how the Monitor
allows you to make the most effective use of the
available core storage.
If your 1130 does not have disk capability, you
cannot use the Monitor, and you may skip over this
and the succeeding three sections.
The 1130 Disk Monitor System is a disk-oriented
operating system that allows the user to assemble,
compile , and/or execute individual programs or
groups of programs with a minimum of operator
intervention. Jobs to be performed are stacked
and separated by control records that identify the
operation to be performed.
The Monitor System consists of five distinct but
interdependent programs (see Figure 50.1):
Supervisor Program
Disk Utility Program
Assembler Program
FORTRAN Compiler
Subroutine Library
The supervisor program provides the necessary
control for the stacked-job concept. It reads and
analyzes the monitor control records, and transfers
control to the proper program.
,--
-
-
--1130 DISK MONITOR SYSTEM -
-
-
-
,
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
IL
_________________
Figure 50.1. 1130 Disk Monitor System
~
Subsections
Page
I
01
01
00
The Disk Utility Program is a group of routines
designed to assist the user in storing information
(data and programs) on the disk, and in retrieving
and using the information stored.
The Assembler program converts user-written
symbolic-language source programs into machinelanguage object programs.
The FORTRAN compiler converts user-written
FORTRAN-language source programs into machinelanguage object programs.
The Subroutine Library contains subroutines for
data input/output, data conversion, and arithmetic
functions.
The Monitor System coordinates program operations by establishing a communications area in core~
storage that is used by the various programs making up the Monitor System. It also guides the transfer of control between the various monitor programs and the user's programs. Operation is continuous and setup time is minimized, thereby effecting substantial time saving and allowing greater
programming flexibility. The complete Monitor
System resides on disk storage, but only those
routines or programs required at anyone time are
transferred to core storage for execution. This
feature minimizes the core storage requirements
and permits segmenting of long programs.
In addition to providing you with an efficient jobto-job transition system, the 1130 Disk Monitor
System significantly reduces the amount of programming you must do. This is made possible
through the sharing of common subroutines by unrelated programs. For example, input/output or
conversion operations are required by most user
programs, whether the programs are written in the
Assembler Language or in FORTRAN. IBM provides a library of subroutines to handle such operations as an integral part of the Monitor System.
The Disk Utility Program (DUP) facilitates
development of a library of user programs. Programs can be stored on cards or paper tape, as is
customary in installations without disk storage.
With disk storage, programs can also be stored
directly on the disk. The disk-stored programs
and data are referred to by name when called for
use. The Monitor System, through the use of a
table known as the Location Equivalence Table
(LET), can locate any user program, subroutine,
or file by a table search for the name. Stored with
the name is the amount of disk storage required
by the program or data.
Any program that is added to the user's diskstored programs is usually placed at the end of
Section
50
Subsections
01
I
00
Page
02
the other programs. If a program is deleted, the
remaining program(s) are moved up on the disk
in order to utilize disk storage effectively.
Detailed descriptions of the 1130 Monitor System
and its components may be found in the Systems
Reference Library (SRL). For Version 1 see
IBM 1130 Disk Monitor System (C26-3750). For
Version 2 see IBM 1130 Disk Monitor System,
Version 2, Programming and Operator's Guide
(C26-3717).
Section
55
Subsections
Page
I
01
00
00
Section 55: THE MONITOR-JOB MANAGEMENT
CONTENTS
Introduction. . • • • . . • • • . . • . • • . • • • . . • • ..
Job and Subjob . . • • . • . • . . • • • • • • . • • •. . ..
55.01.00
55.10.00
Stacked Jobs or the Input Stream. .• •• ••
Disk Cartridge ID Checking .•..••.•.•.
55.20.00
55.30.00
Section
55
INTRODUCTION
The first function of the 1130 Disk Monitor System
is Job Management -- helping you, the user,
Subsections
Page
I
01
01
00
achieve a smooth, orderly transition from one job
to the next. The Monitor is designed to accept a
continuous stream of input, in the form of jobs and
subjobs.
Section
55
Subsections
Page
I
01
10
00
JOB AND SUBJOB
A job is defined as:
• A JOB card and all the following control records, source programs, object programs, and data,
up to, but not including, the next JOB card.
• The processing that takes place from the detection of one JOB card (or paper tape record) until
the detection of another JOB card.
A subjob is defined as:
• A monitor control record and all the following
control records, source programs, object programs,
and data, up to, but not including, the next monitor
control record.
• The processing that takes place from the detection of one monitor control record (such as DUP
card, FOR card, etc.) to the detection of another
monitor control record.
A job is an independent unit of processing; a
subjob is a unit of processing that is dependent on
the subjob(s) preceding and/or following it. The
successful completion of the job depends on the
successful completion of each subjob within it. In
some cases, a subjob is not attempted if the preceding subjobs have not been successfully completed.
The JOB control record defines the start of a new
job. It causes the Supervisor to perform the job
initialization procedure, which includes:
1. Initialization of constants, parameters, etc.
2. Setting of the temporary indicator if a T is
present in column 8 of the control record. If set,
all programs or data files stored in the User Area
by DUP during the current job will be deleted automatically at the end of the job (that is, at the beginning of the next job) .
3. The identification of the cartridge(s) to be
used during the current job.
4. The definition of the cartridge on which the
Core Image Buffer for the current job is to be
found. Core image programs can be built faster if
the CIB is assigned to a cartridge other than the
systems cartridge. (This applies only to systems
with two or more disk drives.)
5. The definition of the cartridge whose Working
Storage is to be used by the Monitor system. (This
applies only to systems with two or more disk
drives.) Although all cartridges contain a Working
Storage area, only one will be used by the Monitor
(for its own purposes). Core image programs can
be built faster if the system Working Storage is on
some cartridge other than the systems cartridge.
They can be built even faster if the CIB, the system
Working Storage, and the monitor system itself are
on separate cartridges. Assemblies are also faster
if Working Storage is on a separate cartridge.
6. The starting of a new page. A skip to channel
1 is executed on the 1132 Printer or 1403 Printer;
ten consecutive carriage returns are made on the
console printer.
Section
55
Subsections
Page
I
01
20
00
STACKED JOBS OR THE INPUT STREAM
JOB 3
Figure 55.1 shows a schematic view of a stack of
three jobs:
• Compile a FORTRAN program (subjob 1)
• Execute it (subj ob 2)
Here, the reason for the job/subjob concept can
be seen clearly. If there were an error in subjob 1
of job 1, the assembly, you would not want to continue with the next two subj obs. The results would
be meaningless.
If those first three items had been made jobs
rather than subjobs, the Monitor would have tried to
perform the second two tasks even though the first
had failed. However, because they are all subjobs,
an error condition encountered in anyone subjob
would cause the Monitor to abandon the remaining
subjobs.
JOB 1
•
gram
•
•
Translate an Assembler Language source prointo an object program (subjob 1)
Store the assembled object program (subjob 2)
Execute the program (subjob 3)
JOB 2
• Store a program that had earlier been dumped
onto cards (subjob 1)
Section
55
Subsections
Page
I
02
20
00
II JOB
DUP
Source Program C
FORTRAN Control Records
r---------------~/
//
Object Program B - - - - + /
*comments
/
~-----
//
Source Program A
Assembler Control Records
//
*comments
----+f
~--------------~/
*comments
(see Cold Start
Operating Procedure)
Figure 55.1. Stacked job input
Section
55
DISK CARTRIDGE ID CHECKING
A second assist given you by the Monitor system is
the checking of disk cartridge ID numbers. Every
cartridge must have an ID number; if you so desire,
you can request that the Monitor check each cartridge for a certain ID and alert you if the desired
cartridges are not mounted.
Subsections
Page
I
01
30
00
For example, suppose you have placed a payroll
data file on a particular cartridge, and have identified it as cartridge 6066. If you punch 6066 in columns 11 through 14 of the JOB card, the Monitor
will read the cartridge ID from the disk on logical
drive 0, and, if it is not 6066, you will be so informed with a message.
If you don't care which cartridge is mounted (or,
more likely, if you will check it yourself), those
columns on the JOB card may be left blank.
Section
60
Subsections
Page
I
01
00
00
Section 60: THE MONITOR-DISK MANAGEMENT
CONTENTS
Introduction. . . . . . . . . • • . . . • • . • • . . . . . ..
Disk Storage Layout.. . . . . . . . . . .. . .. . ..
Introduction. . . . • . • . . • . • . . • . . . . . . • • ..
Cylinder 0 . . . . • • . • . • . • . . . . • • • • . . • • ..
IBM Systems Area. . . . . . • • • . . . . • • • . ..
Working Storage (WS) ..........•.••..
User Area (UA). . . .. . ... .. .. . .. . . . . ..
Fixed Area (FX) . . . . . • •. . • • •. •• • •. . ..
Summary. . . . . . . . • . . • •• . • • •• . • • . • • •.
Increasing the Amount of Space
Available to the User ......••..•.•.••..
Introduction. . . . •• • . . • . •• . • • •• . • •• • ..
How Much Room Do I Have? ..•••.••••
How Can I Make More Space
Available? ................•........
Cylinder 0
IBM System's Area
Fixed Area
User Area/Working Storage
I/o Subroutines for Devices Not on
Your System
Computational Subroutines You Are
Unlikely to Use
Seldom-Used Programs and/or
Data
Unneeded User-Written Programs
and Data
Summary. . .. . . . . . . . • •• . • •. • . •• . . . ..
60.01. 00
60.10.00
60.10.01
60.10.10
60.10.20
60.10.30
60.10.40
60.10.50
60.10.60
60.20.00
60.20.01
60.20.10
60.20.20
60.20.30
The Disk Utility Program. . . . • • • • . • . .
Introduction. . . . • • • • • . • • • • • . • • • • • • .
Format of Material on the Disk. .. .. .
Data Files
Programs and Subprograms
The Most Commonly Used DUP
Functions.........................
Store a Program or Subprogram
in DSF Format
Store a Program in DCI (Core
Image) Format
Convert a DSF Program to DCI
Delete a Program or Subprogram
Dump a nSF Program or Subprogram
and Reload It
Dump a DCI (Core Image) Program
and Reload It
Dump a Data File and Reload It
Copy a Data File onto Another Area
on Same Disk
Defining and Modifying the Fixed
Area
Special Options -- Multiple Disk
1130 Users........................
Copy a Data File onto Another Disk
Copy a Program onto Another Disk
Copy an Entire Disk onto Another
Disk
60.30.00
60.30.01
60.30.10
60.30.20
60.30.30
Section
60
INTRODUC TION
Remember, effective management can make or break
a good installation. ,This also applies to the disk
portion of your 1130. Because the disk is such an
integral part of your system, it is extremely important that you have the knowledge and ability to
manage it effectively. This discussion of the disk,
its layout, and how the Monitor helps you use it,
will give you a good start toward effective disk
management.
Effective use of your disk cartridges requires a
certain amount of planning, especially if the number
of applications on your 1130 is high, or is expected
to grow. Some control must be exercised over what
gets stored on a disk, and which disk cartridge is to
be used for a particular job.
Each installation requires a certain minimum
number of disk cartridges:
• At least one general purpose systems cartridge, with a complete Monitor system (FORTRAN
and Assembler). It should only be used for testing,
one-time applications, and other odd jobs.
• On multiple disk drive systems, at least one
working or scratch disk for each disk drive over
and above the first.
• One disk cartridge to be used for ordering and
receiving programs from IBM. Some packages are
not available in card form and can be obtained only
by forwarding a cartridge to the Program Information Department. PID will place the package on
your cartridge and return it to you.
• One disk cartridge (as required) for each of
the major IBM applications programs to be used.
For example, STRESS, COGO, LP-MOSS, and
others each require all or most of a disk cartridge.
• One disk cartridge for each major application
area, such as payroll, accounts payable, plant
scheduling, highway design, etc. In some cases,
two applications must share a disk because they
both use the same data file, but such dual use
should be avoided whenever possible.
Mixing of different applications on the same disk
may lead to several complications, especially if
different programmers are involved. For example:
1. Duplicate program and data file names may
occur, with resulting confusion.
2. One program may inadvertently write into the
disk data area of another program.
3. The amount of Working Storage is decreased
more rapidly as each application area adds programs, subprograms, etc.
Subsections
Page
I
01
01
00
4. Run times may increase as data files are
pushed further apart by the continuous storing and
deleting of programs, data files, etc.
5. Overall control is diminished.
Before discussing disk storage management,
several terms must be defined:
Systems
the 1130
only one
systems
cartridge -- a cartridge that contains
Disk Monitor system. If your 1130 has
disk drive, all your cartridges must be
cartridges.
Non-systems cartridge -- a cartridge that does
not contain the monitor system. As implied
above, such a cartridge would be of use only in
installations with two or more disk drives.
Master cartridge -- a systems cartridge that has
been referenced by the cold start procedure, or
by a Job card. The Monitor system on that cartridge will be the one in use until another cold
start is initiated, or until a Job card is encountered that switches control to a different cartridge. Obviously, on a one-drive 1130 system,
the one and only disk cartridge will be both a
systems disk and the master disk.
Satellite cartridge -- any cartridge which is not
the master cartridge. It may be either a systems
or non-systems cartridge.
You see, then, that there is a definite distinction
between these terms. A disk cartridge is either a
systems or non-systems disk, depending on whether
you have loaded the Monitor system onto it. On the
other hand, the master/satellite split does not
occur until the cartridges are placed in the drives,
made ready, and a cold start performed. Then, one
becomes the master, and the others, if any, become
satellites.
The terminology of the disk drives themselves
involves another distinction -- that of physical
drives versus logical drives. Single-drive 1130
users need not concern themselves with this; their
one disk drive is physical drive 0 and logical drive
o -- there are no options.
-- --• Each disk drive on the 1130 has a physical
drive number; drive 0 is the one contained in the
mainframe of the 1130; drives 1 through 4 are contained in the 2310 enclosure, a separate unit. These
numbers are fixed and cannot be changed.
• Each disk drive present on the 1130 may also
be given a logical drive number, which mayor may
not agree with its physical number. The only
Section
60
Subsections
Page
I
02
01
00
restraint is that a two-drive system may only have
physical and logical numbers 0 and 1; a four-drive
~ystem, 0, 1, 2, and 3; etc.
You assign logical drive numbers when you
prepare a Job card. The Job card may contain a
series of five four-digit numbers, representing the
ill numbers of each cartridge (each cartridge must
be given a four-digit ID when it is initialized). The
first of the five ID's (cc 11-14) informs the Monitor
that logical drive 0 is to be the drive containing
the cartridge with that ill. For example, if this
field contained 1234, the drive in which cartridge
1234 is mounted becomes logical drive O. That
cartridge may be physically located on any drive;
its actual position does not matter.
Cartridge 1234 would also become the master
cartridge, since the cartridge on logical drive 0
will always be the master.
For further detail, see the Monitor reference
manual.
Section
60
DISK STORAGE LAYOUT
Introduction
Conceptually, disk storage can be divided into five
logical areas:
- Cylinder 0
- IDM Systems Area
- User Area
- Working Storage
- Fixed Area
Subsections
Page
I
01
10
01
The contents and use of these areas are discussed
in detail in the Monitor SRL manual, and in general
terms here.
Note that these areas are logical or symbolic,
rather than physical areas. They are not necessarily intact or contiguous. Some of the items in one
logical area may, in fact, be physically located between two items in another logical area.
The term "logical", as it is used here, denotes
a system organized for ease of understanding,
rather than for accurate technical detail.
Section
60
Subsections
Page
I
01
10
10
Cylinder 0
This area contains certain key information that is
present on every disk cartridge. The exact contents
of this area differ, depending on whether the disk in
question is a systems disk (in which case it contains
the Monitor) or a non-systems disk; the area, however, is always present, and always occupies one
cylinder, Cylinder o.
Section
60
IBM Systems Area
The IBM Systems Area is present on all disk cartridges that have been built as systems disks (that is,
disk cartridges on which the Monitor system has
been loaded).
Subsections
Page
I
01
10
20
This area consists of (1) a basic Monitor package
of 152 sectors, which must be present, (2) two
optional items, which may be removed:
FORTRAN compiler (88 sectors)
Assembler (32 sectors)
and (3) the Core Image Buffer (16 sectors), which
may be deleted from a satellite cartridge but must
be present on the master cartridge.
Section
60
Subsections
10
I
30
Page
01
Working Storage (WS)
Working Storage is used for temporary storage of
programs and data. Since it is used for this purpose by both you and the Monitor, you should not
leave material in WS if you wish to use it later. If
you wish to retain a program or data file, it should
be transferred with DUP to either the User Area or
the Fixed Area, and given a name.
The size of WS is variable, since it consists of
whatever space on the disk is not taken up by the
other four areas.
Section
60
Page
I
01
10
40
Floating
Boundary
User Area (UA)
As mentioned earlier, programs and data that you
want retained must be moved from WS to either the
User Area or the Fixed Area.
The size of the UA is also variable, since it
expands and contracts as material is stored in it or
deleted from it.
The process of transferring a program or data
file from WS to UA is done in a unique manner,
made possible by the use of a "floating" boundary
between the two areas. Because material placed in
WS is at the "lower" end of WS which is adjacent to
the "upper" end of UA, all that is necessary to transfer it from WS to UA is to move the boundary. (See
Figure 60.1.)
The term "User Area" should not be taken to
mean that only user-written programs will be found
there. Nearly the entire IBM subroutine library is
placed in the UA (occupying about 50 sectors), where
it may be called for use by other programs.
The UA may contain:
• Data, in disk data format (DDF)
• Programs and subprograms, in disk system
format (DSF)
• Programs, in disk core image format (DCI)
The major differences between these three formats are discussed in subsection 60.30.10.
The Location Equivalence Table (LET) is a directory of the contents of the User Area. It exists on
Subsections
U"" Moo
Beto"
[r---II I IA I III
---J
!
Wo,k;,. Sto,,'.,
1'1' E'-----------.u'um~
~~-----.vr-----...J/I'-v--'1
I
I
I
Programs and data
previously stored
I
I
I
I
I
I
I
I
I
I~r-_____
User Area
---'A'--_ _ _
At",
I Program or data
I to be stored
I
I
Floating
Boundary
I
I
I
I
I
I
I
I
I
I
I
~I_---,\t~1
:
Working Storage
I II I 1111111 E~
Figure 60.1. Transferring a program or data file from WS to UA
every disk cartridge -- systems and non-systems.
Basically, it contains an entry for every program,
\subprogram, and data file that has been placed in the
UA. Each entry in the table contains the name,
size, and other properties of that program or data
file.
Section
60
Subsections
Page
I
01
10
50
Fixed Area (FX)
The Fixed Area, like the User Area, is a place
where the user may store programs and/or data
files. There are five major differences between
tne FX and the UA:
1. There is no Fixed Area on a cartridge unless
you specifically define one (see 60.30.20).
2. You specify the size of the FX, whereas the
UA expands and contracts as items are added to or
deleted from it.
3. Like the UA, the FX may contain both programs and data, but the programs must be in disk
core image (DCI) format. They cannot be in disk
system format (DSF).
4. Programs or data files stored in the FX may
be deleted, but the FX will not be repacked, as is
the case with the UA. Once an item is stored somewhere in the FX, it stays in the same location until
it is deleted.
5. The directory of the FX is FLET, the Fixed
Location Equivalence Table, rather than LET, which
is the directory to the UA.
Section
Subsections
Page
I
01
60
Summary
Figure 60.2 illustrates the five logical disk areas
and shows the general properties of each.
10
60
Approximate Size, Sectors
Logical Area
Fixed Area
(FX)
User Area
(UA)
Basic
Only on a systems disk
Core I mage Buffer
Non-Systems
Disk
152
152
Can be removed from Non-Sys_
16
16
FORTRAN
Compiler
May be removed
88
88
Assembler
May be removed
32
32
FLET
Not unless defined by user
Contents of
FX
Not unless defined by user
LET
Always
Fixed by the user when he
defines a fixed area
o (LET is part
ofCyl. 0)
Contents of
UA
User data files
User programs
IBM subroutine library
Working
Storage
(WS)
Systems
Disk
Always
Cylinder 0
IBM Systems
Area
Present?
Sub-Areas
···
Always. As delivered, the
UA contains the IBM
Subroutine Library
Contents of WS
Always
Figure 60.2. The five logical areas of the disk
Varies as material is stored
and deleted
Varies in size - WS is
whatever is left over.
Every sector added to UA
is subtracted from WS;
every sector deleted from
UA is added to WS.
Section
60
Subsections
Page
I
01
20
01
INCREASING THE AMOUNT OF SPACE AVAILABLE
TO THE USER
Introduction
As Figure 60.2 shows, there is another way to look
at a disk cartridge. Simply stated, at any point in
time, the disk can be split into two portions:
• The portion now being used.
• The portion not now being used and therefore
available to you.
If you have a data file that you want to store on a
disk, you can ask several pertinent questions:
How much room do I need?
How much room do I have?
How can I make more room, if necessary?
The first question is covered in Section 80; the
other two are answered in 60.20.10 and 60.20.20,
respectively.
Section
60
How Much Room Do I Have?
PAGE
NA~E
PTt-'OL
OMP80
OM1DO
OMTXO
DMPDl
OMPXl
FlIPR
SY SUP
ADRWS
COpy
01 SC
DLCIB
OSLET
I DENT
10
SFPAO
OIAl
=FPAD
OlAl
UA/FXA.
0130
FOR DB
MAT CNT
DB
ADDR
DSF 0009 1700
DSF 0007 1716
DSF OOIA 1710
DSF OOIE 1737
DSF
DSF
DSF
DSF
DSF
DSF
OSF
DSF
DSF
OSF
DSF
DSF
DSF
0007
0036
0010
OOlC
0036
OOlE
0037
OOOC
OOlA
0057
0009
0007
OOOB
1755
l75C
1792
17.A2
17BE
l1F4
1812
1849
1855
186F
18C6
18CF
1806
MOCIF
PTUTl
CAlPR
FSlEN
FSYSU
RDREC OSF 0015 18El
ENC OF DUMPLET/FlET
Figure 60.3.
I
01
20
10
49F3
1AOD
becomes
becomes
18931
6669
Divide by 16 (16 disk blocks per sector):
18931/16
6669/16
is
is
1183 3/16
416 13/16
The first number (1183 3/16) is the size in sectors
of Working Storage; the second (416 13/16) is the
sector at which it begins. The fact that the two add
up to 1600, the total number of sectors on a disk,
confirms the accuracy of the arithmetic.
1AOD
lET
SCTR NO.
0002
PRCG
49F3
4
=C I CN
1234
Page
Convert the two hexidecimal numbers to decimal:
It is quite easy to determine how much room is
available on any particular disk cartridge; all you
need to do is to run the DUP *DUMPLET job. The
last item on the printout will have the name 1DUMY
(a dummy entry representing empty space), its size
in disk blocks (a disk block is 20 words, or 1/16 of
a sector), and its starting address (in disk blocks).
This block of empty space is equivalent to Working Storage, the area where you may place additional programs and data files.
Figure 60.3 shows the last page of a typical
DUMPLET printout. Note the last entry:
1DUMY
Subsections
=CIBA
0118
=UlET
0128
WORDS AVAIL.
009C
=FlET
0000
CHAIN AOOR.
0000
PROG
NAME
FOR DB
MAT CNT
ECHAR
ECHRX
ECHRI
VCHRI
EGRID
HOL48
HOLCA
HXCV
PRNT2
SCATI
STRTB
EPlOT
ERULE
EMOVE
EINC
FCHAR
FCHRX
FCHRI
WCHRI
FGRID
FPlOT
DSF 0005 18F6
DSF 0025 18FB
OSF
OSF
DSF
DSF
DSF
OSF
DSF
DSF
DSF
0008
0008
0006
0004
DOlE
0041
0006
0005
DaDA
DB
AD DR
1920
1928
1930
1936
193A
1958
1999
199F
19A4
DSF 0005 19AE
DSF 0025 19B3
DSF 0008 1908
DSF 0004 19EO
PROG
NAME
FRULE
FMOVE
FINC
PlOTI
PLOTS
PLOTX
POINT
SCALE
SCALF
XYPLT
eMY
FOR DB
MAT CNT
DB
AODR
DSF 0009 19E4
DSF 0003 19EO
DSF
DSF
DSF
OSF
DSF
OOOA
0008
0002
0002
0007
49F3
19FO
19FA
lA02
lA04
lA06
l~
--------
PRO·
NAME
Section
60
Subsections
Page
I
01
20
20
How Can I Make More Space Available?
IBM Systems Area
Using Figure 60.2 as your guide, take a look at
each of the five logical areas, with an eye toward
removing items you don't need:
Every system disk cartridge, after initial loading
with the Monitor, contains the Assembler and
FORTRAN compiler, two programs of substantial
size. The Assembler occupies 32 sectors; the
FORTRAN compiler occupies 88 sectors.
If you rarely compile programs written in Assembler Language, you will probably want to delete the
Assembler from all disk cartridges except the one
used for odd jobs.
Most 1130 users program in FORTRAN, but it is
still possible to eliminate this compiler from some
disk cartridges. Suppose you have a large inventory
file that requires all the room you can get. Why
keep the FORTRAN compiler on that disk?
During the test phase, when you are compiling
many FORTRAN programs, you certainly need the
compiler; once the programs have been debugged,
however, you can eliminate it and increase the size
of your file by 88 sectors. If it becomes necessary
to change a program on a particular disk, you can
recompile the new version using a disk that does
contain the compiler, dump the new program on
cards with the DUP, remove the FORTRAN disk,
replace it with the inventory (no FORTRAN) disk,
and load the new card program with DUP. Because
this takes a few minutes, you will probably not want
to eliminate the FORTRAN compiler from any disk
unless the space is needed.
To delete these two programs from a disk, you
must use the DUP *DEFINE function, as shown
below
Cylinder 0
Since Cylinder 0 is always present and necessary on
every disk cartridge, there is nothing you can do to
reduce its size.
12 3 4 5 6 7 89 10 II 1213 1415 1617 1819 2021 2223 2425 12E27 2829 3031 3233 3435 ~37 3839 4(~1 ~2 3 ~~
II
III!
~~
JOB
I/)Ut.
Er I/oiE
vo I/J
~,).:>
/jL E~
and/or
12 3 4 5 6 7 8 910 1112 1314 1516 1718 1920 2122 2324 52627 2829 3031 3233 3435 3637 3839 140~1 2~3~45
11/ JOIR
VI
loultl
~/) ElF
/ VJiE
va jirJ
~k? ~T ~~~
I
L
I'
L
I. .
Section
60
Fixed Area
Because of the way in which the Fixed Area is handled
by the Monitor, you should not define one lUlless you
have a specific purpose in mind for it. Remember
that the size (and existence) of the Fixed Area is
entirely up to you. If you define a 20-cylinder Fixed
Area and use only half of it, the other half is completely wasted; the empty space is not transferred
to the UA or WS.
To determine what is in the fixed area, you may
rlUl the DUP job:
I 2 3 4 5 6 7 8 9 10 II 1213 1415 1617 1819 2021 2223 2425 2627 2829 3031 3233 3435 3637 3839 14(J~1
~*3 14' 45
II !JOB
~UjJ
ill u~ p[t' L EI7
II/
If it is not full, you may reduce its size (see 60. 30. 20)
accordingly, automatically transferring the released
area to Working Storage. If later you wish to place
something in FX, you may then increase its size.
I/O Subroutines for Devices Not on Your System.
As mentioned earlier, the Monitor, as delivered and
loaded on each disk, is a complete system and includes subroutines for every device that can be installed on an 1130 system -- plotter, paper tape
reader, etc. If you do not have a plotter, it makes
sense to delete the plotting subroutines. As with the
FORTRAN compiler and the Assembler, you must
Page
I
02
20
20
make the decis ion and do the deleting. The Monitor
will not check for the presence or absence of a
plotter and delete those subprograms on its own.
Although you do specify to the Monitor loader (with
the REQ cards) which devices are on your system,
the loader does not use this information to selectively
load the subroutine library. All subroutines are
loaded onto the disk, regardless of your 1130 configuration.
Figure 60.4 illustrates what subroutines can be
deleted, and how many sectors can be gained. The
subroutines noted can be deleted the same as any
other subroutine -- for example:
12 3 4 5 6 78 910 1112 1314 1516 1718 1920 2122 2324 2526 2728 2930 ~1132 ~34 3536 ~738 94C I
2~3fc-4 45
II JOB
VJ
bu~
'II)
EL Elf
PL
OTX
I f you don't have
this equipment
(or if no program on this disk
will use these devices)
IBM 1627 Plotter
User Area/Working Storage
Because the UA and WS interact, they must be considered together. Basically, there is never any
room in the User Area -- it is always full. Even if
you remove something from it, it is still full, since
it is immediately packed, and the free space is
transferred to WS.
Your job, therefore, is to remove lUlneeded items
from UA, decreasing its size and thereby increasing
the size of WS. The entire contents of WS are, after
all, available for transfer back to the UA whenever
you have something you wish to store on a permanent
basis.
The following sections discuss some items that
can be removed from the UA.
Subsections
And gain this
number of sectors
You may delete
these subroutines
PLOTX
PLOTl
POINT
XYPLT
FCHRI
FCHRX
ECHRI
ECHRX
FCHAR
FGRID
FPLOT
SCALF
FRULE
ECHAR
EGRID
EPLOT
SCALE
ERULE
10
DMPDl
DMPXl
6 1/16
IBM 1132 Printer
PRNTl
PRNTZ
PRNT2
IBM 1403 Printer
PRNT3
PRNZ
EBPT3
PTHOL
IBM 1442 Card Read Punch,
Model60r 7
CARDO
CARDl
CARDZ
2 12/16
IBM 1142 Card Punch,
Model 5
P.NCHO
PNCHl
PNCHZ
2 2/16
IBM 2501 Card Reader
READO
READl
READZ
1 4/16
IBM 1134 Paper Tape
Reader and/or 1055 Paper
Tape Punch
PAPTl
PAPTN
PAPTZ
PTLJTL
IBM 1231 Optical Mark Page
Reader
OMPRl
CPPT3
PT3EB
PT3CP
4 8/16
PAPPR
PAPHL
PAPEB
PAPTX
7 14/16
1 1/16
Synchronous Communication
Adapter (Teleprocessing)
HOL48 SCATl
HXCV
PRNT2
STRTB EBC48
HOLCA
9
2310 Disk Drive
COpy
1 12/16
Figure 60.4. I/O subroutines which may be deleted
Section
60
Subsections
20
I
20
Page
03
Computational Subroutines You Are Unlikely To Use.
Let's take the example again of the disk used exclusively for a large inventory file. You have eliminated the compilers, the plotter subroutines, etc.
Is there anything else on this disk that you won't
need? Unless you have an unusual inventory system,
the answer is yes. Do the inventory programs require the computation of any sines, cosines, etc?
If not, you may gain 7 sectors by deleting the trigonometric and logarithmic subroutines:
FSQR
FTANH
FATN
FAXB
FEXP
FLN
FSIN
ESQR
ETANH
EATN
EAXB
EEXP
ELN
ESINE
Seldom-Used Programs and/or Data. Because the
1130 Monitor makes it so easy to do so, many people
tend to "overstore" the disk. This is particularly
true of programs, which are often *STOREd as a
matter of course, with no rules regarding what gets
*STOREd and what doesn't. As a practical matter,
however, many programs should not be placed on
the disk, but should be compiled each time they are
used. For example, suppose that program XYZ is
a stand-alone program that does nothing but read a
deck of cards and produce one or two pages of results.
It is run monthly, cons ists of 150 FORTRAN source
cards, and uses 2100 words of core storage. To
compile (without listing) and execute it, will take
about:
Compile
2 minutes
3 minutes
Execute
Total
5 minutes
To load it from the disk and execute it, will take
about:
Load
1/2 minutes
Execute
3 minutes
Total
3 1/2 minutes
By storing this program on the disk, you will
save 1 1/2 minutes per month, but will use 2100
words of disk storage, or about seven sectors.
Is it worth it? That depends on your installation.
If disk space is scarce, the answer is: "No -- don't
store it!" If there is plenty of room on the disk, the
answer is: "Yes, why not?"
Obviously, some programs should or must reside
on the disk:
- Often used subroutines and functions
- Programs called as LINKS by other programs
- Frequently used programs
- Very large programs
- Programs that are run with a series of other
programs, as one batch JOB.
Unneeded User-Written Programs and Data. This
usually applies more to programs than data. Over
a period of months, the typical disk becomes cluttered with numerous abandoned, obsolete, and/or
useless programs and SUbprograms. The LET /FLET
should be dumped periodically and inspected for such
items. Anything not really needed should be deleted.
Section
60
Summary
To illustrate how much room can be available on a
systems disk, let's assume you have an 1132 Printer
and a 1442 Card Read Punch, and you wish to place
a very large commercial-type data file on the disk.
There is no Fixed Area.
After originally loading the Monitor, you
*DUMPLET and determine from the last 1DUMY
record that the size of Working Storage is 49F3 disk
blocks, or about 1183 sectors, 74% of the disk.
To increase this amount, you can take the three
steps suggested earlier:
1. Delete the FORTRAN compiler and the AssembIer, gaining 120 sectors.
2. Delete the I/O subroutines you don't need, in
this case gaining about 37 1/2 sectors.
Subsections
Page
I
01
20
30
3. Delete the technically oriented computational
subprograms, gaining about seven sectors.
You thereby have increased the available disk
space (WS) by 164 sectors, to 1347, or 84% of the
disk. Of course, you cannot compile any programs
with this disk, nor can you execute any jobs (noncommercial) requiring some of the computational subroutines that have been deleted. From the number
of sectors available you must subtract the space required for your programs. The remainder is available for your data file(s).
The task is easier with a non-systems disk. One
cylinder (eight sectors) is always required for the
Cylinder 0 area, plus two more if you have defined
a Fixed Area. That leaves either 1584 or 1576
sectors for your programs and data files.
Section
60
Subsections
Page
I
01
30
01
T HE DISK UTILITY PROGRAM
Introduction
The Disk Utility Program (DUP) gives you the facilities necessary to manage your disk storage capability. With DUP you can:
• Store programs and data files on the disk
• Make the programs and data files on the disk
available in printed, punched card, or punched
paper tape form
•
•
Remove programs and data files from the disk
Determine the contents of disk storage through
a printed copy of LET /FLET, the directory to
the disk
• Alter certain system parameters and, to a
limited extent, the contents of the system
• Perform other minor disk maintenance functions
The Monitor manual explains the details required
to use DUP (card layouts, etc.). This section will
cover only the most commonly required DUP functions
and the information needed to execute them.
Section
60
Format of Material on the Disk
Essential to the understanding of DUP is a basic
knowledge of the various formats used in the storing
of programs and data on the disk.
Although DUP gives you many format options,
this section discusses only those that apply to the
average user, writing a typical FORTRAN program.
Users with unusual combinations (for example, a
data file in DCI format) will have exercised this
option with a specific purpose in mind and will be
well aware of the details involved.
Data Files
Under normal circumstances, data files are always
stored on the disk in the Disk Data Format (DDF).
Programs and Subprograms
Under normal circumstances, programs and subprograms will be stored on the disk in one of two
formats:
Disk System Format (DSF)
Disk Core Image Format (DCI)
Subsections
Page
I
01
30
10
The main difference between the two lies in what is
stored, rather than how it is stored.
A program in DCI format cons ists of a complete,
self-sufficient core load or program package -- the
mainline program, plus all the subroutines it requires. The entire package is in absolute form;
. that is, all addresses are actual core storage locations rather than relative locations. Subprograms
cannot be in DCI format.
On the other hand, an item in DSF consists of that
item and only that item. Nothing else is included
with it. It may be:
• A program or a subprogram
• Absolute or relocatable (but usually relocatable)
• In either WS or UA (but not in the FX)
As would be expected, a program occupies more
space on the disk in DCI form than it would in DSF,
since it includes more material. However, it may
be loaded into core storage (when called by an
XEQ card) much faster, since the Core Load Builder
need not assemble all the necessary subroutines and
calculate actual core storage addresses.
Section
60
Subsections
Page
I
01
30
20
The Most Commonly Used DUP Functions - Single
Disk Drive Systems
Of the many things that can be done with DUP, a
few stand out as common, everyday tasks in the
typical 1130 installation. The following is a guide
to these common jobs:
Store a Program or Subprogram in DSF Format
After compiling a program or subprogram, you will
commonly store it on the disk for later reference
or execution.
Because the FORTRAN Compiler (or Assembler)
leaves the compiled program in Working Storage,
all that need be done is to move it from WS to UA.
To do this, DUP moves the boundary between UA
and WS so as to include in UA whatever is in WS.
For example, suppose you have just compiled a
program called PROG Z, which requires 812 words
of core storage. If you follow the END card of the
program with
12 34 5 6 78 910 1112 1314 1516 1718 1920 2122 2324 2526 2728 2930 3132 3334 3536 3i31 394(
~1~2~3
45
E!N;:;
1// lDL/lo
~s
TO WE
IJtis
VA
1(0
qZ
DUP will move this program (move the boundary)
from WS to UA, and enter the name PROGZ in LET,
with the proper identification codes. UA increases
in size by about 812 words; WS decreases by the
same amount. Note that you did not have to know
how large the program was -- DUP handles that.
Note also that the DUP card is not preceded by a
JOB card.
Section
60
Subsections
Page
I
02
30
20
Store a Program in DCI (Core Image) Format
Delete a Program or Subprogram
You can, after compilation, also store a program in
DCI format, by simply using the *STORECI card in
place of the *STORE card. Note that the *FILES,
*LOCAL, and *NOCAL cards are placed after the
*STORECI card and that the number of such cards
is punched in columns 27-30 of the *STORECI card.
Because this takes longer than the *STORE option,
it usually will not be done unless you are fairly
certain that the program is free of bugs.
This is one of the simplest of the DUP jobs, since
you need not be concerned with either the format,
the location, or the type (program, subprogram, or
data) of the item to be deleted.
The sequence of cards
12 34 56 78 9 10 II 1213 1415 1611"18 1920 2122 2324 2526 2728 2930 3132 3334 3536 3738 39 40 4142 ~3~1~
1
II IJOV3
II 1& LlI.&
t~ EL £'17 f
WA WElt'
Convert a DSF Program to DCI
For speed of loading, commonly used programs
should be stored in DCI "(core image) format. This
eliminates the need to build a core load each time
you execute the program.
If you have a program called MAIN6 stored on the
disk in DSF (by a STORE card), you can convert it to
DCI with the following sequence:
12 3 4 56 78 910 1112 1014 1516 1718 1920 2122 2324 2526 2728 2930 3132 3334 3536 3738 3940 4142 43445
/ /
/ /
-I/'J)
1I~~
I/)I/p
IL
JlA
ws
PiS
U'II
l/~~
lis TO Ril CI
OC
I
A/
AL - - - - - -
11 / II £5
---
VIO'S
blJllp
Itll ELIE 17£
"""
IVA 'HEN
2-
--
/ I
/ /
~ /
N~
Note that the name of the program had to be
changed.
will delete NAMEP wherever and whatever it is.
Section
Subsections
Page
I
03
30
60
20
Dump a DSF Program or Subprogram and Reload It
Dump a DCI (Core Image) Program and Reload It
As a backup procedure, you can dump your often
used programs and subprograms onto cards or paper
tape. If anything happened to the disk cartridge,
these items could be reloaded much faster than they
could be recompiled. The job
If the program to be dumped and reloaded is in core
12
3 4 56 7 B 9 10 1112 1314 1516 171B 1920 2122 2324 2526 2728 2930 3131 1114 lS16 3B8 3940 412 ~14H5
/ j08
I / Il/lP
i/) ,niP
/
/1,4
01 on/; co rei 5
Cl,b
elo
IT £11
o"t
One
image format, the procedure must be changed somewhat.
The dump to cards can be accomplished in the
same way, with the *DUMP card.
However, to reload, the STOREDATACI option
is required, and the card count must appear in
columns 27 -30. For example, a program called
XXXXX, dumped into a deck of 108 cards, would be
reloaded with the card:
L!7 c;,
12 3 4 56 78
i-'" TO R£
will cause ITEM to be punched into the deck of blank
cards following the *DUMP card, 54 words per card.
In addition, a header and end-of-program card will
be punched.
Since the program is punched in such a compact
form, very few programs w ill require more than an
inch of cards (about 140 cards, or 6300 words).
Extra, unpunched cards will be bypassed automatically by DUP.
To reload this dumped program, the *DUMP card
should be replaced with
12 3 4 56 78 9 10 1112 1314 1516 1718 1920 2122 2324 2526 2728 2930 3131 1114 3516 3718 394( 123
'15 TQ
RE
el.e
LJA
45
TIT Ld'1
(if the program was in DSF) and run as another job.
910 1112 1314 1516 1718 1920 2122 2324 2526 2728 2930 3131 3314 lS16 3718 3940 414243
AT AC i'CO
lIA
)(X
xxx
01 08
45
Section
60
Dump a Data File and Reload It
More important as a backup procedure, you can
dump your data files onto cards or paper tape. In
case anything happens to the disk cartridge, the data
file may be reloaded.
To dump a data file, you must know its size in
sectors.
The sequence of cards
Subsections
Page
I
04
30
20
Copy a Data File onto Another Area on the Same
Disk
Another method of data file backup is to copy the
file onto another portion of the disk. Typically this
would be done before running a job that modifies the
file. If the file is 100 sectors long and called MEN,
the job
123 4 5 67 89 1011 1213 1415 16 17 1819 2021 2223 2425 2627 2829 3(31 3233 3435 3637 3839 14041 2~3
12 3 4 56 78 910 1112 1314 1516 1718 1920 2122 2324 2526 2728 2930 3132 3334 3536 3738 3940 4142 3~45
/I
11 Oil
I I 1iJ11.I1.c
fir. ilV1[t; 14
el7 OL/ IqlA
II
/ I
*1/)
TH
101
1/;14
1
d' Ctl
ell"
dIS
I,.: I LeX 0 ~1.5
I/o ~o Iia II i Ie
will dump the 65-sector data file, FILEX, from the
UA to cards (CD).
The data file is punched into the blank card deck,
54 words per card. No header or trailer cards are
punched.
To reload, you must know the number of cards
in the dumped deck.
To continue the previous example of a 65-sector
file (20,800 words), the dumped deck would have
required about 386 cards.
To reload, then, you need the cards
lr.ul.c
ilV! pi/] ~17f4
*5170 KIE
Ifl~
17H
tIld
fO EL
"
CD
t~e VkI WP ItW kJa 14
UA
1/1
!L IFIX
rj~ E~
01 00
01 I;: It:
HEN
A
jf()
tfs TO fRlE itJA TA
l
115 tkl lelt- Ifl14 TiA
~EltV
luA
JO~
bu~
lk? EL- EITE
.I 01,'1
lIS 5
~I"
12 3 4 567 89 1011 1213 1415 1617 1819 2021 2223 2425 2627 2829 3031 3233 3435 3637 3839 14041 42 3 4445
/ /
II
I I
IUA
will move it to Working Storage, then include it in
the User Area with a different name (TMEN).
If the program you wish to run operates satisfactorily, updating the file MEN, you need do nothing
except DELETE TMEN.
If on the other hand, some error occurs that ruins
the file MEN, you have a duplicate file (TMEN)
ready to replace it. The steps shown below will
replace MEN, which has been ruined, with TMEN:
/I
12 3 4 567 89 10 II 1213 1415 1617 1819 2021 2223 2425 2627 2829 3031 3233 3435 3637 3839 14041 42~3 ~45
45
II olA
E17£
~~
1~5
iW5
Id4
T~ Av
I1EN
T~ c~
01 Ofl
01 01;;
ol~ k5~
Ie 61~ cK
Now you may rerun the job. Be especially careful not to *DELETE TMEN until you are sure
everything went according to plan.
This protects you from accidental programmed
loss of a data file; however, it does not protect
against physical loss or destruction of the disk
cartridge itself.
Section
60
Subsections
Page
I
05
30
20
Defining and Modifying the Fixed Area
or, if you wish to decrease its size by 3 cylinders
If you want a Fixed Area on a disk cartridge, you
must not only instruct the monitor to create one,
but you must specify its size.
If you want a Fixed Area of 20 cylinders, you can
run the job
12 3 4 56 78
12 3 4 5 6 78 91Q 11112 1314 1516 1718 1920 2122 2324 2526 2728 2930 3132 3334 3536 3738 39 140 ~I 2~3~45
II //)18
II I1V~
il-k:lE IW Ii, !,tl
l(IE~
4,('
itA
0/1 a~1j-
910 1112 1314 1516 1718 1920 2122 2324 2526 2728 2930 ~I 32 3334 3536 3738 3940 4142 3 4 5
II VolE
1/ kJ Iv I,c;
~f)
£~
doVE FI XEO
~R IE4
OiJ 21
You should keep a record of whether a particular
cartridge has a Fixed Area or not. If you ran the
first job, then forgot you ran it, and ran it again,
you would have a 41-cylinder Fixed Area. When in
doubt you may use the DUMPLET DUP option, which
will print the contents of FLET.
and you have it. Note that we specified 21 cylinders
as the size of the Fixed Area. One cylinder will be
used for FLET; the other 20 are available for your
programs and data files.
If later you wish to increase the size of FXby 6
cylinders, you can use
12 34 5 6 78 910 1112 1314 1516 1718 1920 2122 2324 2526 2728 2930 3132 3334 35~ 3738 3940 41~2 3
,;,; lOE.
I I
IN/
foIlD I£~ Ud ~I xltlo ~~ IE 14
at: ol~
45
Section
Subsections
Page
I
01
30
60
30
Special Options -- Multiple Disk 1130 Users
Copy a Program onto Another Disk
Copy a Data File onto Another Disk
If you have multiple disks, you may also choose to
back up your programs by copying them to another
disk, rather than dumping to cards. This is similar
to the previous task, but eas ier, since you do not
have to know the size of the program, as was the
case with a data file. You must still, however, go
via WS in the two-step procedure:
If you have more than one disk drive, you will usually take this option rather than the ones described
earlier -- dump to cards for backup, or copy to
another part of th. same disk. This requires a twostep procedure, s~ce data files cannot be copied
directly from the UA on one disk into the UA on
another disk. The transfer must be via WS.
Suppose you have an 88-sector file, called DAT AX,
in UA on cartridge 1075, and you want to copy it into
the UA on cartridge 1077. Assume that cartridge
1075 is on drive 0, and 1077 is on drive 1. The
following card sequence will accomplish this task:
12 5 4 , 6 7 8 910 1112 1314
1/ /
1718 19 20 212223
24~
2627 2829
/I
[./1
7~
111 71.,
10 III
i!;/lip
I-IJ 1I/'t ip
is 1/1 Rl
(J,4
J'tS
w5
1/,4
PR OyX
DR Oil<
7'
10 7 1i
to
to 75
to 77
30~1 325334 35363738 394041 24344~
1/17'"
nvp
//
TA
,i~
""
1~ 7j 10 ,77
(j~
12 54 , 6 78 910 1112 1314 1516 1718 19 20 2122 2324 2526 2728 2930 3132 3334 3536 3738 3940 412 ~3~45
1/ 1J01i
I ...
(114
W5
~.5
~4
47 4X
~7 IAIX
0
7S
IV
It III 717
This copies the program or subprogram called
PROGX from cartridge 1075 to cartridge 1077. As
before, the program now exists on both cartridges,
each of which has its own LET.
Neither the format (DSF or DCI), nor the type
(program or subprogram) need be known, or specified.
You can see that the file was first moved from UA
to WS on cartridge 1075, then from WS on 1075 to
UA on 1077. The file now exists on both cartridges,
and each has the same name: DATAX.
Copy an Entire Disk onto Another Disk
This is not done with the Disk Utility Program (DUP)
but with a Disk Maintenance Program called COPY,
which is supplied with the Monitor. If you want to
copy the entire contents of cartridge 1967 onto cartridge 1968, you execute COpy:
12 3 4 5 6 78 910 1112 1314 15" 1718 1920 2122 2324 2526 2728 2930 3132 3334 3536 3738 3940 ~142 34445
II //1'"
II I Xl'
ir 01 '1~ 7
t9 ~7 19
/'/1
py
19 ~o
'8
Section
65
Subsections
Page
I
01
00
00
Section 65: THE MONITOR - CORE STORAGE MANAGEMENT
CONTENTS
Introduction. . . . . . . . . . . • . . . . . • • . . . • • ..
The Logical Layout of Core Storage. . . •.
Basic •...•.•..•..•....•.•..........
Flipper. • . . . • • • • . . . . • . . . • • . • . • . . . . ..
SOCAL Area. . • • . . . • • • . • • • . • • • . . • • ..
General
Overlay 1
Overlay 2
Overlay 3
The SOCAL Overlay Scheme
Possible Improvements to the
SOCAL Scheme
65.01. 00
65.10.00
65.10.10
65.10.20
65.10.30
Reduce the Size of the Largest
SOCAL Overlay
Combine Overlays 1 and 3
LOCAL Area ...•..•.••••••••..•....
General
IB M -Supplied (Systems)
Subroutines
Program or LINK Area. . . . • . . . . . . . •.
COMMON Area .....•..••••••••.....
Unused Area. . • • . • . • • • • • • • • • . • . . . . ..
Summary............................
65.10.40
65.10.50
65.10.60
65.10.70
65.20.00
Section
65
INTRODUCTION
The 1130 Disk Monitor System gives you three extremely powerful and useful means of managing
core storage. All three involve the sharing of core
Subsections
Page
I
01
01
00
storage by two or more programs (LINKs), subprograms (LOCALs), or groups of subprograms
(SOCALs). This section describes these three
schemes in detail, after discussing the 1130 core
storage layout in terms of its seven logical areas.
Section
65
Subsections
Page
I
01
10
00
THE LOGICAL LAYOUT OF CORE STORAGE
You can think of core storage as consisting, like the
disk cartridge, of several logical areas. Again,
this layout may bear little or no resemblance to the
actual, physical layout; it is merely a device to help
you understand the dynamic nature of core storage.
The seven logical areas are as follows:
Basic
Flipper
SOCAL Area
LOCAL Area
Program Or LINK Area
COMMON
Unused
These areas are described below in general terms.
Complete details may be found in the appropriate
Monitor reference manual. Note that all core sizes
given are based on:
1. A typical FORTRAN program --commercially
rather than scientifically oriented.
2. Approximate subroutine sizes, usuallyadjusted to multiples of 10.
3. Version 2, Modification Level 0, of the 1130
Disk Monitor System.
Because some of the package sizes may increase in
the future, you should not plan on using all of the
available core storage; it might be more prudent to
use about 95% of it.
Section
65
Basic
This is a set of programs that is always in core and
whose size varies only slightly from job to job. It
consists of:
1. Resident Monitor
2 . Transfer Vector
3. Several commonly used subroutines kept in
core storage at all times (IFIX, FLOAT, ELD,
ESTO, NORM, etc.). These are all subprogram
subtypes 0 -- see discussion of subtype under
"SOCAL Area".
A good average size for this area is 740 words.
Unused
COMMON
Program area
lOCAL area
SOCAl area
Flipper
Basic area
Core Storage
~
Subsections
Page
I
01
10
10
Section
Subsections
Page
I
01
65
10
20
Flipper
Unused
COMMON
This routine handles both the SOCAL and LOCAL
overlay system. Flipper is not required (core size
= 0) if there are no SOCALs or LOCALs: if there
are, its size is about 100 words.
Program area
LOCAL area
SOCAL area
Flipper
Basic area
Core Storage
Section
65
SOCAL Area
General
Unused
COMMON
Program area
lOCAL area
SOCAl area
~
Flipper
Basic area
Core Storage
The word SOCAL is an acronym derived from
"System Overlay on Call". The SOCAL area is that
area of core storage where the SOCAL subroutines
reside. The SOCAL subroutines, in turn, are defined as those subprograms that:
1. Are used by the mainline program to be executed.
2. Have been designated as subtype 1, 2, 3, orS.
3. Have not been made LOCAL.
If a subprogram has not been designated as subtype 1, 2, 3, or S, it will be located in one of three
areas:
1. The LOCAL area if it has been specified as
LOCAL.
2. The Basic area if it is an IBM -supplied subprogram (IFIX, FLOAT, ELD, EST, etc.) and has
not been made a LOCAL.
3. The Program area if it is a user-supplied
subprogram and has not been made a LOCAL.
The 1130 Monitor system you receive from IBM
includes a subroutine library in which each subroutine is assigned a subtype number. These may
be called the standard subtypes, and will yield a
SOCAL system as described in the Monitor manual
and in later subsections of this Guide. However,
these subtype numbers may be changed at your
discretion. Furthermore, you may assign subtype
numbers to your own subprograms. Both steps will
yield a nonstandard SOCAL system. Several ideas
on this subject are presented later in this subsection.
The SOCAL system involves the grouping of the
SOCAL subroutines into three groups, called overlays,
which will be manipulated by the Core Load Builder
as it goes about its job of loading your program into
core storage.
Subsections
Page
I
01
10
30
Overlay 1. This is made up of all those subroutines
and functions designated as subtype 2 or S. The
ARITHMETIC, PAUSE, and STOP routines are subtype 2; the functionals (SIN, COS, etc.) are subtype S.
The "typical" commercial program will probably
add, subtract, multiply and divide (in extended precision), PAUSE, STOP, and read the data switches.
The subroutines required to do this will occupy about
520 words of core storage. If the program does not
divide, the size of this overlay will be reduced by
ISO words.
Commercially oriented 1130 programs will
probably be limited to these subroutines, while
technical-type jobs may use the SIN, COS, SQRT,
etc., functions and require-up to several hundred
more words.
Section
65
Subsections
Page
I
02
10
30
Overlay 2. Overlay 2 is composed of all subtype 3
subroutines--those required for non-disk input/
output. The basic component is SFIO, the Format
Interpreter, which is required if the program to be
executed contains any non-disk FORTRAN I/O statements. In addition, each I/O device requires its
own I/O subroutine and often several code conversion routines.
The size of this overlay varies considerably,
depending on the I/O devices specified ·on the *IOCS
card (whether they are used or not). The following
table may be used to calculate the approximate size
of this overlay.
If your program
contains any:
This many words will be
included in overlay 2:
a) Non-disk formatted
input/ output (SFIO)
b) WRITE on the 1132
c) WRITE on the 1403
d) WRITE on the 1442-5
e) WRITE on the console
printer (typewriter)
f) READ or WRITE on the
1442-6 or 7
g) READ from the 2501
h) READ from the keyboard (cannot be
done without writing
on console printer)
i) READ from keyboard
2! 2501 or 1442-6, 7
j) READ or WRITE on
paper tape
Total
1150
190
190
70
60
160
60
30
190
225
Consider, for example, a FORTRAN program
compiled with the card:
*IOCS (1132 PRINTER, TYPEWRITER, KEYBOARD)
Referring to the table above, this program will require the following:
Item
a
Reason
No. of Words
There will be formatted I/O
1150
using non -disk units.
b
The 1132 printer is specified.
190
e
The typewriter is mentioned.
60
The 1442 is included.
f
160
i
The program READs from the
190
1442.
This program, therefore, will require a 1750-word
overlay. (Note again that it is the *IOCS card, not
your program, that determines the size of this
package. )
Section
65
Overlay 3. This is the FORTRAN disk I/O package,
which may contain:
SDFIO (620 words), the disk I/O package
SDFND (80 words), the disk FIND package
SUFIO (730 words), the disk unformatted
I/O package
All three subroutines are subtype 1. The size of
this package, therefore, ranges from 0 (no disk
I/O) to 1430 words.
Note that SDFND is not included unless your
FORTRAN program contains a FIND statement.
SDFIO is included if the *IOCS (DISK) card is present; SUFIO if the *IOCS (UDISK) card is present.
The typical program will require SDFIO and
SDFND, for an overlay size of 700 words.
Subsections
Page
I
03
10
30
The SOCAL Overlay Scheme
Just before you execute a program or store one in
core image format (DCI) , the Core Load Builder
(CLB) is given the task of building a complete core
load, or program package, which will fit into core
storage.
CLB assembles your program and all its required
subroutines, and determines how much core storage
they will require. In so doing, it considers the
subroutines that are to be LOCAL. The CLB then
tries to inc lude the last remaining elements, the three
SOCAL overlays, in four steps:
1. As a first step, CLB attempts to fit all three
overlays in core with no sharing. Using the typical
overlay sizes, this will require 520 +1750 +700 or
2970 words of core.
2. A second step is taken if there is not enough
room to hold all three packages at the same time.
This involves the sharing of core storage by overlay
1 (arithmetic) and overlay 2 (non-disk I/O). The area
they share must be large enough for the larger of the
two overlays, in this case (and almost always) the
non-disk I/O subroutines, overlay 2. The size of
the SOCAL area will now be 1750 +700 or 2450 words,
a reduction of 520 words, the size of overlay 1.
As required by the user's program, Flipper will
read each overlay from the disk whenever it is needed,
placing it on top of the last overlay. Overlay 3, the
disk I/O, will remain in core at all times. Because
Flipper is now needed, your net gain is 520-100 or
420 words.
3. The third step is taken if there is still not
enough room in core storage. It involves the sharing of core storage by all three packages, in an area
the size of the largest of the 3 overlays. As before,
this will probably be the non-disk I/O overlay, at
1750 words.
4. If step 3 fails to provide enough room in core,
step 4 will so advise you with a message.
Summarizing the C LB makes a step-by-step
attempt to fit your program and its subprograms into
the available core storage space.
Step 1 involves the most core storage -- typically
about 2970 words.
Step 2 requires about 520-100 or 420 words less
than step 1.
Step 3 requires about 700 words less than step 2.
Figure 65.1 shows the three steps, or overlay levels,
in graphic form. Note that the discussion of this typical program did not include the program itself. Only
the subprograms have been considered.
Section
65
Subsections
Page
I
04
10
30
If you place an L in column 14 of the / / XEQ
card, the Core Load Builder will print a core map
showing which subprograms, if any, are in which
SOCAL overlay, and the size of each overlay. (See
Figure 65.5 for such a map.)
Step 1
Overlay Level 0
3000 r
Overlay
3
2500
t-
2000
t-
Non-Disk
I/O
Step 2
Overlay Level 1
T
Net Gain
-'-
~f
Overlay
3
tNon-Disk
I/O
Unused
Overlay
2
1000 f-
Net Gain
-- -'~r------,
1
Overlay
2
1500
I
1
1
1
I
I
1
I
1
1
I
1I
1
1
Unused
I
Overlay
2
I
I
I
I
I
r---
tOverlay
1
Overlay
1
Overlay
1
Overlay
3
Arithmetic
o
Unused
I
I
I
1""--1
500
Step 3.
Overlay Level 2
Flipper
Possible Improvements to the SOCAL Scheme
Figure 65.1 illustrates, to a rough scale, the layout
of the SOCAL area at each overlay level. One fact
is apparent: overlay 2 is much larger than either
overlay 1 or overlay 3, and is, in fact, larger than
the two combined. Since the SOCAL area must be at
least as large as the largest of the three overlays,
a certain amount of core storage is unused in some
circumstances.
On the basis of this fact, there are two techniques
that may be used to make the standard SOCAL system more effective:
Reduce the size of the largest SOCAL overlay.
Since LOCALs, discussed later, take precedence
over SOCA.Ls, you have a means to remove subprograms from the SOCAL area and to force them
into the LOCAL area. Naturally, you would do this
only to subprograms in the largest overlay, usually
the non-disk I/O package.
Because one LOCAL cannot call another LOCAL,
you must be somewhat careful here. For example,
you cannot LOCALize both the 1132 subroutine and
a subroutine that calls it. One or the other may be
LOCAL, not both.
If you are sure such a situation does not exist,
you can make the following subroutines LOCAL:
Flipper
Figure 65.1. Core storage layout at each overlay level
Name
CARDZ
PNCHZ
READZ
TYPEZ
WRTYZ
PRNTZ
PRNZ
PAPTZ
Required for
1442 Card Read Punch
1442-5 Card Punch
2501 Card Reader
Console Printer
Console Keyboard and
Printer
1132 Printer
1403 Printer
Paper Tape Units
Approximate
Size in Words
160
70
60
60
90
190
190
225
(If you accidentally do make one LOCAL call
another LOCAL, the LOADER will call it to your
attention with an error message. )
Each of these routines, if made LOCAL, releases
as much core storage as the size of the routine. It
is unlikely, however, that you can reduce overlay 2
to the same size as the other two overlays unless
you LOCALize the entire 1150-word Format Interpreter (SFIO).
Section
65
To see what that would do to the SOCAL system,
let us observe what the three overlays would be if
SFIO were LOCAL (and therefore not SOCAL):
Overlay 1 ARITHMETIC (about 520)
Overlay 2 CARDZ, PRNTZ, TYPEZ,
etc. (about 600)
Overlay 3 DISK I/O (about 700)
You have not saved the entire 1150 words of
SFIO, because now your disk I/O package, overlay
3, at 700 words, is the largest. Your net gain in
the SOCAL area is 1750-700 or 1050 words of core
storage. Furthermore, the LOCAL SFIO at 1150
may now be the largest of the LOCALs, consequently
enlarging your LOCAL area; so you may not really
have saved 1050 words. If the largest LOCAL previously was 800 words in length, and the LOCAL
area is now 1150-800, or 350, words larger, your
net gain is 1050-350 or 700 words. This is still
substantial.
Because all READs and WRITEs (except to the
disk) use SFIO, making SFIO LOCAL rules out the
possibility of making LOCAL any subroutine containing non-disk I/O. This may hamper your flexibility in using LOCALs and further reduce your
700-word saving.
Step 2
Overlay Level 1
Step 1
Overlay Level 0
3000
Step 3
Overlay Level 2
~
Overlay
2970
2
2500 r-
Non-Disk
I/O
Nonexistent
2000 r-
r--1500
I
I
I
Overlay
1000
-
Overlay
2
Unused
Non-Disk
I/O
Overlay
1
1
Arith.
and
Disk I/O
Arith.
and
Disk I/O
500 r-
o
Figure 65.2.
Flipper
1750
Subsections
Page
I
05
10
30
Combine Overlays 1 and 3. Again observing
Figure 65.1, you see that overlay 2 is larger than
overlays 1 and 3 together (1750 is greater than
520+700). Why not, therefore, combine these two
overlays into one? This will not save any core, but
it may reduce the amount of time spent in overlaying
one package with another.
Since the subprograms in overlay 1 are all subtypes 2 and 8, and those in overlay 3 are all subtype
1, you need only change SDFIO, SDFND, and SUFIO
from subtype 1 to subtype 2, and they will be included
automatically in overlay 1.
To do this, you may *DUMP SDFIO, SDFND and
SUFIO from the User Area to cards, *DELETE
them, then reload the cards with a 2 punched in
column 11 of the *STORE cards.
If your programs run more slowly or no longer
fit in core, *DELETE the subtype 2 routines and
reload the card decks, this time with a 1 in column
11 of the *STORE card. This will restore them to
their original state.
Figure 65.2 illustrates how your SOCAL area is
affected by this change. For the typical program,
overlay 2 remains at 1750 and overlay 1 grows to
520+700 or 1220 words. Since there are no longer
any subtype 1 subroutines, overlay 3 will have a
size of zero words, and the CLB will, in effect,
skip step 3.
Section
65
Subsections
Page
I
01
10
40
Local Area
If you execute XXXX with the cards
General
1.2 3 4
56 78 910 1112 1314 1516 1718 1920 2122 2324 2526 2728 2930 132~ 3435 j36 7 31~9 4( 41 ~2 3 ~I~
II l!o~
1/ xv 14: ~x
Unused
xx
~I! 0(' AL IXX xix It I~ lillA t
COMMON
1
s
~12
,sItJlt3
511 ~4 I, 1/, If I-
Program area
LOCAL area
1-11-
SOCAL area
Flipper
Bas·ic area
Core Storage
The LOCAL (LOad -on -CAL.l) area is a second area
in core storage where the Monitor will overlay subprograms, although in a manner different from the
SOCAL scheme in these respects:
1. You must specifically designate a subprogram
as LOCAL. It is not automatic.
2. These subprograms are not grouped by any
subtype. Each subprogram forms one overlay, and
each overlay contains one subprogram.
3. You are not limited to three overlays. If you
have 17 subprograms, you may make all of them
LOCAL, thus creating 17 LOCAL overlays.
Like the SOCAL area, the LOCAL area will be
as large as the largest LOCAL subroutine.
LOCALs and SOCALs do not overlay one another.
There are two areas in core storage for subprogram
overlays--one as large as the largest SOCAL overlay and another as large as the largest LOCAL subprogram.
To give some examples of how LOCALs are
used, take a program that uses five functions and/or
subroutines, called SUB1, SUB2, SUB3, SUB4, and
SUB5. You may designate none, one, two, three,
four, or all five as LOCAL. Those that are LOCAL
will overlay one another, being read from the disk
whenever required; those that are not LOCAL will
remain in core storage at all times.
Subroutines must be specified as LOCAL, with
the *LOCAL card, every time a nSF program is
executed, or at the time a core load is built with
a *STORECI card. Suppose you have a main program XXXX, which uses the five subprograms
mentioned above:
SUB1
300 words
SUB2
60 words
SUB3
378 words
SUB4
406 words
SUB5
19 words
Total 1163 words
you will reduce your core storage requirements by
1153-406 or 747 words, since only enough room for
the largest, SUB4, at 406 words, is needed, rather
than enough for all five, 1153 words.
If you execute
12
34
xxx:x with the cards
5 6 7 89 10 II 1213 1415 1617 1819 2021 2223 2425 2627 2829 3031 3233 3435 36~7 13139 4(~1
1/ JOt3
Ixx Ix >(
/ / Kif
,s~8~
~L Olr 1.4 il xix
xx
*3~45
1
51/ 84
you will reduce your core requi rements by the size
of SUB3 (378 words), since it and SUB4 will overlay
each other. SUB1, SUB2, and SUB5 will be in core
all the time, since they are not mentioned on your
*LOCAL card.
There are several other options in the preparation of the *LOCAL card. For example, the above
example could also have been
12 3 4
5 6 7 89 10 II 1213 14 15 1617 1819
1/ Vb~
I.::
I I lxlE itJ IYx KIx
III L OC ~l lXx xl>< 1,15 u~ 3,
".L10"" ~I.dj ~~
20~i
2223 2425 2627 2829 3031 32133 3435 [3137 3839 14(~1 2
3~45
Section
65
where the comma after SUB3 implies continuation,
or
1/
f4 5 6
JtJi,d
/ /
Xlli~
12
'iL ocIAl
fl
i?C
78 910 1112 1314 15 16 1718 1920 2122 2324 2526 2728 2930 3132 ~34 35iJ' 37138 39 140 ~1~2 344~
x~ Ixx
xix Ixlx 1,I.s lu~.3
Z
AL x)( XIX ,is 141814
If the program to be executed has just been
compiled, it is located in Working Storage and therefore has no name. The *LOCAL card in this case
would appear as
12 34 5 6 78 9 10 1112 1314 1516 1718 1920 ~122 2324 2526 2728 2930 ~132 3334 35iJ' ~n8 3940 ~1~2 3441«
1/ l/OB
I I IX' Elt'l
IL olr At. ~s 1)18.3
t151/ lilI4
without a name for the Mainline (calling) program.
(Note the comma in its place. )
If program XXXX calls program Z Z Z Z as a
LINK ((CALL LINK (ZZZZ)), you must specify the
LOCALs for ZZZZ also, at the time you tell the
Monitor to execute (or *STORECI) XXXX
12 34 56 78 9 10 1112 1314 1516 1718 1920 2122 2324 2526 2728 293Q 3132 3334 35[lE 3738 3940 ~1~2 34445
1/ Vo~
1/ ~IE" ,~ il(x' IX IX
Z
¥t- oe 4LX 1\1 "1 1.Q3 .5iLJ 1A4
r/L olr I4/z 2'12 51) 1E7? .5~ ~'11t l'i
~3
where SUB77 and SUB91 are other subroutines
LOCAL to ZZZZ.
Subsections
Page
I
02
10
40
IBM-Supplied (Systems) Subroutines
In addition to your own subprograms, you may
also deSignate many of the IBM-suppliedsubprograms as LOCALs. All subroutines and functions
except ILSOO, ILS01, ILS02, ILS03, and ILS04, the
Interrupt Level subroutines, can be made LOCAL.
As a practical matter, however, it is often difficult
to LOCALize such subroutines, because many of
them call several other subroutines, and one LOCAL
cannot call another LOCAL.
This was mentioned earlier, when it was suggested that some subprograms, ordinarily SOCALs,
could in fact be made LOCAL instead.
Section
65
Subsections
Page
I
01
10
50
Program or LINK Area
Unused
COMMON
Program area
lOCAL area
SOCAl area
Flipper
Basic area
variable data, subprograms, etc. However, if the
LINKs must communicate with each other through
core-resident data (rather than disk data), this data
must be placed in the COMMON area, with the
COMMON statement (see next subsection). During
execution of such a program, while the location and
contents of the SOCAL, LOCAL, and LINK areas
may be continually changing, the COMMON area
does not change. It stays in the same place and is
not involved in any overlay.
Core Storage
BIG1
This area will contain
1. Your mainline program
2. All of your subprograms that are not LOCAL
or SOCAL.
3. All of the IBM-supplied subprograms that are
not LOCAL, SOCAL, or subtype O.
4. All data (variables and constants) used by the
mainline and/or its subprograms, not placed in
COMMON.
This forms the third area in core where overlays
may be employed; in this case one program package,
or LINK, will overlay another.
As in the case of LOCALs, this is not done automatically; it must be planned and executed by you.
Suppose you have written a very large (10,000word) program, named BIG. When you try to execute it, you are informed by the Monitor that it is
too big. Looking at the program, however, you see
that it can actually be thought of as four program s,
connected as shown in Figure 65. 3 .
If you split BIG into four programs and place the
CALL LINK statements in the proper places, the
four will run essentially the same as one large program (although possibly a little slower). Each program or LINK may have its own SOCALs, LOCALs,
CALL LINK (BIG2)
,
"
BIG2
CAll LINK (BIG3)
1r
BIG3
BIG4
If not
finished:
CALL LINK (BIG2)
If
finished:
CALL LINK (BIG4)
CALL EXIT
Figure 65.3. A program. "BIG". segmented into four links
Section
65
COMMON Area
Subsections
Page
I
01
10
60
There are many different ways yo.u can accomplish this, the easiest being to compose one COMMON statement
Unused
~___C~O_M_M_O~N~~-4~
COMMMON DATE, TABLE (100), K,X, Y,ANS
Progra[n:area
LOCAL area
and include it in BIG1, BIG2, BIG3, and BIG4.
Another way would be to use the following COMMON statements:
SOCAL area
Flipper
Basic area
Core Storage
The COMMON area, because it is not over-laid,
provides a means by which SOCALs, LOCALs, and
LINKs may communicate with each ot}ler via core
storage. SOCALs and LOCALs, because they are
subprograms, may also communicate through the
arguments in the CALLing statement. One LINK,
on the other hand, must use COMMON to pass data
to another LINK.
You must determine what data has to be passed
from one LINK to another. If BIG1 obtains X from
a card, and BIG2 requires it for a computation, X
must be placed in COMMON. If BIGI obtains DATE
from a card, and BIG4 uses it in a printed summary,
DATE must be passed from BIGI to BIG2, from
BIG2 to BIG3, and from BIG3 to BIG4, even though
BIG2 and BIG3 do not need it. In other words, DATE
(or its equivalent) must appear in the same relative
position in a COMMON statement in all four LINKs.
To illustrate, suppose six items must be passed
from one program to another: DATE, TABLE, K,
X, Y, and ANS. The following table shows how the
four LINKs use these six items:
Variable
DATE
TABLE
K
X
Y
ANS
Description
Real variable
Array of 100
items
Integer
Real variable
Real variable
Real variable
BIGI BIG2 BIG3 BIG4
----
X
X
X
X
X
X
X
X
X
X
X
X
X
in
in
in
in
BIGI
BIG2
BIG3
BIG4
COMMON
COMMON
COMMON
COMMON
DATE,
DATE,
DATE,
DATE,
TABLE (100)
TABLE (100), K, X, Y,
TABLE(lOO),K,X, Y,ANS
TABLE(lOO),K,X, Y,ANSWR
Here you see that the size of COMMON in BIGI and
BIG2 is reduced, since unneeded items are not
retained. Some unneeded items (like K in BIG3)
cannot be eliminated, since you must preserve the
relative location (structure) of COMMON from one
program to the next, not just the name.
Note that the name of the last variable changes
from ANS to ANSWR in LINKing from BIG3 to BIG4.
This does not matter, since only the relative position in core storage is important, not the name.
There are many other ways in which COMMON
may be arranged. To take advantage of the fact
that BIG4 does not use X, Y, or the TABLE
array, we may use
in BIGI
inBIG2
inBIG3
in BIG4
COMMON
COMMON
COMMON
COMMON
DATE,K,ANS, TABLE(lOO),X, Y
DATE,K,ANS, TABLE(lOO),~, Y
DATE,K,ANS, TABLE (lOO)X,Y
DATE,K,ANSWR
which reduces the core requirements of BIG4 by
102x3 (or 2) words, depending on the precision
used.
Section
65
Subsections
Page
10
01
I
70
UNUSED Area
This is whatever core storage remains after the
other six areas have been loaded. It must be zero
or more words in length. Good programming
practice suggests that it should be at least 100
words, to provide for future growth of the Monitor
System, IBM subroutines, and/or your programs.
Unused
COMMON
Program area
LOCAL area
SOCAL area
Flipper
Basic area
Core Storage
Section
65
SUMMARY
This section has described the seven logical areas
of core storage, with the emphasis on their overall
roles rather than on exact details. As mentioned
earlier, all quoted subroutine sizes are approximate,
and are based on a so-called "typical" commercialtype program, coded in FORTRAN. You should not
necessarily conclude that these figures will apply to
your "typical" programs; they mayor may not.
The bulk of the material in this chapter concerns
SOCALs, LOCALs, and LINKs--how they work.
Section 90 concerns how they should be used and how
they affect program performance.
Figure 65.4 graphically summarizes what has
been covered in this chapter.
Figure 65. 5 shows a "core map", printed if you
punch an L in column 14 of the I / XE Q card. From
this printout you can determine the exact sizes of
some of these packages:
• The size of the Unused area is contained in
the R41 message.
logical
Area
Approximate
Typical
Size
SubArea
Rasident
Monitor
Monitor
When
Present
740 words
Always
100 words
Only if LOCAL's or
SOCAL's are used
520 words
Almost always
Comments
Transfer Vector
Flipper
Overlay 1
(Arithl
SOCAl
----
---
Overlay 2
(Non-DiSk I/O)
1750 words
Overlay 3
(Disk I/O)
700 words
lOCAL No.1
lOCAL No.2
Size of
largest
LOCAL
subprogram
---- lOCAL
1------
Almost always
Approximate, typical
size will be either
2970 Or 2450 or 1750
words
---- Only if Disk I/O
Only if user includes a LOCAL
card
lOCAL No. n
Program
or
Link
Non-50CAL or
lOCAL Subprograms
Unknown;
depends on
program
coding
Always
Data
Object
Mainline
Program
Common
Unused
Figure 65,4.
Unknown;
depends on
program
coding
Unknown;
whatever is
left over
•
•
•
•
•
•
•
•
•
•
•
•
•
is used
Only if user includes COMMON
statement on
program
See the R41 message
of the core map for
Page
I
01
20
00
• The size of the SOCAL area can be determined
from the largest value contained in the R43, R44,
and/ or R45 message.
• The size of the LOCAL area may also be
determined from the core map. If SOCALs are
present, the size of the LOCAL area is the address
of the lowest SOCAL subroutine, less the address
of the next higher non- LOCAL. In this case it
would be 170C - 1567, or, in decimal, 5900-5479
or 321 words,
• Flipper (FLIPH), if present, is always about
100 words in length.
• The sizes of the other areas--Basic, Program, and COMMON--cannot easily be determined
from the load map.
•
I n Core Subprog.
Subtype 0
Subsections
•
•
•
•
1/ XEQ PAYRO L 2
*F I LES ( 1, F I LEI~)
*LOCALPAYRO,SURW,SUHZ,SUHY1,SUHY2,SUBY3
FILES ALLOCATION
1 01A3 0001 7061 FILEN
22 0000 0001 7061 01A7
STORAGE ALLOCATION
R 40 03E3 (HEX) ADDITIONAL CORE REQUIRO
R 43 01FC (HEX) ARITH/FUNC SOCAL liD CNT
R 44 06E8 (HEX) FI/O, 110 SOCAL WD (NT
R 45 02A2 (HEX) DISK FIIO SOCAL WD CNT
R 41 OOA4 (HEX) WDS UNUSED BY CORE LOAD
CALL ~RANSFER VECTOR
DATSW 1902 SOCAL 1
SUBY3 1701 LOCAL
SUBY2 17C9 LOCAL
SUBY1 17(9 LcicAL
SUBZ
1701 LOCAL
SUBW
1765 LOCAL
LIBF TRANSFER VECTOR
HOLTB lEBR SOCAL 2
EADDX 1883 SOCAL 1
XDD
1988 SOCAL 1
FARC
1966 SOCAL 1
XMD
1924 SOCAL 1
ELDX
1528·
i\lOkl'vl
1594
HOLEZ 1E52 SOCAL 2
EBCTB lE4F SOCAL 2
GETAD lE06 SOCAL 2
IFIX
1568
PAUSE 18Ee SOCAL
ESBR
18D8 SOCAL
EADD
187D soeAL
EDIV
1824 SOCAL
EMPY
17F6 SOCAL
EDVR
17DE SOCAL
FLOAT 155E
SUBSC 1540
ESTO
1516
ELD
152C
PRNTZ 1D48 SOCAL 2
CARDZ 1C9E SOCAL 2
wRTYZ 1C62 SOCAL 2
SFIO
18D9 SOCAL 2
SDFIO 1885 SOCAL 3
SYSTEM SUBROUTINES
ILS04 00C4
ILS02 00B3
ILS01 1EC2
ILSOO 1EDD
FL'"IPR 15De
1467 (HEX) IS THE EXECUTION ADDR
exact size
Figure 65,5.
Section
70
Subsections
Page
I
01
00
00
Section 70: 1130 FORTRAN AND THE COMMERCIAL SUBROUTINES
CONTENTS
Introduction ......•.....•...••..•.•..
Arithmetic Considerations .••.••......
General ......•......•...•••..••.••.
Integer Mode
Real Mode •.•....••••...•....••..••
General
Real -- Floating Point
Real -- Fixed Point
Rounding
Accuracy and Magnitude
Output of Large Real Numbers
Multiplication of Large Real Numbers
Decimal Mode •......•....••.....•..
Introduction
General Principles
The Decimal Arithmetic Subroutines
Addition
Subtraction
Multiplication
Division
Constants
Te sting and Modifying Signs
Moving Signs
Comparing Decimal Fields
Summary •.•...•..•.....•.••.......
Overlapped Input/Output ..•..•.•......
Introduction •.•........•••....•.....
The Commercial Subroutine Package
Over lapped I/O Subroutine s ..•.....••
General
Head a Card, 1442-6 or 7
Punch a Card, 1442-6 or 7
Select Stacker, 1442-6 or 7
Print on 1132
Skip on 1132
Type on Console Printer
Accept Data from Console Keyboard
A precaution -- IOND
Using the Overlapped I/O System
General
Orerlapping and Your Program
FOR TRAN TRACE Not Permitted
Alphabetic Headings
The Interaction of Arithmetic and I/O ...
Character Handling Techniques ••...••.
General .•.••...•..••...••..•.••...•
0......................
7 0.01.00
70.10.00
7 O. 10. 01
70.10.10
70.10.20
70.10.30
70.10.40
70.20.00
70.20.01
70.20.10
70.20.20
70.30.00
70.40.00
70.40.01
Code Conversion. . . ... .. ... . . . .. .. . .
Integer to Real -- FLOAT
Real to Integer -- IFIX
Al to Real -'- GET
Al to Integer
Real to Al -- PUT
Integer to Al
Al to Decimal -- AIDEC
Deci~al to Al -- DECAl
Al to A2 -- PACK
A2 to Al -- -UNPAC
Other Code Conversions
Other Character Handling Techniques. .
Editing Output -- EDIT
Moving Data Fields -- MOVE
Filling a Field with a Specific
Character -- FILL
Comparing Alpha Fields -- NCOMP
Match/No Match Alpha Compare
High/Low/Equal Alpha Compare
Working with Zone Punches -- NZONE
The NZ ONE Subroutine
FOR TRAN Core Saving Tips ........ .
General .............' ............. .
Reducing Program Size ........... .
Use the DATA Statement
Keep FORMAT Statements Compact
Code Efficient 1/ 0 Statements
Avoid Long Subroutine Argument
Lists
Avoid Arithmetic with Variables
Having Constant Subscripts
Reducing Subroutine Requirements ...
Raising a Real Number to a Whole
Power
SQRT vs **.5
Don't Include Unneeded I/O Devices
on *IOCS Card
Remove FIND Statements If You
Have SOCAL's or LOCAL's
Remove the TRACE from Production
Status Programs
FORTRAN Execution Time s ......... .
Processing ....................... .
Summary and Conclusion .•...••.•..
70.40.10
70.40.20
70.50.00
70.50.01
70.50.10
70.50.20
70.60.00
70.60.10
70.60.20
Section
70
INTRODUCTION
The primary purpose of this chapter is to discuss
the use of 1130 FORTRAN in a commercial environment. Many of the topics, however, will also be of
use to the technically oriented user. Topics include:
• Arithmetic considerations -- a discussion of
integer, real, and decimal arithmetic, with partic-
Subsections
01
I
00
Page
01
ular attention to the accuracy and magnitude of
numerical values
• Input! output--explaining the overlapped Ilo
subroutines and how they can improve performance
• The interaction between inputloutput and
arithmetic
• Core storage saving tips for FORTRAN
programmers
• Estimating run time of FORTRAN programs
Section
Subsections
Page
I
01
70
10
01
ARITHMETIC CONSIDERATIONS
General
Of prime interest to commercial 1130 users is the
precision and accuracy of their arithmetic calculations. Many engineering and scientific applications have very little need for answers with more
than five or six digits of accuracy. Much of the
input data comes from physical measurements (6. 34
pounds, 18.97 inches, etc.) that are only approximate
anyway, so the resulting answers (with some exceptions) must also be considered approximate.
However, in an accounting application,
$713,403.14 is exactlythat--$713,403.14. If you
add up your sales by area, by salesman, by item,
by customer, etc., the grand total for each had
better be the same, right down to the last penny.
For this reason, commercial programmers must
be familiar with the ways the 1130 does arithmetic,
and aware of their advantages and disadvantages.
For purposes of discussion, three are four ways
to do arithmetic on the 1130 system:
Integer mode
Real mode, floating point
Real mode, fixed point
Decimal mode
Section
70
Integer Mode
An integer is defined as a whole number, a number
with no fractions. Using 1130 FORTRAN, integers
are limited to a magnitude of +32767 to -32768.
This range is due to the fact that an integer must fit
in one 16-bit word. 32767 is the largest positive
number that can fit in one word (0111111111111111,
where the first bit represents the sign); -32768 is
the largest negative number.
Because of these two limitations (magnitude, and
lack of fractions) you must be careful in your use of
integer mode arithmetic. Integer mode is generally
used for counters and indicators. However, if you
desire to keep track of the position of the decimal
point yourself, you can use integer arithmetic to
process data with implied decimal points.
Subsections
Page
I
01
10
10
For example, if you lmow that pay rates at your
company range from $1. 25 to $6.50 per hour, you
could represent these rates as integers ranging from
125 to 650 cents per hour. If rates ranged from
$1. 250 to $6.500 per hour, with some rates involv'ing fractions of cents (say $3.375 per hour), they
could be represented as integers from 1250 to 6500
mills per hour.
Since mixed mode arithmetic is permitted in 1130
FORTRAN, ,there is no problem involved in multiplying the integer IRATE by the real HOURS:
PAY = HOURS * IRATE
If IRATE is 3125 ($3.125 per hour) and HOURS is
33.5, PAY will be 104687.5. After the multiplication you must be careful to reposition the decimal
point in the proper place ($104.6875) and round off
($104.69) before printing the result or accumulating
totals.
Section
Subsections
Page
I
01
70
10
20
Real Mode
General
A real number may be defined as a number with a
decimal point; fractions are allowed. If you use 1130
FORTRAN for real arithmetic, the arithmetic subroutines will keep track of the decimal point for you,
and the output subroutines will place it in the proper
place in the output results.
On the 1130, a real number may be thought of as
having four components:
1. The whole portion
2. The fractional portion
3. A pointer indicating the location of the
decimal point
4. A positive or negative sign
For example, the number 267.4 has:
1. A whole portion, 267
2. A fractional portion, .4
3. A pointer indicating that the decimal point
is between the 7 and the 4
4. A positive sign
Since the 1130 is a binary computer, these four
components are represented in binary form as
follows:
• The 267 as 100001011
• The. 4 as .011001100110--"'"• A pointer of 9 showingthat the binary point is
between the ninth and tenth bits
• The sign is positive (a 0 bit)
Rearranging and simplifying somewhat, this can
be written as (9, +, 100001011, .011001100110----)
The first value, the 9, is , in decimal, the number
of bits in the whole portion; the second item is the
sign; the third value is the whole portion itself; the
last value is the fraction.
The number of bits available for the whole and fraction combined depends on the precision option selected:
• Standard precision allots 23 bits for these
two items.
• Extended preciSion allots 31 bits for them.
The whole portion of the number, since it is more
significant, gets first choice of the available bits.
In this case, the whole portion (267) requires 9 bits,
leaving either 14 or 22 bits for the fraction, depending on the preciSion chosen.
This can cause inaccuracies, since most fractions
cannot be represented exactly in 14 or 22 bits, or in
any number of bits, for that matter. To see why,
let us see how . 4 in the above example is represented in binary notation. You are probably familiar
with the binary system for whole numbers (1,2,4,8,
16 , 32, etc., or 2 0
, 21, 2
2 , 23
, 24, 5
2 , etc.,
respectively) . In the case of fractions, the values
proceed from the decimal (or binary) point to the
right as 1/2, 1/4, 1/8, 1/16, 1/32, etc., or 2 -1,
2-2, 2- 3 , 2- 4 , 2- 5 , etc., respectively.
For example, .625 is
.1010000000
or 1/2 plus 1/8
or .5000 plus .125.
It can be represented exactly in only three bits;
however, this is unusual.
The example, .4, appears to be a rather simple
number, and you might think that it also can be represented exactly as a binary fraction. The table
below shows that this is not true:
Bit
Used = 1
Position
Value
Not Used = 0 Subtotal
1
2
3
4
5
6
7
8
9
10
11
12
.5
.25
.125
.0625
.03125
.015625
.0078125
.00390625
.001953125
.0009765625
. 00048828125
.000244140625
0
1
1
0
0
1
1
0
0
1
1
0
.0
.25
,.375
.375
.375
.390625
.3984375
.3984375
.3984375
.3994140625
.39990234375
.39990234375
You see that the binary representation can come
close to .4 but never hit it. With 12 bits
(.011001100110) the decimal value is .39990234375;
with 16 bits, .399993896484375; with 20 bits,
.3999996185302734375; etc.
The fraction chosen, .4, is not an unusual number;
it is typical of most fractions.
Unlike fractions, whole numbers can be represented
exactly in binary form. However, you do reach a
limit, depending on the number of bits available. In
standard precision, if you use all 23 bits for the
whole portion, you -can attain a magnitude of
8,388,607. With extended precision, the 31 available bits yield 2,147,483,647.
Section
70
Subsections
Page
I
02
10
20
Real--Floating Point
Real-- Fixed Point
The term "floating point" implies that the decimal
point is permitted to "float" among the digits in a
real number. In other words, the 1130 aritlunetic
subroutines will keep track of the location of the
decimal point and move it about to maintain the
validity of the number. If you multiply $1. 78 per
hour by 32.20 hours, the answer becomes $57.3160.
The decimal point "floats", thus remaining correctly
positioned at all times.
As you saw before, though, the result may not be
exact, since . 316 probably cannot be represented
exactly as a binary number. In fact, the 1. 78 and
the 32.20 were both probably inexact, too.
If you are doing an engineering or other noncommercial job, the answer is probably good enough;
it matters little whether the result is 57.316000 or
57.316003 or 57.315999. If your application is commerciallyoriented, however, close is not good
enough, since you are probably dealing with cash.
Because accounting balances are so important,
answers must he exact, down to the last unit
(penny, box). It is not that people will worry about
the penny itself, but that unbalanced totals traditionally indicate an error. If the face value of
600 payroll checks totals $12345.67, while the
system ts grand total is $12345.68, something may
be seriously wrong somewhere. The fact that the
net error is only one cent is immaterial; there
may be 300 people overpaid by one cent, and 299
underpaid by one cent.
To eliminate the inaccuracies described above, you
can use real arithmetic in a "fixed point" mode.
"Fixed point" means that the decimal point is kept
fixed to the right of the least significant digit, eliminating fractions altogether.
Earlier, you saw that 1. 78 times 32.20 gave
57.3160, an answer that probably was inexact. If,
however, you had used real, fixed point arithmetic,
you would have multiplied 11\78. by 31\220., and
obtained 571\3160., exactly. All three numbers,
since they involve no fractions, will be exact, not
just close. Note that the 1\ is used to locate the
implied decimal point.
This puts a slight burden on your programmer:
instead of letting the subroutines keep track of the
decimal point for him, he must now do it himself.
Using the values mentioned above, 1. 78 times
32.20 is 57.3160 (dollars), while 11\78. times 321\20.
is 571\3160. (ten thousandths of dollars). In the
latter case, you must remember that the true
decimal point is four places to the left of the one
supplied by the system.
Section
70
Subsections
Page
I
03
10
20
Rounding
Accuracy and Magnitude
Suppose you have just calculated an employee I s gross
pay as 107/\5673. (understood to be $107.5673) and
wish to apply a deduction of $19.733 (represented as
19,,733.). Notice that the decimal points are not
"lined up"; the units are not the same--the gross is
in hundredths of cents, and the deductions are· in
tenths of cents.
How do you perform this subtraction?
a. 107,,5673. - (19,,733. x 10.)
b. (107,,5673. /10.) - 19,,733.
c. (107,,5673./10000.) - (19,,733./1000.)
None of these is correct. Before subtracting, you
must round these two quantities -- commonly to the
nearest cent.
In the case of the 107,,5673. gross, you must add
1/2 cent or 50. hundredths, obtaining 107,,5723. ,
then divide by 100, to get 107,,57.23. Now, since
the. 23 is both inexact and meaningless, it must be
eliminated. The WHOLE function supplied with the
Commercial Subroutine Package converts the
fractional part of the number to zeros.
All three functions-- round, shift and clear
fractions -- can be done in one statement. The
statement
GROSS = WHOLE «GROSS + 5~. )*~. 01+0. 5)
rounds off GROSS, shifts it two places to the right,
and clears everything remaining to the right of the
decimal point to zeros. Note that multiplication
rather than division was used (see Section 70.50.00).
In the case of the deduction, you would say
DEDUC = WHOLE «DEDUC +5.) *0.1+0.5)
Now both values have been rounded and are in whole
cents, with all extraneous fractions cleared. Note
what would have happened if the fractions had not
been cleared:
10757.23
1973.80
8783.43
Suppose you are using extended precision real
numbers, where 31 bits are available for the whole
number and fraction combined. How large a number
can you have? 2,14.7, 4S:3 ,6.47?N()., th~.tis just
the largest number that can fit in 31 bits. Values
much larger are possible-- for example,
1,000,000,000,000,666,777,888., which can easily
be handled in the 1130.
The decimal point indicator can be as large as
64 in binary, or about 38 in decimal, meaning
that extremely large real numbers can be represented on the 1130.
The drawback is their accuracy. Especially in
commercial applications, numbers must be precise.
Thenumber 1,000,000,000,000,666,777,888. can be
read into the 1130, but it will be accurate only to
nine or ten decimal digits. In other words, the nine
most significant digits will be retained, but the remaining digits will be lost. The decimal point indicator will show the proper magnitude, but the
number is not accurate.
If you want accurate results, you must not exceed
the 31 bits (2,147,483,647.) or 23 bits (8,388,607.)
available.
Furthermore, if you want accurate numbers, you
must not allow any fractions to be generated.
Combining the above two warnings, then, means
that you should limit real numerical values to the
whole numbers between -2,147,483,648. and
+2,147,483,647. Any number outside this range
will probably not be exact; most fractions will
probably be inexact.
If you work commercial problems in cents, you
are limited to $21,474,836.47 (carried as a whole,
fixed point real number). The limit is $2,147,483.647
if you wish to work in mills.
These limits are usually ample for jobs such as
payroll, etc., but may be troublesome in
accmmting-type work, where year-to-date sales,
total assets, etc., may exceed $21 million. If this
is the case, the decimal arithmetic subroutines of
the 1130 Commercial Subroutine Package may be
used.
The correct answer is:
10757.00000
1973.00000
8784.00000
You may wish to code several arithmetic statement
functions, each one shifting a predetermined number
of places to the right:
RND1(X) = WHOLE (X+X/ ABS(X)*5. 0)/10. +0.5)
RND2(X) = WHOLE «X+X/ ABS(X)*50. 0)/100. +0. 5)
RND3(X) = WHOLE «X+X/ ABS(X)*500. 0)/1000. +0.5)
etc.
where the fourth character of the FUNCTION
name indicates the number of places to be shifted.
Section
70
Subsections
Page
I
04
10
20
Output of Large Real Numbers
Multiplication of Large Real Numbers
A second precaution must be taken with very large
numbers, and it falls in the area of output. Because
most fractions are inexactly represented and will
al ways be less than the true decimal value, the
FORTRAN output routines (including the TRACE)
always add a single bit in the low-order position of
the number, attempting to compensate for this
inaccuracy. For this reason, you rarely notice the
inaccuracy.
For example, if you multiplied 0.35 by 100.0,
you would expect to get 35., exactly. The binary
result, however, converted to decimal, is
34.9999999999999999757138713 ...
(because the multiplier of 0.35 is an inexact
fraction). That is not the result you see, though,
since the FORTRAN output routine adds its one loworder bit, resulting in
35.0000000298023223634091838 ...
Although that is no more exact than the previous
value, it looks better; in fact, you would never
notice the extra
.0000000298023223876953125
unless you output the number with a format like
F40.20, which would be unusual.
If your number is large, however, this "little
extra" can cause the output to be noticeably in error.
For example, the whole number 2111111111. , while
represented exactly in core storage, will be output
as 2111111112., an -error of 1. unit.
This problem will occur with numbers in the
range 1,073,741,824. to 2,147,483,647. if they are
output with a standard FORTRAN F format. For
this reason, you may wish to limit the magnitude of
all numbers to 1,073,741,824., or, easier to
remember, nine digits (999, 999, 999. )
This problem does not occur if the value is printed
as alphabetic data, converted by the PUT subroutine
of the Commercial Subroutine Package. This
routine will not add the extra bit, and all whole
numbers up to 2, 147, 483, 647. will be output exactly.
Because of the manner in which the 1130 performs
multiplication, a product is accurate only to 30 bits.
This means that a product exceeding 1,073,741,823.
may not be exactly correct, In fact, there is a 75-25
chance that it will be correct, and a 25-75 chance
that it will be off by 1. unit.
While this is quite satisfactory for technical
work, it cannot be permitted in most commercial
applications. For this reason, you should avoid
multiplications that might yield such a large product.
Note that this limitation does not apply to addition
and subtraction, where all 31 bits may be used and the upper limit is 2,147,483,647.
Section
70
Subsections
Page
I
01
10
30
Decimal Mode
Introduction
In addition to integer and real mode arithmetic,
there is a third alternative: decimal arithmetic.
This capability is furnished by a group of subroutines supplied with the Commercial Subroutine
Package (1130-SE-25X). This mode of arithmetic
permits variable precision.
Using the decimal arithmetic system, you select
the number of digits to be used for each variable.
If a grand total can attain a magnitude of 15, 000,
000,000.00, you can allocate 13 digits for it; if the
number of employee dependents never exceeds 99,
you may allocate only two digits for that value.
You are not limited by magnitudes of 32767,
2,147,483, 647., etc. You decide how large a
number can become and set aside enough digits
for its storage.
General Principles
This arithmetic system operates on digits stored
as integers, one digit per word. For example, the
value 1968 would be stored in a four-position array
NYEAR as
NYEAR (1)
1
NYEAR (2)
9
NYEAR (3)
6
NYEAR (4)
8
or in a six-position array as
NYEAR (1)
0
NYEAR (2)
0
NYEAR (3)
1
NYEAR (4)
9
NYEAR (5)
6
NYEAR (6)
8
or in any size array you desire.
Negative values carry the minus sign with the
low-order (or rightmost) digit. However, since
the 1130 cannot represent -0, a special method has
been devised to show negative numbers. If the
number is negative, the low-order digit is carried as
one less than its true value.
For example, -1968 is actually held in core
storage as
NYEAR (1)
1
NYEAR (2)
9
NYEAR (3)
6
NYEAR (4) =-9
For ease of reference, we will refer to this as
1968, where the minus sign is written over the
low-order digit.
You need not worry about this unless you are defining negative constants, which should be unusual.
If a negative number is read from a card, this conversion will be done for you, with the AIDEC
subroutine.
The magnitude of each value will be shown by the
number of digits: 001968 implies a six-digit or
six-word value, 0000001968 implies a ten-word
value.
Each decimal arithmetic value requires three
identifying parameteTs:
• The NAME of the array in which it is stored.
• KSTRT, the position (or subscript) of the
high-order (leftmost) digit in the array.
• KLAST, the position of the low-order digit in
the array
When referring to decimal arithmetic values, a
shorthand abbreviation will be used, enclosing these
three parameters in parentheses:
(NAME,KSTRT, KLAST)
For example, if you had a 20-word array called
NUMBR:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
000136430 0 7 7 B 3 0 0 081 3
then
-136
000136
or
(NUMBR, 1, 6)
13
00013
or
(NUMBR, 1,5)
4300778300081
(NUMBR, 7,19)
-813
00081a
or
(NUMBR, 15,20) =
Section
70
The Decimal Arithmetic Subroutines
The IBM 1130 Commercial Subroutine Package furnishes subroutines to perform the following four
arithmetic operations:
ADD to add two decimal values
SUB to subtract two decimal values
MPY to multiply two decimal values
DIV to divide two decimal values
All four have similar calling sequences, requiring
three basic elements:
The identification of the first variable
The identification of the second variable
An error code
Since the identification of each variable requires
three parameters (e.g. ,NUMBR, 1,6), each subroutine has a total of seven parameters.
If no error conditions occur, the subroutine
leaves the error code, NER, set to whatever value
it had when the subroutine was called. Note that the
subroutines merely set the indicator NER. They
do not pause, print a message, or take any other
definite action. It is up to you to set NER before
calling the subroutines, and to test it after each is
complete.
Addition. The general form of the ADD subroutine is
CALL ADD (addend, augend, error code)
where the addend is added to the augend, and the
result is left in the augend.
There are two possible error conditions. Both
are illustrated in the accompanying examples (Figures 70.1 through 70.6).
Subtraction. The general form of the Subtract
subroutine is
CALL SUB (subtrahend, minuend, error code)
where the subtrahend is subtracted from the minuend,
and the result replaces the minuend.
There are two possible error conditions. Both
are included in the accompanying examples (Figures
70.7 through 70.11).
Multiplication. Because of its nature, multiplication is somewhat more involved than addition and
subtraction. For example, if you multiply two
Subsections
Page
I
02
10
30
two-digit numbers, 95 and 86, your result is 8220,
a four-digit number. If you multiply a three-digit
number, 666, by a two-digit number, 55, your
answer is 36630, a five-digit number. The result
of a multiplication, the product, may have as many
digits as the sum of the number of digits in the
multiplier and the multiplicand. Therefore, you
must provide that many digits for the result.
The MPY subroutine accomplishes this in a very
straightforward manner. The multiplicand field,
which will be the eventual location of the product,
is extended to the left the same number of digits as
are contained in the multiplier. For example, if
you multiply a four-digit number by a two-digit
number, the subroutine will extend the four-digit
field to the left two places, to hold the six-digit
product.
It does this regardless of what was in these positions previously. Obviously, you must consider this
fact when laying out your data areas in core storage.
Figures 70.12 and 70. 13 present several examples of the use of the MPY subroutine.
Division. The divide subroutine, DIV, has the
calling sequence
CALL DIV (divisor, dividend, error code)
with the result placed in the dividend field.
Before covering the DIV subroutine, a quick review of division might be in order. If you divide
13 by 4, the result i!3 3 1/4, where
13 is the dividend
4 is the divisor
3 is the quotient
1 is the remainder
In other words:
dividend
divisor
quotient
+
remainder
divisor
This is the form of the result after use of DIV -a quotient of 3 and a remainder of 1. Note that the
result is not 3.25. For this reason special care
must be taken when half-adjusting the result of a
division. Also note in Figures 70.14 through 70.17
that the length of the remainder field will be the
same as the length of the divisor.
Section
70
Subsections
Page
I
03
10
30
1130 COMMERCIAL SUBROUTINES - DECIMAL ARITHMETIC WORKSHEET
DESCRIPTION
BEFORE
X
= Extraneous Data
IWORK: Will remain unchanged
11.1213141516171819110 1111
IK~PKI
:rT;r:r
18191101111121131
~
I
"
~ADDEND
CODING
•
SUBTRAHEND
MULTIPLIER
NER
-
DIVISOR
=D
(
CALL
.. -
,
A
AUGEND, THEN
MUlTlPLieAND':==:I
THEN PRODUCT
DIVIDEND,
THEN QUOT AND REM
,--, -r-'
,
)1..
-IWORK: Unchanged
1
r
/
1213141516171819110 111
NER
=
J
I
KWORK: Result
1
I
I
COMMENTS
NER)
)
y
./
AFTER
,
J..
V
,--,--,
,
SUM~
MINUEND, THEN SUM
t
1
12131415161718191 11131
Section
Subsections
70
10
1130 COMMERCIAL SUBROUTINES - DECIMAL ARITHMETIC WORKSHEET
DESCRIPTION
Or
AO£)/T/O/v
TWcJ ;-/VE-,L)/6/T ";:/ELDS
x = Extraneous Data
BEFORE
OOO~6
00010
0OO4B
IWORK: Will remain unchanged
1 2 3 4
5 6
7 8
(/
0 0
/
.3 X X
9
)( X
10
11
KWORK: Will contain result
4
2 3
1
5 6
7
X- X
X X X 0
(/
9
10
11
0 X
X
.,.'><..'
8
0 3
12 13
), />(
~
,
I
"'
CODING
:~
t=:ADDEND
SUBTRAHEND
NER=lol
A
I
L-
-IWORK:
1
2
() 0
3
4
0
/
5
/
6
3 X
A
V
,
,NER)
)
JI,.,
,~
/
~
=
0
10 11
12
13
><
X
NER
J
7
8
9
X X X
10 11
>< X
KWORK: Result
1 2
3 4
XX
><
5
6
t
7
8
9
U0 0 4 9 X X
COMMENTS
NER IS STILL 0., SO THE
ADDITION W~S CORRECT.
Figme 70,1,
MINUEND, THEN SUM
(£J1/?1RK ,~, ..5,KWORK; 4,a
CALLALW
AFTER
AUGEND, THEN SUM-=:::j
X
I
30
Page
04
Section
70
Subsections
10
I
Page
30
05
1130 COMMERCIAL SUBROUTINES - DECIMAL ARITHMETIC WORKSHEET
DESCRIPTION
BEFORE
X
A,OLJ/T/OA/ 0 ; TJ1/0 4 - o/6/T P/ELOS:
I1/H'ER£ o/V£ /S /VEG4)'7J/E. SU'/W/Sp,oS/77Ve
= Extraneous Data
0030
-OO2~
0004
IWORK: Will remain unchanged
1 2 3 4
5 6 7 8
X X X
><
0 0 2
9
~
10 11
X X
><
THE GO 15
ACTUALLY IN
KWORK: Will contain result
1
2 3
4
5 6 7
8
9
0 0 3 0 X
X
X X X X
X X
10
11
12 13
X
~
CORE STOeAGE
,4.5-7
I:==": "
CODING
SUBTRAHEND
NER
@]
=
A
I
CALL
(IWO£K , 5, a
ADD
,
AFTER
IWORK:
1
2
X X
3
4
5
/
6
A.
V
,KWc/k'K, --L-,
,
4-
,
7
8
G
9
.J
y
.1.
=
0
10 11
12
13
x x x x x x x
X
><
10 11
X X X
,NER)
r
KWORK: Result
1 2
3 4
a
Figure 70. 2 •
MINUEND, THEN SUM
NER
X )( (2 0 2
COMMENTS
AUGEND, THEN SUM==:!
JI..
./
--
•
:~
ADDEND
0 0 4
t
5
6
7
8
9
Section
Subsections
Page
I
06
70
10
1130 COMMERCIAL SUBROUTINES - DECIMAL ARITHMETIC WORKSHEET
DESCRIPTION
BEFORE
X
AO£)IT/O/1/ c:Jr- TJ1/0 ~-L)/G/T F/ELOS~
WHERE ONE /S/vEGAT/VE. Sc/U /S NEC?ATIVE
-000065
000010
-000055
= Extraneous Data
IWORK: Will remain unchanged
1 2 3 4
5 6 7 8
a
0
0
9
10
CJ L CJ X X X X
11
KWORK: Will contain result
><
1~1;1:1:1;1~171819 [1lTl31
THE:5
/s
/NCORE~
STORAG€
"
CODING
SUBTRAHEND
= [QJ
A
I
,
AFTER
IWORK:
1
2
3
4
5
/
6
A
8
9
10 11
KWORK: Result
1 2
3 4
S
()
0
,NER )
,~
.
NER
7
\
)
I\,
0 0
Figure 70, 3.
MINUEND, THEN SUM
)r
/
0 0 CJ 0 / 0 X X X X X
COMMENTS
==:I
AUGEND, THEN SUM
(I wa~ ,~, c;:; ,k""Wt?RK, ~, ~
CALLAOO
--
,
.-
:t
t=:ADDEND
NER
AS-~
= c7
~
5
6
-
7
.5 5 X
8
9
)( X
IN CORE ,4.5-6
10
11
12
13
>< X X X
30
Section
70
Subsections
Page
I
07
10
30
1130 COMMERCIAL SUBROUTINES - DECIMAL ARITHMETIC WORKSHEET
DESCRIPTION
ADDI//OA/
o.".c A
S-D/6/T ~/.EL~
BEFORE
.:f-D/G/T F/CLLJ Tc:JA
BOTHPO.~.5/T/Vc
00077
X = Extraneous Data
/
000 78
IWORK: Will remain unchanged
1 2 3 4
5 6 7 8
X
><
X X
1
9
10 '11
KWORK: Will contain result
1
2 3
4
5 6 7
X X X >< X X
t) 0
0
7 7
)(
8
>< ><
9
10
11
12 13
X X X X X
~
,
I
"
CODING
:~
t=:ADDEND
SUBTRAHEND
NER
@]
=
A
I
l
MINUEND, THEN SUM
A
,(
(IWORK , ..5 ,
CALLAO£>
AUGEND, THEN SUM==:!
.5 ,KIYORk ,~.
Jl
Y
AFTER
IWORK:
1
2
3
4
X X X X
5
/
6
1 /
Figure 70.4.
NER )
)
~
I
NER
7
8
X X
9
10 11
><
X X
=
0
11
12
)<.
x ><
J
KWORK: Result
1
a
COMMENTS
,
;
./'
--
f,
2
3
4
5
0 0 7 13
*
X x x X- x
6
7
8
9
10
13
Section
Subsections
Page
I
08
70
10
1130 COMMERCIAL SUBROUTINES - DECIMAL ARITHMETIC WORKSHEET
c:JF rwo g-LJ/G/T F/fLDS
-St/M 2/0£5 /VCJT F/T /N ALLOTTE.£) AREA
DESCRIPTION-ALJ.!)/T/CJA/
BEFORE
50
X = Extraneous Data
75
IWORK: Will remain unchanged
1 2 3 4 5 6
7 8
X X X
7 .5
X
X
9
><
10 11
X X
KWORK: Will contain result
1 2 3 4
5 6 7
><
X
S 0
8
><
X X >< X
9
10 11
X X
12 13
X >( X
~
,
"-
CODING
t=:;ADDEND
SUBTRAHEND
NER
[QJ
=
A
I
./
IWORK:
1
2
3
X X X
COMMENTS
Figure 70.5.
4
5
7 15
/
6
MINUEND, THEN SUM
A
V
,
AFTER
:t
(IWO,.eX , 4, 5,KWt?R/<, 2,..3
CALL 4P...o
--
.-
AUGEND. THEN SUM-==:!
,
)\.
,
,NER)
J
y
.1..
J
NER
=
.3
J
7
8
X X X
9
10 11
)(
X )(
KWORK: Result
1 2 3 4
~
5
6
7
10 11 12
13
X 9 9 X X X X X X X X X
.x
8
9
- T,HE SU/W 4REA /5 ~/LLE.o W/T# S~
-NER /S SET TeJ T#'c I/~Lt/E O~ T#£
C;;~h PARA/wErcR
30
Section
70
Subsections
Page
I
09
10
30
1130 COMMERCIAL SUBROUTINES - DECIMAL ARITHMETIC WORKSHEET
DESCRIPTION A£)£)IT/~A/
o"c TWa "c'/ELOS, N#ERE T#E
,4Z/oENO /s LO/V6ER Th'AN THe A(/C7END
BEFORE
x = Extraneous Data
0008
+00680
IWORK: Will remain unchanged
1 2 3 4
5 6 7 8
0
~ ~
9
10 11
KWO R K: Will contain result
1
2 3 4
5 6 7
t3 0 X. X X X X X
(:)
a
C)
8
8 X X Xx
9 10 11
12 13
x xxx x
"
,
t:=-: ,
CODING
ADDEND
SUBTRAHEND
NER
=[g
A
I
CALL
400 (.IWORK
./
AFTER
IWORK:
1
2
3
4
0 0 0 8
5
/
6
a x-
:t
Figure 70. 6.
A
)(
1\.
I
NER
7
8
9
X
x
X X X
)
,NER)
J
y
,
10 11
KWORK: Result
1 2
3 4
0 Cl 0 8
COMMENTS
MINUEND, THEN SUM
,..L,..s ,kPY'''RK,..L, ~
\
--
•
AUGEND, THEN SUM-=:::I
5
=
t
6
7
8
9
10 11
12
13
X X X X X X X X X
NOrE- EVEN THOc./G# TNE RESUL~ ~Ba-,
11/0CLO r / T /N' 4 ,lJ/6/TS,T#EALJO
5u8Rour/A/E )1//L-L MOT AO~ S/NCc
T#/5/.5 ,4 POTENT/ALL Y .2)ANGEROVS
S/7c/AT/ON. NER /sser /0 4.
Section
Subsections
Page
J
10
10
70
1130 COMMERCIAL SUBROUTINES - DECIMAL ARITHMETIC WORKSHEET
DESCRIPTION
BEFORE
X
SUBTRACT ONE 5-.0/6// F/ELO FRO/W
ANOTHER 5-DIG/T F/ELD
= Extraneous Data
000/4
-000/8
-OOOO¢
IWORK: Will remain unchanged
1 2 3 4
5
6 7 8
X
)(
X X 0 0 C;
9
8
/
10
11
KWORK: Will contain result
1
2 3
4
5 6
7
X )(
8
9 10 11
12 13
X X X X >< X )( x: 0 0 0 /
4
a.
I
"
CODING
SUBTRAHEND
NER
=~
I
CALL
SUB (ZWORX
"
AFTER
-IWORK:
2
1
X ><
3
4
)( X
5
/
6
7
8
9
/
", S,
1
:~
t=:AOOENO
AUGEND, THEN SUM-==:!
MINUEND, THEN SUM
A-
)(
9
,KNV'-PK, 9,
)\.
)
,
Figure 70. 7.
NER=
0
10 11
12
J
KWORK: Result
1 2
3 4
~
5
6
X X X X X X
COMMENTS
)
,NER)
~
10 11
0 0 t:J / 8 X X
/./!
7
8
)( )(
9
13
-
0 0 0 0 4-
30
Section
70
Subsections
Page
I
11
10
30
1130 COMMERCIAL SUBROUTINES - DECIMAL ARITHMETIC WORKSHEET
DESCRIPTION
S{'/8TR4CT ONE /O-'z)/6/T F/eLD FROM'
4
BEFORE
/2'-£)/6/7 /=/EL£). RESULT /S' A/e64T/V£
X = Extraneous Data
-
-00000 / / /
IWORK: Will remain unchanged
1 2 3 4
5 6 7 8
r;; {;-;
CJ 0 0 0
OOOOOSS55S55
OOO~~b0GG~
9
10
11
~ ~ ~~
X
I / / /
KWORK: Will contain result
2 3
4
5 6
1
7
X () 0 0
8
a0 s
9
10
11
12 13
..r.S .5 S .5 S -.J
.
I
"
CODING
t=:ADDEND
SUBTRAHEND
NER
= [Q]
A
I
CALL
-IWORK:
1
2
3
0 0 0
4
~
5
/
6
:~
MINUEND, THEN SUM
A
)(
,
(IWORX ,1, /O,K'WCJRX,--E..,
SUB
L-..
AFTER
•
AUGEND, THEN SUM==:!
)
JI.
./
/3,NER)
~
.1..
r
NER
J
7
8
9
10 11
C::J & til ~ ~ t4 X
KWORK: Result
2
3 4
1
~
5
6
7
8
9
10 11
X 0 0 0 0 0 I / / /
Z
COMMENTS
Figure 70.8.
= 0
/05 IN CORE 4S -'2
/
12
13
-
/ .1
~
Section
Subsections
I
10
70
1130 COMMERCIAL SUBROUTINES - DECIMAL ARITHMETIC WORKSHEET
DESCRIPTION
BEFORE
SUBTRACT A 3-"£)/6/T
A R-'o/GIT FIELD,
~/ELD
FRO/w
09
X = Extraneous Data
-003
IWORK: Will remain unchanged
1
2 3 4
6 7 8
5
0 Cl 3 X X X X X
9
10
11
X
X
x:
KWORK: Will contain result
1
2 3
4 5 6 7
8
9
10
>< 0 9
X
x:
X X X X
X X X
X
11
12 13
j
I
"
CODING
SUBTRAHEND
NER
CALL
= @]
A
r
-IWORK:
1
2
3
4
0 0 3 X
5
/
6
X X
AUGEND, THEN SUM-==:I
MINUEND, THEN SUM
A
V
,
(IW~RK ,1, .3 ,k~RK, 6, ~R)
5t/B
)1..
L..-
AFTER
.-
:t
CADDEND
/
7
8
9
10 11
><
>(
><
X
><
)
y
..
I
r
NER
=
7
10
11
12
X
X- X X
J
t
KWORK: Result
1
2
4
3
5
X X X >( .>(
6
7
8
9
0 9 X X
VNCHA/IIocD,1
COMMENTS
NOTe,'
-NER
SET TO
7
- sUBTRACT/ON #OT C,L/RR/ELJ
CJc/T BECAUSE OF POTE/VT/.4L
ERROR
Figme 70,9,
CONO/T/OA/
13
30
Page
12
Section
70
Subsections
Page
I
13
10
30
1130 COMMERCIAL SUBROUTINES - DECIMAL ARITHMETIC WORKSHEET
DESCRIPTION
SU!3TRACT A AlEGATIVE ,3-LJ/G/T F/EL.o
FROM ,4 POS/T/VE 4-£J/C7/T ;,C/ELO
BEFORE
0988
- (-45)
1033
X = Extraneous Data
IWORK: Will remain unchanged
1
2 3 4
5 6
7 8
X X-
X
9
10
11
KWORK: Will contain result
1
2 3
4
5 6
7
>< X 0 4- 15 X X X
$/S/NCORE
11
12 13
I:==:
,
"
ADDEND
SUBTRAHEND
I I
•
:~
AUGEND, THEN SUM==:!
MINUEND, THEN SUM
NER
== U'
CALL
Sc:/b' (IWOIq,~, G, 8 ,f{yt/uiPK,..:5 ,8
A
I
"----
Y
A
)r
),
,,
-3
4
5
/
6
NER
7
8
-
9
)
,NER)
)
Y
~
AFTER
= 0
10 11
X X X X X 0 4 5 X X X
KWORK: Result
1
2
3 4
X >( X X
Figure 70, 10,
10
~
CODING
COMMENTS
9
X X XX 0 9 8 8 X X X X X
AS-(O
IWORK:
1
2
8
5
6
7
8
9
.1 0 3 3
X
10
11
12
13
,xc X- X X
Section
70
Subsections
Page
I
14
10
1130 COMMERCIAL SUBROUTINES - DECIMAL ARITHMETIC WORKSHEET
SUBTRACT A N£GATIV~ 2- DIGIT FIELD
FROM A PO.5/TIV§ 2-D/617 FI£LD.RESULT700LAe-G!
DESCRIPTION
BEFORE
88
X = Extraneous Data
(-)- (08
IWORK: Will remain unchanged
1
2 3 4
5 6
7 8
X
X )( 0
9
10
11
KWORK: Will contain result
4
2 3
1
5 6 7
8 X X X X X X
8
9
10
11
12 13
X X B 8 X X X X X X X X X
~
I:==:
CODING
,
I
"
ADDEND
SUBTRAHEND
NER
= [QJ
A.
I
CALL
..sU8
:1:
AUGEND, THEN SUM-=:j
MINUEND, THEN SUM
A.
\{
~
)1..
\
AFTER
IWORK:
1
2
3
4
5
-
/
6
4-
NER)
)
y
/
--
,
,-,-,
( IWOEK ,L,~,KWORK
I
f
7
8
9
10 11
X X X ~ 8 X X X X X X
KWORK: Result
2
1
3 4
NER
=
4
10
11
12
t
5
6
7
8
9
13
X X fj :2 X X X X X X X X X
COMMENTS
NOTE"- R'G'...5ULT FIELD FILLED WITH
- NER SET TO 4
Figure 70. 11.
9$
30
Section
70
Page
Subsections
I
10
30
15
1130 COMMERCIAL SUBROUTINES - DECIMAL ARITHMETIC WORKSHEET
MULTIPLY TWO 4- DIGIT NUM8ERS
1111
2222 = 02.46:;, 8(;; 42-
DESCRIPTION
BEFORE
*"
X = Extraneous Data
IWOR K: Will remain unchanged
2 3 4
1
5 6 7 8
9
10
11
KWORK: Will contain result
1
2 3
4
5 6
7
1 1 1 1 X X X X X X X
8
9
10
11
12 13
X X X X 2 2 2 2 X X X X X
~
I
I
§AD~END
CODING
-
-.... -
SUBTRAHEND
MULTIPLIER
NER
CALL
AUGEND, THEN SUM-=::::::j
MINUEND, THEN SUM
MULTIPLICAND,:=:!
THEN PRODUCT
DIVIDEND,
THEN QUOT AND REM
DIVISOR
=~
A
A
I
)r
)
MPY ( IWORK ,L,~,KWORI(, S ,~,NER)
\
,,
JI..
Y
./'
AFTER
-IWORK: Unchanged
1
2 3 4
5
/
/
/
COMMENTS
Figure 70,12.
/
/
6
)
NER
=
10
11
0
J
7
8
9
10 11
X X X X X X X
KWORK: Result
3
4
5
6
0 2 4-
~
8
~
1
2
~
7
4
8
9
12
13
2 X X X X X
NOTE TH.47 THE PRODUCT t4REA (KWORK)
Ht4S BEEN £XT£ND£"D 4 PL. 4CES TO TH£ LEFT.
Section
Subsections
Page
I
16
10
70
1130 COMMERCIAL SUBROUTINES - DECIMAL ARITHMETIC WORKSHEET
DESCRIPTION
MULT/PLY
SH'O~NG-
BEFORE
rwo
4-..o/G/T /vVA4Bek~'-3J
4N ERRoR cO/V'v/ T/oN
X = Extraneous Data
IWORK: Will remain unchanged
4
2
6 7 8
1
5
3
.f :f d I X X X
9
10
X >( X
11
KWO R K: Will contain result
4
1
2 3
5 6
7
X
9
8
10
11
12 13
X X 2- 2 2 2 X X X X X X
-.
x..
l
.
§AD~ND
CODING
T
AUGEND, THEN
SUBTRAHEND
MULTIPLIER
NER
A
r
CALLA4PY
(IWORK
\r
IWORK: Unchanged
2
1
5
3 4
/
6
/
I
COMMENTS
,
J\..
NER)
J
y
-
r
NER
= GO
J
7
8
9
10 11
/ X X X X X /\ X
NER IS SET TO G
6
~7
3
4
5
.X X 2
<-
?
2 2 X X
1
2
8
9
10
11
12
,~
,x
.~
X .X
8£CAU.....S'E ThERe
WAS NOT E/VOt../GP ROOk? T?i EXTc/ .. '~
..
Tl-le PRC}DUC:T 4REA 4PLAC£S TO /--he
LE~T
Figure 70, 13,
C;
,--,~,
KWORK: Result
I
,
4 /~"(fYO,.(~/.3
,--,--,
./
--
A
.
I
\
AFTER
MULTIPLICAND,
THEN PRODUCT
DIVIDEND,
THEN QUOT AND REM
.. ..
DIVISOR
= ~
SU~
MINUEND, THEN SUM
13
30
Section
70
Subsections
Page
I
17
10
30
1130 COMMERCIAL SUBROUTINES - DECIMAL ARITHMETIC WORKSHEET
DIVIDE 0/3 By 04
DESCRIPTION
BEFORE
X = Extraneous Data
IWORK: Will remain unchanged
1
2 3 4
5 6 7 8 ·9
X
X X X
X 0
4
10
11
KWORK: Will contain result
1
2 3
4
5 6
7
X X X X
X X 0 / 3
8
9 10 11
12 13
X X X X X X X X
~
I
I
EAD~ND
CODING
AUGEND. THEN SUM
SUBTRAHEND
DIVISOR
--.- ..
A.
)(
MUL TIPLIER
=
NER
CALL
@]
D/V
,
MULT!PLlCAND'::==:I
THEN PRODUCT
DIVIDEND,
THEN QUOT AND REM
A.
(IWORK ,~,L,KWO.eK,~, S
,
)1-
\
AFTER
IWORK: Unchanged
I'
/
I;
'---y--J
I" I
,NER)
....
NER
34 5
8 9
1 1 1 1 1~ 1 1 1'0
2
,
)
y
/
--
===I
MINUEND, THEN SUM
=
0
t
KWORK: Result
I~ I~ I; I~ I; 1 11 1 1'lTl31
6
7
8
9
~'--y--J
1
COMMENTS
~
RE.SULT
IS;31..~
J
:. ~
OIGITS WID~ Th'G KWO,€K
FIELD f-IAS BeeN EXTENOEO 2 'pOSITIONs 70 THE: LEf:~
AND THE R€M/JINOER OCCUPIES THe RIGHTMOST
"BEC~(/S£ ,1-11: DIVISOR /s
g
Figure 70. 14
OIGIT..sf'
g
Section
Subsections
Page
I
18
10
70
1130 COMMERCIAL SUBROUTINES - DECIMAL ARITHMETIC WORKSHEET
DIVIOE 0/5
DESCRIPTION
BEFORE
.By 008
X = Extraneous Data
IWORK: Will remain unchanged
1
2 3 4
5 6
7 8
0 0 8
9
10 11
KWORK: Will contain result
X X X IX X
X X X
1:1~1:1;1:1;17181911lTT31
4
I
gAD:ND
CODING
SUBTRAHEND
MULTIPLIER
NER
DIVISOR
[QJ
=
A
f
CALL
DIV
( rWO.eK
IWORK: Unchanged
1
2 3 4 5
0 0 6 X
X
/
6
8
7
9
X X X X
COMMENTS
MULTIPLICAND,
THEN PRODUCT
DIVIDEND,
THEN QUOT AND REM
-
A
X
)
,L,.£...,NER)
,
)\..
)
y
.
,
NER
=
0
10
11
12
J
10 11
KWORK: Result
1 2
3 4
X
'---y--/
~
MINUEND, THEN SUM
,_I_,~, KWO.eK
/'
--
-..
)(
\
AFTER
I
AUGEND, THEN S§
5
6
7
8
9
13
0 0 / 0 0 7
~~.
~
-
RESULT/.5'/2~
~B£C~USE TH€ /JIVI.50R IS
~
- 8
OIGITS WIOBj TH€ KWO~K FIELD
H/iS 8EliN G"XTENDED
POSITIONS TO TI-IG LEF0 /IN£)
THE ~EM,4IN[)£R OCCUPI£S THE RI6)-/TMO.sT ~ DIGITS. Q
a
Figure 70, is,
30
Section
70
Subsections
I
10
Page
30
19
1130 COMMERCIAL SUBROUTINES - DECIMAL ARITHMETIC WORKSHEET
DESCRIPTION
DIVIDE A NEGA71VE NUMBER 8Y.4
of=-2-~2 OR-3 r2
POSITIVE NUM8£R-S/2
BEFORE
X = Extraneous Data
IWORK: Will remain unchanged
1
2 3 4
5 6 7 8
9
10
11
KWORK: Will contain result
0 2 X X X X X X X X X
I' 121;1~1;161718191'lTl31
..
,
I
CODING
AUGEND, THEN
§AD;END
SUBTRAHEND
MULTIPLIER
NER
DIVISOR
= @]
A
t
CALL
D/V
( IWORK
\
- ..
MUL TIPLICAND,
THEN PRODUCT
DIVIDEND,
THEN QUOT AND REM
'\(
A.
,--,--,
I
Y
2
KWOleK
-IWORK: Unchanged
2 3 4 5
1
/
6
Figure 70.16.
)
Y
.
I
NER
7
8
9
10 11
0 2 X X X X X X X X X
COMMENTS
,
.s NER)
,--,--,
..3
,
)"
..""
AFTER
SU~
MINUEND, THEN SUM
KWORK: Result
~
=
0
I~I~I~I~I; 161718191'lTT31
- THE SIGN I~ CAR~/E"D W/TI-I 7HE' QUOT.
Section
Subsections
10
70
I
30
r---------------------------'-----------.--.--.--------,
1130 COMMERCIAL SUBROUTINES - DECIMAL ARITHMETIC WORKSHEET
DESCRIPTION
BEFORE
DIV/S/ON
BY
ZERG~ /S
./,i/VAL/D
X = Extraneous Data
IWORK: Will remain unchanged
1
2 3 4
5 6
7 8
0 0 0 X X
)(
9
10
11
X X. X X
)(
KWORK: Will contain result
1
2 3
4
5 6
7
X X X 7 0 8
,~
DIVISOR
101 ,
A
(/Wo.Rk
CALL..DIV
\
-IWORK: Unchanged
1
2 3 4 5
/
6
7
8
12 13
~ X
X
..
MINUEND, THEN SUM
MULTIPLICAND':::=:1
....
THEN PRODUCT
DIVIDEND,
THEN QUOT AND REM
...
A
~r
,
/ 3 !{kvt;R,K,--,--,
4- ~ NER)
,--,-,-,
Y
9
X X
11
AUGEND, THEN SUM-==I
J\
J
,~
../'
AFTER
10
I
.....
MULTIPLIER
=
.
9
I
SUBTRAHEND
NER
XX
.-
~..I
§AD~N"-
CODING
8
NER
=
(p
10
11
12
10 11
0 0 0 X X ;>( X X X X X
KWORK: Result
1 2
3 4
~
5
6
7
8
9
13
0 0 0 7 0 8 X )<.. X X X X X
COMMENTS
Figure 70.17.
- NO J)/V/S/OA! IS PERFO"t?MED
-NER /5 2>cT ;0 cP
Page
20
Section
Subsections
Page
I
21
10
70
30
Constants
Testing and Modifying Signs
There are four ways in which you may create constants such as 1968, 40, 6600, etc. To illustrate,
suppose you wish to create the constant 660000 (the
Social Security deduction base, in cents) to be
stored in an array named ISSD, DIME NSIONed as
ISSD (6). The four options are:
1. Use FORTRAN equalities.
To facilitate testing and modifying the signs of decimal arithmetic fields, the subroutine NSIGN is
available. It has four parameters:
NARR Y The name of the array
NPOS
The position in the array to be tested
NEWS "New sign", indicating what you want
done to the previous sign:
ISSD
ISSD
ISSD
ISSD
ISSD
ISSD
(1)
(2)
(3)
(4)
(5)
(6)
=6
=6
=0
=0
=0
=0
2. Use the DATA statement.
DATA ISSD/6, 6, 0,0,0,0/
or
DATA ISSD/2*6, 4*0/
3.
Use the TILL subroutine.
CALL FILL (ISSD, 1,2,6)
CALL FILL (ISSD, 3,6,0)
4. Read it from a card, tape, keyboard, or disk.
Option 2 is preferred, since it consumes less core
storage than the other three meth~ds.
Negative constants are handled in much the same
way. Because of their special representation, however, it would be wise to make the constants pos itive
and change the arithmetic. For example, rather
than set up -1 and add it to something, it would be
easier to subtract +1.
+1
Make it positive
Reverse it
-1
Make it negative
NOLDS Leave it alone
NOmS "Old sign", returned to you, indicating
what the previous sign was:
+1
It was positive
-1
It was negative
You, the programmer, send the subroutine the
first three parameters; it returns the last. To
illustrate, suppose you wish to test the sign of the
18th position in the K array:
• Case 1: It Is Now Positive:
NOLDS is returned as +1
K(18) is made + if you said
CALL NSIGN (K, 18, +1, NOLDS)
K(18) is changed to - if you said
CALL NSIGN (K, 18,0, NOLDS)
K(18) is made - if you said
CALL NSIGN (K, 18, -1, NOLDS)
K(18) remains + if you said
CALL NSIGN((K, 18, NOLDS, NOLDS)
• Case 2: It Is Now Negative:
NOLDS is returned as -1 and
K(18) is made + if you said
CALL NSIGN (K, 18, +1, NOLDS)
K(18) is changed to + if you said
CALL NSIGN (K, 18,0, NOLDS)
K(18) is made- if you said
CALL NSIGN (K, 18, -1, NOLDS)
K(18) remains - if you said
CALL NSIGN (K, 18, NOLDS, NOLDS)
o
Section
70
Moving Signs
The NS1G N routine may also be used to move signs.
The two statements
CALL NS1GN (NARRY, I, NOLD, NOLD)
CALL NS1GN (KARRY, J, NOW, JUNK)
will make KARRY (J) have the same as NARRY (I).
Subsections
10
I
30
Page
22
Comparing Decimal Fields
The FUN eTION ICOMP is used to compare two
variable length decimal fields. In practice, it is
typically used within the parentheses of an IF statement;
IF (ICOMP (IWORK, 1,5, KWORK, 6, 10))1, 2,3
This statement will compare (IWORK, 1,5) with
(KWORK,6,10), and branch to
Statement 1 if the first is less than the second.
Statement 2 if they are equal.
Statement 3 if the first is greater than the second.
As was true with the ADD and SUB subroutines,
the first field must not be longer than the second.
Since no error code is returned from this subprogram, there is no way to tell that such an error
has occurred, and the results will therefore be
meaningless.
Section
70
Subsections
10
I
40
Page
01
Summary
If exact results are desired, you must take certain
precautions regarding arithmetic calculations.
1. Use one of the following:
Integer arithmetic
Decimal arithmetic
Real, fixed-point arithmetic, with no
fractions
2. If fractions are allowed to occur (floatingpoint real arithmetic), your results are likely to
show inaccuracies. These inaccuracies will be
slight, but enough to cause significant problems.
3. If no number will ever exceed 8,388,607. ,
you may use standard precision, real, fixed-point
arithmetic.
4. If no addition will ever exceed
2,147,483,647., you may use extended precision,
real, fixed-point arithmetic.
5. If the result of a multiplication will exceed
1,073,741,823., you should consider using decimal arithmetic, since real extended precision
arithmetic will be inaccurate above this limit.
6. If the result of an addition or subtraction
falls in the range 1,073,741,824. to
2,147,483,647., you should not attempt to output
it with the standard FORTRAN F Format; use the
PUT subroutine instead.
7. If any number will exceed 2,147,483,647.
(now or in the foreseeable future), use decimal
arithmetic rather than real arithmetic.
Section
70
OVERLAPPED INPUT/OUTPUT
Introduction
As a machine, the IBM 1130 Computing System is
capable of performing many tasks simultaneously.
For example, it can print, type, read a card, and
compute, all at the same time. This can be done
through its "cycle-stealing" I/O channels and the
priority interrupt system. Each I/O device may,
through an interrupt, signal the CPU that it requires
service, and steal a cycle (3.6 or 2.2 microseconds)
from some other process to do what it needs done.
This process is commonly referred to as "over~
lapping',' .
For example, in the case of the disk, one data
word travels past the read/write heads every 27. 8
microseconds. However, it only takes one cycle
(3.2 or 2.2 microseconds) to transfer that word
from core storage to the disk (if it is being written)
or from the disk to core storage (if it is being read).
Subsections
Page
I
01
20
01
This means that only a little more than 10% of the
CPU time is required to read and write on the disk;
the remainder is available for other use.
Although most of the 1130's I/o devices can be
overlapped, standard 1130 FORTRAN permits only
two of them to operate in this fashion: the disk and
the 1403 Printer. There are several good reasons
for this limitation. For example, suppose you
wrote a program to read two numbers from a card,
add them together, and print the result. With full
overlap, the addition could conceivably be under
way before the two numbers had even been placed in
core. Obviously, this would not be satisfactory.
To take full advantage of the potential of the
machine, in FORTRAN, it would be necessary to
develop a special FORTRAN, which would then
violate the USASI standards set up for that programming language. Avoiding this, IBM has
developed the Commercial Subroutine Package
(CSP) -- a set of subroutines operating within the
FORTRAN system, rather than as part of the
FORTRAN language itself.
Section
70
Subsections
Page
I
01
20
10
The Commercial Subroutine Package Overlapped
I/ 0 Subroutines
CSP subroutines may be divided into three groups:
The I/o subroutines themselves
Several I/o utility subroutines
Those character handling routines necessary for
proper use of the I/o routines
This section discusses the former two groups; the
latter is covered later in this section under "Character Handling Techniques".
General
All of the overlapped I/o subroutines operate on
data in Al format -- one alphabetic character per
word, left-justified. If you wish to read 80 card
columns, you must set up an array 80 positions long
to receive the data, and convert the Al data to whatever format you require for later processing. There
are no FORMAT statements; you must handle all
conversions (see "Character Handling Techniques").
Unlike standard FORTRAN, the overlapped I/O
subroutines are oriented toward a sign punch over
the low-order digit of a field. For example, a negative number or credit of -$6. 50 would be punched
with an II-punch over the zero, rather than in a
separate column, as would be done if FORTRAN
FORMAT were used.
In general, for your non-disk I/O, you must
choose either one system or the other: FORTRAN
FORMAT or overlapped I/O .. They may not be mixed
within the same program.
For further detail on these subroutines, see the
SRL manual H20-0241.
READ a Card, 1442-6 or 7
The subroutine READ will read a card from the 1442
Model 6 or 7, overlapping reading with the conversion
from card code to Al format. The CPU will not
proceed any further until the last des ired card
column has been read and converted. Therefore you
need not be concerned that processing will be started
before the desired values have reached core storage.
A typical call to this routine would be
NER = -1
CALL READ (INOUT, 1, 80, NER)
which would read and convert 80 columns, and place
the result in the array INOUT. It should be followed
by a
IF (NER) xxx, xxx, xxx
If NER is still -1, everything is normal; if it is
zero, the card just read was the last card in the
hopper; if it is +1, there was a read or feed check
(1442 malfunction).
It is equivalent to
DIMENSION INOUT(80)
77 FORMAT (80A1)
READ (2,77) INOUT
Section
70
Subsections
Page
I
02
20
10
PUNCH a Card, 1442-6 or 7
Select STACKer, 1442-6 or 7
The subroutine PUNC H will punch a card on the 1442
Model 6 or 7. Nothing will be overlapped with this
activity. A typical use is
Subroutine STACK permits the FORTRAN programmer
to direct a card into the alternate stacker on the 1442
Model 6 or 7. After the statement
NER =-1
CALL PUNCH (INOUT, 1,20, NER)
CALL STACK
which will punch the first 20 words of the INOUT
array into the first 20 columns of a card.
It is equivalent to
DIMENSION INOUT (80)
77 FORMAT (80A1)
WRITE (2, 77) (INOUT(K), K=1, 20)
The use of the error parameter, NER, is identical to the READ subroutine.
the last card read (and only the last card) will be
selected into the alternate stacker.
The placement of the CALL STACK statement is
important:
• If the program reads and punches into the same
card, the statement may be placed between the READ
and WRITE, or after the WRITE.
• If the program reads (but doesn It punch), the
CALL STACK goes after the READ statement that
read the card to be stacked.
• If the program only punches (and does not read),
the CALL STACK should be placed after the WRITE
statement that punches the card to be stacked.
Section
70
Subsections
20
1
10
Page
03
PRINT on 1132
SKIP on 1132
Subroutine PRINT enables you to write on the 1132
Printer, overlapping printing with other processing.
A typical use of this routine is
Subroutine SKIP permits full use of the carriage control tape mechanism on the 1132. Skipping is significantly faster than printing blank lines and should be
used wherever possible. A typical use of this routine
is
NER = 1
CALL PRINT (INOUT, 1, 120, NER)
CALL SKIP (KODE)
This will initiate the printing of the 120-word array
INOUT on the 1132, then continue processing. Because of its overlapped capability, it can drive the
1132 Printer substantially faster than the equivalent
FORTRAN/FORMAT statements:
DIMENSION INOUT (120)
88 FORMAT (120A1)
WRITE (3, 88) INOUT
Like READ and PUNCH, it should be followed
with a test of NER:
• If it is still 1, nothing unusual happened.
• If it is 3, the line being printed matches with
a channel 9 punch on the carriage control tape.
• If it is 4, the line being printed matches with
a channel 12 punch in the carriage control tape.
Note that the first pos ition is not used to control
the printer carriage, as it is with stacdard FORTRAN.
The SKIP routine must be used if you wish to skip to
channell, double-space, etc.
where the allowable values of KODE, and their
meaning, are as shown in Figure 70.18.
Value
of KODE
Action Taken
by the 1132
12544
Immediate skip to channel 1
12800
Immediate skip to channel 2
13056
Immediate skip to channel 3
13312
Immediate skip to channel 4
13568
I mmediate skip to channel 5
13824
Immediate skip to channel 6
14592
I mmediate skip to channel 9
15360
I mmediate skip to channel 12
15616
I mmediate space of 1 space
15872
I mmediate space of 2 spaces
16128
I mmediate space of 3 spaces
0
Suppress space after printing
Figure 70.18. SKIP codes for 1132 Printer
Section
70
Subsections
Page
I
04
20
10
Type on Console Printer
Accept Data from Console Keyboard
Subroutine TYPER will initiate typing on the console
printer, and then continue processing. Actual printing time will be overlapped with other processing
(printing on the 1132, reading cards, computing,
etc.). A typical call is
Subroutine KEYBD will read characters entered from
the console keyboard, Only 60 characters at a time
may be read with this routine. This activity is not
overlapped with any other function. An example of
the use of this subroutine is
CALL TYPER (INOUT, 1,50)
which will type the first 50 values of the IN OUT
array. There is no error parameter connected with
this routine.
In addition to printing, this subroutine also permits several typewriter control functions. If the
values listed below are inserted in the INOUT array,
the corresponding action will be performed at that
point:
Value
1344
5184
13632
5696
5440
9536
Action
Tabulate
Shift to black
Shift to red
Backspace
Carrier return
Line feed
Because TYPER does not start each line with an
automatic carrier return, you may want to place a
5440 in position 1 of the output array.
CALL KEYBD (INOUT, 1, 30)
which will read 30 characters from the keyboard.
This is no error parameter.
Section
70
Subsections
Page
I
05
20
10
A Precaution -- laND
Because of the properties of the overlapped I/o subroutines, all I/o activity must be completed before
you cause the 1130 to PAUSE or STOP. The subroutine laND will do this for you by testing the status
of the interrupts and looping until none are pending.
laND is required only when Vers ion 1 of the
Monitor is used; it should not be used if Version 2 of
the Monitor is in use.
The call to laND should always be placed immediately before each PAUSE or STOP statement:
CALL laND
PAUSE 1234
or
CALL laND
STOP 5678
Section
70
Using The Overlapped I/O System
Alternative A
Develop results
CALL PRINT ( )
CALL PUNCH ( )
General
If you are to gain the full potential of the over lapped
I/o routines, you should lmow several basic principles of this system:
• You must decide whether your non-disk I/O
will be done by FORTRAN FORMAT READs and
WRITEs or by the overlapped I/O subroutines. A
program cannot use both. Note that the disk I/o is
completely independent of the overlapped I/O system
and,does not enter into this discussion.
• Certain devices are not overlapped by these
routines, making the placement of the subroutines
CALLs quite important.
Subsections
Page
I
01
20
20
Alternative B
Develop results
CALL PUNCH ( )
CALL PRINT ( )
With alternative A, PRINTing is initiated, then
PUNCHing, and the two I/O functions are overlapped.
Alternative B, on the other hand, does not overlap
these two functions, since the 1130 will wait until
PUNC Hing is completed before starting PRINTing.
Alternative B does, however, overlap whatever
follows the PRINT statement.
To gain maximum overlap, then, the three truly
overlapped routines (PRINT, SKIP, and TYPER)
should be placed as early in the processing cycle
as possible. Figure 70.19 gives some examples
of good and bad usage of these routines.
Overlapping and Your Program
As far as your program is concerned, only two I/o
devices are really overlapped: the 1132 Printer and
the console printer. The other devices are either
not overlapped at all or overlapped with various
housekeeping chores (for example, code convers ion)
rather than with your program. In other words:
These subroutines
initiate an action,
then continue
processing:
PRINT
SKIP
TYPER
These subroutines start
an action and finish it
before they continue
processing:
READ
PUNCH
KEYBD
Thus the sequence in which you use these routines becomes important. For example, suppose
you have a program that develops some result, then
must print a line on the 1132 and punch a card. How
should this be done?
Bad Practice
Example
processing
1
I
processing
CALL PRINT
CALL SKIP
2
3
4
Figure 70. 19.
processmg
CALL SKIP
CALL PRINT
processing
processing
CALL PRINT
CALL PRINT
processing
CALL PRINT
CALL PRINT
CALL PUNCH
CALL PRINT
WRITE disk
1
p""~';ng
processing
I
1
I
Good Programming
CALL PRINT
{ CALL PRINT
CALL PUNCH
1
CALL PRINT
WRITE disk
Section
70
Subsections
20
I
20
Page
02
FORTRAN TRACE Not Permitted with Overlapped
Alphabetic Headings with the Overlapped I/O System
1/0 Routines
If you use the overlapped I/O routines, you must not
include any of the non-disk I/O devices on the *IOCS
control record; only *IOCS (DISK) is permitted.
This means that you may not take advantage of the
standard FORTRAN TRACE facility, but must
instead program your own trace. If this is done
while the program is being developed, it presents
little difficulty.
Several methods may be used -- for example:
• A series of numbered pauses, to display your
progress through the program.
• A set of extra PRINT or TYPER statements,
to function much the same as the standard TRACE.
It might be useful to code a subroutine called TRACE,
which would do this after testing Data Switch 15.
Since you may not use FORMAT statements in conjunction with the overlapped I/O routines, you must
enter alphabetic headings and other constants in
some other manner. Several methods are available.
1. Use the DATA statement. This allows alphabetic constants to be entered, in the proper format,
at the start of the program.
2. Read the alphabetic data from the card deck.
You may layout all the alphabetic data required
(headings, error messages, etc.) so as to fit in one
large array, then read that array from a deck of
cards each time the program is executed. Because
it is done only once, those program steps could be
made into a LINK, in which case it could use
FORTRAN I/O, regardless of which system the
main program used.
3. Same as 2, except that the read-in program
is run only once and places the array of heading
information on the disk. This data is then read from
the disk each time the main program is executed.
This is somewhat more foolproof, since you do not
have to worry about assembling the card deck each
time the main program is run.
Section
70
Subsections
Page
I
01
30
INPUT
THE INTERACTION OF ARITHMETIC AND I/O
You have seen that two options are available for I/O:
Standard
FORTRAN
Standard FORTRAN FORMAT
Overlapped I/o subroutines
Overlapped
I/O
You have also seen that, for all practical purposes,
two options are available for arithmetic:
FORTRAN real arithmetic
Decimal arithmetic, variable length.
While you may choose any des ired combination,
certain combinations appear easier to use than others.
You can see from Figure 70.21 that some provision
must in all cases be made for convers ion from input
code to some arithmetic code, then from some
arithmetic code to output code. If you use standard
FORTRAN exclusively, you specify, with the FORMAT
statement, what conversions you want. If you use
any of the other three combinations, you must specify
the des ired code convers ion with the character
handling routines supplied by the Commercial Subroutine Package: GET, PUT, EDIT, DECAl, A1DEC,
PACK, and UNPAC. (These routines are covered in
later sections of this Guide. )
Figure 70. 22 summarizes the advantages and
disavantages of each alternative. You can see that
the convenience items (ease of programming, readability, etc.) are gradually sacrificed in order to
make gains in the area of capability and performance.
Standard
FORTRAN
Overlapped
I/O
OUTPUT
Figure 70.21.
Convenience
Items
Standard FORTRAN
Easily
Programmed
?
Easily
Readable
Program
?
easy
Capability and Performance
Items
Easy to
Debug?
Trace?
Maximum
Size. of
Numerical
Values
?
Read a
Record
of Unknown
Format
?
Edited
Output
?
Zone
Punches
Allowed
?
I/O
Overlapped
?
very good
yes
9 digits
no
no
no
no
Standard FORTRAN
Extended with GET, PUT
and EDIT
a little
harder
very good
yes
9 digits
yes
yes
no
no
Standard FORTRAN Arith,
with GET, PUT and EDIT,
and overlapped I/O
a little
harder
very good
no
9 digits
yes
yes
yes
yes
FORTRAN I/O with
GET, PUT, EDIT and
Decimal Arith.
a little
harder
good
unlimited
yes
yes
no
no
Overlapped I/O with
Decimal Arith.
a little
harder
good
to fair
unlimited
yes
yes
yes
yes
Figure 70. 22.
can trace,
but not too
effectively
no
00
Section
70
Subsections
Page
I
01
40
01
CHARACTER HANDLING TECHNIQUES
General
A great deal of the programming effort in most commercial applications falls into the general classification
of character handling -- code conversion, editing,
moving data, testing zone punches, comparing alphabetic data, etc. This section covers many of these
tasks in detail, showing how they may be accomplished with the Commercial Subroutines.
Section
Subsections
Page
I
01
40
70
10
Code Conversion
Integer to Real -- FLOAT
As you saw earlier, code conversion is essential to
any program, commercial or technical. If you use
standard FORTRAN, you must specify the desired
conversions with the FORMAT statement. If you
are using FORTRAN augmented by the Commercial
Subroutines, you can also use the GET, PUT and
EDIT subroutines for special formatting. If you
are using the overlapped I/o routines, you must
specify all the code convers ions with the Commercial
Subroutines (except Al format), since no FORMAT
statements may be used.
Basically there are five internal codes with which
you might be concerned:
The FLOAT function, a FORTRAN standard, is used
to convert an integer to a real number. A typical
use of this function is
Integer
Real
Alphabetic -- one character per word (AI)
Alphabetic -- two characters per word (A2)
Decimal -- one digit per word
Very few programs can avoid converting from one
code to the other. Figure 70.23 shows the tools at
your disposal to effect all possible conversions. The
common ones are handled by a single subroutine;
those less often needed require a combination of two
or three subroutines.
The Al code is particularly important since all
the overlapped I/O routines require data in that
format. In addition, GET, PUT, and EDIT work
with data in the Al format.
The A2 code is used primarily when writing
alphabetic data on the disk, since it holds twice as
much data per word as Al format.
Decimal code is encountered only if you are using
the decimal arithmetic, variable length routines of
CSP.
TO
FROM
Integer
Real
Integer
PUT (FLOAT)
Real
Alphabetic (All
IFIX (GET)
GET
Alphabetic (A2)
UN PAC, then
UN PAC, then
GET, then
IFIX
GET
OECA 1, then
GET, then
IFIX
OECA 1, then
GET
Variable Length
Decimal
Figure 70. 23.
Alpha (A 1)
Alpha (A2)
Decimal
FLOAT,then
PUT, then
PACK
FLOAT,then
PUT, then
A1DEC
x = FLOAT
(K)
which will set the real variable X equal to the value
of K. The same conversion can also be accomplished
by coding
X=K
This also uses the FLOAT function, even though it
does not appear.
Real to Integer -- IFIX
The IFIX function, also a FORTRAN standard, is
used to convert a real number to an integer. A
typical use is
K = IFIX(X)
which will take the real variable X, convert it to an
integer, and store it as K. If X is 6.0, then K = 6;
if X is 87.9, then K = 87; and so on.
This can also be accomplished by coding K = X;
this too uses the IFIX function.
Section
70
Subsections
40
I
Page
02
10
A1 to Real -- GET
A1 to Integer
IBM supplies the GET function as part of the 1130
Commercial Subroutine Package (CSP). The original
A1 data may have resulted from a FORTRAN READ
with an A1 FORMAT, or from use of one of the CSP
Over lapped Input routines, which always results in
A1 format.
If you have a five-place array, in A1 format
As shown in Figure 70.23, this step requires use
of both IFIX and GET, in the following manner:
K(l) = 1
K(2) = 9
K(3) = 8
K(4) = 6
K(5) = 8
and you say
x = GET(K, 1, 5, 1. 0)
then X = 19868.
The last parameter (1. 0) is a shift factor, and
will usually be 1. 0 if you want accurate results. (If
it had been. 1, X would be 1986.8; however, since
the fraction . 8 is present, you could expect it to be
inaccurate.) Subsection 70. 10.20 explains why
fractions should be avoided in commercial work.
Basically, the above use of GET can be thought
of as equivalent to an F5. 0 in a FORMAT statement.
A shift factor of .1 would be an F5. 1; a shift of .01
would be F5. 2; a shift of .001 would be F5. 3; etc.
J
= IFIX(GET(K, 10,12,1. 0»
where positions 10 through 12 of the K array are
converted first to a real number, then to an integer
called J.
Secti0n
Subsections
Page
I
03
40
70
10
Real to A1 -- PUT
Integer to A1
This step is quite commonly required -- if you are
us ing the over lapped II0 routines, if you wis h to do
further editing, etc. It is accomplished with the
PUT subroutine supplied with CSP.
Suppose you have just computed a gross pay figure,
GROSS, which might have a typical value of 275869. ,
understood to be mills. Again, note that you are
working,in whole numbers, so that no fraction problems are encountered. This value is to be rounded
off and the result placed in the first ten postions of
array I}GROS for ,later editing and output. The
statement
This requires two steps, since PUT operates on
real numbers, not integers. If you have an integer
I, which you want converted to A1 format, you must
first convert it to real format:
x
or
X
= I
= FLOAT(I)
then use the PUT subroutine.
CALL PUT (KGROS, 1, 10, FLOAT (I) , 5. ,1)
will perform this conversion.
CALL PUT (KGROS, 1, 10, GROSS, §..,~)
will take GRQSS, add 5. to it, truncate the last 1
digit, and place it in A1 format in the KGROS array
as 0000027587, with leading zeros and no decimal
point.
The last two parameters, the adjust factor and the
truncate factor, usually form a logical pair. Obviously, if you add 5. to half-adjust, you won't want
to print the resulting digit. The table below shows
the common pairs:
5th parameter
(half-adjust factor)
6th parameter
(how many digits to
truncate from right end)
.5
o
5.
50.
500.
etc.
1
2
3
etc.
Half-adjust factors of less than. 5 should not be
used, since this will bring up the problem of inexact
fractions.
If GR'OSS is negative, an 11-zone punch will be
added to the code for the low-order digit. For example, if GROSS is -275869., the result will be
000002758P, where the character P is equivalent to
a 7,11 punch.
Or, in one step:
Section
Subsections
Page
I
04
40
70
10
Al to Decimal -- A1DEC
Decimal to Al -- DECAl
This convers ion will be needed if you have chosen
to use the decimal arithmetic system of CSP. The
Al field being converted was read by FORTRAN with
an Al format, or by the overlapped 110 routines.
Suppose a card contained 1968 in columns 1 through
4, and you read it with the overlapped I/O CALL
READ. It would be in Al format, in an array KOL,
one character per word:
If you are using decimal arithmetic, you must print
the answers either with a series of I1 formats, or
in Al format. The latter will be the case if you
desire any editing or are using the overlapped I/o
routines.
The DECAl subroutines will perform this conversion, thus operating in reverse fashion from
A1DEC.
A typical use would be
KOL
KOL
KOL
KOL
(1)
(2)
(3)
(4)
contains
conta ins
contains
contains
the
the
the
the
alphabetic
alphabetic
alphabetic
alphabetic
1b
9b
6b
8b
CALL DECAl (IWORK, 6,10, NER)
If you want to use this value in decimal arithmetic computations, it must be converted to decimal
format, one digit per word. To do this, you simply
code
CALL A1DEC (KOL, 1,4, NER)
and it will be converted, in place. Note that the Al
coding is replaced by the decimal coding. The NER
is an error parameter, and will be set to the pos ition
at which it last encountered an invalid character
(not 0 through 9 or a blank).
The exception to this is the last (rightmost)
character, which may contain an 11 or 12 punch,
indicating a sign. See the table below for allowable
punches;
Digit or
character
without a
zone punch
blank
0
1
2
3
4
5
6
'7
8
9
with an 11 punch
- (dash)
(- zero)
J
K
L
M
N
0
P
Q
R
with a 12 punch
&
(+ zero)
A
B
C
D
E
F
G
H
I
which will convert the 6th through the 10th items in
the IWORK array from decimal to Al format. The
NER error parameter is present but should be of
limited use, since the decimal arithmetic routip.es
should not leave any invalid digits in the field.
The rightmost digit is assumed to carry the sign
and, if negative, will be converted to the proper
character plus an 11 punch.
Section
70
Subsections
Page
I
05
40
10
Al to A2 -- PACK
A2 to AI.-- UNPAC
This conversion is very desirable if you wish to
store alphabetic data on the disk. For input, output,
and editing, your data must be in Al format, however, A2 format will pack twice as much data in an
equivalent number of words.
The PACK subroutine gives you the ability to convert from Al to A2 format. For example, suppose
the array IUNPK contains 123bGO:
To convert A2 data back to AI, the UNPAC subroutine may be used. A typical call to UNPAC would
be
IUNPK
IUNPK
IUNPK
IUNPK
IUNPK
IUNPK
(1)
(2)
(3)
(4)
(5)
(6)
contains
contains
contains
contains
contains
contains
an
an
an
an
an
an
alphabetic
alphabetic
alphabetic
alphabetic
slphabetic
alphabetic
1
2
3
blank
G
0
Now suppose we say
CALL PACK (IUNPK, 1,6, IPAKD, 1)
The data is packed and moved from IUNPK to IPAKD:
IPAKD (1) contains an alphabetic 1 and 2
IPAKD (2) contains an alphabetic 3 and blank
IPAKD (3) contains an alphabetic G and 0
The IUNPK array remains unchanged. An even number of characters will be packed. Therefore, the
Al field should contain an even number of characters;-otherwise, the last character in the IPAKD array
will be meaningless.
CALL UNPAC (IPAKD, 1,3, IUNPK, 1)
which would unpack the I23bGO packed in the previous example.
Section
70
Subsections
40
I
10
Page
06
Other Code Conversions
As Figure 70.23 shows, there are other code conversions that you may require. However, since
they are unusual and can be performed as a combination of several other steps, they will not be
discussed in detail.
Section
70
Other Character Handling Techniques
Editing Output--EDIT
Most commercial applications are strongly oriented
toward the format and appearance of the output results, as opposed to the technical job, where all
you want is the answer. For example:
• Dollar amounts should have commas, dollar
signs, and so on.
• Invoices should show a CR symbol after negative values.
• Balance sheets should have a minus sign following a negative item.
• Punched card output should have leading zeros,
so that the cards may be handled properly with a
mechanical sorter.
The EDIT subroutine enables you to do all these
formatting tasks. Its use requires two fields,
stored in Al format in integer arrays:
1. The source field or the field which will be
edited
2. The edit mask, a field which you have coded
to indicate how you want the edited output to appear.
A typical call to the EDIT subroutine is
CALL EDIT (KSOUR, 1, 10, MASK, 1, 13)
where the source field consists of items 1-10 in the
KSOURarray, and the mask consists of items 1-13 in
the MASK array. After editing, the MASK field is
replaced by the edited source field; if you wish to
use it again, therefore, you must save it somewhere else. Usually, the mask will be moved into
the output area, and the source field will be edited
into the output array. Thus the original mask is
not destroyed. For example:
CALL MOVE (MASK, 1,13, KOUT, 36)
CALL EDIT (KSOUR, 1,10, KOUT, 36,48)
Figure 70.24 is a worksheet that you may use
for setting up an edit mask. The principles involved are shown best by examples (see Figures
70.25-70.30).
Subsections
Page
I
01
40
20
Moving Data Fields --MOVE
Often it becomes necessary to move the data in one
array into another array--especially if you are
using CSP. The MOVE subroutine has been included in CSP to facilitate such operations. Its use
is quite simple, since it does no more than move
. data from one place to another. For example:
CALL MOVE (IFROM, 6,8, ITO, 14)
will move
IFROM (6) to ITO (14)
IFROM (7) to ITO (15)
IFROM (8) to ITO (16)
leaving the IFROM array undisturbed.
Note that the ending position in the ITO array is
not supplied -as. one of the parameters.
The format of the data items is not affected.
They may be AI, A2, decimal, or integer (but not
real).
Section
70
Subsections
Page
I
02
40
20
EDIT WORKSHEET
PROGRAM
DATE
PROGRAMMER
COMMENTS:
STEP 1.
FILL IN LINE a, SHOWING THE LARGEST POSSIBLE SOURCE FIELD, ANDWHAT YOU WANT IT TO LOOK LIKE AFTER EDITING.
HINT: PUT POSITION 10F THE SOURCE FIELD IN POSITION~ OF THE MASK, AND SO ON, LEFT TO RIGHT.
STEP 2.
IF YOU HAVE INSERTED ANY SPECIAL CHARACTERS INTO THE EDITED OUTPUT, PUT THEM IN THE EDIT MASK IN THE SAME
POSITION IN WHICH THEY APPEAR.
NOTE:
THIS DOES NOT APPLY TO *'5 (ASTERISKS), b's (BLANKS), OR $'s (DOLLAR SIGNS). DO NOT PLACE THEM IN
THE EDIT MASK YET.
NOTE:
ALLOWABLE SPECIAL CHARACTERS ARE A THRU Z, 1 THRU 9, AND /,. +
= etc.
FILL IN LINE b,SHOWING HOW YOU WANT ZERO TO APPEAR IN YOUR EDITED OUTPUT.
STEP 3.
STEP 4.
WHAT DID YOU DO WITH LEADING ZEROS? (YOU MAY ONLY CHOOSE ONE OPTION)
a)
LEFT THEM AS ZEROS? THEN DO NOTHING TO THE MASK.
b)
REPLACED THEM WITH ASTERISKS? IF SO, NOTE THE RIGHTMOST ASTERISK AND PUT AN ASTERISK IN THE MASK IN THE SAME
POSITION.
c)
REPLACED THEM WITH BLANKS? IF SO NOTE THE RIGHTMOST BLANK AND PUT A ZERO IN THE MASK IN THE SAME POSITION.
d)
REPLACED THEM WITH A STRING OF BLANKS AND A DOLLAR SIGN? (FOR EXAMPLE bbbb$). IF SO, NOTE THE POSITION OF THE
DOLLAR SIGN AND PUT A DOLLAR SIGN IN THAT POSITION IN THE MASK.
STEP 5.
FILL IN LINE c, SHOWING A TYPICAL NEGATIVE FIELD, AND HOW YOU WANT IT TO APPEAR.
STEP 6.
WHAT DO YOU WANT DONE WITH A NEGATIVE FIELD INDICATOR?
CHOOSE ONE.
a)
NOTHING, FIELD WILL NEVER BE NEGATiVE ••••••••.......••..••••..•. DO NOTHING.
b)
LETTERS 'CR' AFTER THE FIELD - •••••• ; •••••••••••••••••••••••••••••.• PUT A 'CR' IN THE MASK TO THE RIGHT OF
THE FIELD.
c)
MINUS SIGN IN ITS OWN COLUMN, AFTER THE FIELD •••••..•••.••......• PUT A MINUS SIGN IN THE POSITION RIGHT
--AFTER THE FIELD.
d)
11·PUNCH OVER ONE OF THE CHARACTERS ••.•••••••....••••••.•.....• SAME AS OPTION C, THEN USE NZONE SUBROUTINE
-/
TO MOVE ZONE PUNCH TO THE DESIRED POSITION'
"CERTAIN ZONE PUNCHES (11, 0 AND
12,0) CANNOT BE HANDLED BY
CAUTION:
CALL NZONE (MASK,ct, 5, NOLDZ)
MOVE ZONE FROM HERE TO HER?,
FORTRAN I/O. IF THESE PUNCHES
WI LL OCCUR, YOU MUST USE CSP I/O."
CALL NZONE (MASK,D, NOLDZ, JUNK)
STEP 7.
HOW MANY CHARACTERS WERE IN THE FIRST SOURCE FIELD?"'8 a
HOW MANY BLANKS REMAIN IN THE MASK?...................
CAUTION:
STEP 8.
b
a CAN BE EQUAL TO OR LESS THAN b, BUT CANNOT BE LARGER!
DON'T FORGET; THE SOURCE FIELD MUST BE IN A1 FORMAT, WITH THE SIGN OVER THE RIGHTMOST CHARACTER.
SOURCE FIELD
1
2
3
4
5
6
7
8
DESIRED EDITED OUTPUT
9 10 11 12
1
2
3
4
5
6
7
8
9
10 11 12 13 14 15 16 17· 18
LINE a - LARGEST
LINE b - ZERO
b
b
CL-1--L-1_L-1-JL-1~L-1-JL-1-l-L_IN_E-C_-_T_Y-PI_C_A_L_N-EG--A_T_IV_E_ _~~~_+~~+_~_+~--+_~_+~-+_~_+~-+_+_~~
123456789101112131415161718
IMPLIED SIGN
Figure 70. 24.
REQUIRED EDIT MASK
-----1
c
Section
70
Subsection~
I
40
EDIT WORKSHEET
PROGRAM
DATE
PROGRAMMER
COMMENTS:
JIIONET/I!lY FIELD TO BE PUNCIiEi1 /N7"O C.QRLJ #Irll LE.t9L}/Nq ZEROS
DE..5/Rc~ BUT #0 CO#;f~:S OR .iJEC .or. f/ PI/NCII OVER RI(jHTNOST
/bN/TS) pO.5ITION IF Ncq.4TIJ/E.
STEP 1.
FILL IN LINE a, SHOWING THE LARGEST POSSIBLE SOURCE FIELD. AND WHAT YOU WANT IT TO LOOK LIKE AFTER EDITING.
HINT: PUT POSITION 10F THE SOURCE FIELD IN POSITION 1. OF THE MASK, AND SO ON. LE;FT TO RIGHT.
STEP 2.
IF YOU HAVE INSERTED ANY SPECIAL CHARACTERS INTO THE EDITED OUTPUT, PUT THEM IN THE EDIT MASK IN THE SAME
POSITION IN WHICH THEY APPEAR.
NOTE:
THIS DOES NOT APPLY TO *'5 (ASTERISKS), b's (BLANKS), OR $'5 (DOLLAR SIGNS). DO NOT PLACE THEM IN
THE EDIT MASK YET.
NOTE:
ALLOWABLE SPECIAL CHARACTERS ARE A THRU Z, 1 THRU 9, AND /,. +
= etc.
FILL IN LINE b,SHOWING HOW YOU WANT ZERO TO APPEAR IN YOUR EDITED OUTPUT.
STEP 3.
STEP 4.
WHAT DID YOU DO WITH LEADING ZEROS? (YOU MAY ONLY CHOOSE ONE OPTION)
a)
LEFT THEM AS ZEROS? THEN DO NOTHING TO THE MASK.
b)
REPLACED THEM WITH ASTERISKS? IF SO, NOTE THE RIGHTMOST ASTERISK AND PUT AN ASTERISK IN THE MASK IN THE SAME
POSITION.
c)
REPLACED THEM WITH BLANKS? IF SO NOTE THE RIGHTMOST BLANK AND PUT A ZERO IN THE MASK IN THE SAME POSITION.
d)
REPLACED THEM WITH A STRING OF BLANKS AND A DOLLAR SIGN? (FOR EXAMPLE bbbb$). IF SO, NOTE THE POSITION OF THE
DOLLAR SIGN AND PUT A DOLLAR SIGN IN THAT POSITION IN THE MASK.
STEP 5.
FILL IN LINE c, SHOWING A TYPICAL NEGATIVE FIELD, AND HOW YOU WANT IT TO APPEAR.
STEP 6.
WHAT DO YOU WANT DONE WITH A NEGATIVE FIELD INDICATOR?
CHOOSE ONE.
a)
NOTHING, FIELD WILL NEVER BE NEGATiVE ••••••••...•.•••••••.•••••• DO NOTHING.
b)
LETTERS 'CR' AFTER THE FIELD ••••.••••••••.••••••••••••••••••••••• PUT A 'CR' IN THE MASK TO THE RIGHT OF
THE FIELD.
c)
MINUS SIGN IN ITS OWN COLUMN, AFTER THE FiELD ••.•••••••••• , •••..• PUT A MINUS SIGN IN THE POSITION RIGHT
AFTER THE FIELD.
d)
11·PUNCH OVER ONE OF THE CHARACTERS •...•••••...•.••••••••.....• SAME ASOPTION C, THEN USE NZONE SUBROUTINE
-~ TO MOVE ZONE PUNCH TO THE DESIRED POSITION'
~
CAUTION:
"CERTAIN ZONE PUNCHES (11,0 AND
12,0) CANNOT BE HANDLED BY
CALL NZONE (MASK,y, 5, NOLDZ)
MOVE ZONE FROM HERE TO HER?,
FORTRAN I/O. IF THESE PUNCHES
WI LL OCCUR, YOU MUST USE CSP I/O."
CALL NZONE (MASK,D. NOLDZ, JUNK)
STEP 7.
HOW MANY CHARACTERS WERE IN THE FIRST SOURCE FIELD? ••
0
a
HOW MANY BLANKS REMAIN IN THE MASK? •••••••••.••••.•.•• ~ b
CAUTION:
STEP 8.
a CAN BE EQUAL TO OR LESS THAN b, BUT CANNOT BE LARGER!
DON'T FORGET; THE SOURCE FIELD MUST BE IN A1 FORMAT, WITH THE SIGN OVER THE RIGHTMOST CHARACTER.
SOURCE FIELD
1
2
3
4
5
6
7
8
DESIRED EDITED OUTPUT
9 10 11 12
a9999'99999
bOOOO'OOOOO
1
2
3
4
5
6
7
8
9
10 11 12 13 14 15 16 17 18
t-L_N_E_a_-_LA_R_G_E_ST__________~~~9~9~9~9~9~9~9~9~9~~~~t_~~~a
LINE b - ZERO
000000000
CL-1-1-1-J~~~~~~~~:L~:L-L_1-I-L-I-NE--C---T-Y-PI-C-A-L-N-EG-A-T-1-V-E----~~-+O:+O:+:04=0~.=04=~~~~~~~~_+_+_+_4~~--~
1
IMPLIED SIGN
Figure 70. 25.
REQUIRED EDIT MASK - - - - - -......r~l/;
2
3
4
5
6
7
8
9 101112131415161718
b 6 /; b " b b b b
b
c·
20
Page
03
Section
Peg~
Subsections
I
40
70
04
20
EDIT WORKSHEET
PROGRAM
PROGRAMMER
NOIVET"tl/?y F/E~~, N/Tfi FLO.-9T/N'q.
CoLU;tf# FOLtOtA//N(f).
COMMENTS:
-1,
DATE
/lNO /IIcv19T/Yt /No/cnTO/? (8-/N
STEP 1.
FILL IN LINE a, SHOWING THE LARGEST POSSIBLE SOURCE FIELD, AND WHAT YOU WANT IT TO LOOK LIKE AFTER EDITING.
HINT: PUT POSITION lOF THE SOURCE FIELD IN POSITlON~ OF THE MASK, AND SO ON, LEFT TO RIGHT.
STEP 2.
IF YOU HAVE INSERTED ANY SPECIAL CHARACTERS INTO'THE EDITED OUTPUT, PUT THEM IN THE EDIT MASK IN THE SAME
POSITION IN WHICH THEY APPEAR.
STEP 3.
NOTE:
THIS DOES NOT APPLY TO *'s (ASTERISKS), b's (BLANKS), OR $'s (DOLLAR SIGNS). DO NOT PLACE THEM IN
THE EDIT MASK YET.
NOTE:
ALLOWABLE SPECIAL CHARACTERS ARE A THRU Z, 1 THRU 9, AND /,' + = etc.
FI LL IN LINE b, SHOWI NG HOW YOU WANT ZERO TO APPEAR IN YOUR EDITED OUTPUT.
STEP 4.
WHAT DID YOU DO WITH LEADING ZEROS? (YOU MAY ONLY CHOOSE ONE OPTION)
a)
LEFT THEM AS ZEROS? THEN DO NOTHING TO THE MASK.
b)
REPLACED THEM WITH ASTERISKS? IF SO, NOTE THE RIGHTMOST ASTERISK AND PUT AN ASTERISK IN THE MASK IN THE SAME
POSITION.
c)
REPLACED THEM WITH BLANKS? IF SO NOTE THE RIGHTMOST BLANK AND PUT A ZERO IN THE MASK IN THE SAME POSITION.
d)
REPLACED THEM WITH A STRING OF BLANKS AND A DOLLAR SIGN? (FOR EXAMPLE bbbb$). I F SO, NOTE THE POSITION OF THE
DOLLAR SIGN AND PUT A DOLLAR SIGN IN THAT POSITION IN THE MASK.
STEP 5.
FILL IN LINE c,SHOWING A TYPICAL NEGATIVE FIELD, AND HOW YOU WANT IT TO APPEAR.
STEP 6.
WHAT DO YOU WANT DONE WITH A NEGATIVE FIELD INDICATOR?
CHOOSE ONE.
a)
NOTHING, FIELD WI LL NEVER BE NEGATiVE •.....••.......•........... DO NOTHING.
b)
LETTERS 'CR' AFTER THE FIELD ..................................... PUT A 'CR' IN THE MASK TO THE RIGHT OF
THE FIELD.
c)
MINUS SIGN IN ITS OWN COLUMN, AFTER THE FIELD .••.• : ..•.•..•.••... PUT A MINUS SIGN IN THE POSITION RIGHT
AFTER THE FIELD.
d)
11·PUNCH OVER ONE OF THE CHARACTERS •..............•..••.•...... SAME AS OPTION C, THEN USE NZONE SUBROUTINE
-~ TO MOVE ZONE PUNCH TO THE DESIRED POSITION'
CAUTION:
"CERTAIN ZONE PUNCHES (11, OAND
12,0) CANNOT BE HANDLED BY
CALL NZONE (MASK,9' 5, NOLDZ)
MOVE ZONE FROM HERE TO HER?,
FORTRAN I/O. IF THESE PUNCHES
WI LL OCCUR, YOU MUST USE CSP I/O."
CALL NZONE (MASK,D, NOLDZ, JUNK)
STEP 7.
HOW MANY CHARACTERS WERE IN THE FIRST SOURCE FIELD? ..
~
a
HOW MANY BLANKS REMAIN IN THE MASK? •••••••••..•••.•••. ~ b
CAUTION:
STEP 8.
a CAN BE EQUAL TO OR LESS THAN b, BUT CANNOT BE LARGER!
DON'T FORGET; THE SOURCE FIELD MUST BE IN A 1 FORMAT, WITH THE SIGN OVER THE RIGHTMOST CHARACTER.
SOURCE FIELD
1
a
2
3
4
5
6
7
8
DESIRED EDITED OUTPUT
9 10 11 12
9 9 9 9 99 9 9 99
b ()
00 0 00 00 0 0
I I , I
c
IMPLIEDSIGN~
Figure 70. 26.
1
1
LINE a - LARGEST
2
3
$ 9 9
4
I
7
5
6
9
99
8
)
9
10 11 12 13 14 15 16 17' 18
<)
9 9
lJ9
iO
0 0
b
I
c
LINE b - ZERO
LINE c- TYPICAL NEGATIVE
J
1
REQUIRED EDIT MASK
2
3
b bIJ
4
I
5
6
7
bhh
8
1
I I /
,-
9 10 11 12 13 14 1516 17 18
b
I
b • /J
h-
a
Section
70
Subsections
I
40
EDIT WORKSHEET
PROGRAM
DATE
PROGRAMMER
COMMENTS:
SOC/Rl. .5cCt./R/TY NO.
STEP 1.
FI LL IN LINE a, SHOWING THE LARGEST POSSIBLE SOURCE FIELD, AND WHAT YOU WANT IT TO LOOK LIKE AFTER EDITING.
HINT: PUT POSITION lOF THE SOURCE FIELD IN POSITION~ OF THE MASK, AND SO ON, LEFT TO RIGHT.
STEP 2.
IF YOU HAVE INSERTED ANY SPECIAL CHARACTERS INTO'THE EDITED OUTPUT, PUT THEM IN THE EDIT MASK IN THE SAME
POSITION IN WHICH THEY APPEAR.
NOTE:
THIS DOES NOT APPLY TO *'s (ASTERISKS), b's (BLANKS), OR $'s (DOLLAR SIGNS). DO NOT PLACE THEM IN
THE EDIT MASK YET.
NOTE:
ALLOWABLE SPECIAL CHARACTE RS ARE A THRU Z, 1 THRU 9, AND /, - + = etc.
STEP 3.
FI LL IN LINE b, SHOWING HOW YOU WANT ZERO TO APPEAR IN YOUR EDITED OUTPUT.
STEP 4.
WHAT DID YOU DOWITH LEADING ZEROS? (YOU MAY ONLY CHOOSE ONE OPTION)
a)
LEFT THEM AS ZEROS? THEN DO NOTHING TO THE MASK.
b)
REPLACED THEM WITH ASTERISKS? IF SO, NOTE THE RIGHTMOST ASTERISK AND PUT AN ASTERISK IN THE MASK IN THE SAME
POSITION.
c)
REPLACED THEM WITH BLANKS? IF SO NOTE THE RIGHTMOST BLANK AI\ID PUT A ZERO IN THE MASK IN THE SAME POSITION.
d)
REPLACED THEM WITH A STRING OF BLANKS AND A DOLLAR SIGN? (FOR EXAMPLE bbbb$l. IF SO, NOTE THE POSITION OF THE
DOLLAR SIGN AND PUT A DOLLAR SIGN IN THAT POSITION IN THE MASK.
STEP 5.
FILL IN LINE c,SHOWING A TYPICAL NEGATIVE FIELD. AND HOW YOU WANT IT TO APPEAR.
STEP 6.
WHAT DO YOU WANT DONE WITH A NEGATIVE FIELD INDICATOR?
CHOOSE ONE.
a)
NOTHING, FIELD WILL NEVER BE NEGATiVE ••••••.•...•••.•.•.•••....• DO NOTHING.
b)
LETTERS 'CR' AFTER THE FIELD .•••••••••••••••••••••••••••••••••••• PUT A 'CR' IN THE MASK TO THE RIGHT OF
THE FIELD.
c)
MINUS SIGN IN ITS OWN COLUMN,~ THE FIELD .••.•••.••..•..•.... PUT A MINUS SIGN IN THE POSITION RIGHT
AFTER THE FIELD.
d)
11-PUNCH OVER ONE OF THE CHARACTERS •..•.••.••..••••••••••••...• SAME AS OPTION C, THEN USE NZONE SUBROUTINE
-~ TO MOVE ZONE PUNCH TO THE DESIRED POSITION'
~
CAUTION:
"CERTAINZONEPUNCHES(ll,OAND
12,0) CANNOT BE HANDLED BY
CALL NZONE (MASK,ct, 5. NOLDZ)
MOVE ZONE FROM HERE TO HERE7
FORTRAN I/O. IF THESE PUNCHES
WILL OCCUR, YOU MUST USE CSP I/O."
JI
CALL NZONE (MASK,D. NOLDZ, JUNK)
STEP 7.
HOW MANY CHARACTERS WERE IN THE FIRST SOURCE FIELD? .•
HOW MANY BLANKS REMAIN IN THE MASK? ••••••••..••.•...•.
CAUTION:
STEP 8.
W
0
a
b
a CAN BE EQUAL TO OR LESS THAN b, BUT CANNOT BE LARGER!
DON'T FORGET; THE SOURCE FIELD MUST BE IN A1 FORMAT, WITH THE SIGN OVER THE RIGHTMOST CHARACTER.
SOURCE FIELD
1
a
/
2
3
I I
4
5
6
7
8
DESIRED EDITED OUTPUT
9 10 11 12
223 3 3 3
1
LINE a - LARGEST
8
10 11 12 13 14 15 16 17' 18
3
4
5
I
I
I
- 2 2 - 3 .3 33
6
7
9
2
LINE b - ZERO
b
b
LINE c- TYPICAL NEGATIVE
cLL~~LL~~LLr-------------'~+4~~+4~~++~~~
1
IMPLIED SIGN
Figure 70. 27.
REQUIRED EDIT MASK
a
-----1
I
2
3
4
h bb
5
6
7
- "b
8
9 10 11 12 13 14 1516 17 18
- b
bo
h
c
20
Page
05
Section
Subsections
Page
I
06
70
40
20
EDIT WORKSHEET
PROGRAM
DATE
PROGRAMMER
L)/iTc
COMMENTS:
STEP 1.
FILL IN LINE a, SHOWING THE LARGEST POSSIBLE SOURCE FIELD, AND WHAT YOU WANT IT TO LOOK LIKE AFTER EDITING.
HINT: PUT POSITION 10F THE SOURCE FIELD IN POSITION 1 OF THE MASK, AND SO ON, LEFT TO RIGHT.
STEP 2.
IF YOU HAVE INSERTED ANY SPECIAL CHARACTERS INTO'THE EDITED OUTPUT, PUT THEM IN THE EDIT MASK IN THE SAME
POSITION IN WHICH THEY APPEAR.
STEP 3.
NOTE:
THIS DOES NOT APPLY TO *'s (ASTERISKS), b's (BLANKS), OR $'s (DOLLAR SIGNS). DO NOT PLACE THEM IN
THE EDIT MASK YET.
NOTE:
ALLOWABLE SPECIAL CHARACTERS ARE A THRU Z, 1 THRU 9, AND /,. + = etc.
FILL IN LINE b,SHOWING HOW YOU WANT ZERO TO APPEAR IN YOUR EDITED OUTPUT.
STEP 4.
WHAT DID YOU DO WITH LEADING ZEROS? (YOU MAY ONLY CHOOSE ONE OPTION)
a)
LEFT THEM AS ZEROS? THEN DO NOTHING TO THE MASK.
b)
REPLACED THEM WITH ASTERISKS? IF SO, NOTE THE RIGHTMOST ASTERISK AND PUT AN ASTERISK IN THE MASK IN THE SAME
POSITION.
c)
REPLACED THEM WITH BLANKS? IF SO NOTE THE RIGHTMOST BLANK AND PUT A ZERO IN THE MASK IN THE SAME POSITION.
d)
REPLACED THEM WITH A STRING OF BLANKS AND A DOLLAR SIGN? (FOR EXAMPLE bbbb$). IF SO, NOTE THE POSITION OF THE
DOLLAR SIGN AND PUT A DOLLAR SIGN IN THAT POSITION IN THE MASK.
STEP 5.
FILL IN LINE c, SHOWING A TYPICAL NEGATIVE FIELD, AND HOW YOU WANT IT TO APPEAR.
STEP 6.
WHAT DO YOU WANT DONE WITH A NEGATIVE FIELD INDICATOR?
CHOOSE ONE.
a)
NOTHING, FIELD WILL NEVER BE NEGATiVE •.••••••....••••••.••••...• DO NOTHING.
b)
LETTERS 'CR' AFTER THE FIELD ••••••••••••••••••••••••••••••••••••• PUT A 'CR' IN THE MASK TO THE RIGHT OF
THE FIELD.
c)
MINUS SIGN IN ITS OWN COLUMN, AFTER THE FIELD •••••...••...•.••... PUT A MINUS SIGN IN THE POSITION RIGHT
AFTER THE FIELD.
d)
11·PUNCH OVER ONE OF THE CHARACTERS •.•....•••....••••••••.....• SAME AS OPTION C, THEN USE NZONE SUBROUTINE
-~ TO MOVE ZONE PUNCH TO THE DESIRED POSITION'
~
CAUTION:
"CERTAIN ZONE PUNCHES (11,0 AND
12,0) CANNOT BE HANDLED BY
CALL NZONE (MASK,c;J. 5, NOLDZ)
MOVE ZONE FROM HERE TO HER7
FORTRAN I/O. IF THESE PUNCHES
WILL OCCUR, YOU MUST USE CSP I/O."
CALL NZONE (MASK,D, NOLDZ, JUNK)
STEP 7.
HOW MANY CHARACTERS WERE IN THE FIRST SOURCE FIELD? •.
W
a
[II
HOW MANY BLANKS REMAIN IN THE MASK? ••••••.•.........•.
CAUTION:
STEP 8.
b
a CAN BE EQUAL TO OR LESS THAN b, BUT CANNOT BE LARGER!
DON'T FORGET; THE SOURCE FIELD MUST BE IN A1 FORMAT, WITH THE SIGN OVER THE RIGHTMOST CHARACTER.
SOURCE FIELD
1
2
3
4
5
6
7
8
DESIRED EDITED OUTPUT
9 10 11 12
1
LINE a - LARGEST
b
I 2
Figure 70. 28.
3
I
4
5
0
!I! (;,1
6
7
8
9
10 11 12 13 14 15 16 17 18
a
LINE b - ZERO
b
LINE c- TYPICAL NEGATIVE
c
1
IMPLIED SIGN
2
REQUIRED EDIT MASK
2
3
4
5
6
7
8
-----1
·b b /b b /II})
9 10 11 12 13 14 15 16 17 18
Section
Subsections
Page
I
07
40
70
EDIT WORKSHEET
PROGRAM
DATE
PROGRAMMER
Or} TE
COMMENTS:
STEP 1.
FILL IN LINE a, SHOWING THE LARGEST POSSIBLE SOURCE FIELD, AND WHAT YOU WANT IT TO LOOK LIKE AFTER EDITING.
HINT: PUT POSITION 10F THE SOURCE FIELD IN POSITIONl OF THE MASK, AND SO ON, LEFT TO RIGHT.
STEP 2.
IF YOU HAVE INSERTED ANY SPECIAL CHARACTERS INTO'THE EDITED OUTPUT, PUT THEM IN THE EDIT MASK IN THE SAME
POSITION IN WHICH THEY APPEAR.
STEP 3.
NOTE:
THIS DOES NOT APPLY TO *'s (ASTERISKS), b's (BLANKS), OR $'s (DOLLAR SIGNS). DO NOT PLACE THEM IN
THE EDIT MASK YET.
NOTE:
ALLOWABLE SPECIAL CHARACTERS ARE A THRU Z, 1 THRU 9, AND /,' + = etc.
FILL IN LINE b, SHOWING HOW YOU WANT ZERO TO APPEAR IN YOUR EDITED OUTPUT.
STEP 4.
WHAT DID YOU DO WITH LEADING ZEROS? (YOU MAY ONLY CHOOSE ONE OPTION)
a)
LEFT THEM AS ZEROS? THEN DO NOTHING TO THE MASK.
b)
REPLACED THEM WITH ASTERISKS? IF SO, NOTE THE RIGHTMOST ASTERISK AND PUT AN ASTERISK IN THE MASK IN THE SAME
POSITION.
c)
REPLACED THEM WITH ~ IF SO NOTE THE RIGHTMOST BLANK AND PUT A ZERO IN THE MASK IN THE SAME POSITION.
d)
REPLACED THEM WITH A STRING OF BLANKS AND A DOLLAR SIGN? (FOR EXAMPLE bbbb$l. IF SO, NOTE THE POSITION OF THE
DOLLAR SIGN AND PUT A DOLLAR SIGN IN THAT POSITION IN THE MASK.
STEP 5.
FILL IN LINE c, SHOWING A TYPICAL NEGATIVE FIELD, AND HOW YOU WANT IT TO APPEAR.
STEP 6.
WHAT DO YOU WANT DONE WITH A NEGATIVE FIELD INDICATOR?
OR
CHOOSE ONE.
a)
NOTHING, FIELD WILL NEVER BE NEGATiVE •.•••••••...••••....•.•..•. DO NOTHING.
b)
LETTERS 'CR' AFTER THE FIELD ••.••••••••••.••••••••••••••••••••••• PUT A 'CR' IN THE MASK TO THE RIGHT OF
THE FIELD.
c)
MINUS SIGN IN ITS OWN COLUMN, AFTER THE FIELD ••.••••••.•••..••... PUT A MINUS SIGN IN THE POSITION RIGHT
AFTER THE FIELD.
d)
11·PUNCH OVER ONE OF THE CHARACTERS •••...•..•..•••••.••......•• SAME AS OPTION C, THEN USE NZONE SUBROUTINE
~
r--------------------.......,
~
TO MOVE ZONE PUNCH TO THE DESIRED POSITION'
CAUTION:
"CERTAIN ZONE PUNCHES (11, OAND
12,0) CANNOT BE HANDLED BY
CALL NZONE (MASK,9, 5, NOLDZ)
MOVE ZONE FROM HERE TO HERE7
,
CALL NZONE (MASK,D, NOLDZ, JUNK)
STEP 7.
FORTRAN I/O. IF THESE PUNCHES
WILL OCCUR, YOU MUST USE CSP I/O."
HOW MANY CHARACTERS WERE IN THE FIRST SOURCE FIELD? ••
0
0
HOW MANY BLANKS REMAIN IN THE MASK? ••••••••........•••
CAUTION:
STEP 8.
a
b
a CAN BE EQUAL TO OR LESS THAN b, BUT CANNOT BE LARGER!
DON'T FORGET; THE SOURCE FIELD MUST BE IN A 1 FORMAT, WITH THE SIGN OVER THE RIGHTMOST CHARACTER,
DESIRED EDITED OUTPUT
1
2
3
4
5
6
7
8
9 10 11 12
1
LINE a - LARGEST
b
2
3
4
H 0
:::
/ 2
5
6
7
8
9
/)/1 y'
I
10 11 12 13 14 15 16 17 18
:: 0 to
I
y~
=II
~
7
LINE b - ZERO
b
LINE c- TYPICAL NEGATIVE
c
cLL~~LL~~-Lr_------------~+4~~++~~++~~~
1
IMPLIED SIGN
Figure 70.29.
a
REQUIRED EDIT MASK
----_1.,4.f
2
3
()
;::iJ b
4
5
6
I
7
IJ
8
9 10 11 12 1314 15 16 17 18
A y'
:: " b
,
y K
::.~
b
20
Section
Subsections
Page
I
08
70
40
20
EDIT WORKSHEET
PROGRAM
DATE
PROGRAMMER
NOAl£T4I?Y FIELD, #/T# c/( SYMBOL. J LE4/)INt; f
COMMENTS:
STEP 1.
FILL IN LINE a, SHOWING THE LARGEST POSSIBLE SOURCE FIELD, AND WHAT YOU WANT IT TO LOOK LIKE AFTER EDITING.
HINT: PUT POSITION 10F THE SOURCE FIELD IN POSITION 1 OF THE MASK, AND SO ON, L~FT TO RIGHT.
STEP 2.
IF YOU HAVE INSERTED ANY SPECIAL CHARACTERS INTO THE EDITED OUTPUT, PUT THEM IN THE EDIT MASK IN THE SAME
POSITION IN WHICH THEY APPEAR.
STEP 3.
NOTE:
THIS DOES NOT APPLY TO
THE EDIT MASK YET.
NOTE:
ALLOWABLE SPECIAL CHARACTERS ARE A THRU Z, 1 THRU 9, AND I, - +
"5
(ASTERISKS), b's (BLANKS), OR $'s (DOLLAR SIGNS). DO NOT PLACE THEM IN
= etc.
FILL IN LINE b,SHOWING HOW YOU WANT ZERO TO APPEAR IN YOUR EDITED OUTPUT.
STEP 4.
WHAT DID YOU DO WITH LEADING ZEROS? (YOU MAY ONLY CHOOSE ONE OPTION)
a)
LEFT THEM AS ZEROS? THEN DO NOTHING TO THE MASK.
b)
REPLACED THEM WITH ASTERISKS? IF SO, NOTE THE RIGHTMOST ASTERISK AND PUT AN ASTERISK IN THE MASK IN THE SAME
POSITION.
c)
REPLACED THEM WITH BLANKS? IF SO NOTE THE RIGHTMOST BLANK AND PUT A ZERO IN THE MASK IN THE SAME POSITION.
d)
REPLACED THEM WITH A STRING OF BLANKS AND A DOLLAR SIGN? (FOR EXAMPLE bbbb$). IF SO, NOTE THE POSITION OF THE
DOLLAR SIGN AND PUT A DOLLAR SIGN IN THAT POSITION IN THE MASK.
STEP 5.
FILL IN LINE c, SHOWING A TYPICAL NEGATIVE FIELD, AND HOW YOU WANT IT TO APPEAR.
STEP 6.
WHAT DO YOU WANT DONE WITH A NEGATIVE FIELD INDICATOR?
CHOOSE ONE.
a)
NOTHING, FIELD WILL NEVER BE NEGATiVE •••••••••....•••••.•••••.•. DO NOTHING.
b)
LETTERS 'CR' AFTER THE FIELD ••••••••••••••••••.•••••••••••••••••• PUT A 'CR' IN THE MASK TO THE RIGHT OF
THE FIELD.
c)
MINUS SIGN IN ITS OWN COLUMN, AFTER THE FIELD •••••...•••.••.•...• PUT A MINUS SIGN IN THE POSITION RIGHT
AFTER THE FIELD.
d)
11-PUNCH OVER ONE OF THE CHARACTERS •••.•.••......••••••••.•...• SAME AS OPTION C, THEN USE NZONE SUBROUTINE
-~TO MOVE ZONE PUNCH TO THE DESIRED POSITION'
~
CAUTION:
"CERTAIN ZONE PUNCHES (11, OAND
12,0) CANNOT BE HANDLED BY
CALL NZONE (MASK,9, 5, NOLDZ)
MOVE ZONE FROM HERE TO HER?,
FORTRAN I/O. IF THESE PUNCHES
WILL OCCUR, YOU MUST USE CSP I/O."
CALL NZONE (MASK,D, NOLDZ, JUNK)
STEP 7.
HOW MANY CHARACTERS WERE IN THE FIRST SOURCE FIELD? .•
HOW MANY BLANKS REMAIN IN THE MASK? ••••••••••.••••••..
CAUTION:
STEP 8.
~
@]
a
b
a CAN BE EQUAL TO OR LESS THAN b, BUT CANNOT BE LARGER!
DON'T FORGET; THE SOURCE FIELD MUST BE IN Al FORMAT, WITH THE SIGN OVER THE RIGHTMOST CHARACTER.
SOURCE FIELD
1
2
3
4
5
6
7
8
9 9 9 999 9 9
booaooooo
a
c
/
2 .3
4-
DESIRED EDITED OUTPUT
9 10 11 12
1
LINE a - LARGEST
LINE c- TYPICAL NEGATIVE
Figure 70. 30.
REQUIRED EDIT MASK
4
5
6
7
8
9 10 11 12 13 14 15 16 17 18
'3 ~
a
* 1f-* * ** *0
~* it ~* ** z
OD
b
.3 4C Il
c
1
IMPLIED SIGN
3
, 999
If.
LINE b - ZERO
2
999
2
3
4
5
------1 b 6/J 6 ,
6
7
8
b-1f b
9 10 11 12 1314 15 16 17 18
6
"
e
~
Section
70
Subsections
40
I
20
Page
09
Filling a Field with a Specific Character--FILL
Comparing Alphabetic Fields--NCOMP
If your program requires that you create long strings
of the same digit or character, the FILL subroutine
may be used. The statement
The requirements for alphabetic comparisons
can usually be broken into two main classifications:
1. Comparing to determine whether there is a
match/no match condition.
2. Comparing to determine whether one field is
higher than, lower than or equal to another
field.
Because the first is quite a bit simpler than the
second, these two types of alphabetic compares will
be discussed separately.
CALL FILL (KAHHY, 10,36, IT)
will place the coding of IT in positions 10- 36 of the
array KAHHY. IT may be any integer between
+32767 and -32768.
In a standard FOHTHAN program, this is a
useful way to clear a set of totals to zero.
If you are using the decimal arithmetic routines,
this can also be used to clear a total field to zero.
When using the overlapped I/O routines, it is
often necessary to fill an area with blanks, dashes,
or some other character.
A table of the decimal equivalent of various
EBCDIC (AI) characters may be found in the CSP
manual. However, it is usually easier to obtain
their value indirectly with a DATA statement. For
example, to fill a printer output line with dashes,
you would place a DATA statement in the beginning
of your program:
DATA IDASH/' - '/
placing the dash character between the quotes or
apostrophes. Then the FILL statement
CALL FILL (lOUT, 1,120, IDASH)
would fill the lOUT array with the Al code for a
dash.
Section
70
Subsections
Page
I
10
40
20
Match/No Match Alpha Compare. This operation
is common to many commercial applications:
• An employee time card may contain a fourletter code describing what job he worked on,
and the program must look up a corresponding
rate.
• An inventory card may contain a two-letter
code indicating unit of measure--LB, GR, EA,
etc.
• The name field on eachinput card is compared
with the name field on the preceding card; if they
are not the same, branch to the "control break"
section of the program.
If the fields to be compared are one or two
characters long, they may be read into a single
integer variable and compared like any other
intergers. For example, if their names are ITHIS
and ITHAT, the statement:
If the fields are longer than two characters,
they should be read into integer arrays, in Al
format, and compared with the NCOMP function.
Using the previous example, suppose ITHIS and
ITHAT are arrays, each containing ten alphabetic
characters.
IF(NCOMP(ITHIS, 1, 10, ITHAT, 1»1,2,1
will work the same as the simple IF statement
shown earlier.
Don't try to compare alphabetic fields that have
been stored as real variables. Two six-character
fields, called THIS and THAT, may be read from
a card and moved about in core just like any other
real variables; however, they cannot be compared
validly. The statement
IF(ITHIS-ITHAT) 1,2,1
will branch to statement number 2 if they are identical, and statement number 1 if they are different.
The format (AI or A2) does not matter, except, of
course, that it must be the same for both.
IF(THIS-THAT)1, 2, 1
will not always branch to statement number 1 if
the two fields are different.
Section
70
High/Low/Equal Alpha Compare. Everything said
about the Match/No Match compare also applies
here, with two exceptions:
1. The fields to be compared should always be
in Al format.
2. The Al representation for a blank must be
changed if you want it to fall in the proper
collating sequence.
Figure 70. 31 shows the decimal representation of
various characters in Al format. Note that the
blank falls after the letters and numbers. If it is
left there, alphabetic compares will yield an ascending
sequence--for example:
WILLIAMSON
WILLIAMSbb
WILLIAMbbb
11
20
This can easily be corrected if blanks are
converted from 16448 to something less than
-16064, the letter A. In fact, you might as well
change it to -16448. With a DO loop, the input
record can be scanned for +16448s, and each one
found can be changed to -16448.
They need not be converted back to +16448 for
printed output, since any invalid character (such
as -16448) will be printed as a blank anyway. For
punched output, however, this will not be so, and
the -164488 should be changed back to +16448s.
A1
A1
Character
Character
Decimal
Equivalent
Decimal
Equivalent
A
-16064
S
-7616
B
-15808
T
-7360
. (period)
19264
C
-15552
U
-7104
<(less than)
19520
16448_
D
-15296
V
-6848
(
19776
E
-15040
W
-6592
+
20032
F
-14784
X
-6336
&
20544
G
-14528
't
-6080
$
23360
H
-14272
Z
-5824
"
23616
I
-14016
0
-4032
)
23872
J
-11968
1
-3776
-(minus)
24640
K
-11712
2
-3520
/
L
-11456
3
-3264
24896
27456
M
-11200
4
-3008
%
27712
N
-10944
5
-2752
#
31552
0
-10688
6
-2496
@
31808
P
-10432
7
-2240
, (apostrophe)
32064
Q
-10176
8
-1984
=
32320
R
-9920
9
-1728
Figure 70.31.
I
40
WILLIAMbbb
WILLIAMSbb
WILLIAMSON
A1
blank
Page
rather than the correct
Decimal
Equivalent
Character
Subsections
-
Note
position
of blank
Section
70
Subsections
Page
I
12
40
20
Working with Zone Punches -- NZONE
The top three rows of the data processing card are
commonly called the "zone" rows, and a punch in
one of them is called a zone punch. The top row is
called the 12 zone; the next, the 11 zone; and the
next (the 0 row), the 0 zone. (See Figure 7 O. 32. )
A digit overpunched with .a 12 zone punch is taken
to be positive; an 11 punch indicates negative. This
is quite reasonable, since an 11 punch alone is a
minus sign, and a 12 punch is an ampersand (&) or
plus sign (+), depending on the coding scheme and
cardpimch used. (While many people use the term
"X punch" instead of 11 punch, both mean the same. )
The 12 punch is rarely used, since it is easier
to have no zone punch for positive numbers.
The zone punch, when used to indicate the sign,
should be placed over the units (rightmost) position
of the field. For example, -1675 would be punched
with an 11 punch over the 5.
This practice will result in a card code equivalent to one of the letters J through R, or a negative
·zero. The table below shows the card code equivalents:
If the card containing the 1675 field were interpreted, or listed character for character, it would
appear as 167N, where the character N is equivalent to a 5 and an 11 punch.
In a few cases, zone punches may also be found
in card columns other than the low-order digits of
a numeric field. This is particularly true in installations that once had a unit record, or punched card,
system. In such a system, zone punches provided
an easy way to pack additional data into a punched
card.
One of the advantages of the CSP overlapped
I/O routines is that they allow the input and output
of fields with zone punches. This is normally quite
difficult with standard FORTRAN READs and
WRITEs, since the 11,0 (- zero) punch is not permitted.
. - - - - - - An 11-punch, X-punch, or minus sign
. . . - - - - A 12-punch, &, or plus sign
An N or a 5 with an 11-punch
':(
~l
I
These punches
11,0
Mean either this
Or this
-0
0
I
I
0000000000000000000000000000900000000000
1111 5 6 18 910111113111511111111212122232125161111213031313331353131313911
etc,
1111111111111111111111111111111111111111
11,1
-1
J
11,2
-2
K
33333333333333333333333333333333333333333
11,3
-3
L
4 4 4 4 4 4 4 4 4 4 4 • 4 4 4 4 4 4 4 4 4 4 4 44 4 4 4 4 4 4 44 4 4 44 44 4 44
11,4
-4
M
11,5
-5
N
7 7 7 7 7 7 1111'11 11 7 1 11 1 1 I 11111 1 1 I 11111 111 1111
11,6
-6
0
8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 I 8 8 8 8 8 8 8 8 8 8 8 8 18 88 8 8 8 I
11,7
-7
P
11,8
-8
Q
11,9
-9
R
2 2 2 2 2 2 2 2 2 Z 2 2 2 2 2 2 2 22 2 2 2 2 2 2 2 2 2 2 2 22 2 2 2 22 2 2 2 2
555555515555555555555555555555555555555555
6666666666666666666666&666666666666666&6&6
ggJ99999999~9999999992999999999999999999
I 2 3 4
Figure 70.32.
~
6 1 , 9 10 11 12 13 14 IS 16 11 11 II 20 21 22 23 24
2~.
25 21 21 21 31 31 32 13 S. :t5 l5 11 1I 31 41
Section
70
The NZ ONE Subroutine. The NZ ONE subroutine
has been included in CSP to allow you to interrogate
a zone punch, obtaining a code that indicates its
status, and to modify a zone punch. If you wished
to operate on the 18th character in the INOUT array,
the call to NZ ONE would be
CALL NZONE (INOUT, 18, NEWZ, NOLDZ)
NOLDZ will be returned to you, indicating what
zone punch was present:
NOLDZ
Zone Punch
Character
1
12
A--I
2
11
J--R
3
0
S--Z
4
more than 4
none
0--9
special character
Note that an NOLDZ of 4 or more does not tell
you what zone punch was present, but only that
INOUT (18) contains a special character.
Subsections
Page
I
13
40
20
You supply the NEWZ parameter, indicating to
the subroutine what you want done with the old zone
punch:
NEWZ
Action Taken
1
Make the zone a 12
2
Make the zone an 11
3
Make the zone a 0
4
Remove the zone
more than 4
Let the zone alone
Section
70
Subsections
Page
I
01
50
01
FOHTHAN COHE SAVING TIPS
General
The way in which you code your FOH THAN programs
will have a considerable effect on their size. The
difference between efficient and inefficient coding
might be as much as several hundred words. This
may mean the difference between a program that
fits in core and one that doesn't, or the difference
between one that requires many time-consuming
overlays and one that requires none.
In general, the larger a program, the more
slowly it will run--not because it does more, but
because of the overlays(SOCALs, LOCALs and
LINKs) required to fit it into core. When writing
your programs, therefore, you should make every
effort to keep them small. One way to do this is
to know which FORTRAN techniques save core
storage, and which ones consume it excessively.
A better way is to design programs that do just one
job, rather than many. (Subsection 25.30.20 contains a discussion of the advantages of modular
programming.) Still another way is to use efficient
overlays (see Section 65).
The core storage requirements for any particular
program can be split into three major elements:
• The object code generated by the compiler
• The subroutines, which actually do the
work
• The data area, where all variables and
constants are stored
You should realize that very little actual work
is done "in line" by your program; when the end-ofcompilation summary says your program size is
1000 words, it means that your program has been
translated into 1000 words of branches or linkages
to subroutines, plus some housekeeping to prepare
the linkages. The exception to this statement is
integer arithmetic, which is done in line, without
subroutines. However, all subscript calculation,
real arithmetic, and input/output is accomplished
by subroutines.
Some of the core saving tips in this section are
directed toward reducing the subroutine requirements, while others will reduce the amount of
in-line coding.
If you modify an existing program, incorporating
some of these tips, don't expect to find all the savings reflected in the end-of-compilation summary.
Check the list of required subroutines; you may
have eliminated some of them.
Section
70
Reducing Program Size
Use the DATA Statement
The DATA statement is a recent addition to 1130
FORTRAN, having been incorporated into Version 2
of the 1130 Monitor System. Basically, it is used
to create constants at the time the program is compiled, rather than each time the program is executed. It saves some time, but this should not be
enough to notice in the overall run time of most
programs. Much more important, the DATA statement saves core storage.
It is a nonexecutable statement, like the TYPE,
DIMENSION, EQUIVALENCE, etc., statements,
and requires no core storage. It provides only a
starting value for variables. For exact rules concerning the use of the DAT A statement, see the 1130
FORTRAN manual; in this section you will see some
examples of its use.
• Case 1: Initialize Tables at the Beginning of
a Program
Almost every program begins with statements
such as
DO 16 J = 1,50
TOT(J) = 0.0
16 SUBT(J) = 0.0
This coding, which requires about 27 words of
storage, can be replaced with
DATA TOT/50*0. 0/, SUBT/50*0.0/
which requires no storage.
Let us stress three facts at this point:
1. You still require two 50-position arrays.
The DATA statement merely takes care of initializing their values.
2. If you say TOT (1) = 1. 5 later in the program,
this will be done, and TOT (1) will no longer be O. O.
3. If you want to clear out these tables again
during the execution of the program, you must use
the conventional DO loop. You cannot GO TO or
reexecute the DATA statement, since it is a nonexecutable statement and, in fact, no longer exists
once the program is loaded.
Subsections
50
I
10
Page
01
• Case 2: Initialize Indicators, etc.
The program PAY04, listed in Subsection
70.50.30, contains the following FORTRAN
statements:
T = O.
IERR = 0
ICOL = 1
INI = 1
XOT:::: O.
XBN = O.
XSP = O.
XREG = O.
IPAGE = 0
LINE = 50
which require 40 words of object coding. They may
be replaced by
DATA T/O./, IERR/O/, ICOL/l/, etc., etc.
• Case 3: Setting a Variable to Different Values
Again inspecting the same program, PAY04, we
find
GO TO (76,77,78,79,80,81), NOPLT
76ILST=250
GO TO 83
77ILST=90
GO TO 83
78ILST=200
GO TO 83
79ILST=50
GO TO 83
80ILST=150
GO TO 83
81ILST=30
83 continue
which requires 44 words of object coding. It may be
replaced by a combination of
DIMENSION IFACT (6)
DATA IFACT/250, 90, 200, 50, 150, 30/
and the statement (using eight words)
ILST = IFACT(NOPLT)
PlaCing the six constants in the IFACT array adds
no core requirements, since they were in core
before, as INTEGER CONSTANTS (see listing at
end of compilation).
Section
70
Subsections
Page
I
02
50
10
• Case 4: Creating Alphabetic Masks for the
EDIT Subroutine
If you want to print or punch you.r FOR TRAN results with commas, floating dollar signs, etc., you
are probably using the EDIT subroutine found in CSP.
This subroutine requires an Edit mask, which may
look like
bb, bb$. bbCR
There are two ways to obtain this mask, which must
be in Al format in an eleven-word integer array
(call it MASK). You can read it off a card, or you
can look up the decimal equivalents of the EBCDIC
codes, and set each one equal to the desired
character:
MASK (1) =
16448 blank
MASK (2) =
16448 blank
MASK (3) =
27456 comma
MASK (4) =
16448 blank
MASK (5) =
16448 blank
MASK (6) =
23360 dollar sign
MASK (7) =
19264 period
MASK (8) =
16448 blank
MASK (9) =
16448 blank
MASK (10) = -15552 letter C
MASK (11) = -9920 letter R
The DATA statement allows you to eliminate this
sixty-six-word series of commands, replacing it with
DATA MASK/'b', 'b',',', 'b', 'b', '$', '.', 'b', 'b', 'C', 'R'/
where b indicates a blank.
Keep FORMAT Statements Compact
1130 FORTRAN includes a very flexible repertoire
of FORMAT codes, and often gives you several
different ways to achieve the same results. For
example, you can specify either (F6.2, F6.2, F6.2)
or (3F6. 2). With alphabetic heading data, there are
more options. To type a line which reads
bbbbbbbbbTOT AL
you can use as FORMAT statements the following:
a. FORMAT (14HbbbbbbbbbTOT AL)
b. FORMAT('bbbbbbbbbTOTAL')
c. FORMAT(9X, 'TOTAL')
d. FORMAT(9X,5HTOTAL)
etc.
If you suspected that some options used more core
storage than others, you would be correct. Options
a and b force the compiler to allocate nine words for
this FORMAT STATEMENT; options c and d only
require six words.
The main difference between the two styles is the
manner in which you have generated nine blank
columns -- 9X or 'bbbbbbbbb'. The 9X is coded and
compressed into one word; the 'bbbbbbbbb' requires
one word, plus a string of five words, each containing two alphabetic blanks.
The difference does not appear to be great, but
consider your typical commercial report writing
program with its many long FORMAT statements.
The difference between the best (smallest core
requirement) and what the programmer has actually
used may be substantial.
This topic is further complicated by the fact that
the X specification is best for large numbers of
spaces, while the literal or ' , specification is best
for small numbers. In summary, to get one or two
spaces, it is best to enclose blanks within quotes
(or use the H specification). To get three or more
spaces, use the X specification.
Section
70
Subsections
Page
I
03
50
10
Code Efficient I/O statements
Avoid Long Subroutine Argument Lists
The manner in which you code your I/O statements
can have a significant effect on the size of your
program. The FORTRAN compiler will generate a
certain fixed amount of coding for each READ or
WRITE:
3 words
READ
WRITE
4 words
plus a certain additional amount (average) for each
item in the I/O list:
variable -- e. g., AB or I
2 words
variable, constant subscript -e. g. , X(3)
4 words
variable, variable subscript -e. g., X(J)
5 words
array name
3 words
implied DO loop e. g., (X(N) , N=l, 6)
19 words
If you wish to WRITE a line containing eight real
variables, you may code
WRITE (3,XXX) A, B, C, D,E, F, G, H
and use 4 + (8 x 2)or 20 words. Or vou could
EQUIVALENCE each of the eight items to a variable
in the ANSWR array
EQUIVALENCE (A, ANSWR(l»
EQUIVALENCE (B,ANSWR(2»
etc.
and code
WRITE (3, XXX) ANSWR
which would require only 4 + (1 x 3) or 7 words.
You would not want to use
WRITE (3,XXX) (ANSWR(K),K=l, 8)
since that would require 23 words, more than the
original. In fact, the implied DO loop I/O format
should be avoided wherever possible. This can
usually be accomplished with the EQUIVALENCE
statement. For example, if you want to WRITE
the first six items of the eight-item ANSWR array,
you would code
DIMENSION ANSWR(8), ANS6(6)
EQUIVALENCE (ANS6(1), ANSWR(l»
The coding generated for CALLs to subroutines is
quite similar to that of READs and WRITEs -- an
initial CALL (two words) plus a certain number of
words for each argument:
Approximate
Type of Argument
Core Required
None
o words
Constant -- e. g. ,6
1 word
Unsubscribed Variable -- e. g., X or I
1 word
Array Name, -- e. g., IARRY
1 word
Variable with Constant Subscript -8 words
e. g. ,A(7)
Variable with Variable Subscript -e. g. ,A(N)
13 words
You can see that there is quite a difference' between
a. CALL SUB
2 words
b. CALL SUB (X, Y, Z)
5 words
c. CALL SUB (lARRY)
3 words
d. CALL SUB (A(l), A(2), A(3»
26 words
e. CALL SUB (A(I),A(J),A(K»
41 words
There are many ways to avoid those types of CALLs
that consume core storage.
Item d, CALL SUB (A(l), A(2), A(3», could be
replaced by
EQUIVALENCE (A(1),X)
EQUIVALENCE (A(2), Y)
EQUIVALENCE (A(3), Z)
WRITE (3, XXX) ANS6
saving 23-7 or 16 words.
and
CALL SUB (X, Y, Z)
or by
DIMENSION XA(3)
EQUIVALENCE (XA(1), A(1»
and
CALL SUB (XA)
or by placing the A array in COMMON and using
CALL SUB
with no arguments.
Item e, CALL SUB (A(I) , A(J), A(K», could be
replaced by
CALL SUB (A, I, J, K)
which would require a revised subroutine but would
save 41 -6 or 35 words. Or it could be replaced by
CALL SUB (I, J, K)
with the A array placed in COMMON.
Section
70
Subsections
50
I
10
Page
04
Avoid Arithmetic with Variables Having Constant
Subscripts
In the average arithmetic statement, a variable with
a constant subscript (TOTAL(10)) will require two
words more coding than an unsubscripted variable
(TOTDF). Such usage can always be avoided by an
EQUIVALENCE statement such as
EQUIVALENCE (TOTDF, TOTAL(10»
Then, rather than say
TOTAL(10) = TOTAL(10) + AMT
you would code
TOTDF = TaI'DF + AMT
and save two words.
In a large program, the saving can be considerable. Furthermore, it makes the program more
readable, since TOTDF can be a more descriptive
name than TOTAL(10).
The data can be referred to by either name:
• TOTDF when doing arithmetic
• TOTAL(10) when you want it subscripted -for example, when clearing an array of totals, when .
writing an array of totals on the disk, etc.
Section
70
Subsections
Page
I
01
50
20
Reducing Subroutine Requirements
SQRT vs **.5
Raising a Real Number to a Whole Power
To take the square root of a number, you have two
alternatives: the SQRT function or the 1/2 power
option (**.5). While both will give the same result,
the core storage required is quite different. The
SQRT routine is about 76 words in length; the "real
base to real exponent" routine, about 242 words.
The difference, about 166 words, is substantial.
Of course, if your program must use the "real
base to real exponent" routine (for example ~**A),
you need those routines anyway. If that is so, use
the **.5 option rather than SQRT; otherwise, you
will have both packages in core storage.
FORTRAN allows you two ways to do this. For
example, to square X, a real number, either X**2
or X**2. may be used. While the two look almost
identical, the first will use the "real base to integer
exponent" routines (about 82 words) and the second
will use the "real base to a real exponent" routines
(about 242 words).
In this case you should code X**2 and save about
160 words of core storage, unless, of course, your
program really requires a real·base to a real
exponent somewhere else.
A programmer will often use this form of arithmetic to obtain the various powers of ten -- for
example:
10**N
10**0 = 1
10**1 = 10
10**2 = 100
However, if this is the only way in which the
double asterisk is used in a particular program, it
will usually be more economical to code:
DATA TEN/I. ,10. ,100. ,1000. ,etc. /
and then use subscripting
'" TEN (N+1) .....
This will eliminate the 82-word subroutine.
Section
70
Subsections
50
I
20
Page
02
Don't Include Unneeded I/O Devices on *IOCS Card
In many installations, a stack of all-purpose *IOCS
cards is left on the card reader, or nearby, to save
the. trouble of punching a new card for every program. However, you should be aware that the card
*IOCS(CARD, DISK, TYPEWRITER, KEYBOARD,
1132 PRINTER)
will cause all those I/O routines to be added to your
program, whether you use the devices or not. The
size of the package to handle those devices listed
above is about 620 words for the disk, and 1780
words for the non-disk group. Because of the way
in which the SOCAL system operates, your program
may still fit in core, but with more overlays, thus
causing it to run more slowly.
It would be wiser to maintain a set of cards with
only one device per card
*IOCS(CARD)
*IOCS(1132 PRINTER)
*IOCS(DISK)
etc.
and use only those that are really needed. In this
way no unnecessary I/O packages will be included
with your program.
Remove FIND Statements If You Have SOCALs or
LOCALs
Even if you have included FIND statements in your
program, they will not be executed if SOCALs or
LOCALs are being used. The FIND subroutine
(SDFND), however, remains in core storage.
Therefore, if you know you are going to have
SOCALs or LOCALs, remove all FIND statements,
and you will save about 80 words of core storage,
plus three words for each statement.
Section
70
Remove the TRACE from Production-status
Programs
The trace features furnished in 1130 FORTRAN are
an invaluable aid in debugging. Most users, when
they compile their programs, include the *ARITHMETIC TRACE and *TRANSFER TRACE cards,
just in case something goes wrong. However, since
Subsections
Page
I
03
50
20
these features consume both core space and time,
they should be eliminated when no longer needed.
Core requirements are increased by about 140
words, and execution time is slowed down for each
equal (=) sign, IF statement, or computed GO TO
executed. This is true regardless of the status of
Sense Switch 15. In addition, the object coding
generated may be slightly greater.
Section
Subsections
70
60
I
Page
01
10
FORTRAN EXECUTION TIMES
Processing
It is possible to estimate the length of time it will
take to execute an arithmetic block of FOR TRAN
coding. Inspect your coding sheets, or program
Operation
GET
PUT
EDIT
MOVE
FILL
WHOLE
NCOMP
NZONE
ICOMP
NSIGN
ADD
SUB
MPY
DIV
Approximate* time in
Microseconds,** each execution
(time for standard precision
use in parentheses)
2250 + 2190C
3450 + 3090 C
630+
90S+ 180M
300+
45 C
300+
30 C
1400
250+
75 C
350
500 + 95 C
240
2160+ 216 L
2160+ 216 L
2400 + 120 P
4000 + 0(445 + 667 DIV)
A1DEC
DECA1
700+
180+
A1A3
A3A1
PACK
UNPAC
DPACK
DUNPK
470 + 1084 A
545 + 156 A
360+
63A
420 +
66 A
3920
3600
5400
5900
8900
10400
4400
8000
8100
SIN
COS
ATAN
SQRT
EXP
ALOG
TANH
54 A
117 A
(3000)
(3400)
(5300)
(4500)
(2000)
(5100)
(4300)
N
C
S
M
P
=
=
=
=
=
A
0
L
=
=
=
0
DIV
=
=
Operation
real =
integer
listings, and count the average number of times the
operations shown in Figure 70.33 will be executed.
Then use the times shown in Figure 70.33 to
estimate the total execution time.
Note that you must consider the probability of
execution, not just the number of appearances. If
a certain loop will be executed 15 times, on the
Approximate* time in
Microseconds,** each execution
(time for standard precision
use in parentheses)
300 (360)
22
=
440(460
12
490 (560)
12
790 (560)
30
2100 (800)
80
+real
+integer
-real
-integer
*real
*integer
/real
/integer
real**real
integer**integer
13300 (8000)
4700 (3800)
FLOAT
FIX
330
140
subscript (no variabl e)
25
subscript (one variable)
280
subscript (two variables)
390
subscript (three variables)
530
DO
IF (real)
I F (integer)
22 + 50 N
190 (210)
30
GO TO
GO TO (
), N
7
7
The number of times through the DO loop
Length of the field, in characters
Length of the source field
Length of the edit mask
Length of the multiplier field x length of the multiplicand field
(significant digits only - don't count leading zeros)
Length of the A 1 field
Length of the packed decimal (04) field
Length of the longer of the two fields (significant digits only don't count leading zeros)
Number of significant digits in the quotient (result) field
Number of significant digits in the divisor (denominator) field
* Most timings are approximate and are based on test runs of "typical" cases, using fields of "average" size,
magnitude, etc. Unusual cases may (or may not) differ significantly from the timings obtained from the
given equations. This is particularly true of the decimal arithmetic routines (ADD, SUB, MPY, DIV).
** Based on 3.6-microsecond CPU cycle speed. Multiply by 0.6 to obtain timings on 2.2-microsecond CPU.
Figure 70.33.
Section
70
average, every operation within it should be counted
15 times. If, in the other hand, a certain routine is
only executed half the time, it should be counted as
half an execution. To illustrate:
X=X+6
IF(X-77.)1, 2,1
1
Z=X*14.
GO TO 3
Z=X*16./W
2
3
CONTINUE
If you assume extended precision, and a probability of one-third for path 1 and two-thirds for
path 2, the estimated execution time is
Operation
+
*
/
FLOAT
(6 to 6.0)
IF (real)
GO TO
No. of Times
1 +1/3+2/3=2
1
1
1/3+2/3=1
2/3
1
1
1
x
Subsections
Page
I
02
60
10
Unit Time * Total *
330
660
440
440
490
490
790
790
2100
1400
330
330
190
7
190
7
4307
*In microseconds
On the average, then, this portion of your program will require 4307 microseconds, or 4.307
milliseconds, or . 004307 seconds.
Figures 70.34 through 70.40 show some
additional examples.
Section
Subsections
60
70
I
Page
03
10
FORTRAN TIMING ESTIMATE WORKSHEET
CODING
X
=X+~
IF
(X -77.) ~ ~ /
~Z~X ~/4~
ONE t:?U'T ~.,c EYERY .3 T//4£..5
GO T03
C£Z=X~/r;,·8
3
Component
TJA/CJ c)i/T OF THReE. T/ME.5
CV'A/T/NC/c
Number
of
Executions
/,Lf.§ 7'~
Time per Execution,
M i croseco nds
Extension,
Microseconds
..:330
(; ~ 0
I
4¢()
4- ~ 0
~LGJ4r
/
330
3 .3 0
-r~t?/
/
49CJ
4 9 0
/FV--~.'7/)
/
/9~
GeJ /-r;;;)
/
re:t:l/ ==
1'-
r~t?/
:1: r~c//
~I-%
/ rr:Jt1/
o/.§
Figure 70. 34.
/
9 cl
7
7
7 57 0
790
<1
2/00
/
TOTAL
4 Z.
=
CJ 0
/
7
Section
Subsections
Page
I
04
60
70
FORTRAN TIMING ESTIMATE WORKSHEET
CODING
X (I)
:=
X(I)+~
Ir(X (I)-7h) 0 2.; L
.1 Z= x(rJ */4,
GO
ro
.3
X (r)~ /~./J1/
C ~N)"/Nt.'%C"
Z Z.:.
.3
5Qme 05 r/.!lvre 7c:? 3¢ exee~/ ;-/;41X /5 St/e5.sCr?r,,,
Number
of
Executions
Component
S-~/?;l~
#. '$ hgw ~~
lW.6scl"~tt rvtl. -:
4
Time per Execution,
Microseconds
7t:7.3..-/
2i'LJ
TOTAL =
Figure 70. 35.
Extension,
Microseconds
~
Z / 7
/
/
Z 0
15 3 13
7
10
Section
70
Subsections
Page
I
05
60
10
FORTRAN TIMING ESTIMATE WORKSHEET
CODING
C
COC/;/.,/7'
TO /c:JoCl - £)0 Lc)OP
00 17 I=-d./ /000
. -,. ."
. .. .
~
17 C-O#7/A/,/c;-
I
Component
Number
of
Executions
;)0 lOG?
/COC
Time per Execution,
Microseconds
22' -I- 5t;',~ ;J
Extension,
Microseconds
;:'-"
0
0 2
2
f----.
TOTAL =
Figure 70. 36.
5 0
0 2- Z.
Section
70
Subsections
Page
I
06
60
FORTRAN TIMING ESTIMATE WORKSHEET
CODING
Ct:JO'N'T Tt:l 1 (JtJt:)
C
C/NTcGERS)
I::. 0
CI -/t:JtJCJ) I; 2)
7
If="
~
.£::=..z~:f
2'
GO 7"0 7
2
Component
$k~~r~
caNT/,A./vE
Number
of
Executions
/000
Time per Execution,
Microseconds
Extension,
Microseconds
22
-~k96'r
/ttJoL
/2
/Frf/;kye/)
/~t/.1
..30
/t!Jt:JO
7
/C?ot:?
/c
2 2, 0 0 0
I 2 0
3
LJ 0
/
2-
3
0
v
GCJ
rc;
-I-//Jk~er
TOTAL =
Figure 70. 37.
7
Cl 0 0
/
'2
(/
0
8
"
~
4- Z
0
10
Section
70
Subsections
60
I
Page
07
10
FORTRAN TIMING ESTIMATE WORKSHEET
CODING
TCJ /OC)O
sTAN.o/J,,{?O PRECiS/aN
C
C
COG/NT
x=o·o
7
i
2
Component
JF
x
=
(x-/ooo)
><
~2)2
~ f,
60 TO 7
Cc;?NT/NUE
Number
of
Executions
Time per Execution,
Microseconds
Extension,
Microseconds
/'~/ .::
/000
360
-re'4/
/ao/
SbO
/~(/e4/)
/co/
190
GOTe?
/c:?cJO
7
-rre4/
/000
460
TOTAL =
Figure 70. 38.
3 ~ 0 0 0 0
5 G 0 s b 0
/
9
4- ~
/4"I 5
CJ /
9 0
7 t/
t:? 0
0
0
(/
7 7~ 7 5
CJ
0
Section
70
Subsections
Page
I
08
60
FORTRAN TIMING ESTIMATE WORKSHEET
CODING
C
C
7
:1
2
Component
COL/NT TcJ /CJCJGJ
EXrEN£)££/ PREC/S/t;?/V
)(: 0, t:/
/ r ,x-/c/oo.)
X = x-r.f.
GO Tc:/ 7
CO/V'7/NUE
Number
of
Executions
/,.? 2~
2
Time per Execution,
Microseconds
Extension,
Microseconds
/cJOO
3.30
-/'~t?/
/00/
49CJ
/rVe'~1)
/?JO/
GCJ7CJ
/tJoo
7
f /"e.'t:1 /
/(/00
~¢o
/ 'ttPtfI /
:::
/
/9~
TOTAL =
Figure 70.39.
3 3 0 0 0 0
~ 9 0 4 9 0
/
:3
/
9 0
70
0 0
0
4 4-
0
0 0 C
4- 5
I
7
,6 8
0
10
Section
Subsections
60
70
I
10
Page
09
FORTRAN TIMING ESTIMATE WORKSHEET
CODING
C
COt/AlT
TO
/ClClc:J.)
!)£CIMAL.
AR/TH
.z
A55t/ME X Fie!.. 0 TEN D/t;//TS Lv#~'
ASSUME TJ1/0-0/~/T Cc::JA/.5T.4A/T O,-C a.IVE (K1)
C
c ASSL/ME TE/\/-LJ/t;7/T cONsrAlA//" c/"c /OOOCff/Ot::q)
C4LL F/LL (I0 1;10;1 (j)
7 IF (//COM.P{£ X/ 1,ltJ; ,1(/OOOJ I J /0)) 0 27 2
1 C/iLL 40D(£X)I.; 10) I-(~~ 2) N£)
GO 707
2 CCJA/?/NG/c
C
Component
-
Number
of
Executions
Time per Execution,
Microseconds
l,c(/;'/eye~ /£)0/
GO 70
~/LL
#i.?O.4'l"r?
,4£.ILJ
Extension,
Microseconds
..3c
7
/C)oo
.t
30o..,t./Ox,,90
/00/
250 7'-/0 X 75
/c::;oo
2/60 -f- 4
X
2/r;;;
TOTAL =
Figure 70,40,
3
0
cJ 3 0
7
0 0 0
C; 0 0
0
I
()
3
0 Z
4
()
-'I
I cJ 0 0
4-
tJ tJ 0
6 Z ~
""
.3
C)
Section
70
Summary and Conclusion
From the examples shown you may draw some
conclusions:
1. Integer arithmetic is much faster than real
arithmetic.
2. Extended precision and standard precision
real arithmetic are of essentially the same speed.
Subsectiors
Page
I
01
60
20
3. Decimal arithmetic is fairly slow.
4. Subscripting adds a considerable amount of
time to arithmetic calculations. (It also increases
the size of your program.)
5. Unnecessary use of mixed mode expressions
can add somewhat to execution time.
Section
70
Subsections
60
I
20
Page
02
FORTRAN TIIViING ESTIMATE WORKSHEET
CODING
Component
Number
of
Executions
Time per Execution,
Microseconds
TOTAL =
Extension,
Microseconds
Section
75
Subsections
Page
I
01
00
00
Section 75: SORTING WITH YOUR 1130
CONTENTS
Introduction ..
0 75.010 00
Some Preliminary Information . . . . . . . • 75.10.00
Alternate Approaches . . . . . . . . . . . • . . 75.20.00
Use of File Organization . . • . . . . . . . 75.20.10
Pure Sequential
Indexed Sequential
Random
Sorting Offline . . . . . • . • 0 . . .
75.20.20
Methods of Sorting . • . • • • . . . 0 . 0 .•.. 75.30.00
Introduction . . . . . . . • . 0 . . • • . • . . 75.30.01
Key Compare vs Key Value
(Radix) Techniques
Sequence-Creating vs
Sequence Reducing Techniques
0
•
0
0
•••••••••••••
0
••••
Degree of pat a Accessibility
Degree of Generality
Internal Sorting Methods . • . . . . . . . .
Selection
Exchanging
Merging
Insertion
Replacement Selection
Address Calculation
External Sorting Methods . . . . . . . . .
Key (Tag) Sorting
Key Sort vs Record Sort
A Detailed Look at an 1130 Record
Sort ••
Summary . . . . • • . . . . . . • . . . • . • .
0
•••••••••••••••••••••
75.30.10
75.30.20
75.40.00
75.50.00
Section
75
Subsections
Page
I
01
01
00
INTRODUCTION
Most data processing applications require a sequential arrangement of the information to be processed.
Frequently, a collection of related information, or
file of data records, is to be updated by adding,
deleting, or changing information as new transactions occur. Before the new transactions can be
applied against the main or master file, however,
a method must be established whereby a transaction
can be associated with a master. One such method
would be to arrange the transactions in the same
sequence as the master file (see Figure 75.1). For
this purpose, the master and transaction files are
sequenced by some common identifying characteristic, such as part number, account number,
employee number, etc. Similarly, when payroll
earnings are to be computed or data is to be tabulated in accordance with some scheme of classification, it is necessary to arrange the information
in a sequence that facilitates processing.
Sorting is simply a systematic method for
arranging or rearranging a file of data records in
sequence by some group of characters that constitute the control field, or control word, of the
record. (Control words are sometimes called the
key.)
This section discusses sorting with your 1130
but attempts first to show you (1) a possible way to
__--....,A.....- - - - . .
Record '
Num ber
Cant
67
4
81
106
107
303
Transaction or Detail File
108
109
308
809
Master File
Figure 75. 1. Transaction file and master file in same sequence
avoid sorting with your 1130 and (2) a way to ease
the task of writing a sort program, if one must be
written.
Section
75
Subsections
10
I
00
Page
01
Control Field or Word
SOME PRELIMINARY INFORMATION
It may be useful to review the meaning of some
basic terms and concepts that are part of sorting
terminology. As already stated, sorting concerns
the arrangement of a file which is a collection of
related data records stored in a data storage
medium (cards or disk). The file size specifies
the total nurrber of records contained in the file.
The input file is the collection of data records
introduced as input to the sorting process, while
the output file represents the collection of records
properly sorted and stored.
To place a file into a specified sequence, each
of its records must somehow be uniquely identifiable. The identification is made by means of the
control key, a group of characters arranged in a
certain way. The contiguous groups of characters
that are placed in order within the control key. are·
called control fields. Each of the control fields
bears certain identifying information, such as payroll number, name, organization code, address to
which checks are sent, etc. The data record control field that is most irEportant in sequencing the
records is called the major control field. When
two records contain identical data in their major
control field, they must be compared by the next
most significant, or IT, inor, control field in order
to be sorted into the proper sequence. If even the
minor control fields are equal, the next most
significant or minor control field must be considered, and so on. Thus, for the purpose of successive comparison, all the control fields within
the control key are arranged in major-minor (that
is, decreasing) order of significance (see Figure
75.2) .
Since the control fields of a record may consist
of numbers, letters, or special characters ($, -,
+, etc.), an order must be prescribed for the
characters of the control field to determine which
is greater and which is less. Such an order of
characters, upon which the sequencing of records
is based, is known as the collating sequence. In
the 1130, the collating sequence is A-Z, 0-9,
blank, and special characters, in ascending order
(see 70.40.20). The collating sequence determines
the proper order of the control keys.
Using these definitions, sorting may now be
defined more accurately as the process whereby
a file of records is placed in order by the collating
sequence of the control keys of the records.
A considerable body of specific sorting terms
has been generated over the years. To simplify
Disk or
card record:
Assembled into
control key
or tag
Major Control
Field
Amount
Salesman
JONES
A
B
9
SMITH
C
X
HILLIAMS
Second Minor
A
9
6.10
14.67
17.76
14.01
376.35
1.98
706.13
37.38
309.76
101.37
67.42
8.77
336.75
601.32
706.14
975.93
Customer
Name
Date
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
xxxx
Figure 75. 2.
the ensuing discussion, some of the more commonly
used terms are explained here.
The object of a sort is (to restate it) to place a
file of records in a desired sequence. Any group
of data records in which the control keys are in the
desired collating sequence is called a "sequence"
-- or, sometimes, a "string". The length of each
sequence can be one or more data records. It has
been assumed till now that a sort must be in
ascending sequence; that is, the final sequence of
records is such that the control key of each successive record collates (compares) equal to or
higher than that of the preceding record. This need
Section
75
not be the case, however. A sort can be in a descending sequence, with the control key of each successive record collating equal to or lower than that
of the preceding record.
Frequently, two or more sorted files have to be
merged into a single file of sequenced records. In
general, "merging" is a technique that collates
several sequences of data records to form a single
sequence. The number of files to be combined
during a merging operation is known as the order
of merge, or "merge order". Thus, a merge of
order m is called an "m-way merge". The processing of all the records once through the merge
is termed a "merge pass", or simply, a "pass".
The object of a pass is to reduce the number of
sequences (strings) by increasing the number of
records contained in each sequence. During a
single pass, the number of sequences is usually
reduced by a factor equal to the order of merge
(m). Several intermediate passes may be required
to reduce the file to a single sequence. A multipass sort is a sort program designed to sort more
data than can be contained within the internal storage of the central processing unit. In this case,
intermediate storage (disk) is required.
It is customary to segment a sort program into
a number of phases, each of which is executed as
one core storage lo.ad. For example, a typical
sort may be divided,into four phases: an initialization phase, an internal (presort or premerge)
phase within core storage, a merge phase (for
combining the sequences), and a final output phase.
The sequencing of a group of data records contained at one time in core storage is known as an
"internal sort". The size of the internal sort
is the nUli ber of data records (abbreviated G) that
can be sequenced at one time in core storage.
Note, however, that since the num ber of data
records to be sorted usually exceeds G (the number contained at one time in core storage), the
internal sort process must generally be repeated
until all the records in the file have been sequenced
into strings that may later be combined, or
merged.
It has been implied that sorting consists of moving data records around until their respective control keys are in the proper collating sequence. This
is not always the case. In some sorting methods,
the control keys upon which sequencing is based
are read from the record and combined with the
record number (called tag) to form a key-tag pair.
Then the keys are sorted, rather than the original
records. A fter sorting, the tags serve as an index
for later retrieval of the data records in the desired
sequence (see Figure 75.3).
Subsections
Page
I
02
10
00
Key
085
2
Record Number
NREC
603
3
143
4
801
5
013
6
035
7
109
8
706
9
431
10
307
11
010
12
444
I n core storage
before sorting:
Key
I n core storage
after sorting:
NREC
Key
NREC
11
085
1
010
603
2
013
5
143
3
035
6
801
4
085
1
Keys are p.hysically
sorted (moved around)
- - - . with each corresponding
013
5
035
6
109
7
706
8
431
9
431
9
444
12
record number (NREC)
moved with it
........
109
7
143
3
307
10
307
10
603
2
010
11
706
8
444
12
801
4
Now, either physically move the
disk data records
or
process (e.g., print report)
by obtaining disk records
in the order found in the
NREC table.
Figure 75. 3. Tag sort
The effectiveness of a sort program is measured
by the time it takes to sort a file of data records.
If the sorting method alone determined the overall
performance and speed, the choice of the best
method would be relatively simple. In actuality,
though, sort performance is the result of a complex
interaction between the characteristics of the data
file, the data processing system, the sorting
method used, the objectives desired, and a number
Section
75
Subsections
Page
I
03
10
00
of other characteristics. Thus a great many factors play a role in determining the efficiency and
speed of a sort program.
Among the more important data file characteristics, the following may be cited: the degree of
original ordering of the file (that is, is it in random
order or do natural sequences exist?); the length,
range, and location of control word data; and the
number and length of the records.
Equally important in influencing sort performance are the characteristics of the storage facilities
and the CPU of the computer. Among storage characteristics of interest are the capacity of the main
internal storage and the mode of addressing it, as
well as the availability and access times of external storage devices, such as disk files. Relevant
machine and CPU characteristics include simultaneous read, write, and processing capability; the
basic processing speeds of compare, add, and
move operations; the structure of the OP-code set;
and the availability of indexing, table lookup, etc.
For a given sorting method, the data file characteristics influence the primary sorting statistics,
such as the total number of arithmetic operations
or comparisons and the total number of passes.
For a file of a given size, each method also has
some inherent characteristics that influence the
complexity and speed of the sort -- for example,
the required working storage, the required number
of comparisons, transfers, and exchanges, etc.
Finally, realistic sorting objectives must consider the specific data processing requirements,
as well as the complexity and cost of the sort programming effort. A specific sort program should
try to provide an optimum match between the specified data file, the given machine configuration, and
the chosen technique. In sorting large files, a
single sorting technique cannot always provide this
optimum match. Frequently, therefore, a program
combines two methods in order to take advantage of
special machine features, minimize the effects of
storage limitations, and provide increased speed.
Section
75
ALTERNATE APPROACHES
Before you write a sort program for your 1130,
examine your files and the reports to be produced
Subsections
Page
I
01
20
00
from them. You may find that sorting on your 1130
is not necessary, or that sorting can be avoided.
Some alternate approaches to sorting on your
1130 are:
Use of file organization
Sorting offline
Section
75
Subsections
Page
I
01
20
10
Use of File Organization
Indexed Sequential
Is it possible to keep mulitple copies of your files,
each in the sequence of a report to be produced?
If so, you can avoid sorting. If not, however, as
is likely with moderate to large files, the importance of your file organization scheme emerges.
Is it possible to keep multiple copies of your index,
with each index in the sequence of a report to be
produced? Since your index is considerably smaller
than your file, this may be the ideal solution. Processing against the file would be random. (See Figure 75.5.) Again, if this solution cannot be used,
you can still sort offline.
Pure Sequential
An answer for files organized in a pure sequential
manner is to maintain multiple copies on multiple
disk cartridges. This eliminates sorting but may
cause problems in processing. (See Figure 75.4.)
Generally, with pure sequential files that are too
large for multiple copies, the solution is offline
sorting.
Random
In this case your files are usually organized in a
sequence that does not relate to a report. The
transactions (say, cards containing only control
keys) must be sequenced appropriately; a sort is
necessary. Hence, the only way to avoid sorting
using your 1130 is to sort offline.
00103
Jones
2
Jones
2
3
Jones
3
00109
00110
4
Jones
00115
5
Smith
00131
6
Smith
1
r
87961
Williams
in salesman
sequence,
for sales report
in part number
sequence, for inventory
report
Figure 75.4. Same data in two files, but in different sequence
Section
75
Man number
Birth date
010
2
015
3
017
4
021
5
036
6
043
055
Master File
99
591
100
603
~
Record Man
Number Number
/
Birth
date
Record
number
010
2
015
3
017
4
021
5
036
6
043
7
055
8
99
591
100
603
Index, in man number
sequence (same as file)
To run payroll, etc., look
up employee in this index.
Index, in birth date sequence
To run birth date report,
print from this index
Figure 75.5. One file, but with a multiple index system
Subsections
Page
I
02
20
10
Section
75
Subsections
Page
I
01
20
20
Sorting Offline
Sorting offline can be either a manual or a mechanized procedure. A manual procedure (by hand)
should not be used unless volumes are very small.
Even with small volumes, you will need a program
to sequence-check the sorted cards.
A mechanized procedure involves the use of a
sorter. IBM has mechanical sorters available that
can process up to 2000 cards per minute.
The rule-of-thumb procedure for timing offline
mechanized sorts is:
1. Compute the card-passing time for each
column in the control key.
2. Sum these times.
3. Add 10% for card handling.
You must decide whether the time and money spent
sorting offline will be less than the cost of programming and running a sort for your 1130.
Section
75
METHODS OF SORTING
Introduction
Sorting and merging methods can be classified in accordance with certain distinguishing characteristics.
Key Compare vs Key Value (Radix) Techniques
Most sorting methods compare control keys of two
or more records at a time and sequence the records
on the basis of a high, low, or equal comparison of
th~ keys. Despite variations, all key compare
techniques are essentially similar in concept. An
example of a key compare technique is the card
player's way of inserting new cards into his hand
in proper sequence, by comparing the value of each
new card with the values of those he is already
holding.
In some sorts, action is taken on the basis of
the value of the individual digits in the key and
their pOSition, rather than by comparison of two
keys. The value of the key digits -- or, more generally, of the key number base (radix) -- is used to
determine into which particular slot each record
should go. Key value or radix techniques are also
known as digit sorts, which is a narrower term.
The mechanical punched card sorter, with separate
pockets for each key value, is an excellent example
of a radix technique. Another illustration is the
distribution of a deck of cards into four piles (or
files), one for each suit.
Sequence- Creating (Internal) vs Sequence -Reducing
(External) Techniques
Another fundamental way of viewing sorting is to
distinguish between techniques that create sequences
(starting with a random or unsorted file) and those
that reduce the number of existing sequences to one.
In theory, most techniques capable of creating
sequences of at least two records, or keys, are also
capable of lengthening those sequences to a point
where, finally, all records are contained within a
single sequence. In practice, however, the
sequence-creating or internal sorts are usually
only the prelude to the main or merge phase of the
sort (hence the terms "presort" and "premerge").
Initial sequences are created by loading a group of
Subsections
30
I 01
Page
01
records into core storage, sorting the records
internally, and placing the resulting sequence on
an intermediate storage device. This internal sort
process is repeated until the input file is exhausted.
The sequences thus created internally are then
reduced to one by an external merge. If the entire
file can be contained within core storage at one
time, the sort is exclusively internal. In most
cases, however, both internal (sequence-creating)
and external (sequence-reducing) techniques are
necessary to sort a large file.
Degree of Data Accessibility
Sorts also may be distinguished in accordance with
their relative need of data accessibility. Most of
the internal techniques are best suited to storage
media that can provide rapid access to many groups
or sequences of records. Core storage provides
the most rapid and direct access, while disks furnish a lesser degree of data accessibility. A number of methods work well with disk.
Degree of Generality
Finally, sort programs may be categorized by the
relative degree of specificity or generality for which
they are designed. A large range of objectives
exist between narrow, highly specific sorts and
broad, generalized programs. On one end of this
range there are specific sorts designed to operate
on a specified input file and a specific computer
configuration. Somewhere in between are generalized sorts that will accept the introduction of some
parameters at execution time to adapt the sort program to the characteristics of the particular file
and computer configuration. At the other extreme
of the range, there are highly sophisticated, generalized sorts and sort generators that, virtually
without user intervention, can generate a great
variety of ordered results on a variety of file and
computer configurations.
In most instances, a specific sort program will
satisfy your sorting needs. The remainder of this
subsection discusses some sorting methods (both
internal and external) of the types described above.
In addition, one of the easily implemented sorts
is expanded in flowchart form for your more detailed
examination.
Section
75
Subsections
Page
I
01
30
10
Internal Sorting Methods
Internal sorting is defined as the sequencing of a
group of data records contained in the core storage of your 1130. It generally involves reading
successive records from disk storage into core
storage, sorting the group in storage by one of
the methods to be described, and then writing the
sequenced group onto disk.
Since internal sorting is generally a part or a
phase of other processing and programs, you' must
distinguish between methods according to the ultimate purpose they serve. Thus, some sorting
routines found in compilers, assembly programs,
and other applications are strictly internal; that is,
a group of items is to be sequenced only in core
storage, not written onto disk. On the other hand,
in most generalized and specific sort programs,
the file of records is too large to be contained, at
one time, within core storage. Here the internal
sort passes serve only as a prelude to the subsequent external merge phase of the sort and, hence,
are frequently called presorts or premerge sorts.
The purpose of the internal sort, then, is to form
a number of sequences, or strings, which are
placed into the output and subsequently merged.
The more efficient the premerge sort, and the
longer the strings it generates, the fewer external
merge passes required.
In addition to the purpose of the sort, the follow..:..
ing considerations apply in selecting an internal
sort technique and evaluating its suitability for a
specific application:
1. Characteristics of the machine (basic processing speed, internal storage capacity, etc.)
2. Input/ output characteristics (number of disk
drives).
3. Number and length of data records.
4. Length and range of control keys.
5. Degree of original file ordering (natural
sequences) .
6. The associated program.
Since there is no single best method for all types
of applications, most sort programs represent a
compromise between conflicting requirements. In
general, they attempt to incorporate the following
in as nearly optimal a manner as possible:
1. Sort internally as many records as can be
packed into core storage.
2. Minimize total process time per record.
3. Function in a manner compatible with I/O
operations and strive for a maximum overlap of
read, write, and processing time.
4. Utilize existing sequences in the input file,
if possible.
5. Write routines that are compact and that can
be modified easily.
6. In a generalized program, accept and sort
variable length records with any size control key.
Generally, records can be sorted by (1) physically moving them about until they are in order,
(2) forming tables of record numbers (tags) in storage, which are then sorted, or (3) combining the
control key and record number and sorting the
resulting short key-tag pairs. Either tag sorting
or key sorting is the preferred method today. The
sorted keys are then used as an index to the file.
In addition to an explanation, the advantages and
limitations of each sorting method will now be evaluated briefly with respect to major file and machine
characteristics. Additional methods and additional
information on each of the methods discussed may
be found in Sorting Techniques (C20-1639).
Section
75
Subsections
30
I
10
Page
02
Selection
Exchanging
Sorting by selection -- perhaps the simplest, and
also the slowest, of the internal sorting methods -consists essentially of an examination of the input
file to find the record with the smallest key (for an
ascending sort) and placing this record or its key
in the output area as the first item of the new file.
The source file is then scanned for the smallest
key of the remaining records, which becomes the
second item of the new file, and so on, until all
items have been placed in the output file.
When the selection process is carried through
the entire file in one stage, it is called "linear
selection"; when the original file is broken up into
groups, and the smallest key of each group is
chosen, and then the smallest of these smallest
keys, the process is termed "quadratic selection".
Selection requires a relatively small working
storage area in core, equal to the number of items
being sorted internally. However, the number of
passes over the file also equals the number of items
(one for each record), and the total number of
comparisons required increases with the square
of the number of items to be sorted (for linear
selection); this rapidly becomes inefficient for a
large file.
The technique of sorting by exchanging consists
essentially of comparing the keys of successive
records -- either one by one or pair by pair -and exchanging out-of-sequence items. The sort
is completed when no exchanges are made during
a pass through the file. Many variations of this
general procedure are possible.
The major advantages of exchange techniques are
the relative ease of their programming and the fact
that all work is done in the area in which the original file is stored; no separate working storage
area is required. Among the drawbacks are the
dependence of exchange methods upon the distribution of the control fields in the original file and
upon the number of records in the file. If the file
is almost in sequence, one pass will generally
suffice. In the worst case, reverse sequencing,
the number of passes may equal the number of
items (G) to be sorted, and the number of exchanges
(key and/or record movements) may become
very large. Since the number of comparisons
required increases with the square of the number
of items to be sorted, exchange methods are most
efficient for sorting a relatively small file of
records. Perhaps the simplest exchange technique,
and the easiest to program, is pair exchange. The
keys of adjacent records are compared; whenever
they are not in as cending sequence, they are interchanged. During the first pass, the keys of the
first and second records are compared, then of
the second and third, of the third and fourth, and
so on, until all keys in the file have been compared
and interchanged, when necessary. Each successive pass will process one less record. The sort
is completed when no interchanges occur during a
pass. The example below illustrates the procedure. In general, the maximum number of passes
(for the worst case) is equal to G - 1. The average total number of comparisons (C) is
G(G-1)
2
where G is the total number of items to be sorted.
Section
75
Subsections
Page
I
03
30
r
10
Merging
Input and Pass 1
13
13
13
13
13
69
69
56
56
56
56
56
56
L- 02
02
02
02
02
02 )~69
08
08
08
08
08
08
69
L- 21
21
21
21
21
13
r69
r
21~69
Pass 2
13
56
r
13
13
13
13
56
02
02
02
08
r
02
02
08
08
56 )~ 08
08
56
21
21
21
21
69
69
69
69
Pass 3
13
r
02
r
21
56
69
Output
02
02
08
08
08
13
13
13
02
r r
02
13
08
08
21
21
21
21
21
56
56
56
56
56
69
69
69
69
69
The size of the file is of great importance, since
the total number of comparisons and interchanges
increases roughly with the square of the number of
records in the file.
Merging is the process of combining several
sequences of records to form a single specified
sequence. The same rules by which sequences are
combined may also be used to form sequences (of
two or more items). Thus, the merging process
has, essentially, a dual nature: it can be used for
creating sequences (usually in an internal sort),
and it is also capable of reducing previously created
sequences to one (usually in an external sort). This
dual capability contrasts with the selection and
exchange techniques described thus far, which are
useful prim arily for internal sorting of relatively
short files of records. The versatility, speed, and
simplicity of merging make it one of the most widely
used sorting techniques.
There are two basic methods of merge sorting:
(1) straight or standard merging, with fixed-length
sequences, and (2) natural merging, with variablelength sequences, or strings. (The words "sequence"
and "string" are often used interchangeably in
merging terminology.)
In straight merging, the input file is distributed
initially into two or more work areas, depending
upon the number of sequences to be combined during each merge (that is, the order of merge). For
example, in a method of two-way straight merging,
the first merge pass alternates between two storage areas to form strings of two records, one from
each area. Subsequent passes double the length
of the strings each time (for example, 4, 8, 16,
etc.), until the last pass produces a single sequence
of all the records. The length of the strings during
each pass and the number of passes are fixed.
The natural merge sort takes advantage of
"natural" sequences in the original file, w hi ch
occur with a certain "probable" frequency. The
length of the strings on each pass is no longer fixed,
but depends upon the existing sequences. The total
number of passes required to sort a given file, then,
also depends on the number of natural sequences in
the original file. For a file that is in correct
sequence, only a single pass is required --- to verify
that sequence. In the worst case, the number of
passes is the same as for straight merging.
Section
75
Subsections
Page
I
04
30
10
Insertion
Replacement Selection
A fairly effective method for sorting a small number of items, the insertion technique, places each
item in sequence as soon as it is encountered. The
records (or tags) are brought into storage one at a
time, the key is examined, and the item inserted
in the correct place of an output file. Earlier
members of the partial file are moved aside, when
necessary, to make room for new items. The
method is straightforward and easy to program,
but is relatively slow compared with other
techniques.
Sorting by simple insertion has two inherent
drawbacks: (1) the partial file must be searched
each time to locate the correct place for inserting
the new item, and (2) excessive shifting of the
sorted records is necessary for each new insertion.
The first limitation can be overcome, to some
extent, by sUbdividing the area that must be
searched in order to locate the correct position
of each new item. The second drawback -- the
large amount of record movement -- can be avoided
by sorting record numbers (tags), rather than the
record themselves. Even with these improvements,
the method is too slow for larger files.
The internal sorting methods described thus far
are all capable of sorting a group of records (G)
that can be contained at one time in core storage.
The maximum string length is, therefore, limited
to G items. An auxiliary technique, known as
replacement (sometimes, replenishment), tries
to keep the core storage area filled with G items
by replacing records that have been withdrawn during the sort. As a result, for a file in random
order, an average string length of 2G items is
developed in an area with a capacity of only G
records. For a given amount of available core
storage, the replacement technique produces the
maximum possible sequence length. This characteristic makes the technique eminently suitable as
a premerge sort and permits a Significant reduc
tion in the number of merge passes required for a
subsequent external (disk) sort. The price paid
for this advantage is increased complexity of programming, relatively long processing time per
record, and a slight increase in the required working storage. Also, the number and length of the
sequences are variable and, hence, not predictable. Most replacement sorts, however, will
generate string lengths approximating 2G.
Essentially, the replacement selection method
determines the lowest record in the record storage
area, moves it to the output area, and then replaces
it with a new record from the input file. If the
new record is lower than the one just moved to the
output, it cannot be part of the current sequence
and, therefore, is flagged or held for the next
sequence. The process then continues with the
selection of the next-lowest record, and so on,
until there are no more replacement records in
the record storage area that fit into the current
sequence. A new sequence is then started, and the
procedure continues until the entire input file is
processed.
Section
75
Subsections
30
1
10
Page
05
Address Calculation
When the approximate distribution of the key values
is known, it becomes possible to sort a file internally by estimating the eventual (sorted) position
of each key. This method is called "address calculation" or "pigeonhole sorting".
Briefly, it consists of calculating the correct
record number of each item within the file by a
predetermined linear formula of the form y= a +bx.
If the location at that record number is empty, the
item (record or key) is placed there; if it is full,
a search is made to find the closest empty space in
the viCinity of the calculated record number. The
item at the calculated record number and the adjacent items are then moved so that the new item can
be inserted in its proper place in the sequence.
Address calculation is similar to the insertion
method in that each item is placed directly in its
proper relative position within the file, and the
entire file is in order just after the last item has
been inserted. The method differs from insertion,
however, in that some foreknowledge of the range
and distribution of the keys is required to estimate
the relative location for each item. When this is
available, address calculation is a relatively simple
and rapid method for sorting a medium-size file
(several hundred to a few thousand items) of small
to medium-length records. The major disadvantage
of the method is the need for a fairly large storage
area -- about two or three times the size of the area
needed for the original file. If only a relatively
small working storage area is available, or if the
distribution within the file is not as forecast, a great
deal of processing time will be spent in redistributing the records.
To illustrate this method, let us consider a
hypothetical case: Many years ago, the ABC Company set up a man-number system based on a threedigit number. Since they had about 150 employees,
each man was assigned, in alphabetic order, a number evenly divisible by 5 (005, 010, 015, 020, 025,
... ,995). However, there are now about 240 employees, and the system is not quite as neat as it
once was.
Some of the men (50 of them) have been assigned
num bers out of the normal pattern (for example,
862 in between 860 and 865). They are still in alphabetic order, though.
The address calculation sort could be used to
place this employee file onto the disk in alphabetic
(man-number) sequence in the following way:
1. Set up a file containing 500 records.
2. As each man-number is encountered, divide
it by 2.5, and convert the result to an integer (call
it N).
3. Check record number N to see whether there
is already an employee there.
4. If there isn't, put the man just processed into
that record.
5. If there !E someone there already, move the
adjacent records up (or down) until there is room
to insert the new man.
This will be quite fast, provided the "moving around"
(step 5) is not required too frequently. If it is, the
file could be increased to 600 records, and the mannumber divided by 2. This, however, would waste
a considerable amount of space on the disk.
Section
75
External Sorting Methods
When a file cannot be contained within core storage,
additional external passes and intermediate storage
devices, such as disks, are required to sort the
file. The internal sort, then, is only one phase of
a generalized multiphase (or multipass) sort that
may have three or four phases. In such a multiphase sort, the internal sort phase is concerned
with the creation of suitable sequences from the
main file, while the external sort, or merge phases,
are devoted to the reduction of those sequences to
one continuous sequence.
Practically all the internal sorting techniques
described earlier can also be used -- with varying
success -- for external sorting by changing the
terms of reference appropriately. Thus, the internal storage area is replaced by several input and
output areas on disk.
It has been suggested earlier that sorting techniques could be categorized according to the degree
of and relative need for data accessibility. Thus
far, sorting techniques suitable for one extreme of
data accessibility have been described. The internal sorts were seen to be best suited to high-speed,
direct (random) access storage media, such as
magnetic core storage. In these media, any record
or string of records can be accessed immediately,
without the need for passing over other, unwanted
Subsections
30
I
20
Page
01
records.
Despite their name, direct (random) access file
storage media (such as disks) provide a degree of
data accessibility less than core storage. The time
to access a record in these devices is not completely independent of the location of the previously
accessed record (as in core storage), but neither
does it depend on the entire sequence of records
stored before it (as in magnetic tape). The time to
access the next record depends on the number of
cylinders the access mechanism must be moved
from the previous record. (Each one or two cylinder move on the 2310 disk drive requires 15
milliseconds.) However, since internal core
storage is generally insufficient to hold an entire
file, auxiliary storage devices such as disks are
usually necessary.
With disks some attention must be given to the
relative advantages of key or tag sorting and sorting of complete records. It has been found in internal sorting that key or tag sorting (involving either
record numbers only or short control records) is
conSiderably faster than sorting of complete records. However, because of the substantial seek
time, this is no longer true for disks, when the
orginal records must be retrieved at the end of the
sort.
The follOWing paragraphs explore some of the
considerations pertinent to disk sorting.
Section
75
Subsections
30
I
20
Page
02
Key (Tag) Sorting
In general, key sorting consists of extracting the
control key from each record and adding the record
number to form a key-tag pair. These pairs,
rather than the original records, are then sorted.
(Sorting is done with the key; the record number is
merely moved about so as to remain with its associated key.) After sorting is completed, the pairs
provide an index for later retrieval of the data records in proper sequence. The obvious advantage of
key sorting is the more rapid processing of the keytag pairs, rather than the much longer original records. During internal sorting, more pairs can be
sorted into strings; thus, fewer strings and, probably, fewer merge passes will result. The eventual retrieval of the data records (if needed) from
external storage is done using the final sorted keytag file.
A typical key sort with disk storage proceeds in
either two or three phases, depending upon whether
final retrieval of the data records is necessary.
Phase 1 is an internal key sort; phase 2 merges the
internally formed strings of key records; and phase
3, if required, retrieves the input records in
proper sequence. The approximate procedure during each phase is described below.
Phase 1 (Internal Sort) consists of the following
steps:
1. Place input records on the disk file in order
of occurrence.
2. Form key-tag pairs by lifting the control
field(s) from each input record and adding to it
(them) the disk record number.
3. Read G key-tag pairs at a time into core
storage and sort them internally (by any standard
method) into strings of length G. (G refers to the
number of items that can be contained at one time in
internal core storage.)
4. Write the stings of G pairs successively
onto the disk file, using as many sectors or files as
necessary (usually no more than five files of strings).
Phase 2 (Merge). The merge phase of the sort
consists of merging the strings of pairs from the
separate files on disk. The merge is completed
when a single sequence of key-tag pairs has been
written onto disk. During the final merge pass, the
control keys are stripped from the key-tag pairs,
leaving only the disk record numbers or tags.
These record numbers then serve as an index for
placing the input records in sequence. At your
option, sorting can end at this point.
Phase 3 (Record Retrieval). This phase is
necessary if the data records are to be retrieved
from the disk file in their sorted order. (Remember,
only the tags have been sorted, not the records
themselves.) The manner in which this is done has
a greater effect on overall timing than phases 1 and
2 combined. The simplest way (also the slowest)
consists of retrieving the records one by one in the
order indicated by the successive disk record numbers. If the original input records constitute a
large file extending over several cylinders of the
disk, the probability is high that a seek must be
executed for the retrieval of each record. This will
add considerably to the time required, since the
seek time necessary to retrieve the records will
probably dominate the overall sort time.
A number of ways have been devised to minimize
this seek time during the retrieval of records in
phase 3. One method consists of bringing the disk
record numbers (from phase 2 of the sort) into
internal storage in some multiple of the output
blocking factor. The disk record numbers are then
sorted internally in ascending sequence, thereby
reducing the seek time between records. The
input records are read initially from the disk in
ascending record number sequence; blocks of records are then placed in proper sequence (in accordance with the original sequences of disk record
numbers); and the sorted records are finally written
back onto the disk file. The method reduces seek
time substantially, at the expense of more complex
programming.
Another method of modifying the key sort consists of blocking the sorted keys so that the number
of items in each block plus an equal number of
original records just fills the core working area.
The items in each block are then sorted again to
place the disk record numbers in ascending sequence. As before, the records indicated in each
block can then be retrieved sequentially from the
file and sorted internally into the proper sequence.
It will be found, however, that in most cases, and
for large files in particular, these methods of reducing the seek time still result in a greater overall
sort time than might have been requi red to perform
a complete record sort.
Sectio.n
75
Key So.rt vs Reco.rd So.rt
Usually, key so.rting is o.f no. advantage, even with
large disk files, when mo.st o.r all o.f the o.riginal
records are to. be retrieved. Mo.difying the so.rting
and reading schemes to. minimize the to.tal seek
time can have a co.nsiderable effect, but the advantage, generally, still lies with reco.rd so.rting.
Whether a reco.rd so.rt o.r a key so.rt sho.uld be used
to. so.rt a disk file depends largely o.n the ultimate
disPo.sitio.n o.f the so.rted reco.rds.
Subsectio.ns
Page
I
03
30
20
If o.nly an index o.f so.rted reco.rds is necessary,
and few o.f the so.rted reco.rds are actually used,
key so.rting Wo.uld appear to. have the edge.
Exceptio.n repo.rts extracted fro.m the so.rted file
are an example o.f this type o.f situatio.n. On the
the o.ther hand, if mo.st o.r all o.f the original
reco.rds are to. be retrieved, record so.rting is
preferable to. key So.rting. Mo.reo.ver, the advantage
increases with the size o.f the file.
Section
75
Subsections
Page
I
01
40
00
A DETAILED LOOK AT AN 1130 RECORD SORT
An improvement on the simple exchange technique
consists of making alternate passes in opposite
directions, attempting to move the high records to
the bottom and the low records to the top of the file.
This is called an alternating pair exchange sort.
The procedure starts in exactly the same manner
as in pair exchange, by comparing the keys of
successive records. After an exchange is made,
the high key is compared with the key of the next
record in sequence, and these comparisons continue until either a higher key is found or the end of
the file is reached. All intermediate records (and
their keys) are shifted up one pOSition. During this
first downward pass, therefore, a high record can
move down many positions, but lower records can
move up only one pOSition.
The second pass is in the upward direction (from
the bottom to the top of the file) and tends to move
the smaller records closer to the beginning. During this, and during every other even-numbered
pass, a high record can move down only one position,
but a low record can move up many positions.
Successive passes continue to alternate, with oddnumbered passes in ascending sequence and evennumbered passes in descending sequence. The file
is in sequence when no interchanges occur during
a pass. A final output pass is required to verify the
correct sequence.
The example below illustrates the alternating
exchange technique. The first pass, proceeding
downward, recognizes that 89 and 56 are out of sequence and exchanges them. The high of the compare, 89, is then compared, in turn, with 02, 08,
and 21; since 89 is higher in each case, it moves to
the bottom of the file. The low of the compare, 56,
moves up one, and all intermediate keys also move
up one pOSition. In the second pass, the comparisons start with 89 and move upward. The first outof-sequence keys are 02 and 56. The 56 drops down
one pOSition, while the 02 moves up two positions,
since it is lower than the 13. During the next downward pass, the 56 and 08 are out of sequence; the 08
moves up one position, and the 56 moves down two
positions, since it is higher than the intermediate
21. During the fourth (upward) pass the out-of-sequence 08 and 13 are interchanged. The final output pass is needed to check the completion of the
sort.
End
End
End
End
Pass 2 Pass 3 Pass 4
Output
Input Pass 1
13
13
8K5656
02
08
08
21
21
89
1
t
02
/
02
02
13
13~08
08
21
89
21
56
89
02:><--"'5~0~
t
~
-----13
21
56
89
02
08
13
21
56
89
t
The arrows indicate the direction of the pass.
The example shows that the maximum number of
passes is equal to the distance, measured in number of keys or records, which is the largest separation of a key from its final place in the sequence.
In this case, 89 is four pOSitions away from its final
(bottom) position in the file and, therefore, at most
four passes (plus the output pass) are required to
complete the sort. In general, the alternating
exchange method requires slightly more complex
programming than the earlier exchange method, but
it results in a smaller number of compares and,
frequently, fewer passes. The following pages
show this method in more detail.
Section
Subsections
Page
I
02
40
75
00
START
DISK
DISK
Initialize:
NSTRT
NEND
NRL
first rec.
number
last rec.
number
record
length
, . . . . - - - - -__~ 2,M,NREC 2- (M)*
(NRPC),NRL,NRPC,
NARAY,NRECT
1,M,NREC2,NRL,
NRPC,NARAY,
NRECT
DISK
FIND
2,-M,NREC1,
NRL,NRPC,
NARAY,NRECT
NREC1
Housekeeping:
NRECI
NRECT
M =1
NSTRT
NEND
N=O
SORT
N=O
NEXS,LARRY,
NRL,KS,KE
NRPC =
(320/NRLl*8
N=N
STOP
M=-M
Move bottom
of NARAY to top
when M>O, top
to bottom when
+ NEXS
MO, top
to bottom when
M
........ 11-::> VALUE
I-a.. MAX.
~O
MIN.
VALUE
Z
j)/5X
-
- -
-
-
,c//,/LJ
~k£
=--
- -
-
-
*"KS
I
tfser
I
~ARRY Z / Z
I / T
A1
Z / T
#
t/.J't!!~
,.1/,4R4Y 41 I~ T
PA/R
Program Name
g.t?//'J
//~e
Date/q/f!3/67
Programmer
No.
FUNCTION OF VARIABLES
~el" t/.5el";"
/ f
/
~LT£RNA'7/NG
EXC/-/4A/&E 30/'?7
~
~
.z
Application
~;;I/t:7/?
t/ser
~/r;~"
tf'5er
cJ/l'?/!J/J
/
~Jb/he
'r7t/dllJe:j{
rec{7r,
-
/}su!Jrt:Jdf//?e /-0 (/)7; // TAt:!' RSA U///~ d/JsC)/,led
/'L?ct:}/2?'s oa4<2.,)e/77/;JTo/ The RS/1 t:JT S'o/'~~./ r~ct:Jr4's
The Fi::JRrRAA./ srt:?/en1t!?n"
/7701/
LJ/ SO""/'vp ~e IJk tPr ck~// rA,h/'e -/ or +/.
~n1e of?drrdt/
P~card S~ro.ge
/b,-
'*"¥ENL? I / I /J/'?/~a 2
Uj) rp
!V'eXS' Z / T AlR,.ot? ¢'
#'R'£cT I / T AlLAID ~T..f>T
7h~ rt!'ctCJrQ' /7d/17'oer C)/ ~Ae
II
WA'ECZ V
u?s;91
/".5"7 reclJ!7n//;' He..,4l:!
'The /)V.-rlbero C)~ e~ch'f"?5es dC/~/'r;9 rhe s~#'£)/1 4 .Pd //? 11>/ C.9'VAa'er,.s-.
ae ;r-.ecor# nvn'16&ro e/J/';"'-9 d
"LJdSS
/
T WEA/L.>
/
me record/u.N1?bt!?r
I
T
/
7Ae /"ect!:J,..d nVh7ber ~r RE4D/;;~ h,n The IJ/e.
.32~
2
lhe reCLJrq /e/?grh .
.L / / /Z80
A/RIf/ I I T 2
t/fer I/ser>
~#STA?T I / l' ~I'/o",
8
A/c/fr1b~/' o/' reco,-~ 'per C'qh~der;
/
RE4Cj 'p(/,f'/TE
/
.Me recor-t:T /'1vrnber 0/ .,tA~ A;-'s/,ec~r///7 rA~ ~~
;t/~EC/
*/\/RL
z:
jc/.5t'1"
1 Z
AlEA/LJ
A"Rpc
SORT
¥:
- - - -
-
/l;r WR/7/::~ .d4c;f ~rA~r;~
5.:,v/·-/Ch, ,-96>44=/;
M/k::t?
/l sC/6rClv~/;,e r(!) SCJr-~ rhe co/) 7t!!'rlr:s t:!JT
N,4R4~ fAe /'ect?r/ srore:?'4e area.
#l.Isl be .se;/ 0;;1 Me
*Mode: I = integer, R = real, D = decimal, A = alphabetic,
V.$'e/'.
Section
75
1=1
>
L
L = 0-1)*NRL+1
= H(NRPC+I-1)*
NRL
N = I*NRL
N = (NRPC+I)*NRL
*
NREC = NREC+M
NREC = NREC-M
1 = 1+1
Subsections
40
I
00
. Page
04
Section
Subsections
75
I
40
Page
00
05
VARIABLES
IBM
1
1130 COMPUTING SYSTEM
VARIABLE SUMMARY SHEET
Vl
"E
0
NAME
*W
0
0
::2!
:s:
0..
::2!1w:J
1-0..
. .
MAX.
VALUE
'0 ;::::~
~o
ci
z ~
I
I
J
V
/ T 25C;¢
I
I
T
.T
i.
AI
f
/
;t/
I
I· T
*NRN .I /
/
gt?!JI"'''/~g
-/
256~
.5'G'()
r
~
tlS
Pedc//h/r/ I-e
orcur~t!!?n,t ,record~e/~.:7 r~4~r/He'7
/W.:-/use ~~ Aq//o/'A//IRA>{H-=,t/ V.fe~//dn7l1)q/f1
-
/
/
~/77e'
C'/'??/'rd~ A,- /f~Cl!Jrd' S/o"..qge (RS,q)
/'lYe numOe"'"
/0 b~ $or/ed'
C!O,r/,
f-I:::>::>
/<
~KE
~kS
Z /
f
T
Z
.L / Z
LARRY Z
UtJV£
/
-
/
-
;VeX
.L
~E%S I
*AIRL
-1F
-
I
/
.T I
NameSor.f- SuLJrou///?e
Date/q/e~7
Programmer
No.
A
-
,te,n/,:or'd""'Y
C7reQ ~O'-
s-;42,-':.ny
..57/8
{/sed
User
CJ;p?}b~
(/ser
tqlJhb"
-
:h-';t%.
T ih2c!!,/s
very-
/
2
)
d$
,record'
//7d'e~ /~ /t::>o,r:"
E.nd ~/ rAe C0/77ro/ ke:p /h- 8a.td/J:;1 /i:!Js/'h~~
.8~/~,:,//J.:I or rhe Conrro/ kt5?.::/; /rs dorr//7,9
P-cs/ r/O/7
S/ZO .Ie/1.:J"h o/'rh~ ~ct!Jrd $/o~S7e4/eq~s4)
-
CJ
/I .:500/''t7v/e
~o /?70V~ C? rec~r-d
Ak,/Y7e O/'4/"'/dY
4
~
/or-- 7rbcon::/ sn;.roj7e ~SA)
sC/,6rc7/./r//Je :1-0 cCJ~t:?re ~o co/? rro/ +eys
coc/.ar i f ~he "t./n?oer ~r eKchd~.7es dU"-/'~9
d S//7BLe /aJo-cq~;'dt!?/' sorT "OdSS
/) cc>v/?;L CJ/ r-Ae rort;7/ /7G/,,?-?oer e>r exchd/Jges
% h~4e
c:J
dV/"//Jt:3
Z
2
T/;~ record /t!!?/Jg/h
320
O/7e
dv/"//?'g &7/7 eKC.l7dr7ge
The /dS";/- ret=orL7' ~ur t::)/'CJrd~r
tJ,tJl/b/7
-
Program
4L/cR-A/AT/A./G PA'//c:::::::.
EKCHAA./6E SOR T
.57/8 4,10&
- /
MIN.
VALUE
FUNCTION OF VARIABLES
;;/ser
~RAY /// W"Zl: I/tJ
;1iCU'M.P -
Application
MAX.
VALUE
0..0
~
7T£!WP 41 V,(l I
J
J / T
1130 COMPUTING SYSTEM
4////Jq p4rdn?e/ers
*Mode: I = integer, R = real, D = decimal, A = alphabetic
Section
75
SUMMARY
Generally there are two approaches to sorting with
your 1130:
1. Avoid sorting
2. Write a sort program
The ways in which you can avoid sorting are:
1. Maintain multiple copies of your files.
Subsections
50
I
00
Page
01
2. Maintain multiple copies of your index, if an
index exists.
3. Sort offline.
If you decide that sorting is necessary, many
techniques are available. The methods available and a brief evaluation of each were given
earlier.
Section
80
Subsections
Page
I
01
00
00
Section 80: USE OF THE DISK FOR DATA STORAGE
CONTENTS
General. . . . . . . . . . . . . . . . . . . . . • . • . . . . ..
The Physical, or Hardware, Structure
of the Disk ... ~. ..... .. ...... ....... ..
The Disk as Seen by the FORTRAN
Programmer . . . . . . . . . . . . . . . . . . . ... . . ..
The Interrelationship of the Physical
and Logical Structures ................
The DEFINE FILE Statement. . .... ..
The *STOREDATA and *FILES Cards..
80.01.00
80.10.00
80. 20. 00
80.30.00
80.30.10
80.30.20
Record Lengths and Sector Utilization..
A Trick to Get Long Records
and/or Better Packing .............
Computing Record Length. . . . . . . . . . . . .
Shortening Record Length . . . . . . . . . . . ..
Some Examples of Disk File Setup .....
Example 1 .......................
Example 2 .......................
Example 3 .......................
80.40.00
80.40.10
80.50.00
80. 60. 00
80.70.00
80.70.10
80.70.20
80.70.30
Section
80
GENERAL
To make effective use of your disk storage capability,
you need to know the way the disk is organized and
the way your data will be set up on it. This section
deals exclusively with the use of the disk as a data
storage device. Although it is desirable (and often
necessary) to store programs and subprograms on
the disk, these normally present little difficulty,
since the 1130 Monitor system handles most of the
details involved.
Subsections
Page
I
01
01
00
The way in which the disk is used can significantly affect:
1. The amount of data that can fit into the available disk space
2. The running speed of programs using disk
data files
3. The basic practicality of many jobs. (An
improperly organized disk file can make the space
and time requirements of some jobs appear excessive,
w hen in reality they need not be. )
Section
80
Subsections
Page
I
01
10
00
THE PHYSICAL, OR HARDWARE, STRUCTURE OF
THE DISK
Each IBM 2315 disk cartridge contains 512,000 words
organized into 200 cylinders of eight sectors each;
a sector, in turn, contains 320 words (see Figure
80.1). This is a very rigid organization dictated by
the basic design of the 1130.
A word
•
A sector,
320 words
+ address
Read-write
heads
A cylinder,
2 tracks,
8 sectors
An entire cylinder (eight sectors) is accessed by
one setting of the disk read/write heads. If you wish
to read or write from a cylinder other than the one
at which the heads are now set, the disk arm must
be moved to the new cylinder. The disk mechanism
moves the arm directly from the old position to the
new position in steps of one or two cylinders. (It
does not return to a "home" position first, as some
other disk units do.) Both single steps and double
steps take the same length of time: 15 milliseconds
(.015 seconds). To move nine cylinders, you need
four 2-cylinder moves (4x15 or 60 milliseconds)
plus one I-cylinder move (15 milliseconds) -- a
total of 75 milliseconds. A move of ten cylinders
takes the same amount of time -- five 2-cylinder
moves (5x15 or 75 milliseconds). Figure 80.2 shows
some representative arm movement times.
Move This
Many Cylinders
Figure 80.1. Disk storage definitions
Stabilization
Time
Average
Rotational
Delay Time
Read
or Write
Total
0
20
10
30
15
25
20
10
70
30r 4
30
25
20
10
85
5 or 6
45
25
20
10
100
1500
25
20
10
1555
None
1 or 2
A cartridge,
200 cylinders
512,000 words
1600 sectors
Seek
Time
199 or 200
(maximum)
Figure 80.2.
°
Section
80
THE DISK AS SEEN BY THE FORTRAN
PROGRAMMER
When programming in 1130 FORTRAN, the disk
appears to be an entirely different device than the
one just described. It consists of a data area which
can be subdivided into any number of files, whose
physical size, symbolic names, and symbolic numbers have been determined by you.
You may further subdivide each file into some
number of equal-size blocks known as records. You
choose the size of the record, and each record has
a symbolic record number, starting with 1.
Subsections
20
I
00
Page
01
Within the record you can place fields, which may
be real, decimal, or integer numbers, oralphameric
data.
This is an extremely flexible system, as opposed
to the rigid subdivisions and addresses of the actual
hardware. It is still one and the same disk, however, and you must have a good knowledge of both
systems to use the disk effectively. This section
presents the basic guidelines by which you can relate
these seemingly diverse systems:
The physical, or hardware, system
The logical, symbolic, or software system
Section
80
Subsections
Page
I
01
30
10
THE INTERRELA TIONSIDP OF THE PHYSICAL
AND LOGICAL STRUCTURES
The DEFINE FILE Statement
For every data file you wish to access on the disk,
there must be a DEFINE FILE statement in your
FORTRAN program specifying certain details. A
typical DEFINE FILE statement is
DEFINE FILE 47(400,85, U,NEXT)
which indicates a file numbered 47, having 400 records of 85 words each. The U is always required
and specifies an unformatted record. NEXT is the
name of an integer variable that will always be set
to the record number of the next record in the file,
a number between 1 and 400. For example, if you
have just given the command
READ (47'K) A, B, I,J
where K was 96, NEXT will equal 97, the record
number of the next record. The incrementing of
NEXT occurs automatically and you may choose to
ignore it completely. In this case, you are addressing
your file by the symbol K, doing your own manipulation of K, and not using NEXT at all. If you wish to
read the next record, you can say either
READ (47'NEXT) A, B, I, J
or
K=K+1
READ (47'K) A, B, I, J
An 85-word disk record allows three records per
sector (Figure 80.2), so that your file of 400 records
will require 134 sectors (the exact answer, 133 1/3,
must be adjusted upward to the next higher whole
number).
(If your record length could somehow be shortened
to 80 words, you could place four records per
sector, reducing the sector requirement from 134 to
100, a substantial savings -- see 80.40.00. )
If you do not want to save this data file for use by
a subsequent program, the DEFINE FILE statement
is the only place you need reference it.
The DEFINE FILE statement specifies a mixture
of physical (actual) and logical (symbolic) subdivisions:
File number (symbolic)
Number of records (symbolic)
Number of words per record (actual)
Cylinders, sectors, and fields are nowhere mentioned.
The READ (or WRITE) statements specify only
symbolic designations:
File number (symbolic)
Record number (symbolic)
Field names (symbolic)
Section
80
The *STOREDATA and *FILES Cards
In some programs, the DEFINE FILE statement is
all that is required to specify the details of a data
file. The file is placed in Working Storage (WS) ,
and records may be read or written by that program
and/ or its subprograms.
If, on the other hand, you have a data file that is
to be used by more than one program, you must do
more than just specify it in a DEFINE FILE statement. You must get it out of Working Storage (WS)
and into the User Area (UA) or Fixed Area (FX),
where 'it will be protected from accidental destruction. Working Storage is true to its name: it is
strictly a work area. Data placed in WS may still
be there when it is needed; then again, it may not,
since the IBM compilers, DUP, and other programs
all use WS.
Working with data files in the User Area or Fixed
Area requires the use of two additional cards: the
*STOREDA TA card and the *FILES card.
The *STOREDA TA card is used first to create an
entry in the LET or FLET, specifying the name,
location, and size of your data file. In this case
the *STOREDATA card, despite its name, does not
really store your data; actually, your data has not
even been written yet.
In the preceding example (file 47 -- 400 records
of 85 words each, requiring 134 sectors) you must
run a disk utility job
Subsections
30
I
Page
20
01
3. The *STOREDATA card contains mixed type
information -- both actual (number of sectors) and
symbolic (file name and cartridge identification
number).
At this point you have run the *STOREDATA job,
specifying certain data about the file named PAYRL,
and compiled your FORTRAN program referencing
the file numbered 47. How, when, and where can
you tell the 1130 that these two files are one and the
same?
How? With the *FILES card, which in this case
would read
123 45 67 89 1011 1213 1415 1617 1819 2021 2223 2425 2627 2829 30~1 3233 3435 ~37 3839 140 41 42
r!f 1/
E~
147
,&4
3~45
ylKL I? ~17)
When and where? This depends on the format (DSF
or DCI) of your program. If the program is in DSF
format, you must place the *FILES card after the
execute card every time you execute the program.
12 3 4 567 89 10 II 1213 1415 1617 1819 2021 2223 2425 2627 2829 3031 3233 3435 3637 3839 14O~1
II vo~
/1 P< Elf
;:It //. Its I( 4!7
2~*445
II
p~
Y~L lzt? 67/
12 3 4 567 8 9 10 II 1213 14 15 1617 1819 2021 2223 2425 2627 2829 3031 3233 3435 3637 3839 401 42 3 ~45
II 17~,ll
1/ lI;fI~
lsi.,.
74
Iws
WA
I4IY fI?/.
0/ ~4 19 Gl7
19 ~I
If the program is to be built into core image format
(DCI) , the *FILES card must be placed after the
*STORECI card
which sets aside 134 sectors in the User Area (UA)
of disk cartridge 1967 and labels it PA YRL.
Notice that:
1. The information contained on the
12 3 4 5 6 78
910 II 1213 1415 1617 1819 2021 2223 2425 2627 2829 3031 3233 3435 3637 3839 14O~1 ~2 3 ~14!
1
EW!O
/ / 111./1:~L5
f51 RE II
~If 1/ ES ( 4!7 .t:1A Y!k/'
k1A
,yf4 HIE
/9 (; 7)
DEFINE FILE 47(400,85, U, NEXT)
card does not appear anywhere on the *STOREDATA
card (and vice versa).
2. The *STOREDATA job is run before there is
any data to place in the PA YRL file.
and not after the / / XEQ card.
11 9~ 7
119 617
Section
80
Subsections
Page
I
02
30
20
As mentioned earlier, data m~y be-pl-aeed in
Working Storage (WS) if you do not intend to save it -that is, if it is to be used for temporary storage
within one JOB. In fact, data will be written in WS
unless a *FILES card is used; likewise, any HEAD
commands will assume that the data is in WS if no
*FILES cards are present.
Using the *STOHEDATA and *FILES combination,
however, you have a choice as to where your data file
will be placed -- either in the User Area (UA) or
Fixed Area (FX). In most cases it does not matter
which is chosen, since both areas are safe from
accidental destruction. The main difference is
that files in the Fixed Area are in a fixed position
and will not be moved about as other files and programs are deleted.
This option is exercised by the characters
punched in columns 17 and 18 of the *STOHEDA TA
card -- UA indicating User Area, FX indicating
Fixed Area. Columns 13 and 14 always contain
WS, since the *STOHEDATA always takes some
number of sectors from WS and adds them to UA
or FX.
Note that there is no Fixed Area on a disk cartridge unless you have defined one with a *DEFINE
FIXED AREA card.
Section
80
RE CORD LENGTHS AND SECTOR UTILIZATION
Remember, the disk is physically composed of
sectors, each containing 320 words. A symbolic
record may not cross the boundary between two
physical sectors; in other words, a record must
lie entirely within one sector of 320 words. This
means that a record cannot exceed 320 words in
length. (Actually, it is possible to have records
longer than 320 words, using a trick covered in a
later subsection.) It does not mean that only one
record may occupy a sector; it is possible that
many records will be placed on one sector. For
example, if your record size is twelve words, you
may place 26 records onto each sector (26x12 = 312
words), with eight words (320-312) words remaining.
These eight words will not be used for two-thirds of
the 27th reco.rd, since that would violate the rule
spelled out above. The remaining eight words will
not be used, and are inaccessible to the FORTRAN
programmer.
It goes without saying that you will gain the most
efficient use of your disk if you utilize all 320 words
of every sector. As the previous example shows,
however, this may not always occur. Figure 80.3
shows the relationship between record size and
sector utilization.
Clearly, certain record lengths result in very
poor disk utilization. Take a 65-word record, for
example. It will allow four records per sector,
using 4x65 or 260 words, but leaving the remaining
60 words (about 20% of the sector) unused. On the
other hand, if you could reduce the length of that
record by one word, to 64, you could fit five records
in a sector, using 5x64 or 320 words, and wasting
none.
Inefficient use of the disk can have two major
effects on your overall system:
1. A given number of records may require more
space than is available on the disk. If you have 800
employee records at two per sector, you need 400
sectors or 50 cylinders, fully 25% of the disk. If
you could fit three records per sector, your total
sector requirements would drop to 234, or 30
cylinders. It is entirely possible that there are 30
cylinders available on a particular disk, but not 50.
Subsections
Page
I
01
40
00
In this case you either have to abandon the job, delete
something else from the disk, or shorten the record
size.
2. Even if 50 cylinders are available, you cannot escape the fact that you are using them inefficiently. If your 800 employee records are spread
out over 50 cylinders, rather than 30, you will spend
proportionately more time in disk arm movement.
Your records will be 67% further apart, and your
disk arm seek time will be about the same percentage greater.
Thus you have two incentives to make your disk
records as short as possible. Several techniques
for doing so are given in the subsection 80.60.00.
For long records (46 words or more), you should
inspect your record size to determine whether it is
at or slightly above a boundary, or break point -46, 54, 65, 81, 107, or 161 words. (See Figure
80.3.) If this is the case, it is worth considerable
effort to shorten this record enough to increase the
"packing factor" by one.
For medium records (19 to 45 words in length) the
record size is always near a boundary or break point,
so the packing factor can be increased by one or two
with a small reduction in record length. With records
of this length, however, it becomes more difficult
to find ways to shorten the records.
For short records (9 to 18 words in length), even
greater improvements are theoretically possible,
but are proportionately more difficult to obtain.
NOTE: When shortening disk record lengths,
always keep future needs in mind.
Record
Length
Record
Length
Records
per Sector
Record
Length
Records
Record
Records
per Sector
Length
per Sector
320
10
32
19 - 20
16
41 - 45
160
11
29
21
15
46- 53
54- 64
106
12
26
22
14
80
13
24
23 - 24
13
65 - 80
64
14
22
25 - 26
12
81 -106
53
15
21
27 - 29
11
107 - 160
45
16
20
30- 32
10
40
17
18
33- 35
35
18
17
36 - 40
Figure 80.3.
161 - 320
cannot exceed 320
Records
per Sector
Section
Subsections
Page
I
01
40
80
10
A Trick to Get Long Records and/or Better
Packing
If you have records exceeding 320 words in length,
or records of a length that yields very poor packing,
you may wish to employ a trick, or, more properly,
an unorthodox usage of FORTRAN. This usage takes
advantage of the fact that an 1130 FORTRAN READ/
WRITE I/O list will be satisfied, regardless of the
FORMAT or DEFINE FILE statement.
For example, if we say
DIMENSION ITEMS(500)
READ (6'N) ITEMS
500 ITEMS will be read from the disk, starting at
record number N. It would not matter if the statement:
DEFINE FILE 6(100,100, U, NEXT)
were used, indicating 100-word records. In fact,
no matter what the DEFINE FILE statement contains,
the entire ITEM array will be read,whether it exceeds 320 or not.
The DEFINE FILE statement has one effect, however, in that it still defines the length of the "defined"
record at 100 words. Reading the 500-word array
merely means that we have read five "defined"
records. If N were 100, you would have to increment
it by five to read the next 500 words or block of
five 100-word records.
The DEFINE FILE statement, then, must define:
1. A file that contains enough space to hold all
the data to be placed in it
2. A record length less than 320
3. Preferably, a record length evenly divisible
into 320 -- that is, 320, 160, 80, 64, 40, 32, 20,
16, 10, 8, 5, 4, 2, 1.
To illustrate, suppose you have a file containing
100 records, each with 400 words. Since
DEFINE FILE 1(100,400, U, N)
is not allowable, you could alternately specify
DEFINE FILE 2(200,200, U, N)
DEFINE FILE 3(400,100, U, N)
DEFINE FILE 4(800,50, U, N)
DEFINE FILE 5(500,80, U, N),
etc.
Note that all four files fulfill the first two rules:
same number of words as file number 1 (40,000) and
record length less than 320. However, only FILE 5
meets the third rule; 80 is evenly divisible into 320,
while 200, 100, and 50 are not.
The reason for the third rule should be selfevident in light of the previous material in this
section:
• The FILE 2 combination (200, 200) results in
only one record per sector, with 320-200 or 120
words on each wasted. Total file size would be
200 sectors.
• FILE 3 (400, 100) gives three records per
sector, with 320 -3 x 100 or 20 words wasted. Total
file size is 400/3 or 134 sectors.
• FILE 4 (800, 50) yields six records per sector,
with 320 -6 x 50 or 20 words wasted. Total file
size is also 134 sectors.
• FILE 5 (500, 80) results in four records per
sector, with 320 -4 x 80 or no words wasted. Total
file size is 500/4 or 125 sectors.
To implement this trick, you need change only
the DEFINE FILE statement and the incrementing/
decrementing logic in existing programs. For
example, if you have a file that formerly contained
400 records of 196 words each:
DEFINE FILE 6 (400, 196, U, NEXT)
you now realize that it will use each sector quite
inefficiently. Therefore, you choose instead to
use
DEFINE FILE 6 (1600, 50, U, NEXT)
which replaces the old 196-word record with four
50-word records. (In addition to better packing,
you gain four words in each record.) In the body of
your program, where you coded
N=N+1
READ (6'N) data
you use instead
N=N+4
and so on throughout the program.
Where you use the automatically incremented
parameter NEXT
READ (6'NEXT) data
you need do nothing; NEXT will automatically reflect
the number of defined records that have been processed, and will be incremented by 4 rather than 1.
Section
80
COMPUTING RECORD LENGTH
Once you have decided what data will be included in
your disk record, you may easily calculate the
length of the record by listing the fields in the record,
totalling the number of real fields (called R), the
number of integer fields (called I), and using the
table below to determine the number of words:
*EXTENDED
PRECISION
Card Used
No
Precision
Card Used
*ONE
WORD
INTEGERS
Card Used
WORDS =
(3xR) +I
WORDS =
(2xR) +I
No
Integers
Card Used
WORDS =
(3xR) +(3xI)
WORDS =
(2xR) +(2xI)
Subsections
50
I
00
Page
01
In the case of fields comprising the items of an
array (often alphameric data), the number of items
is the size of the array. For example, if you have
a field conSisting of a 16-character name, placed
two characters per word (A2 format) in the array
NAME, this will count as eight items rather than
one, when you are calculating 1.
The task is simplified by the fact that *ONE
WORD INTEGERS should always be used, reducing
all integers to one word per field. Except in very
unusual cases, you should compile all of your programs using the *ONE WORD INTEGERS control
card.
Section
80
Subsections
Page
I
01
60
00
SHORTENING RECORD LENGTH
The following suggestions will help you shorten the
length of disk records. The first three should be
taken regardless of record length, since they represent good programming practice and involve little
or no effort. Suggestions 4-7 involve more programming effort and core storage. You must determine how much effort it is worth to gain more space
on the disk.
1. First and foremost, each item in the disk
record should be inspected to determine whether it
really must be in this record. Can it be eliminated
entirely, or placed in a separate file?
2. You should decide whether standard or extended precision should be used. The decision is
usually based on other considerations; extended
precision is normally used, but it does no harm
to re-ask this question.
3. You should make certain that the *ONE WORD
INTEGERS control record is included when compiling
all programs. If not, each integer will occupy two
or three words, depending on the use of standard or '
extended precision.
4. Each real (floating point) field should be
studied with an eye toward converting it to integer
mode. Remember, in most cases integers require
only one word; real fields, three words. Integers
are limited to a magnitude of 32767, but many items
in your application may never exceed this limit,
which may be thought of as
32767
327.67
3.2767
units, pieces
dollars, hours, percent
pay rate, etc
where the decimal points are implied and handled
by you. Some typical items that lend themselves
to such treatment are:
• Discount and interest rates
• Prices or price differentials
• Inventory -- quantity on hand, quantity on
order, etc.
• Payroll -- savings bond deduction, city and
state taxes, miscellaneous deductions
5. Alphabetic data should be placed on the disk
with two characters per word (A2) rather than one
(AI). In many cases, data (numeric and alphabetic)
will be read from a card using Al format (one character per word) for later processing with the Commercial Subroutine Package. Before this data is
written on the disk, it may be compressed into
two-characters-per-word format (A2) , using the
PACK subroutine supplied with CSP. Typical items
in this category include names and addresses, descriptions, Social Security numbers, etc.
6. If necessary, three alphabetic characters can
be placed in one word for disk storage. This can be
done by subroutine that involves a table of 40 EBCDIC
codes and a packing/unpacking formula. Only 40
characters are allowed -- for example:
0123456789ABC .................... XYZb-.,
where b signifies a blank.
If you have just read the three characters B2(called LTRl, LTR2, and LTR3 respectively) from
a card with Al format, the subroutine can look up
their positions in the table and find that:
LTRl, a B, is 12th
LTR2, a 2, is 3rd
LTR3, a -, is 38th
Then, using the formula
INA3
or INA3
= LTR3
= 38
+ 40*LTR2+ (LTRI-20)*1600
+ 40*3 + (12-20) * 1600
the subroutine obtains -12642.
This is a unique representation of the three characters B2-, and can be placed on the disk as one
word.
To decode after reading from the disk, the subroutine manipulates INA3 to obtain LTRl, LTR2,
and LTR3:
I - I (32,000 + INA3)/1600 if negative
2
LTR - I INA3/1600 + 20
if positive - 1
LTR2 = (INA3 - 1600 * LTRl-20)/40 = 3
LTR3 = (INA3 - 1600 * (LTRI-20) - 40*LTR2) = 38
Looking up these three codes from the same table,
you may return to Al format.
I-
Section
80
7. In many cases, several values may be combined into one word. For example, in a payroll file,
you might have four different variables:
IE (Exempt or nonexempt)
1 = EXEMPT
2 = NONEXEMPT
MSC (Marital Status Code)
1 = SINGLE
2 = MARRIED
MORF(Male OR Female)
1 = MALE
2 = FEMALE
NDEP(Number of DEPendents)
o through 99
One way to compress these four items into a fivedigit word (called KODE) is:
I5
Digit
1
2
3
Description
Exempt
or
nonexempt
Marital
status
code
Male
or
female
Number
of
dependents
IE
MSC
MORF
NDEP
Variable
Name
4
For example, if KODE = 22103, this employee is:
• Nonexempt (digit 1 is 2)
• Married (digit 2 is 2)
• Male (digit 3 is 1)
• With three dependents (digits 4 and 5 are 03)
Subsections
Page
I
02
60
00
To compress these values before writing on the
disk, all you need do is
KODE= (IE*10000)+(MSC*1000)+MORF*100)+NDEP
To decompress the word KODE after reading it
from the disk, you could use a function similar to
the one below, called NDIG
FUNCTION NDIG (N, IT)
DIMENSION IZ (6)
DATA IZ/32767, 10000, 1000, 100, 10, 1/
NDIG = IT/IZ(N+1)-IT/IZ(N)*10
RETURN
END
Using this function
IE
= NDIG (1, KODE)
= NDIG (2, KODE)
MSC
MORF = NDIG (3, KODE)
NDEP
= NDIG (4, KODE) *10+NDIG(5, KODE)
etc.
In this case, such a packing technique will save
three words on each disk record (by using one word
rather than four). This mayor may not be worth
the added programming involved, the additional
core storage required for the function, and the
packing/unpacking coding.
Don't forget that KODE is an integer, and its
magnitude is limited to 32767. To be safe, you
should plan for a limit of 29999 for such compressed
words.
Section
80
Subsections
Page
I
01
70
10
SOME EXAMPLES OF DISK FILE SETUP
Example 1.
A program reads a deck of cards and builds two
large tables of data. The individual data items are
of no particular interest; however, after the last
input card has beenprocessed, you want to summarize the data tables and print a summary report.
The data tables required are so large that they cannot fit in core storage; therefore, you decide to use
the disk as an extension of core storage to accumulate the two tables.
After this job has been run, you have no need for
the data, so you decide to keep it in Working storage
(WS).
Two files are required, numbered 1 and 2, and
any disk cartridge may be used. Each of the two
files contains 100 records of 150 words each.
Since the files are of a temporary nature and
will remain in Working Storage, neither a *STOREDATA card nor a *FILES card is required; consequently the files have no names, only numbers.
The next two exhibits show how the Disk File Layout Worksheet would be filled in for these two files.
Section
80
Subsections
70
I
DISK FILE LAYOUT WORKSHEET
Description
of File
Cartridge
10 Number
File
Number
*FILES
OR
*FILES
If ID number is not used
Next
Indicator
Number of
Words per
Record
DEFINE FILE
)
Record
Records
Length
per Sector
Recore!
Length
Records
per Sector
Record
Length
Records
perSectol
320
10
32
19-20
16
41 - 45
29
21
46 - 53
26
22
54 - 64
13
24
23 - 24
13
65 - 80
22
25 - 26
12
81 - 106
21
27 - 29
16
20
30 - 32
17
18
33 - 35
107 - 160
10
161-320
cannOt exceed 320
36 - 40
Number of
Records per
Sector
File to be
placed in:
,
Records
per Sector
·15
18
WS
Record
Length
UA
FX
Don't need
*STORE DATA
*STORE DATA
WS
13 14
17 18
21 22 23 24 25
27 28 29 30
37 38 39 40
File
Name
Number of
Sectors
Cartridge
10 Number
10
Page
02
Section
80
Subsections
Page
I
03
70
10
DISK FILE LAYOUT WORKSHEET
Description
of File
7/18L£ O..c SALES ,By 4RfA
Cartridge
ID Number
File
Number
OR
Next
Indicator
Number of
Words per
Record
wiLl
/50
)
DEFINE FILE
Record
Length
Records
Records
per Sector
Record
Length
per Sector
32
19-20
16
29
21
15
per Sector
Record
Length
320
10
160
11
106
12
26
22
13
24
23 - 24
80
64
Record
Length
46 - 53
54 - 64
13
65 - 80
81 - 106
22
25 - 26
53
15
21
27 - 29
107 - 160
45
16
20
30 - 32
161 - 320
40
17
18
33 - 35
cannot
36
18
17
36 - 40
Number of
File to be
placed in:
Records
per Sector
41 - 45
exc~ed
320
Number of
Records per
Sector
card
*STORE DATA
13 14
17 18
21 22 232425
27 28 29 30
37 38 39 40
File
Name
Number of
Sectors
Cartridge
ID Number
Section
80
Subsections
Page
I
04
70
DISK FILE LAYOUT WORKSHEET
Description
of File
Cartridge
ID Number
File
Number
*FILES
OR
Next
Indicator
*FILES
1/llzl
Number of
Words per
Record
DEFINE FILE
Record
Length
Records
per Sector
Record
Records
Record
Records
Length
per Sector
Length
per Sector
320
Record
Length
10
32
19 -20
16
160
11
29
21
15
106
12
26
22
14
80
13
24
23- 24
13
65- 80
22
25 - 26
12
81 - 106
53
15
21
27 - 29
11
45
16
20
30- 32
10
40
17
18
33- 35
35
18
17
36-40
Number of
File to be
placed in:
Records
per Sector
46- 53
54-64
107 -160
161 - 320
cannot exceed 320
Number of
Records per
Sector
card
*STORE DATA
13 14
17 18
21 22 232425
27 28 29 30
37 38 39 40
File
Name
Number of
Sectors
Cartridge
ID Number
10
Section
80
Subsections
Page
I
01
70
20
Example 2.
A payroll and project cost accounting system involves four disk data files:
EMPS
-
PROJ
-
DDESC -
SUBT
-
300 employee records with 60 words
per record.
100 project records with 20 words
per record.
20 records of 18 words each, containing some alphabetic information
for each of 20 departments.
20 records of 60 words each, containing an array of subtotals of
department worked for vs department
charged to. This is a temporary
file used only as an extension of
core storage, not saved from job to
job.
Assume you have only one disk drive and don't
care which disk cartridge is mounted. (You really
do, but you, rather than the Monitor, will make
sure the correct disk is being used. )
With this basic data, you can fill in the Disk File
Layout Worksheets and punch the necessary cards.
Note that file 9 (SUBT) does not need a *FILES OR
*STOREDATA card, since it is not to be saved
from one job to another. It does require a DEFINE
FILE card.
Section
80
Subsections
Page
I
02
70
DISK FILE LAYOUT WORKSHEET
Description
of File
EA4?LCJYEE
RECORDS
Cartridge
10 Number
File
Number
*FILES
OR
Next
Indicator
Number of
Words per
Record
If 10 number is not used
*FILES
INl
60
DEFINE FILE
Record
Length
per Sector
46 - 53
54 - 64
65 - 80
107 - 160
161 - 320
cannot exceed 320
40
36
Number of
Filetobe
placed in:
18
17
36-40
Number of
Records per
Sector
WS
+
Don't need
*STORE DATA
card
*STORE DATA
13 14
17 18
21 22 23 2425
27 28 29 30
37 38 39 40
File
Name
Number of
Sectors
Cartridge
10 Number
20
Section
80
Subsections
Page
I
03
70
20
DISK FILE LAYOUT WORKSHEET
Description
of File
/VIAsrcR PROJECT COSTS
121Rlo Idl
File
Number
Cartridge
ID Number
*FILES
OR
If ID number is not used
*FILES
Next
Indicator
Number of
Words per
Record
22
DEFINE FILE
Record
length
Records
per Sector
41 - 45
46- 53
54 -64
65-80
81 -106
107 - 160
161-320
cannot exceed 320
18
Number of
File to be
placed in:
17
36-40
Number of
Records per
Sector
,
WS
Don't need
*STORE DATA
card
*STORE DATA
13 14
17 18
21 22 232425
27 28 29 30
37 38 39 40
File
Name
Number of
Sectors
Cartridge
10 Number
Section
80
Subsections
Page
I
04
70
DISK FILE LAYOUT WORKSHEET
Description
of File
File
Number
*FILES
OR
*FILES
Next
Indicator
Number of
Words per
Record
/8
DEFINE FILE
Record
Length
~~s
Recore!
Length
Records
per Sector
320 \
10
160
11
per Star
106
80
64
53
45
40
35
Number of
File to be
placed in:
~
13
Length
Records
per Sector
32
19 - 20
16
29
21
26
22
24
23 - 24
Record
22
25 - 26
1
21
27 - 29
16
20
30- 32
17
18
33- 35
17,/
36 - 40
11"",8
Record
Length
Records
per Sector
46 - 53
13
65 - 80
12
&1 - 106
107 - 160
10
161-320
cannot exceed 320
Number of
Records per
Sector
WS
+
Don't need
*STORE DATA
card
*STORE DATA
13 14
17 18
21 22 232425
27 28 29 30
37 38 39 40
File
Name
Number of
Sectors
Cartridge
ID Number
20
Section
80
Subsections
Page
I
05
70
20
DISK FILE LAYOUT WORKSHEET
Description
of File
SUB rOTA LS
File
Number
b5k/18ITI
9
Cartridge
ID Number
/
*FILES
OR
If I D number is not used
*FILES
Next
Indicator
Number of
Words per
Record
DEFINE FILE
File to be
placed in:
card
*STORE DATA
13 14
17 18
21 22 232425
27 28 29 30
37 38 39 40
File
Name
Number of
Sectors
Cartridge
ID Number
Section
80
Example 3.
This is the same job as in example 2, except
that two disk drives are now available and you are
going to be more careful about which disk cartridge
is mounted on which drive unit:
DRIVE 0
DRIVE 1
CARTRIDGE ID 0012
CARTRIDGE ID 0019
Subsections
70
I
Page
01
30
File SUBT, since it is in WS, really does not need
a name (or a *FILES or *STOREDATA card). How,
then, can you tell the 1130 Monitor on which disk
drive it should be placed? Again, with the II JOB
card. Columns 41-44 should contain the cartridge
ID number of the disk to be used for Working
storage, in this case 0019.
The special II JOB card
12 3 4 5 6 78 910 1112 1314 1516 1718 1920 12223 2425 2627 2829 3C~1 3233 3435136[37 3139 4C1 ~2 3
WS
UA
FX
EMPS
WS
SUBT
UA
FX
II j•./Ilil:3
bit:
IZ 00 1'1
~
1617'
PROJ
DDESC
First, you have decided that cartridge 0012 will
be on drive 0 and cartridge 0019 on drive 1. How
is this communicated to the Monitor? It is done
with the II JOB card, which must be punched
12 3 4 56 78 910 1112 1314 1516 1718 1920 2122 2324 2526 2728 2930 132 3334 3536 3738 3940 ~1~2 344i4!
1//
j/lill
k::Ik:' 12 l"lv 1'/
must be used when running the DUP *STOREDATA
jobs and when executing the programs that use
these files. Needless to say, the disk cartridges
should be placed in the proper disk drive units.
The remaining three files (EMPS, PROJ, AND
DDESC) are handled in a different manner. Since
they are to be in the UA, they do require *FILE S
and *STOREDATA cards, which contain a field
for placing the cartridge ID number. These are
shown on the Disk File Layout Worksheets following.
Section
80
Subsections
70
I
30
Page
02
DISK FILE LAYOUT WORKSHEET
Description
of File
EA4PLOYEE
Cartridge
ID Number
File
Number
101011 121
*FILES
OR
Next
Indicator
If I D number is not used
*FILES
IN)
Number of
Words per
Record
)
DEFINE FILE
Record
Length
Record
Records
perSeclor
Record
Length
Records
per Sector
Length
per Sector
320
10
32
19 - 20
16
29
21
46 - 53
26
22
54 - 64
160
106
12
80
13
64
53
Record
23 - 24
13
65 - 80
22
25 - 26
12
81 - 106
21
21 - 29
45
16
20
JO - 32
40
11
18
33 - 35
=Vi
18
11
J6 - 40
Number of
File to be
placed in:
Length
perSecfor
41 - 45
10
s:>
161 - 320
cannot exceed 320
Number of
Records per
Sector
WS
+
Don't need
*STORE DATA
*STORE DATA
13 14
17 18
21 22 23 24 25
27 28 2930
37 38 39 40
File
Name
Number of
Sectors
Cartridge
ID Number
Section
80
Subsections
70
I
DISK FILE LAYOUT WORKSHEET
Description
of File
/WA'STc/2
PROJECT COSTS
Cartridge •
10 Number
File
Number
*FILES
OR
*FILES
Next
Indicator
Number of
Words per
Record
22
)
DEFINE FILE
Record
Length
Records
Record
Records
Length
Records
per Sector
Record
per Sector
Length
per Sector
Record
320
10
32
19 - 20
16
41 - 45
160
11
29
21
15
46- 53
106
12
26
:;t:2
14,)
54 - 64
80
13
24
23 - 24
13
65 - 80
Length
64
14
22
25 - 26
12
81 -106
53
15
21
27 - 29
11
107 -160
45
16
20
JO - 32
10
40
17
18
33- 35
35
18
17
36-40
Number of
File to be
placed in:
per Sector
161 - 320
cannot exceed 320
Number of
Records per
Sector
WS
+
Don't need
*STORE DATA
card
*STORE DATA
13 14
17 18
21 22 23 2425
37 38 39 40
File
Name
Cartridge
ID Number
Sectors
30
Page
03
Section
80
Page
Subsections
70
I
04
30
DISK FILE LAYOUT WORKSHEET
Description
of File
DESCR/PT/O/t/S
OF LJEP4RTAdEA/TS
Cartridge
ID Number
File
Number
*FILES
OR
If I D number is not used
*FILES
Next
Indicator
Number of
Words per
Record
/6
DEFINE FILE
Record
Length
per Sector
ecord
Length
320
160
106
12
80
Record
Records
per Sector
Records
Length
per Sector
32
19 - 20
16
29
21
15
26
22
13
24
23 - 24
22
25 - 26
53
15
21
27 - 29
45
16
20
30- 32
64
40
Record
Length
per Sector
46 - 53
54 - 64
13
65 - 80
81 - 106
107 - 160
10
161 - 320
cannot exceed 320
35
Number of
File to be
placed in:
WS
+
Don't need
*STORE DATA
*STORE DATA
13 14
17 18
21 22 23 2425
27 28 29 30
37 38 39 40
File
Name
Number of
Sectors
Cartridge
ID Number
Section
80
Subsections
Page
I
05
70
30
DISK FILE LAYOUT WORKSHEET
Description
of File
SUBTOTALS
Cartridge
ID Number
File
Number
*FILES
OR
If I D number is not used
*FILES
Next
Indicator
Number of
Words per
Record
Number of
DEFINE FILE
Record
Length
Records
per Sector
Record
Records
Record
Length
per Sector
Length
per Sector
320
10
Record
Length
32
19 - 20
16
29
21
15
46 - 53
12
26
22
14
54 - 64
14
22
25 - 26
12
81 - 106
15
21
27 - 29
Records
per Sector
23 - 24
16
20
30 - 32
17
18
33- 35
18
17
36 - 40
107 - 160
10
161 - 320
cannot exceed 320
Number of
Records per
Sector
File to be
placed in:
card
*STORE DATA
13 14
17 18
21 22 23 2425
File
Name
27 28 29 30
37 38 39 40
Number of
Sectors
Cartridge
ID Number
Section
85
Subsections
Page
I
01
00
00
SECTION 85: DISK DATA FILES -- ORGANIZATION
AND PROCESSING
CONTENTS
General .......•.•....••••..•........
Organization. . . . . . . . . . . . . . • •• . • . • • . . .
General ..•.•..••..........••.....
Pure Sequential. . . . . . . • • . • • •• ••• . . .
Searching a Pure Sequential File
Adding Items to the File
Indexed Sequential .••.•••••••••....
Choosing an Index Step Size
Building the Index
Searching the Index
Maintaining the Index
Adding Items to the File
85.01.00
85.10.00
85. 10. 01
85.10.10
85.10.20
Direct, or Random
Organizations .....................
Direct
Computed Direct
Partitioned Direct
Summary
Processing .......................•..
The Interaction of Organization and
Processing ........••.......•....•...
Introduction. . . . . .... ••. . . . .. . . . . . .
Choosing the Organization..........
85. 10. 30
85.20.00
85.30.00
85.30.01
85.30.10
Section
85
GENERAL
Data records should be filed according to a plan.
The relationships between file organization and data
processing should be carefully considered before
this plan is chosen. With a disk, both storage and
processing can be accomplished by either of two
basic methods - sequential or direct (or random).
Thus the following four storage-processing approaches are available:
Sequential processing of sequentially organized
data
Random processing of sequentially organized
data
Subsections
Page
I
01
01
00
Sequential processing of randomly organized
data
Random processing of randomly organized
data
The first two are the most commonly used approaches. The third and fourth are of limited use
in most applications. However, the fourth offers
some benefits (in selected applications), particularly
when the data files undergo frequent additions and
deletions, or when most of the transactions must be
processed randomly.
Section
85
Subsections
10
I 01
Page
01
ORGANIZATION
General
In a sequentially organized file, records are stored
on the disk in control key sequence, so that records
with successively higher control keys have successively higher record numbers. It is not necessary
(or customary) for the control key to be the same
number as the record number. The only requirement is that the control keys be in sequence, and in
sequential (not necessarily consecutive) locations.
Often, to narrow the search for a record in a sequential file, an index is consulted for the record
number. This index is a sequential list of the keys
of selected data file records with their corresponding record numbers. An example of a sequentially
organized data file is a telephone directory, in which
people are listed one after the other, in alphabetic
order, the control key being the last name/first
name combination, and the data being the telephone
number.
In a randomly organized file, the records are
generally stored in the sequence of their control
keys. However, a mathematical transformation of
the control key yields the record number. To find
a record in such a file, the record number is computed from the control key by using the same transformation formula. In the random approach no index
tables are required.
Section
85
Pure Sequential
In a purely sequential disk data file, your records
are placed on the disk in some logical order, with
no attempt to organize them or to keep track of
where they are placed. If a certain record is desired, the disk is searched sequentially until that
record is found.
Searching a Pure Sequential File
Searching a pure sequential file is simple, but
finding any particular record may be time-consuming
in the case of large files. (If you are processing
only a small number of records, however, the effect
on the overall running time may be slight.) If you
have a file of 1000 records, you can search for the
item with key KEYXX, using the following FORTRAN
statements:
14
DO 14 NREC=l, 1000
READ (NFILE'NREC) KEY
IF (KEY -KEYXX) 14, 77, 14
CONTINUE
77
KEYXX has been found at record NREC.
KEY is the control key on the disk record, and
KEYXX is the key you are searching for. If
KEYXX is the 608th item, you will read, check, and
get "no hit" on 607 items before reaching the 608th.
A better way to search such a file is obvious: read
every nth record until you pass the key being sought,
then back up one record at a time until you find
KEYXX.
8
66
14
77
DO 14 NREC=l, 1000, NTH
IREC = NREC
READ (NFILE'IREC) KEY
IF (KEY-KEYXX) 14, 77, 66
IREC = IREC-1
GO TO 8
CONTINUE
KEYXX has been found at record IREC.
If n is 20, you will read and check 32 records
(1, 21, 41, 61, ..... 601, 621) until you have
passed the desired item (KEYXX, the 608th). Then
13 more records in the backing-up portion of the
search (620, 619, 618, ..... 609, 608) must be
read. Here, the "skip" search has reduced your
disk reads from 608 to 45, with a concurrent drop
in processing time.
Subsections
Page
I
01
10
10
A further improvement can be made if you search
first in large increments (say 100), then, when you
pass the desired item, back up with a smaller increment (say 20) and, after passing the desired
item the second time, switch to an increment of 1.
Again, looking for the 608th item, the search will
be - 1, 101, 201, 301, 401, 501, 601, 701, 681,
661, 641, 621, 601, 602, 603, 604, 605, 606, 607,
608, which involves 20 disk reads.
All the methods shown above, however, have one
disadvantage: because they start at record number
1, the disk arm must move back to that record
each time. A more elegant search technique would
involve starting from wherever you found the last
record, rather than from the beginning of the file.
This assumes that the disk arm is still positioned
over the last record, but it will not be so pos itioned
if you have meanwhile used LOCAL or SOCAL subroutines or accessed a record in another file on the
same disk. This technique, therefore, is often
impractical.
Another technique involves the method of halving,
sometimes called a binary search. Suppose you
have a file of 1000 records and you want to find the
record whose key is KEYXX. First, halve the file
size to obtain 500, and check the 500th record. If
you do not find KEYXX there, halve the 500 to obtain
250 and, if the 500th record KEY was higher than
KEYXX, check 500-250 or 250 next; if it was lower,
check 500+250 or 750 next. The increment next
becomes 125, then 63 (62. 5 rounded upward), then
32 (31. 5 rounded upward), etc. Using the previous
example (KEYXX is the 608th item), your search
pattern would have been:
low, so
high, so
high, so
low, so
low, so
high, so
low, so
low, so
hit
500
+250
750
-125
625
- 63
562
+ 32
594
+ 16
610
8
602
+ 4
606
+ 2
608
first try
second try
third try
fourth try
fifth try
sixth try
seventh try
eighth try
ninth try
a sequence of only nine disk reads.
Section
Subsections
Page
I
02
10
85
10
Programming such a search is easy:
3
8
10
9
NREC = 0
INC = 500
INC = (INC+ 1)/2
READ (NFILE'NREC) KEY
IF (KEY-KEYXX) 8,9,10
NREC = NREC + INC
GO TO 3
NREC = NREC-INC
GO TO 3
KEYXX has been found at record NREC.
Adding Items to the File
Adding new records to a sequential file involves
some advance planning. If your employee file now
consists of 188 employee records in man number
sequence
018, 023, 067, 107, 109, ....... 667, 691, 806, 902
where should you put the newest employee, who has
just been assigned man number 098? You could
rebuild the entire file, but that might prove timeconsuming in the case of large files.
One way to handle file additions is to set up a
separate "addition area" on the disk, either as a
separate file or as a special area in the main file.
With the latter option, new employees would be
placed at the end of the file, starting with the last
record and working backward.
For example, suppose the 188 employee records
have been placed in a 200-record file. When man
number 098 is added, it is placed in record number
200; the next new man number goes in 199; and so
on.
The search programming becomes somewhat
more involved: if a man number is not found in the
main (sequential) portion of the file, the "addition
area" is searched. If it is not found in either place,
an error message is printed.
Since this added work will slow the running of the
program, the file should be reorganized periodically,
and new man numbers put in their proper places in
the sequential file.
Section
Subsections
Page
I
01
10
85
20
Indexed Sequential
Choosing an Index Step Size
An indexed sequential file is essentially the same as
a pure sequential file except that you maintain a
table or index to the file, making it eas ier to find
records. Suppose you have an inventory file containing 2500 items, with stock numbers ranging from
00001 to 28406. The stock number is kept as an
integer, and the items have been placed on the disk
in stock number sequence. In order to find an item
on the disk, you will maintain an index consisting of
the stock number of every 25th item. This will be a
FORTRAN array in core storage. It will require
2500/25 or 100 entries in the index table:
In the above example, 25 was arbitrarily chosen as
the index step size; in other words, every 25th item
in the file is recorded in the index table. What is
the best index step size? First, for convenience, it
should be an even divisor of the number of records
in the file. If it is not, it complicates programming.
Second, it should be about the same as or less than
the number of records in a cylinder. For example,
say your record size is 48 words. This allows six
records per sector, and 8x6 or 48 records per cylinder. If you have 5000 records, you can choose 40 as
your step size, making your INDEX array length
5000/40 or 125. The smaller the step size, the more
likely you are to hit the right cylinder on the first
disk arm movement. The probability that you will
find the des ired record on the first cylinder accessed
is:
INDEX (1) = 67, the stock number of the 25th
item
INDEX (2) = 103, the stock number of the 50th
item
INDEX (~ ;;; 297, the stock number of the 75th
item
1 - ((STEP SIZE-1)/ (2
* NO
RECS PER CYL»
or in this case:
INDEX (99) ;;; 28073, the stock number of the
2475th item
INDEX (100) = 28406, the stock number of the
2500th item
When it comes time to find an item on the disk,
you first look for it in the core storage array INDEX.
You probably will not find that particular item in the
INDEX array, but you can get a good idea of its
location. Suppose you have just read a card containing ITEM number 181. You look it up in the
INDEX table as follows:
INDEX (1) = 67, which is lower than 181
INDEX (2) = 103, which is lower than 181
INDEX (3) = 297, which is higher than 181
The search stops here, since it is obvious that you
have just passed item number 181 in the process of
moving from INDEX (2) to INDEX (3). Since INDEX
(2) is the 2x25 or 50th disk record and INDEX (3) is
the 3x25 or 75th disk record, you know item 181 is
between records 51 and 75.
Now resume your search for item 181, this time
on the disk rather than in core. You may start at
51 and work your way up, or at 74 and back down.
In the latter case, your program reads record 74,
checks the stock number to see if it is 181, then
reads record 73, 72, 71, 70, 69, 68, etc., down to
record 51. If 181 is on the disk and in the right
order, you will find it relatively qUickly.
1 - ((40-1)/(2x48»
or about 0.6.
In other words, with 48 records per cylinder, and
an index of every 40th record, there are s'ix chances
in ten that the desired record can be found with one
disk arm movement (seek), and four chances in ten
that a second seek and read will be reqUired. Such
a second step will take about 65 milliseconds.
If you processed 225 inventory items, this second
seek and read would add about one minute to the
total running time of the job.
If you increase your step size to 50, the size of
your index table in core drops from 125 to 100 items,
but your probability of a second seek and read increases from. 40 to .51.
On the other hand, if you decrease your step
size to 25, your index table requires 200 entries,
but your probability of a second seek drops to .25.
Section
85
Subsections
Page
I
02
10
20
Building the index
Building your index of every 25th (or 90th, or
whatever) item in your file presents no difficulty.
Option 1: Build the index at the same time that
you load the data on the disk. All you need do is to
keep a sequential number for each item (NO) and
place its item number (or stock number, or employee number) in the INDEX array at position
NO /
(ISS + 1) + 1
where ISS is the index step size. In FORTRAN,
keeping an index of every four ITEMs (1SS=4) can be
done like this:
ISS = 4
NO = 1
55 READ (card) ITEM
K = (NO-I) /ISS+l
INDEX (K) = ITEM
WRITE (file 'NO) ITEM, etc.
NO = NO + 1
GO TO 55
Tracing through this coding, you will see that in
addition to creating the data file on the disk:
The ITEM
number from
this card
first
second
third
fourth
fifth
sixth
seventh
eighth
ninth
etc.
will be placed
on this disk
record
and at this
position in
the INDEX table
1
2
1
3
1
1
2
2
2
2
4
5
6
7
8
9
1
3
When finished, the INDEX table will contain the
ITEM numbers of the 4th, 8th, 12th, 16th, etc.,
records on the disk, just as desired. The INDEX
can now be written on the disk as a separate file,
for further use.
Option 2: Create an index file after the data
records have been placed on the disk. This is
even easier, since you need only read every 4th
(or 20th, etc.) record from the disk and place its
ITEM number in your INDEX table. Because this
would be relatively slow, you would want to do it
only once, with a separate program, storing the
INDEX as a separate data file. Then, each program
using the file could read it from the disk.
Section
85
Searching the Index
Figure 85. 1.
Page
I
03
10
ITEM -- the item you are searching for
ITABL -- the name of the index table
LTABL -- the length of the index table
ISS -- the index table step size
NFILE -- the number of the file
1/ FOR
*EXTENDED PRECISION
*TRANSFER TRACE
*ONE WORD INTEGERS
*LIST ALL
*ARITHMETIC TRACE
SU8ROUTIN~ FINDM(NREC,ITEM,NFILE,ITABL,LTABL,ISS,IER)
DIMENSION ITABL(l)
IER = 1
DO 1 N = 1 , LTABL
IF ( ITEM - ITABL(N) ) 2 , 2 , 1
1
CONTINUE
C
ITEM IS LARGER THAN THE LARG~ST VALUE IN THE INDEX TABLE
IER = 2
RETURN
2
NREC = ISS * N
DO 3 N = 1 , ISS
READ ( NFILE t NREC
KEY
IF ( KEY - ITEM) 4 , 5 , 6
6
NREC = NREC - 1
3
CONTINUE
C
ITEM IS NOT IN THE FILE IN THE AREA WHERE IT SHOULD BE
4
IER = 3
5
RETURN
END
VARIABLE ALLOCATIONS
N(I ) =0000
KEY (I ) =0001
STATEMENT ALLOCATIONS
1
=0033 2
=0042
6
=005B
3
=0001
FEATURES SUPPORTED
TRANSFER TRACE
ARITHMETIC TRACE
ONE WORD INTEGERS
EXTENDED PRECISION
CALLED SUBPROGRAMS
SIAR
SIIF
SUBSC
SUBIN
INTEGER CONSTANTS
1=0004
2=0005
CORE REQUIREMENTS FOR FINDM
COMMON
0 VARIABLES
END OF
CCMPI~ATION
SDRED
SDI
3=0006
4
20
Figure 85.1 illustrates a typical method of searching an index.
You would CALL the subroutine FINDM with the
known values of:
Unlike pure sequential organization, which is
searched on the disk, indexed sequential gives an
index to search in core storage. The simplest
approach is to search the table sequentially, one
entry at a time, starting at the top. When you find
an equal-or-less-than condition, you have found
what you are looking for. The subroutine shown in
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Subsections
PROGRAM
108
4
=006A
5
=006E
Section
85
Subsections
10
I
20
Page
04
The subroutine returns:
NREC -- the record number where ITEM
may be found
IER -- an error code:
1 -- ITEM has been found on the disk.
2 -- ITEM is larger than any entry in
the index table.
3 -- ITEM is not on the disk where the
index table indicates that it
should be.
If IER is 2 or 3, the value of NREC returned is
meaningless.
For example, suppose you have an index of 150
entries, called ITABL, representing every 60th
item in an inventory file. After reading an inventory detail card containing a field called ITEM,
you want to find the inventory record for that item.
By using subroutine FINDM
CALL FINDM (NR, ITEM, NFILE,
ITABL, 150,60, IER)
you obtain, perhaps, an NR of 731 and an IER of 1,
meaning that the desired ITEM has been found, at
record 731. You can now read the inventory record
for that item:
READ (NFILE'NR) data
Maintaining the Index
When using an indexed sequential disk data file, you
must make sure that the index agrees completely
with the file. If you rearrange records in the file
without rebuilding the index, you may expect great
difficulty in locating items in the file. Rebuilding
the index is a rather simple matter, and two
methods are given in a preceding section.
The file index is typically stored on the same
disk as the file itself, and is read into core once,
at the beginning of each program that uses the file
it indexes.
Adding Items to the File
Adding items to an indexed sequential file can
be handled in much the same manner as for pure
sequential files. New records are placed in a
separate file, or at the "high" end of the main
file.
These new items will not be reflected in the
index, but this does not matter too much. The
index may be used to facilitate looking up records
in the main portion of the file, and, if an item is
not found there, it can be sought in the addition
area.
Section
85
Subsections
Page
I
01
10
30
Direct, or Random, Organizations
Computed Direct
Direct
Sometimes it is possible to take an employee
number (or part number, etc.) and modify it to
make a usable record number. For example, if
you have 300 employees with employee numbers
between 3000 and 9000, you could take this number,
NEMP, subtract 3000, divide by 20 (which is
(9000-3000)/300), and add 1:
The simplest of all organizations exists when the
record number is the same as the control key. For
example, in a payroll application requiring one
record per employee, the record number would be
the same as the employee number. If you had a
three-digit employee number, 001 to 999, you
would set up a file of 999 records:
DEFINE
FILE
1
(999,XXX, U,NEXT)
If you read an employee number from a card
77
FORMAT (14)
READ (2,77)
NEMP
you can immediately find that employee on the disk
with
or
READ (1 'NEMP) data
WRITE (1 'NEMP) data
The advantages of this scheme are obvious, but
the disadvantages may override them. In all probability, although there are 999 employee numbers,
there are not really 999 employees, so there will
be many "holes", or unused records, on the disk.
Furthermore, 999 records, if they are large, may
take up an inordinate amount of space on the disk.
Even if they do fit on the disk, they will be spread
out so far that programs using this file will run
very slowly, because of the amount of "seeking",
or disk arm movement, required.
One remedy would be to make the employee
numbers more compact. If there are 300 employees,
why not renumber them from 001 to 300? Or
renumber your customers in a billing file? Or
renumber your part numbers? Or job numbers?
Usually, this is more easily said than done, and
you can expect difficulty in convincing management
that they should change established systems just to
make it easier for you or the computer.
NREC
=
(NEMP-3000) / 20 + 1
This results in an NREC between 001 and 301. This
is compact and wastes no space; however, two (or
more) employee numbers may quite possibly result
in the same record number. These are known as
synonyms. There are many ways to handle this
problem, but they require a certain added amount
of programming and disk space.
Section
85
Subsections
Page
I
02
10
30
Partitioned Direct
Summary
The disk addressing used by 1130 FORTRAN makes
this method applicable in some cases. At one installation, there are about 150 employees, each
with a four-digit employee number. The first two
digits indicate the department number; the second
two digits are sequential numbers. The distribution
is as follows:
Each of the techniques described above has its advantages and disadvantages, as has been pointed out
earlier. Ingeneral, indexed sequential files require
more core and disk storage (because of the index)
and tend to increase processing time because of the
searching invoived. Random (direct) organizations
make for fast access, with little extra core or disk
requirements, but are usually difficult to set up
because of the synonym problem.
Dept.
No.
1
3
4
5
6
7
10
11
12
15
Maximum
No. of
Employees
5
35
10
10
30
60
10
20
20
50
250
Range of
Employee
Numbers
101
301
401
501
601
701
1001
1101
1201
1501
..
-
Number of
Possible
Employee
Numbers
110
340
420
520
650
770
1020
1130
1230
1570
10
40
20
20
50
70
20
30
30
-1.Q.
360
This user noticed that he could use this breakdown of employee numbers to advantage by setting
up ten files:
DEFINE
DEFINE
DEFINE
DEFINE
DEFINE
DEFINE
DEFINE
DEFINE
DEFINE
DEFINE
FILE
FILE
FILE
FILE
FILE
FILE
FILE
FILE
FILE
FILE
1
3
4
5
6
7
10
11
12
15
(10,X,U,Nl)
(40, X, U, N3)
(20,X, U, N4)
(20,X,U,N5)
(60,X, U, N6)
(70,X, U, N7)
(20, X, U, NlO)
(30,X, U, NIl)
(30, X, U, N12)
(70,X, U, N15)
requiring a total of 360 records to hold 250 employees. This wastes about one-third of the available
records but results in much simplified programming,
since the user can read the employee department
and man number from a card:
77 FORMAT (I2, 12)
:READ (2,77) NDEP, NEM
and access that employee with a
READ (NDEP'NEM) data
statement.
Many numbering systems fit this general type and
may lend themselves to this disk organization approach.
Section
85
PROCESSING
Just as sequential and random are two basic ways
to organize a file, they are also two ways to process
or access a file.
If you process records in the same order as that
in which they lie on the disk, you are processing
sequentially; if you process in a different order, you
are processing randomly. Thus the same two words
(sequential and random) have substantially different
meanings when used in the area of processing, since
the definition of each depends on the organization of
the file. This was not so when considering organization; a file was sequential or random depending on
Subsections
Page
I
01
20
00
the order in which control keys were placed on the
disk.
Consider the telephone directory -- a sequential
file because the control keys (names) are in alphabetic order. If you scan through the directory, from
front to back, looking for people who live on Main
Street, or for men whose first name is John, you are
processing sequentially, in the same order as the
keys.
If you are looking for the telephone numbers of
three friends -- J. DOE, P. ADAMS and L. SMITH -and you look for them in that order (not alphabetic),
you are processing randomly. On the other hand, if
you sort them into alphabetic order -- ADAMS, DOE,
and SMITH you are processing sequentially.
Section
85
Subsections
Page
I
01
30
01
THE INTERACTION of ORGANIZATION and
PROCESSING
Introduction
As you have seen, the two factors, organization and
processing, are tied together quite intimately.
Often, for this reason, it is not easy to make the
basic decision as to which combination of techniques
to use:
Sequential organization, sequential processing
Sequential organization, random processing
Random organization, sequential processing
Random organization, random processing
Actually, it is often impossible to use only one type.
You can (and, perhaps, must) process in many
sequences; but your file can have only one organization at anyone time.
Section
85
2.
Choosing the Organization
Because of the interaction between processing and
organization, there are few concrete guidelines for
the user who must make this decision. However, the
following outline will help lead the way toward one
organization or the other. The payroll application
is given as the example.
1. List the processing that must be done to this
file and the required order of inputs and outputs
(see Figure 85.2).
Required Order of:
INPUT
Application
No order
or
doesn't matter
Other
Doesn't
matter
Edit input
cards
Same as
later
process,
J
Calculations
Employee
number
.;
Payroll
register
Employee
number
,J
Payroll
checks
Employee
number
Employee
number
941 report
Name and
address
stickers
Figure 85. 2.
,J
,J
,J
J
Page
I
01
30
10
How many different sequences are there?
a. None. No one really cares what the processing sequences are (order of card input, order of output on reports, etc.).
Make sure this is so. If it is, go to step 3.
b. One. There is only one basic processing
sequence des ired; go to step 4.
c. More than one. This complicates the
matter. Go to step 5. Processing
sequences needed:
1.
2.
3.
4.
OUTPUT
Same
as
input
Subsections
Other
5.
3. No one cares what the processing sequence is.
This is unusual but does sometimes occur. If this
is so, you can forget about processing, and choose
an organization as an isolated problem, entirely
separate from processing.
4. This file will never be processed in more than
one sequence. Therefore, it would seem like a good
idea to organize it either sequentially or randomly,
in the same order as that required by processing.
5. This file must be processed in more than one
order; however, it can be in only one order at anyone
time. Recheck step 1. Can any of the inputs be handor machine-sorted into the same order as another input? Can some of the output orders be relaxed? Can
you somehow reduce the number of orders required?
If you can reduce it to one, you can go to step 3 or 4.
If not, you must sort your file from one order to the
other, or otherwise work around this problem.
Section
90
Subsections
Page
I
01
00
00
Section 90: IMPROVING YOUR SYSTEM -PERFORMANCE
CONTENTS
General ........................... .
The Role of the Monitor ......•........
General ......................... .
The Effect of the Monitor on
Performance .................... .
The Role of the Programmer ..•.......
Planning for Performance .....•....
Organizing for Performance -How to Use LOCA Ls ......•....•..
Programming for Performance .....
Reducing Core Storage
Requirements
Programming Techniques to
Increase Speed
The FIND Statement
The Role of the 1130 Hardware .....•..
General ........................ .
Productive Time That Cannot be
Improved by Hardware Changes .....
90.01. 00
90.10.00
90.10.01
90.10.10
90.20.00
90.20.10
90.20.20
90.20.30
90.30.00
90.30.01
90.30.10
Productive Time That Can be
Improved by Hardware Changes ..... .
Plotting
Card Reading
Card Punching
Printing
Computing
Nonproductive Time That Can be
Reduced by Hardware Changes ...•...
Additional Core Storage
Additional Disk Drives
Some Case Studies of Performance
Improvements .•.•...••....•.•••..••..
General .......•...•...............
Case I .....••......•.••.•..•.....
Case II ..........•.......•....•....
Case III .....•..•...•.•.•..........
Summary ......................... .
90.30.20
90.30.30
90.40.00
90.40.01
90.40.10
90.40.20
90.40.30
90.40.40
Section
90
GENERAL
This section covers many items of interest to all
1130 users:
• How to conserve core storage
• How to increase the running speed of a program
• How to segment programs
• The proper (and improper) use of LOCAL
and SOCAL subroutines, etc.
The general theme of this chapter, is, however,
how to improve your system, or, how to increase
system performance.
The performance of your programs should be one
of the major considerations of your programmer.
Unfortunately, however, performance is all to often
Subsections
01
I
00
Page
01
forgotten in the drive to produce a working program.
The programmer, usually working against a deadline,
devotes all his energy and ingenuity to the TEST /
DEBUG/CORRECT/RETEST cycle, finally producing an error-free program with no time to spare,
and with little thought given to efficiency.
Hemember, however, that this program now
enters production status, to be run weekly, or
possibly daily, where its performance may greatly
affect the overall operation of the 1130 system.
Program performance is affected by three factors, each of which will be discussed in more detail:
The Monitor, or software
The programmer
The system itself, or 1130 hardware
Section
90
Subsections
10
I
01
Page
01
THE ROLE OF THE MONITOR
General
The 1130 Monitor system has an outstanding feature,
lmown as the "system overlay scheme", designed to
assist you in fitting your programs into core storage.
This scheme is covered in some detail in Section
65, under "SOCALs".
Recapping that section briefly, the Core Load
Builder, which is given the task of building a core
load, or ready-to-execute package, also is given
the task of resolving the problem of more program
than core storage (if this problem arises).
Typically, many blocks of programming are
competing: for core storage: your programs, your
subprograms, the IBM subprograms, and the
Monitor control package itself. All must be in
core storage when required.
As a first step, the CLB attempts to fit the entire package into core storage simultaneously. If
that does not fit, the CLB splits the IBM subprograms into four groups:
Group 0
Basic
Overlay 1
Arithmetic (add, subtract, multiply,
etc. )
Overlay 2
Non-disk Input/Oltput (cards,
printer, etc.)
Overlay 3
Disk Input/Output
As step 2, the CLB determines whether the
package will fit in core if Overlay 1 and Overlay 2
share the same area in core storage (the SOCAL
area). The SOCAL area must be large enough to
contain Overlay 3 plus the larger of Overlays 1 and
2.
If this does not provide enough room, step 3 is
taken. Here, all three overlays (1, 2, and 3) will
share the same area, which must now be as large.
as the largest overlay.
Step 4, taken if step 3 does not work, consists
of a message informing you that this program is
too large to fit in core storage.
To illustrate this graphically, Figure 90.1 shows
the layout of the SOCALs required by a "typical"
commercial job. This "typical" program:
• Is written in FORTRAN.
• Adds, subtracts, multiplies, and divides.
• Uses the 1132 Printer, the 1442 Card Read
Punch, and the console typewriter (but not the
keyboard).
• Contains at least one PAUSE, STOP, and
CALL DATSW statement.
• Contains disk READ, WRITE, and FIND
statements.
If you punch an L in column 14 of the / / XEQ
card, the CLB will print a core storage map of
your program and all its subprograms, indicating
which are SOCAL or LOCAL, and what overlay
level is in effect.
Section
90
Step 1
Overlay Level 0
3000
Step 3
Overlay Level 2
Step 2
Overlay Level 1
2970
Overlay
3
2500
I-
Disk
I/O
(700)
2000
......
Overlay
2
Overlay
3
Disk
I/O
(700)
1500
-
Non-Disk
I/O
(1750)
2450
---
-
1750
--,
I
Overlay
2
Overlay
2
Unused
1000
r-Unused
I
Unused
Non-Disk
I/O
Non-Disk
I/O
(1750)
(1750)
I
I
I
I
I
I
500
-
o
Figure 90. 1.
Overlay
3
Overlay
1
Overlay
1
Arith.
Arith.
Arith.
Disk
I/O
(520)
(520)
(520)
(700)
Overlay
1
Subsections
10
I
01
Page
02
Section
90
Subsections
10
I
10
Page
01
The Effect of the Monitor on Performance
To return to the main subject of this chapter, you
may ask, "How does all this affect performance?"
To answer this, we can construct a flowchart of a
"typical" commercial job. Let us say it is basically of the type:
1. Head a card.
2. Taking a key item number from the card,
look up its approximate disk location in an index
table (indexed sequential organization).
3. Head a disk record.
4. Determine whether it is the right disk record.
If it is, continue; if not, decrease the record number by 1 and go back to step 3.
5. Do some calculations based on the data
obtained from the disk and from the card.
6. Write an updated disk record.
7. Print a line of answers on the 1132 Printer.
8. Do some arithmetic (reset indicators, clear
totals, etc.) and go back to step 1.
For the purposes of this analysis you may ignore
routines that are executed only once (initialization,
final totals) or infrequently (error messages, etc.).
Figure 90.2 shows this job in the form of a rough
flowchart.
If this program is of a size that requires no
over lays, it will run at some base speed or throughput rate. If its size is such that it must run at
SOCAL level 1, Overlay 1 (Arithmetic) and Overlay
2 (Non-disk II 0) must be read from the disk whenever required. Figure 90.3 shows when these overlays would be required. This will lengthen the
base running time.
Each pass will require four overlays and two
disk arm moves. The arm moves are required
because the disk data file and the SOCAL overlays
are on different areas of the same disk. The time
required for these arm movements varies, depending
on several factors, but it may be considerable.
A good average might be about 250 milliseconds or
1/4 second.
If the program must run at Overlay level 2, the
picture changes considerably, as seen by Figure
90.4. If it hits the correct disk record on the first
try, it will require seven overlays and four disk
arm moves. For each additional disk read looking
for the correct record, add two overlays and two
arm moves. Running time will be further lengthened.
Initialization
Arithmetic
_J
--.
Read Card
•
Look up key
item number
in index table
_J
--.
Read a disk
record for
an item
t
-
Not
found
Check it against
the item number
on the card
Found
t
Calculations
t
Write a new
disk record
t
Print results
t
Not
finished
Miscellaneous
arithmetic
Finished _
-
Print
Grand
Totals
...
Figure 90.2. "Typical" commercial job -- rough flowchart
E XIT
Section
I
02
10
Initialization
Arithmetic
Initialization
Arithmetic
......-____~
.. I
OJlERLAY JlRITfI
- . ...---- WITII NON-DI.5K I/O
r--_ _ _ _~_I
OJlERLAY JlRITII
... -• ...---- WITII NON-DiSK I/O
Read Card
Read Card
•
OYERLAY NON-DISK
OYERLAY NON-DISK
..----- WITH ARITii
..----- WITH ARITii
Look up key
item number
in index table
Look up key
item number
.n index table
~
Page
10
90
•
Subsections
NOVE DISK ARM
.-----.aM
_I
FROM OVERLAY
--. . . - - - -AREA rOFILE AREA
NOVE DISK ARM
FROM OVERLAY
- . . . - - - -AREA rOFILE AREA
___~
__I
r-----L--~__, OVERLAY All/TN WITH
DISK I/O
Read a disk
record for
an item
Read a disk
record for
an item
MOVE ARM TO OV£III.AY
I .---- ,qR£A
,...-_ _........
,_~_---. OVERI.,l/Y LJISK I/O WITH
I'1RITIIMET/C
_
Not
found
_
Not
found
Check it against
the item number
on the card
Found
~
Check it against
the item number
on the card
Found
t
Calculations
Calculations
OVERLAY /Ill/TN WITN
I ..--- OI$K I/O
,
4 - - MOVE ARM TO FILE ,qIU',I/
,..-----------.
Write a new
disk record
I
Write a new
disk record
F.I?OJl1 FILE AREA
.---- TO OVERLAY AREA
.--_---:,l..-.~~
..
I .---,...--_ _........
'_
...._-.
Ot/ERLAY A R I T1-1
WITH AlON-OISK £/0
Not
finished
Ot/ERLAY tJISK
WITH AlON-OISK £/0
t .----
Ot/ERLAY NON-DISK
. - - - - WITH ARITHMETIC
Miscellaneous
arithmetic
F.I?OJl1 FILE AREA
TO OVERLAY AREA
Print results
Print results
•
MOVE f)ISK ARM
MOVE f)ISK ARM
-
Finished _
Print
Grand
Totals
~XIT
Figure 90.3. Overlays and disk arm movements required at
SOCAL level 1
Not
finished
Miscellaneous
arithmetic
Ol/ERLAY NON-DISK
WITH ARITHMETIC
Finished _
...
Print
Grand
Totals
~XIT
Figme 90.4. Overlays and disk arm movementS required at
SOCAL level 2
Section
90
Subsections
Page
I
03
10
10
Figure 90.5 summarizes the overlay pattern as it
varies with the disk search.
You can see the Overlay level 1 will not hurt
performance too much. If each arm movement
takes about 1/4 second, the processing time per
card might jump from 8 to 8 1/2 seconds. Overlay
level 2, on the other hand, may cause this program
to run significantly more slowly. A typical indexed
sequential file might require 15 disk reads to find
the correct record. This would increase the time
per card from 8 seconds to 16 seconds, or half the
throughput rate. This could become even worse if
the data file being searched were large or distant
from WS, since the SOCAL area would be proportionately further away from the file area.
The overlay time itself may be ignored, since
it is quite small compared with the disk arm movement time.
This example illustrates two principles:
1. The disk data file must be organized so that
items may be found qUickly (see Section 85).
2. For programs involving disk search techniques, as does the example, you should try diligently to avoid SOCAL Overlay level 2.
The difference between level 2 and level 1 is
either 620 words (HEAD and WRITE disk) or 700
words (HEAD, WRITE, and FIND disk), but this
does not mean that you must cut 620 or 700 words
from your program to drop from level 2 to level 1.
The CLB will use level 2 if the program is too big
for level 1. (It may be one word too big or 700
words too big.) Every word you can cut from
the size of the program increases the probability
that the program will fit at level 1 rather than level
Number of disk
READs to find
the desired
record
Overlay level 0
Overlays
Overlay level 1
Arm
moves
Overlays
Arm
moves
Overlay level 2
Overlays
Arm
moves
1
0
0
4
2
7
4
2
0
0
4
2
9
6
3
0
0
4
2
11
8
4
0
0
4
2
13
10
5
0
0
4
2
15
12
10
0
0
4
2
25
22
15
0
0
4
2
35
32
20
0
0
4
2
45
42
Figure 90.5. Single-drive 1130 system
2. For this reason, you should strive to keep your
programs as small as possible. Several means of
doing this are discussed in the next subsection.
Also, Section 70 gives many FOHTRAN core saving
tips.
Note that the above analysis applies to single
disk drive 1130 systems; the addition of a second
disk drive would eliminate all the overlay-caused
arm movements -- assuming of course, that you
have placed your data file on one disk and Working
Storage on another.
Section
90
THE HOLE OF THE PHOGHAMMEH
In reading the preceding subsection, you may have
got the idea that the 1130 Monitor has the major effect 011 the performance of your programs and that
you do not enter the picture unless the "system
overlay scheme" fails to squeeze your program into
core storage.
Nothing could be further from the truth. The
program the CLB was manipulating was, after
Subsections
20
I
00
Page
01
all, planned, organized, and programmed by you,
not by the CLB.
Anyone of these three functions, if not
properly done, can force the CLB into building
an inefficient package - ... one that may take five
or ten times longer in execution than a similar (but
better planned) program doing the same job.
As mentioned earlier in this section there are
many things you can do to avoid such inefficiencies;
most of them are easy to understand, remember,
and implement.
Section
90
Subsections
Page
I
01
20
10
Planning for Performance
The major factor affecting program performance is
core storage and how it is used. Therefore, you
should try to avoid core storage difficulties by
planning for reasonably sized program packages.
It may seem quite efficient to have the entire payroll processed by one comprehensive program, but,
overall, it would probably turn out to be quite
inefficient. Because it would be a very large
program, it would probably involve many overlays
and could run for eight hours, whereas four smaller
programs might take only five or six hours.
Section 60 contains many hints on how you may
write small, modular programs. Besides helping
to gain performance, modular programs have many
other advantages over large, all-inclusive ones
(they are easier to test, tend to keep errors from
spreading, etc.).
Section
90
Subsections
Page
I
01
20
Organizing for Performance -- How to Use LOCALs
After its scope has been determined, a program
should be organized into logical blocks that lend
themselves to efficient segmentation. You should
organize your program expecting to have problems
concerning core storage. If you do not have problems, very little time is lost. If you do, as is
typical in most cases, you are in a position to create
your own overlay scheme, if that of the loader will
degrade the performance of your program.
As you have seen, in Section 65, the Monitor
gives you two overlay or segmentation methods:
LOCAL subprograms and program LINKs. These
two overlay schemes are entirely planned and
executed by you, in contrast to the Core Load
Builder's automatic SOCALs.
The three interact in one important way: If you
can conserve enough core with LOCALs and LINKs,
the C LB will not have to resort to SOCALs. As you
saw earlier, SOCAL Overlay level 2 can seriously
degrade the performance of some programs, particularly those that search a disk data file looking for a
certain key (man number, part number, etc.).
If you have a program such as this running at a
comparatively slow rate, you should investigate it
closely; if the program is using level 2 overlays,
you should make a determined effort to reduce its
size enough to allow CLB to use level 1. (To find
out which overlay level is in use, execute the
program with an L punched in column 14 of the
/ / XEQ card.)
Figure 90.6 shows the same program used earlier
as an example. To it has been added:
INIT
The Initialization routine
WRAP
The wrap-up routine (grand totals)
and three exception subroutines:
BADCD
"Bad input card" message
NOHIT
"No such item on disk" mes sage
NEWPG
Page heading routine
In addition, the following have been made into subroutines:
READC
Read card
CALC1
Calculations Part 1
CALC2
Calculations Part 2
Calculations Part 3
CALC3
Miscellaneous arithmetic
MISC
How should you go about reducing the size of this
program? Many programmers, irked at the fact that
their program does not fit in core storage, take
an "I'll show 'em" attitude and make all subroutines LOCAL. This probably will eliminate
Initialization
Arithmetic
e
Read Card
~
ERROR ROUTINE
~
8,1;,0 CRI?,o
Look up key
item number
in index table
Read a disk
record for
an item
~
Not
found
Check it agai nst
the item number
on the card
Found
Calculations
Figure 90.6.
ERROR ROIJTINE-
. . - - - ITEM NOT ON OISK
20
Section
90
Subsections
Page
I
02
20
20
the need for Overlay level 2, but is a rather extreme
case of over-reacting to a problem. Figure 90.7
shows the way in which this program would run, if
all seven subroutines were LOCAL and Overlay
level 1 were used. Each card processing cycle
would involve 11 overlays (7 LOCALs, 4 SOCALs)
and i arm movements (these figures are not dependent on the number of times the disk must be read
before finding the desired item).
Reviewing Figure 90. 7, it seems that you are
somewhat better off than if you had used Overlay
level 2, but you still require an excessive number
of over lays and arm movements.
It would have been far more prudent to LOCALize
only BADCD, NOHIT, and NEWPG, three subroutines
that are only used occasionally. This would reduce
your LOCAL overlays drastically and might save
enough core storage for Overlay level 1 to be used.
Another technique that would reduce the size of
this program is the use of LINKs. The blocks
called INIT and WRAP could easily be separated
from the main program, and made into what can be
called "one-shot LINKs". This might save enough
core storage to eliminate the need for LOCALs and
SOCAL level 2 altogether.
Another LINK is possible here -- a type you might
call a "repetitive LINK". Suppose you split the main
program into:
PARTI
a. Read card
b. Look up key in index
c. CALL LINK (PAR T2)
PART2
a. Read disk
b. Check if correct record found
c. Calculations
d. Write new disk record
e. CALL LINK (PART3)
PART3
a. Print results
b. Miscellaneous arithmetic
c. CALL LINK (PARTl) if not finished
CALL LINK (WRAP) if finished
This arrangement is particularly good, for several
reasons:
• It cuts the original program into five pieces
(two small and three large).
• It isolates the I/o into separate LINK.s -- for
example:
PARTI uses neither the disk nor the printer.
PART2 uses neither card nor printer.
PART3 uses neither card nor disk.
This reduces the sizes of these LINKs substantially
• It probably eliminates the need for SOCALs
and LOCALs altogether.
Initialization
Arithmetic
e
Read Card
'----r----~
@--
.....
):0
,....------,;;:;
E.R.ROR ROUTINE
SRb CRNb
Look up key
item number
in index table
Read a disk
record for
an item
8-0
.....-----......;::::::;
~ ERRORROUnNE-
Not
found
Check it against
the item number
TEM NOr 011 DISK
. - - - ..../ _ _ _ _ _- - - J
Found
Calculations
e,0
Write a new
disk record
,....-------~~
5KIP TONElli PRf;E
AND PRINT NERD/NtiS
WileN NECE»RR'I
Print results
Not
finished
Miscellaneous
arithmetic
/.: L OCR/. OVERLI1Y
S = SOCRJ. OVEIUR'I'
Figure 90.7.
Finished
Print
Grand
Totals
,Al0 =MOYE I1RN TO OV£~LA'I AIUR
ND" "'"VE AIIN TO DI17R 'Ii~ AR~A
Section
90
To summarize, a typical program has been segmented in several different ways, and the probable
effect of each way on performance has been discussed. The purpose has not been to illustrate that·
LINKs are better than LOCALs, or that LOCALs
are better than SOCALs, or any other hard and fast
rule. The purpose has been to illustrate that the
options must be chosen wisely, not blindly. The
easiest way, letting the CLB do it with SOCALs,
mayor may not be the best in terms of performan,ce.
The next easiest way -- LOCALs -- mayor may not
be best. The only way to determine which is best
is to :lraw a flowchart of the type shown and to
tailor the overlay option to the program.
You can generalize ::;omewhat, with some
common -s ens e do's and don'ts:
1. DON'T worry about the performance of a
program that runs for only a few minutes, or that
is used only occasionally. Concentrate your efforts
on the long-running, everyday jobs.
2. DON'T place an overlay, or cause one to be
placed, within a loop that reads from the disk. For
example, take the problem discussed above, where
you have a loop of the type:
Read disk record
Compare disk key to sought-for key
If not equal, repeat
SOCAL level 2 will overlay the Disk I/o package
,required for the Disk READ) and the Arithmetic
package (required for the subtraction within the IF
statement parentheses). Furthermore, the disk
READ command requires the disk arm to move away
Subsections
Page
I
03
20
20
from the SOCAL disk area. This repetitive disk arm
movement may have a disastrous effect on the
running time of the program.
If you place a LOCAL subroutine within this loop,
it will have the same effect as if the CLB had included a SOCAL.
3. DON'T LOCALize subprograms that are
always used, unless it is absolutely necessary to
get the program into core storage. DO LOCALize
subprograms that are the exception rather than the
rule (error messages, new page headings, initialization, final totals, unusual payroll deductions,
etc. ).
4. DO minimize the amount of coding between
DISK I/O commands. This, in turn, will minimize
the chance of an overlay (SOCAL or LOCAL) which
will require that the disk arm move from the data
area to the overlay area and back again.
5. Also, DON'T LOCALize a subprogram that is
called between two disk statements. For example,
suppose a program has the following sequence:
DISK I/o
CALL SUB
DISK I/o
In this case SUB should not be made LOCAL, since
it will force excessive disk arm movement.
6. DO plan for problems with performance -either a program too large for core or a program
that does not run as fast as it might. Keep the
scope (and therefore the size) of each program
modest; program as a series of LINKs; design the
exception routines as subprograms; etc.
Section
90
Subsections
Page
I
01
20
30
Programming for Performance
Reducing Core Storage Requirements
You have seen in the preceding examples that system
performance is very closely related to the size of a
program. In general, the larger the program, the
more slowly it will run. This degradation is not
evidenced in a gradual way; because of the SOCAL
and LOCAL system, it will show up in sudden jumps
or drops in throughput rates. Suppose you have an
1131 Model 2B (SK) and the familiar "typical"
program. With no overlays you have about 4500
words for your program; with Overlay 1, about
4920 words; with Overlay 2, about 5620 words.
Assuming these figures to be exact, this means that:
If your program size is
It will:
Fit with no overlays
1 -- 4500 words
4501 -- 4920 words
Require Overlay 1
Require Overlay 2
4921 -- 5620 words
5621 words or more
Not fit in core storage without further
work
If you add 1 word to a 4920-word program, it will
suddenly require Overlay 2 and may take twice as
long to execute. (It may also take no longer than
before -- this depends on the pr~gram.)
Conversely, if you have a program at level 2,
it may take anywhere from one word to 700 words to
make it drop to level 1. If it was 4921 before, it
will take only one word; if it was 5620, it will take
7:'0 words.
To make a long story short, every word counts.
You should always keep this fact in mind and strive
to write efficient programs. Section .70 gives many
core saving tips; Section 65 also gives some ideas
for improving the SOCAL system. Repeating the
FOR TRAN tips (the details are given in Section
70. 50.20):
1. Use the DATA statement wherever possible.
2. Keep FORMAT statements compact.
3. Take square roots and raise numbers to
powers in the most efficient manner.
4. Code efficient I/O statements.
5. Avoid long subroutine argument lists.
6. Don't include unneeded I/O devices on the
*IOCS card.
7. Avoid arithmetic with constant subscripts.
S. Remove the TRACE from production status
programs. The trace package requires about 140
words of core storage. In addition, it requires that
Data Switch 15 be interrogated every time you
"execute" an equal sign, IF statement, or computed
GO TO. This requires 150 to 200 microseconds
each time; some programs may do this tens of
thousands of times in the course of one run.
Section
90
Programming Teclmiques to Increase Speed
Just as reduced program size can improve performance, so can several programming teclmiques.
All involve utilizing the overlapped I/o capability
of the 1130. The hardware of the 1130 allows for the
overlapping of almost all I/o devices; however, the
programming system used determines which units
can actually be made to run concurrently with
other units, or with the central processor. (See
Figure 90.8.)
Overlapping means that you can:
1. Tell the devfce vlhat it is to do.
2. Start it going (printing, punching, etc.).
3. Then continue with other processing before
the device has actually finished what it has started.
This section covers those units that can be overlapped by standard FORTRAN. The use of the
overlapped I/O feature of the Commercial Subroutine Package is discussed in Section 70.
Unit
FORTRAN
with Commercial
FORTRAN Subroutine Package
Assembler
1442-6 or -7 Reader
Yes
Yes
1442-6 or -7 Punch
Yes
Yes
1442-5 Punch
Yes
Yes
Console Typewriter
Yes
Console Keyboard
1132 Printer
1403 Printer
Yes
Disk - Arm Movement (FIND)
Yes
Yes
Yes
Yes
Yes
Yes
-Writing
Yes
2501 Reader
Page
I
02
20
30
The FIND Statement. Because it is an optional
feature of FORTRAN, some programmers are unaware of, and/or neglect, the use of the FIND statement. However, in many disk-oriented programs
it can increase performance significantly. It can be
added to any program quite easily and is simple to
use.
Suppose your program calls for a disk read from
record NR of file 6:
READ (6'NR) DATA
The disk subroutine will automatically compute
where that record resides, move the disk arm to the
proper position, and read the data. As mentioned
many times earlier, the second job, the movement
of the disk arm, may take much longer than the
other two functions.
The FIND statement
FIND (6'NR)
ahead of the READ (or WRITE) will cause the subroutine to compute the location of record NR, start
the disk arm moving to that location, and then continue processing other FORTRAN statements.
The secret of the FIND statement is self-evident:
it should be placed as far in advance of the actual
READ or WRITE statement as possible. In this way
you can get the arm moving, overlapping its movement or "seek" time with computations, printing,
etc.
Let us take a portion of a FORTRAN program
that looks like this:
FIND (6'NR)
Yes
- Reading
1627 Plotter
Yes
Yes
Subsections
Yes
Yes
Yes
1134 Paper Tape Reader
Yes
1055 Paper Tape Punch
Yes
Figure 90. 8. Pro gramming systems permitting overlapped operations
other FORTRAN coding
READ (6 'NR) DATA
Suppose it takes 700 milliseconds to move the
disk arm to record NR from where it happens to be
now. Suppose also, that the "other FORTRAN
coding" shown takes 300 milliseconds. Without
the over lapping gained by the FIND statement, the
~otal time would be 700+300 or 1000 milliseconds.
With the FIND statement, the total time would drop
to 700 milliseconds, since the 300 milliseconds
is "buried" within the 700 milliseconds seek time.
Figure 90. 9 illustrates this graphically. This
.night amount to only 20 or 30 minutes a day,
but it is so easy to implement that it is certainly
worth the trouble of punching a few FIND cards.
If you are using LOCALs, and/or the CLB has
included SOCALs, the FIND statement will not be
executed. The Monitor will take care of this automati cally. The reason is obvious: if you FIND a
Section
90
Subsections
Page
I
03
20
30
record then call a LOCAL or SOCAL subprogram,
the entire purpose of the FIND will liave been
negated, and you will wind up increasing disk seek
time rather than decreasing it. If you know you
will have LOCALs or SOCALs, you may want to
remove all the FIND statements from your program,
eliminating the SDFND subroutine, which is approximately 80 words long.
Without the FIND statement:
READ
•
Compute
Location
of Record
Other
Coding
I---
300 m,,<
----.~~I. .
Arm Movement
~I o.I .
- - - - - - - 7 0 0 msec
I - - X -...
Total time
= 700 + 300 + X + Y
X is small compared with the others.
With the FIND statement:
READ
,..
F IND
-
700 msec
I
Compute
Location
of Record
Arm Movement
Other Coding
x
Total time
I
,
Compute
Location
of Record
Read
Record
x
y
= 700 + X + X + Y
X is small compared with the others.
Figure 90.9.
Read
Record
Continue
Section
90
THE ROLE OF THE 1130 HARDWARE
General
The last component in the user/hardware/software
trio is the 1130 hardware itself. Because this section is concerned primarily with increasing performance, the discussion will concentrate on the ways
you can improve throughput by the use of alternative hardware configurations.
The first step is the separation of run time into
four basic elements:
1. Productive time that cannot be improved by
hardware changes
Subsections
Page
I
01
30
01
2. Productive time that can be improved by
hardware changes
3. Nonproductive time that cannot be improved
by hardware changes
4. Nonproductive time that can be improved by
hardware changes
The third is included only for completeness; using
the definitions, there are no meaningful items to discuss in this area.
Productive time is the time that the 1130 occupies
itself doing something you wantitto do. Nonproductive time applies to activities that may be necessary,
but that are unproductive from your point of view.
Some examples of the latter are disk seeks, reading
LOCAL and SOCAL overlays, etc.
Section
90
Subsections
Page
I
01
30
10
Productive Time That Cannot Be Improved by Hardware Changes
Some of the 1130 system components are available
in only one model; therefore, it is impossible to increase performance by changing them. The typewriter, the console keyboard, the paper tape reader,
and the paper tape punch are four such devices. In
addition, the reading/writing speed of the disk is
constant, which means that the reading/writing of
your data records cannot be speeded up through
hardware changes. However, because more disk
drives may be added, certain other times relative
to the disk (seeks, reading of overlays) may be reduced; they are therefore covered in a later section.
Section
90
Productive Time That Can Be Improved by Hardware Changes
There are five elements of productive time that
can be improved by changing the model or speed of
an 1130 component. That is, you can:
• Heduce plotting time by switching to a faster
plotter
• Reduce card reading time by obtaining a
faster card reader
• Reduce card punching time by obtaining a
faster card punch
• Reduce printing time by obtaining a faster
printer
• Reduce computing time by changing to a
faster CPU
Plotting
This is a somewhat special case; two plotting
speeds are available, but they are tied to carriage
sizes. The 1627 Modell, with an II-inch carriage,
is twice as fast as the Model 2, which has a 29 1/2inch carriage. However, most users have chosen
one model or the other on the basis of carriage size,
rather than speed, and are not in a position to
change models just to increase speeds.
Subsections
Page
I
01
30
20
Card Reading
There are four different card readers that may be
attached to the 1130 system, each with a different
card-read time:
Milliseconds per card (approx.)
Reader
200
1442 Model 6
150
1442 Model 7
100
2501 Model Al
60
2501 Model A2
If your programs use standard FORTRAN, none
of the specified card read time will be overlapped
with any other activity.
If you have a 1442-6 on your 1130, for example,
the time to read ten cards will be 10 X 200 or 2000
milliseconds. This is in addition to whatever manipulation must be performed on the data on those
cards. In a FORTRAN program, the system must,
at the very least, convert the Hollerith card codes
to EBCDIC, break that down according to the specified FORMAT statement, and, finally, place the
resulting data in the proper core location.
The rated speed of the 1442-6 is 300 cards per
minute, but this assumes that the 1130 reads a card
every 200 milliseconds. It is true that the reading
of each card will take 200 milliseconds, but the
system may not read a card every 200 milliseconds.
If the intervening processing takes 100 milliseconds,
it will read one card every 300 milliseconds,
yielding a speed of 200 cards per minute.
You see, then, that rated I/O device speeds are
difficult to use when evaluating potential system
improvements. You must compare alternatives
on the basis of the time per card that the CPU is
prevented from doing something else.
Suppose you have a 1442-6, and you time one of
your representative jobs. It reads 2100 cards, and
runs for ten minutes (600,000 milliseconds). You
lmow, from the timing table, that the 1130 must
have spent 2100 X 200 or 420, 000 milliseconds
reading cards, and 600,000-420,000 or 180,000
milliseconds doing something else.
If you changed to a 1442-7, the card read time
would drop to 2100 X 150 or 315, 000 milliseconds,
the "something else" would remain at 180,000
milliseconds, and the total run time would drop
from 600,000 milliseconds to 495,000 milliseconds,
or from ten minutes to about 8 1/4 minutes.
Section
90
Subsections
Page
I
02
30
20
The 2501, because of its clutch arrangement,
requires a special analysis. The 2501-A1, the 600card-per-minute reader, will read at fixed speeds of
600 cpm (100 millisec)
300 cpm (200 millisec)
200 cpm (300 millisec)
150 cpm (400 millisec)
120 cpm (500 millisec)
100 cpm (600 millisec)
etc.
and the 2501-A2, the 1000-card-per-minute reader,
will read at fixed speeds of
1000 cpm (60 millisec)
500 cpm (120 millisec)
333 cpm (180 millisec)
250 cpm (240 millisec)
200 cpm (300 millisec)
166 cpm (360 millisec)
etc.
To calculate the expected improvement in timing
due to a 2501-A1, we must, as before, substitute
100 milliseconds for the 200 milliseconds (1442-6),
to get 2100 x 100 or 210,000 milliseconds read
time, add the 180,000 milliseconds other time,
obtaining 390,000 milliseconds or 15 minutes.
Dividing this into the number of cards read (3000),
we find that this yields a rate of 323 cards per
minute.
However, the clutch arrangement of the 2501-A1
will not allow it to run at 323 cards per minute, so
the next lower speed (300 cpm) must be assumed.
2100 cards at 300 cpm yields a total time of seven
minutes.
A similar analys is for the 2501-A2 gives a
theoretical speed of 412 cpm, but, choosing the next
lower speed, 333 cpm., the total run time is calCUlated as 6.6 minutes.
Card Punching
Three different card punches are available for use on
the 1130 system; all three operate in the same mode,
punching one column at a time.
Card Punch
Millisec0nds per Card Column
Punched or Spaced
1442 Model 6
12. 5 plus 12. 5 per column
1442 Model 7
6. 5 plus 6. 5 per column
1442 Model 5
6. 5 plus 6. 5 per column
Models 6 and 7 both read and punch; Model 5 only
punches.
The overall speed is determined by the last
column punched, rather than the l'lIlmlber of columns
punched. If you skip the first 20 columns and punch
into the 21st, you have punched or spaced 21 columns
and the time for that number will apply. Figure
90.10 gives the punching time for the three models,
as they vary with the last column punched.
To continue the previous example, suppose that
of the 2100 cards read, the program punched into
1000
900
800
700
600
VI
"0
c:
0
(,.)
~
500
~
400
300
200
100
o
10
20
30
40
50
Last Column Punched
Figure 90.10.
60
70
80
Section
90
the first 20 columns of 500 of them. For the 1442-6,
the breakdown now becomes:
Operation
Milliseconds
Read 2100 cards
420,000
Punch 20 columns,
131,250
500 cards
Something else
48,750
Total
600,000
With the 1442-7, it becomes:
Read 2100 cards
210,000
Punch 20 col. 500 cards
68,250
Something else
48,750
Total
327,000
or 5.5 minutes
N ate that the times shown apply only to the time
actually spent punching. If the card being punched
was previously read, the punch time may be simply
added to the total. If the card being punched was
not previously read, you must add 200 or 150
milliseconds of read time per card to allow for the
(feeding of cards past the read station, even
though they were not read. This will always be
the case with the 1442-5, which cannot read cards.
Subsections
Page
I
03
30
20
Printing
Three different line printers may be attached to the
1130 system, each having different print and skip
times:
Approximate Time in Milliseconds
Skip 1 Line
Print 1 Line
16
1132
750
175
(3.61403 Model
microsecor
5
ond CPU)
100 (2.2Model 7
microsecond CPU)
To illustrate the improvement pOSSIble III this
area, let us take an example similar to the last one.
Suppose you have a program that is essentially a card
listing job. In ten minutes it reads 600 cards,
prints 600 lines, and skips 100 lines. This can be
broken down as follows:
Operation
Milliseconds
Read card (1442-6)
120,000
Print (1132) 600 @ 750
450,000
Skip 100 @ 16
1,600
28,400
"Everything else"
Total
600,000 (10
minutes)
If you replace the 1132 with a 1403-6, your print
and skip times drop:
Print (600 @ 175)
105,000
Skip 100 @ 5
500
Added to the card read time and the "everything else"
time, which remains the same, this results in a total
time of 253,900 milliseconds, or about 4 1/4 minutes,
as opposed to 10 minutes.
Note that despite this dramatic increase in
throughput, the 1403 is printing at only 141 (600/4.25)
lines per minute, far below its rated speed of 340.
The 1132 was also below its rated speed of 80 lpm,
since it printed 600 lines in ten minutes, or 60 lpm.
This shows again that rated speeds of cards per
minute, lines per minute, etc, cannot be used when
investigating alternate approaches to improving
throughput. The only usable figure is the length of
time the CPU is tied up-- that is, prevented from
doing something else.
This example has assumed a 3. 6-microsecond
CPU; if the 1130 were a Model C (2.2 microseconds),
a 1403 time of 100 milliseconds would be used. The
overall time would drop to 3.5 minutes, for a speed
of 172 lpm.
In all cases of 1403 timing investigations, you
must calculate the resulting lines per minute to make
sure that it does not exceed the rated speed of the
Printer
61
Section
90
Subsections
Page
I
04
30
20
printer. Fo-r example, an analysis that indicates a
1403 speed of 450 lpm must be modified if the printer
considered is a 1403-6, which cannot exceed 340 lpm.
The 750-millisecond time for the 1132 is based on
standard FORTRAN, which is not overlapped.
The 176 (or 100) millisecond time for the 1403
consists mainly of the conversion from EBCD1C to
1403 code - the 1403 itself is buffered, and the time
required to fill the buffer is quite small. The 176
milliseconds drops to 100 on a 2.2 microsecond
CPU because of the faster CPU. See the next subsection.
Computing
The 1131 Central Processing Unit is available with
one of two basic cycle times: 3.6 microseconds
(Models 1 and 2) or 2.2 microseconds (Model 3). In
more basic terms, the Model 3 will compute in .61
the time of the Model 1 or 2.
However, in this area it is not quite as easy to
calculate the improvement to be expected from the
faster CPU. The problem is that you often don It
lmow how much time you were computing before
(with a 3. 6-microsecond CPU), in which case you
cannot possibly tell what effect the 2. 2-microsecond
CPU will have.
Let us review the previous example: 1442-6 and
1132; ten minutes run time, read 600 cards, print
600 lines, skip 100 lines. The times in milliseconds,
were:
Card read
120,000
Print and skip
451,600
"Everything else"
28,400
Total
600,000 (10 minutes)
The only way you determined the 28,400 milliseconds
of "everything else" was by subtracting one lmown
value (I/O times) from another known value (total
run time).
If you lmow that all 28,400 milliseconds were
spent in computing, you can calculate that the 2.2microsecond CPU will do the same amount of work
in 61% of that time, or 17,300 milliseconds, a
reduction of 1,100 milliseconds or 1. 8 minutes.
If those 28,400 milliseconds had included any disk
operations, you could not have made the above estimate, since you would have had no way to determine
the split between disk activity and computing. Aside
from a good estimate, which would be quite an
achievement, the only way to evaluate the effect of
a new CPU in this case would be to take your program
to such an 1130, run it, and time it.
Section
90
Nonproductive Time that Can Be Reduced by Hardware Changes
By definition, three items fall into this category:
1. DISK seek, to get from one data record to
the next
2. DISK seek, to get from data area to overlay
area, and vice versa
3. DISK read to read overlay
All three items are necessary, but unproductive as
far as you are concerned. Note that item 1 is required whenever you are using data files, item 3
whenever you are using overlays (SOCALs, LOCALs,
and/or LINKs), and item 2 whenever you have both
overlays and data files.
The time requirements of all three are difficult
to determine, so an exact analysis will not be
attempted, as with the card readers, punches, etc.
There are two hardware changes that will reduce
these times:
1. More core storage, which will probably
eliminate overlays, and therefore items 2 and 3.
2. More disk drives, which will allow a redistribution of files and overlays, and reduce items
1 and 2.
Subsections
Page
I
01
30
30
Additional Core Storage
Asside from programmer convenience, the main
advantage in adding more core storage is its probable
effect on performance, or run time. If you can
execute your programs without any overlays, they
can be expected to run at some "top" speed,
governed mainly by the amount of productive work
you want done.
Additional Disk Drives
Unlike core storage, which will probably be augmented to improve performance, additional disk
drives are likely to be considered primarily to
increase capability -- the capability to copy disks,
the additional storage gained, etc. In many cases,
however, the move from a single to a multiple disk
1130 system may be accompanied by a gain in
throughput or performance. This will be true only
if you plan your system so that the LOCAL/SOCAL
overlays are on a cartridge other than the one on
which the data files reside.
The location (cartridge ill number) of the data
files is specified on the *FILES card. The LOCAL/
SOCAL overlays are either (1) in Working Storage,
if the program is executed immediately after
compilation, or (2) with the mainline program (in
UA or FX), if the program has been stored in core
image format. If they are in Working Storage, the
Monitor should be informed, with the JOB card, to
use the Working Storage on a disk cartridge other
than the data file cartridge. If they are with the
mainline program (in UA or FX), you should make
sure the core load is stored on a cartridge other
than the data file cartridge.
Section
90
Subsections
Page
I
01
40
01
SOME CASE STUDIES OF PEHFOHMANCE
IMPHOVEME NTS
General
This section is designed to present a general guide
to the principles involved in improving performance.
It also shows many of the techniques used to fit a
large problem into core, stressing how to do so
without adversely affecting performance.
In order to best illustrate these principles, three
case studies, or sample problems, are shown in detail:
• Case I -- a commercial job, typical of a
payroll-type application
• Case II -- a commercial job, typical of an
accounting type application
• Case III -- a scientific or technical job, involving mostly computation, with little or no input!
output
All examples are based on an 8K 1130 system,
but the principles are the same for any size machine.
Section
90
Case I
The first example uses a typical payroll-type
application to show one approach to improving performance. It may not be the best approach, but it
results in a set of programs that produce the
Subsections
Page
I
01
40
10
desired result, fit in core storage, and operate at
a near-maximum throughput rate.
A rough block diagram of this job, marked
to show what action has been taken, is included
with each step.
Section
90
Subsections
Page
I
02
40
10
Step 1
The first time we are able to try to execute the
program PA YRO we are informed that it does not
fit in core storage, needing 388 (hexadecimal) or
904 words.
~.-
;.-•
-.
II XEQ PAYRO L
*FILES( 1,FILEi'l)
FILES ALLOCATIO~
1 01A3 0001 7U61 FILEN
22 0000 UOOl 7U61 OlA7
STORAGE ALLOCATION
R 40 07AD (HEX) ADDITIONAL CURE REQUIRD
R 43 OlFC (HEX) ARITH/FUNC SOCAL WD CNT
R 44 06E8 (HEX) FIIO, 110 SOCAL we CNT
R 45 02A2 (HEX) DISK FIIO SOCAL ~J CNT
R 40 0388 (HEX) ADDITIONAL CORE REQUIRD
R 18 PAYRO LOADI~G HAS BEEN TERMINATED
Section
90
step 2
In order to test the program, we make all five subroutines LOCAL and find that it now fits in core,
but requires SOCAL level 2. Running of the program is accompanied with quite a bit of disk arm
movement, which slows it down considerably.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
I I XEQ PAYRO L 2
*FILES(l.FILEN)
*LOCALPAYRO.SUBW.SUBl.SUBY1.SUBY2.SUBY3
FILES ALLOCATION
1 01A3 0001 7061 FILEN
22 0000 0001 7061 01A7
STORAGE ALLOCATION
R 40 03E3 (HEX) ADDITIONAL CORE REQuIRO
R 43 01FC (HEX) ARITH/FUNC SOCAL ~D CNT
R 44 06E8 (HEX) FI/O. 110 SOCAL WD CNT
R 45 02A2 (HEX) DISK FIIO SOCAL WD CNT
R 41 00A4 (HEX) WDS UNUSED BY CORE LOAD
CALL TRANSFER VECTOR
DATSW 1902 SOCAL 1
SUBY3 1701 LOCAL
SUBY2 17C9 LOCAL
SUBY1 17C9 LOCAL
suez
1701 LOCAL
suew
1765 lOCAL
lIBF TRANSFER VECTOR
HOLTB 1EBB SOCAL 2
EADDX 1883 SOCAL 1
XDO
1988 SOCAl 1
FARC
1966 SOCAL 1
XMD
1924 SOCAL 1
ELDX
1528
NORM
1594
HOLEl 1E52 SOCAL 2
EBCTB 1E4F SOCAL 2
GETAo lE06 SOCAl 2
IFIX
1568
PAUSE 18EC SOCAl
ESBR
1808 SOCAl
EADD
1870 SOCAL
EoIV
1824 SOCAl
EMPY
17F6 SOCAl
EDVR
17DE SOCAl
FLOAT 155E
SUBSC 1540
ESTO
1516
ElO
152C
PRNTl 1048 SOCAL 2
CAROl 1C9E SOCAl 2
wRTYl 1C62 SOCAL 2
SFIO
1809 SOCAl 2
SoFIO 1885 SOCAl 3
SYSTEM SUBROUTINES
ILS04 00C4
ILS02 0063
I LS01 1£C2
IlSOO 1EDD
FLIPR 15DC
1467 (HEX)
Subsections
Page
I
03
40
10
The subroutines are:
SUBW -- Error message (hardly ever called)
SUBZ -- New page headings (once every 25
employees)
SUBYI -- FICA routine (almost always called)
SUBY2 -- Special deductions (one out of every
six employees).
SUBY3 -- Savings Bond deduction (one out of
every three employees)
LOCAL Sl/4W
LOCAL
st//JY I,
SVIIY2,
___s_v~., y 3
LOC.IIL
SC/8Z
Section
90
Subsections
40
I
10
Page
04
Step 3
Studying the flowchart, we see that this program
could be split into three smaller programs, or
LINKS:
PGMAB, which is made up of blocks A and B
PGMX, which was block X
MAIN, which is the main program
Executing with no LOCALs, we find that the program
MAIN requires SOCAL level 2 to fit into core, and
that it runs no faster than before.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
XEQ MAIN L
*FILES( 1,FILE,'!)
FILES ALLUCATION
1 01A3 0001 7061 FILEN
22 UOuu uuUl 7u01 UIA7
STORAGE ALLOCATIUN
R 40 03C5 (HEX) ADDITIONAL C0RE REQUIRv
R 43 01FC (HEX) ARITM/FuNC SOCAL Wi) CNT
R 44 06ES (HEX) FI/O, I/U ~UCAL wO CNT
R 45 02A2 (HI::.X) DISK FI/O ~OCAL WD CNT
R 41 005E (HEX) wDS UNUSED BY CORE LOAD
CALL T~ANSF~R V~CTOH
SUBW
1753
SUBZ
1627
SUBYl 155F
SUl3Y2 13CF
SUl3Y3 123F
DATSI'I 1946 SOCAL 1
L1BF THA"'lSFER VtCTUR
rlvLT6 lEFF SUCAL 2
EADDX 10(7 SOCAL 1
XCI)
19CC SOCAL 1
19AA SOCAL 1
FA"C
X;'lD
1968 SOCAL 1
114()
ELDX
;~Or<,'111
1788
HOL.EZ lE96 SOCAL 2
El3CTt3 lE93 SOCAL 2
(JETAO lE4A SOCAL 2
IFIX
175C
PAUSE 1930 SOCAL
ESi:JR
191C SOCAL
EADD
ItlCl SOCAL
tDIV
186H SOCAL
Ei'<;PY
183A SUCAL
EDVR
1822 SOCAL
FLUAT 1176
SUBSC 1158
C:STO
112E
ELI)
1144
PR,'1TZ lOBC SOCAL 2
CAROL lCE2 SOCAL 2
WfHYZ lCAo SOCAL 2
SFIO
191D SOCAL 2
SDFIO 18CQ SOCAL 3
SYSTEi>1 SUBROUTINES
ILS04 iJOC4
ILS02 OU63
ILS01 1F06
ILSOO IF21
FLIPR 1762
10CF (HEX) IS THE EXECUTIUN ADDR
.11
MM<.E TIIESE
INTO LINKS
Section
90
Step 4
Making all five subroutines LOCAL again, we find
this is just enough to eliminate SOCALs, but does
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
I I XEQ MA Ii"
L
*LOCALMAIN,SUBW,SUBZ,SUBY1,SUBY2,SUBY3
*FILES( 1,FIU:,'I)
FILES ALLOCATION
1 01A3 0001 7061 FILEN
22 (JOJO 0001 7061 01A7
STORAGE ALLOCATION
R 41 0004 (HEX) wDS UI'IUSED BY CORE L0AD
CALL TRAi"SFER VI::CTOR
DATSw 1 t:l7 E
SUtlY3 lE9F LOCAL
SUtlY2 IF67 LOCAL
SUBYl IF67 LOCAL
SUtlZ
lE9F LOCAL
SUBI'i
lF03 LOCAL
L I BF TI~AI\jSFER VECTOR
HOLTB 1059
I:: Al.!OX lAFF
XOD
1CDC
FARC
lCtlA
XtvlD
lC78
ELDX
lA12
,~ORr~
lC4E
HOLEl lC18
EBCTtl lC15
GETAD IdCC
IFIX
IBAO
PAUSE iB68
ESBR
1B54
I::ADD
lAF9
EDIV
1AAO
EMPY
1A72
EDVR
1A5A
FLOAT 1A48
SUtlSC 1A2A
ESTO
lAOO
ELO
lA16
PRIHZ 193E
CAROZ 1894
wRTYZ 1858
SFIO
14CF
SOFIO 1109
SYSTEivl SUBROUTINES
ILS04 00C4
ILS02 00B3
ILSOl IF74
ILSOO IF8F
FLIPR 107A
10CF (HEX) IS THI:: txECUT ION AODR
Subsections
Page
I
05
40
10
not speed up the program, since SUBY1, the
FICA routine, is called for almost every employee
and causes the disk arm to be moved from the data
file area back to the overlay area, and vice versa.
THE.Se: ARe:
.sTILl.. LINk'S
LOCAL. S-V4W
L.OCAI.. Sf/BY /,
Sc/8Y 2,
51.181 3
J. OCAL
SV8Z
Section
90
Subsections
Page
I
06
40
10
Step 5
Discussion of Case I
Since SUBYI as a LOCAL is slowing down the program, we must try to keep it in core storage at all
times. However, the previous load map showed that
there are only four words unused by the package,
and SUBYI is 400 words long. If we could free up
396 words, SUBYI could be taken out of the LOCAL
category, and the program would be speeded up.
(Realize, of course, that SUBYI could easily be
made non-LOCAL, but that SOCALs would then be
required. The secret is to avoid both SOCALs and
a LOCAL SUBYl).
Note also that SOCALs would cause the program
to run even slower. Since the sequence of the
program is a repetition of
Here you have seen one way to fit this "typical"
program into core, at little or no sacrifice in
throughput. There may be other ways to do the same
thing; there may be better ways.
Basically, common sense is used -- a step-bystep segmentation of the program, with each step
having a greater effect on performance:
1. Make LOCALs out of those subroutines that
are not always called~
2. Break the program into LINKs.
a.
I/o
b. DISK
c. ARITH, including SUBYI
d. DISK
e. ARITH
f. I/O
SOCAL level 1 will cause the disk arm to be moved
between the data area and the overlay area between
steps
a and b
band c
c and d
d and e
while SUBYI as a LOCAL will require such a movement only between steps
band c
c and d
After considerable study, we decide that there is
very little that can be done to further improve the
performance of this program, unless, of course, we
can reduce its size by 396-100 or 296 words (Flipper would no longer be required).
Because SUBYI handles the FICA calculation, it
will be called less and less as the year progresses,
since more employees will attain a "paid up" status.
(This won It be true, however, if your test for "paidup" is done inside the subroutine: It should be made
in the mainline program, otherwise SUBYI will be
called every time, whether the employee gets a deduction or not.)
Section
90
Case II
This program is of a basically different organization
than Case 1. It is typical of a job in which the input
consists of a master card followed by a variable
number of detail cards, with the sequence repeated
many times. Some good examples of this type of
job are billing, accounting, cost systems, etc.
Subsections
Page
I
01
40
20
Assume that this application is some type of project
cost system, with a master card for each project,
followed by a series of detail or change cards pertaining to that project. These detail cards may be
due to labor or materials charges against the
project or, in a few cases, an accounting department adjustment.
Section
90
Subsections
Page
I
02
40
20
Step 1
After several tries, the program COST achieves a
successful compilation, only to be met by the R40
•
•
•
•
•
II XEQ CUST
L.
*FIL.ES( loFIL.EN)
FIL.ES AL.L.OCATIO~
1 01A3 0001 7061 FIL.EN
22 0000 UOOl 7061 01A7
STORAGE AL.L.OCATION
R 40 084C (HEX) ADDITIONAL CORE REQUIRD
R 43 01E6 (HEX) ARITH/FUNC SOCAL WD CNT
R 44 06E8 (HEX) ~I/O, 1/0 SOCAL WD CNT
R 45 02A2 (HEX) DISK FIIO SOCAL. WD CNT
R 40 043E (HEX) ADDITIONAL CORE REQUIRD
R 18 COST LOADING HAS BEEN TERMINATED
and R18 messages shown. Even after SOCAL level
2 has been attempted, this program package exceeds
core storage by 43E or 1086 words.
Section
90
A. Initialize
B. Read a
card
X. Type Error
bad
card
message
last
card
C. Check the
card code
totals
master card;
one in 8.
labor card;
40ut of8.
material card;
3 out of 8.
t
t
t
D. Update disk
for last
master
P. GET data from
material card
just read
L. GET data from
labor card
just read
Y. Print grand
adjustment
card; unusual.
+
T. GET data from
adjustment
card just read
t
Z. Skip to new
page, print
headings
M. Calculations
t
t
E. Print totals
for last
master
Q.
N. Add to job
Calculations
U. Calculations
+
t
R. Add to job
totals
totals
V. Add to job
totals
t
F. Clear totals
for last
master
O. Print detail
line
S. Print detail
line
W. Print detail
line
"
••
'P
t
G. GET data from
master card
just read
•
H. Read disk
record for
new master
+
0
to B
Subsections
Page
I
03
40
20
Section
90
Subsections
40
I
20
Page
04
Step 2
Observing the flowchart, we see that we are fortunate in having several subroutines that are seldom,
if ever, called:
• BADCD, the illegal card message
• NEWPG, the skip to new page routine
• FINAL, the final total routine
• T, U, V, W, four routines involved in the
processing of an accounting adjustment card (an
unusual occurrence)
These seven subroutines are ideal LOCALs, and,
executing COST in this mode, we get the load map
shown. The program (at SOCAL level 2) runs, but
quite slowly. Checking the flowchart, we see we
have two blocks involving disk READs/WRITEs, D
and H, bracketing blocks E, F, and G, which use both
arithmetic and non-disk I/O functions. Obviously,
this will cause continuous disk arm movement between the disk data file area and the overlay area.
The only way we can reduce this time-consuming
function is to eliminate the need for overlays between
the disk READ and WRITE.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
••
I I XEQ COST
L 2
*FILES(l,FILEN)
*LOCALCOST.FI~AL'NEWPG,BADCD,T,U,V'W
FILES ALLOCATION
1 01A3 0001 7061 FILEN
22 0000 0001 7061 01A~
STORAGE ALLOCATION
R 40 02FE (HEX) ADDITIONAL CORE REQUIRU
R 43 01~6 (HEX) ARITH/FUNC SUCAL wD CNT
K 44 06E8 (HEX) FI/O, 110 SOCAL WU CNT
K 4'
U~A~ IH~XI
UISK fI/U SUCAL WU CNT
K 41 U1/4 IH~XJ ~U~ UNUS~D ~y CUR~ LUAU
CALL TRANSFER VECTOR
G
1410
F
1355
E
12F1
D
1280
DATSw 181A SOCAL 1
w
162F LOCAL
V
15CB LOCAL
U
16F7 LOCAL
T
15CB LOCAL
BAOCD 1567 LOCAL
NEwPG 162F LOCAL
FINAL 1693 LOCAL
LIBF TRANSFEK VECTOR
HOLTS 1DE9 SOCAL 2
EADOX 1781 SOCAL 1
XDD
18AO SOCAL 1
FARC
181E SOCAL 1
XMD
183C SOCAL 1
ELOX
10C6
NOKM
1452
HOLEl 1080 SOCAL 2
EBCTB ID10 SOCAL 2
GETAO 1034 SOCAL 2
IFIX
1426
ESBR
1806 SOCAL
EADD
17AB SOCAL
EOIV
1752 SOCAL
EMPY
1724 SOCAL
EOVR
170C SOCAL
FLOAT 10FC
SUBSC 100E
ESTO
1064
ELD
10CA
PRNTl 1C16 SOCAL 2
CAROl 16CC SOCAL 2
WRTYl 1690 SOCAL 2
SFIO
1801 SOCAL 2
SOFIO 1763 SOCAL 3
SYSTEM SUBROUTINES
ILS04 00C4
ILS02 0083
ILSOI IDFO
ILSOO lEOS
FLIPR 14A6
1048 (HEX) IS THE EXECUTION ADOR
Section
90
A.. Initialize
s.
LOCALs
ARE.
CIRCLSD
Reada
card
BAPcJ)
F/NAL
bad
card
C. Check the
card code
master card;
one in 8.
labor card;
4 out of 8.
D. Update disk
for last
master
L GET data from
labor card
just read
P. GET data from
material card
just read
M. Calculations
a. Calculations
N. Addtojob
totals
R. Addtojob
o.
So Print detail
E. Print totals
for last
master
F. Clear totals
for last
master
G. GET data from
mastercard
just read
H. Readdisk
record for
new master
Print detail
line
material card;
3 out of 8.
totals
line
adjustment card;
UNUSUAL
Subsections
Page
I
05
40
20
Section
90
Subsections
Page
I
06
40
20
Step 3
As mentioned in Step 2, we now realize that there
is no real reason for blocks E, F, and G to be
sandwiched between the disk READ and the disk
WRITE.
Rearranging the program slightly, to make the
sequence Z, E, F, G, D, H, we reexecute and find
that the program runs substantially faster than before. There is still some disk arm movement, but
it is not quite as frequent. Actually, as long as we
have disk data files and overlays, there will be
some disk arm movement. The goal is to reduce it,
if it cannot be eliminated altogether.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
II XEQ COST
L 2
*F ILES( ltF ILEN)
*LOCALCOST,FINAL,NEWPG,BADCD,T,U.V.W
FILES ALLOCATION
1 01A3 U001 7061 FILEN
22 0000 0001 7061 01A~
STORAGE ALLOCATION
R 40 02FE (HEX) ADDITIONAL CORE REQWIRu
R 43 01~6 (HEX) ARITH/FUNC SUCAL WD CNT
~ 44
06~8 (HEX) FI/O. 110 SOCAL WU CNT
K 4~
U~A~ IH~X)
uISK rIIU SOtAL wu tNT
K 4~
U~(4 IH~AJ
wu~ UNU~~D bY CUR~ LUAu
CALL TRANSFE~ V~CTOR
G
141D
F
1355
E
12F1
D
128D
DATSW 181A SOCAL 1
W
162F LOCAL
V
15CB LOCAL
U
16F7 LOCAL
T
15CB LOCAL
BADCD 1567 LOCAL
NEWPG 162F LOCAL
FINAL 1693 LOCAL
LIBF TRANSFER VECTOR
HOLTS lDE9 SOCAL 2
EADDX 17Bl SOCAL 1
XDD
18AO soeAL 1
FARe
187E SOCAL 1
XMD
lS3C SOCAL 1
ELDX
10e6
NO~M
1452
HOLEZ lD80 soeAL 2
EBCTB 1D7D soeAL 2
GETAD lD34 soeAL 2
IFIX
1426
ESBR
1806 soeAL
EADD
17AB SOCAL
EDIV
1752 SOCAL
E~PY
1724 soeAL
EDVR
170C SOCAL
FLOAT 10FC
SUBSC lODE
ESTO
10B4
ELD
10CA
PRNTZ lC76 SOCAL 2
CARDl 18CC SOCAL 2
WRTYZ 1890 SOCAL 2
SFIO
1807 SOCAL 2
SDFIO 1763 SOCAl 3
SYSTEM SU8ROUTI~ES
ILS04 00C4
ILS02 00B3
ILS01 lDFO
ILSOO 1EOB
FLIPR 14A6
104B (HEX) IS THE EXECUTION ADDR
Section
90
A. Initialize
LOCALs
B. Read a
card
ARE.
CIRCLED
BADe/)
FINAL
bad
card
master card;
one in 8.
labor card;
4 out of 8.
D. Update disk
L. GET data from
labor card
just read
for last
master
M. Calculations
E. Print totals
N. Add to job
for last
master
totals
F. Clear totals
for last
master
o.
G. GET data from
master card
just read
r------L.~
H. Read disk
record for
new master
MOI/E
BLOck'D
POWN
HE-Re!
Print detail
line
C. Check the
card code
material card;
3 out of 8.
P.. GET data from
material card
just read
Q.
Calculations
R. Add to job
totals
s.
Print detail
line
adjustment card;
UNUSUAL
Subsections
Page
I
07
40
20
Section
90
Subsections
Page
I
08
40
20
Step 4
In step 3, we have prevented overlays from occurring between disk READs/WRITEs. The next
logical step is to eliminate overlays altogether, or,
if that is impossible, limit overlays to LOCALs or
SOCALs that are infrequently called.
Further study of the flowchart reveals that a
master card is somewhat exceptional, even though
every eighth card or so is a master card. Adding D,
E, F, and G to the LOCAL list, we again execute
and find that the program now runs even faster than
before, with disk arm movement only when a master
card is encountered. The load map shows that
SOCALs are no longer required.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
II XEQ CUST
L
*LOCALCOS T, F I'J~AL, NEWPG, ~ADCD, T 'u, v, W,I) ,!;, F ,G
*FILES( 1,FILEi~)
FILES ALLOCATION
1 01A3 0001 7061 FILEN
22 UuJU UU01 7061 OlA7
STORAGE ALLOCATIOJ~
R 41 OOUA (HEX) WDS UNUSED BY CORE LOAD
CALL TRA~SFER VECTOR
DATSW 1AEE
G
1!;33 LOCAL
F
1DCF LOCAL
E
1DCF LOCAL
D
1EFB LOCAL
W
1E97 LOCAL
V
1E33 LOCAL
U
1F5F LOCAL
T
1E33 LOCAL
BADCD 1DCF LOCAL
NEWPG 1E97 LOCAL
FINAL 1EFB LOCAL
LIBF TRANSFER VECTOR
HOLTB 1CC9
EADDX lA85
XDD
1C4C
FARC
1C2A
XMD
1BE8
ELDX
1998
NORM
1tiBE
HOLEZ 1688
EBCTB 1685
GETAD 1B3C
IFIX
1610
ESBR
lADA
EADD
1A7F
EDIV
1A26
EI~PY
19F8
EDVR
19EO
FLOAT 19CE
SUBSC 19BO
ESTO
1986
ELD
199C
PRNTZ 18C4
CA~DZ
l81A
wRTYZ 17DE
SFIO
1455
SDFIO ll5F
SYSTEM SUBROUTINES
ILS04 00C4
ILS02 0063
ILSOl lF6C
ILSOO lF87
FLIPR 1DOE
104B (HEX) IS THE EXECUTION ADDR
Section
90
A. Initialize
LOCALs
ARE.
CIRCLED
B. Read a
card
bad
card
labor card;
4 out of 8.
master card;
one in 8.
L. GET data from
labor card
just read
M. Calculations
H. Read disk
record for
new master
material card;
3 out of 8.
P. GET data from
material card
just read
Q.
Calculations
N. Add to job
totals
R. Add to job
totals
O. Print detail
line
S. Print detail
line
BLOCK 0
HAS 8£E/II
MOVE/)
OOWN
HERE
C. Check the
card code
adjustment card;
UNUSUAL
Subsections
Page
I
09
40
20
Section
90
Subsections
Page
20
10
40
I,
Discussion of Case II
Here, as in Case I, we take a similar series of
common-sense steps to improve performance:
1. Make the exception subroutines LOCAL.
2. If that still requires SOCALs, consider separating the program into LINKs. In this case, this
approach did not seem to be too effective.
3. Since SOCALs seem unavoidable, we try to
rearrange our program steps to reduce their effect.
Section
90
Case III
Here you have a technically oriented job, with a
great deal of iterative or trial-and-error computation and very little input/output. The program reads
Subsections
Page
I
01
40
30
a deck of ten cards, computes for quite some time,
then prints a page of answers. On the basis of a
similar program, you estimate that the computations
should take about 15 minutes.
Section
90
Subsections
Page
I
02
40
30
step 1
Attempting to execute this program, TECH, for the
first time, we are informed that it exceeds core
storage by 2AO or 528 words.
•
•
•
•
•
I I XEQ TECH
L
*FILES(l.FILENI
FILES ALLOCATION
1 01A3 0001 7061 FILEd
22 OOOU 0001 7061 01A7
STORAGE ALLOCATION
R 40 068C (HEXI ADDITIONAL CORE REQUIRO
R 43 01C4 (HEXI ARITH/FUNC SOCAL wD CNT
R 44 06E8 (HEXI FI/O. 110 SOCAL W~ CNT
R 45 02A2 (HEXI DISK FIIO SOCAL WD CNT
R 4U 02AO (HEXI ADDITIONAL CORE REQUIRD
R 1& TECH LOADING HAS BEEN TERMINATED
..
N
P
Q
X
Y
Z
1111_
3111_
3111_
--
lill_
3111_
1111_
Section
90
step 2
Noting that the program may be split into three
separate programs or LINKs, we make some minor
modifications and obtain:
• INPUT, made up of the first two blocks, A
andB
•
•
•
•
Subsections
Page
I
03
40
30
• j\NSWR, the printing of the results, formerly
block K
• TEem, the main program
Executing, we find that INPUT and ANSWR fit with
room to spare, but TECH1 is still too large; however, it now exceeds core by only BE or 142 words.
II XEQ TECH1 L
FILES ALLOCATION
1 OOUO 0001 7061 01A7
22 0001 0001 7061 01A7
STORAGE ALLOCATION
R 40 047A (HEX. ADDITIONAL CORE REQUIRD
R 43 01C4 (HEX' ARITH/FUNC SOCAL wD CNT
R 44 0514 (HEX' FI/O. 110 SOCAL WD CNT
R 45 02A2 (HEX. DISK FIIO SOCAL WD C~T
R 40 008E (HEX. ADDITIONAL CORE REQUIRD
R 18 TECH1 LOADING HAS BEEN TERMINATED
--_of",
L
M
N
P
1011_
3011_
3011_
Q
X
1011_
-
Y
3011_
MAKE THIS
... LINK..
CALLED IWSWR
Section
Subsections
Page
I
04
40
90
30
Step 3
Reexecuting TECH1 with all eight subroutines as
LOCALs (L, M, N, P, Q, X, Y, Z), we learn from
the load map that this strategy not only gets the
program into core storage, but eliminates the need
for SOCALs. It runs quite slowly, however, and
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
I I XEQ TECH1 l
2
*FIlES(1.FI1..ENI
*lOCAlTECH1.l.M.N,P.Q.X,Y,l
FILES AllOCATION
1 01A3 0001
7061 FILEN
22 0000 0001
7061
01A7
STORAGE AllOCATION
R 41 0132 (HEX) WDS UNUSED BY CORE lOAD
CAll TRANSFER VECTOR
l
lD4D lOCAL
1E15 lOCAL
Y
lD4D LOCAL
X
Q
1£79 LOCAL
P
lE79 LOCAL
N
lE15 LOCAL
M
lE15 LOCAL
L
lD4D LOCAL
LIBF TRANSFER VECTOR
EADDX
lAA3
XDD
lC12
FARC
lBFO
XMD
lBAE
ELDX
19B6
NORM
lB84
EBCTB lB81
GETAD lB38
IFIX
lBoe
ESBR
lAFA
EADD
lA9D
EDIV
lA44
EMPY
lA16
EDVR
19FE
FLOAT 19Ee
SUBSC 19CE
ESTO
19A4
ELD
19BA
WRTYl 1964
SFIO
15DB
SDFIO 12E5
SYSTEM SUBROUTINES
lLS04 00C4
ILS02 00B3
FLIPR
lcac
110A(HEX) IS TH~ EXECUTION ADDR
takes nearly 60 minutes to go to completion, compared with the 15 minutes we expected. The sound
of the disk arm moving gives us a clue to what is
wrong: we have caused an overlay to be placed
between the disk READ/WRITE commands. In this
case the LOCAL subroutines L, P, and Q are the
culprits.
Section
90
A. Read input cards
;£NPifT
B. Initialize
C. Compute:
Call L-~
Call M-*
Call N-*
Sizes of the
Subroutines used:
D. Write disk
record
"ih
-;toM
*N
*P
I.
~Q
E. Compute:
Call L--IfCall P-:If
Call Q-*
Type message:
"STEP NUMBER n"
7fX
*y
:*z
100 words
300 words
300 words
400 words
400 words
100 words
300 words
100 words
*MAK£
1"1-1£5£
F. Write disk
LOCAL
record
G. Read disk
H. Compute
Call X-*
Call
Call Z-7f-
y-*
ANSWR
If not complete
J. Wrap-up
computations
K. Print results,
EXIT
Subsections
Page
I
05
40
30
Section
Subsections
Page
I
06
40
90
30
Step 4
Leaving L, P, and Q off the LOCAL card, we again
execute TEC HI, but find that it runs even more
slowly, since we now need SOCAL level 2 to fit into
core storage.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
II XEO TECHl L 2
*LOCALTECHl,M,N,X,y,Z
*FILES(l,FILEN)
FILES ALLOCATION
1 01A3 0001 7061 FILEN
22 0000 0001 7061 01A7
STORAGE ALLOCATION
R 40 OlDC (HEX) ADDITIONAL CORE REQUIRD
R 43 01C4 (HEX) ARITH/FUNC SOCAL ~D CNT
R 44 J514 (HEX) FIIO, 110 SOCAL WD CNT
R 45 02A2 (HEX) DISK FI/O SOCAL WD CNT
R 41 0274 (HEX) WDS UNUSED ~y CORE LOAU
CALL TRANSFER VECTOR
L
1607
P
15A3
1413
Q
Z
1745 LOCAL
Y
1800 LOCAL
X
1745 LOCAL
N
1800 LOCAL
M
l~OD LOCAL
LIBF TRANSF'ER VECTOR
EADDX 18C5 SOCAL 1
XDD
1992 SOCAL 1
FARC
1970 SOCAL 1
XMD
192E SOCAL 1
ELDX
124C
NORM
163C
EBCTS lD29 SOCAL 2
GETAD lCEO SOCAL 2
IFIX
1610
ESBR
191A SOCAL
EADD
18BF SOCAL
EDIV
1866 SOCAL
EMPY
1838 SOCAL
EDVR
1820 SOCAL
FLOAT 1282
SUBSC 1264
E5-TO
123A
ELD
1250
WRTYZ 1CA4 SOCAL 2
SFIO
191B SOCAL 2
SDFIO 18C7 SOCAL 3
SYSTEM SUBROUTINES
ILS04 00C4
ILS02 00B3
FLIPR 1684
llDA (HEX) IS THE EXECUTION ADDR
At this point, you have a choice: accept the
program as a one-hour job, or work on it further
to speed it up. Since it is used quite often, you
decide to give it one last check.
Section
90
A. Read input cards
INPUt
B. Initialize
Sizes of the
Subroutines used:
*"*'
100 words
300 words
300 words
400 words
400 words
100 words
300 words
100 words
L
M
N
Q
I.
"* y
*'"
*Z
X
Type message:
"STEP NUMBER n"
*MAK£
TI-IEoSE
L()c,.QL
F. Write disk
record
G. Read disk
H. Compute
Call X-~
Call
Call
y-*
ANSW!f
Z_~
If not complete
J. Wrap-up
computations
K. Print results,
EXIT
Subsections
Page
I
07
40
30
Section
Subsections
Page
I
08
40
90
30
Step 5
After some study, we notice that the typewritten
message, block I, is the only non-disk input/output
in the entire program. It looks innocent enough, but
because of it, the entire Format Interpreter (SFIO)
is required, plus the Typewriter routine (WRTYZ)
and the typewriter code conversion routine (EBCTB).
The total size of this package may be determined
from the previous R44 message -- 514 (hexadecimal)
or 1300 words.
•
•
•
•
•
•
•
•
•
•
•
•
•
II XEQ TECH2 L
*FILES(l,FILEN)
FILES ALLOCATION
1 01A3 0001 7061 FILEN
22 aoua 0001 7061 01A7
STORAGE ALLOCATION
R 41 00F2 (HEX) vlDS UI'WSED flY CORE LOAl)
CALL TRANSFER VECTOR
N
lCA3
M
HH7
L
lA4B
p
19E7
Q
1857
l
16C7
Y
1663
X
1537
L I BF TRAI... SFER VECTOR
EADDX lD63
XDD
lE88
FARC
lE66
XMD
1E24
ELDX
1DCA
NORM
lDFA
ESBR
lDE6
ESTO
lDB8
EADD
1D5D
EDIV
1D04
EMPY
lCD6
EDVR
lCBE
FLOAT lCAC
SUBSC 14BE
SDFIO 12CA
SYSTEM SU~ROUTINES
ILS04 00C4
ILS02 00B3
llD7 (HEX) IS THE EXECUTION ADDR
Removing that message -- and the *IOCS
(TYPEWRITER) Card! -- we recompile the program
(calling it TECH2) and find, on execution, that it
runs with no SOCALs or LOCALs.
It now executes to completion in 15 minutes, as
we hoped, and the disk arm movement is reduced to
an occasional "click" as it moves from one cylinder
to the next in the data file area.
If a typewritten message is really needed, consider
using the TYPER routine of CSP - it is quite small
and does not use SFIO.
Section
90
A. Read input cards
INPUT
B. Initialize
C. Compute:
Call L
Call M
Call N
Sizes of the
Subroutines used:
D. Write disk
record
L
100 words
M
N
300 words
300 words
400 words
400 words
P
Q
E. Compute:
Call L
Call P
CallQ
IJROP T#/.5
PA~T OF THE
P/?OG-I-lays
Limited to
SeIdcJm..UsKt
Blocks
some basic
Program will
run at less
.......Top
"Top~n.
~",but
Continuously,
But Not in
between Disk
StatemenIs
Overlays Used
in between
DiskR-uwrite
Statemen1s
2. Since all subprograms are called during each
pass, we try to LOCALize only those that do not
appear inside the main disk READ/WRITE loop.
3. With excessive overlays still required, we
~ttack the main program and try to shorten it or
eliminate some of the subroutines it uses.
Case 1
Temporary files.
residing in WS,
are close to
overlay area
Average ann
movement
distance
probably not
enough to be
noticed.
Case 2
Smalto
MediumSize
Program
will run at
some basic
Program will
run at less
.......'Top
Program will
run noticeably
beIcwv"Top
"Top~'.
~',but
~',but
End of
probably not
enough to be
not too much,
since overlay .
WSI
noticed.
_isnottoo
flIr-..,from
datafile_.
Program will
run slowly,
since overlay
_isproportionately
FilesN..WS (lddle
Very
I..-ge
Program
will run at
Disk
some basic
Program will
run Id less
than "Top
Data
Files,
011 Small
Files Deep
insideUA
"Top~'.
~",but
probably not
enough to be
noticed.
funher-..,
from data
file_.
Program will
run slowly;
many ann
IIIINa'IIeIIIS of
short distance
will be needed.
The combination
of many ann
rnovsnent:s. and
Case 3
long dislances.
will cause this
type program
1D run considerabIy beIcwv
"Top~'.
Worst case!
Figure 90. 11.
File is in UA,
but still close
10 overIay_
File is in UA,
but far removed
from overlay
-
Figure 90. 12.
Section
90
Summary
To recapitulate the lessons learned in the preceding
three case studies, performance depends on five
major factors:
1. The size of the program. When writing any
program, you should anticipate problems with
core storage and performance. Plan programs of reasonable scope, and code them as
a series of LINKs, if at all possible.
2. The subroutines required by the program.
Realize that many seemingly innocent
FORTRAN statements can cause sizable subroutines to be included in your core load.
Some examples are PAUSE, STOP, FlND,
division, use of the data switches, etc.
FORTRAN control cards can have a similar
effect -- for example, unnecessary *IOCS
cards, the TRAC E, etc.
3. The way the program is structured. When
flowcharting and coding your programs,
always keep in mind the location of the disk
arm, so that you do not invite excessive arm
movement between the overlay area and the
data area. Place as little coding as possible
between disk READ/WRITE loops so that the
chance of an intervening overlay is reduced.
Figure 90.11 shows the various combinations
of data files and overlays.
Note that the location of the overlay has a
great effect on performance. If you must
move the disk arm from one area to the other,
you can at least try to minimize the number
of times it is required (or reduce the distance
involved, by making data files compact).
4. The overlay scheme used. If your program
is of such magnitude that some overlaying is
required, you should have a good feel for
how each works and how each can affect performance. Figure 90.11 shows that there is
no differentiation made between LOCALs,
SOCALs, and LINKs -- they are all overlays.
Note also that the number of times an overlay is required is not as important as the disk
Subsections
Page
I
01
40
40
arm movement that may be necessary to get
it. For this reason you should take particular
care to avoid causing an overlay to be placed
in between disk READ/WRITE statements.
LOCALs, because they are selected by
the programmer, will often yield better performance than SOCALs, which are chosen by
the CLB according to predetermined rules.
However, if you select LOCALs without
regard to their effect on performance, it is
possible that they can slow down execution
time even more than SOCALs.
5. The size and location of the data file. Since
you are concerned with minimizing disk arm
movement time, you should try to shorten
the distance involved.
The overlay area is always at the end of the
UA or at the beginning of WS, whichever way you
prefer to look at it. The data files may be either:
In the UA or FX, if you have put them
there with the *STOREDATA card
• At the end of UA (beginning of WS), if you
have not used a *STOREDA TA or *FILES
card
If you have a temporary file, in WS, your arm
movement times will be minimized, since the
files and the overlays are as close as they can
be. If your file is in the UA, however, the
picture may be quite different, depending on
how "deep" it lies in the UA. If a DUMPLET
shows that there is a great deal of distance
between the file and the end of UA, you should
consider moving the file. Figure 90.12 shows
three possible situations.
The key to gaining good program performance is
knowledge:
•
• Knowledge of the way in which the three
overlays work
• Knowledge of the basic workflow of your
program
Section
Subsections
I
INDEX
AlDEC: 70.30.00,70.40.10
Accidents: lS.10.60, lS.20.01, lS.20.10, lS.20.30, lS.20.S0, 15.20.60,
lS.20.70
Accounting controls: 10.30.00,20.01.00,20.10.01,20.10.10,20.10.20,
2S.40.40,40.20.00
Accounts payable: 10.40.S0
Accounts receivable: 10.40.20
Accumulator: 30.20.00, 4S.0S.30
Accuracy: 70.10.01,70.10.20
ADD: 70.10.30
Addend: 70.10.30
Addition area: 8S.10.10
Address calculation sorting: 7S.30.10
Alphabetic fields, comparing: 70.40.20
Alternating exchange sort: 7S.40.00
Arithmetic: 70.10.01
Binary: 70.10.20
Constant sUbscripts: 70.50.10
Decimal: 70.10.20,70.10.30
Extended precision: 70.10.20
Fractions: 70.10.20
Integer: 70.10.10
Interaction with I/O: 70.30.00
Real: 70.10.20
Real fixed point: 70.10.20
Real floating point: 70.10.20
Standard precision: 70.10.20
Variable precision: 70.10.20
Arithmetic statement function: 2S.40.40
Assembler: SO.01.00, 60.10.20
Assembler Language: 20.60.01
Audit: 20.10.10
Control: 20.30.10
Trail: 20.40.70
Auditors: 20.10.10
Augend: 70.10.30
Backup: lS.10.60, lS.20.60, 2S.40.40
Batch size: 20.10.10
Batch controls: 20.10.20,20.40.70
Billing: 10.40.10
Blocking factor (see "packing factor")
Bugs (see "errors")
CALL LINK: 65.10.S0
CALL PDUMP: 30.20.00
CALL TSTOP: 30.20.00
CALL TSTRT: 30.20.00
Cancellation: 20.10.20
Card data files
Backup: lS.IO.60
Changes to: lS.10.30
Size: lS.IO.S0
Card: IS.10.01
Design: 20.30.10
Formats: 40.30.00
Layout: 10.20.00
Layout form: 20.30.10
Paths: 4S.20.00
Punches: 4S.20.00
Punching: 30.01.00
Punching standards: 30.01.00
Readers: 4S.20.00
Verification: 20.10.10
Zone punches: 70.20.10,70.40.10,70.40.20
CARDZ: 6S.10.30
Cartridge identification: SS.10.00
Cathode ray tube: 4S.3S.00
Check, reasonableness: lS.20.40
Check register: 2S.40.60
Check writing: 2S.40.S0
COGO: 20.60.01
Collating sequence: 7S.10.00
Commercial Subroutine Package: 20.30.10,20.60.01,30.20.00,30.30.00,
70.10.20,70.10.30,70.20.01,70.20.10,
70.20.20, 70.30.00, 70.40.10, 70.40.20,
70.60.10,80.60.00,90.20.30
COMMON: 6S.10.S0
Comparing fields: 70.10.30
Components, nonstandard: 4S.4S.00
Computed GO TO: 30.20.00
Configurator: 4S.SS.00
Console
Debugging: 30.20.00
Display lamps: 4S.0S.30
Keyboard: lS.IOAO, 4S.05.10, 70.20.10
Keyboard input: 2S.40.1O
Continuous Systems Modeling Program: 20.60.01
Contour map plotting: 20.60.01
Control
Field, major: 7S.10.00
Field, minor: 7S.10.00
Key: 7S.10.00, 8S.10.30
Panel, punched card: 10.20.00
Tape: 10.30.00
Word: 7S.01.00
Controls (see "accounting controls")
Conversion: 40.1O~00, 40.20.00
Methods: 40.30.00
Copy a data file: 60.30.20
Copy a data file onto another disk: 60.30.30
Copy an entire disk onto another disk: 60.30.30
Copy a program onto another disk: 60.30.30
COpy program: 60.30.30
Core image format (see "disk data formats", "disk core image")
Core image buffer: SS.10.00, 60.10.20
Core load builder: 60.30.01, 6S.IO.30, 90.10.10, 90.20:00, 90.20.20,
90.30.40
Core storage
Dump: 30.20.00
Factors affecting:8S.1 0.30
Logical layout: 6S.10.00
Management: SO.01.00, 6S.01.00
Map: 6S.10.30
Reducing requirements: 90.20.30
Saving: 70.S0.00
Crossfooting: 20.10.20
CRT (see "cathode ray tube")
CSP (see "Commercial Subroutine Package")
Cutover: 40.30.00
One-time: 40.30.00
Cycle stealing: 70.20.01
Cylinder: 4S.IO.00, 80.10.00
Cylinder zero: 60.10.10,60.20.20
DASD (see "direct access storage device")
Data: lS.10.01
Area on disk: 80.20.00
Live: 30.01.00
Packing: 25.40.10
Switches: lS.10.40, 2S.40.40, 4S.0S.20, 6S.10.30
Types: 15.20.10
DATA statement: 70.10.30,70.20.20,70.40.20, 70.S0.1O, 70.50.20
Data Presentation System: 20.60.01
DCI (see "disk core image")
Debugging (see "programs, testing of')
Debugging, console: 30.20.00
DECAl: 70.30.00,70.40.10
Decimal arithmetic: 70.10.20, 70.10.30
Decision tables: 25.10.00
DEFINE FILE: 80.30.10,80.30.20,80.40.10,80.70.10, 8S.10.30
*DEFINE VOID ASSEMBLER: 60.20.20
*DEFINE VOID FORTRAN: 60.20.20
DELETE: 60.30.20
Desk checking: 30.40.00
Page
01
Section
Subsections
Page
I
02
Direct access storage device: 15.10.10
Disk (see "disk data file", "disk cartridge", etc.)
Disk arm movement time: 45.10.00
Disk cartridge: 15.20.20,45.10.00, 80.10.00
Checking of ID numbers: 55.30.00
Format of material: 60.30.01
ID numbers: 50.01.00
Number required: 50.01.00
Scratch: 50.01.00
Space on: 60.20.10
Disk core image: 60.30.01,80.30.20
Disk core image: format (see "disk data formats")
Disk data file: 15.10.01,45.10.00
Adding items: 85.10.10,85.10.20
Addition area: 85.10.10
Backup: 15.10.60,15.20.60
Changes: 15.10.30
Design: 20.30.10
Duplicate copies: 15.20.10
Hazards: 15.20.20
Inquiry: 15.10.40
Intentional modification: 15.20.20
Jobs involving more than one: 15.10.20
Organization: 85.10.01,85.10.20
Organization, choosing: 85.30.10
Organization, direct: 85.10.30
Organization, indexed sequential: 20.30.10,75.20.10,85.10.20
Organization, partitioned direct: 85.10.30
Organization, pure sequential: 85.10.10
Organization, random: 20.30.10,75.20.10,85.10.30
Organization, searching a pure sequential: 85.10.10
Organization, sequential: 75.20.10
Processing: 85.20.00
Processing, random: 85.20.00
Processing, sequential: 85.20.00
Reorganization: 15.10.30,85.10.10
Safeguarding: 15.20.01
Setup: 80.70.10
Size: 15.10.50
Space required: 80.40.00
Disk data formats: 60.30.01, 80.30(20
Conversion: 60.30.20
Disk drives
Logical: 50.01.00
Physical: 50.01.00
Disk file (see "disk data file")
Disk management: 50.01.00
Disk Monitor System: 50.01.00
Version I: 70.20.10
Version II: 65.10.00,70.20.10
Disk storage (see "disk data file", "disk cartridge", etc.)
Disk system format: 60.30.01
Disk Utility Program: 50.01.00,60.30.01
DIV: 70.10.30
Dividend: 70.10.30
Divisor: 70.10.30
Documentation: 10.01.00,15.20.70
Current system: 20.01.00
Old system: 40.20.00
Standards: 25.10.00
Document controls: 20.10.20
Document register: 20.10.20
DSF (see "disk system format")
Dump: 60.30.20
Dump a data file and reload: 60.30.20
Dumplet: 90.30.40
*DUMPLET: 60.20.10
DUP (see "Disk Utility Program")
Duplicate files: 15.10.60
EDIT: 25.40.50,70.30.00, 70.40.10, 70.40.20
Editing: 25.40.10
Input cards: 85.30.10
EDIT mask: 70.40.20, 70.50.10
Employee numbers: 85.10.30
EQUIVALENCE statement: 70.50.10
Error recovery sheet: 15.20.70
Errors: 15.20.20, 15.20.40, 15.20.50, 15.20.60, 15.20.70, 30.10.00,
40.30.00
Card punch: 30.01.00
Program logic: 30.01.00
Programmer clerical: 30.01.00
Programmer procedural: 30.01.00
Exchanging sorting: 75.30.10
Execution time (see "running time, factors affecting")
Executive: 40.30.00
Exponentiation: 70.50.20
Extended precision: 70.10.20,80.50.00,80.60.00
Fields: 10.10.00,80.20.00
Field size: 20.30.10
File maintenance: 20.30.10 (see also "disk data file, organization")
File organization: 20.30.10
FILES: 80.20.00, 80.30.20, 80.70.10, 90.30.30
FILL: 70.10.30,70.40.20
FIND: 65.10.30,70.50.20,90.20.30
Fixed area: 60.10.50,60.20.20,80.30.20,80.70.10
Fixed Location Equivalence Table: 60.10.50,80.30.20
Fixed point arithmetic: 70.10.20
FLET (see "Fixed Location Equivalence Table")
Flipper: 65.10.20,65.10.30
FLOAT: 70.40.10
Floating boundary: 60.10.40
Floating point arithmetic: 70.10.20
Flowcharts: 10.10.00,20.01.00,25.10.00,25.30.20,30.40.00
Format, AI: 70.40.10
Format, A2: 70.40.10
Formats, core storage required: 70.50.10
Forms
Design: 20.20.10,20.20.20
Preprinted: 45.40.00
FORTRAN: 20.60.01
Compiler: 50.01.00,60.10.20
Fractions: 70.10.20
FUNCTION, arithmetic statement: 25.40.40
FX (see "fixed area")
GET: 70.30.00,70.40.10
GO TO, computed: 30.20.00
Graphic output: 45.30.00,45.35.00
Half-adjust: 25.40.40,70.40.10
Hash total: 20.10.10,20.40.70
Hazards (see "disk data file, hazards")
Hexadecimal numbers: 30.20.00,45.05.30
High/low/equal compare: 70.40.20
IBM System/360: 45.50.00
IBM systems area: 60.10.20,60.20.20
ICOMP: 70.10.30
IFIX: 70.40.10
IF statement: 30.20.00
ILSOO: 65.10.40
ILS01: 65.10.40
ILS02: 65.10.40
ILS03: 65.10.40
ILS04: 65.10.40
Index: 25.40.20
Index to a disk data file: 85.10.01, 85.10.20
Maintaining: 85.10.20
Indexed sequential (see "disk data file, organization, indexed sequential")
Input data, errors: 15.20.70
Input stream: 55.20.00
Inquiry: 15.10.40
Insertion: 75.30.10
Inside controls: 20.10.20
Installation: 05.01.00, 05.30.00
Integer arithmetic: 70.10.10
Integers: 70.10.10,80.60.00
One-word: 80.50.00, 80.60.00
Interchangeable chain cartridge: 20.20.10
Internal sort: 75.10.00
Interrupt: 70.20.01
Section
Inventory: 10.40.40, 85.10.20
Involution: 70.50.20
*IOCS card: 65.10.30,70.20.20,70.50.20,90.30.40
IOND: 70.20.10
JOB: 55.10.00
Job management: 50.01.00
Job-to-job transition: 50.01.00
KEYBD: 70.20.10, 70.20.20
Keyboard, console: 45.05.10
Keypunching (see "cards, punching")
Key-tag pair: 75.10.00
Key verification: 20.10.10
Language selection: 20.60.01
Large real numbers: 70.10.20
LET (see "Location Equivalence Table")
Light pen: 45.35.00
Linear Programming: 20.60.01
LINK: 65.10.60,70.20.20,90.20.20,90.30.40
LINK area: 65.10.50
Load on call: 65.10.40
LOCAL: 65.10.20,65.10.30,70.50.20,85.10.10,90.20.20,90.20.30,
90.30.40
LOCAL area: 65.10.40
Location Equivalence Table: 50.01.00,60.10.40,80.30.20
Magnitude: 70.10.20
Main line: 25.30.20
Manpower requirements: 40.30.00
Master cartridge: 50.01.00
Matching: 20.10.20
Match/no match: 70.40.20
Mechanism Design System: 20.60.01
Merge order: 75.10.00
Merging: 75.10.00, 75.30.10
Minuend: 70.10.30
Modular programs: 15.20.50, 25.30.20
Monitor control record: 55.10.00
MOVE: 25.40.50,70.40.20
MPY: 70.10.30
NCOMP: 70.40.20
Negative balance: 20.10.20
Next record number indicator: 80.30.10,80.40.10
Nonstandard components: 45.45.00
Non-systems cartridge: 50.01.00
NSIGN: 70.10.30
Numbers
Binary: 45.05.30
Hexadecimal: 30.20.00,45.05.30
Numerical Surface Techniques: 20.60.01
NZONE: 70.40.20
Object code: 70.50.01
Operation manual: 15.20.70
Optical reader: 45.40.00
Optical System Design: 20.60.01
Order entry: 45.40.00
Outside controls: 20.10.20
Overlap: 70.20.01
Overlays: 65.10.30
PACK: 70.30.00,70.40.10
Packing factor: 80.40.00
Paper tape punch: 45.25.00
Paper tape reader: 45.25.00
PAPTZ: 65.10.30
Parallel operations: 40.30.00
Partitioned direct (see "disk data file, organization, partitioned direct")
Pass: 75.10.00
Patches: 30.40.00
PAUSE: 30.20.00,45.05.30,65.10.30,70.20.10
Payroll: 10.40.60, 15.10.20, 15.20.10, 15.20.50,55.30.00,80.60.00,
85.10.30,85.30.10
PDUMP: 30.20.00
Performance (see "running time, factors affecting")
Personnel: 05.01.00
Petroleum Engineering and Exploration: 20.60.01
PID (see "Program Information Department")
Subsections
Page
I
03
Pigeonhole sorting: 75.30.10
Pilot operation: 40.30.00
Planning: 05.10.00
For conversion: 40.10.00
For testing: 30.01.00
Plotter: 45.30.00
PNCHZ: 65.10.30
Precision: 70.10.01
Preinstallation: 05.01.00
PRINT: 70.20.10,70.20.20
Printer, console: 45.05.10
Printers: 45.15.00
Priority interrupt system: 70.20.01
PRNTZ: 65.10.30
PRNZ: 65.10.30
Processing, order: 15.10.10
Programmers, experience: 15.10.90
Program
Area: 65.10.50
Change authorization: 25.20.00
Changes: 25.10.00,25.30.20
Comments: 25.40.10
Modular: 15.20.50,25.30.20
Patches: 30.40.00
Testing: 30.01.00, 30.10.00
Type I: 20.60.01
Type II: 20.60.01
Type III: 20.60.01
Type IV: 20.60.01
Program Information Department: 50.01.00
Program informatiom manual: 35.10.10
Programming
Aids: 25.30.10
Modular: 25.30.20
Standards: 25.10.00
Project Control System: 20.60.01
PUNCH: 70.20.10,70.20.20
Punched card systems: 10.20.00
Punching cards (see "cards, punching")
PUT: 25.40.50,70.10.20,70.30.00, 70.40.10
Random file organization (see "disk data file, organization, random")
READ: 70.20.10, 70.20.20
Read/write heads: 45.10.00, 80.10.00
READZ: 65.10.30
Real arithmetic: 70.10.20
Real numbers: 80.60.00
Output of large: 70.10.20
Multiplication of large: 70.10.20
Record
Layout: 30.40.00
Length: 80.40.00,80.40.10
Length, computing: 80.50.00
Length, shortening: 80.60.00
Number: 85.10.30
Size: 15.10.70
Records: 80.20.00
Recovery: 15.20.60
Replacement selection: 75.30.10
Resident monitor: 65.10.10
Rotational delay: 45.10.00
Rounding: 70.10.20
Route accounting: 20.60.01
Route slip: 20.10.20
Run book: 15.20.70
Running time, factors affecting: 80.01.00,80.40.00,85.10.20,85.10.30
SAC (see "storage access channel")
Sales analysis: 10.40.30
Sample documents: 10.10.00
Satellite cartridge: 50.01.00
SCA (see "synchronous communications adapter")
Scientific Subroutine Package: 20.60.01
Scratch disk: 50.01.00
SDFIO: 65.10.30
SDFND: 65.10.30,70.50.20
Section
Subsections
I
Page
04
Searching an index: 85.10.10
Sectors: 45.10.00,80.10.00,80.40.00
Utilization: 80.40.00
Seek time: 45.10.00
Selective sorting: 75.30.10
Selective tracing: 30.20.00
Sequential organization (see "disk data file, organization, sequential")
Serial numbering: 20.10.20
SFIO: 65.10.30
SKIP: 70.20.10,70.20.20
SOCAL: 65.10.10,65.10.20,70.50.20,85.10.10, 90.10.10,90.20.20,
90.20.30, 90.30.40
SOCAL area: 65.10.30
Sorting: 15.10.10,15.10.20,75.01.00,75.10.00,85.30.10
Mechanical: 70.40.20, 75.20.20
1130 flowchart: 75.40.00
Sort phases: 75.10.00
SQRT: 70.50.20
Stabilization time: 45.10.00
STACK: 70.20.10
Stacker select: 25.40.30
Standard precision: 80.50.00, 80.60.00
Arithmetic: 70.10.20
Standards
Documentation: 25.10.00
Error handling: 25.10.00
FORTRAN labels: 25.10.00
Programming: 25.10.00
Statistical System: 20.60.01
Stock status: 15.10.40
STOP: 45.05.30,70.20.10
Storage access channel: 45.45.00
Storage costs: 15.10.80
*STORE: 60.30.20
*STORECI: 65.10.40
Store core image: 60.30.20
*STOREDATA: 80.30.20,80.70.10
Store data core image: 60.30.20
Strategy, testing: 30.10.00
STRESS: 20.60.01
String: 75.10.00
SUB: 70.10.30
Subjob: 55.10.00
Subprograms, subtypes of: 65.10.10
Subroutine library: 50.01.00
Subroutines: 25.30.20, 70.50.01
Devices not on your system: 60.20.20
Logarithmic: 60.20.20
Long argument lessons: 70.50.10
Trigonometric: 60.20.20
Unlikely to be used: 60.20.20
Subtrahend: 70.10.30
SUFIO: 65.10.30
Supervisor program: 50.01.00
Survey: 10.10.00
Survey questionnaire
Accounts payable: 10.40.50
Accounts receivable: 10.40.20
Billing: 10.40.10
Inventory: 10.40.40
Payroll: 10.40.60
Sales analysis: 10.40.30
Synchronous communications adapter: 45.50.00
System overlay: 65.10.30
Systems cartridge: 50.01.00
Systems testing: 30.10.00
Table lookup: 25.10.00
Tag: 75.10.00
Tag sort: 75.10.00,75.30.20
Teleprocessing: (see "synchronous communications adapter")
Temporary indicator: 55.10.00
Test decks: 30.10.00
Testing: 30.10.00,30.20.00,30.30.00,30.40.00
Throughput (see "running time, factors affecting")
Time
Rotational delay: 45.10.00
Stabilization: 45.10.00
Stamps: 20.10.20
Timing: 70.60.10
Trace: 30.20.00,30.30.00,45.05.20,70.10.20,70.20.20,70.50.20
Transfer vector: 65.10.10
Transmittal slip: 20.10.20
TSTOP: 30.20.00
TSTRT: 30.20.00
Type Composition: 20.60.01
TYPER: 70.20.10,70.20.20
TYPEZ: 65.10.30
UA (see "user area")
UDISK: 65.10.30
UNPAC: 70.30.00,70.40.10
Unused area: 65.10.70
User area: 60.10.40,60.20.20,80.30.20,80.70.10
Variable precision arithmetic (see "arithmetic, variable precision")
Variable summary sheet: 25.30.10
Verifier: 20.10.10
WHOLE: 25.40.40,70.10.20
Work Measurement Aids: 20.60.01
Working storage: 60.10.30,60.20.20,80.30.20, 80.70.10
WRTYZ: 65.10.30
WS (see "working storage")
X-punch: 70.40.20
Zero balance: 20.10.20,25.40.40
Zone punch: 20.30.10,70.40.10,70.40.20
lDUMY: 60.20.10
11-punch: 70.20.10,70.40.10,70.40.20
11-zone: 70.40.20
12-punch: 70.40.20
12-zone: 70.40.20
941 report: 25.40.70
1055 Paper Tape Punch: 45.25.00
1130 Configurator: 45.55.00
1131 Central Processing Unit: 90.30.20
1132 Printer: 45.05.10,45.15.00,70.20.10,90.30.20
1134 Paper Tape Reader: 45.25.00
1231 Optical Mark Page Reader: 45.40.00
1403 Printer: 45.05.10,45.15.00,70.20.01,90.30.20
1442 Card Read Punch: 45.20.00,70.20.10, 90.30.20
Model 5 Card Punch: 45.20.00
1627 Plotter: 45.30.00,90.30.20
2250 Display Unit: 45.35.00
2315 Disk Cartridge: 45.10.00, 80.10.00
2501 Card Reader: 45.20.00, 90.30.20
READER'S COMMENT FORM
C20-1690-0
IBM 1130 Computing System User's Guide
Please comment on the usefulness and readability of this publication, suggest additions and
deletions, and list specific errors and omissions (give page numbers). All comments and suggestions become the property of IBM. If you wish a reply, be sure to include your name and address.
COMMENTS
fold
fold
fold
fold
• Thank you for your cooperation. No postage necessary if mailed in the U.S.A.
FOLD ON TWO LINES, STAPLE AND MAIL.
C20-1690-O
.'
YOUR COMMENTS PLEASE •••
Your comments on the other side of this form will help us improve future editions of this publication. Each reply will be carefully reviewed by the persons responsible for writing and publishing this material.
Please note that requests for copies of publications and for assistance in utilizing your mM
system should be directed to your IBM representative or the IBM branch office serving your
locality.
..
fold
fold
........................................ .......................................................................... .
~
FIRST CLASS
PERMIT NO. 1359
WHITE PLAINS, N. Y.
BUSINESS
REPLY
MAIL
NO POSTAGE STAMP NECESSARY IF MAILED IN THE UNITED STATES
POSTAGE WILL BE PAID BY ...
IBM Corporation
112 East Post Road
White Plains, N. Y. 10601
Attention: Technical Publications
....................................................................................................................
fold
International Business Machines Corporation
Data Processing Division
112 East Post Road, White Plains, N.Y.IOSOI
[USA Only]
[BM World Trade Corporation
821 United Nations Plaza, New York, New York 10017
[International]
fold
C20-1690-0
TIrn~
®
International Business Machines Corporation
Data Processing Division
112 East Post Road, Whit.e Plains, N. Y. 10601
(USA Only)
IBM World Trade Corporation
821 United Nations Plaza, New York, New York 10017
(International)
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.3 Linearized : No XMP Toolkit : Adobe XMP Core 4.2.1-c041 52.342996, 2008/05/07-21:37:19 Create Date : 2012:08:25 11:13:37-08:00 Modify Date : 2016:07:28 10:19:20-07:00 Metadata Date : 2016:07:28 10:19:20-07:00 Producer : Adobe Acrobat 9.0 Paper Capture Plug-in Format : application/pdf Document ID : uuid:715f0cd7-35ca-469f-958f-912f6b612b1b Instance ID : uuid:8c04509b-7bcf-d74a-9a68-0c917d88fdbb Page Layout : SinglePage Page Mode : UseOutlines Page Count : 706EXIF Metadata provided by EXIF.tools