SC21 7742 3_System34_Concepts_and_Design_Guide_Jan82 3 System34 Concepts And Design Guide Jan82

SC21-7742-3_System34_Concepts_and_Design_Guide_Jan82 SC21-7742-3_System34_Concepts_and_Design_Guide_Jan82

User Manual: SC21-7742-3_System34_Concepts_and_Design_Guide_Jan82

Open the PDF directly: View PDF PDF.
Page Count: 376

DownloadSC21-7742-3_System34_Concepts_and_Design_Guide_Jan82 SC21-7742-3 System34 Concepts And Design Guide Jan82
Open PDF In BrowserView PDF
-- - -------- - -------

SC21 -7742-3
Fi le No. S34-34

•

II

IBM System/34
Concepts and Design Guide
Program Numbers

5726-SS1
5726-AS1
5726-F01
5726-RG1
5726-UT1
5726-CB1
5726-BA1

--- - - --- --.....
-- --------.-

SC21-7742-3
File No. S34-34

•

IBM System/34
Concepts and Design Guide
Program Numbers

5726-551
5726-A51
5726-FOl
5726-RGl
5726-UT1
5726-CBl
5726-BAl

Fourth Edition (January 1982)
This is a major revision of, and obsoletes, SC21-7742-2. New material includes
System/34 storage cc;>ncepts, IFILE programming considerations, print spooling,
the X.21 interface, and data processing security. Changes or additions to the text
are indicated by a vertical line to the left of the change or addition.
This edition applies to release 08, modification 0 of IBM System/34 and to all
subsequent releases and modifications until otherwise indicated in new editions or
technical newsletters.
Changes are periodically made to the information herein; changes will be reported
in technical newsletters or in new editions of this publication.
Use this publication only for the purposes stated in the Preface.
This publication contains examples of data and reports used in daily business
operations. To illustrate them as completely as possible, the examples include the
names of individuals, companies, brands, and products. All of these names are
fictitious and any similarity to the names and addresses used by an actual
business enterprise is entirely coincidental.
It is possible that this material may contain reference to, or information about,
IBM products (machines and programs), programming, or services that are not
announced in your country. Such references or information must not be construed
to mean that IBM intends to announce such IBM products, programming, or
services in your country. (For example, ideographic support is available only in Far
East countries.)
Publications are not stocked at the address below. Requests for copies of IBM
publications and for technical information about the system should be made to
your IBM representative or to the branch office serving your locality.
This publication could contain technical inaccuracies or typographical errors. Use
the Reader's Comment Form at the back of this publication to make comments
about this publication. If the form has been removed, address your comments to
IBM Corporation, Publications, Department 245, Rochester, Minnesota 55901.
IBM may use and distribute any of the information you supply in any way it
believes appropriate without incurring any obligation whatever. You may, of
course, continue to use the information you supply.

© Copyright International Business Machines Corporation 1979, 1980, 1981, 1982

Preface

This manual is primarily for System/34 designers,
analysts, and programmers who are changing a
centralized operating environment to a work station
operating environment. The reader should understand
how System/34 functions can be used in a centralized
environment. The System/34 Implementation course,
S2020 provides one way to obtain this information.
The manual is divided into the following segments:
Chapter 1. Introduction: Explains the need for careful
design and programming on System/34 in a work
station environment.
Chapter 2. System/34 Concepts: Reinforces many
concepts that are important in either a centralized or
work station environment and presents additional
concepts that should be understood before design and
programming in a work station environment begins.
Chapter 3. Design Considerations: Describes designing
displays, input documents, printer forms, files,
programs, and security and integrity for a work station
system.

Related Publications
• IBM System/34 System Support Reference Manual,
SC21-5155
• IBM System/34 Operator's Guide, SC21-5158
• IBM System/34 Command and OCL Statements
Reference Summary, GX21-7690
• IBM System/34 Data File Utility Reference Manual,
SC21-7656
• IBM System/34 Source Entry Utility Reference
Manual, SC21-7657
• IBM System/34 Sort Reference Manual, SC21-7658
• IBM System/34 Work Station Utility Reference
Manual, SC21-7663
• IBM System/34 RPG 1/ Reference Manual, SC21-7667
• IBM System/34 Installation and Modification Reference
Manual, SC21-7689

Chapter 4. Coding Techniques: Presents coding
examples that illustrate concepts explained in Chapters 2
and 3.

• IBM System/34 Data Communications Reference
Manual, SC21-7703

Chapter 5. Sample Applications: Presents a sample order
entry application and sample inquiry applications.

• IBM System/34 Interactive Communications Feature
Reference Manual, SC21-7751

Appendix A. Display Station Operations Requested by
Basic Assembler Programs: Describes the work station
data management operations that can be requested from
an assembler program.

• IBM System/34 Basic Assembler and Macro Processor
Reference Manual, SC21-7705

Note: This manual follows the convention that he means
he or she.

Prerequisite Publications

• IBM System/34 Screen Design Aid Programmer's
Guide and Reference Manual, SC21-7716
• IBM System/34 Overlay Linkage Editor Reference
Manual, SC21-7707
• IBM 5211 Printer Models 1 and 2 Component
Description ~nd Operator's Guide, GA24-3658

IBM System/34 Introduction, GC21-5153
IBM System/34 Planning Guide, GC21-5154

• IBM 3262 Models Al and Bl Component Description
and Operator's Guide, GA33-1530

I ·

IBM 5224 Printer Models 1 and' 2 Setup Procedures

iii

• .IBM 5224 Models 1 and 2 Operator's Guide,
GA34-0092
• IBM 5256 Printer Operator's Guide, GA21-9260
• IBM 5225 Printer Operator's Guide, GA34-0089
• IBM System/34 FORTRAN IV Reference Manual,
SC21-7706
• IBM System/34 COBOL Reference Manual,
SC21-7741
• IBM System/34 Installation Manual-Physical Planning,
GA21-9242
• IBM System/34 Physical Planning Template,
GX21-9280
• IBM System/34 BASIC Reference Manual, SC21-7835
• IBM System/34 System Measurement Facility
Reference Manual, SC21-7828

iv

Contents

CHAPTER 1. INTRODUCTION
CHAPTER 2. SYSTEM/34 CONCEPTS
SYSTEM/34 STORAGE CONCEPTS
Disk Storage . . .
Task Work Area
Main Storage . . .
Transient Area .
System Nucleus
Control Area . .
Assign / Free Area
Assign/Free Size
Nucleus Size. . .
User Area . . . .
SYSTEM/34 JOB PROCESSING
Jobs and Job Steps on System/34
Functions Performed During Job Processing
Command Processor
Initiator . . .
User Program
Terminator. .
System Input (SYSIN) Processing
System Input Processing Example
JOB MANAGEMENT AND JOB SCHEDULING
ON SYSTEM/34 . . . . . . . . . . . . .
Execution Priorities ' "
. . . . . . . . .
Placement of Jobs on the Input Job Queue
Changing the Position of a Job Within
the Input Job Queue . . . . . .
Execution Priorities of Jobs in the
Input Job Queue .
Initiating a Program
Dispatching. . . . .
Swapping . . . . .
Active Program List.
How the Swapping Function Uses the
Active Program List
Swapping Times . . .
Job Priority . . . . .
Execution Priority Hints
Nonswappable Programs
WORK STATION DATA MANAGEMENT
Data Fields in a Display Screen Format .
Field Attributes. . . . . . . . . .
Work Station Data Management Operations
The Work Station Buffer
Normal Operations . . . . . . . . . .
Modified Operations . . . . . . . . .
Operations Requested by Basic Assembler
Programs . .
FILE CONCEPTS
File Identification
File Organization
File Processing .
Delete-Capable Files .
Extendable Disk Files
Indexed Files With the IFILE Attributes.

1-1

2-1
2-2
2-2
2-2
2-3
2-3
2-3
2-4
2-4
2-4
2-5
2-5
2-6
2-6
2-8
2-10
2-11
2-17
2-18
2-20
2-21
2-23
2-23

2-24
2-25
2-25
2-26
2-27
2-29
2-32
2-35
2-36
2-37
2-37
2-38

2-40
2-42
2-43
2-43

2-44
2-46
2-49
2-50
2-51
2-52
2-53
2-55
2-57
2-58

PROGRAMMING ATTRIBUTES OF IFILES
2-60
File Locking and IFILES . .
2-60
Performance Considerations . . .
2-61
Keysorts and IFILES . . . . . .
2-61
2-62
File Sharing in Multiple Program Mode
2-62
Types of Files That Can Be Shared
2-62
Type of File That Cannot Be Shared
2-62
Accessing Records Added to Shared Files
File Sharing Considerations
2-63
2-63
Sector Protection . . . . .
2-66
File Update Programs . . .
2-68
Key Sorting for Indexed Files
IPL File Rebuild Function . .
2-69
Using a Disk File as Two or More Logical Files
2-71
Use of a File by an Inquiry Program in Single
Program Mode . . . . . . .
2-72
- 2-73
Inquiry Programs and IFILES . . . . . .
Offline Multivolume Files . . . . . . . . .
2-73
Third and Fourth Disk Drive Implementation
Considerations . . . . . . . . .
2-75
2-77
PRINTER CONCEPTS . . . . . .
Printer Data Management Output
2-79
System List Output . . . . . .
2-79
Example of Directing Printer Data Management
Output and System List Output . . . . . . .
2-79
Vertical Line Spacing Support for the 5225 Printer
2-80
Print Spooling. . . . . . . . . . . . .
2-81
Advantages of Print Spooling
2-81
Spooling Options During Configuration
2-82
Control of Print Spooling
2-82
2-82
Spool File . . . . . .
Spool Intercept Routine .
2-84
2-85
Spool Writer Programs .
Performance Considerations
2-87
Spool Commands
2-88
2-89
Identifying Your Spool Output
2-89
The COPYPRT Command . .
Using the STATUS PRT and COPYPRT Commands
2-90
Using Procedure Members and the
COPYPRT Command . . . . .
2-91
2-92
Related Spooling Documentation
LIBRARIES . . . . . . .
2-93
Types of Library Members
2-93
Library Format
2-94
Directory . , . . .
2-94
2-94
Library Size. . . . . .
2-96
Reuse of Library Space
Active User Library
2-97
Library Sharing . . . .
2-98
2-98
Storing Library Members in Disk or Diskette Files
Record-Mode Files . . . .
2-98
2-99
Sector- Mode Files . . . .
2-99
Saving a Library on Disket"
MENUS . . . . . . . .
2-100
Fixed-Format and Free-Fo .at Menus
2-102
PROGRAM ATTRIBUTES . . . . . .
2-105

Contents

v

SRT (Single Requestor Terminal) Program
Coding SRT Programs.
Acquiring a Display Station in an SRT Program
Releasing Display Stations from an SRT Program
';
Interrupting an SRT Program.
MRT (Multiple Requestor Terminal) Program
Coding MRT Programs
Acquiring a Display Station in an M RT Program
Releasing an'Acqulred Display Station from
an M RT Program
Interrupting an MRT Program
Maximum Number of Display Stations for an
MRT Program.
Releasing Requesting Display Stations from
MRT Programs
Ending M RT Programs
Canceling an MRT Program
Using the Attn Key to Release a Display Station
from an M RT Program
Never-Ending Program (NEP)
Coding Never- Ending Programs
Ending a Never- Ending Program
JOBS THAT RUN WITHOUT A REQUESTING
DISPLAY STATION.
SYSTEM-PROVIDED SECURITY
Password Security .
Security Classifications
Badge Security
Format of the Magnetic Stripe
Menu Security
File and Library Security
Security File Listing
INTERACTIVE COMMUNICATIONS FEATURE
(SSP-ICF)
SSP-ICF Sessions
Locally Initiated Sessions
Remotely Initiated Sessions
SSP-ICF Data Management
Autocall Capabilities
System/34 Finance Support Subsystem
Data Communications and the X.21 Interface
Communications Support Available with the
X.21 Interface .
SAMPLE INQUIRY APPLICATION USING SSP-ICF
Local Inquiry Program .
Remote Inquiry Program.
CHECKPOINT FACILITY (FOR COBOL AND
ASSEMBLER PROGRAMS AND SUBROUTINES) .
Checkpoint Restrictions
Checkpoint Considerations
RESTART FACILITY
Restart Considerations
Printed Output
Nonrestartable Job Step .
Removing Checkpointed Jobs
Operator Considerations .
System/34 and Distributed Data Processing
Environments
System/34 as a Processor Terminal
System/34 as a Host System
System/34 as a Subhost System
System/34 as a Peer Connection
Distributed Disk File Facility

vi

2-106
2,..106
2-107
2-107
2-108
2-109
2-112
2-112
2-112
2-113
2-113
2-114
2-114
2-115
2-115
2-115
2-117
2-117
2-118
2-120
2-120
2-121
2-123
2-123
2-124
2-125
2-127
2-128
2-129
2-129
2-130
2-131
2-132
2-133
2-133
2-135
2-136
2-136
2-138
2-139
2-140
2-141
2-142
2-142
2-144
2-144
2-144
2-145
2-146
2-146
2-147
2-148
2-149
2-149

CHAPTER 3. DESIGN CONSIDERATIONS.
DISPLAY DESIGN.
Identify the Displays .
Provide Meaningful Headings
Plan Readable Displays
Display a Small Amount at One Time
Maintain Consistencies Among Displays
Keep Operator Responses Short.
Provide One Idea for Each Display .
Acknowledge Operator Input
Make Error Correction Easy .
Provide a Means for Help
Make the Operator Feel Productive
Document the Displays .
Make the Screen Look Line the Source Document
Use SDA as a Documentation Aid
MENU DESIGN
FORMS DESIGN
Design Considerations for Output Forms
Design Considerations for Input Forms
FILE DESIGN
File Organization
Master File Organization .
Transaction File Organization
Volatility of Files
Activity of the Files .
Record Design
Determining Field Size
Providing for a Delete Code
Providing Extra Space .
Naming Fields
Documenting Record Layout
Record Blocking .
Physical I/O and Logical I/O
Blockitlg Records to Minimize Physical I/O
Access Method
Storage Index
Sequential Processing
File Sharing
Shared I/O
Access Algorithms for Direct Files
Determining an Access Algorithm
Handling Synonym Records
Examples
APPLICATION DESIGN
Data Entry Programs .
DFU Data Entry Programs
WSU Data Entry Programs
RPG II Data Entry Programs
The Badge Reader as a Data Entry Device
Editing in Data Entry Programs
Inquiry Programs
File Update Programs
Program Attributes
Disk Activity for Loading Programs and Attaching
Display Stations to Them
Minimizing Disk Activity to Increase Throughout
on the System
Program Size
Read-Under-Format (RUF)
Display Station Local Data Area
External Indicators .
DATA PROCESSING SECURITY AND ACCURACY

3-1
3-2
3-2
3-3
3-4
3-6
3-6
3-8
3-8
3-9
3-9
3-10
3-10
3-10
3-10
3-12
3-13
3-16
3-16
3-19
3-20
3-20
3-21
3-22
3-24
3-24
3-25
3-26
3-28
3-28
3-28
3-29
3-32
3-34
3-34
3-35
3-35
3-38
3-38
3-38
3-39
3-39
3-40
3-42
3-49
3-50
3-50
3-51
3-52
3-54
3-54
3-58
3-58
3-59
3-61
3-62
3-62
3-64
3-66
3-67
3-69

Physical Security . . . . . . . .
Physical location . . . . . . .
Limited Access to the Computer
Fire Protection . . .
Data Security . . . . . . . . . .
Limited Data Access . . . . .
Backup and Recovery Considerations
Method 1
Method 2 .
Method 3 .
History File
HISTCRT Procedure
Considerations For Remote Work Stations

CHAPTER 4. CODING TECHNIQUES .
Memo Updating. . . . . . . . . . . . . . . .
Program Communication with the local Data Area .
Using the PROMPT OCl Statement . . . .
Using the PROMPT OCl Statement with
PDATA-NO . . . . . . . .
Using the UPSI Parameter of the
PROMPT OCl Statement . . .
Using the PROMPT OCl Statement with
PDATA-YES . . . . . . . . . . . .
Protecting Records from Concurrent Updates
in an MRT Program . . . . . . . . . .
Protecting Records from Concurrent Updates
by Multiple MRT Programs . . . . . .
Using the local Data Area to Increase Sort
Program Flexibility . . . . . . . . . .
Using Data Structures for Multiple Line Displays
Accessing a Function Control Key or Command Key
in an RPG II Program . . . . . . . . . . . . .

3-69
3-69
3-69
3-69
3-70
3-70
3-71
3-72
3-74
3-75
3-76
3-79
3-80

Documenting the Application Program
System Test . . . . . . .
User's Run Book . . . . . . . .
Operator Program Run Book . . . .
SAMPLE INOUIRY APPLICATIONS USING SSP-ICF
local Inquiry Program . .
Remote Inquiry Program . . . . . . . . . . .

5-65
5-75
5-75
5-76
5-78
5-78
5-80

APPENDIX A. DISPLAY STATION OPERATIONS
REQUESTED BY BASIC ASSEMBLER PROGRAMS .

A-1

GLOSSARY.

B-1

INDEX . . .

X-1

4-1
4-1
4-5
4-7
4-9
4-9
4-12
4-13
4-15
4-17
4-19
4-26

CHAPTER 5. SAMPLE APPLICATIONS . . . . . . .
5-1
SAMPLE ORDER ENTRY APPLICATION
5-1
Documenting Application Functions
5-2
Designing the Screens
5-4
Designing Disk Files
5-12
Master Files . . .
5-12
Transaction Files .
5-14
Designing the Report
5-20
Considerations for Designing Output Reports .
5-20
Determining Program Requirements
5-21
System Flowchart
.
5-27
Building a Development Library .
5-29
Building a Development Menu
5-29
Creating Development Procedures
5-30
Using SEU to Update and Recompile
a Program (ZSEUR) . . . . . . .
5-30
Saving Disk Files (ZSAVEF) . . . .
5-32
Changing the Session Library and/or
Menu (ZLlBCHNG) . . . . . . .
5-33
Listings for Sample Development Procedures.
5-34
Creating Display Screen Formats
5-42
Coding the Programs
5-53
Coding with RPG II .
5-53
Coding with COBOL
5-60
Testing the Programs
5-61
Considerations for Program Testing
5-62

Contents

vii

viii

Chapter 1. Introduction

IBM System/34 is a general-purpose system that can be designed to operate
in a work station environment. In this environment, the system is available to
users via display stations and printers that are in their departments. A major
advantage of this environment is that users have access to current, correct
information in the system. Also, users can enter data directly into the system
and find and correct errors that might otherwise be overlooked.
Designing a system and applications that fit your business needs requires
activities such as planning displays, menus, input documents, output forms,
files, programs, and security and integrity procedures. Some of this planning
would be required for any type of system, but some additional planning must
be done especially for a work station environment. This manual provides
important information that you should know in order to design a system in that
environment.
A well-designed system should have the following characteristics:

Easy to Use: System/34 operators should not need to understand how the
system or its programs work. If the displays are understandable, if applications
are divided into logical steps, if written operator instructions are clear, and if
operator data entry is minimized, operators can be productive and make few
mistakes.

Provide Adequate Throughput: Throughput is the amount of work done by the
system during a period of time. You could determine for example, the number
of invoices,. orders, and inquiries that should be processed over a period of
time and design a system that can realistically meet those requirements.

Provide Satisfactory Response Times: Response time requirements can vary
significantly. For example, a 15-second response time might be adequate for
an inquiry program that is used occasionally, but a 2-second response time
might be required for an order entry application that is used for an hour or
more at a time.

Able to Change and Grow: A well-designed system allows for future
expansion. For example, the design should allow for additions of display
screens, printers, and new applications. Be aware that a design might be
adequate initially but might require major rework when the work load increases
or additional applications are installed.

Introduction

1-1

Provide Security and Integrity: System security and integrity should be planned
for the system so that information required for an audit can be maintained,
recovery from system failures can occur, and the system cannot be used
without proper authorization.

This manual has been written to help you design a system that has these
characteristics. Chapter 2, System/34 Concepts provides information that
should help you design and code applications that use system resources
efficiently. Chapter 3, Design Considerations provides considerations for many
of the design activities that you will do. Chapter 4, Coding Techniques
describes techniques that should be of interest to programmers. Chapter 5,
Sample Application describes the design and development of a sample order
entry application. These chapters can give you a better understanding of your
System/34 and of designing applications to meet the objectives you set.
If you are an experienced designer of work station systems, you would already
know much of the information in Chapter 3 and might want to skip that
chapter. If you thoroughly understand how System/34 works and are
interested mainly in designing the system, you might skip Chapter 2 and begin
reading Chapter 3.
Binary synchronous communications (eSC) between the System/34 and some
office product devices are available with an RPQ. These office product devices
are:
• 6640 Document Printer
• OS/6 Information Processor
• Magnetic Card II-Communicating
• 6670 Information Distributor
• 6240 Magnetic Card Typewriter-Communicating

1-2

Chapter 2. System/34 Concepts

This chapter describes concepts of System/34 that are important in a work
station environment. Understanding these concepts can help you plan your
design more confidently and evaluate the design considerations presented in
Chapter 3. The following concepts are described in this chapter:
• System/34 storage concepts: Describes the storage areas used by the
System/34.
• System/34 job processing: Describes how the SSP (System Support
Program) processes jobs and job steps.
•

Dispatching and swapping: Defines dispatching and swapping and explains
how the priority capabilities of the system affect dispatching and swapping.

• Work station data management: Defines work station data management and
explains how it works.
•

File concepts: Describes important System/34 file concepts such as file
sharing and sector protection.

• Printer concepts: Describes spooling and the differences between the
system list function and the printer data management function.
•

Libraries: Describes library members, library size, and active user libraries.

• Menus: Describes fixed-format and free-format menus.
• Program attributes: Describes single requestor terminal (SRT) programs,
multiple requestor terminal (MRT) programs, never-ending programs (NEPs),
and programs that release the requesting display station.
• Security: Describes the security functions provided by System/34.
• Interactive Communications Feature (SSP-/CF): Lists the communications
interfaces supported by SSP-ICF, describes the concept of sessions, and
briefly describes the SSP-ICF data management function.

System/34 Concepts

2-1

System/34 Storage Concepts
Understanding the storage areas used by the System/34 helps you use the
system efficiently. The following diagram illustrates the important storage
areas of the System/34.
Main Storage

Transient
Area

System
Nucleus
Task Work
Area

Disk
Storage

User
Area

DISK STORAGE
Disk storage is used by the system as a storage place for both programs as
well as files and libraries.

Task Work Area
Programs are moved from main storage to disk and from disk to main storage.
After they are removed from main storage, programs or portions of programs
are stored in the task work area (TWA) of the disk. Also contained in the TWA
are work areas used by active programs and control information used by the
system.
The size of the TWA depends upon:
• Number of display stations being used
• Number of programs running within the system
If a program tries to acquire more disk space than is available within the TWA,
the system attempts to allocate disk storage space. If there is enough
additional space, the system expands the TWA, although this reduces the
amount of space available for your files and libraries. An active program waits
until the necessary amount of disk space is available when there is not enough
room to expand the task work area.

2-2

MAIN STORAGE
Main storage contains programs, data, or instructions to the computer. It also
contains work areas used by both application programs and the system.
The following diagram shows the basic parts of main storage.

Transient Area
Control Area
System programs and system work areas

System NUCLEUS

Assign/Free
Share work area for system and user programs
User Area
User programs, extended disk data management
and terminator.

Transient Area
System programs not required to be in main storage all of the time are tailed
transient programs. There is a 2 K area of main storage called the transient
area which is used to contain these programs. Transients are loaded into the
transient area from the system library.

System Nucleus
The system nucleus manages system resources such as:
• Disks
• Printers
• Display stations
There are two main areas of the system nucleus:
• Control area
• Assign/Free area

System/34 Concepts

2-3

Control Area
The control area contains the programs and work areas used by the system.
Some of the items within the control area are:
• The SSP
• Work space used by the spool writer and spool intercept routine
• Work space used by the work stations
• The system routines that control your libraries and files on disk
• The system routines that control work station operations

Assign/Free Area
The assign/free area contains temporary storage space for both user and
system programs. The more programs you have executing the more the
system attempts to increase the size of the assign/free area by reducing the
size of the user area. The system issues a message when the assign/free area
can no longer be expanded.

Assign/Free Size
The maximum size of the assign/free area is 32 K bytes. The size of the
assign/free area is affected by:
• Number of active tasks
• Number of never ending programs (NEPs)
• Number of multiple requestor tasks (MRTs)
• Number of work stations varied on or signed on
• Number of open files

2-4

Nucleus Size
The size of the nucleus you create on your system is important in three ways:
• The smaller your nucleus, the more main storage you can use for your
programs.
• The larger your nucleus, the more system resource you can use at the same
time. A resource is either a program, a file, an NEP /MRT, and so on.
• The system can potentially provide better response time and throughput as
the nucleus increases in size.
You want to have a nucleus size that gives you the maximum amount of
main storage while obtaining the most work possible from the System/34.
The maximum nucleus size is 5DK bytes.

User Area
System/34 loads your programs into the user area of main storage before
running them. The user area also contains extended disk data management.
For more information about the nucleus size and performance, refer to Chapter
12 of the Planning Guide.

System/34 Concepts

2-5

System/34 Job Processing
A basic understanding of the steps in System/34 job processing can help you
design and code applications that more efficiently use System/34. This section
defines the differences between jobs and job steps and describes the major
functions performed during job processing. The following diagram shows the
major SSP functions that are used to process your job.

JOBS AND JOB STEPS ON SVSTEM/34
On System/34, a job is a unit of work initiated by an operator at a display
station or by a remote program that communicates with System/34 via the
Interactive Communications Feature (SSP-ICF). One or more programs can be
executed as part of a job. The execution of each program within a job is called
a job step. Any of the following methods can be used to start a job on
System/34:
• Entering OCl statements from the keyboard. When OCl statements are
entered from the keyboard, the execution of a single program is considered
to be a job. The lOAD and RUN statements, any OCl statements entered
between them, and any utility control statements are processed as part of
the job. OCl statements that are not entered between lOAD and RUN
statements are processed as individual jobs. For example, the setting of
switches via a SWITCH OCl statement that is not entered between a lOAD
statement and a RUN statement is a job on System/34.
• Running a procedure. The operator can cause a procedure to be run by:
Entering a procedure command from the keyboard
Selecting an item from a menu
Placing the procedure on the input job queue
The execution of the procedure requested by the operator is a job on
System/34. If the requested procedure runs other procedures, those
procedures are part of the job.
• Using the EVOKE OCl statement to evoke a different job from within a
procedure.
• Evoking the job from a remote program. that is communicating with
System/34 via SSP-ICF.
The SSP (System Support Program) assigns a unique job name to each job
that the operator submits. The SSP-assigned job name has the following
format:
wwhhmmss
where ww is the work station 10 of the requesting display station or the
session 10 of the associated SSP-ICF session, and hhmmss is the time the job
was submitted in hours, minutes, and seconds based on the 24-hour clock,
which is set by the system operator.

2-6

System Control Flow Overview

I

Starting
t h•
ystem

IPl

T

I

Work Station
Managemant

h

Command
Processor

'II
I
I

OCl from Display Station Batch

Processing
Commandl

I
I

Job Control
Inquiry

.-L

Dilplay
Station

-"

:)I

Batch Job Procedurel

Batch
Job
Queue

")I

I

Logical 1/0

1>

Messages, Prompts, Responses
D

-

,::::.,-;:

rr=0

SYSIN

Initiator

Task
Work

~-

_~Jl

.......

.......

Starting
a
Job

_-'

......

h

Messeges and Responses

....

OCl

.--

Source
SYSIN

j

...
Prompts,
Responses

OCl

_-_--

~~

~-

AlB

C/D

Disk
Initialization

File Names

... f-----'"
VTOC

Create
$SOURCE,
for compiler

B

-

"V

rr=8

~-Source
Library

~--

MSG MBRS,
UserPGMS

....

Active Disk Files

~

J
.

_Object
Library

History
File
Put

$WORK
for Sort

Program
Initiation

r-----

local
Area

Task
Work

......~-

Active
Disk Files

~~

1'..-

Assign/Free
$WORK
Pointers

r1
r1
I

-I
User
Program

Ru nning
a
Job

Active- Disk Files

Termination

Step
Termination

Term inating
a
Job

I

L

~

\)
Jo<.

SYSlOG

Readerl
Interpreter

Procedure
library

......

OCl

Keyboard
SYSIN

Keysort
for Index File

I
I

---j

Device
Allocate

Open

Data
Management

SYSllST

Close

History
File

}-

~

ll1
l-

Close files and update VTOC.

I

r. . .-----..I
Job
Termination

ContrOl Flow

,

Data Flow

>

j

System/34 Concepts

2-7

FUNCTIONS PERFORMED DURING JOB PROCESS I NG
When the operator enters a statement or command on a command display or
when he selects an item from a menu, the SSP function called the command
processor processes the entry. If a remote program requests a job to be run,
the command processor also processes the procedure command.

Command
Processor

or
Procedure Command
from
Remote Program

If the statement entered is a control command, the command processor
performs the requested function. If the statement entered is not a control
command, the command processor either passes control to the initiator
function of the SSP or attaches the display station to an active MRT program
if the procedure command is for an already active M RT program.

Command
Processor

or
Procedure Command
from
Remote Program

_ _•••

MRT Program

1
Initiator

The initiator reads and processes Oel statements for the job. When it
processes a RUN Oel statement, the initiator loads the requested program and
passes control to it. The RUN statement is the last Oel statement in a job
step.

Command
Processor

or
Procedure Command
from
Remote Program

1
Initiator

1

User
Program

2-8

•

MRT Program

When the step ends, the SSP terminator function performs system actions
necessary to end the step. If more job steps follow, the terminator returns
control to the initiator. If no other job steps follow, the terminator ends the job
and either returns control to the command processor for locally initiated jobs or
terminates the SSP-ICF session for remotely initiated jobs.

Command
Processor

MRT
Program

J

or
Procedure Command
from
Remote Program

r J
Initiator

--------.."

End of Job Steps
But Not
End of Job

End

~!b
Terminate
the SSP-ICF
session.

User
Program

J

L!::r--T-e-r-m-in-a-t-or-'"'
or
IL-----..J

.f-____

The following paragraphs provide more detailed information about the
functions performed by the command processor, the initiator, the user
program, and the terminator.

System/34 Concepts

2-9

Command Processor
The command processor is the SSP function that initially processes information
that the operator enters. When (1) the operator enters a command or selects
an item from the menu, or (2) a remote program sends a procedure command
request via SSP-ICF, the command processor checks the command entered or
checks the statement associated with the selected menu item to determine
whether a job should be initiated.
If the associated statement is an operator control command, such as the
STATUS control command, the command processor does not initiate a new
job. Instead, the command processor gives control to the SSP routines that
immediately execute the control command.
If the associated statement is not an operator control command, the command
processor next checks to see if the procedure command is a request for a
currently active M RT program. If it is, the command processor attaches the
display station or SSP-ICF session to the active MRT program. If it is not a
request for an active M RT program, the command processor passes the
statement to the initiator.

2-10

Initiator
The initiator uses the SSP system input function to read and process DCl
statements from the system input device, which can be either the keyboard at
the display station or procedure members in a library. During DCl processing,
the initiator checks each DCl statement for valid parameters. The initiator
function contains a routine for processing each of the DCl statements. These
routines are loaded and executed when required by the initiator.
Functions provided as part of the initiator function include:
• Processing substitution expressions and condition tests. (This function is
performed by the SSP system input function.)
• Checking the syntax of each DCl statement.
• Ensuring that required load members exist in the active user library or the
system library.
• Ensuring that required files exist and are compatible with the parameters on
the FilE DCl statement.
• Ensuring that required source and work files are available.
• Acquiring display stations for which REQD- YES is specified on the
WDRKSTN DCl statement.
• Releasing the requesting device if RELEASE-YES is specified on the A TTR
DC l statement.
• Ensuring that the available user main storage is at least as large as the job
region size. User storage occupied by nonswappable programs is not
available.
• Allocating the SSP work areas required for the job.
If the processed procedure does not request an active MRT procedure via an
INCLUDE DCl statement, the initiator loads the requested program and passes
control to it.
The initiator executes in the user area of main storage at the same priority level
as the program that is using the initiator.

System/34 Concepts

2-11

If the initiator processes a procedure call for an M RT procedure, the actions
performed by the initiator depend upon whether or not the MRT program is
already executing. If the MRT program is already executing, the initiator
attaches the display station to the. executing program; if the maximum number
of requestors is already attached, the initiator queues the display station to the
program. If the MRT program is not already active, the initiator processes the
statements (up to and including the RUN statement) in the MRT procedure,
loads the MRT program, attaches the display station to the program, and
passes control to the MRT program. When the MRT program releases the
display station, the initiator regains control and returns to the calling procedure.
For further information about MRT procedures and programs, refer to MRT
(Multiple Requestor Terminal) Program later in this chapter.
The suggestions listed under OCL Performance Considerations, which follows,
should help minimize Del processing time.

OCL Performance Considerations

Minimizing Del statement processing time is a good practice because
excessive processing of these statements can increase job initiation time. The
following suggestions should help minimize Del statement processing time:
• Use defaults whenever possible. For example, code:

1111~+1~ ~~!~~3n III 1111 Illnnllli IlliUUffi
not

• Avoid using comments on Del statements.
• Group Del statements. For example, all WDRKSTN statements should be
grouped together. Grouping statements allows the system to load individual
Del processing routines once instead of loading them many times.
• Avoid continuation lines. For example, code:

not

• Use the local data area only when necessary. Processing information in the
local data area requires additional disk accesses and can significantly
increase Del statement processing time.

2-12

• Use external switches rather than the local data area to condition the
execution of steps in a procedure.
• When a sort is executed after it is tested, use the 3 print option, which
prints only severe errors.
• After a procedure is tested, do not log Del statements to the history file.
logging requires that every Oel statement processed by the system be
written to the history file. Therefore, logging can significantly increase Oel
processing time.
• For interactive applications, avoid using the / / * statement to inform the
display station operator that a procedure has started. Instead, use the first
format displayed by the program to present that information.
• Limit the number of conditional expressions that are processed within a
procedure. The GOTO and TAG statements should help you limit the
number of conditional expressions that are processed.
• Use the PROMPT Oel statement to prompt for data that will be passed to
the program when it begins processing. Using the PROMPT statement in
this way allows the operator to key data into the first display while the SSP
processes the rest of the Oel statements for the job step.
• Use the PROMPT Oel statement to prompt for procedure parameters
instead of using the / / * statement to issue operator messages and then
prompting for input with ?nR? or ?nR'mic'? expressions. The / / * statement
and substitution expressions require more system activity than that required
to display prompts and input fields with a display screen format. For
example, a procedure displays selected records from a selected file. rf the
/ / * statement and substitution expressions are used to prompt for input,
the procedure could be coded as follows:

\tM it. < FIll LA EL'
1/1
III IIF 11 l' GOrT ER OR
\ tN t:.~ Sl A rfIN RE CO RD INIU MB EI<'
III
Ilil IF 12 R11 GO Ira ER OR
'lEN IllER EN D NG EC ORD NU MB I=IR'
III
II I F 1i3 R? I ~\ END 0 FIL E AS SU "IE. D'
-D1 SPL AN 111.. I.. RECO ROI, 1Z ?I- 18 1
--III ETIU N
- -. -- _.- -III AG ~tl w
III AUS \REQO PA,R~ ETIER--PRO~ __ CIt\N 1"r:~LED' ---

._,-

-'- - f - - i -

,-- f--

-f-

--. 1---,-...

.~

..__ ~_ .~~ J~~:~ :~~

.1. _ .____ L.I...I.__ L__

-f-

_.f---'-

System/34 Concepts

2-13

When this procedure is executed, the operator is prompted for one parameter
at a time. The operator presses the Enter f Rec Adv key after entering each
parameter. The same procedure could be coded to use the PROMPT Oel
statement. The procedure then could be coded as follows:

1//
~ srr ARll
N lUll
f.1IE IB R- irlR NF M. FO R~ rT- IDI SP 'lIA ~1
/V
III I F 11 111 F~ 72 11 GO TO G OD
I:)
-11"," _-!I]~l[ O~ ~ _rr -lEg BOR
~~ ~-~ O~ PT
>... ! ! , ! ! ! '1 ! I
ITO Is triA R,.
II
I1I1 r IG GO 010
I
tISP U~N 111 1. I,R EC DR DI, 1rl 11., 131
IV

I~

!-..

[oj

-

-

-

-

1-.•. _

--

._

.

..

--'---'--

,-~'-'-

_L- _ _

I

In this case, the display screen formats, DISPLAY1 and ERROR, are both in a
load member called TRYFM. Figure 2-1 shows the Sand 0 specifications for
the two displays. (Instead of coding Sand 0 specifications, you could use the
Screen Design Aid (SDA) to create the display screen formats.) When
DISPLAY1 is displayed, the operator is prompted for all three parameters. The
operator enters all three parameters and presses the Enter fRec Adv key.
Figure 2-2 shows the display screen when DISPLAY1 is displayed.

Note: The check for null entries, which is coded in this example, would not be
required if the fields were defined as mandatory-enter fields (Y in column 29
of the D specification).

Second Edition

System/34 Display Screen Format Specifications

Use this coding sheet only to define display screen formats for WSU
and $SFGR. This coding sheet could contain typographical errors.

GX21·9253- U/M 050'
Printed in U.S.A.
'No. of sheets per pad may vary slightly.

WSU Only

8>.
:>

Sequence
Number

~

Format

!

Name

9

r-

E

tf
I 2 3 456

S

"'~~

.!

~

~

'0

~::::;

Enter

.. ~

"C

- ..
eill ~g. t~
~c5

~-g

E'~ ~
.r 8 g

!j

~

~

~ zg.9~~~ ~ afiJi m

~

t

.! i

:;

.!! _

5u;ai~ §~.g~

Mode

~
u:

~

C

;

a a

...

~

j

~' ':~'> ~
Q)

IMSIPIL Ar1ll

w

~

~

Reserved

.~

a:_

~-g~!

:~ ~
I

~~

1

7 8 910111 j1314151617ISI19202122123

~ l~

~

2

3

i
i

Inse,\'
Mode
Record
Identifying
Indicators
1

2

Reserved

Key Mask

~
~

3

~

46 47 ~8 49 ~o 51 525354 55 56 57 sa 5960 61 6263164 65 66 67 68 69 70 71 72 73 747576 77 78 7980

I

Starting
Location

wsu

~I"IO I?

~

~~

Review
Mode
Record
Identifying
lridicators

I

..~ ,,," ~- 1!lj ,,~ Ii
I!' ".". j 1~1~1!'llll'!"~li
~ ,-...~ I~~ ! h~'""'>I'" lil~~

6"

~~~nce

0
OJ
C/)Wwa:
78 9 10111213141516171819202122232 252627282930313233343536373839404142 344

Field

"",,... .!

1 2 3 4 5

;. ~

1 TT1 TT111 I ITTI I I I I I

i~ ,,-, I.!
"'.",M_
~ I)
lili " . , . " """"". "'''' '" ..

I~
II

~ 11

1~'lou515253~45!15d515859606162636465666768697071

ron " "

~7374757E77787980

~I'Y

IEINIII~~ ~n~~lII~lb ~I~ 1111~lr

10m

I-++-l-I--I--Io

IIIJIE

10 It 1-1-1-1,
10
10EIND

~111'UI~I~

181111

N

ilN

10

10
Figure 2-1 (Part 1 of 2), Sand D Specifications for DISPLAY1 and ERROR

2-14

GX21·9253- U/M 050·
Printed in U.S.A.

Second Edition

System/34 Display Screen Format Specifications
~

>
Sequence
Number

1

1 J

a8~
e

Format

8.

Name

~

5 ~

~

z:'::;

~..

~ g.§.~

'0

~.!: ~ ~ ~ c5

..~

-



~~~~nce

'C

a;

u:

rr

_~

~

a:

:~~:w

~~~~

Identifying

Identifying

Indicators

Indicators

Record

'0

.~

Reserved

~

iii

J : ~~!~~~ 1jj! I

J

4

.8

Use this coding sheet only to define display screen formats for WSU
and SSFGR. This coding sheet could contain typographical errors.

~

Record

Reserved

Key Mask

~I---r--.--+--..---r--l

'C

~

~~!l!!!

j

~

~

56 7 8 9 10111113141516171819101122232'25161718293031323334353E373839404142 34445~647~849 05152535455565758 5! 60616163160 65 66 67 68 69 70 71727374757677 78 79 80

I I

I

I

I

I

I

I

I

I

I I

I

I

I

I

I I I

I

I

Starting
Location

Field
Name
Sequence
Number

~'T
Field

8.

~ wsu

.fE

F' Id N

"Length

:5~
.... 3

~

~

~

~
~

§

~

.~

B

W

~

)( c:

>

~ ~"C >
~ -g ~ ~
~
c§ -; ~ 8. ~ ~ ~ ~ ~ ~~] ~ ._~c:
- 8<~;~6~ 0 ';~~ ~
s..~ ~ ~ ~ ~ £::g. 'v. iEg . . -a.
0 ~..s 0 :E ::!: ~ « ~ .li 8 ~ £. :r

S:

&

~

~ ~
u: ~
~

~

c

~

~
~
§
J

Reserved

c

I~

Constant Data

0

~

....

~

8"

C

CD
a:
Ie
arne
~~
~ ~
2
2 -3--4-5--6-7--8-9-'-0-'-''-2-'3-'-4-'5-'-6-'7-'-8-'9-2-0-2-'2-2-1
1 2 3 4 56 78 91011121314151617181920212223225262728293031323 34 35 3~ 3738 3940 41 42~3 44 45 4647 4S 49505152 53 ~4 5515E 5758 596061626364 65 66 67 68 6970 7172 73 74757677 787980

olCl1 ItJlltJII714
o

-i

I~ ~

:;);3

81--'

I'~I\JIAII

illtl~

1~1~!I~lr}

ID

o
o
o

o
o
o
o
o

o
o

o
o
o
o
o
o
o
Figure 2-1 (Part 2 of 2). Sand D Specifications for DISPLAY1 and ERROR

System/34 Concepts

2-15

DISPLAY SELECTED RECORDS FROM A FILE
ENTER FILE NAME --->

WORK

ENTER STARTING RECORD NUMBER --->

00000001

ENTER ENDING RECORD NUMBER --->

000000102

Figure 2-2. DISPLAY1 After the Operator Enters Parameters

2-16

User Program
Each program allocates and opens the files that it uses. In RPG II, WSU (work
station utility), and FORTRAN programs, the programmer does not explicitly
code these operations. After opening the files, the user program begins
processing. Some of the services the SSP provides during execution of a user
program are:
• Disk data management, which controls the flow of information to and from
disk files. For information about disk files and disk file processing, refer to
File Concepts later in this chapter.
• Printer data management, which controls the flow of information to the
printer. For more information, refer to Printer Concepts later in this chapter.
• Optional spooling functions, which intercept printer commands and place
them in disk storage, creating a spool file. When requested, the spooling
function retrieves records from the spool file and prints them. For
information about spooling, refer to Printer Concepts later in this chapter.
• Work station data management, which enables the user program to present
data on a display screen by providing only a string of data fields and a
format name. Work station data management then displays the data in the
predefined format. For information about display screen formats and work
station data management, refer to Work Station Data Management later in
this chapter.
• SSP-ICF data management, which enables the program to communicate
with programs on the same System/34 (INTRA subsystem) or with
programs on another system. For more information, refer to SSP-ICF Data
Management later in this chapter.
After the user program completes processing, it closes the files it used and
passes control to the SSP terminator function. The RPG II, WSU, or FORTRAN
programmer does not explicitly code these operations.

System /34 Concepts

2 -17

Terminator

Normal Termination
When the user program goes to end of job or when the operator selects option
2 in response to a displayed error message, the terminator function replaces
the user program in main storage. The terminator performs the following
steps:
• Updates the disk VTOC entries
• Frees system resources, such as main storage and assign free are.a (system
queue space), that the program used
• Updates and initializes system data areas so that the SSP can initiate the
next job step
• Terminates all previously acquired SSP-ICF sessions established by the
program
If more job steps remain in the job, the terminator reloads the initiator so that
the next step can be run.
If the step just ended is the last step in the job, the terminator also performs
the following steps:
• Deletes all job files (RETAIN-J files) used by the job
• Deletes the reserve area that was requested for the job
•

Releases the requesting display station if it is still attached to the job and
returns control to the command processor so that the operator can request
another job

• Terminates the requesting SSP-ICF session if the program was requested
by a remote program and if the session is still active
• Frees the remaining system resources that were used by the job

2-18

Abnormal Termination
Abnormal termination of a program occurs when any of the following operator
actions are taken:
• The operator selects option 3 in response to a displayed error message.
• The operator interrupts the executing program and selects option 2 or option
3 from the Inquiry display for all programs except MRT programs. For MRT
programs, option 2 releases the display station from the MRT program and
continues with the next job step; option 3 releases the display station from
the MRT program and cancels the remaining job steps.
• The system operator uses the CANCEL control command to cancel the job.
• A program check occurs.
• The system detects an error condition during normal termination.
• The CANCEL keyword is executed in a procedure.
When an abnormal termination occurs for non- M RT programs, the terminator
is loaded. Any remaining job steps in the job are not performed. If option 2
was selected from an Inquiry display, the files that were being used by the
terminated job are closed. For all other types of abnormal termination, files are
not closed, and the following statements are true:
• Files contain all updates made before the abnormal termination.
• Any additions made to nonshared files do not remain in the file unless the
file is an I FI LE.
• New files are not added to the disk VTOC.
• If keys were being sorted when the termination occurs, the file is marked as
unusable. The index will be rebuilt by the IPL file rebuild function, which is
described later in this chapter.
When the terminator function ends, it returns control to the command
processor or terminates the SSP-ICF requestor session depending upon how
the job was initiated.
The terminator executes in the user area of main storage.

System / 34 Concepts

2 -1 9

SYSTEM INPUT (SYSIN) PROCESSING
The SYSIN (system input) function reads records from the input job stream,
which is either entered from the keyboard or read from a procedure member.
After reading a statement, SYSIN performs all substitutions and performs the
functions specified by the statements that control SYSIN processing. The
statements and expressions that control SYSIN processing are IF, 1FT, IFF,
RESET, ELSE, CANCEL, RETURN, END, GOTO, and TAG. For information
about these statements and expressions, refer to Chapter 5 of the SSP
Reference Manual.
After processing a statement, SYSIN gives the statement to the calling SSP
function. During job initiation, the calling function is the initiator; therefore, all
statements up to and including the RUN OCl statement are passed to the
initiator. After a job is initiated, the statements are passed to the system utility
program or the user program that requested system input processing.
The following example shows how SYSI N processes a typical statement. The
example is intended to give a general idea of how SYSI N works, and is not
intended to show the detailed logic of SYSIN processing. Before reading the
example, you should be aware of the fundamental rules of system input
processing:
• SYSIN processes a statement one field at a time from left to right. Fields
are delimited by blanks.
• Each time a substitution operation is performed, SYSIN goes back to the
first field in the record and begins processing the record again. This must
be done to allow for nested substitution.
• After all substitutions are performed, the length of the generated statement
must be less than or equal to 120 characters. The actual length of the
statement before substitution can be up to 240 characters.
• If substitution expressions follow the RUN OCl statement, job initiation time
increases due to increased disk read and write operations required by
SYSIN. You should use GOTO statements to make sure that conditional
expressions and substitution expressions that follow the RUN statement are
evaluated only if necessary.

2-20

System Input Processing Example
In this example, the following record is read from the input job stream:
$~PATAF1-?~'?2?'?FILE, fWI:C~ ! (t>

Step 1.

Identifies the first field as / /

represents a blank).

Step 2.

Identifies the second field as a valid system input expression (IF).

Step 3.

Examines the third field and determines that the field contains a
nested substitution expression. For a nested substitution
expression, the innermost substitution is performed first. Therefore,
SYSIN substitutes the value of parameter 2 (AR) into the
expression. After the substitution, the record looks like this:
S~PATAF1-?1'AR'?FILEJ ?WITC~ ! .

Step 1.

Identifies the first field as / /

Step 2.

Identifies the second field as a valid system input expression (IF).

Step 3.

Examines the third field and determines that the field contains a
substitution expression. SYSIN performs the substitution. In this
case, parameter 1 is undefined and the value AR is substituted.
The resulting record now looks like this:

II IF DATAF1-ARFILEI 'SWITCHI \.X1XXOOXX
.
I

'-y-I'-y-I \.

/,,,
Field 1

Field 2

i l l

Field 3

Field 4

Field 5

System/34 Concepts

2-21

Again, because a substitution was performed, SYSIN g03S back and begins
processing the record at field 1.

t> .

Step 1.

Identifies the first field as / /

Step 2.

Identifies the second field as a valid system input expression (IF).

Step 3.

Identifies the third field as an existence test. SYSIN performs the
test and, in this case, determines it to be true.

Step 4.

Evaluates the conditional expression formed by fields 2 and 3. The
conditional expression specifies that because a disk file labeled
ARFILE exists the remainder of the record should be processeci.
SYSI N discards the I F test (fields 2 and 3) and processes the
remainder of the statement, which now looks like this:

II SWITCH
7'

Xl XXOOXX

I,

Field 1

Field 2

I

FieL 3

After checking each field and determining that no further substitution or SYSIN
processing of the statement is required, the statement is passed to the
initiator.
Note: If the conditional expression is not satisfied, that is, ARFILE does not
exist on Fl, SYSIN discards the remainder of the record and reads the next
record from the input stream.

2-22

Job Management and Job Scheduling on System/34
The IBM System/34 lets you assume an important role in the management
and scheduling of your jobs. You can affect the order in which your jobs are
presented to be executed by the use of different job queue priorities in the
input job queue. You can affect the swapping and main storage processor
utilization of your programs by the use of different execution priorities.

EXECUTION PRIORITIES
You can specify four different execution priorities for your job or job steps.
These execution priorities may affect the swapping and the way your program
gains control of the main storage processor from the dispatcher. The
dispatcher is responsible for allocating the main storage processor to your
program. The four execution priorities are:
• High
• Medium
• Normal

• low
If you do not specify an execution priority for your job, the system assigns
your job a normal priority.
To specify the execution priority of your job(s), you can use the following:
•

PRTY command

•

/ / ATTR DCl statement

For further information about using the PRTY command and / / ATTR OCl
statement with execution priorities, refer to either the SSP Reference Manual or
to the Operator's Guide.

System/34 Concepts

2-23

Placement of Jobs on the Input Job Queue
The input job queue has five different· priority levels numbered 1 to 5. Priority
level 5 is the highest priority and priority level 1 is the lowest. By assigning job
queue priority levels to your jobs, you can· specify the placement of jobs on the
input job queue and control the order in which your jobs are presented to the
dispatcher to be executed. Jobs are placed on the input job queue on a
first-in, first-out basis within job queue priority level. This means that all jobs
with a level 5 job queue priority are presented for execution before jobs with a
level 4 priority, and that before a priority 4 job can be considered for execution,
all jobs with a job queue of 5 must have been dispatched. If you do not
specify a job queue priority for a job that is using the input job queue, the
system assigns your job a level 3 priority. The following illustration shows the
order in which your jobs are presented for execution based upon placement in
the input job queue.

Placement in Job Queue
by Job Queue Priority

Job Order Presented
for Execution

Priority

5

Job
F

Job
D

Job
B

Job
A

4

Job
C

3

Job
E

2

Job
G

...

..

Job
H

Job A

1

Job B

2

Job D

3

Job F

4

Job C

5

Job E

6

Job G

7

Job H

8

Changing the Position of a Job Within the Input Job Queue
You can place a job in a higher or lower priority within the input job queue by
using the CHANGE JOBQ command. The execution priority associated with
the job is not changed.

2-24

Execution Priorities of Jobs in the Input Job Queue
The execution priority of a job placed in the input job queue is normal unless
you use the PRTY command. If you use the PRTY command before placing a
job in the input job queue, the execution priority is equal to the value specified
on the PRTY command. If you use the PRTY command and do not specify a
value, your job is assigned the high execution priority.
If you use a procedure to place a job in the input job queue, your job has the
same execution priority as the procedure.
From the system console you can use the PRTY command to change the
execution priority of a job in the input job queue. When you change the
execution priority of a job, the job queue priority and its position within the job
queue priority are not affected.

Initiating a Program
When a _new program is to be initiated, the system arranges the programs by
execution priority in the active program list and begins initiation of the
programs with the highest execution priority.
The initiator on the system takes into account the following items regarding
execution priority:
• Execution priority may be specified multiple times in a job by the use of the
PRTY command or the / / ATTR Oel statement. Each job step may have
its own priority. The priority specified becomes effective as soon as the
syntax of the Oel statements are validated by the initiator.
• When you have an N RT (no requestor terminal) program, the priority of the
program is the same as the job that initiated the NRT program.
• When a job is started by the use of the / / EVOKE Oel statement, the
priority of the job evoked is the same as the job that evoked it.
• If you do not specify an execution priority for an MRT (multiple requestor
terminal) program, the M RT program has the same priority as the job prior
to the inclusion of the MRT program. If you attach a job to an MRT
program, your job has the same priority as the M RT program. When a job
is released from an M RT program, the job has the priority that was in effect
prior to the inclusion of the MRT program.

System/34 Concepts

2-25

DISPATCHING
Systems that allow only one program in main storage at a time waste
considerable processor time. For example, when the executing program waits
for an I/O operation, the processor is idle until the operation is complete.
System/34, on the other hand, provides a dispatching function that allows
multiple programs in main storage to share processing time. When a program
that is using the main storage processor waits for the completion of an I/O
operation or has executed for longer than a system-defined time limit, the
system dispatcher gives control to another program in main storage that is
ready to execute. The system dispatcher determines which program uses the
main storage processor next.
To determine which program should use the processor next, the system
maintains a list of programs that are in main storage and ready to execute.
That list is called the program ready list. The dispatcher gives control to the
program on the list with the highest execution priority. Programs are
dispatched on a priority first-in, first-out basis. The following chart lists the
dispatching sequence used by the System/34.

Execution Priority

Dispatching Sequence

System
High

2

Medium

3

Normal

3

Medium-low

4

Low

5

Note: The medium-low priority and system priorities are determined by the
SSP and cannot be specified by the user.
At certain times, the system assigns a priority other than what you have
specified. This assignment is temporary and is used to accommodate special
situations such as termination of a job.

2-26

SWAPPING
Even though dispatching enables two or more programs in main storage to
share the main storage processor, processing time can still be wasted. For
example, if a program is so large that no other program can fit in main storage,
the time that program spends waiting for I/O operations is wasted. Even if
two or more programs fit into main storage, considerable amounts of time can
still be wasted. For example, assume that two operators are running programs
that require those operators to enter information from their display stations and
that together the two programs, A and 8, occupy all the available user storage.
While one of the programs waits for an operation such as a disk or display
station operation to be completed, the System/34 dispatching function allows
the other task to execute.

Display Station W1

Main Storage

A
Display Station W2
B

In this situation, the main storage processor is not used continuously. For
example, after Program A requests input from display station W1, that program
waits in storage while the operator enters the input. If both programs wait for
input from display stations at the same time, the processing unit might be idle
for several seconds.
To make better use of processing time, System/34 provides a swapping
function that allows the total amount of user storage required by concurrently
executing programs to exceed the amount of main storage available for user
programs. During swapping, the system temporarily removes a program or a
segment of a program from main storage when the program cannot continue
to execute because it is waiting to use some resource on the system. The
system saves this program or segment of the program on disk so that another
program can use main storage.

Note: The system swaps the program only if the main storage area is needed
by another program.
The swapping function uses the execution priority of a job to help it determine
which jobs are to be swapped. The lower priority jobs in most cases are
swapped first, leaving the higher priority jobs in main storage for as long as
possible. The following chart lists the swapping sequence.
Execution Priority

Swapping Sequence

Low
Medium-low

2

Medium

3

Normal

3

High

4

System/34 Concepts

2-27

Ordinarily, swapping requires only fractions of a second. Most of the time, the
operator at a display station is not even aware that the job is sharing the
system with other jobs.
The following example shows how swapping can increase the total amount of
work that concurrently executing programs can perform.
Assume that programs A, 8, and C are executing concurrently and have the
same execution priority. The programs are the same size. Programs A and 8
are in main storage; program C has been moved to the swap area on disk and
is waiting to resume processing.
Display Station W3

Display Station W1

Main Storage
Swap Area

A
Display Station W2
B

The system knows that program C is waiting to execute when program A
requests input from display station W1. Program A will be inactive until the
operator enters information. Therefore, the system transfers program A to the
swap area on disk and transfers program C into main storage. Programs 8 and
C share the main storage processor until program A is ready to be swapped
back into main storage. In this example, the main storage processor will be
idle only when all three programs are waiting for work station input.
Display Station W3

Display Station W1

Main Storage
Swap Area

c
B

The following paragraphs further describe swapping on a general level, but
they are not intended to be a complete discussion of the topic. The
information presented, though not essential for successful use of System/34,
provides a general understanding of how swapping works and how it can
affect response time.

2-28

Active Program List
To keep track of the status of all active programs, the system maintains a list
(or queue) of all active programs. An active program can be either in main
storage or in the swap area on disk. The system uses the position of the
program along with the execution priority to decide which programs to swap in
and out of main storage.
Normally, programs on the active program list are in sequence by their
execution priority. All high priority jobs precede medium priority jobs, and
medium priority jobs precede low priority jobs. Low priority jobs are last on the
active program list. For example, if programs A and D are high priority jobs,
programs 8 and E are medium priority jobs, and programs C and F are low
priority jobs, the list of active programs might look like this:

A

Execution
Priority
High

0

8
Medium

E

C
Low
F

If you do not specify an execution priority or you specify normal execution
priority for your job, the system assigns a normal execution priority to your job.
The normal execution priority is considered equivalent to medium by the
system. The system can change this system-assigned medium execution
priority to a medium-low execution priority. This change occurs only when you
do not specify an execution priority and your program executes for longer than
a system-determined time limit without performing a display station read
operation. The time limit, called the interactive time limit, is approximately
(N+1) x 1/2 second (1/2 second=500 milliseconds), where N is the number of
display stations attached to the program. The interactive time limit also
deducts I/O processing time as well as main storage processor time.
For more information about the interactive time limit, refer to the System
Measurement Facility Reference Manual.

System/34 Concepts

2-29

The following examples show how a program's position on the active program
list can be changed, when you have specified an execution priority.
• When you specify an execution priority and your program performs a display
station read operation, that program is moved to the bottom of the list of
programs with the same priority.

Execution
Priority

High
Display Station Read

B
Medium

E

Low
Display Station Read
• When you specify an execution priority and your program exceeds the
interactive time limit, that program is moved to the bottom of the list of
programs with the same priority.

Execution
Priority

High

Exceeds Interactive Time Limit

Medium

Exceeds Interactive Time Limit

c
Low
F

2-30

The following examples show how a program's position on the active program
list changes when you do not specify an execution priority and you let the
system assign normal priority to your program. You should be aware that the
system initially considers normal priority equivalent to medium priority. .
• When your program exceeds the interactive time limit, that program is
moved to the top of a system defined list with medium-low priority. Only
the system can specify a medium-low priority for your program.

Execution
Priority
Medium
Exceeds Interactive Time Limit

y

Medium-low

z
c
Low

F

Your program remains in this medium-low classification until a display station
read operation is performed by your program. When your program performs a
display station read operation, the program is moved by the system to the
bottom of the list of 'the medium priority programs.

E

Execution
Priority
Medium

y

Medium-low

Z

Display Station Read Operation

c
Low

F

System/34 Concepts

2-31

Your program remains at the bottom of the list of programs with the same
priority until programs ahead of it perform display station read operations or
exceed their interactive time limit. When these conditions happen, your
program is moved up on the list. The following diagram shows the. movement
of program C on the active program list.

·. .
c

Display

_+- Station

Bt

Read

~--+-

Interactive
Time Limit
Exceeded

C
A

ct

B

How the Swapping Function Uses the Active Program List
The System/34 swapping function is activated whenever the status of an
active program changes such that swapping may occur. For example,
swapping can occur when a program issues a display station read operation.
As the first step in swapping, the system starts at the top of the list of active
programs and checks the status of the programs to determine whether a
program is waiting to be swapped in. The first swapped-out program of the
highest priority the system finds that is ready to swap back in is the program
that will be swapped in. For example, suppose that seven programs are on the
list. Of those programs, 2, 4, and 7 are swapped out, and 2 and 7 are ready to
run. If the active program list looks like this:

Execution
Priority
High

Active
Program List

Status of Program

4 • - - • • • • • • • • • • • • • • • •• Swapped out, not ready

6 .. · · · . . . . . ·· . . . . · · · . In main storage, waiting for display station input
Order
of
Search
for
Swapping
In

I

7 · · · · · · · · · · · · · · · · · - · · Swapped out, ready

3 · · · · · · - - · · · · · · - · · · · · In main storage, waiting for display station input
5 - · · · · · · · · · · · · · · · · · · · In main storage, executing
2

I

Swapped out, ready

I

In main storage, waiting for printer operation

1

Low

then program 7 is the program that will be swapped in.

2-32

I

If a program is ready to swap in, the system must determine which program or
programs to swap out. To determine which programs to swap out, the system
starts at the bottom of the active program list and searches for programs in
main storage that are waiting for input from a display station. The system
swaps out the first program it finds that satisfies the search and swaps in the
other program if enough storage is made available. The system might have to
swap out two or more programs to free enough main storage for the program
to be swapped in. In the preceding example, program 7 is to be swapped in.
As shown in the example, programs 3 and 6 are both waiting for display
station input. The system will swap out program 3, which has the lowest
priority on the list, and swap in program 7.

Execution
Priority
High

t

Order
of
Search
for
Swapping
Out

I
Low

Active
Program List

4
6
7
3
2

Main Storage

6
Swap Area

5
1

~

,

"">
4
7

2

3
~

-

-'"

If swapping out program 3 does not free up enough space for program 7, the
system continues searching until it finds another program or programs to swap
out along with program 3. In this example, program 6 is also waiting for
display station input and could be swapped out along with program 3.
Program 7 could then be swapped in.

System/34 Concepts

2-33

If the system does not find any programs waiting for display station input or if
the amount of storage used by the programs and the amount of unused
storage is not large enough to contain the program to be swapped in, the
system goes back to the bottom of the active program list and searches for
programs that have been executing in main storage for longer than 1/2
second, including I/O time. Such a program can be swapped out only if it is a
lower priority on the active program list than the program to be swapped in.
By allowing a program to execute for at least 1/2 second, the system avoids
constantly swapping a program in and out while the program uses little or no
processor time. For example, assume the following:
• Programs A, C, and D are in main storage.
• Of the programs in main storage, program A is waiting for display station
input, and program D had been executing for longer than 1 /2 second.
• Programs B, E, and F are swapped out.
• Of the swapped-out programs, programs E and F are ready to be swapped
in.
• The active program list is as follows:

A - - - - - - - - - - - - - - - - - - - - In main storage, waiting for display station input
B - - - - - - - - - - - - - - - - - - - - Swapped out, waiting for display station input

I

F - - - - - - - - - - - - - - - - - - - - Swapped out, ready

o -- -- ----- - --- -- - -- - -

I

E - - - - - - - - - - - - - - - - - - - - Swapped out, ready

c --------------------

2-34

I

In main storage, ready

I

In main storage, executing

The system begins with the highest priority program at the top of the active
program list and searches for a swapped out program that is ready to resume
processing. In this example, the first such program that the system finds is
program F. Therefore, program F is the program that will be swapped in.
Now, the system begins searching for a program or programs to be swapped
out to make room for program F. The system begins at the bottom of the
active program list with the lowest priority program and searches for programs
in main storage that are waiting for display station input. Program A is the only
such program and will be swapped out. If enough space still does not exist for
program F, the system returns to the bottom of the list and searches for
programs that have been executing for longer than 1/2 second. The first such
program the system finds is program D. Because program D is of lower
priority than program F on the active program list, program D can also be
swapped out to make room for program F.

Active
Program List
A
8
F
D

Main Storage

Swap Area

A
C

E

C

D

The swapping and dispatching activity just described is controlled by programs
that execute in control storage; therefore, the swapping and dispatching
functions are executing at the same time as the programs that are using the
main storage processor.

Swapping Times
The amount of time System/34 takes to swap a program or segment of a
program is directly related to the size of the program. The System/34 swaps
only as many 2 K byte segments of a program as is necessary. For example, a
12 K byte program might require about 90 milliseconds to swap in and about
130 milliseconds to swap out. By comparison, a 24 K byte program might
require about 140 milliseconds to swap in and about 230 milliseconds to swap
out. The actual swapping time will vary depending upon the disk drive being
used and other disk activity within the system.

System/34 Concepts

2-35

Job Priority
When assigning jobs to different priority levels within the input job queue and
specifying different levels of execution priority, your main goal is to process the
maximum number of jobs in the least amount of time.
You may want to use the input job queue and execution priorities to establish
groups of jobs with certain characteristics. For example, you may want to
assign all nonswappable jobs a specified job queue priority with a specific
execution priority, so that jobs that use display stations have been executed
before your nonswappable programs begin to execute. You may want to run
your testing jobs with one execution priority and your production programs
with a higher execution priority. You may want to assign execution priority to
programs based upon the following criteria:
• Main storage size of the program. You may want to assign a lower
execution priority to programs that use a larger amount of main storage.
• Whether the program can be run as an interactive or batch program. You
may decide to assign higher execution priority to interactive programs than
to batch programs, depending on your processing requirements.
• Amount of main storage processing time the program uses. You may decide
that a program that uses a large amount of main storage processor time
should have a lower execution priority than a program that does not use as
much main storage processor time.
• How much elapsed time it takes the program to run. You may want to
assign a high execution priority for a job that does not take a long time to
execute and complete its processing on the system.
• What kinds of demands the program. makes on system resources, such as
disk files. You may want to base your assignment of execution priority to a
job based on the total demands it makes on the system. For example, a
program that uses four files and a printer may have a lower priority assigned
than a program that uses only one file and does not use a printer.
• How important the program is to your data processing requirements and
deadline schedules. You may want programs that are extremely important to
your organization assigned a high priority every time they are run.
You may also let the system set the job queue and execution priorities for you.

2-36

Execution Priority Hints
In general, let the system assign execution priorities to your job(s): the normal
defaults can usually handle your job needs. However, you should be aware of
the following when setting your own execution priorities:
• Assign high priority to jobs requiring either fast response time at a display
station or quick throughput.
• Assign low priority to batch jobs that will run for a long time.
• Assign medium priority to interactive jobs that could be reclassified as batch
jobs by the system, based upon the processing requirements of the
program.

Nonswappable Programs
When you run the overlay linkage editor, you can specify that a FORTRAN,
COBOL, or assembler program is nonswappable. You cannot define an RPG II,
BASIC, or WSU program as nonswappable. A nonswappable program, once it
is initiated, remains in storage until the program completes. Because a
nonswappable program decreases the amount of· main storage available to
other programs, the amount of swapping usually increases when a
nonswappable program is being run. Therefore, the performance of other jobs
can be degraded when a nonswappable program is run. Because the
performance of all other programs may be adversely affected and the capability
of the system to initiate new jobs restricted, the nonswappable attribute should
be used only when absolutely necessary.
When a nonswappable program is run, the amount of main storage available
for swappable programs is diminished. The amount of storage used by a
nonswappable program is called nonswappable storage. The remaining user
storage is called swappable storage.

System/34 Concepts

2-37

Work Station Data Management
User programs that communicate with display stations use a system function
called work station data management to write to and read from a· display
station. A display screen format defines to work station data management
what information should be displayed and read from the display station. When
a program requests an operation, the program supplies to work station data
management the name of the format that defines the display. Formats used by
a program are kept in a library load member separate from the program. The
formats do not have to be kept in the library that contains the program. One
display format load member can contain up to 32 formats. For an RPG II
program, the default name of the display format load member consists of the
program name followed by the characters FM. For example, if the RPG II
program is called I NV, the default display format load member is named
INVFM. The FMTS continuation option on the file description specification
allows you to specify a different name for the format load member or *NONE
if only interactive communications formats are used.
Display screen formats are generated automatically by some programs or must
be defined by programmers for other programs. Examples of automatically
generated formats are those used by DFU (Data File Utility) and the RPG II
CONSOLE file. Examples of formats that must be explicitly defined by the
programmer are the formats used with RPG II WORKSTN files and the formats
used by WSU, COBOL, FORTRAN, and BASIC prbgrams.
If you are programming in RPG II, screen formats do not have to be defined as
the program name followed by the characters FM. You can also use the same
format member in more than one program.
The programmer defines display screen formats by:
• Using SDA (Screen Design Aid) to interactively define the formats. Detailed
information about SDA is in the SDA Reference Manual.
• Creating Sand D specifications. The programmer can use SEU to place
these specifications in a source member. For programs other than WSU
programs, these Sand D specifications are used as input to the $SFGR SSP
utility program, which generates the actual display screen format and places
it in a library load member. For WSU programs, the Sand D specifications
are included as part of the specifications for the program. The WSU
procedure calls $SFGR to process those specifications and generate the
display screen format. For detailed information about the entries on the S
and D specifications, refer to the SSP Reference Manual and the WSU
Reference Manual.

2-38

To use the functions provided by work station data management, the
programmer should know what kinds of information he supplies when he
defines a display screen format and how that information controls the
operations performed by work station data management. The following
sections describe:
• How information supplied by the programmer affects individual data fields
• How information supplied by the programmer affects the operations
performed by work station data management
Note: If you define a screen format that is larger than the screen size of the
display station that you are using, an error condition occurs. For example, if
your screen format is 1000 characters and you are using a 960-character
screen size, an error condition occurs.

System/34 Concepts

2-39

DATA FIELDS IN A DISPLAY SCREEN FORMAT
When the programmer defines a display screen format, he defines it in terms
of the fields on the display. He specifies each field as an input field, an output
field, or an output/input field.
Input fields are fields into which the operator can enter data. When a program
displays a format, input fields are normally blank. The contents of input fields
are sent to the program when the operator presses (1) the Enter/Rec Adv key,
(2) an enabled user command key, or (3) an enabled roll key or when the
operator exits from a field for which. auto-record-advance was specified.

Input Fields

Note: The vertical lines in the input fields are column separators, which can be
requested by the programmer when he defines the format.

Output fields contain data that the display station operator cannot change. The
contents of output fields are not returned to the program when the operator
enters the display.

2-40

The program can supply the information displayed in an output field, or the
programmer can provide the information as part of the format definition.
(Prompts and constant values specified when a format is created are output
fields.)

Output Fields

TRANSACTION QUANTITY
ITEM NUl":C.ER

P.O./MEMO REFERENCE
ITEM DESCRIPTION
PLEASS VERIFY ENTRY AND ACCEPT, CORRECT, OR CANCEL

R~C
c~m

ADV TO ACCEPT,
KEY 1

System/34 Concepts

2-41

Output/input fields contain information that is either supplied by the program
when it displays a format or specified by the programmer when he defined the
format. The display station operator may change the information in
output/input fields. The information is returned to the program when the
operator presses (1) the Enter / Rec Adv key, (2) an enabled user command key,
or (3) an enabled roll key or when the operator exits from a field for which
auto-record-advance was specified.

Output/Input Fields

Field Attributes
In addition to defining field type, the programmer defines the location of the
field on the display and the type of data that can be entered into the field (for
example, alphameric data or only signed numeric data). The programmer also
defines physical characteristics such as display intensity and whether or not the
field is blinking. The description of the $SFGR utility program in the SSP
Reference Manual explains each of the field characteristics that the programmer
can define. Chapter 3, Design Considerations presents some considerations for
designing displays.

2-42

WORK STATION DATA MANAGEMENT OPERATIONS

The Work Station Buffer
Work station data management uses an area in main storage called the work
station buffer (or work station queue space) as a buffer for work station
operations. For output operations, work station data management prepares a
format for transmission by merging data supplied by the program with display
control information from the format load member. The merged information is
placed in the work station buffer. Work station data management then
transmits the contents of the buffer to the display station. For input
operations, work station data management normally uses the work station
buffer as an input buffer for information received from the display station.
The size of the work station buffer is specified during system configuration.
The size of the buffer can affect system performance. If the buffer is larger
than necessary, the amount of storage available for user programs is
decreased, and more swapping might take place. If, on the other hand,
sufficient buffer space is not available ~or an operation, system performance
might be degraded. The action taken by the system when the buffer space is
not sufficient depends on whether the display station is a local or remote
display station.
If a format is being transmitted to a local display station and if the size of the
format exceeds the configured work station buffer size, work station data
management writes a portion of the user program to the disk and uses the
freed area as work station buffer space. After the information is transmitted,
the saved portion of the user program is returned to main storage, and the
program can resume processing. This activity affects system performance in
two ways:
• Additional disk operations are required to perform the display station output
operation. These additional operations increase the time taken to perform
the output operation.
• The space occupied by the user task becomes nonswappable until the
display station output operation is completed.
Normally, on a read operation from a local display station, the program is
swapped into main storage (if the program has been swapped out) when the
operator presses the Enter key. The SSP reads the information into the buffer
at the same time that the program is being swapped in. However, if sufficient
work station buffer space is not available, this overlapping of operations cannot
occur. Instead, the program is swapped into main storage, and work station
data management reads the data directly into the input area in the program.

System/34 Concepts

2-43

If a format is being transmitted to a remote display station and if sufficient
work station buffer space is not available for a display station output operation,
work station data management does one of the following:
• Save on disk any input information in the work station buffer and use the
freed space for the output operation.
• If enough space cannot be made available by saving input· data, work station
data management writes the data onto the disk and issues the output
operation from the disk area.
When input is received from a remote display station, work station data
management normally places the received data in the work station buffer. If
sufficient work station buffer space is not available, work station data
management writes the received data onto the disk. After the program is
swapped into main storage, the data is transferred from the work station buffer
or from the disk into the program's input/output area.

Normal Operations
Normally, when a program requests that work station data management send a
display screen format, work station data management accepts the request and
prepares the specified format for transmission by merging data supplied by the
program and display control information from the format load member stored
in the assign/free area of main storage. Work station data management places
the merged information in the work station buffer. The user program can then
resume execution without waiting for the format to be transmitted. After
transmitting the format, work station data management invites input from the
display station. The system will not accept input from the display station until
work station data management invites input from the display station.
When the user program requests work station data management to read the
information entered on the display, work station data management performs an
accept input operation, which waits for information to be entered from an
invited display station.
Input may have been invited from more than one display station attached to
the program. When a display station operator enters data from an invited
display station, work station data management causes the input data to be
read into the user program's buffer area.
Figure 2-3 summarizes these steps.
Note: Work station data management does not invite input if you use the
suppress input operation, which is described later in this section. If a program
attempts to read from a display station from which input is not invited, the
display station will no longer be able to communicate with the program.

2-44

User
Program
~-----

Buffer

User
Program

-----Buffer

Work Station
Data
Management

o

Work Station
Data
Management

o

Format Name
(DISP2)

Data from
Program
(customer name
and numbed

~

I

~
User
Program
1------1
Buffer

DISP2
Cust Name ABC
Cust No. 12345
Oty
Item

----

Work station data management transmits the
format and then invites input from the display
station.

---

Read
Request

The program requests work station data management to read from the display screen.

Work Station
Data
Management

r------

Work station data management merges data
from the program (in this case, customer name
and number) and display station control information with the format.

Format
(DISP21

Work Station
Data
Management

User
Program

The user program passes to work station data
management the name of the format to be
displayed (in this case, DISP2) and a buffer
containing output data fields to be supplied by
the program (for example, as the result of a
disk file access operation).

Buffer

User
Program

r-----Buffer

Input Data
for Program

Work Station
Data
Management

....

....

DISP2
Cust Name ABC
Cust No. 12345
Item
Oty
1234
100

Work station data management accepts the information entered by the operator (in th is case,
item number and quantity), and places the
information in the program's buffer area.

Figure 2-3. Steps in Normal Processing Using Work Station Data Management

System/34 Concepts

2-45

Modified Operations
When a programmer defines a display screen format, he can modify the
operations normally performed by work station data management, or he can
identify indicators that conditionally modify the operations when the format is
displayed. The following sections describe the modified operations that can be
requested. Each section refers to the columns on the S specification that
specify the operation. If the programmer uses SDA rather than the S
specification, he requests these operations by responding to prompts.

Erase Input Fields Operation

For an erase input fields operation, which is specified in columns 31 and 32 of
the S specification, work station data management blanks out the contents of
the input and output/input fields on the display. Work station data
management then invites input from the display. The format is not sent to the
display station on an erase input fields operation. Therefore, the programmer
might want to request the erase input fields operation when an application
requires an operator to enter information on the same screen time after time.
In such an application, the programmer should specify that the erase input
fields operation be controlled by an indicator. The first time the program
displays the format, that indicator should be off. The program should then turn
on the indicator for the next and succeeding times it issues the display. Each
time the display is issued with the indicator on, the input fields are blanked
out, and the operator can again use them for input. This technique is especially
important when a program communicates with a remote display station
because the amount of information transmitted to a remote display station
might significantly affect the performance of the jobs using the
communications line.

Override Fields Operation

For an override fields operation, which is specified in columns 33 and 34 of the
S specification, work station data management:
• Transmits the contents of conditional output fields if the output indicator is
on. A conditional output field is a field for which an indicator is specified in
columns 23 and 24 of the 0 specification. The field is transmitted only if
that indicator is on.
• Retransmits the attribute bytes for all field attributes controlled by indicators,
except the protect field attribute.
The override operation allows the program to override (modify) program output
fields on a display without retransmitting the entire display. Again, this
technique is especially important when a program communicates with a remote
display station, in that it reduces the amount of information transmitted over
the communications line.

2-46

An example of a program that uses the override fields operation would be the
following inquiry program. The first display issued by the program requests the
operator to enter the item number of the item to be displayed.

ENTER ITEM NUMBER _-__ (OR I TO END)

After the operator keys an item number and presses the Enter fRee Adv key,
the program retrieves inventory information about the item and displays it.

ENTER ITEM NUt-~6ER

I-I II II

ITEM NO.

DESCRIPTION

111111

ALUMINUM BATS

l

(OR I TO END)

PRICE

2.33

ON HAN::>
20

50L~

I
I

I
I
i

I'\

j

L

i
Ii

o

--..-~
System/34 Concepts

2-47

If the operator enters an item number that is not in the inventory file, the
program turns on the override-fields indicator and redisplays the first display.
(The override-fields indicator is the indicator specified in columns 33 and 34 of
the S specification for the first display.) The first display contains a message
field in line 24 that is displayed only when the override-fields indicator is on.
Also, the override"';fields indicator could be used to redisplay the incorrect item
number as a reverse-image field.

r-:

ER

ITEM NUM8ER

(OR I TO END)

ITEM NO.

DESCRIPTION

111111

ALU~1INUtf

ITEM NOT

BATS

PRICE
2.33

ON HAND
20

FOUND

Unless the suppress input operation is requested when the override fields
operation is performed, the operator can enter another item number.

2-48

,

SOLD

3

Suppress Input Operation

For a suppress input operation, which is specified in columns 35 and 36 of the
S specification, work station data management will not invite input from the
display station after transmitting the format to the display station. The operator
may enter information into input fields on the display, but he cannot enter the
display and return the input to the program until work station data
management invites input from the display station. The suppress input
operation should be used when multiple formats are displayed before input is
sent to the program. When mUltiple formats are sent, the suppress input
operation should be specified on all but the last display or the system will have
to do extra work to generate the displays.
Note: If an RPG II MRT program transmits multiple displays and does not
suppress input on all but the last display and if the operator interrupts the
program by pressing the Attn key before the last display is transmitted, the
program will be suspended. No other requestors will be serviced during the
inquiry request. No indication that the program is suspended is given to the
operators at the other display stations.

Operations Requested by Basic Assembler Programs
Appendix A describes the operations that can be requested by a basic
assembler program when it calls work station data management.

System/34 Concepts

2-49

File Concepts
This section describes these System/34 file concepts:
• File identification
• File organization
• File processing
• File sharing in multiple program mode
• File sharing consideration
• Sector protection
• File update programs
• Key sorting for indexed files
• I PL file rebuild function
• Using a disk file as two or more logical files
• Use of a file by an inquiry program in single program mode

2-50

FILE IDENTIFICATION
The SSP requires that you must be able to uniquely identify each file on the
disk. You can accomplish this by assigning a unique label, eight character
maximum, to each file on the disk. However, you can assign the same label to
more than one file as long as each of those files has a different creation date.
Groups of files, as well as individual files, can be uniquely identified. File labels
of files that belong to a file group contain one or more periods. The characters
preceding a period identify the file group. Examples of labels of files within a
file group are:
A.B.GO
A.B.INV
A.INV
A.ACCTS
A.PROll

!

A1.INV
A1.ACCTS
A1.PROll

}

A.B.GO
A.B.INV

}

Files in file group A

Files in file group A 1

Files in file group A.B

Only the SAVE procedure and the $COPY and $DElET utility programs can
process file groups.
If a file label does not contain one or more periods, the file is not a member of
a file group. User libraries cannot be processed as file groups.
Depending upon the disk storage capacity of your system, you can create up to
2008 files and libraries on your system.

System/34 Concepts

2-51

FILE ORGANIZATION
A file can have one of three types of file organization based on the
arrangement of records within the file: sequential, indexed, or direct. All three
types can be delete-capable files. For further information, refer to
Delete-Capable Files, later in this section.
In a sequential file, the position of a record depends upon the order in which
records are placed in the file. The first record placed in the file occupies the
first record position in the file. Subsequent records are placed in the file
sequentially.
A sequential file organization usually requires less disk storage than do indexed
and direct organizations.
In an indexed file, an entry for each record is stored in a separate part of the
file called an index. The index has a record key and record location for every
record in the file. An index allows a program to process required records by
referring to the record keys.
The index is divided into a primary area and an overflow area. The entries in
the primary area are in ascending order by record key. The entries in the
overflow area are the result of added records and are not neceSsarily in
sequence except for I FI lES. When the SSP does a key sort for the file, the
SSP merges the overflow entries into the primary area. Refer to Key Sorting
for Indexed Files later in this section for information about when the SSP does
a key sort.
You can bypass the checking of duplicate keys when you are randomly adding
records to an indexed file by specifying BYPASS-YES on the / / FilE DCl
statement. The bypass function is supported by the program-defined access
path and is not a file attribute. For example, if you have a shared file, one
access path used by one program may bypass duplicate key checking, while
the other access path used by another program may check for duplicate keys
being added to the file.
Because the BYPASS-YES parameter of the / / FilE DCl statement can result
in an indexed file containing records with duplicate keys, you should have a
method of checking to see that records with duplicate keys are not present in
an indexed file. For example, you might set an l1 indicator on to'check for
records with duplicate keys when using RPG II.

2-52

In a direct file, a relationship exists between records and their positions in the
file. In a direct file, the relative position of a record might be equal to a
program counter or a field value. The relative position also might be derived by
a formula or conversion technique (known as an algorithm) that the
programmer codes. Such an algorithm might result in a number of records
producing the same relative record position. Those records are called
synonyms, and a programmer must allow for their storage and retrieval in
alternative locations within the file. If a direct file is created as delete-capable,
unused record locations are initialized to hexadecimal FFs. If a direct file is not
created as delete-capable, unused record locations are initialized to
hexadecimal 40s (blanks).
Additionally, an algorithm might result in some record positions being
unoccupied. The algorithm chosen should be the best compromise between
wasted disk space and an unnecessarily large number of synonyms.

FILE PROCESSING
Programs process files by four basic methods: consecutive, sequential by key,
random by key, and random by relative record number. These program
processing methods should not be confused with physical file organizations.
The following table illustrates which processing methods can be used for each
file organization.
File Organization
Processing
Method:

Sequential

Indexed

Direct

Consecutive

Yes

Yes 1

Yes

Sequential by Key

No

Yes

No

Random by Key

No

Yes

No

Yes

Yes 2

Yes

Random by Relative
Record Number

10 nly consecutive input processing is valid.
2Changing the key in a record when processing an indexed file randomly by
relative record number results in the key in the data record being changed· and
not the index.

The consecutive method processes records in the order in which they
physically appear in a file. This method can be used for all three file
organizations. Records are read until the end of the file is reached or until the
program stops reading records. If a delete-capable file is processed
consecutively, any deleted records are bypassed when they are read.
Typically, sequential files are processed consecutively when all records in the
file are to be processed.

System/34 Concepts

2-53

When a direct file is processed consecutively, the contents of spaces left for
missing records are read as blank records. If a delete-capable direct file is
processed consecutively, the deleted records are bypassed when they are read.
When an indexed file is processed consecutively, the index is ignored.
Sequential-by-key processing applies only to indexed files. When an indexed
file is processed this way, records with entries in the primary index area are
processed in the order of their record keys. Records with entries in the .
overflow area are also processed when an indexed file having the IFILE
characteristic is processed this way. In a delete-capable file, the deleted
records are bypassed when they are read.
An indexed file can be processed sequentially in one of two ways: total file by
key or records within limits. Total file by key processes records in the order of
their key fields. Processing continues until all records with entries in the
primary area have been read or until the program stops reading records. If
IFILE support is used, all records can be accessed. Processing records within
limits allows a section of a file, a group of records, to be processed in key
sequence. Each section is identified by a lower limit, a starting key, and an
upper limit, an ending key.
Random processing by key allows records in an indexed file to be processed in
a sequence determined by the user. The user program specifies the record key
of the desired record. Disk data management scans the index portion of the
file until the key is found and then reads the desired record directly into the
user program. This access method allows the program to retrieve records from
the primary area and the overflow area. When a delete-capable file is
processed randomly by key, the deleted records are not available.
Random processing by relative record number allows disk records to be
processed in a sequence determined by the user. (The file is treated as a
direct file even though it is an indexed or consecutive file.) A particular record
can be processed independently of its relation to other records. All three file
organizations can be processed. randomly by relative record number. Relative
record numbers are used to identify records. These numbers indicate the
positions of records within the file in relation to the beginning of the file. The
relative record numbers are not disk addresses, but positive, whole numbers
that the SSP converts to disk addresses of the records. When a
delete-capable file is processed randomly by relative record number, the
deleted records are not available.
If you want to process an indexed file both by key and by relative record
number, you can define two logical files in your program for the same physical
file. This process is described in Using a Disk File as Two or More Logical Files
later in this chapter.
The relative record numbers can be in an ADDROUT file created by the Sort
program of the Utilities Program Product. An ADD ROUT file is a record
address file that contains binary, 3-byte, relative record numbers that indicate
the relative position of records in the file to be processed. A record can be
read from the ADDROUT file and used to access a record in the disk file.
Typically, sequential files are processed randomly when only a few of the
records in the file are to be processed and the user knows their relative
location. To process a sequential file randomly, the program should define the
file as direct.

2-54

DELETE-CAPABLE FILES
The extended disk data management function of the System/34 SSP allows
you to create a delete-capable file. User programs can then delete records
from such a file. Any file, regardless of organization and processing method,
can be created as delete-capable. When a direct delete-capable file is created,
all bytes in the file are set to hexadecimal FFs. When a record is deleted from
a delete-capable file, the SSP fills the record with hexadecimal FFs. Also, for
an indexed file, the key is marked as deleted, not the record.
If you use an ADD ROUT sort to access records in an indexed file and you
delete a record, the record is deleted, but not the key. You must reorganize
the file with a SAVE and RESTORE operation to delete the key.
When a primary, secondary, or demand file containing deleted records is
processed consecutively or sequentially, each deleted record (a record
containing hexadecimal FFs) is bypassed and the next record is read. When a
file containing deleted records is processed randomly with a CHAIN operation
by RPG II the no-record-found indicator is turned on when a deleted record is
accessed.

Note: The SSP checks the first byte of a record. If that byte contains a
hexadecimal FF, the record is bypassed.
Extended disk data management will not allow a record having hexadecimal FF
as its first byte to be written to a file during an output, add, or update
operation. If the first byte of the record contains a hexadecimal FF, an invalid
update/add/output completion code is returned to the user program.
You can add records to delete-capable sequential and direct files by using
relative record numbers. By using relative record numbers you must add a
record in the file in the place you want, if the record has been deleted before.
If you are using RPG II, the relative record number of the record to be added
to the file must be placed in the RECNO (continuation line of the F
specification) field. The relative record number must be the record number of a
deleted record. You code output specifications that contain ADD to add
records to a file. RPG II uses the relative record number from the RECNO field
to locate where the record is to be added to the file. If the relative record
number is not the number of a deleted record, a halt occurs and the system
issues a message that a duplicate record exists in the file.

System /34 Concepts

2 - 55

If you are using COBOL and specify relative organization for the file, you can
add records to delete-capable files also. When ACCESS is RANDOM or
ACCESS IS DYNAMIC is specified, new records are inserted into the file. The
RELATIVE KEY specified for the file must contain the desired relative record
number for this record before a WRITE is issued. When the WRITE statement
is executed, the record is placed at the specified relative record number
position in the file. If the relative record number is not the number of a deleted
record, a halt occurs and a file status return code indicating that a duplicate
record exists is returned to the program.
For RPG II programs, the delete-capable file must be defined as an update file
(U in column 15 of the file description specification) if records will be deleted.
To delete a specific record, DEL must be specified in columns 16 through 18
of the main output record line. The DEL applies to all OR extensions of the
main line.
For COBOL programs, the DELETE statement is used to delete records.
For BASIC programs, the DELETE statement is used to delete records.
When records are loaded or added to °a delete-capable direct file, the specified
relative record number must be the relative record number of a record that
contains hexadecimal FFs; otherwise, an error message is displayed and the
record will not be added to the file.
RPG direct files that are not delete-capable must be loaded using the CHAIN
operation.
DFU cannot be used to create delete-capable files or to delete records in the
manner described for the system delete function. DFU can, however, be used
to update, list, and inquire into delete.;..capable files in a manner similar to that
used for nondelete-capablefiles.
WSU does not allow records to be deleted. Therefore, a WSU program ends
abnormally if it tries to use a delete-capable transaction file. A WSU program
can, however, use a delete-capable master file.

2-56

EXTENDABLE DISK FILES
Specifying extendable disk files prevents your program from abnormally
terminating when there is no room in the data file to add additional records.
When you use a disk file on System/34, you can use the EXTEND parameter
on the FILE OCL statement to identify the file as being extendable. For an
extendable file, the SSP automatically attempts to allocate more space for the
file each time it becomes full. The value of the EXTEN D parameter specifies
the amount of additional space that is allocated. (If the file size was originally
allocated in blocks, the value of the EXTEND parameter is in blocks; if the file
size was originally allocated in records, the value of the EXTEN D parameter is
in records.) The specified value must be at least large enough to hold one
record. If a file is being shared and the various users specify different EXTEND
values, the EXTEND value for the user that caused the file to become full is
used for the extension. When a file is extended, all users can take advantage
of the additional file space, regardless of whether or not they specified
EXTEND on the FILE OCL statement.
The SSP attempts to extend an extendable file whenever it becomes full as the
result of one of the following situations:
• When an indexed or consecutive file is being created or added to.
• When a direct file is being created.
• When a record is read from a direct file for updating or is written to a
delete-capable file, and the specified relative record number is beyond the
end of the file. (If the relative record number is greater than the file size
plus the extend value, the SSP does not attempt to extend the file. In that
case, a no record found completion code is returned to the user program.)

System/34 Concepts

2-57

The following list describes how the SSP handles different types of extendable
files when they become full:
• Scratch and job files in the reserve area: The SSP displays a message when
such a file becomes full. The operator can then choose to have the SSP
copy the file into a larger space outside of the reserve area. The user
program will resume processing after the extend operation. If the operator
does not choose to extend the file, he can choose an option that returns an
end of extent completion code to the user program or an option that cancels
the user program.
• Direct and consecutive files: The SSP attempts to allocate the additional
space immediately following the file. If that is not possible, the SSP copies
the file to a larger area on disk and frees the area originally occupied by the
file.
• Indexed files: The SSP copies the file to a larger area on disk and then
frees the area originally occupied by the file.
If the SSP successfully extends the file, an informational message identifying
the file as having been extended is logged in the history file. Execution of the
user program then resumes. If the extend operation was not successful, either
because space was not available or because a disk I/O error occurred, an end
of extent completion code is returned to the user program.

INDEXED FILES WITH THE IFILE ATTRIBUTES
I FI LE support allows shared indexed sequential processing of all records in an
indexed file by keeping the entries in the index overflow area in sequence.
Without I FI LE support, indexed sequential processing is limited only to those
having index entries in the primary portion of the index. IFILE support requires
that both the extended disk data management and extended index data
management be selected during system configuration. Indexed files can be
given the IFILE attribute by specifying it on the FILE OeL statement or the
SETFILE or BLDFILE procedure.
The functions provided by I FI LE support require additional system resources.
These resources include processing and I/O cycles as well as additional main
storage. Therefore even though the function requires no recompilation of
programs, you should be selective of which files you give the IFILE attribute to.
Generally, IFILE support is advantageous only in file sharing situations where
indexed sequential processing is used while indexed random adds are being
performed. Large files with a low volume of records being added to the file are
the best candidates for I FI LE processing.

2-58

The following list summarizes the general functions and restrictions of the
IFILE support:
• IFILE processing allows shared indexed sequential retrieval of records that
have been added by shared indexed random users.
• IFILE processing does not change the indexed sequential add restrictions;
that is, you still cannot specify DISP-SHR with indexed sequential add
operations.
• The indexed sequential sequence of get, add, and update data management
operations are not supported with I FI LEs.
• Any binary key of hexadecimal zeros is not supported. There is no
restriction on decimal key values.
• Specifying DISP-SHR will assure that doubly defined files in one program
will have access to records added by that program.
• IFILE processing does not apply to the assembler language access method
called ISRI (indexed sequential random input).
Files having the IFILE attribute place additional demands upon system
resources. The following list summarizes some techn!ques you can use to help
performance on your system when using files with the IFILE attribute:
• Add records to the indexed file with the key values in ascending order if
possible.
• Use the KEYSORT procedure at either IPL or STOP system time, since
fewer entries in the index overflow area require less search time and
improve performance.
• Allocate disk space slightly larger than the expected file capacity.
Indexed files without the IFILE characteristic need to have the added keys in
the overflow area keysorted into the primary index area before records added
to the file can be accessed sequentially by key. Refer to Key Sorting for
Indexed Files later in this chapter for more information on. when the SSP does
a key sort.

System/34 Concepts

2-59

PROGRAMMING ATTRIBUTES OF IFILES

File Locking and IFILES
Beyond the normal sector protection of records being updated, I FI LEs have an
additional level of file protection: the entire file is locked so that the index
entries can be maintained in sequence, This additional level of protection can
cause some problems when a program updating records and a program adding
records are sharing the same indexed file. Record update programs mark the
file as being in use until the record update is complete and another operation is
issued by the same program. The record-adding program begins when the
operation is issued.
This condition occurs when any of the,following happen:
• Specifying IFILES as extend capable files.
• Accessing data records with index entries in the overflow portion of the file.
• Accessing records in the same sector as the next record slot.
• The area in the file where the next new record is to be placed is the next
record slot.
For example, assume three programs, P1, P2, and P3, are sharing an indexed
file that is an I FI LE. Program P1 uses the file first to update records. Program
P2 is adding records to the file, and program P3 is updating records. Programs
P2 and P3 wait until the record updating done by program P1 is complete and
program P1 does another operation.
Update

Add

Update

P1

P2

P3

(Wait)

Indexed
File

2-60

Performance Considerations
Performance with IFILEs can be slowed down by:
• A large overflow area in the indexed file
• A program that occupies a large area of main storage
• A small user area in main storage
These three factors affect the way the system uses I/O buffers for IFILE
support.
Performance may also slow down when adding records randomly by key to an
indexed file that has not had a keysort done for some time.

Keysorts and IFILES
Specifying an indexed file as an I FI LE eliminates the need for doing a keysort
each time you want to sequentially process the indexed file to gain access to
new records added to the file.
However, System/34 automatically keysorts IFILEs when:
• A job step terminates normally and the file is not a shared indexed file
• The last program using the shared index file ends

System/34 Concepts

2-61

FILE SHARING IN MULTIPLE PROGRAM MODE
System/34 supports file sharing in multiple program mode; file sharing allows
two or more programs to ~ccess the same file. DISP-SHR must be specified
on every FilE OCl statement for a file that is shared. For BASIC programs,
SHR must also be specified on the OPEN statement for the file.

Types of Files That Can Be Shared
Input and update files can always be shared. Add files, except for indexed add
files that are processed sequentially by key, can always be shared.

Types of Files That Cannot Be Shared
Files that are being created cannot be shared. An indexed add file that is
processed sequentially by key cannot be shared.

Accessing Records Added to Shared Files
Programs sharing sequential files always have access to added records.
Programs sharing an indexed file have access to added records, except in
either of the following situations:
• If records have been added to a file that is being processed sequentially by
key, the program cannot access records added to the file since the last time
the keys were sorted unless the file is an I FI LEo
• If records have been added to a file that is being processed consecutively,
the program cannot access records added to the file since the file was
allocated to the program.
Refer to Key Sorting for Indexed Files later in this section for information about
when the SSP does a key sort.
If a program that is adding records to a shared file is ended abnormally, the
records added before the abnormal termination remain in the file. If a program
that is adding records to a file that is not shared is ended abnormally, records
added before the abnormal termination are removed from the file unless the
file is an indexed file using the I FI lE support. If the system unexpectedly
stops (for example, as the result of a power failure), added records can be
recovered during the I Pl file rebuild process. For information about I Pl file
rebuild, refer to IPL File Rebuild Function later in this section.

2-62

FILE SHARING CONSIDERATIONS
If you want to share a file among programs or if you want to allow more than
one display station to process a file concurrently, consider that:
• Programs can share only permanent or temporary files.
• If you change a temporary file to a scratch file by specifying a RETAIN-S
parameter on the FilE Del statement, the file cannot be shared.
• The SSP protects sectors read for possible updating by one program from
being updated by any other programs. The SSP protects sectors by
assigning them to the program doing the update. Refer to Sector Protection
in this section for further information.
• If programs share more than one file, all programs should access the. files in
the same sequence to reduce the chances of a deadlock condition. Refer to
Sector Protection in this section for a description of this deadlock condition.

SECTOR PROTECTION
Sector protection is the SSP function of assigning sectors to a program when
that program reads records in the sectors for a possible update. A sector is a
256-byte area on disk and,is the smallest amount of data that can be read
from or written to disk during one operation.
How you set up record blocking within your application program affects the
number of records that are sector protected. A sector can contain more than
one record, and more than one sector can be assigned to the input blocks you
specify in your application program. Each record contained within a sector is
sector protected. For more information on how input blocks and sectors are
related, refer to Record Blocking in the next chapter.
A program that tries to update a record within a sector that is assigned to
another program must wait until the sector is released. A program releases a
sector by (1) completing the update, (2) performing an add operation, (3)
reading a different sector from the same logical file or (4) rereading the same
sector. (For information about logical files and physical files, refer to Using a
Disk File as Two or More Logical Files, later in this chapter.) Programs that
request an assigned sector for input only do not have to wait until the sector is
released.

System/34 Concepts

2-63

A deadlock condition can occur when update files are shared. For example,
assume that program A and program B are, updating two shared files, file 1
and file 2. Program A reads record 3 updating from the sector of file 1, and
program B reads record 2 for updating from the last sector of file 2.

Program A
Record
1

Record

Record

Record

2

3

4

File 1

First Sector

Record

Record

Record

3

4

5

File2

Last Sector
Suppose that program A tries to read record 5 from the last sector of file 2.
Program A must wait because the sector is assigned to program B.

Record
1

Record
2

Record

3

File 1

Record
4

Program A
(waiting)

.

Assigned to Program A
Program B
(waiting)

Record
1

Record
2

Record

3

Record
4

Assigned to Program B

2-64

Record

5

File 2

Suppose that program B tries to read record 1 from the first sector of file 1.
Program B must wait because the sector is assigned to program A.

Record

1

Record
2

Record

Record

3

4

File 1
Program A
(waiting)

Assigned to Program A
Program B
(waiting)

Record

1

Record
2

Record

Record

Record

3

4

5

File 2

Assigned to Program B
This condition of programs waiting for each other is called a deadlock. To
ensure that deadlocks do not occur and that a sector from a shared update file
is not assigned for a long time, always release a sector before reading a record
from another shared update file. A sector is released when it is rewritten to
disk, or a different sector is read.
For example, in RPG II programs, a good way of releasing a sector is to write
an output record that has no fields (columns 32 through 71 of the RPG II
output specifications specify no data). This rewriting causes the sector to be
released and requires no physical disk accesses.
Note: If the operator selects inquiry option 1 while the interrupted program has
a sector enqueued, the system does not resume execution of the interrupted
program until all sectors are released. The system then allows the operator to
enter another command or statement.
Interrupting a program that is updating records in an IFILE can cause a file
lockout condition which prevents you from accessing records in the file. The
file lockout condition can occur when a program updating records in the IFILE
is interrupted. For example, an operator presses the ATTN key and takes
option 1. The operator starts a program to add records to the file already
opened by the program that was interrupted.

System/34 Concepts

2-65

FILE UPDATE PROGRAMS
You should use care when updating disk files in any program that supports
multiple display stations. If a single logical file is used by two or more display
stations within the same program and if the program, after readin,g a record for
updating, does other read operations from the same file before actually
updating the record, the following error conditions can occur:
• An update or part of an update can be lost. For example, suppose a record
is read from File X and displayed at display station 1; then the same record
is read from File X and displayed at display station 2. If File X is not
shared, the update done by one display station might be destroyed by an
update done by the other display station. If File X is shared, an error
message is issued, and the second update is not done.
• The wrong record can be updated. For example, suppose a record is read
from File X and displayed at display station 1; then a different record is read
from File X and displayed at display station 2. If display station 1 tries to
update the first record but does not reread that record, disk data
management tries to update the last record read from File X.
• An update performed by another program sharing the file can be lost. For
example, suppose a record is read from File X and is displayed at display
station 1; then a record in a different sector of File X is read by the same
program and displayed at display station 2. The second read from File X
causes the SSP to free the sector containing the first record. Another
program that is sharing File X can update the first record. If display station
1 rereads and also tries to update that record using the original field values,
the updates made by the other program might be lost.

2-66

You can avoid the preceding error conditions by using one of the following
techniques:
• Before doing an update, reread the record and check that none of the fields
being updated have been changed since the record was displayed for
updating. If any of the fields were changed, redisplay the field for updating
or, if possible, do the update using the field values currently in the record.
• Protect records being updated by establishing a field in the disk records to
be used as a busy indicator. After reading and displaying the record for
update, place the busy indicator in the record and write the record to disk.
(The busy indicator might be the work station 10 and the program name.)
Subsequent attempts to access the same record should test for the busy
indicator and not allow access for update. The busy indicator should be
removed from the record when the update is done by the requestor or if no
update is to be done. If the possibility exists that another program might
update the same file concurrently, both programs must test and use the
same busy indicator.
If the program ends abnormally and you are not going to restart the
program, you should run another program that turns off the busy indicators
in records that were being updated by the program when it ended so that
programs that check the busy indicator can handle the record properly.
• Consider defining a separate logical file for each display station. Separate
logical files protect against updates by other programs, but they do not
protect against multiple updates within a single program. For further
information, refer to Using a Disk File as Two or More Logical Files, later in
this section.

System/34 Concepts

2-67

KEY SORTING FOR INDEXED FILES
After an indexed file is created or after an indexed file has records added to it,
the added keys exist in an overflow area. If the file is to' be processed
sequentially by key, the keys must be sorted to allow access to all records in
the file, unless IFILE support is being used. Even when IFILE support is being
used, key sorting is done by the system to limit the size of the overflow area.
The SSP sorts keys at the end of a job if the indexed file was created during
the job and the records were not placed in the file in key sequence.
Additionally, I FI LEs are keysorted at end of job when the system detects that
add operations are slow because of the size of the overflow area.
The SSP performs a special key sort at the end of a job when certain
conditions are met. The special end-of-job key sort is done if all of the
following conditions are true:
• The file is being used exclusively by one user, or the file is being used by
the last shared user.
• There was no overflow key area for this file when the file was first
allocated.
• All keys added to the file are in ascending sequence,. and the value of the
added keys is greater than the highest key in the primary key area of the
file.
The SSP sorts keys when a file is allocated to a program if ,all the following
conditions are true:
• The file has keys out of sequence because records were added to the file.
• The file processing method to be used is sequential by key.
• The file is not shared.
• The file is not being used by an interrupted program.
The system operator can request that the SSP sort keys at system shutdown.
To request a key sort, the operator can specify STOP SYSTEM or STOP
SYSTEM,SORT. The SSP sorts keys of files that (1) have had records added
to them and (2) have not had the keys sorted. That is, keys are sorted for files
that have overflow areas.

2-68

The SSP sorts keys during an I PL if the system operator enters Y in response
to the EXAMINE AND VERIFY THE DISK VTOC? (Y,N) prompt on the file
rebuild display and if the sort or merge flag is set on in the VTOC entry. These
flags are set during fOile processing whenever a duplicate key or an
out-of-sequence key is found. The flags may be set by disk data
management, diskette-to-disk copy, or index construction during I PL file
rebuild. Files might have keys out of sequence if a system shutdown was not
done before the I PL.
The SSP sorts the keys of files processed by some SSP utility programs.
When the following SSP utility programs or procedures are used to do the
indicated functions, the SSP sorts the keys in the file:
SSP Procedure

SSP Utility

Function

RESTORE
DISPLAY
ORGANIZE
TRANSFER
KEYSORT

$COPY
$COPY
$COPY
$BICR
$DDST

Restore a file from diskette
Display an indexed file
Organize a file to disk or diskette
Transfer a file from disk to diskette
Sort the keys of an indexed disk file
0

The SSP does not sort the keys of shared files. Therefore, records added to
those files cannot be accessed when the file is processed sequentially by key,
unless IFILE support is being used. To be able to access these added records,
you can use the KEYSORT procedure or the $DDST utility program. The
KEYSORT procedure does not execute until it has exclusive use of the file.
The KEYSORT procedure issues a warning message when records with
duplicate keys are found in an indexed file.

IPL FILE REBUILD FUNCTION
System/34 provides IPL file rebuild as a recovery function that (1) verifies the
integrity of the VTOC entry for each user data file and (2), if possible, corrects
the entry and/or the file itself. Therefore, the IPL file rebuild function should
be run during IPL following failures such as power outages and inadvertent
IPLs.
The IPL file rel:5uild function is controlled by options on the second IPL display.
From that display, the operator can (1) request file rebuild or bypass it, (2) limit
the function to only files that were being created or to all files, (3) request that
the labels of all files in error be displayed, (4) request that the VTOC entries for
nonrecoverable errors be deleted, and (5) request that checkpoint/ restart active
files be deleted.

System/34 Concepts

2-69

If disk file reorganization (COMPRESS) had not completed when the system
failure occurred, the IPL file rebuild function calls the $FREE utility to complete
the reorganization.
The I PL file rebuild function then examines each entry in the VTOC. If a VTOC
entry contains any of the following errors, the entry cannot be corrected:
• The file type is not sequential, direct or indexed
• The retention type is neither temporary nor permanent
• The record length exceeds 4096 bytes
• The file is an indexed file, and the key length is zero or exceeds 29 bytes
• The file is an indexed file, and the key position exceeds 999 bytes
• The file is an indexed file, and the key is not within the record
• The file is not located within the data file bounds
Because System/34 initializes the data space to hexadecimal zeros for new
sequential and indexed files, to blanks for direct files, and to hexadecimal FF
for delete-capable direct files, the I PL rebuild function can update the
end-of-data pointer in the VTOC entry to reflect records that were added to
the file.
Note: Records added to a file may be written on disk or may be in a main
storage buffer. If a failure occurs, only those records written on disk can be
located in order to update the VTOC entry.
If the file is an indexed file, the entire index is reconstructed if (1) the
end-of-data pointer is updated, (2) the sort or merge flag is set on in the
VTOC entry, or (3) the number of indexes is not equal to the number of
records.
In the VTOC entry for an indexed file, a flag (sort or merge) is set on during
file processing whenever a duplicate key or an out-of-sequence key is
encountered. This flag may be set on by disk data management,
diskette-to-disk copy, or index construction during IPL file rebuild. If the flag
is set on, the IPL file rebuild function calls the key sort function.
Finally, the IPL file rebuild function ensures that all files with unique labels are
marked with the latest date indicator in the VTOC entry. For files with the
same label, the dates of creation must be unique, and only the file with the
most recent date is so marked.
The IPL file rebuild function then re-creates the disk control block to reflect
both available space and space in use on the disk.

2-70

USING A DISK FILE AS TWO OR MORE LOGICAL FILES
Each file defined within a program is called a logical file. A program can use
one disk file as two or more logical files. An RPG II program, for example,
may be written to access two files called FllEA and FllEB. If the following
FilE OCl statements are used:

then the disk file labeled MASTER is used as two different logical files by the
program.
An example of using multiple logical files could be a bill of materials program
that accesses a master file randomly by key and randomly by relative record
number.
Records added to one logical file can be accessed from a second logical file
except in the following cases:
• Records in the second logical file are being read or updated, and the file is
an indexed file being processed sequentially by key (unless the file is an
IFllE).
• The second file is an input-only file that is being processed consecutively.
If DISP-SHR is not specified on the FilE statements, records can be added or
updated in only one of the logical files. If DISP-SHR is not specified on the
FilE statements for multiple logical files, the following considerations exist:
• Records can be added or updated through only one of the logical files.
• If the input-only file(s) is being processed sequentially by key or
consecutively, added records cannot be read. In addition, updates to
records that have already been read into the I/O buffer are not available to
the input-only file unless it is an IFllE. For information about when records
are read into the I/O buffer, refer to Physical I/O and Logical I/O in Chapter

3.
• If the input-only file(s) is being processed randomly (either by key or by
relative record number), the file has immediate access to updated records.
• If the input-only file(s) is being processed randomly by relative record
number, added records cannot be read.
If DISP-SHR is specified, records can be added or updated in more than
of the logical files. Care must be taken, however, because the SSP does
protect against two logical files updating or adding to the same sector at
same time. If two logical files are updating or adding to the same sector
same time, only the update or add made last will appear in the disk file.

one
not
the
at the

Note: If the file is shared, the system does protect each logical file against
concurrent updates by other programs. The system does not protect against
concurrent updates from within the same program.
System/34 Concepts

2-71

USE OF A FILE BY AN INQUIRY PROGRAM IN SINGLE PROGRAM M()DE
In single program mode, the SSP allows an inquiry program to access active
files for input or update. Active files are those files that were being used by
the program that was suspended by the inquiry request. Updating an active
file is allowed only if the suspended program did not open the file for an
update or add operation. Active output files can never be accessed by an
inquiry program.
Figure 2-4 summarizes the types of file processing that can be used by an
inquiry program when processing a file that was being used by the suspended
program.

Interrupted Program
File Type

Abbreviation
Direct

Sequential

Indexed

Used

Meaning

A

Add
Consecutive
Input
Random by key
Sequential by key
Processing by the inquiry
program is not allowed
Output
Random by relative record
number
Update
Processing the inquiry
program is allowed

C

Access
Method

IS

IR

IR

IS

I

0 U A I

C

0 U A I

R

I

U I

Y

y2

n

n

I

y

n

y2 y4 Y

n

y2 y4 Y

0

n

n

n

n

n

n

n

n

n

U y3 n.n

n

y3 n

n

n

y3 y3 n

A

n

n

n

n

n

n

n

n

n

I

y

n

y2 yl Y

n

y2 yl Y

Y

y2

n

n

U y3 n

I

n

n

y3 n

y

n

y2 yl Y n

0 n n n

.
~.
A
··ii

;.}

n

n

n

i/ it. [\

:.. :

i/

R

0 U A I

R

C

U I

U I

0 U

S

..

n

n

o

.................

...

R

.

•.....

...

y3 y3 n

.

.

i•..

.

.

............

..

.

y2 yl Y Y

y2 Y

n

y2 y2 Y y2 Y

n

n

n

n

n

n

n

I;.i·

\

.........

...........

n

i·./) li

...

.(

..
.......•.•.

.. } ...

y3 n
n

n

n

n

n

n

y3 n

n

n

n

I

y

n

y2 yl Y

n

y2 yl Y

Y y2 Y

n

y2 y2 Y

0

n

n

n

n

n

n

n

n

n

U y3 n

n

n

n

n

y3 n

n

n

n

n

y3 y3 n

n

y3 n

n

n

n

I.·. .· .· . . .
y2 Y

n

y2

n

n

n

y3 n

n

y3 n

n

n
y'- Y

y2 Y n

y2

n

n

n

n

y3 n

n

n

n

n

y3 n

n

y3 n

n

The inquiry program can access all records in the file except those records added
by the suspended program.
'- Records retrieved by the inquiry program may not reflect the current status of
the file.
3 Records retrieved by the interrupted program may not reflect the current status
of the file.
4 The inquiry program cannot access records in the overflow area.
S Shading indicates an invalid access method.
I

Figure 2-4. Use of a File by an Inquiry Program in Single Program Mode

2-72

IR
IS
n

..

0 n n n n n n n n n n n

A n n n n n n n n n n n

C

R

C

U
y

Inquiry Programs and IFILES
Suspending the execution of a program that is updating records in an indexed
file that has the I FI lE designation and then executing a program that adds
records to this same indexed file may result in a condition known as an
enqueue failure. An enqueue failure is a condition where a program cannot
access the file. If an enqueue failure occurs, the Input Inhibited indicator on
your work station goes on until you press the A TIN key and take either the 2
or 3 option.

OFFLINE MULTIVOLUME FILES
An offline multivolume file is a sequential file that is used as though it
completely resides on disk but, in fact, is stored on one or more diskettes. The
portion of the offline multivolume file stored on one diskette is called a file
segment. Offline multivolume file processing uses a disk file as a work area in
which the offline multivolume file is processed a segment at a time.
An offline multivolume file is created when a FilE OCl statement for a diskette
file has the same NAME parameter as that on a FilE OCl statement for a new
disk file. For example, a program creates a disk file called PAYMSTR, which
requires 800 blocks of disk storage; however, 800 blocks of disk storage are
not available. In this case, you can create the file as an offline multivolume file
by using the following FilE statements:

Note: This example uses a diskette 1 diskette that has been initialized in the
128-bytes-per-sector format. The 96-block segment was selected to fully use
each diskette, but you might decide to specify smaller segments if disk space
is limited.
Now, when PAYMSTR is created, the system places records in the 96-block
file on disk. When all 96 blocks are full, the system copies the disk file to the
diskette in location M 1.01. The system places the next record written by the
program into the first record position in the disk file. When the file is again
filled, the system copies it to the diskette in location Ml.02. If all diskettes in
slot M 1 are filled in this manner, the system prompts the operator to insert
another magazine in slot M 1 and continue processing. (If AUTO-YES has been
specified, the system does not prompt the operator, but uses the magazine in
slot M2.) The system copies the last file segment to the diskette when the job
ends.
To process an existing offline multivolume file, you must again specify two
FilE statements with the same NAME parameter. The size specified on the
FilE statement for the disk file must be the same as the size specified when
the file was created.

System/34 Concepts

2-73

The following restrictions apply to offline multivolume files:
• They cannot be shared.
• They can only be sequential files and can only be processed by consecutive
processing methods.
• They can only be processed by means of the diskette magazine drive.
• Each access to an offline multivolume file must start with the first diskette
of a magazine. Therefore, M 1.01 or M2.01 must be _specified on the
LOCATION parameter of the FILE statement for the diskette file.
• Records added to an offline multivolume file must be added at the end of
the file. Therefore, the magazine containing the last segment in the file
should be inserted when an addition is to be made to the file. When
additions are made, the current program date becomes the creation date of
all the new segments and of the last segment of the old file.
• When segments are added to an offline multivolume file, the diskettes must
not contain any other active files.
• Only one offline multivolume file at a time can be processed by a step.
• A program running in inquiry mode cannot access an offline multivolume file
that was being used by the interrupted program.
• Offline multivolume files created by System/32 cannot be processed by
System/34. The offline multivolume files created by System/34 cannot be
processed by System/32.
• The size of the disk file cannot exceed the capacity of an individual diskette:
- For a diskette 1 diskette initialized in the 128-bytes-per-sector format,
the maximum file size is 96 blocks.
For a diskette 1 diskette initialized in the 512-bytes-per-sector format,
the maximum file size is 118 blocks.
- For a diskette 20 diskette initialized in the 256-bytes-per-sector format,
the maximum file size is 384 blocks.
- For a diskette 20 diskette initialized in the 1,024-bytes-per-sector
format, the maximum file size is 473 blocks.

2-74

THIRD AND FOURTH DISK DRIVE IMPLEMENTATION CONSIDERATIONS
You have additional disk capability and disk seek processing with the third and
fourth disk drives on the System/34. The SSP supports the additional disk
drives by extending the current definition of the logical name for disk drive A2.
The following chart shows how the physical configuration of the disk drives
and the logical disk name are related.
Logical Disk Name

A1

Physical Drive Configuration

A2

1,2

2

1,2,3

2,3

1,2,3,4

2,3,4

A1

Drive

Drive

1

2

Drive
3

Drive

4

Beginning Block
Number Location 25203

50406

75609

The SSP allocates space for the file you have specified on the / / FILE
statement by the following rules if you did not specify a location based upon
block number:
• If you specify disk A 1, the file is allocated in the first segment (lowest
address) on disk A 1 that is large enough to contain the file. If not enough
space is available on drive A 1, the SSP attempts to allocate the file on the
disk A2.
• If you specify disk A2, the file is allocated in the last segment (highest
address) on disk A2 that is large enough to contain the file. On a
three-drive system, this is the last segment of drive 3. On a four-drive
system, this is the last segment of drive 4. If not enough space is available
on the last physical disk of A2, the SSP attempts to find space on the other
drives that comprise logical disk A2. If not enough space is available, the
SSP attempts to allocate the file on disk A 1.

System/34 Concepts

2-75

The following chart shows the placement of files based upon file type and disk
drive configuration if you do not specify a preferred disk placement by block
number.

Number of Disk Drives

1

2

3

4

Permanent

A1

A2

A2

A2

Temporary

A1

A2

A2

A2

Scratch

A1

A1

A1

A1

Job

A1

A1

A1

A1

Type of File

Notes:
1. Permanent and temporary files are allocated in the
last segment of the disk large enough to contain
the file.
2. Scratch and job files are allocated in the first
segment of the disk large enough to contain the
file.
3. If not enough space· is available for placement on
a particular disk, the SSP can allocate a file that
spans the disks.

The manner in which you arrange your files on the disk can affect the
performance of your system. You should arrange the files on the disk so that
the utilization of the disk drives is approximately the same.
For more information on how you can obtain performance data about your disk
drives, refer to the System Measurement Facility Reference Manual.

2-76

Printer Concepts
Five types of printers are available with System/34: the IBM 5211 Line Printer,
the IBM 3262 Line Printer, the IBM 5224 and 5225 Matrix Line Printers, and
the IBM 5256 Serial Printer. These printers are described in the System/34
Introduction. Operating information for these printers is described in the
following manuals:
IBM 5211 Models 1 and 2 Component Description and Operator's Guide
IBM 3262 Models Al and Bl Component Description and Operator's Guide
IBM 5224 Printer Models 1 and 2 Operator's Guide
IBM 5224 Printer Models 1 and 2 Setup Procedures
IBM 5225 Printer Operator's Guide
IBM 5256 Printer Operator's Guide

One 5211 or 3262 printer can be attached to a System/34. Multiple 5256 or
5224 or 5225 printers can be attached to a System/34, either locally or by a
communications line.
The system printer, assigned dudng system configuration, should ordinarily be
located with the system unit and the system console. Any type of printer can
be the system printer. All printers other than the system printer are called
work station printers.
Display
Station

Display
Station

Work Station
Printer

Display
Station

Work Station
Printer

Work Station
Printer

System
Remote
Display Stations
and Printers

System/34 Concepts

2-77

When a program prints information, the program uses either the system list
function or the printer data management function of the SSP. The following
diagram lists those programs that use the system list function and those
programs that use the printer data management function.

Programs That Use System List
(prints on the system list device for
the session)

Programs That Use Printer Data
Management (defaults to the
configuration printer)

·

·

Print key
SSP data communication
programs
RPG II compiler
Utilities Program Product (SEU,
the job execution portion of
DFU, SDA, and WSU)

·
·
·
·

User-written programs
SSP Service Aids
COBOL compiler

·
·
·

2-78

SSP Utility Programs, except data
communications and service aid
utilities. Output from the menu build,
history display, display screen format
generator, and library maintenance
procedure use system list.

Privileged user-written assembler
programs
The job setup portion of DFU
The sort portion of the Utilities
Program Product

·
··

·
·

FORTRAN compiler
Assembler
BASIC

Printer Data Management Output

For individual files, you can direct printer data management output to a specific
printer by using a PRINTER OCl statement. If output is not directed to a
specific printer by a PRINTER OCl statement, printer data management output
is printed on the default printer assigned to the display station. The default
printer is assigned during system configuration and is shown as the
CONFIGURATION SYSLIST DEVICE on the second session status display. You
can use the SET procedure to change the default printer.

System List Output

System list output is printed on the system list device for the session. The
system list device for the session is shown as the SESSION SYSLIST DEVICE
on the second session status display. When an operator signs on, the default
printer becomes the system list device. The SYSLIST statement or procedure
can be used to change the system list device for a session.
If printed output is generated by a job run from the input job queue or from a
job that was run by an EVOKE OCl statement, the system printer is used
unless a PRI NTER OCl statement directs output to a specific printer or unless
the printer default for released jobs is changed during system configuration.

Example of Directing Printer Data Management Output and System List
Output

In this example, printer Pl was assigned to a display station during system
configuration. Now, however, the programmer would like to redirect all printer
data management output to printer P2. The following command statement
changes the default printer to P2:
SET """P2
After the SET statement is entered, all printer data management output is
printed on P2 unless the output is directed to another printer via a PRINTER
OCl statement. System list output continues to print on printer P1 or the
default printer for released jobs assigned during system configuration. After
the SET statement is entered, the second session status display shows P2 as
the CONFIGURATION SYSLIST DEVICE and printer Pl as the SESSION
SYSLIST DEVICE. If the operator then signed off and back on, both the
CONFIGURATION SYSLIST DEVICE and the SESSION SYSLIST DEVICE are
P2. If an IPl is performed, the default printer is not set to Pl, but remains P2
(the printer specified with the SET procedure).

System/34 Concepts

2-79

Vertical Line Spacing Support for the 5225 Printer
If you have a 5225 Printer, you' have the ability to specify the vertical line
spacing on your output reports without requiring the operator to set the
hardware switch on the printer.
You can specify a vertical lines-per-inch value either during system
configuration or by specifying the vertical lines-per-inch value on a FORMS or
PRINTER OCL statement or executing the LINES procedure.
The default value is six lines per inch. You can specify either four, six, or eight
lines per inch. If you do not specify a vertical lines-per-inch value on either
the PRINTER or FORMS OCL statements or the LINES procedure, you will
obtain the value specified during system configuration.
If you specify the vertical lines-per-inch values using OCl, you should specify
either the FORMSNO parameter or the LINES parameter when using the
PRINTER or FORMSOCL statements. This will help in setting the correct
number of lines per page of forms mounted on the printer and helps in
maintaining the proper page alignment on the forms when you change the
vertical lines-per-:inch value. You should initially run CNFIGSSP to assign the
default values for vertical line spacing for your 5225 Printer. If you do not run
CNFIGSSP, the SSP assumes a value of six yertical lines per inch.
If you specify a lines-per-inch value for a printer other than the 5225 Printer,
the value you specify is igpored by the system. The only way you can specify
a lines-per-inch value on printers other than the 5225 is by the use of a
switch on the printer.

2-80

PRINT SPOOLING
Print spooling is the capability of the SSP to save printer output on disk, in an
area called the spool file, for printing at a later time. The spool intercept
routine saves the print data in the spool file, and the spoolwriter retrieves the
print data from the spool file and prints it. The operator can control the
spooling process using spool commands.
The following diagram shows the normal output process and the print spooling
process.
lrmal Output Processing

Print Spool ing

User
Program

User
Program

Printer
Data
Management

Printer Data
Management

SPOOL
Intercept
Routine

SPOOL
File

SPOOL
Writer

Command
Processor

Printed
Output
Printed
Output

Advantages of Print Spooling
Print spooling provides several advantages over normal printing:
• Programs execute faster because time does not have to be spent waiting for
the printer to print each line of data.
• Multiple programs using the printer may be run concurrently rather than
serially because they do not have to wait for the printer to become available.
• Programs producing printer output can be run even if the printer is not
working.
• Multiple copies of the printer output can be produced without repeated
execution of the program producing the printer output.
• Different priorties can be assigned to the printer output in order to schedule
printing sequences.

System/34 Concepts

2-81

• In the event of a printer malfunction, printing can be restarted without
re-execution of the program that produced the printer output.
• A spool writer printing data from the spool file makes more efficient use of
the main storage processor, the printer, and the communications lines (for
remote printers) than direct printing does.

Spooling Options During Configuration
During system configuration the user can decide whether to include print
spooling in the system. If selected, print spooling can be later cancelled via the
IPl overrides or temporarily disabled for a particular printer by using the
SPOOL-NO parameter on the / / PRINTER OCl statement.
If print spooling is selected, you can specify whether all printers are to be
spooled, or just the system printer. If only the system printer is selected, the
other printer can be spooled temporarily by the use of the SPOOL-YES
parameter on the / / PRINTER OCl statement.

Control of Print Spooling
Print spooling may be controlled either by the system operator or by
subconsole operators. Subconsoles are display stations assigned control during
system configuration over one or more printers. The system operator has
control over all printers and all print files in the spool file. Subconsole
operators have control over their designated printer(s) as well as all print files
in the spool files to be printed on their designated printers. Display station
operators have some control over print files they create.

Spool File
The spool file resides on fixed disk and consists of a primary file and up to five
additional areas called extents. When spooling is active, the primary file always
exists; the extents exist only as needed. A new extent is allocated only when
the primary file and all currently allocated extents are full. When an extent
becomes empty, it is deleted.

2-82

Spool File Size
The size of the primary spool file is specified in blocks during system
configuration and by the IPL overrides. When there is sufficient disk space, the
amount specified is used to allocate the primary file and extents. Whenever
there is insufficient disk space, the largest space available is used to allocate
the primary file first.
The primary file and extents are divided into contiguous areas called spool file
segments. The size of the segments is specified in blocks during system
configuration and by the IPL overrides. The first segment of the primary file
called the spool master segment keeps track of the rest of the spool file. All
other segments of the primary file and all segments of the extents store print
data. When a printer file begins producing output, a spool file segment is
allocated to that printer file to store print data in. If there is more print data
than the segment can contain, another segment is allocated when the first one
is filled. This process continues until all the print data has been put in the
spool file. Any unused space at the end of the final segment is ignored. Once
the print file has been printed, it is removed from the spool file, and the
segments it used become available for use by another printer file.
Refer to the Installation and Modification Reference Manual to determine the
spool file and segment sizes based on the expected spool file usage. The
following explains some of the considerations that can be made:
• The recommended size for the primary spool file is one-sixth of the number
of blocks needed to contain all the print data, so that it may be spread
across the primary file and all five extents. This is done so that the spool
file occupies less disk space when there is less data in it. A larger primary
file involves more work by the system to allocate and deallocate spool file
extents. However, the spool file will occupy more disk space even when it
contains less data.
• The recommended size for the spool file segments is based on the size of
the typical printer file. Larger segments reduce the work the system does
allocating segments because fewer segments are needed. However, smaller
segments make more efficient use of spool file space by reducing the
amount of unused space in the last segment of the print files. The primary
file and extents have a limit of 800 segments, so in the cases where a large
spool file is needed, you may need to increase the segment size to keep the
number of segments from exceeding the limit.
Heavy usage of the spool file by spool routines and other programs running on
the system can create increased demand for the disk. To help balance the
activity across the disks, you can specify a disk preference for the spool file,
both during system configuration and by the IPL overrides.

System/34 Concepts

2-83

Spool Intercept Routine

The spool intercept routine stores printer output in the spool file. Printer output
can be from multiple printer files, either from multiple programs producing
printer output or from multiple printer files within one program, or both.
Spool intercept routine handles all printer files concurrently but independently
of one another. Each printer file has its own intercept buffer to receive printer
data, its own spool file segment for storing the data in the spool file, a unique
spool 10 consisting of the characters SP followed by four decimal digits.
Each printer file may be opened, closed, and reopened, etc. as desired
independently of all other printer files. When a printer file is closed, it
becomes disassociated from the spool intercept routine. If the printer file is
reopened, the spool intercept routine treats it as an entirely new printer file.
There is no limit to the number of printer files from one or more programs that
can be handled concurrently by the spool intercept routine.
If the spool file is not large enough to contain all the print data being put into
it, a message is issued when it becomes full. You may have to wait until space
becomes available in the spool file and then respond to the message with an
option that allows processing to continue, using the newly available space. If
the spool file has no space available, you may respond to the message with an
option that will close the printer file in the spool file. When the data in the
newly closed printer file has been printed, the spool file space it used is made
available again. Processing of the printer file continues from the point at which
it was closed, reusing the spool file space. If the spool file frequently becomes
full, you should consider increasing the size of the spool file.

Intercept Buffer
Whenever one spool intercept routine intercepts a new printer file, it assigns an
intercept buffer in which to accumulate print data and a spool file segment to
write the print data into. The data in the intercept buffer is written into the
spool file when it becomes full and the buffer can then be filled with more
data.
Intercept buffers are assigned from the system assign/free area and returned
to it when the printer file is closed. The amount of assign/free area assigned
for each printer file depends on the following:
• For a printer file created by a program which has no other spooled printer
files currently open, a buffer of 512 bytes will be used if there is sufficient
assign/free area. If there is insufficient area, or eight or more programs
with printer files open a buffer of 256 bytes will be used.
• For any printer files created by a program having at least one other spooled
printer file open, a buffer size of 256 bytes is used.
In addition to the intercept buffers the spool intercept routine itself and other
related data areas increase the amount of main storage that the SSP occupies
by about 1 K bytes. The system operator should select a system assign/free
area size that will accommodate the expected spooling activity.

2-84

Spool Writer Program
The spool writer program retrieves print data from the spool file and prints it.
There is a separate spool writer program for each printer in the system.
Before a spool writer can begin printing, the spool writer program must first be
started. If the autowriter function is requested during system configuration or
by the I Pl overrides, all spool writer programs will be started automatically
when you IPl the system. If the autowriter function is not requested, the
START PRT command must be entered by the system operator or subconsole
operator to start the spool writer programs.
Once a spool writer program has been started, the SSP automatically loads it
into main storage to begin printing whenever a printer file is available from the
spool file. When nothing is left in the spool file for the writer to print, the
writer terminates. When a change is made to the spool file so that another
print file becomes available for printing, the spool writer program is again
automatically loaded to begin printing.
The following diagram shows how the spool writer program prints jobs from
the spool file.

SPOOL
Writer

The system operator or subconsole operator may enter a STOP PRT command
to stop the spool writer(s). When a spool writer is stopped, it cannot print
even if printer files are available for printing. The START PRT command must
be entered to allow the writer to print again after it has been stopped.
Printer files are placed in the spool file according to the PRIORITY parameter
of the PRINTER OCl statement. The spool writer for each printer selects
printer files for printing on a particular printer in order of decreasing priority.
Printer files having equal priority are selected according to the order in which
they were placed in the spool file. Printer files that are either held, being
copied by the COPYPRT procedure or still being intercepted are bypassed and
cannot be printed until that condition is changed. (Printer files can be printed
while they are still being intercepted if you specify the DEFER-NO parameter
on the PRINTER OCl statement or entering the CHANGE DEFER command.)

System/34 Concepts

2-85

Changing Forms

The operator and subconsole operator can reduce the number of requested
forms changes by specifying a forms number on the START PRT command
when starting the spool writer. This causes the spool writer to print only those
printer files that require the specified forms. When all files have been printed,
the START PRT command should be entered again with either a different
forms number, or without a forms number if the writer is to resume printing all
printer files.
Before printing each printer file, the spool writer ensures that the forms are
positioned at the top of a page by advancing them to line one unless they are
already at that position. -Not advancing the forms if they are already at line one
prevents the spool writer from inserting a blank page between printer files.
However, if the previous printer file ended by printing on line one of a page
and did not move the forms afterwards, the following printer file will begin
printing on that same page and possibly overlay the information previously
printed on line one. To avoid this situation, ensure that either your programs
do not print on line one, or that they move the forms forward.

Forms Alignment

If forms alignment was requested by the printer file, either in the program that
created the file or by the ALIGN-Yes parameter of the PRINTER OCl
statement, the spool writer will print the first line of output and then issue a
message requesting the operator to align the forms. When the forms have
been aligned, the operator may respond to the message, instructing the spool
writer to reprint the same line and· halt again, or to print the next line and halt
again, or to resume normal printing.

Separator Pages

The spool writer will print separator pages ahead of each printer file if desired.
The number of separator pages (0-3) may be specified during system
configuration for each printer individually, and may be changed by the
CHANGE SEP command. If separator pages are either specified during
configuration or set to a nonzero value by the CHANGE SEP command, the
spool writer issues a message asking the operator whether separator pages
should be printed whenever any of the following situations occur:
• When the first printer file is to be printed after the system is I Pled
• When the first printer file is to be printed after the spool writer has been
restarted via the RESTART PRT command
• Whenever a printer file is to be printed that requires forms other than those
currently in the printer
The spool writer continues printing or not printing separator pages as specified
until the operator informs it to do otherwise.

2-86

The RESTART PRT Command

If the operator stops the spool writer while it is printing a printer file, entering
the RESTART PRT command causes the writer to begin printing that printer file
again. A page number may also be entered with the command to inform the
spool writer of what page it is to begin printing on. Entering the RESTART
PRT command while the spool writer is printing a printer file causes it to start
printing the file again from the beginning or from a s~ecific page.

Message Options
The options allowed on the messages that the spool writer issues are generally
sufficient for the operator to inform the writer of the action that is to be taken.
However, when the writer should take some action other than what is indicated
by the message options, the operator may enter the appropriate command to
inform the spool writer of the desired action, rather than responding to the
message.

Performance Considerations
During system configuration, or through the CHANGE RES command, you can
specify whether individual spool writer programs are to be swappable or
resident when loaded into main storage. Swappable spool writers may be
swapped to and from disk in order to share main storage with other programs
running at the same time; resident spool writers do not have this capability.
Making a spool writer resident can improve its performance somewhat,
because a resident spool writer is not swappable. However, doing this can
significantly reduce the amount of main storage that can be used by other
programs, as spool writers each require 8 K bytes of main storage.
Another performance factor of the spool writer is that of priority. During
system configuration, or through the CHANGE PRTY command, you can
specify whether an individual spool writer program is to have normal or high
priority when loaded into main storage. A spool writer program with high
priority executes before a program with normal priority. The performance of a
spool writer program can generally be improved by selecting high priority rather
than normal.
In addition to the configuration option, the priority of a spool writer may be
changed by the CHANGE PRTY command.
A final factor related to the performance of the spool writer for the 5211/3262
Printer is the spool writer print buffer size. A buffer size of 1 to 4 half- K bytes
may be selected. A buffer size of one half-K (512 bytes) is usually sufficient,
but in a heavily loaded system, a larger buffer size will generally improve
performance.

System/34 Concepts

2-87

Spool Commands
Spool commands are the operator's means of controlling both the spool writers
and the printer files in the spool file. The following general rules apply to the
spool commands:
• Commands entered from the system console can apply to any spool writer
or to any printer in the spool file.
• Commands entered from a subconsole apply only to spool writers for
printers controlled by the subconsole or to printer files that are to be printed
on printers controlled by the subconsole.
• Commands entered from a display station apply only to printer files created
by the display station operator.
The following spool commands are used on the System/34:
CANCEL PRT

Changes the priority printing sequence of a specified printer
file in the spool file.

CHANGE PRTY Changes the priority of a specified spool writer.
CHANGE RES

Changes the resident/swappable attribute of a specified
spool writer.

CHANGE SEP

Changes the number of separator pages printed by a
specified spool writer.

HOLD PRT

Holds selected printer files to prevent them from being
printed.

RELEASE PRT

Releases selected printer files that were previously held to
allow them to be printed.

RESTART PRT

Restarts a specified spool writer.

START PRT

Starts a specified spool writer.

STATUS PRT

Displays the status of the spool writers.

STOP PRT

Stops a specified spool writer.

After entering a command, the operator is issued a message indicating whether
the command was successfully executed.
For more information about these commands refer to the Operator's Guide or
to the Command and OCL Statements Reference Summary.

2-88

Identifying Your Spool Output
Output for each printer has a unique six-character identification consisting of
the characters SP followed by four numbers, such as SP0042.
You can obtain the status of each job in the spool file by entering D P
(Spooled Print Status) command from either the system console, a subconsole,
or a work station. The following example illustrates the spooled print status
screen.

SPOOLED PRINT STATUS
**COMPLETE**
BLOCKS AVAILABLE: 1106 OF 1134
POS 10
PROC
JOBHAME USER
PRltHER 10 PRTY
1 SP0042
PRnHKEY PI Al
~1111 0559 RON
2 SPOO(.3
WIll0643 RON
PRltHKEY PI
1
3 SP0044
PRItHKEY PI
WIl10655 ROH
I

WI
---PAGES--COPY TOTAL WRT
Cot~SOLE

FORM
0001
0001
0001

1
1

1
1

1

I

1

ENTER F-FORWARD, I-INPUT, R-RESTART, U-UPDATE, OR E-END •......... ~ ..•....•... F

For more information about the print status screen, refer to the Operator's
Guide.

The COPYPRT Command
The COPYPRT command executes two programs, $UASF and $UASC, to do
the following:
• $UASF copies one or more spool entries into a disk file.
• $UASC displays the contents of the disk file at the work station.
•

Both $UASF and $UASC can copy one or more spool entries into a disk file
and then display these entries at the display station.

The disk file can be saved on diskette and restored into the spool file for later
printing.

System/34 Concepts

2.:..89

Using the STATUS PRT and COPYPRT Commands
After using STATUS PRT to display spool entries in the spool file, you can use
the COPYPRT command to copy entries into a disk file according to criteria
such as spool 10 or forms 10.
The following two examples show the use of the STATUS PRT and COPYPRT
commands.

SPOOLED PRINT STATUS
*l'COt1PLETE**
BLOCKS AVAILABLE:
1106 OF
1134
JO[,t~I'.r·lE
POS TO
PROC
USER
PR!NTER
ro PRTY
PRItHKEY PI
Al
I SPOOl.2
Will 0559 ROl~
PRHHI

Remo~

If the host is a System/370 or another System/34, communication can be via
BSC or SDLC. If the host is any other type system, communication can be
only via BSe.

2-146

System/34 as a Host System
System/34 as a host system is applicable to many common business services.
Many organizations have data that should be entered into a central control file.
Some examples are attendance reporting, customer order masters, and
inventory. Firms that have remote locations can use terminals to transmit or
receive data using nonswitched or switched communications line connection to
the host System/34. For example, a business has several remote locations.
Location A uses a System/32 for payroll processing and location B uses a
programmable 3741 to enter inventory transactions; the other locations use
online 5250 devices. Summary data from locations A and B are transmitted to
the System/34 using a switched communications line, while a nonswitched line
is used to communicate with the 5250 devices .

.----A

------1 r--------

System/34

._. . . .
_OR . . . . . . . . . . . . . . . . . . . .~

- - - System/32 - - - - - - "

~B--l

......

Programmable 3741

~

5256

Multiprogramming is an advantage of using System/34 as a host system.

System/34 Concepts

2-147

System/34 as a Subhost System
This category is a combination of the first two. The subhost serves as a host
for some processor terminals, and also as type of processor terminal for
another host. A subhost system provides all the advantages of terminal entry
to interact with centralized data files in a system and to communicate with the
central office's system. The central (host) system has the main data files, and
each subhost has a subset of those data files that can be accessed by the
terminals attached to the subhost.

a

_ - - - - Subhost System - - - - _ ,
Local Work Stations

Q,
o

eSC/SOLC

OR/~

DJ

.-----Processor Terminal

~---

Programmable 3741

BSC

Host System
__----System/370,303X,308X----~

System/34 as a Peer Connection
System/34 as a peer connection is applicable to many common business
services with one or more remote System/34s. The peer connection allows
System/34 to utilize data on remote systems and to start remote procedures to
offload processing. A peer connection provides System/34-to-System/34
processing without having to go through a host. This processing can be done
on a point-to-point connection using sse or SOLe, or on a multipoint
connection using SOLe.

------System/34 - - - - - ,
BSC/SDLC

I
•

------r

System/34 - - - - -

DISTRIBUTED DISK FILE FACILITY
The distributed disk file facility allows you to access data files stored on
another System/34 or a System/3 Model 150. You do not have to recompile
your programs to use this feature.
The distributed disk file facility is available by PRPQ only. The following is the
PRPQ number list:
• P84037 for System /34
• P84038 for System/3 Model 150
For more information about the distributed disk file facility, refer to the IBM
System/34 and System/3 Model 150 Distributed Disk File Facility Reference
Manual, SC21-7869.

System/34 Concepts

2-149

2-150

Chapter 3. Design Considerations

During system design, you typically need to make decisions regarding the
following items:
• Displays and menus that operators use
• Input documents and printer forms
• Files
• Applications and programs
• System security and integrity
• Documentation
• Remote display stations
For example, you might need to answer questions such as:
• What information should operators see on their displays and how can I
format the information so that it is readable]
• Should I design similar forms for the various printers] If not, how should
they differ]
• Which file organizations should I use and when should I use them]
• How should I design the records in the files]
• What design decisions affect response times]
• Which application should I design first]
• Which data entry programming method should I use]
• Which programs should be SRT programs] Which should be MRT
programs? Which should be never-ending programs?
Design considerations for all these questions and more are presented in this
chapter. As you read these considerations, keep in mind that no two
businesses are likely to have the same design concerns. Therefore, the
information in this chapter is necessarily general in order to apply to as many
situations as possible.

Design Considerations

3-1

Display Design
This section describes some· key elements of display design. The guidelines
presented, although representative of most display'design, might not apply in
all circumstances. The topics are offered more for your consideration during
display design than for rules that you must follow.
Display design is concerned primarily with the way data is displayed to the
operator and the way that the operator responds to this data. Generally, input
displays should be designed for ease of data entry, and output displays should
be designed for ease of reading. Many displays show output as well as accept
input. These displays are the most challenging for the designer, who must
make tradeoffs between ease of data entry and ease of reading. This section
might help the designer make decisions about the tradeoffs.
System/34 operators might be miles from the computer room or at least far
enough away so they cannot bring their questions or problems to this room.
Therefore, displays that these operators use should be clear, complete, and
concise.
Operators should feel that their display stations are helping them be more
productive. You might help operators attain a positive attitude for using their
display stations by involving them in the display design. For example, ask for
opinions of some sample displays that you plan for them to use and ask how
they might improve them.
Experienced operators might be able to use displays that have few operator
instructions on them, and they might be more productive if the response times
are short. Inexperienced operators might need more guidance from the
displays, and they might tolerate longer response times.
As you read the following display design guidelines, you might consider the
amount of experience your display station operators have and plan your
displays accordingly.

IDENTIFY THE DISPLAYS
Each display could be identified by a title or heading and a nondisplayed 10.
The title should be as concise as possible, yet meaningful. Titles, which are
usually centered on or near the top line of the display, could be intensified or
underlined.

3-2

PROVIDE MEANINGFUL HEADINGS
Descriptive headings help operators understand what they see and do. For
example, the headings on a display for entering line items from an order might
be:

LINE

ITEM NO

QTY

DESCRIPTION

PRICE

ANOUNT

You might need to compromise between the number of descriptive headings
you use, which makes a display easier to understand, and the length of the
response time. Too many headings might degrade performance, especially on
remote display stations. For those displays, you might want to minimize the
number of characters on each display by abbreviating or eliminating the
headings.

Design Considerations

3-3

PLAN READABLE DISPLAYS
The basic rule of designing displays is to make the display screen easy to read.
Display screens are the easiest to read when they are not cluttered with extra
information. You should try not to put too much information on one screen.
The following suggestions are provided to help you plan readable displays:
• Use blank space to separate data items. Blank space is the most effective,
least cluttering, separator.
• Organize data in columns or lists. Text could be left-justified; numeric data
could be right-justified and aligned on the units position.
• Present information in some recognizable order for ease of scanning. For
example, put historical dates in chronological order.
• Use complete words rather than contractions.
• Use lowercase letters in prompts. (Lowercase letters do not print on a 5211
Printer or a 3262 Printer unless it has a 96-character print belt.)
• Use column separators in input fields.
• Highlight new, added, or referenced information when a display is reshown.
• Use blinking fields sparingly. Blinking should be used only for urgent,
attention -getting purposes.
• Arrange fields so that the most frequently used fields are recorded first,
followed by less frequently used fields.
• For inquiries, show only the expected data in a readable sequence.
• Avoiding unnecessary information such as asterisks that outline information,
which reduces the amount of data sent from the program to the display
station.
Avoiding unnecessary data is especially important for displays shown at remote
display stations. Unnecessary data transmitted to a remote display station can
cause lengthy response times.

3-4

The following displays show use of some of these design guidelines:

Centered Title

Column Separators

Blank Lines for . . ._____
Improved Readability

UIIII

Lowercase Letters
in the Prompt

PRESS FIELD EXIT KEY TO CONTINUE
PRESS COMMAND KEY 7 TO END YOUR SESSION

Operator
Instructions

c

Reshown Data
from a Previous
Display

CUSTO~ER

101
OBRIEN CHEMICAL SUPPLIES
1240 INDUSTRIAL WAY
LAKEPORT MN
25555

Underlining Used
to Highlight the
Prompts; Indentation Used for the
Customer Addre

Initial Position
of Cursor

A

'\

ORDER ENTRY

HAROBIN INTERNATIONAL
INDIAN HIllS INDUST PARK
MARIETTA GA
521&2

CUST REF NO
-

KEY REF NO AND VIA; THEN PRESS ENTER

Design Considerations

3-5

DISPLAY A SMALL AMOUNT AT ONE TIME
The displays should be kept uncluttered and include only meaningful
information. For example, do not display the entire· record on an inquiry if the
operator normally looks at only one or two fields. Instead, display the
necessary fields and, perhaps, provide a function that .allows the operator to
display the entire record when it is required.
Large displays are not intended only for displaying more data; part of the
advantage of large displays is that they allow more formatting freedom. For
example, double-spaced lines might make a display more readable.
Certain applications accumulate data from display to display. To a point, such
an accumulation might be desirable. However, if you are not careful, the
display can get too cluttered.
You might use nondisplay fields for information that is not needed by the
operator but needed for your programs. For example, the display station 10 or
a screen format 10 might be needed by a program, but it might not need to be
seen by the operator.

MAINTAIN CONSISTENCIES AMONG DISPLAYS
Each application has its own display screen requirements, but good design
requires display consistencies among applications. For example, terminology,
abbreviations, and codes should be consistent from one application to another.
Consistency is particularly important when the same operator does more than
one application. The standards established within .an application are even more
important than those between applications.
Use of keys should be standardized for displays and applications. For example,
avoid allowing command key 7 to end a job on one display and command key
9 to end the job on another display. Of course, a key sometimes has to be
used in an application-unique function, but a legend should tell the operator
about the nonstandard use of the key.
Reserve areas of the display for certain types of information and maintain the
areas in the same relative locations on all displays. For example, try to provide
operator instructions and display messages near the bottom of the displays.

Finally, try to highlight a field consistently, whether via underlining, blinking,
high intensity, or a reversed image.
The following display illustrates some of the consistency guidelines:

ACCOUNTS RECEIVABLE
CASH RECEIPTS
Customer Nut.lber

Legend Placed
Near Bottom of
this Display and in
the Same Relative
Position on all
Displays in the
Appl ication

000101

Check Number

U I1II

Amount

111111I1

Check Date

I1I1II

~

OBRIEN CHEMICAL SUPPLIES

II

PRESS ENTER TO CONTINUE
eHD KEY 2 TO RETRY PREVIOUS ENTRY
eHD KEY 3 TO ENTER NEXT CUSTOMER
eMO KEY 7 TO END SESSION

J

-------t----~-------

Messages to the operator are shown
on the bottom line on all displays
in the application.

Throughout the application,
these keys have the same
basic functions.

Design Considerations

3-7

KEEP OPERATOR RESPONSES SHORT
Whenever possible, keep operator responses short but complete. These
responses can include codes or abbreviations, but only if the operators are
trained to use them.
Cursor positioning by operators should be minimized. Instead, displays should
be designed so that operators need not frequently space over unused fields.
The cursor might be positioned by the program to avoid this skipping over
fields.
Consider blinking the cursor to draw the op.erator's attention to its initial
position.

PROVIDE ONE IDEA FOR EACH DISPLAY
Whenever possible, a display should contain information concerning only a
single aspect of an application. For example, one display should not be used
to inquire into a file and perform an update at the same time. Concentrating on
a single idea at a time decreases the possibility of an operator error. The
following display is an example of allowing one function per display. The
legend of command keys at the bottom of this display shows additional
functions that the operator can select.

A & A GROCERY

30000

A & A GROCERY

PHONE: 312 / 555-1734
SALESMAN 16

P 0 15159

E. DUNDEE

I l 60118

--- A/R BALANCE --BALANCE fORWARD
PREVIOUS BALANCE
CH;,RGES
PArt1ENTS
AOJUSntENTS
* MfOUNT NOW DUE
fUTURE CHARGES
* TOTAL AMOUNT DUE
CREDIT LIMIT -

579.04
1,313.00
874.46
.00
1,Ol7.58
.00

1,017.58
l.500.00

LAST PAID ON

9/02/78

DETAIL fOR AMOUNT NOW DUECURRENT PERIOD
438.54
OVER 30 DAYS
579.04
OVER 60 DAYS
.00
OVER 90 DAYS
.00
UPAID LATE CHGS
.00

CmtMAND KEYS1

RESU~1E

SEARCH

5 SALES DATA

3-8

2 NEW SEARCH
6 PRICE INQUIRY

3
24

BILLING DATA
SIGN Off

4 A/R BALANCE

ACKNOWLEDGE OPERATOR INPUT
Operator interaction with a display station is usually conversational; for
example, an operator makes an inquiry, and the display station shows the
requested data. For this reason, you should be concerned about how long an
operator waits for the System/34 to respond.
If a program takes a relatively long time to respond to an operator, you might
want to display an in-process message immediately after the program receives
the operator's input. For example, you might want to do this for a program
that does extensive calculations with the operator's input. Acknowledging
operator responses at remote display stations might affect their response
times.

MAKE ERROR CORRECTION EASY
On System/34, the number of input errors might be reduced by detecting the
errors as they occur and notifying the operator so that he can correct them.
One way to design a display to inform an operator of an error is to use the
lower part of the display for error messages.
You might reserve a fixed number of message positions on the next-to-Iast line
of the display. The bottom line of the display is usually reserved for system
error messages rather than your messages. The message field can be
conditioned by an indicator so that the proper message is an output field when
an error occurs. Indicators can be used to condition the attributes of the
message and the field(s) in error, and indicators can also be used to position
the cursor.
The following display shows the use of some of these guidelines:

o R D ERE N TRY
ORDER 1'10- 26

Valid Item Invalid Item

I

I

ITEM

QTY

NWiaER

ORDER

_2500

-------r----

CU5TOMER- 47600

1

1

QTY
SHIP

GERSHWIN AND SWEET

QTY
8/0

1

5

I

ITEM NOT ON FILE; REKEY OR REMOVE ITEM NUMBER

Design Considerations

3-9

PROVIDE A MEANS FOR HELP
Operators should know what actions to take when problems occur. Problem
recovery steps should be included in the written operating procedures. In
addition to the written steps, further information about the error should be
available for the operator to display. This information might be requested via a
command key or function key.

MAKE THE OPERATOR FEEL PRODUCTIVE
Because the operator is using the display station as a means to do a job, the
display station should be easy to use and allow the operator to do a better job.
Application programming and display design should not bore, scare, or annoy
the operator. Try to use only as many features of the display station as are
necessary. A display that has too many blinking fields or too much underlined
data and highlighted information might only confuse and frustrate the
operators.
Whenever possible try to give the well-trained operator the chance to take
shortcuts from one display to another.

DOCUMENT THE DISPLAYS
Printed copies of your displays can be made by using the Print key. These
copies can be labeled and stored with the $SFGR utility output for the displays.
If possible, use a printer that can print lowercase letters. The 5256 and 5225
printers can print lowercase letters. The 5211 and 3262 printers can print
lowercase letters only if they are equipped with a 96-character print belt. If
lowercase characters cannot be printed, they can be changed to uppercase
characters by using translation tables. Refer to the IMAGE Oel statement
description in the SSP Reference Manual for details.

Make the Screen Look Like the Source Document
If the operators are entering data onto a screen from a particular document, try
to design the screen display to look like the document. This technique is
especially helpful if the operator's work includes a lot of data entry. The
following display illustrates this principle.

3 ... 10

Audio/Eyesight
1816 West Tuckey
Phoenix, Arizona 85015

Store Number 346

Daily Report of Items Bought
Item Description

Quantity Bought
2
1
150

7653 Air Wrench
3489 Widget
4300 Balsam Wedges

SCREEN: AE232
Store 346
ITEM Description

Unit

Price

Discount

Net Cost

DOl

38.95
4.00
12.00

10%
5%
10%

70.11
3.80
1620.00

DOl
DOl

Report of Items Bought
Qu~ntity

COMMAND KEYS
4 = Ch~nge previous d~t~
5 = Review d~ta entered

Unit

Price

7

= End

Discnt

Net Cost

of job

Design Considerations

3-11

Use SDA as a Documentation Aid
When creating or updatihg screen formats you can use SOA to help document
your displays.. The following example shows the documentation provided by
SOA fora newly created screen format.
SCREEN DESIGN AID

DATE

07/07/81

TIME

15.56

1 ••• + ••• 10 •••• + ••• 20 •••• + ••• 30 •••• + ••• 40 •••• + ••• 50 •••• + ••• 60 •••• + ••• 70 •••• + ••• 80
2
3

4
S

o
7
a
9
o
1

2
.3
A

.5

i6
i7

18
19

20
21

**
*it
**
**
**
**
**
**
**
**
**
**
**
**
**
**
**
**
**
**

ACCOUNT IDENTIFICATION

21-_____ _

ACME INC WEEKLY BILLING
STATUS SCREEN

CUSTOMERADDRESS
NAME
STREET
______________ _
CITY _________________
STATE

ZIP CODE _____ _

INVOICE DATA SECTION
INVOICE NUMBER
A211302
A411202

INVOICE DATE
07/06/81
07/07/81

INVOICE AMOUNT
$142.30
$156.78

STATUS

**
**

**

22 **

23

**
**
**
**
**
**
**
**
**
**
**
**
**
**
**
**
**
**
**
**

24 **CMD KEY 3 INVOICE STATUS
CMD KEY 7 RETURN TO BILLING PROCESS
1 ••• + ••• 10 •••• + ••• 20 •••• + ••• 30 •••• + ••• 40 •••• + ••• 50 •••• + ••• 60 •••• + ••• 70 •••• + ••• 80
FORMAT •••• WEEKLYAR

SOURCE MEMBER NAME •••• BILLING
LIBRARy •••••••••••••.• DRFLIB

1

2
3

4
5

6
7

8
9

10
11

12
13
14
15
16
17

18
19

20
21

** 22
** 23
** 24

Menu Design
A menu is a displayed list of functions from which an operator can select an
item. Using a menu, an· operator enters a number that specifies what he wants
to do. Yqu might have the operators use menus so that they can start their
jobs by selecting an item number rather than entering a command statement or
OCl statements. Well-designed menus can shorten the time an operator takes
to do his work and can reduce his chances for error. Your menu design might
ensure that the operator does his jobs at the proper time in the proper order.
As described under Menus in Chapter 2, System/34 provides two menu
formats: fixed and free-form. Fixed-format menus have two columns of
pre-numbered items, and you can specify descriptions for as many of the
numbered items as you want. On free-format menus, most of the lines (3
through 20) are available for you to format as you want.
For either menu, you might consider placing the most frequently selected items
near the top of the display so that the operator spends less time scanning for
them.
Menu items should not be abbreviated unless you are sure that the
abbreviations would not confuse the operators. Also, menu items should be
meaningful. For example, Order Release is a more meaningful item than,
ORDREl, the name of the program that releases orders.
Menu chaining, a good technique to use for applications on System/34, helps
organize an operator's work by guiding him to the displays from which he does
his jobs. This technique uses a main menu that categorizes the jobs that can
be done. For example, the following menu is a main menu for an order entry
and invoicing application. Notice that each item except Monthly Close causes a
lower-level menu to appear.

CO~lMAND

ORO ERE N TRY AND
--MAIN l'lENU--

I NV 0 I C I NG

1
2
3
4

ORDER PROCESSING MENU
INQUIRY MENU
REPORTS MENU
MONTHLY CLOSE
5 FILE MAINTENANCE MENU

ENTER NUMSfR, COMMAND, OR oel

<-READY

Design Considerations

3-13

The following figure shows some of these lower-level menus ~nd the
commands used to chain the menus ..

COMMAND

COMMAflD
MENU: AMBMOO
ENTRY AND INVOICING
--MAIN MENU--

ORDER

~O~ROiEl'E~R~P~R~OC~E~SS~I~N::.G.:.l1iiiEti.l:olU,-_~_-

I-----

1 MENU AMB10

,--i!-l

I

COtlMAND

~ ~~~~~~~ ~~~~

2 MENU AMB20

4 MOIITHLY CLOSE

5 FILE MAINTENANCE MENU

3 MENU AMB30
4 MENU AMB40

MENU: AMBMI0
/
ENTRY AND INVOICING
--ORDER PROCESSING--

ORDER

5 MENU AMB50

1 ORDER ENTRY
2 ORDER ENTRY-IMMEDIATE RELEASE
:5 ORDER MAINTENANCE

Order Processing Menu includes entering, maintaining,

4 ORDER RE LEASE
5 DISKETTE ORDER ENTRY
6 BATCH UPDATE
7 PICK LISTS
8 ACKNOWLEDGEMENTS
9 INVOICES
10 BILLS OF LADING
11 RETURN TO OE & I MAIN MENU

releaSing, and updating of customer orders and offers
printing of pick lists, acknowledgments, invoices and bills
of lading.

COMMAND
MENU: AtlBMZO
ENTRY AND INVOICING
--INQUIRY--

ORDER

1 CUSTOMER STATUS
Z CUSTOMER ORDERS
:5 OPEN ORDER
4 ITEM
5 BATCH STATUS
6 RETURN TO OE & I

Inquiry Menu includes displaying of the contents of main
master fIles.

MAIN MENU

COMMAND
MENU: MIBM30
ENTRY ANO INVOICING
--REPORTS--

ORDER

1
Z
3
4
5
6
7
8
9
10
11
12

OPEN ORDER BY DATES
OPEN ORDERS BY ITEM
OPEN C'RDERS BY CUSTOMER
BLANKET ORDER STATUS
TAXING BODY DETAIL
TAXING BODY :;UM1·IARY
COMMISSIONS ~:O~KSHEET
GENERAL LEDGER WORKSHEET
ITn! FRICE LIST
FILE LIST REPORTS ~IENU
PICKING SHORTAGE REFORT
OE & I MAIN MENU

Reports Menu includes printing of all report listings available in Order Entry and Invoicing except those included
under Order Processing and offers a display of the File List.
Menu, which lists contents of main master files.

COMMAND

ORDER

1
Z
3
4
5
6
7
8
9
10
11
12

MENU: AMBMSO
ENTRY AND INVOICING
--FILE MAINTENANCE--

CUSTOMER MASTER-MAINTENANCE
CUSTOMER MASTER-REORGANIZE
ITEM MASTER-MAINTENANCE
ITEM MASTER-REORGANIZE
S!lIP-TO MASTER-MAINTENANCE
SHIP-TO MASTER-REORGANIZE
CONTRACT MASTER-~!AINTENANCE
CCNTRACT MASTER-REORGANIZE
QUf,NTITY PRICE-MAINTENANCE
QUAflTITY PRICE-REORGANIZE
TAXING BODY MASTER-MAINTENANCE
TAXING BODY MASTER-REORGANIZE

13
14
IS
16
17
18
19

OPEN ORDER SUMMARY-REORGANIZE
OPEN ORDER MATERIAL-REORGANIZE
VALIDATE-CUSTOMER ORDER CHAINS
VALIDATE-OPEN ORDER CHAINS
VALIDATE-ITEM WHERE-USED CHAINS
FILE LIST REPORTS MENU
RETURN TO OEU MAIN MENU

File Maintenance M?nu includes executing of fIle mainte-

<-READY

nance, file reorganization and chain validation of main
master files and offers a display of the File List Menu,
which lists contents of main master fIles.

When an operator selects item 1 from the main menu, the MENU command is
executed and the Order Processing Menu appears. When the operator selects
an item from that menu, he sees either another lower-level menu if there are
additional order entry categories to select or a display on which he can begin
order entry.
When you chain menus, you might allow ways for operators to redisplay the
main menu. Also, you might allow ways for experienced operators to bypass
the menu chains and directly begin their jobs.
The / / MENU Oel statement or the MENU control command are useful when
you are constructing a menu chain. For more information about constructing
menus, refer to the Screen Design Aid Reference Manual or to the BlDMENU
procedure in the System Support Reference Manual.

Design Considerations

3-15

Forms Design
Computer input and output forms should not be overlooked during system
design because they are important interfaces between the system and the
users of your system. These forms are possibly the only contact that some of
the business' customers and employees have with the system; therefore, their
design can influence impressions of the system and the business.

DESIGN CONSIDERATIONS FOR OUTPUT FORMS
System/34 supports the 5211 Printer, the 3262 Printer, the 5224 Printer, and
the 5225 Printer which are line printers, and a 5256 Printer, which is a
character printer. Each printer has unique forms design considerations.
On the 5256 Printer, printing is done one character at a time by a print head
that must move to the appropriate position on the line. This head movement
takes time. Therefore, you might consider designing your forms to reduce the
amount of head movement required. For example, try not to center one or two
fields on a line if the fields need not be centered. Left-adjusting them on the
line might shorten the printing time. Placing fields in a horizontal line rather
than spacing them vertically and minimizing the horizontal space between fields
might also shorten the printing time. Planning horizontal lines so that
fixed-length fields print first and variable-length fields print last allows the
print head to a<;lvance to the next line as soon as the last character prints on
the line. For example, an item description field might be a good
variable-length field to print last on a line. Finally, using a large form and
printing a small amount of information on it might be inefficient because many
new line returns might be required to print the data. Therefore, keeping the
forms as short as possible might improve printing speed.
Figures 3-1 and 3-2 illustrate an initial design and an improved design for an
output form used by a 5256 Printer.

3-16

ABC
CO.

L

SHIP TO:

(name)

(name)

(address)

(address)

(city)

(city)

(state)

(state)

.JL

II TERMS:

VIA:

--,

-,r

r;OLD TO:

I

,

; CUST. NO.

~

ITEM

I
I

I

I
I
I
I

I
I

I

I

I
I

I
i

OTY. ORO.

I

I

OTY. SHP.

I
I

I

I
I

I
I
I

I

I

I
I

I
I

I
I

i

I

I

I

I

~~

,-

SALESMAN

I

.-J

I

I
I

OTY. BO.

I

I

I
I
I
I
I

I
I
I

~L

I

I

DESC.

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

I

I

I

i

AMT.

I

I

I
I

I

I

I

I

I

I

I

I
I

I

I
LIST

I
I

Quantity back ordered is
not always printed, so it
would be better to put it
in the rightmost column.

I

II

Putting all these
fields on one
line would
shorten the form
and increase
printing speed.

I
I

I
I
I

I
I
I
I
I
I

I
I

GROSS ~
TAX

~

DISC.
NET

Four lines are used for totals, causing
extra spacing. The totals on these four
lines could be printed on one line.

J

Figure 3-1. Initial Forms Design for a 5256 Printer

Design Considerations

3-17

-,r

(name)

(name)

(address)

(address)

(city)

(city)

(state)

L
CUST. NO:
ITEM

J

SHIP TO:

r;OLD TO:

(state)

.JL
I

I

,VIA:

I TERMS:

I

I

I DESCRIPTION I

,
I

I
I

ABC
CO.
...J

I

I SLSMAN:

LIST

,

AMT.

QTY. SHP.

I
I

I

I
I
I

I
I

I

I
I

I
I
I

I
I

I
I
I

I

I

I

I
I
GROSS

I

TAX

DISCOUNT

Figure 3-2. Improved Forms Design for a 5256 Printer

3-18

NET

QTY.ORDER

I

QTY. BIO

On the 5211 Printer or the 3262 Printer, one line is printed at a time by a
character belt rather than by a print head moving from character to character
across a page. Good design techniques for a line printer should therefore
attempt to reduce the number of lines printed on each form. Increasing the
number of characters printed per line might shorten the time required to print
the form. An example of this would be to combine two lines into one print
line. Consider using as wide a form as possible and as short a form as
possible. Finally, try to space lines so that line skipping rather than line spacing
can be used because line skipping is usually faster than line spacing.
For preprinted forms such as picking slips or invoices, consider shading
alternative lines; this technique can make a long list of items more readable.
Design and order your preprinted forms well in advance of when you plan to
use them. Request a proof of the form so that you can verify its accuracy
before it is printed.
Refer to the SSP Reference Manual for information about the number of printed
lines allowed per page.
Refer to the following manuals for information about the physical dimensions
of printer forms:
• 3262 Printer Component Description and Operator's Guide
• 5211 Printer Component Description and Operator's Guide
• 5224 Printer Models 1 and 2 Operator's Guide
• 5225 Printer Operator's Guide
• 5256 Printer Operator's Guide

DESIGN CONSIDERATIONS FOR INPUT FORMS
Well-designed input forms might help shorten data entry time, reduce the
number of data entry errors, and improve operator satisfaction with the system.
Forms that will be used for data entry at a display station should match the
input displays that operators use. For example, the input fields should be in
the same order and have the same headings on the form and on the display.
Usually, the form should be designed first and then the display could be
designed to match the form.
To shorten the time required to fill out your forms, you might design them so
that the data can be recorded in the order that it is usually received. You might
consider placing mandatory entries first, followed by the optional entries, which
might minimize skipping over fields. If you use special codes, consider listing
them on the input form so that the operator does not have to look for their
meanings.

Design Considerations

3-19

File Design
One of the most important design activities is file .design. This activity can
significantly influence system performance, data security, data maintenance,
data accessibility, and data recovery in case of a system failure. This section
describes some considerations for attaining a good file design, particularly in
the following areas:
• File organization
• Record design
• Record blocking
• Physical I/O and logical I/O
• Access algorithms for direct files

FILE ORGANIZATION
File organization can affect system throughput and display station response
time in an interactive environment. Because much of the file processing is
random, the choice of file organization is usually between indexed and direct.
Indexed organization offers a wide variety of processing methods; however,
direct file organization provides the following advantages that can contribute to
an efficient system design:
• Fewer accesses to the disk can improve response times.
• File recovery in the event of a system failure is easier for direct files than for
indexed files.
• Sharing files between programs is simplified when direct files are used.
These advantages can be critical to the performance of the system, especially
for files that are frequently accessed. However, sequential and indexed files
can be used in an interactive environment. Sequential organization is useful for
files that are not processed randomly, such as some logging files. Indexed
organization might be satisfactory for master files if the file is not too active
and if short response times are not necessary.
The following information provides considerations for choosing the organization
of your files. These considerations are not rules that you must follow, but
guidelines that might help you organize each of your files so that you attain the
best system performance possible.

3-20

Master File Organization
A master file is relatively permanent and is often used in several jobs with
several other files. When you choose an organization for a master file, consider
these processing requirements for it:
• What are the organizations of the other files that are processed against the
master file? If the other files are ordered, which means that they are sorted
in the same sequence as the master file, the master file could be processed
consecutively and, therefore, a sequential or indexed organization for the
mastEn file would be most efficient.
If the other files that you process against the master file are unordered, the
master file needs to be indexed and processed randomly by key, or the
master file needs to be direct. Processing an indexed file randomly requires
a disk access to read the key and anoth&f disk access to read the record.
Processing a direct file randomly requires one disk access per record unless
the record has synonyms and is usually faster than processing an indexed
file.
• How do other jobs process the file? If the master file is used in several jobs
and its records are processed both in order and randomly, either an indexed
or direct organization should be a better organization than a sequential
organization.
• Does the master file require sorting? If so, consider that indexed and direct
files can be sorted, but the sorted file is a sequential file. Rather than
keeping the sorted file as the master file, you would need to keep the
original unsorted file.
• Can operators inquire into the master file? If so, consider how necessary a
short response time is. To ensure the shortest possible response times, the
file should be direct because a record can possibly be read with one disk
access. Satisfactory response times also might be attained from an indexed
file processed randomly by key because a record can be read with two disk
accesses, one for the key and one for the data. If the direct file has
numerous synonyms, multiple disk accesses can be required for each record,
and this organization might not provide shorter response times than an
indexed organization.

Design Considerations

3-21

Transaction File Organization

Transaction files are less permanent than master files and typically are used to
update master files. Transaction files are frequently logged,. in history files to
keep records of business activities. An example of a transaction file is. a cash
receipts file for an accounts receivable application. An example of a more
permanent transaction file is an open-item accounts receivable file. These
transactions are usually maintained to show detail. on. reports such as
sti:ltements sent to customers and aged trial balances.
Typically, transaction files entered from display stations in an interactive
environment are direct files. The reason for using direct files is that the
operator can usually expect a short response time when doing the following
functions: paging through a file, adding records, deleting records, and
reviewing all or part of the file.
The transaction file created by a WSU program, for example, is a direct file
that has records separated logically by display station. Several display stations
can enter transactions concurrently, and these transactions become mixed in
the file. The transactions from a display station are chained by control
information so that operators can access the records entered from his display
station. This logical separation of records requires control records and control
information in each transaction record. Subroutine SUBR22 allows an RPG 1/
program to read records from a WSU transaction file.
Relative Record
Number

Contents

Next available relative record number
Last relative record number

3-22

2

W4 transaction 1

3

W1 transaction 1

4

W7 transaction 1

5

W1 transaction 2

6

W1 transaction 3

7

W4 transaction 2

8

W1 transaction 4

9

W7 transaction 2

10

W2 transaction 1

11

W1 transaction 5

A direct transaction file might also be organized so that each display station
has its own work area. For example:

Relative Record
Number

Contents
Next available relative record number
First relative record number
W1 control record
Last relative record number

2

Next available relative record number
First relative record number
W2 control record
Last relative record number

10
11

12

W1 transaction 1
W1 transaction 2
W1 transaction 3

110
111

W2 transaction 1
W2 transaction 2

Notice that a control record is required for the records entered from each
display station. This direct file organization reduces the possibility of
contention for the same sector of data, a condition described under File
Concepts in Chapter 2; however, the number of records that can be entered
from a display station is limited, and gaps can exist between the end of one
,.section and the beginning of the next section.

Design Considerations

3-23

Volatility of Files
The frequency of additions to and deletions from a file are important factors to
consider when you choose a file organization. This disk activity is called
volatility.
Highly volatile files might be direct files because a record can usually be added
or deleted with fewer disk accesses than for other organizations, and fewer
disk accesses should help shorten response times.
For example, adding records to indexed files requires (1) scanning the index,
including added index entries, to ensure the record does not already exist; (2)
reading the data area where the new record will reside; (3) writing the record;
(4) writing the new index entry.
Adding records to a direct file might require (1) reading a control record to find
the next available location, (2) writing the data, and (3) updating the control
record. Updating the control record after each record addition makes
programming for recovery easier but requires additional disk access.
The direct file might require disk space to allow for synonym records, and
multiple disk accesses could be required for those records. Processing the
direct file should be faster than processing a sequential file as an indexed file;
however, in some cases an indexed file might be processed faster than a direct
file that has many synonym records.
Refer to Access Algorithms for Direct Files later in this section for further
information about synonym records.

Activity of the Files
Activity, which refers to the frequency that accesses are made to the file, is
not as important a factor as how a file is used or how volatile the file is;
however, activity should be considered when you choose a file organization.
Activity is usually referred to as a percent of the number of transactions to the
number of records in the file. For example, if a file has 600 records and 1200
transactions are processed randomly per day, the activity is 200 percent.
As activity increases, consecutive processing becomes advantageous because
of the chance that the record to process is available in a buffer and the record
can be accessed without physical I/O activity. Therefore, very active files
could be sequential and processed consecutively or could be indexed and
processed sequentially by key. When an indexed file is processed sequentially
by key, records added since the last key sort cannot be accessed, unless the
IFILE attribute is specified.
A relatively inactive file might best be direct or indexed and processed
randomly by key.
The total activity of a master file might be reduced by sorting a transaction file
so that only one retrieval of a master record is needed for a group of
transactions that have the same key.

3-24

RECORD DESIGN
After deciding which organization to use for a file, you can design its records
and determine the file's size.
The applications determine what data is needed in the records. Study the
applications then decide on the layout of the record. Layout means the
arrangement of fields in a record. When you design a record, you should
consider processing requirements of the record then determine each field's
length, location, and name.
To illustrate these design considerations, a name and address file is described
in the following text. Each record in the file contains the following data:
Field
Customer number
Name
Street address
City and state
Record code
Delete code
Other fields

Size (number of positions)

6
20
20
20
2
47
116 Positions

Design Considerations

3-25

Determining Field Size
Field size depends on the data in the field. The length of the data can vary, or
all data in a field can be the same length. In the example, Name is 20
positions. The length of each customer's name varies, but 20 positions should
be sufficient for most names without abbreviating them. Customer Number,
however, is six positions, and all six positions are used in each record.

Numeric Fields

If the field is numeric, you should determine whether the field is to be in a
packed or zoned decimal format. Packed format can reduce the amount of
storage required.
Be sure to allow for the maximum length for dollar-amount fields, or a
high-order position could be lost for exception conditions.
The maximum length of a packed field in RPG " is 15 digits (8 bytes). The
following table shows the number of bytes needed for a specified number of
characters in a packed field as compared to the number of bytes needed for
that number of characters in a zoned decimal field.
Number of Bytes Required
Number of
Characters

3-26

Zoned Decimal

Packed

1

1

1

2

2

2

3

3

3

4

4

4

5

5

5

6

6

6

7

7

7

8

8

8

9

9

9

10

10

10

11

11

11

12

12

12

13

13

13

14

14

14

15

15

15

The maximum number of numeric digits allowed for a numeric field is shown in
the following diagram.
Programming
Language

Numeric Digits
Allowed

Notes

BASIC

14

Long precision

BASIC

6

Short precision

COBOL

18

FORTRAN

17

Real*8 variable

FORTRAN

No limit

Decimal variable-no
limits

RPG II

15

Packed or unpacked
field

Key Length

The maximum alphameric key length is 29 positions. The maximum numeric
key length is 15 bytes or 8 bytes if the key is packed. All relative record
numbers in an add rout file are three positions long.

Alphameric Fields

No strict rules exist for determining alphameric field size. The major problem
involves fields with variable length data. For example, if the name field is
planned as 15 positions and a new customer name has 19 characters, a
problem arises when this record is added to the file. To avoid this problem, try
to estimate the maximum length of the data that will be contained in a field.
Use this length to determine field size. The maximum length of fields for
various languages is shown in the following table:
Language

Field Size

RPG
BASIC
COBOL

255 positions
255 positions
32767 bytes

Design Considerations

3- 27

Providing for a Delete Code
Your program can place a delete code in a record. Then, when the file is
processed, your program can check for this code. For example, if a customer
record becomes inactive, you may not want to process the record. Thus, a
one-position field is included to provide for a delete code.
Records with a delete code are not physically removed from a file. To remove
those records, you can use the ORGAN IZE SSP procedure.

Providing Extra Space
Because record length is not yet established when the record is designed, you
can allow for additions to the record. Although it may be difficult to plan what
data might be added, you should reserve some extra space. For example, you
might consider making the record length ten percent longer than initially
required in order to allow for future additions.

Naming Fields
An important consideration when choosing field names is that each name
should be meaningful. Meaningful field names contribute to better
documentation and help prevent misinterpretation or confusion during program
writing. The language you use to write your program places restrictions on the
length you can specify for your field names. The following table lists the
maximum length your field names can be by programming language:
Programming
Language
RPG
COBOL
BASIC
FORTRAN

3-28

Maximum Field Length
(characters)

6
30

8
6

Documenting Record Layout
When record layouts are documented, your programs are easier to write. The
following samples show the layout of a customer master record. Record layout
includes the order of the fields in the record, the length of each field, and the
name of each field. Notice that the field names follow the field-naming
guidelines. The following diagrams show different ways of documenting your
record layout. Included in this section is a sample form you can use for such
documenting.
CRECCD

CDELETE

[ipfCUSNO]
2 3

4 5

9 10

34 35

CSLSNO

BLANKS

\

\

~~

~

CCITY

CADDR

CNAME

CSTATE

ICZIPCD]' ~

81 82 83 84

59 60

88 89 90 91

128

File name: CMAST
File organization: Indexed
Key: Customer number
Record length: 128
Field Description

Length

Record code-MA

Decimal
Position

2

Delete code-D (blank if
not active)

Location
From

To

A

1

2

CRECCD

A

3

3

CDELETE

N

4

9

CUSNO

Data
Format

Field Name

Customer number

6

Customer name

25

A

10

34

CNAME

Customer address

25

A

35

59

CADDR

City

22

A

60

81

CCITY

State

2

A

82

83

CSTATE

0

Zip code

5

0

N

84

88

CZIPCD

Salesman number

2

0

N

89

90

CSLSNO

A

91

128

Blanks

38

Record Length

Although field lengths within a record may vary, the field lengths for the same
fields in each record in a file should be the same, and all records in a particular
file must be the same length. Record length is the sum of the field lengths
including reserved space. The maximum record length for a disk file is 4096
positions.
In the name and address file example in this section, the sum of the fields was
set at 90 positions. However, record length was set at 128 to reserve 38
positions for data that might be needed at a later time.

Design Considerations

3- 29

File No. _ _ _ __

INPUT/OUTPUT Record De,s<;ription
'.

',;.!.

System _ _ _
_ _ _ _ _ _ __
Customer Record
Page _ _ of~_~
Date _ _ _ _ _ __
File Name _C;;. ;.MA;. .; ;. ; ;.; ;. S.; ; .T______________
181 Disk
Sequence Customer Number
Prepared by _ _ _ __
File Organization Indexed
Key Customer Number
Key Length_6________
Record Length --=1:..:2~8::....-_ _ _ _ _ __
Created by _ _ _ _ _ _ _ _Used by ORDHDR
.. Updated by _ _ _ _ _ _ _ __
Record Name

Values

~

Field Description

CRECCD "
CDELETE
CUSNO
CNAME'
CADDR
CCITY
eSTATE
CZIPCD
CSLSNO

Record Code
Delete Code
D, blanks
000001-999999 Customer Number
Customer Name
Customer Address
City
state
zip Code
Salesman Number
01-99
Blanks
MA

Decimal
Format
Pos.

Length

Field Name

2

1

..

0

·6

25·
25
22
2
5
2

0
0

38

.

.

.

..

.

..

3-30

A
A
N
A
A
A
A
N
N
A

Location
From
To

1
3

2
3

4
10
35
60
82
84
89
91

9
34
59
81
83
88
90
128

File No. _ _ _ _ __

INPUT/OUTPUT Record Description
Record Name _ _ _ _ _ _ _ _ _ _ _ __

System _ _ _ _ _ _ _ _ _ _ _ __

File Name _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _File Organization ______

o Disk

Page _ __

of _ __

Date _ _ _ _ _ _ __

o Diskette

Sequence __________________________

Prepared by _ _ _ __

Record Length _____________
Created by _ _ _ _ _ _ _ _ __
Values

Key _ _~--------- Key Length _ _ _ _ _ _ _ _ __
Used by _ _ _ _ _ _ _ _ __
Updated by _ _ _ _ _ _ _ _ __

Field Description

Field Name

Length

Decimal
Format
Pos.

Location
From
To

Design Considerations

3-31

RECORD BLOCKING
A block is the number of characters transferred as a unit of information
between a disk file and the processing unit. Although only one record at a
time is available for processing by your program, one or several records may
be transferred in a block at one time.
The block length is used to specify the amount of main storage used for an
I/O buffer in the user program. Block length does not affect the way that
records reside on disk, and the block length in a program does not have to
match the block length specified when loading the file.
Block length is a multiple of record length. For example, if the record length is
64, the block length could be 256. Four records would be transferred at one
time.
For efficient blocking, you should choose a record length that is either a
multiple or submultiple of 256. For example, 512 would be a multiple of 256,
and 64 would be a submultiple of 256 because it divides into 256 a whole
number of times.
This choice is best because data is always transferred in sector increments,
which are 256-byte increments, and you eliminate the chance of having records
reside in more than one sector. For example, if the record length is 64 and the
block length is 128, 2 blocks, which is one sector, would transfer with each
physical I/O operation.
You can specify l00-character records as shown in the following example:

Sector A
100
Record 1

Sector B

~

100
Record 2

56
1' - .1441
,-'

100

100

1

12

1

Record 3

To process record 3, therefore, 2 sectors must be in main storage: sector A
and sector B. The first 56 characters of record 3 reside in sector A; the
remaining 44 reside in sector B. Thus, to process l00-character records with a
block length of one hundred, 512 characters (2 sectors) must be available in
main storage.

3-32

As another example, suppose you specified 100-character records with a block
length of 400. Four 100-character records might span 3 sectors. To process
your records in this case, 768 characters (3 sectors) might be required in main
storage.

Sector B

~

Sector C

1121

100

88

1

Sector D
100

~

Record 6

68

32
1 1

100

~

Record 7

Record 8

....

I~

Record 9
~

Block Length of 400

Blocking can be an advantage if you are likely to process multiple records in
the block; by specifying a large block, you can reduce the physical I/O that
occurs for a logical I/O operation.
For example, assume you read a file consecutively when the records are
blocked 100 per block. The first get operation, a logical I/O operation, results
in one relatively long read operation, a physical I/O operation, of 100 records.
However, the next 99 get operations read from the buffer in main storage that
holds the block of records and require no physical I/O.
For files processed randomly, you should not specify a large block length
unless you are sure that more than one record will be processed in a block
before another block is transferred.
For shared indexed or direct files that are processed randomly you should not
block records because the entire block would be transferred for each input or
output operation.
Finally, you might choose not to block records if you are trying to keep a
program from getting too large.

Design Considerations

3-33

PHYSICAL I/O AND LOGICAL I/O
Physical I/O operations are those operations that cause disk read and write
operations to occur. These operations take time because disk arm positioning
and moving is usually required. Therefore, during system design you normally
plan to minimize physical I/O operations in order to improve response times
and system performance.
Logical I/O operations are get and put operations that access records. The
number of physical I/O operations that result from logical I/O operations is
affected by the following factors:
• Record blocking
• Access method
• Storage index
• Sequential processing
• File sharing
• Buffer sharing

Blocking Records to Minimize Physical I/O
By specifying a relatively large I/O buffer for a program, you can often
minimize the physical I/O activity for a set of logical. I /0 operations. A large
I/O buffer reduces physical I/O activity for files that are not shared and for
shared files that are processed consecutively or sequentially by key for input
only.
For example, assume you specify a block of 100 records and use the
consecutive input access method. The first get operation causes a disk read
operation to occur that reads 100 records into the buffer. The next 99 get
operations read from the buffer and require no physical I/O operations.
Refer to Record Blocking in this section for further explanation.

3-34

Access Method
Another factor that affects the amount of physical I/O activity is the access
method that you use. When a file is accessed with an indexed access method,
each logical I/O operation results in a logical I/O operation that processes the
index entry and a logical I/O operation that processes the data record. The
amount of physical I/O activity that occurs depends on whether the contents
of the index buffer can be used for index entry processing and whether the
contents of the data buffer can be used for data record processing.
For example, assume that the logical I/O operation is an indexed sequential
get and the index buffer already contains the next index entry. In this situation,
physical I/O is not required to process the index entry, which can be read from
the buffer by the logical operation. After the index entry is processed, the data
buffer is searched to find the associated data record. If the record is in the
buffer, the record can be read by a logical operation, and physical I/O does
not occur.
In the previous example, either one or two disk read operations would have
been required if either the index or the record had not been in the buffers.

Storage Index
For COBOL, RPG II, WSU, BASIC, and Basic Assembler programs you can
request that the system create a storage index, which is an in-storage index to
the actual file index on disk. (The storage index is called a master track index
in some System/34 publications, and a key work area in BASIC.) A storage
index can significantly reduce the amount of physical I/O activity required to
process an indexed file because the storage· index enables the system to go
more directly to· a record you want.
When a storage index is not used, the system sequentially searches the file
index until it finds the entry for a requested record. This search often requires
several I/O operations. When you request a storage index, the system divides
the file index into segments and then creates a storage index, which points to
each of the segments. The storage index eliminates needless searching by
directing the system to the index segment containing the entry for the
requested record~
If the space allocated for the storage index is large enough, the system divides
the file index into segments one track long. If enough storage index space is
not allocated for this optimal segmentation, the system divides the file index
into larger segments. Each storage index entry contains (1) the lowest key field
from the next segment in the file index and (2) a sector address that points to
a segment of the file index.
The sector addresses in the storage index are relative sector addresses which
represent a displacement sector address from the start of the file.
Note: The storage index is supported by the SETLL instruction for RPG II and
the START instruction for COBOL.

Design Considerations

3-35

The following chart shows the storage index for a file index that occupies four
tracks on disk. If a program requests the record with key 1541, the system
searches the storage index and determines that the requested record is on
track B. The system then scans the index entries on track B until the entry for
record 1541 is found. The system can then chain directly to the data record.

Storage Index for File INDEXT

I-

_I

48 bytes
1-13 bytes-..J

I
000

I Record Key

I

I

1543

SSS

/

I
I Record Key

I

I

2800

I

I
SSS I FFFFF .•. F

;

'-v-I

Distance in Sectors from
start of File to Start of
Track C

\

Distance in Sectors from
start of File to start of
Track 0

File Index for File INDEXT

TRACK A

UI
I

3 .. 36

IRecor~

I

Key

I

Record Key I
345
I

Record Key I
346
I

Record Key
1541

Record Key
1542

I

TRACK B

Record Key I
I
347

Record Key
348

Record Key I
I
349

TRACK C

Record Key
1543

Record Key
1544

Record Key I
I
1545

TRACK 0

Record Key
2800

Record Key
2801

Record Key I
2802
I

I

I

I

Record Key I
I
2798

I

Record Key I
I
3173

I
I

I

I

Record Key I
I
2799

To calculate the amount of space required for the optimal storage index, you
should first calculate the number of tracks used by the file index. The number
of tracks used by the file index is related to the capacity of your disk. You will
use different numbers to calculate the file index if you have more than 27.1
megabyte disk capacity. To determine the number of tracks used by the file
index and the amount of space required for the storage index:
1.

Use the STATUS command to determine disk capacity.

Is the disk capacity greater than 27.1 megabytes?
a. If yes, the file index will have 64 sectors per track.
b. If no (that is, if the disk capacity is less than or equal to 27.1
megabytes), the file index will have 60 sectors per track.
2.

Use the CATALOG procedure to determine the number of records in the
file.

3.

Add three (3) to the key length to determine the length of an entry in the
file index. (Each entry in a file index is composed of the record key plus
the 3-byte address of the record in the file.)

4.

Divide 256 by the entry length to determine the number of keys in each
sector. Drop the remainder.

5.

Divide the number of records in the file by the number of keys in each
sector to determine the number of sectors in the index. Round· off the
result.

6.

Divide the number of sectors by either 60 or 64 to determine the number
of tracks in the index. Round off to the nearest whole number any
fractional result.

7.

Multiply the number of tracks in the index by the length of an entry in
the file index to determine the optimal index size.

Design Considerations

3-37

The following two examples, using an indexed file containing 8000 records
with 9-byte keys, show the calculation of the index size. The examples show
the effects of different disk capacities on the optimal size of the storage index.

II

Disk capacity greater than 27.1 megabytes

B 8000 records
B 9 + 3 = 12 bytes for the file index entry

II 256/12 = 21 keys in each sector
II 8000/21 = 381 sectors in the index
B 381 /64 = 6 tracks in the index

a 12 *

6 = 72 bytes for the storage index

Disk capacity less than or equal to 27.1 megabytes

8000 records
9 + 3 = 12 bytes for the file index entry
II 256/12 = 21 keys in each sector
8000/21 = 381 sectors in the index
m381/60 = 7 tracks in the index
12 * 7 = 84 bytes for the storage index

II

a

If .the application program cannot accommodate the amount of storage required
for the optimal sized storage index, you' can specify a smaller size, but this
smaller size results in a correspondingly smaller improvement in performance.

Sequential Processing

If record processing is sequential relative to the physical order of records on
disk, a performance advantage can be gained. For example, assume 50
records per block and sequential processing is used. Physical I/O for data
might be required only once for each set of 50 logical requests.

File Sharing

File sharing affects the amount of physical I/O activity for each logical I/O
operation. For most access methods, each logical I/O operation causes at
least one physical I/O operation.
Exceptions to this guideline occur for consecutive input-only processing and
indexed sequential input-only processing, which do not always require physical
I/O activity for each logical I/O operation.

Shared I/O

Shared I/O allows two or more. files in one job to share the same buffers and
causes a large amount of physical I/O activity because buffers must be reread
for each logical I/O operation.

3-38

ACCESS ALGORITHMS FOR DIRECT FILES
A key to designing and implementing a direct file is defining an access
algorithm that satisfies the processing requirements for the file while preserving
the advantages of direct files.

Determining an Access Algorithm
An access algorithm is whatever fixed (programmed) method is used to
determine the position to be occupied by each record. The algorithm can be
simple or complex. In any case, the algorithm must yield a positive, whole
number as a relative record number.
In the simplest case, relative record numbers are assigned sequentially. The
first record placed in the file has relative record number 1, the second record
has relative record number 2, and so on.
In another simple case, a control field in each record is used as its relative
record number. For example, loan number 3456 could be used without change
as relative record number 3456. Another example of a direct technique is using
direct files to store large arrays of data. If element 10 is desired, then the
tenth record in the file is read. A control field should be used directly as a
relative record only if there is not an excessive number of unused values within
the range of values for the control field. If there are too many unused values
and, therefore, unused record positions, an algorithm should be defined to
reduce the size of the file.
A formula can be used as an algorithm to determine the record number. For
example, if loan numbers start with 1001, then loan number 3456 could be
relative record number 2456 (3456 minus 1000). The formula can be as
complex as you need to make it. Refer to Examples later in this chapter for
more information and examples.
A control field that contains alphameric data could also be used. An algorithm
must convert the alphameric data to a relative record number. Refer to
Handling Synonym Records later in this chapter for an example of using a
customer name as the control field.
The choice of an access algorithm and, ultimately, the decision whether or not
to use a direct file is usually based on how well synonym records can be
handled. A synonym record is a record in a direct file whose control field yields
the same relative record number as another control field. If the handling of
synonyms requires a significant number of additional disk accesses, one of the
important advantages of the direct file is lost. Also, because the access
algorithm and the synonym code must reside in each program that uses a
direct file, a risk is involved: if the algorithm and synonym handling are
revised, you might need to rebuild files and modify all the programs that use
those files.

Design Considerations

3-39

Handling Synonym Records

Synonyms can be handled in many ways. Some of the common ways are:
• Place synonyms in a separate part of the file, following the home locations,
which are the locations used for home records. A horne record is a record
that is stored in the location indicated by its relative record number.

'Home Locations

Synonyms

• Place synonyms in the next available blank location, closest to the home
location.

Relative
Record Numbers
Record Positions

• Place synonyms in an area, next to the home location, that is reserved for
synonyms.

IHome ISynonyms IHome ISynonyms IHome ISynonyms I
In the first two methods, the record in the home location must contain a
pointer to the synonym record location. If two or more synonyms exist for a
home location, the first synonym contains a pointer to the second synonym,
and so on.

3-40

In the third method, synonyms are close to the home location. For example,
assume the control field for a file is the first five characters of the customer's
name. The file contains space for 40000 records and allowance for three
synonyms for each home record. The customer's name is converted to a
decimal value as follows:

S MIT H

//\"'~
D4 C9 E3 C8

E2

I

F2

I

F4

I F3I F8I

F9

,,\
/ /~
2 4 938

(EBCDIC code)
(zoned decimal)
(decimal)

The decimal value is then divided by 9999:
24938

+ 9999 = 2.4940

Ignoring the whole number of the quotient, you would calculate the home
location as follows:
(4940 x 4) + 1 = 19761
Because many Smiths may be in the file, the program may have to read
records 19761, 19762, 19763, and 19764 to find the correct Smith. If extra
synonyms are required, the third synonym could point to the next available
space in the file (possibly the next home location will not require all its
synonym locations). Another possibility, to reduce the number of synonyms,
would be to accept six or more characters from the customer name.

Design Considerations

3-41

Examples
The following examples illustrate direct file approaches.

Example 1
In this example, the major goals are to build a file in which (1) the records can
be accessed with an average of slightly more than one disk access, (2) the
amount of disk space used for the file does not contain excessive unused
space, and (3) the file can grow and easily accommodate new records.

Defining the Algorithm
In this example, an indexed item file is to be converted to a direct file for an
online order entry application. The key field is a five-digit item number; four
digits are assigned by the user, and the fifth digit is a check digit. The four
digits start with 1001, and the user merely assigns the next sequential number
to new items. Deleted item numbers are not reused until item number 9999
has been taken. Approximately 20 new items are added per month, and four
items are dropped. The highest current number is 4317, but the file contains
only 2812 items.
As a first approach, the algorithm could be stated this way: the direct file
position for each record shall be equal to the four-digit item number. Assume
that the new record will bea few bytes larger than the old record and that the
file will also accommodate 12 months of growth before reorganization. The
algorithm would require a file containing 4557 record positions. The mapping
of items to direct file positions would appear as follows:

Item Number

File Position
1st

} Unused

12
Months
Growth

1000th
• 1001st

1001
1002
1003

• 1002nd
I
1003rd

4317

• 4317th

l

4557

I

4557th

This first approach, while yielding no synonyms, uses only two-thirds of the
record positions, and most of the unused space is at the beginning of the file.

3-42

Assume the algorithm is revised to state: the direct file position for each
record shall be equal to the four-digit item number minus 1000. The file
requires 3557 positions with the following mapping:

Item Number

File Position

1 0 0 1 - - - - - - - -... 1st
1002
• 2nd
1003
• 3rd

4317 --------~. 3317th

4557 - - - - - - - - . . . 3557th

This approach, also yielding no synonyms, uses 85 percent of the record
positions; the unused portion is embedded randomly within the file where
items have been dropped. Although each record only requires one disk access,
the file size still is 15 percent larger than the data portion of the file when
organized as an indexed file. The algorithm can be further revised.
Now assume the algorithm states: the direct file position for each record shall
be found by subtracting 1000 from the four-digit item number, multiplying the
difference by 0.85, and half-adjusting the result. The file will occupy 3023
positions with the following mapping:

File Position

Item Number

1 0 0 1 - - - - - - - - - , 1st
1002
- 2nd
1003
3rd
I

4 3 1 7 - - - - - - - - - 2819th

r
3023rd
4557 _ _ _ _ _ _ _ _

This approach uses 99 percent of the record positions, and the file size is only
1 percent larger than the indexed data. It has, however, introduced the
possibility of synonym records; item number 1004, if it exists, will also be
assigned to direct file record position number 3 (same as 1003). Similarly, item
numbers 4316 and 4317 conflict, as do 4556 and 4557. Thus, the refinement
of the algorithm to meet the second major goal, minimum file space, may now
have affected the first goal, minimum disk accesses, because synonym records
will take a minimum of two accesses.

Design Considerations

3-43

Handling Synonyms

Various methods of handling synonyms exist. Whatever method is used, it
must accomplish two goals: minimum accesses and minimum file space. The
more immediate goal is to define (program) the manner in which a record will
find an alternate position when its first location choice is filled.
Further analysis of the previous item file example might offer some
suggestions for synonym handling. Note that a synonym in that example
occurs about once in seven records.
The previous algorithm causes the following mapping (asterisks identify
synonyms):

Item

Position

Item

Position

Item

Position

1001
1002
1003
1004
1005
1006
1007
1008

•

1009
1010
1011
1012
1013
1014
1015
1016

• 8
• 9*
• 9*

1017
1018
1019
1020
1021
1022
1023
1024

• 14*
.. 15

J
J

•
I

•

1
2
3*
3*
4
5

• 6
• 7

• 10
• 11
.. 12
• 13
• 14*

Approximately one in seven item numbers is unused because of deleted items;
the file is only· 86 percent full. Thus, you might expect to find an unused
position in the direct file with about the same frequency as the synonyms
occur.

3-44

• 16
• 17
I
18
• 19
• 20*
• 20*

Assume the method of handling synonyms can be stated: a synonym record
will be placed in the next higher numbered position that is unused. Because
the file uses only 85 percent of the range of numbers, 15 percent of the
numbers will not be used because they are deleted. However, the deleted
numbers are randomly distributed through the entire range of numbers. Thus,
some positions will be available in the file for synonym records. About every
seventh number will be a synonym. Assume that of the first 40 item numbers,
items 1007, 1008, 1015, 1017, 1020, and 1039 are among those deleted
numbers.

Item

Position

Item

Position

Item

1001
1002
1003
1004
1005
1006
1009
1010
1011
1012

• 1
• 2
r 3
• 6
I
4
I
5
• 8
I
9
I
13
I
10

1013
1014
1016
1018
1019
1021
1022
1023
1024
1025

11
12
I
14
• 15
• 16
I
18
I
19

1026
1027
1028
1029
1030
1031
1032
1033
1034
1035

I

I

• 20
• 33
I
21

Item

Position

1036
1037
1038
1040

I
22
• 23
• 24
• 25
r 26

Position
I

31

**
I
I

32
34

**
I

27

• 28
• 29
• 30

Note the following:
• Item number 1031 will occupy some position numbered greater than 34.
• Item number 1037 will occupy a higher numbered position than will item
number 1031.
• Record positions 7 and 17 are unused.
• After accessing a record, the program will have to verify that the record is
the one that the program really wants; if it is not, the program must access
a synonym.
• There will not be more than two items with the same relative record
number; thus, most records require no more than two disk accesses.
Note: This example assumes that records are loaded into home locations
before synonym records are loaded in a second run; this example also
assumes that there will be few added records. If records are added after
the home records and synonyms are loaded, the home locations for the
added records may be occupied by a synonym. Thus, the added record
becomes a pseudo synonym. If many records are added, most will have to
be handled as synonyms. In this situation, the technique described here
may be less useful because performance tends to be degraded as records
are added.

Design Considerations

3-45

In this synonym-handling technique, the average synonym should be close to
the first position searched. Thus, a second. access is necessary approximately
15 percent of the time, and this access should find the record not too distant
from the home location.
At this point, the file shouJd be loaded (home positions only), and the
synonyms added in a second pass. As the synonyms are added in the next
available higher numbered position, a synonym pointer in the home record will
have to be updated to point to the synonym record position.

Example 2

Assume a customer master file contains three types of records (A, 8, and C)
for three types of customers. These records are in an .indexed file in which
type A records have keys-customer numbers from 10000 to 49999; type 8
records are numbered from 60000 to 79999; and type C records from 90000
to 99999. Each type of record is arranged alphabeticaUyby customer name.
The file was first loaded with approximately 500 alphabetized type C records,
followed by 1000 alphabetized type 8 records, and finally about 3000
alphabetized type A records.
Additions have been made at the end of the file in the following manner: first,
the added record type is determined-A, 8, or C; then it is assigned an unused
customer number that corresponds to the alphabetic sequence of the customer
name according to a listing of the file. When first loaded, the contents of the
file were as follows:

Record #0001
Record #0002
Record #0003

Customer #90000}
Customer #90020 Type C (alphabetical
by customer name)
Customer #90040

Record #0467
Record #0468
Record #0469

Customer #60020}
.
Customer #60040 Type 8 (alphabetIcal'
by customer name)
Customer #60060

Record
Record
Record
Record

3-46

#1592
#1593
#1594
#1595

Customer
Customer
Customer
Customer

#100001
#10013 Typ.e... A (alphabetical
#10026 ,by customer name)
#10039
.

The file originally contained 4725 records; space was allowed for 6000.
Eighteen months later, the file contains 5638 records.
An analysis of the file indicates the following:
• The file is experiencing about 12 percent annual growth and should probably
be planned for about 6600 records to meet one year's requirements.
• Customer numbers 10000-50000 are 8 percent used, and the other numbers
are 5 percent used.
• Synonym records should be kept as close as possible to the home location.
• The best file design solution might be more than one file and more than one
type of file organization.
• If all the customer numbers will be in one file, an algorithm must take into
account the necessity of loading type C customers at the front of the file,
followed by types Band A.
• The ratio of A:B:C types is about 6:2:1.
A trial algorithm might try to accomplish the following mapping:

Customer
Number

90000-99999
60000-79999
10000-49999

Type

File Record Number

C

0001-0733 (1/9 x 6600 = 733)
0734-2200 (2/9 x 6600 = 1467)
2201-6600 (6/9 x 6600 = 4400)

B

A

In order to accomplish the mapping, the algorithm must:
• Convert customer numbers 90000 to 99999 into a set of relative record
numbers from 1 to 733
• Convert customer numbers 60000 to 79999 into a set of relative record
numbers from 734 to 2200
• Convert customer numbers 10000 to 49999 into a set of relative record
numbers from 2201 to 6600

Design Considerations

3-47

One method of doing these conversions is as follows:
• If the customer number is greater than 89999, subtract 89999 from it; then
multiply the difference by 0.0733 (the ratio of 733 positions to 10000
numbers), and use the half-adjusted product as the record position.
• If the customer number is less than 50000, subtract 9999 from it; then
multiply the difference by 0.11 (the ratio of 4400 record positions to 40000
record numbers), add the half-adjusted product to 2200, and use the sum as
the record position.
• For all other customer names (60000 to 79999), subtract 59999 from the
number, multiply it by 0.0733 (the ratio of 1467 record positions to 20000
numbers), add the half-adjusted product to 733, and use the sum as the
record position.
The synonym-handling technique might be the same as in Example 1.
The test of success might be to implement the algorithm/synonym-handling
technique by loading the file. Then the success can be measured by another
program that attempts to retrieve all records and counts the number of
accesses necessary. The results of the second program dictate whether
modifications are necessary or desirable. To further test the file, a sample
program can be run in an interactive environment to see whether response
times at the display stations are acceptable.

Example 3

Other master files might have altogether different uses and for that reason use
different techniques. Consider a rate file in a telephone revenue accounting
application wherein one record exists for every from-to location in the United
States. A call made from number (507) 286-5688 to (518) 392-5536 would
require the retrieval of a rate record from the master file that would have a key
of 507286518392. How can such a number be equated to a relative record
position on a direct file?
One algorithm might be to multiply the numbers 507286 and 518392 and use
the second, fourth, sixth, eighth, and tenth digits of the product as the relative
record position. This technique might yield a random distribution across a file
for approximately 100 000 records. Another algorithm might be to take the
second, fourth, sixth, eighth, and tenth digits from the 12-digit key. Thus, the
first algorithm might locate the rate record in relative position 69301
(262973004112); the second algorithm might place the same record in position
02613. Some records, for a given billing location, would be far more active
than the majority of the records. These very active records might be placed in
a separate file, which mayor may not be direct.
The techniques described in the previous paragraph are randomizing
techniques. Many randomizing techniques are employed by users of direct
files. Regardless of which technique is used, the concept and approach should
be well documented in each program that uses the technique.

3-48

Application Design
After the applications for the System/34 have been chosen, you can plan
which programs should be designed and implemented first. You might
consider the following factors to help you decide upon the initial programs:
• Which application best justifies the cost of the System/34? An accounts
receivable application or an order entry application might benefit the
business most quickly.
• Which application makes the user departments more productive and the
users' jobs easier? Inquiries from display stations are typically programs that
can help the users do their jobs more effectively.
• Which application can be designed and implemented in the least amount of
time? Again, applications that have numerous inquiries are usually easiest to
plan.
• Which application are you most familiar with? If possible, starting with an
application that you have implemented or operated on another system is
usually a good idea.
A good design technique, therefore, is to begin by designing the easiest
programs and gradually add the more complex programs. Inquiry programs are
usually a good starting point because they are relatively simple and operators
can use them productively with minimal instruction. More complex programs
can be added as confidence in programming and operating the System/34
grows.
Most applications for System/34 have both batch and interactive programs.
Interactive programs communicate with one or more display stations; batch
programs do not have this interaction.
Interactive programs can be classified as data entry, inquiry, or file update. The
following examples show typical interactive programs:
Function

Program

Application

Data entry

Order entry

Order entry

Inquiry

Open order inquiry

File update

Inventory allocation

Data entry

Cash receipts entry

Inquiry

Accounts status inquiry

File update

Open accounts receivable items

Data entry

Inventory receipts/adjustments
entry

Inquiry

Inventory status inquiry

File update

Vendor code changes

Accounts
receivable

Inventory control

Design Considerations

3-49

DATA ENTRY PROGRAMS
Data entry programs allow one or more operators to enter data directly into the
system via display stations. Data entry programs involve nearly continuous
operation of display stations. Operators enter transactions such as order
information, cash receipt information, or inventory receipt/adjustment
information, and programs process them or save them for later processing.
Typically you will need to choose data entry programming methods. The Data
File Utility (DFU), Work Station Utility (WSU), and RPG II Program Product are
three methods that offer similar data entry functions. The following table and
descriptions compare these data entry methods. These three methods are not
the only ways to code interactive data entry programs. For example, COBOL,
BASIC, FORTRAN, and Basic Assembler programs can interact with display
stations.

DFU Data Entry Programs
DFU programs are generally best for high-volume data entry with minimal
operator guidance and no editing other than modulus 10 and modulus 11 self
checking. DFU can create an indexed file or a direct file from the entered data.
Programming is easily done by answering a series of prompts.
DFU programs are SRT programs. Multiple operators, if they run the same
program, use separate copies of the program and unique or shared transaction
files. Refer to the System/34 DFU Reference Manual for a complete description
of the functions of DFU.
To allow several operators to enter the same type of data using common DFU
specifications, you can create a procedure that contains the required DFU
command. The file name in this command should be the file name
concatenated with the 10 of the display station that calls the procedure. This
technique results in unique files for each operator. For example, creating an
order file from two display stations could be allowed by using ORD?WS? for
the file name. Two files would be created: ORDW1 from display station W1
and ORDW2 from display station W2.

3-50

WSU Data Entry Programs
WSU programs optionally create a direct transaction file from a master file or
files and the data entered from one or more display stations. WSU programs
can be front-end entry programs for programs that do final editing, processing,
updating, and printing. WSU is designed for efficient display station data entry
and processing and, therefore, does not provide printed output.
WSU programs are always M RT programs, which means they can be used
concurrently by multiple operators. The MRT program can use input from
operators, from master files, and from results of processing within the program
to create and maintain one transaction file. The program can also add records
to and update any master files that are used by the program.
Two or more different WSU programs can be running at the same time and
can share master files. For example, payroll input, job costing input, and
accounts payable can be handled by three separate WSU programs that run
concurrently. Sharing of transaction files, however, is not supported.
The transaction file that a WSU program creates is a direct file, and the
records are partitioned logically by display station. WSU formats the
transaction file with special header and trailer records to identify the records.
WSU protects each partition so that records entered from one display station
cannot be read or modified from another display station unless a special WSU
function is enabled. This special function allows you to read and modify
records entered from another display station. For more information about this
special WSU function, refer to Chapter 14 of the Work Station Utility Reference
Manual.
Because of the headers and trailers, the transaction file cannot be input to a
follow-on program until this control information has been removed or handled
in the program. RPG II provides a subroutine, SUBR22, that can be used to
prepare the transaction file for processing. Refer to the System/34 RPG "
Reference Manual for a description of SUBR22.
WSU also provides support for removing the control information. A rebuild
procedure for WSU allows you to copy a WSU transaction file and change it to
an indexed or sequential file. The new file can then be processed by a
subsequent program.
An extract procedure can copy specific records to another file or remove blank
records from a WSU transaction file. The extract can also be used to create a
WSU transaction file by adding control information. This function allows you to
create a file on a separate data entry device and then update the file using
WSU.

Design Considerations

3-51

A WSU program, using an indexed random or a direct access processing
method, can read from and write to as many as 20 master files. These files
can be indexed, direct, or sequential files. Master files can be reviewed,
updated, and added to by operators if the programmer codes these functions
in the program.
WSU programs can do more edit checking than DFU programs. Some
checking is done by the display station; for example, numeric data entered in
an alphabetic field will cause an error to be flagged, and the operator can
reenter the field. Some checking can be specified by the programmer on
display screen specifications; for example, mandatory fill, mandatory enter, and
self-check fields can be defined on these specifications. Additional checking
can be done within the program; for example, the calculations for a display can
check for valid entries within a range of values and reshow the display with the
cursor positioned at the field in error.
Refer to the System/34 WSU Reference Manual for a complete description of
WSU programs.

RPG II Data Entry Programs
RPG II provides three methods of coding data entry programs:
• WORKSTN file
• CONSOLE file
• SET/KEY logic of the KEYBORD file
Programs that use a WORKSTN file have the most display design flexibility
because these programs use display screen formats defined by the
programmer. For example, field attributes and a variable starting line number
can be specified. Also, multiple items per display can be programmed.
Programs that use a CONSOLE file are easy to code. The format of displays
are determined by RPG II when the program is compiled. Multiple items per
display are allowed and require no additional programming.
Programs that use SET/KEY logic provide field-:-by-field data entry. Data is
entered on the bottom line of the display and, when entered, rolls up one line
to allow the next field to be entered on the bottom line.
Refer to the System/34 RPG /I Reference Manual for descriptions of coding
data entry programs via the previous three methods.

3-52

RPG
Function/Feature

DFU

WSU

IKEYBOARD

CONSOLE WORKSTN

Field attribute selection

No

Yes

No

No

Yes

Yes

Yes

Variable starting line

No

Yes

No

No

Yes

Yes

Yes

No

Yes

Not

Yes

Yes

Yes

Yes

Yes

Programmable

Programmable Programmable

COBOL

BASIC

Display layout

number
Multiple items per display

recommended
Display associated with

Yes

Programmable No

record type

Function/Feature

DFU

Printed output

Yes

No

Yes

Yes

Yes

Yes

Master file access
Multiple user (MRT)

LIST only

Yes

Yes

Yes

Yes

Yes

WSU

RPG

COBOL

BASIC

FORTRAN

No

Yes

Yes

Yes

Yes

No

-

Most

Some

Programmable

Programmable

Partitioned
direct

User-coded

User-coded

-

Maximum record length

Indexed,
sequential,
direct
512

-

4083

4096

4096

4096

4096

Review mode

Yes

Yes

Programmable

Programmable

Programmable

Programmable

Insert mode

Yes

Yes

Programmable

Programmable

Programmable

Programmable

Control over operator
modification

No

Yes

Yes

Yes

Yes

Yes

Self-check numbers

Hardware
feature

Hardware
feature

Hardware
feature

Hardware
feature

Hardware
feature

Hardware
feature

Maximum alphameric field
length

60

256

256

4096

255

4096

Limited

MRT code handled
Transaction file

Calculations

Yes

Yes

Yes

24'

Yes
Many

Yes

Number of result fields

Many

Arrays

No

No

Yes

Many
Yes (3-D)

Many
Yes (2-D)

Many
Yes (3-D)

Edit checking

No

Yes

Yes

Programmable

Programmable

Programmable

Batch totals with insert
and review mode
adjustments

Yes

Programmable

Programmable

Yes

Yes

Yes

Yes

Time of day

Yes

Yes

Yes

Yes

Yes

Date

Yes

Yes

Yes

Yes

Yes

Yes

Local data area access

No

Yes

Yes

Yes

Yes

Yes

User switch access
Roll keys handled

No
Yes

Yes
Yes

Yes
Programmable

Yes
Programmable

Yes
Programmable

Yes
No

Dup key handled

Yes

Not
available

Programmable

Programmable

Programmable

No

No
Yes

Yes

Roll portion of screen

No

No

No

Yes

Write on message line

No

Yes

No

Allow help key

No

No

Yes

Yes
No

Yes

No

Read message member via
format output

No

Yes

Yes

Yes

Yes

Yes

Explicit open / close

No

No

No

Yes

Yes

Yes

User indicators

No

Limited

Limited

Yes

Yes

No

No

Note: Yes means the function or feature is available for the programming method; No means the function or feature is not
available.

, Less if more than one factor is used per result field.

Design Considerations

3-53

The Badge Reader as a Data Entry Device
You can use your badge reader as a means of entering data into the system.
The data is encoded onto a magnetic stripe which is part of the badge that is
read by your badge reader.
The encoding of this data onto the magnetic stripe involves special data
encoding considerations. Contact your local IBM branch office for more
information about encoding data for use with magnetic stripe badges.

Editing in Data Entry Programs
Data editing at the time data is entered into the system should be a primary
function of an online application. The same basic edit functions apply to data
regardless of the application involved. This section addresses some major
editing problems that you could encounter.
One or more of the following edit checks may be specified for any given data
field.
• Field editing
Mandatory field entry
Every field required
At least one field required
Only one field required
Default value editing
List check editing
Range check editing
Mandatory fill
Self checking
Adjust/fill
Duplication
• Date editing
• Compatibility editing
• Table look-up editing
The following sections provide a detailed discussion of some of the types of
edit functions that could be considered.

3-54

Field Editing
Field editing performs basic data characteristic validation for data fields within
a transaction. Some of the key types of data characteristics possible are:
• All characters must be blank or alphabetic.
• All characters must be blank or numeric.
• All characters must be blank, alphabetic, or numeric.
• All characters must be numeric.
• All characters must be numeric, with leading blanks optional. Field must not
contain embedded blanks.
• All characters must be alphabetic or numeric.
• All characters must be alphabetic. Field must not contain leading or
embedded blanks.
• All characters must be alphabetic, numeric, blanks, or special characters.
• All characters must be alphabetic, special characters, or blanks.
• All characters must be numeric, special characters, or blanks.
• All characters must be special characters or blanks.
• All characters must be special characters.
• All characters must be alphabetic, numeric, or blanks, with no leading
blanks.
• All characters must be alphabetic, numeric, or blanks, with no trailing
blanks.
• All characters must be alphabetic, with no embedded blanks. Leading and
trailing blanks are permitted.
• All characters must be numeric, with no embedded blanks. Leading and
trailing blanks are permitted.
• All characters must be numeric, alphabetic, or special characters, with no
embedded blanks. Leading and trailing blanks are permitted.
• All characters must be alphabetic or special characters, with no embedded
blanks. Leading and trailing blanks are permitted.
• All characters must be numeric or special characters, with no embedded
blanks. Leading and trailing blanks are permitted.

Design Considerations

3-55

• All characters must be special characters, with no embedded blanks.
Leading and trailing blanks are permitted.
• All characters must be alphabetic, numeric, with no embedded blanks.
Leading and trailing blanks are permitted.

Mandatory Field Entry: Specifies that a value must be entered for a field.
Blank fields that have been designated as required fields are invalid. Other
types of editing may also be done on required fields. If a field is to have a
default value, mandatory field entry should not be specified.

Required Entry of Every Field: Specifies that all fields in a logical group must
be entered if anyone field of the group is entered. This capability might be
used, for example, on a mailing address to specify that if any part of the
address-street, city, or zip code-is entered, then all the mailing address fields
are required.

Required Entry of at Least One Field: Specifies that at least one field in a
logical group of fields must be entered. This editing might be used, for
example, on a list of the reasons a student has withdrawn from a university, to
ensure that at least one reason for the withdrawal has been entered.

Required Entry of Only One Field: Specifies that only one field in a logical
group may be entered. If a group of fields is mutually exclusive, but one field
is required, this type of editing would be used. This capability might be used,
for example, to prevent the scheduling of more than one surgical procedure at
a time per operating room.

Default Value Editing: Moves specified default values into a data field if
nothing is entered in that field. If data is entered in the field, the default value
is ignored, and normal editing is performed.

List Check Editing: Specifies a list of valid values for a data field. If the
content of a field is not equal to one of the values in the list, the field is
invalid.

An optional feature is to have a default value substituted for the data entered if
the value of the data entered is not in the list.

Range Check Editing: Determines whether the value contained in a given data
field is between predetermined high and low boundaries established for that
particular data field.

The range edit function could specify one of three possible conditions for data
fields that have been range edited: (1) the data value is lower than the
specified range, (2) the data value is higher than the specified range, (3) the
data value is within the specified range.

3-56

Mandatory Fill: Ensures that all positions in the field are entered. Thus, for
example, entry of only four numeric digits in a five-position code field would
be invalid. A field designated as variable, such as a 25-position name field,
need not require that all the positions be filled to be considered valid.

Self Checking: Specifies that the data entered in the field is checked by a
modulus 10 or modulus 11 algorithm after the field is entered.

Adjust/Fill: Specifies that data entered in a field can be right-adjusted and
that unused positions are filled with zeros or blanks.

Duplication: Indicates that the Dup function key can be used to fill the position
of the cursor and the positions in the field to its right with the duplication
character, which is!. (hexadecimal 1C). The user program must check for these
characters and place the appropriate duplicated data in the field.

Date Editing
Date editing should validate date fields within a transaction.
Either of two types of date editing may be specified for date fields. The first
type of date edit determines, in general, whether or not a given date field is
valid: the month is between 01 and 12; the day is between 01 and 28, 01 and
29, 01 and 30, or 01 and 31 depending on the month and whether or not it is
a leap year; and the year is numeric and within a predetermined range.
The second type of date editing validates the date field as above and, if the
date is valid, determines whether the date is on or after the current system
date. This form of date editing is used when the date wanted must be either
the current date or some date in the future.

Compatibility Editing
Compatibility editing should ensure that designated data fields are compatible
with each other by cross-checking their respective contents. In other words,
the data within a given field is valid only if another field contains a specific
value or is within a specified range of values. If this is not the case, then an
error condition exists, and the first field is flagged as having failed compatibility
checking. Therefore, even if a field passed field editing, it may fail overall
editing due to incompatibility.

Design Considerations

3-57

Table Lookup Editing

Table lookup editing should provide the ability to alter the contents of a field
based on a conversion table established by the user. This is basically a
one-for-one replacement of data according to the conversion specifications
contained in the table. The table contains the values of the field to be
converted and corresponding substitution values used to replace the original
values.
When a match is found in the conversion table for a given field value, the
replacement value is placed in the edit result table, and table lookup is
considered to be successful. If the field contains a value not in the conversion
table, then the field is considered invalid and is flagged.
An optional feature of table lookup editing is to have a default value
substituted for the data entered if that entry is not in the conversion table.

Summary of Editing

Collectively, the above edit capabilities provide a powerful tool to the user of
an online system and although any or all the edits may be performed on any
given data field, the extent of editing is at the discretion of the user. Field data
editing is usually performed initially because this validates a data field before
additional editing is performed. Additional types of editing are usually not
performed if field data editing indicates a given data field is invalid.

INQUIRY PROGRAMS
Inquiry programs are the simplest of the types of interactive programs to
design and implement. They allow operators to look at information in files.
Inquiry requirements might vary from user to user: some users might need to
look at data that pertains to their department only, and other users might need
to inquire into entire master file records.
When used for inquiry, a display station is not operated continuously. Rather,
an operator typically asks a question of the system. Based on the system
response, another question might be asked. While the operator reads the
displayed information, the system can handle requests from others or can
resume processing until the operator asks another question. When an operator
finishes inquiring, the display station can be used to do other work.

FILE UPDATE PROGRAMS
Interactive file update programs update master files with transaction file data.
How and when the changes occur vary with the type of system design
implemented. An effective method of file update that provides immediate
update and efficient recovery is called memo updating. Refer to Chapter 4,
Coding Techniques, for a description of this method.

3-58

PROGRAM ATTRIBUTES
Program attributes describe a program's use of display stations or use of
resources on System/34.
Attributes that can be specified when a program is compiled are:
• SRT (Single Requestor Terminal). The program allows one requesting
display station or SSP-ICF session.
• MRT (Multiple Requestor Terminal). The program allows more than one
requesting display station or SSP-ICF sessipn.
• NEP (Never-Ending Program). This attribute can be given to SRT programs
and M RT programs. Programs do not wait for nonshared resources that the
NEP uses, and the NEP remains active when no requestors are attached to

it.
A program can also run without a requestor. This allows a display station to be
released from a job step after that step has been initiated if interaction
between the display station and the program is not required.
If none of the steps of a job communicate with display stations, the job can be
run from the input job queue.
For a description of each of these attributes, refer to Program Attributes in
Chapter 2.
Usually an application has a mixture of these attributes for its programs. For
example, the sample order entry application in Chapter 5 has an SRT program,
an MRT program, and a no-requestor-terminal program. The following
information provides considerations for choosing program attributes.
If a program is likely to be requested by more than one display station
concurrently, consider coding an MRT program. Coding a program as an MRT
program avoids resource conflicts that might occur if multiple copies of the
program were run concurrently. Also, a single copy of an MRT program usually
occupies less storage than two or more copies of the same program coded as
an SRT program.
If the program runs when main storage might be overcommitted-the programs
that are running do not fit into storage at one time-an MRT program can
reduce the swapping that would occur if multiple copies of the same program
were run concurrently. Reduced swapping should shorten response times for
the display stations.
Finally, only the first requestor of a MRT program causes the program to be
initiated. Subsequent requestors should have a shorter sign-on time because
their display stations attach to an active program and initiation is not done.

Design Considerations

3..,59

An M RT program might be more complex and use more main storage than the
same program coded as an SRT program. If a program will not be requested
by more than one operator concurrently and if the initiation time for the
program is acceptable, consider coding the program as an SRT program.
If the maximum number of requesting display stations is already attached to an
MRT program, the SSP queues a new requesting display station to the
program. While the display station waits for its request to be accepted, the
display station cannot be used unless the operator presses the Attn key and
releases the display station from the MRT procedure. To avoid this situation,
you can code the program as an SRT program or increase the maximum
number of display stations supported by the program.
If the program must do extensive input/output processing between displays
(for example, extensive array processing, multiple printed lines, or ten or more
disk accesses), shorter response times are possible when multiple copies of an
SRT program are run concurrently.
If a program is requested frequently, is active for more than a few seconds,
and uses nonshared resources such as a printer or nonshared disk files, you
might want to define the program as never-ending. (Refer to Never-Ending
Programs in Chapter 2 for a description of these programs.)
An MRT never-ending program with no active requestors will wait for a
requestor. This waiting saves program initiation time but will use system
resources such as assign/free space in order to remain active.

3-60

DISK ACTIVITY FOR LOADING PROGRAMS AND ATTACHING DISPLAY
STATIONS TO THEM
The following table shows the number of disk accesses required for loading
programs and for attaching display stations to them. Factors affecting the
number of disk accesses that are shown in this table are:

·
·
·

Program attributes
History file logging
Read-under-format processing. This technique, a method of overlapping
data entry time and program initiation time, is described later in this chapter.

·

File status: open or closed

·

Number of files used by the program

Program
Attribute

History
Logging

MRT-NEP

MRT

SRT

Disk Accesses
for Display
Station
Attachment

Read-U nder-Format

Files
Open

Disk Accesses for Program
Load

Yes

No

N/A

N/A

9

No

No

N/A

N/A

8

Yes

Yes

N/A

N/A

3

No

Yes

N/A

N/A

2

Yes

No

No

41 + (4 x number of files)

6

No

No

No

30 + (2 x number of files)

5

Yes

No

Yes

41 + (2 x number of files)

6

No

No

Yes

30

5

Yes

Yes

No

37 + (4 x number of files)

2

No

Yes

No

26 + (2 x number of files)

Yes

Yes

Yes

37 + (2 x number of files)

No

Yes

Yes

26

Yes

No

No

34 + (4 x number of files)

N/A

No

No

No

23 + (2 x number of files)

N/A

Yes

No

Yes

34 + (2 x number of files)

N/A

No

No

Yes

23

Yes

Yes

No

30 + (4 x number of files)

N/A

No

Yes

No

19 + (2 x number of files)

N/A

Yes

Yes

Yes

30 + (2 x number of files)

N/A

No

Yes

Yes

19

N/A

Design Considerations

2

3-61

Minimizing Disk Activity to Increase Throughput.on the System
There are several things you can do to minimize disk. activity and disk
processing.
• Call a procedure from within another procedure by using the procedure
name instead of a / / INCLUDE OCl statement.
• log entries to the history file. only if they are absolutely necessary. Each
record logged to the history file requires three to four disk operations.
• Send messages tcYWork station ~perators by using a / / PAUSE OCl
statement instead of a / /* statement.
• Use the IDElETE command to suppress informational me~sages that may
not be necessary for a particular work station.
• Use tests for the existence of disk, diskette, or library members only when
they are necessary. These tests require reading the disk or diskette VTOC
and require additional disk activity. You should be aware of this when
coding procedures, and should branch around these expressions in your
OCl when these existence tests are not needed.

PROGRAM SIZE
If possible, programs should be designed to run in a predetermined region size
that allows more than one program to be resident in user storage concurrently.
If a program is so large that no other program can be in user storage with it,
another program can be swapped in, but these programs cannot execute
concurrently.
A program that is larger than the predetermined region size can cause two or
more programs or segments of programs to be swapped out each time the
large program is swapped in. This swapping can affect performance because
of the additional disk activity that is required. Swapping, however, is more
efficient than using overlays for a program if the execution of one program
cycle results in many overlays. For example, in RPG the number of overlays is
not easily controlled by a programmer. In COBOL, Basic Assembler,
FORTRAN, BASIC, and WSU, the programmer can control the overlays and
therefore might improve performance by using overlays instead of swapping.
In addition, BASIC has a status feature inthe HELP support that allows the
programmer to see how many overlays are occurring for a particular region size
and work area partition.
When you predetermine a region size and, try to code your programs to fit that
region, you might have to adjust the size of the program after. you have coded
it. If the program is too large, specifying the predetermined region size to
execute causes overlays to be built to fit the program into the region.

3-62

Each program need not be the same size in order to execute in the same
region. If the region size specified for a program is not a multiple of 2 K bytes,
the number is rounded up to the next even 2 K byte increment. For example, if
you have a 32 K byte user memory, you might design each program so that it
executes in a 16 K byte region. Because of the rounding up that was
previously described, programs between 14 K bytes and 16 K bytes will require
this region for their execution.
Program size can vary with the number of functions and the types of functions
used and is therefore difficult to estimate before a program is coded. For
example, the following items can affect program size:
• Number of files used."
• File types used. For example, input-only disk files require less storage than
update-capable disk files.
• Processing method used. For example, input-only processing of disk files
require less storage than update or add capable processing.
• Storage index for indexed files.
• Amount of input processing specified. For example, the number of I
specifications in an RPG program can affect program size.
• Record lengths, which can affect the size of input/ output areas that are
reserved for files.
• Number of .output specifications.
• Number and type of calculations. For example, a LOKUP operation in an
RPG program done by a subroutine. If you use this operation and a manual
search in an RPG program, you might want to use one method instead of
two in order to reduce the storage required.
• Number and sizes of constants, data structures, fields, tables, and arrays
defined.
• The number of formats on an H specification in an RPG II program. If a
number is not specified, 32 is assumed. The number of formats must be at
least the number of formats in the load member, even if not all of the
formats are used in the program. For each format, an additional 16 bytes is
required in your program. For example, if your program uses five formats
and you specified five formats on the H specification, 80 bytes (5 x 16) are
used for formats. If, for the same program, you used the default of 32
formats on the H specification, 512 bytes would be required. Thus, your
program would be 432 bytes larger than necessary.
Program size can be adjusted by dividing a program into several job steps and
using a technique such as the read-under-format technique to show displays.

Design Considerations

3-63

READ-UNDER-FORMAT (RUF)
Using a read-under-format technique allows an operator to enter information
onto a display while the program that uses the display is initiating. When
read-under-format is used, a program or a procedure displays the format, and
the program called next in the procedure reads it. The format is displayed by a
program or a PROMPT OCl statement with PDATA-YES specified. If an SRT
program displays the format, it then goes to end of job. An MRT program
displaying the format releases the display station. While the program is being
initiated, the operator enters information for the display. When the operator
presses the Enter key, the input from the display is sent to the second
program.
This technique can be used with all types of programs, including never-ending
programs. Read-under-format processing decreases program size because
each program might handle a few formats. This technique might increase
processing time because of the extra time the system spends initiating a
program.
The following example shows a read-under-format technique that uses two
displays and two programs. The PROMPT OCl statement is used to show
Display 1. While the operator enters information on that display, Program 1 is
being loaded. When the operator enters Display 1, his input is sent to Program
1. Before Program 1 ends, it shows Display 2. The operator can enter
information on this display while Program 2 is being loaded. When the
operator enters Display 2, his input is sent to Program 2.

3-64

oeL
7'/-~1I~1"'.1" r

IDt Sill I~ " 11

•

III

Program 1 {
Load Time

~I

111

~Il

VI

·
·
LIOIAt

n

... ~I LE . . .
51h! IT CH ...
fI lE

RiUlN

Display and Program Flow

III"''''

rAil

1

···

The operator keys data and then enters the display.

Program 1 Ends
Program 1
Execution

Program 2 {
Load Time

I
II

..

Program 1 shows Display 2
and then ends

t

~IE SE T r If IU"I r CAlli
blAn Plr loa r~U' 2

I ",II lE
/ FI LE

I RlulN

...
...

The operator keys data and then enters the display.

Program 2
Execution

The sample application described in Chapter 5 also uses a read-under-format
technique.

Design Considerations

3-65

DISPLAY STATION LOCAL DATA AREA
A 256-byte local data area exists on disk for each command display station on
the System /34. This area may be used to pass information between programs
and procedures. This area is initialized to blanks at the start of a session. RPG
1\, WSU, SOA, SMF and 3270 emulation use part of the display station local
data area to control their execution. Therefore, any user data in those bytes is
destroyed when one of these programs is run. The use of the local data area
by these programs is as follows:
Program

Bytes Used

ICFVERIFY
SOA
RPG 1\
SMF
3270 Emulation
WSU
HELP

1 through 4
1 through 104
201 through 256
220 through 256
230 through 256
238 through 256
249 through 256

The LOCAL OCL statement may be used to put data from a procedure into the
local data area. The ?L'offset,length'? substitution expression may be used to
test or extract data from the local data area in a procedure. Both COBOL and
RPG \I have subroutines available to read and update the local data area for
any attached display station. In BASIC, the local data area can be opened with
the OPEN statement and is then available to read and update.
The local data area becomes resident in main storage the first time a LOCAL
OCL statement or LOCAL substitution expression is encountered within a job
step. Each subsequent LOCAL OCl statement processed in a job step updates
the main storage resident local data area and the data area that resides on
disk. Each subsequent lOCAL substitution expression· in the job step accesses
only the local data area in storage. The local data area is resident in storage
for a particular job step only until a / / RUN OCl statement is encountered and
processed. The local data area can be reestablished for the next job step if
necessary.
The local data area, when resident in main storage, uses the assign/free area
of the nucleus.

3-66

The following OCl statements in a procedure called PROCA would prompt the
operator to enter a starting invoice number. It would store this number in the
first six bytes of the local data area. PROC5 would execute using and updating
the first six bytes of the local data area, which contain the invoice number.
When control returns to PROCA, the updated invoice number would be
displayed to the operator and the procedure would pause until a 0 response is
entered.

lL
I

~ 'I:Nlr t:t<

1l(1l

I P

I\..

AL "

UI~!E

I

IN ~nlIe E NIUM~ ER 16
1. DA !fA -' irl R?'

ST AR IT[ NG

"' ...

'I -

IJ[J

I.,IT rIS'

EN IJ[~G IN vo Ie E WA~ ?L '1 .6 ' ? •
-t-~

Note: If a / / * statement, rather than the PAUSE statement, is used to display
the operator message, processing of the procedure continues and the message
might appear on the screen only momentarily. For that reason, if a / / *
statement is used, you might want to follow it with a PAUSE statement.

EXTERNAL INDICATORS
System/34 has a set of eight external, ,indicators (switches) available for each
display station. These switches are available to the COBOL programmer as
switches UPSI-O through UPSI-7 and to the RPG II and WSU user as
indicators U1 through US.
Subroutines are provided for retrieving and updating the external switches of
any attached, command-capable display station in an RPG MRT program or in
an SRT or MRT program coded with the subset ANS COBOL PRPQ
(X3.23-196S). Retrieving and ,updating these switches is automatically done for
RPG SRT programs; WSU programs, and programs coded with the ANS
COBOL Program Product (X3.23-1974). The switches are available to BASIC
programs through the U PSI$ intrinsic function.
System/34 OCLaiso has the ability to test and set these switches. Thus, the
execution flow of various OCl statements in a procedure can be controlled by
the settings of various switches.
If UPSI-YES is specified on the / / PROMPT statement, the current setting of
the eight UPSI switches are made available to the screen format as indicators
91 through 9S. A return code that indicates which command or function key
was used can be accessed by a ?CD? substitution parameter. For more
information on using the ?CD? substitution parameter with indicators, refer to
Using the Prompt DeL Statement in Chapter 4.

Design Considerations

3.,.67

The following example uses the SWITCH OCL statement to set switch 1 to an
off status and switch 2 to an on status; switches 3-8 are unchanged. PROC1
is called and executed. If switch 1 is on when control is returned from PROC1,
then. PROC2 is called; if switch 1 is off, the ELSE statement causes PROC3 to
be executed. The last SWITCH statement sets all eight switches to an off
status. The switches are also set to an off status when a display station
session is initiated.

/ sf'" Iii" CH

~.

1"lvIv

--

V"

... 11e1U 11

I

I

!F iSlll "T ef.! 11-11
LS E 1'1(
I\,j

p~

oe2

~

I SIItJ Iil II' ~ ICIOO

Note: A separate copy of the switch settings is kept for each requestor of an
MRT program. When a requestor gains control of the program, the switches
are automatically set to the values stored for that requestor.

3-68

Data Processing Security and Accuracy
Data processing security involves protecting both data and the equipment
needed to process the data. The major emphasis of data processing security is
to prevent the unauthorized release, modification, or destruction of your
information or data processing equipment. Data processing security is
especially important because the System/34 allows many activities to occur at
the same time, often away from as well as at the central computer site. There
are two important areas that make up data processing security: physical
security and data security.

PHYSICAL SECURITY
Place your computer in a safe location. There are several factors to consider.

Physical Location
You should not place your computer below ground level, as in the basement.
Backed-up sewer lines, broken water mains, and floods can occur.
Place the computer away from outside walls or windows. If you must place
the computer along an outside wall or window make sure the wall or window
is strong enough to protect your computer from damaging winds, hail, or other
conditions accompanying severe weather.

Limited Access to the Computer
Only people who need to use the computer to do their work should be allowed
to use the computer. If you have the computer in a special room, you may
want to limit access to the computer room through the use of special locks or
special doors.

Fire Protection
Place your computer in a building that is as fireproof as possible. Good
housekeeping is vital to maintain a fireproof environment.
Other things you can consider:
• Place some fire extinguishers near the computer and make sure the
appropriate people are trained in their use.
• Keep a smoke detector near or in the computer room.
• Install appropriate sprinklers to put out a fire.
Because sprinklers can use water that can damage your computer, make
sure your sprinklers use chemicals that will not damage the System/34.

Design Considerations

3-69

DATA SECURITY

Limited Data Access
Limiting access to your data protects it from being read or disclosed to people
who are not authorized to use it. The System/34 provides some security
features to help you safeguard your data. These features include:
• Password security
• Badge security
• File and library security
• Menu security
For more information about System/34 security features, refer to
System-Provided Security in Chapter 2.

Data Accuracy

You can better safeguard the accuracy of your data if you use certain data
controls to help you make sure your data is as accurate, reliable, and complete
as possible. There are three basic types of data controls:
• Input controls
• Processing controls
• Output controls

Input Controls

The following steps will help to ensure that your input data is correct.

Input Verification: Check fields on the input record to see if these fields are
correct. Some businesses have personnel check all input documents and
records before entering them into the computer.

It is necessary to make sure not only that input records are processed correctly
but that all input documents cannot be lost and the loss go undetected. You
should have some way of recording what input was entered into the computer.

3-70

Processing Controls
Processing controls are those routines that are written into a program to ensure
the program is processing data correctly.
Some common processing controls are:
• Record counts: This control counts how many input records were
processed; it can determine if any records were lost during processing.
• Sequence checking: This control checks whether records have been sorted
properly.
• Audit trails: An audit trail records what work was done on the computer
and the order in which the work was done. An audit trail should indicate
that the computer is doing the work correctly. Additionally, the audit trail
should provide information to identify any errors and their causes.

Output Controls
These controls report the results of the processing done by the computer.
These controls when combined with input controls can be especially effective
in checking such items as output totals compared to input totals. Some,
effective output controls are:

Output counts: Count of records either processed or written as output.

Program messages: Messages issued by the program when data errors occur
(for example, a message issued to the console operator when a four-digit
control number is blank and the control number is used as a key).

BACKUP AND RECOVERY CONSIDERATIONS
Because data (programs and files) can be damaged or destroyed by incorrect
modification, a system failure, operator errors, or a natural disaster such as a
fire, keeping backup copies of vital information is recommended. Backup
procedures typically involve copying the vital information kept on the system
and then storing the copy in a safe location. For example, data can be copied
to diskettes, dated, labeled, and stored in a fireproof safe. Because a disaster
such as a fire could destroy the onsite backup copy, a good practice is to store
another set of backup diskettes offsite.
Loss of data could be disastrous to most businesses using data processing.
Thus, a standard, well-documented, backup procedure should be established
and used regularly. Typically, master files and all files related to the master
files are saved at the same time. For example, if a customer master file
contains an accounts receivable sum for each customer, this file and the
accounts receivable open item file are saved and restored together.

Design Considerations

3-71

New data such as batches of transaction records can be copied to disk or
diskette after they have been entered and edited. These saved transactions can
be used during recovery procedures to make the master files current.
Recovery is a series of steps that an operator follows or procedures that an
operator runs to restore data on the system. Following recovery, programs and
files are returned to the status that they had just before the error, failure, or
disaster occurred.
Recovery procedures can require removing all or some master files, restoring
backed up master files, and reexecuting those procedures that updated files to
repost transactions in the order that they were originally processed.
Programs and procedures can be designed to restore and recover all files,
inform the operators about the last items correctly processed, and allow
operations to continue from that point. This effort might involve using
additional fields in records and using additional calculations in programs. Also,
new files, programs, and procedures might be needed, particularly for recovery
in a work station environment. The planning and programming effort might not
seem costly in light of the potential results of inadequate backup and recovery
procedures. Typically, businesses that are most dependent on their data
processing system require the shortest recovery times and thus should develop
the most elaborate backup and recovery procedures. Regardless of their
complexity, backup and recovery procedures should be well-documented so
that all operators use them correctly.
The following information describes three methods of backup and recovery.
The first method requires the least design and programming effort, but
probably requires the longest recovery time because transaction batches are
not saved. The second method requires more planning and programming, but
reduces the amount of recovery time required because reentering the
transactions is not necessary. The third method requires the most planning and
programming but provides the quickest way to recover data because the
operator's involvement is minimized.

Method 1
This method requires the operator to periodically save master files and files
that the application updates in order to establish a point from which to recover
(restart) the application. For example, at the end of each day after all
transactions have been posted, the operator might execute a procedure that
contains SAVE commands to back up all master files and their related files on
diskette.
Operators should keep a log of the work they do on the system. This manually
kept log must be accurate if it is to be relied upon during recovery. One
method of keeping a log is to use the following sample run sheet.

3-72

RUN SHEET
Date _ _ _ _ _ Page _ _ _ __

Work Station ID _ _ _ _ _ __

Menu, Item, Command, or
Procedure Name

Operator's
Initials

Start
Time

Stop
Time

OK

Comments, Halts,
Messages

.,-

Design Considerations

3-73

Another method of obtaining a log of work done on the system is to print the
history file.
This recovery method consists of the operator (1) deleting files from disk, (2)
restoring the backup copies from diskettes to establish a point from which to
recover, and (3) reprocessing all transactions that have been entered since the
last backup was done.
All of the work done since the last backup must be redone. Because they are
not saved, transaction batches must be reentered. This method might be
adequate for a business that processes low volumes of data and that
frequently backs up its data.

Method 2
This method requires the operator to (1) periodically save the master files and
their related files and (2) save batches of transactions at logical breakpoints in
the application. For example, at the end of each day after all transactions have
been posted, the operator executes a procedure that contains SAVE commands
to back up master files and their related files on diskettes. As part of the
transaction-posting procedure run during normal processing, a batch of
transactions is saved on diskette and deleted from disk. The operator labels
the diskettes that contain the transactions so that he knows the sequence in
which the batches have been saved. Also, the operator lists the names of the
procedures in the order that he runs them.
The recovery method requires the operator to (1) delete the files from disk, (2)
restore the backup copies from diskettes to establish a point from which to
recover, and (3) reprocess the application's procedures in their original order
using the saved copies of the transaction batches. The operator uses the
information he has labeled on the diskettes to ensure that the transaction
batches are restored in the correct order.
This method eliminates the rekeying of transactions that was required in the
previous method.

3-74

Method 3
This method requires code to be included in an application's procedures to do
the following things:
• Periodically back up the master files and their related files.
• Automatically back up batches of transactions on disk or diskettes at logical
breakpoints in the application.
• Assign names and sequence numbers to these batches of transactions.
• Keep a history of all procedures executed by the operator following the last
backup. This history is kept in a control file.
• Provide a common recovery procedure.
The recovery method consists of the operator running the common recovery
procedure, which lists the control file and restores the files. The operator uses
the listing of the control file to rerun the application's procedures in their
original order. The common recovery procedure could prompt the operator to
insert the proper backup diskettes in the correct sequence.
This recovery method uses a program-generated control log, which is more
accurate than a manually-kept log. Because unnecessary procedures such as
reprinting statements or reports could be skipped during recovery, this method
provides the quickest recovery of the three methods. This method is similar to
the backup and recovery procedures used in some IBM Licensed Application
Programs.
The following example shows one method of restoring a particular file from a
diskette in a magazine.
Procedure
Command

Action

CATALOG

Determine the file that you want to restore.

2

RESTORE

Restore file to disk from diskette files kept
as backup.

3

CATALOG(optional)

Verify that the file has been restored.

Step

Design Considerations

3-75

Procedure Command Examples

1.

Print a list of all files on each diskette in a magazine.
CATALOG All, 11, M 1.01, NOAUTO

2.

Restore a file named ORDITEM located on diskette 07 in magazine drive
01.
RESTORE ORDITEM""M1.07

History File
The history file is an area that is located in the system area on disk
(#SYSHIST) and occupies a minimum of 120 sectors and a maximum of 9960
sectors. The size of the history file is specified during the configuration
process. The history file is an important tool you can use to review events that
have occurred on your system. Recorded in the history file are:
• All OCl statements, utility control statements, control commands, and
procedures executed by the SSP.
• All messages displayed at the display station.
• All operator responses to messages and prompts.
• Work stations being used.
• Operator's user ID.
• Job name in the form WWHHMMSS; WW is the work station ID and
HHMMSS is the time the job began running. Occasionally, there will be all
asterisks (*) in either the operator user I D or the job name. This indicates
that the entry recorded was generated by the system. Double quotes (")
indicate that the line is continued from the previous entry.
• The time the entry was recorded in the history file.

3-76

In addition, there are entries in the history file designated as *E entries. There
are two types of *E entries: *EJ, which indicates the end-of-job recording,
and *EP which indicates the end of a spool print job. The following information
items are shown by the *E entries:
• Starting and ending time of the job
Date the job was run
• Amount of elapsed time it took to run the job
Operator's user I D
• Work station or printer I D
Name of the procedure that began the job or created the print job
• Whether the job was an MRT program
• Two-character completion code for the *EP entries
NC: Normal completion
CP: The print job was canceled by either the console or subconsole
operator
SP: The print job has been stopped by either the console or subconsole
operator
Th~ following
H1CTORY FILE DISPLAY
STATEMENT

three printouts are samples of a listing of the history file entries.

WORKSTATION - Xl

USER - RON

DATE

07/24/80

TIME

14.0i
WKSTN

HISTORY SYSTEM

RENAME TEMP1.WFR7V066
RENAME PROCEDURE EXECUTING
HELP SAVE
SAVE WFR7V066.999 •• WSUWSU ••••••
SAVE PROCEDURE EXECUTING
SEU SAVEFILE.P ••• WSUFT
SEU PROCEDURE EXECUTING
II LOAD $SFGR
II RUN
II LOADMBR NAME-TOM
II INOUT INlIB-JMGLIB,OUTLIB-JMGLIB
II UPDATE SOURCE-TOM
SAVEFILE 066.CUSMF001.ITEMF002 •• TRANF018.58.25
DISPLAY PROCEDURE EXECUTING
I I END
SYS-1598 OPTIONS ( 23) COCI
TRANF018--THIS FILE IS NOT ON DISK
SYS-5019 OPTIONS (
3) SFDE
TERMINAL ERRORS IN $SFGR INPUT SPECIFICATIONS

W2

SUBCONSOLE

-

PAGE-

USER

..JOB NAME

TIME

RON

W2143606

14.36.07
14.36.08
14.36.17
14.36.30
14.36.32
1.4.37.01
14.37.02
14.38.01
14.38.05
14.38.14
14.38.27
14.38.49
14.38.50
14.38.52
14.38.56
14.38.59
14.39.00
14.39.01
14.39.01
14.39.05
14.39.1.9

W2143617
W2143700
Xi

3
3

SDA
SEU SAVEFILE.P ••• WSUFT
SEU PROCE~JRE EXECUTING
SEU-0549 OPTIONS ( 2) SEEJ
NOT ENOUGH ROOM IN l.IBRARY TO HEPLACE MEMBER

JMG

X1143800

W2

RON

W2143850

Xi
W2

JMG
RON

X1i43800
W2143850

Xi

JMG

X1i43800

W2
Xi
W2

RON
JMG
RON

W21438S0
X1i43926
W2143'732

2

CONDENSE WSUFT
CONDENSE PROCEDURE EXECUTING
SYS-2582 OPTIONS ( 123) MARC
WSUFT
--THIS LIBRARY NOT COMPHESSED. BEING USED .•.

W2144046

3

OFF
OFF
SEU PROCEDURE EXECUTING

1~2

Xl
W3
Wi
W3

LI>I<:

II LIBRARY NAME-WSUFT
CONDENSE WSUFT
CONDENSE PROCEDURE EXECUTING
II LIBRARY NAME-ILIBRARY
CJR
CMENU WSUFT
OFF
SEU SAVEFILE.P ••• WSUFT
SEU PROCEDURE EXECUTING
SEU-0545 OPTIONS (01 3) SE
WORK FILE ALREADY EXISTS--IS THIS A RECOVERY

o

WSU WSUFT079.WSUFT •• REPLACE
WSU PROCEDURE EXECUTING
RON
COST WSUFl
RON
wsurT

loll

W2
W3
W2
RUN~

******** ********
*****.*** ********
X1i43926

..JMG
LDK
RON
LDK

********

RON
CJR

W114'1140

C.JR

W2144~?00

Wii44i31.
W3144138

********
*1('****** ********

•..
W2144551
W3
W4

HDN

14.~39.27

14.39.32
14.39.34
14.40.36
i4.40.36
14.40.41
14.40.46
14.40.47
14.40.49
14.40.49
14.40.52
14.41. 02
14.41. 16
14.41.24
14.41.28
14.41.31
14.41.38
14.41.39
14.41.41
14.41.55
14.41.59
14.42.01
i.4.42.02
14.42.07
14.42.07
14.42.13
14.45.51
14.45.53
14.46.14
14.46.35

*11*'''''***
******.,,* ********
Design Considerations

3-77

WORKSTATION - Xl

HISTORY FILE DISPLAY
HISTORY NOLIST,RESET", ,X2
II LIBRARY NAME-O
II MEMBER USER1-IIMSG2
II * 2076
HISTORY PROCEDURE EXECUTING
II LO,'D $HIST
II fWN
II DISPLAY NOLIST,RESET" I
I I WDRKS'TN'''X2,
II SYSTEM-NO
II GDTO END
II END
*EJ 07.28.07 07.29.13 00.01.06

*

WI,RON

14. OS

SUBCONSOLE - PAGE-

07/24/80

RON

Xl

PUBSHISR

NO OPERATOR COVERAGE FROM 11:30 TO 13:30!!
COST PUBSLIB

Xi

HISTORY FILE DISPLAY

WORKSTATION - X2

STATEMENT

1 ENTRIES DISPLAYED

00.00.49

09/0B/BO

DRF

Syst~m

display

0

USEf<

DRF

HISTORY ALL, •• EONLY
il.36.38

Operator entry

HISTORY *EJ entry

HELP HISTORY
II LOAD $HEl.P
1/ HUN
II * 'HISTORY SYSTEM,VIEWED,NORESET,TOTAL.CONTHOLS,,;,.
HISTOf(y SYSTEM, VIEWED, NOPE SET , TOTAL, CONTROI.S, , • , ,
HISTORY SYSTEM.VIEWED,NOPESET,TOTAL,CONTRDLS,, '"
II LIBRARY NAME-O
1/ MEMBER USEHI-~IMSG2
II * 2076
@@206
HISTORY PROCEDURE EXECUTING
II LOAD $HIST
II RUN
II GOTD SYSDVFl.
II DISPLAY VIEWED,NDRESET,TOTAL,CDNTRm_s,
I I
SYS'I' EM-YES
II FND
SYS-8423 SRT CANCELED BY INQUIRY OPTION 3 AT Xl

3-78

TIME

@@206

II END
SYS-8423 SRT CANC8_ED BY INQUIRY OPTION 3 AT Xl
*E,J
j3.5'7.23
13.59.09
OO.OL46 07/24/BO RON

11.35.49

07/24/90

HISTORY ALL, ,CURRENT.TEXTONLY

RON
HELP HISTORY
II l.DAD $HELP
II FWN
II * 'HISTORY SYSTEM,VIEWED,NORESET,TDTAL,CDNTROLS".,,'
HISTORY SYSTEM, VIEWED, NORESET, TOTAL, CONTrWLS, , , , ,
HISTORY SYSTEM,VIEWED,NORESET,TOTAl..CONTRrn_s,, '"~
1/ LIBRAPY NM'if.::-·O
] Generated
II MEMBER USER1-IIMSG2
// *. :~07b
OCL
r~'R~206
HISnmy PFWCEDURE EXECUTING
II LUAD iHIST
]
;~ Rg~~Tn SYSOVFL
Generated
~~ D~~~:~~~.~:iWEIJ, NOI

~

85

'AUTO

~~
U1

Position

in
Output
Record

w

a:

Commas

Zero Balances
to Print

No Sign

Yes
Yes
No
No

Yes
No
Yes
No

I
2
3
4

CR

-

A
B
C

J

0

M

K
L

X = Remove
Plus Sign
Y= Date
Field Edit
Z = Zero
Suppress

5·9 =
User
Defined

:::;

~

Constant or Edit Word

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 2021 22 23 24
AND
9 10 11 12 13 14 15 16 11 18 19 20 21 22 23 24 2526 21 26 29 30 31 32 33 34 35 36 31 3839 40 41 42 43 44464604646~~~~645656U5668~~~63646666~6868ro 71 72 73 74

0 2

ol~ lAS TIEIR
0

0 3

0

o

10

4-2

0

- or:
w " Space

~

4

z

p

C»

ILl!

8.

0 1

~il

c •

-!.

1~

0
f---

4

~_~

9 10 11 12 13 14 15 16 11 18 19 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 46 49 Su 51 52 53 54 55 56 51 58 59 60 61 62 63 64 6566 67 68 69 70 71 72 73 74

o

3

5

~ ~-~---.r-r+""""'! i ~
Data
~ ~ f- § 's. ~

o

Line

Field Location
Record Identification Codes

1 z": ~_ --.=~g>_ . ~o~.
:::.

S~~~~re

3

External Field Name

~
'g

~

Filename
or

~

1~11

IMISIAL

I;~

Later (for example, at the end of the day), the transaction file is processed by a
batch edit program. The transactions are posted to the balance fields in the
master file by a batch update program, as the following segment of the
program shows:

-

I
&

Line

4

6

8

o
o

2

I

3

I

o

4

o

5

o
o
o

6

-

7 8

Line

~!~

4

~~

2

~~

5

0 1

8

C
C

o

3

C

AL

7

8

..,

ZO

s:;

U

0

~
~

~ ;Z a:
Wj ~

!U

Oata Structure

.~ ~

Occurs
n Times

v,

~

RPG
Field Name

l

]

-

.j

g

8

0

Length

:s
0

:§ -l3

u: ~

Field
Indicators

~
'E

~ c;n ~
~.~ '0
~;S u:0;

Zero
Plus Minus or

Blank

co NIT IRL M1

110

11

1~ IQl~ MT

i
311

.1C ICO NT RIL

~1

ur IDl JlIAI

Resulting
Indicators
Arithmetic
!!
g Plus IMinusl Zero
Compare
IS :;:
Length
1>211<211 2
Lookup(Factor 2)is
~~ High Low Equal

Result Field

Jd

Factor 1

:E

Factor 2

Operation

~IN.l

f2a

Comments

i!

29 30 31 32 33 34 35 38 37 38 39 40 41 42 43 44 45 45 47 45 495061 52 sa 54 55 56 57 58 59 60 61 62 63 64 65 68 67 68 69 70 71 72 73 74

~ICD

e,AIL

IEiJl L

~

Filename
or
Record Name

~

~

~l Space
J!
i~
~R

Output Indicators

Skip

e.iii
:t
~

~~ ]
~ ';'L
~ o 0 c!

,1

!

5 6

7

8

9

0

4

10

5

0

Jd

~
a:

End
Position
in
Output
Record

1)

1)

1)

Z

Z

"AUTO

Commas

Zero Balances
to Print

Yes
Yes
No
No

Yes
No
Yes
No

a:

~

ii:
~~
~~~
10 11 12 13 1415 16 17 181920 21 22 2324 2528 2728 29 30 31 32 33 34 35 38 37 3839 4041 4243

olM l'lS Te~
10

3

:Field Name
or
EXCPT Name

~!i)

Z

2

~

0 ~

~

102

INS

O;Z MIl<

&

o
o
o
o

Z

Position

Q1

IN$

1)
0
Z
Z
9 1011 1213 14 15 1617 18 19 20 21 22 23 24 26 28 27

~

0 1

e=

~

TO

15

5

~

From

t:

Name

0

4

_

Position

Z

~ A;' i

2

3

;

i
0 0-.6
v

Position

3

~ea:

o

Line

1

Indicators

~

3

c: •

1

C

~

9 10 11 12 13 14 15 18 17 18 19 20 21 22 23 24 25 28 27 ~ 29 30 31 32 33 34 35 38 37 38 39 40 41 42 43 44 45 45 47 45 49 5u 61 52 53 54 56 56 57 58 59 80 61 62 53 64 65 68 67 68 69 70 71 72 73 74

I~ ~S TER

7

€if:!~

~~~
~ 'i ¥
AND Z C5" a:

I
I
I
I

8

w",

.! i :g

Irl~IAiNIS

01

~ ;i
"

:: S -!.
Oat
S'
~~c;:.~re

3

Field Location
Record Identification Codes

I

~
~

External Field Name

ic:~

i

Filename
or
Record Name

No Sign
1

2
3
4

CR

-

A
B
C
0

J
K

L
M

X = Remove
Plus Sign
Y = Date
Field Edit
Z = Zero
Suppress

5-9=
User
Defined

Constant or Edit Word

CD

1

2

3

4

5

6

7

8

9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

44~45~~~~~~~~~56~58~~~~5364~~~~OOro

rD

O~

71 72 73 74

''--

M~

'BAlL
SAIL

1'40 I

r;o 1

Note that these
balances are set
equal to one
another.

I I I I I II I

Coding Techniques

4-3

Backup of the transaction files is required each day (or for each batch); backup
of the master files is required periodically. Recovery can be done by reloading
the master files and processing all subsequent transactions. The current
transaction file should be intact after the system I PL File Rebuild· function is
run. After IPL File Rebuild runs, the master file does not reflect the current
transactions. To bring the memo balance field to its current value, run a
program that updates the memo balance field with the transactions. Then,
after the memo balance field has been updated, all current activity has been
accounted for, and normal operations can continue.
A variation of the memo updating technique could be to set the memo balance
field to zero at the start of the day rather than to. the value of the balance field.
As for the previous method, interactive updates would be made only to the
memo balance field.
The memo balance field would reflect the day's activity for that item. If no
transactions for the item occurred, the memo balance would remain zero. In
order to determine the current balance, an inquiry program would have to add
or subtract the memo balance from the balance in the master file.

4-4

PROGRAM COMMUNICATION WITH THE LOCAL DATA AREA
Programs can communicate with the local data area (LOA) via data structures.
For a discussion of data structures, see the Systemj34 RPG II Reference
Manual. A U data structure (U in column 18) defines the LOA to the program.
This data structure (UOS) can be subdivided. For example:

IBM

RPG INPUT SPECIFICATIONS

1"1erMII0I\I1 8uslI\ess MKhlnes COfporatlon

I Keying
I Instruction

Ptogr.m

I Date

Programmer

Filename
or
Record Name

&

3
4

0 5

o

6

0 1
n

A

1

Card Electro Number

1

pageDJOI

0.,1
Nlme
7

IJ.1E
III
I
I
I
I
I

8

Record Identification Codes

~

";en

wen

=-5

SlructulO

2

~

E

3 4 5 6

o
o
o

I I

~~~~;~~ation I

~j

~~~ ~8

cO

1

3

From

il

;E.
~

2

Position

~

~

0

~

~§~

Position

~e~
o~~

z u u

Ii;

Position

Jl

cr

~Ig
~~ Dci)ii:
~u

To

nTimes

0

~

Data Structure

Occurs

c:

~
RPG
Field Name

~

Lenglh

..J

]

5
:§i9

j

.! 'ii
u..u:

e

-fi :~

!

~

III III

Field
Indicators

Field Location

H

1 ~~ t~

~

of
0 1

I I

I I

Key

GX21·9094·4 UM/050·
Printed in U.s.A.
75 76 77 78 79 80

2

External Field Name

I

I--

Line

I I

Graphic

1

.~ ~

jcS

Zero
Plus Minus or
Blank

9 1011 12 13 14 1516 17 18 1920 21 22 23 24 2526 27 18 29 30 31 3233 34 35 36 37 38 3940 41 42 43 44 45 46 47 48 49 5v 51 52 53 54 55 56 57 58 5960 61 62 6364 65 66 6768 6970 71 72 73 74

USIE

1"'1. IIr"IK

OF

I'~IE

LDIA
lUDIC;

1

~

Ij

f11~

25 AR EA
~O EG CK
120

1212

~D ATE

orr PAri

T

Note: Although a filename (OSWRK) is specified in the example, this entry is
optional for data structures used as a display station local data area.

The fields can represent whatever the programmer defines and can be used as
factor 1, factor 2, or results in calculations, or the fields may be used as input
or output fields with input/ output operations.
For SRT programs, a routine is provided to load the LOA into the data
structure before the first RPG II cycle and to copy it back to the LOA following
the last RPG II cycle. This routine is generated if the programmer specifies a U
in position 18 of the OS input control record.
A data structure can also be used with an MRT program. However, the only
LOA loaded into the data structure is that of the first program requestor.
When the program ends, no LOA is updated.
When an inquiry is requested or when a job is placed on the input job queue, a
copy of the submitting display station's lOA and user switches is saved. The
lOA copy is updated when the program ends so that the lOA can be tested
by subsequent programs and Oel in the same job. At end of job, this lOA
copy is not saved.
A subroutine, which is mainly for MRT programs, can be used to access the
lOA of any display station that is attached to the MRT program. This
subroutine, SUBR21, allows the programmer to read or write an lOA, which is
identified by the display station 10. SUBR21 requires the two-character display
station 10 and an indication whether to read or write all 256 bytes of the
specified lOA.

Coding Techniques

4-5

The following RPG calculation lines are used for executing SUBR21 from an
RPG program:

Indicaton

C

~

I

Lin.

3

•

ii

~

0 2

C

0 3

C

•

Name

~j

•

e

0 1

j

XI

IC,'I

1M'"

c

I

I

I

I

o

8

c

0 7

C

'--

..

-.

..

-

~J

Plu'JM.nu,IZe,o
Compa,.
1>211<2\1 -2
Lookup(FlClo,21 ••
HiWo Low f'luII
"'55 5551

71 ..

If

l ~ L
L L

_.

::1

~j

j

C

I

Length

~i

9 10 11 12 13 I. 15 18 17 I. 19 20 21 22 23 24 25 211 21 211 29 30 31 32 33 34 35 38 31 38 19 40 41 42 4 3 44 45 48 41 48 49 50 51 52

0 5

0

~ !

Fletor 2

Operation

III

~

tndfClton
Arithmetic

!

Fletor 1

c·

~

5

1

AL

i

Resulting

RelUlt Field

,

f5f) 61 6:1 63

~

- -

..

.

..

_

-

--

One-character field that indicates the operation code. The RPG
program places this code in the field.
I = input: read from the LOA
write to the LOA

TNAME

Two-character field that contains the display station 10. If
TNAM E is the same label used with the 10 field of the work
station file, then SUBR21 is addressing the LOA for the work
station currently being processed.

RCODE

One-character field that contains the return code.

o = successful
1 = unsuccessful (display station was not attached to program)
2 = unsuccessful (display station was not a requestor)

4-6

n

13 14

--

-

r--- . -

'"

o = output:

AREA

6ft 61 68 e9 10 "

~EIA

The meanings of the OP, TNAME, RCODE, and AREA fields are as follows:
OP

6~

--

NJo1 11'1 't:
,.,..
o'E

.-

'-"

...

~8 ~9

Comments

Field, up to 256 characters, that is used with SUBR21 to transfer
the LOA. This field cannot be a data structure.

USING THE PROMPT oel STATEMENT
The PROMPT OCl statement can be used to show a display directly from OCl
without loading a program. The input returned from this display can be input
to a subsequent display in the program or can be input to the procedure in
which the PROMPT OCl statement occurred.
The format of the PROMPT OCl statement is as follows:

II PROMPT MEMBER-screen format load member name,FORMAT-display screen format name

The PROMPT statement provides a return code to indicate which command or
function key was pressed. This code can be checked by using the lCD?
substitution expression. The following chart shows the code returned for each
key pressed:

Key

Return Code

Enter / Rec Adv
Command key 01-24
Roll Up
Roll Down
Help
Record Backspace

0000
2001-2024
2090
2091
2092
2093

Coding Techniques

4-7

This example shows the use of the PROMPT Oel statement and the return
codes to set switches allowing the selective listing of library members when a
particular command key is pressed by the operator. The use of the return
codes to set switches, which indicate which library members are to be listed, is
necessitated by the fact the SSP resets the return code to 0000 whenever it
executes a RUN Oel statement.

LIBRARY DIRECTORY LISTING
CURRENT SESSION LIBRARY
PROCEDURE MEMBERS ONLY
SOURCE MEMBERS ONLY
OBJECT MEMBERS ONLY
SUBROUTINE MEMBERS ONLY
SYSTEM DIRECTORY ONLY
foll... 1... DIRECTDRIES
CI~INCEI...

I:~E(~I...IEST

DRFLIB
CONi'·l(.:lND

t{EY 1.

COrlrli~-lND

A-••

KEY ...

)

CDi'1MAND !',[Y ~:~
COMMf.-lND KEY 4
COfv1j':lf~IND I-':':[Y .)
CDt1i"·j(.:iND KEY b
I""

CDf'li"lf~N1)

KEY

"'I

I

//
//
//
//

00000000
7:i. F I ? SL I B7 I? {Ini~ialize sw~tches and ~ara~eter 1,
Pi=;!OMPT
which contains the session library.
PROMPT MEMBER-EXAMPLE,FORMAT-EXAMPLE,UPSI-YES
IFF ?CD?)OOOO GOTO PROMPT
IF ?CD?/2007 CANCEL
IF ?CD? /200 1. S~I I TeH 1. OOO()()()() - - - - - - - - - . Command key 1 was pressed; set switch 1.
IF ?CD? /2002 SIAl I TeH 01.000000
• Command key 2 was pressed; set switch 2.
IF ?CD?.I 200::~) Sl,,1 I TeH 001.00000
• Command key 3 was pressed; set switch 3.
IF? CD? I 2 0 0 -4 SWIT CH 000 :J. 0000
Command key 4 was pressed; set switch 4.
IF? CD? / 2 0 O~:> SWIT CH 000 () :1. 000
• Command key 5 was pressed; set switch 5.
IF ?CD? 1200':') Sl~ I TeH OOOOO:t 00
· Command key 6 was pressed; set switch 6.
LOf~D $Mi~l I NT

l.l

I:~UN

//

S'l~ I TeH

/.1 T f~G

II
1/

1/
1.1

//
/.1

I

// COpy FROM-?l?,
1/ IF SWITCH1.-1 LIBRARY-P,
/1 IF SWITCH2-1 LIBRARY-S,
// IF SWITCH3-1. LIBRARY-O,
// IF SWITCH4-1 LIBRARY-R,
/f IF SWITCH5-i LIBRARY-SYSTEM,
// IF SWITCHb·"·j. L.IBE:f~F("{""i~~LI..., ___
II
NAME-DIR,TO-PRINT

Select correct parameter based upon
wh ich switch was set.

I I END
Note: The PROMPT -Oel statement cannot be used with a format that
requires more than 88 characters of execution output data. If PDATA-NO or
the PDATA parameter is not specified, the PROMPT Oel statement cannot be
used to display a screen that has more than 88 characters of input data. If
PDATA-YES is specified, the maximum amount of input data is controlled by
the user program that reads the screen.

4-8

Using the PROMPT Oel Statement with PDATA-NO
PDATA-ND is the default value for the PDATA parameter and specifies that all
input from the display is used for parameters in the procedure. The input data
is inserted into positional parameters 1 through 11 in sequence. Each
parameter contains eight bytes; therefore, the input/output data on the prompt
screen can contain up to 88 characters. Parameters can be used for
subsequent OCl processing or passed as data to other procedures or
programs.
As an example of using the PROMPT statement with PDATA-NO, consider a
user-written procedure called SEUP, which prompts the operator for the
member name, member type, and library of a member to be edited with SEU.
The PROMPT screen displayed by SEUP will show the active session library as
the default library to be used. The statements in SEUP are:
Defaults the session library
name to parameter 3 .
...
1

4

8

12

16

20

24

II PR OM] PTI ME MB ER -0 CL FM .F OR
SE U 11 1. 12 1. 13?
•

28
M~

32

36

T- SE JfJ1

40

44

48

52

73 '1 SL 18 1'1

til

Notice that parameter 3, if it is not coded on the procedure command, is
assigned the value of the current session library. Because all substitutions in a
record are performed before the record is sent to the initiator function for
processing, the assignment of the session library to parameter 3 is performed
before the prompt screen is displayed.
If a parameter is specified before the prompt screen is displayed, the
corresponding SFGR indicator is set on. For example, if parameter 2 is
specified, SFGR indicator 02 is set on.

Using the UPSI Parameter of the PROMPT Oel Statement
When UPSI-YES is specified on the PROMPT DCl statement, the settings of
the UPSI switches affects the SFGR indicators. Each of the UPSI switches U1
through U8 that is on sets on the corresponding SFGR indicator 91 through 98.
This allows control of the display by the setting of the UPSI switches in a
previous program or SWITCH OCl statement.

Coding Techniques

4-9

The format for the prompt screen is called SEU01 and is in a format load
member called OCLFM. The prompt screen and its Sand D specifications are
as follows:

SEU PROCEDURE MAnnENAHCE

MEMBER NAME

4-10

--->

11111I111

MEMBER TYPE.(A/RIS/F/W/P) --->

~

LIBRARY

10000LlIIBl I I I

--->

Second Edition
Use this coding sheet only to define display screen formats for WSU
and SSFGR. This coding sheet could contain typographical errors.

System/34 Display Screen Format Specifications

Starting
Location

Field
Name
Sequence
Number

1l.

~

j

1 2 3 4 5 6

5~
"0

wsu
Field Name

Field
Length

~~

~"O.-=

;:;;

.~
w

>
C

~

.8 ~20C 0 ~ ~ ~ ~ ~ ti·~ 8
~ _ ~ 8 ~ ~ ~ ~ ~ ~g
~

J:

a

~~~ ~ ~~~ ~

g
~

"0"0
-.;«

~~~

0
'0

-.;

cS~~ u:
QJoa:
~ES
~8~

£.

>
;;;

'0

>

c
.c

u::

~

'I:

a;

c

-.;

.><

c

~

z

f
j

c

:-

2.5

"0

:::>

:pr, --YPE

o
o )1 AD

o - L0

00

18 RAR

)

8 b511 11 ,,/
3
1'''

851 S' y
Sq.! q 'I
1 1 16
1 51 ~ '(

;3

y

V

Y

i'I

y

1'1

'(

~

Y

C

Reserved

~

0
;:;

Constant Data

1-

"

c

;:;

c

8

8
1 2 3

4

5 6

7

8

9 101112131415161718192021222

-'-1-f- f-f-

f-~

- - ~-

RUN

-f-. >- --I-

-

.~- f---

>-- - - .. ---f-.

-- --

.

>-'-1--.>- ---.

--- --- --

_-

f--~ ~_L~:~~ -~~~t ~ -~.~~'-~~~_ ~ ~.: ~.~~~
__

In the previous example, PROCA shows display 01 and then calls MRTPROC,
which is an MRT procedure. Input from display 01 can then be read by the
MRT program.
The sample application described in Chapter 5 also uses the PROM PT OCL
statement to show the initial display.

4-12

PROTECTING RECORDS FROM CONCURRENT UPDATES IN AN MRT
PROGRAM
System/34 protects files that are shared by two or more programs by not
allowing concurrent reads for updates to the same sector of data. The system
cannot, however, protect a single program from itself or two MRT programs
from each other; this means that a program that allows concurrent updates to
a file by two or more display stations might produce incorrect results.
Situations for which a program might need this internal protection arise most
often in RPG MRT programs. WSU has built-in protection of its transaction
file so that an operator can see and change only those entries that were made
from his display station. RPG MRT programs do not have this built-in
protection.
The following information describes a coding technique for protecting records
within an RPG MRT program or COBOL MRT program. This technique protects
an indexed file and, therefore, record keys are referenced. You can use the
same method to protect direct files. In that case, the references to record keys
would apply to relative record numbers.
This coding technique uses two subroutines, RESERV and RELEAS, and a
table, TABREC. The table is used to hold the key of each protected record.
The table elements, therefore, must be the same length as the key. Because a
display station can own only one record at a time, the number of elements in
the table should be the same as the maximum number of requestors of the
program.
The following subroutine, RESERV, is executed each time a record is read for a
possible update:

Indicators

C

f---

AL

&

~
~

Line

.f
3

4

5

6

Result Field

I

Factor 1

~

~

~

C

E~ ERIV

c
c
c

E't

D 4

c

D 6

C

D 7

C

Length

Z
z
9 10 11 12 13 14 1516 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 3 3 34 35 38 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51

D 2

D 5

Factor 2
Name

D 1

D 3

Operation

INi1!
1~

LA NI<

~E

GSIR

fI,e I~Elc
La KUP ASIREC
.".v
~o ve
EN DSR
LO KUIF

rr~ ISIR

ec

Resulting
Indicators
Arithmetic
Plus [Minusl Zero
Compare
< 2[1 = 2
Lookup(Factor 2)is

Comments

1 > 2[1
High

Low Equal

54 55 56 57 5859 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74

[11
[QJ

Coding Techniques

4-13

The field named BLANK is defined in the program as a blank field that has the
same length as the key. You can also use the figurative constant ·BLANK,
which always has the length of the receiving field.
The RESERV subroutine checks whether or not the requested record is in use.
If this key is in the table, the record is in use, and indicator 11 turns on. The
RPG program should ask the operator to retry his request and, thus, give the
owner of the record a chance to release it. If the key is not in the table, the
record is not in use. The subroutine finds a blank element in the table in which
to store the key. Putting the key in the table establishes protection for the
record.
The following subroutine, RELEAS, is executed when an operator is finished
with a record. The subroutine finds the key in the table and then sets the
element to blanks to remove protection from that record and make it available
to other display stations.

c

!-11

~

a

Indatorw

110111

RealltFieid

1

... ~ ~i5' • •
4

I

o1
o2
o3
o4
o5
o•

~.

•

7 •

FICtOr 1

lrZJ

LIIIgttI

Plus

IMinus! Zero

CcImpIre
II 1>211<21
1- 2

..

:a 24
IDlI:II It: .Ale

~!
2Ii 21 27 .21 30 3122 33 24 31 21 37 21 21 •

01(

,..v

1lI0II ...

EC

II A ~"(

H~

Low Equ"

41 42 43 . . . 41547 48 .1051 12 ia 54 II . . 57 18 58 10 111 112 83 14 II III 117 . . . . 70 71 72

iitl
I

C

~
~
~.

'"

.~.

This technique of using the table and two subroutines protects one file. To
protect multiple files used by one RPG MRT program, you must provide one
table per file. If the lengths of the elements differ among tables, you also need
a BLANK field for each table. You can also use the figurative constant
·BLANK, which always has the length of the receiving field.
You should have record lengths that are a multiple of 256 bytes when using
this technique. Refer to File Concepts in Chapter 2 for additional information
about file sharing.

4-14

Comments

~

i ... LooIwp(F8Ctor 2111

rl(E~

c

J::£

FICtOr 2

Name

• 1011 12 11 14 I l' 17 1. 11 20 21 22

C
C

Opemlon

R_III",
IndlcltOfJ
Arithmetic

n

74

PROTECTING RECORDS FROM CONCURRENT UPDATES BY MULTIPLE MRT
PROGRAMS
When two or more MRT programs share a file and are allowed to update it,
unexpected results can occur if you do not protect records from concurrent
updates.
For example, assume that two operators at displays W1 and W3 are using
MRT Program A to update File 1. At the same time, two operators at displays
W2 and W4 are using MRT Program B to update the same file.

W1

W2

To show how an unexpected result can occur in this situation, assume that
while W1 reads record 14 and displays an on-hand quantity, W3 reads record
60. System protection is removed from the sector that contains the first record
read (record 14) and is given to the sector that contains the last record read
(record 60). Because of this loss of protection, the on-hand quantity in record
14 could be read and updated by another program. Program logic must be
able to handle this situation. For example, when a field is read and displayed,
its value on disk rather than its value on the display should be used for
subsequent calculations, because the disk value is more current.
When two programs allocate inventory based on the same displayed on-hand
quantity, one of the operators may make an incorrect decision because the
quantity he sees is not most current. An editing routine in the program should
display a message when an on-hand quantity is not sufficient.

Coding Techniques

4-15

If two M RT programs share a file and both can update that file, you can
protect records from concurrent updates by adding and using an ownership
field in each record. If possible, this field should be large enough to hold the
10 of the display station that updates the record.
The ownership field should be blank until it becomes owned (read for an
update) by a program for a particular display station. To establish ownership, a
program should place its name and a display station 10 in the ownership field.
If that field is already owned by another display station, a message could be
displayed indicating that the record is temporarily not available. The operator
could decide to reread the record or continue with other calculations and return
later to reread the record.
A program could remove ownership of a record by setting the ownership field
to blank; this usually would be done when the updated record is written.
This technique simplifies file recovery because the ownership field provides a
good picture of what was happening when an error occurred. If this technique
is used, a recovery program is needed to check and reset the ownership field
in all records whenever recovery is necessary, such as after a power failure.
An ownership field can also be used to prevent an operator from incorrectly
updating the same record using two different programs. For example, assume
that the operator requests a program, begins updating a record, and then
cancels the program using the Attn key and option 2 or 3 on the Inquiry
display. If the operator requests the same record using another program, the
ownership field would indicate that the canceled program still. owned the
record. The current program could allow an option to be selected that
overrides the program name of the ownership field or could display a message
instructing the operator to recall the first program and normally complete the
transaction update.

4-16

USING THE LOCAL DATA AREA TO INCREASE SORT PROGRAM FLEXIBILITY
The System/34 local data area (lDA) provides a way to increase the flexibility
of System/34 sort programs. By initializing the lDA through Oel and then
accessing this area in the sort statements, you can allow one sort source
member to serve several functions.
For example, suppose the item master file should be sorted to include:
• All items
• Only certain items
• Items within a range
The procedure format might be:

ALL
}
SORTITEMITEMS, Item-~,item. -.2,.,:item.g
{
RANGE, low Item, high Item
'
The following procedure could be coded for this sort:

1

4

II

~

8

12

111

~l~

I FILE

I~

V RLN

16

-OUT

HSIO lA
11l'

I,

FINe

24

28

32

36

40

44

SET-~,IC~ A-'I~ n~ I~C

48

52

I

Ul~L~ EL-IJMAIDIRI,iREtbRIDS-1B~~

A

111l \ 112 12'?C?

3' ?

1

11 ~ L\ 1 'Zio l' 1c? 7?
11111l'1'Z 12'1C?la1

? l ' , 3I 1
'l'7 3/~

1/ ENlt

20

LOCAL OF

1111

Coding Techniques

4-17

As the previous procedure shows, you can control calls of the sort program via
parameters; such control is particularly useful when you select fields based on
variable data in a field.
As the following example shows, you can substitute nearly all sort
specifications:

1

4

8

12

16

20

24

28

32

36

11 7/ lIT IJ LO CA L IOF FS ET -1 lIlA IliA -'
rr 11 1/IVIE r1010 R LO tA l OF FS ET ':1 I,ID !AITIA- ,
L IA #6 ~O
FIL NA I~~E -I NP lJl IliA 18~ L- IlT E~ t-I~T
r: L NA ~IE- OIU TP uT I, L~B El -I TPti iAIDR
R IN
Hsn RT ~ ?Il' 1 , ;' ?~
F C~ L' ~ 18 I ?
II ENO

II
III
1//
II
1/
III/

II

40

......44

48

.0lil1 .. I........

I-

By putting the length of the control field and its beginning and ending
positions in the record in the LDA, you can pass this data to the procedure
that calls the sort program.
Note that the ?L'x,y'? option truncates all leading and trailing blanks.
Therefore, any sort specification fields used in this manner should be
zero-filled (as are the item numbers in the first example).

4-18

52

~ Ii'
I

USING DATA STRUCTURES FOR MULTIPLE LINE DISPLAYS
Using data structures in RPG programs can reduce the number of lines you
code and the amount of array processing required to display multiple lines that
have the same format. For example, a data structure might be used in an RPG
program that has the following display:

Display Screen Layout Sheet
COLUMN
1 -'-1-0----.1--1-1--2-0-··'---21-..-30------,r-----3-1 ---4-0- - T - - 4 - 1·50
61-70
71-80
I
1 234567890 1 234 516 7 890 1 2 3 4 56 7 8901 234 56 7 89 0 1 2 3 4 5 6 7 890 1 23456 7890 1. 23451617181901112131451617181910

-r--S'-'-60

ro---· .. -

01

• • • • I . . • , j •••• I • . . .

02

j , ••• I • . . . j • • •• ! . . .. j •••• I . . . .

I . . . .

I . . ..

I ..••

~., ~ '--~L' L ••.. I .... I ••.. I .•.• I . . . .' i .... I, ,.•. ,_+, '-L.~

I ••• , l. ..... 1.."

04

••••

I ••••

I ....

05

••••

I • • • •

I . . . . I • • . . i . . . . I . . •• j . . . . I . . . . j • •• •I . . . •I....I . •• . I....I •

j ••••

I ....

I , ••• j . . . . 1 •••. j ..... I ••.• j .•.•

I .... I •••• I .... I ••••
I' ,,,I ,, •,I' ,.,I•, ••
08 . . , ' I . , , , I ' . , , I , , , ,~., , , , I , , . ,
09 " . , I . . . . I . . . . I . . , , I ' , , , I . . , ,
10 r-'-'-'_.L lLllit, ,Ll,T.E,M Itt T),E,SIC,RJP,TjI,O,N, ,

"
12

a:: 13

, ••• I ••••

• • , • L• , , ,

I
I
I
I

....
....
' .,,
' .,,

I , , • ,
I , , • ,

I' ,.,
j.,,,
I' ,,,

I' ,,,

I

j , , , , I , , , ,QjT,'r', , ' I

..

L.-'-~+-~ ~<--JI,--,----,,-,-,.......

L ••

I • , , ,

I , . • , j , , , • I , , • ,
I

j •

L_._~~L~. L , ._~ ,.~ ~~~

I' .
I.,
, , , , I ' , , •I , , , , I ' ,
, , , , I ' ,.. . I , • , , I ' ,
,P,RI,CIE, ,L.I,NtE, J,O:r.j!1,L.

I •••• j •••• I •• , ,
I , • . ,

j .,..~

'.L
L

L

"'~" IX'-'-'-Llx'X, l"" I"" I"" I X XXIX,X, .x.XIX,X:l<..,XIX Xx'xIX,X,X.X,.jXx.,., tXX~.1+.L..<-. ,--,-,-I--,--,-~
.". I
.,. I
L, '..J. , +--"-J._' , LJ- ., ., t ' , • , I .. "
",. I, " I . " , I, L.,.I"".1,.L
1
1
• .. • • I " . I ., ,1 ., • , , I ' , , . I, ,. j • • , • I , , "
, . . , I, "I.,., I, " I " . , I •
I ' ,.-L..-..L.~I-.L-L""""""--I
I.,

.I..

, , , ,I
I

I
••• I .,

'"

I

I'
I,
. I • , •• I ' , .. I.

1.1

I

I

,

I

,

15

,.,.

16

••••

I

.,'

I ..

, I , .• ,

17

•• , '

I

, . , I ,.

,I, ...

18

-L

19 _.
20
21
22
23
24

t
I
-,-l " -'-.-'-.~--'.L ..

, , I ••
, . I • • • , .l -,--,--,-L~L.....L--<'--I
, , I , , , , -I- '-..L.-.L....L-~I......................
, , L -'-, , L.-t . -'-., ,-'--'-'I~-....j
, L-L....--'---'--~J~

I

14

~ ..• L~-LI""""""""""""""--l

I . ~._j .•..•• " j • • . . I . . . . j •••• I . . . . I . . . . i . . . . j . . . • j • • • • 1.L'L L~._L.• _~~~-L-L"""""""~'-I

I

03 _-'-."_, •

06
07

~

I ....

I

L

I

I

"I",

I

1•

'-'--'-~

•• I ' , • , I •• ,.

, , • I,

"I",

, . , ' I,

"I""

I.

I' , , •I

I,

"

I,

"j.,

I

I .... L. -'--1...t,. 1.,.1., , ,1. •• , ' I, "I". ~,_-,---,-,--+,
I ' .. , I, ., I . , , , I •.• , " " I
1
1
1
'--'-.....If----'-_L..J_I-.-.... .
L.L.L._L___L+-'--'-~~ -,--,-_+ ..1..-,---,---,-1 L.-'-.-1.._-'-- ~-~r--'--L I ' , , , ----'---'----I, .1_.' 1.. --L-...L.J-.!._..J, _L.I....-'---'----'--+--+-"
, ,I
---'---'- I ' , , , 1 '----'- "
. , •. _...J __
1
~ ___-'--'--+.-'--'---'--...J
-'-_.L ..

1

,

L

I

1.-'----'----'-_.J.

f--'-~

.,.'

L."

-"--'---'--

IX)(

---'----'-.~,

1

I

I

I

I

I

I

I

I

I

1

.J_' ,

I

I
Lt . . . . ."-'--..I......L.~-'-I
1

1

I

1

1

1

., 1

I

I

I

I

1

1

I

I

I

I

. .. I. •• I . , , , I.. 1 ,. l ... ·
I--'-t'---'---t-I---'----'---'--'-.....I--'-'--'--'-....j
jX'LL-,----,--_1X..kL+.J.,U:::1_-'-__L.-,-L):_LJ.. 1~,X+-xx.X)(IXXX."XIX. .x.x.XIXXXXJ..v<,t_L .. J}LX.~~--,--·--,---,--,,--,-J~~
I

1

1.-,-·1 ' ..1. ..

.1_'---

1_...1...

I

T'

L...L.'

.!. ...J_..J .1

I

I

J

,

L' , "

I , ,

L

L~

-'----'-.,

J..~--'--li----'----'

,

L ..1----'----'-

,

I ••••

I , .. 1..-,-.J..+

I

I""

L.J____L.J....~.L.'__J__'__1..___'____'_~~........i......"

..J... __

f

--of . .

L.-'-_L...L..L.

1

I

'

-'--'--'--1-1.._-'-.J.

-'-.+

.J. -'-

-'-

-'-

L ... ,-'--'---+-1---'-'----'-'-.....1........................--1

--'-.. L--'----'----'-_L-'---'---'-".L~.

-1

I

I

1

.
.. 1-10
11--20
21-30
31-40
41-50
51--60
61-70
71-80
123456789012345161718191011121314567890 1121314151617181910 112131415!617T8T~rOI1121314 5678901234567890123456789

Coding Techniques

4-19

Second Edition

GX21·9253

U/M 050"
Printed 'in U.S.A.

Use this coding sheet only to define display screen formats for WSU
and $SFGR. This coding sheet could contain typographical errors.

System/34 Display Screen Format Specifications

"No. of sheets per pad may vary slightly.

WSU Only
:;.

"" >

C

g .8

Sequence
Number

2

3

4

5 6

7 8

I 01121l

wsu
Field Name

DO I..N!.

/..INI.2

LiAj3
oD LI~llI
DO

DO

£'NI~

DO /..NIJ
of} LN7
01tJ ~N8
DO Lllf

1...'" 1O
DO til 1/
010 LN II~
DO

0

;5

'.,
0

!l~

::3:
~~

.8 ~ 8
5 ~
z
,~ ~
c"

...J

::t

:::>
(/)'0

-:3:~g"~

8~

6 ~-~

7 8 9 10" 12 1314 15161718 1920 2122 23

0
0
DO

r-

10

j ~~

Insert
Mode

Indicators

Indicators

~:~~:1Ying

:.'Of2!.~Qg.l
U5tD~~~o:o:

(I)

~:~:1Ying

2312

Reserved

Key Mask

~

a:

2~

I I IT 1 T 111 I I I I I I I I I I I I I I I

" c:

W ~
'0'0

:>0

Sl

:-:c

ac: cS]l~

u.W

8. ~
:>oE

I- ..

~~
c:!;

Ql<

I~i ~

.g

:!;c1!<

C,i.i:"E

'0

Ql
;:

Q.lOa:
i€s ~

.li8~

..§:>0
]

0

c!:

'5.

:r

8.

'0

~

~

a.

""c: ~
iii z

~

~

~

*
~

Reserved

c:" c1!

~ ~
:5 ;9

,~

~
23456789101112131415161718192021222

2526 2728 2930 31323 3435 363738 3940 4142 143 4 4 4546 4748 4950 51 52 53 G4 55 565758596061626364 65 66 67 68 6970 717273 74757677 787980

"16 12- bY
1'15 I 3 hY
'15 I~ 6Y

,;

·8

Constant Data

~1

LIIljIAl

23 IIeJ 61y
23 III l'ilo y
65 I I 6V

~[5 116

c:

8.

~
c:

Q1Y

--

ltl1 14!~

if.

PR ,I" e:

De S~ RI iP1 IltJifJ

.

bY

16 ''I

blS I 7 hY
b5 18 6Y

bls 1<1 61Y
,Is 21" ,y
b! 21 by
b& 22 6'1

0

0
0
0

0

This section provides a partial RPG program that uses a data structure to show
as many as 12 lines of an open order on the previous display.
On each line of the display, the following fields are shown:
Field Name

Description

LNNO
ITNBR
DESCR
QTYOR
PRICE
EXTEND
THSRRN

Line number
Item number
Item description
Quantity on order
Unit price
Extended price
This relative record number

Length
2

6
20
4

8
10

5

The sample RPG program uses an array, OLN, for the fields on the display.
The number of elements in the array is 12, which is the nU,mber of lines used
on the display. The length of each element in the array is 65, which is the sum
of the lengths of one line of fields and includes blanks between the fields.

4-20

~

3

.~ ~

:>0

~~
Field
Length

1 2 3 4 5 6

t-r",~

I I I I I 11

I I

Startina
Location

Field
Name

2!.
~
E

i

Reserved

Review
Mode

910111213141516171819202122 23 2~ 25 26 2728 2930313233343536373839404142434445 4647rS 49505152 5354 5556575859606162636465666768697071727374757677787980

m
~

;: j:

'0

I I I I S zlMvlDI/I'lel

Sequence
Number

'0

~::J Eu~a~~§~c:~c:~ ~:
~ u; ~g.9~&:~ ~ ww en w 0

~
1

~ :;

~ 5 ~
~g ~
~ ~
e ~ i ~ ~ ~ i~ <{ ! ~! ~

Format
Name

2!.
~
E

Enter,

Mode
Sequence

:>0 .,

~

LI 114 £

TIJ 11~L

The following sample RPG program uses a data structure that corresponds to
the format of a line on the display:
RPG CONTROL AND FILE DESCRIPTION SPECIFICATIONS

IJ3:~ International BUSiness Machines Corporation

GX21-9092 UM/050·
Printed in U_S_A.
1

Card Electw Number

Program

2

75 76 17 78 79 80

~~;~;~f~~ation I

page[]]of _
Date

Programmer

IIIII I

Control Specifications
For the valid entries for a system, refer to the RPG reference manual for that system

i

H
r--!

Line

B-.g

~ ~ Execute

5 6

Size to

7

8

0--'
9 10 11

~

of Print

Il -g

Positions

~ ~

~ :~

§

4

Number

Size to

Compile

LL
3

o

;;;

!

olllHl1

Reserved

o "

~il]i

-

~

':0::
1~

~~

c:

'5

~

13 1. 15 16 17 18 19 20 21 22 1.3 24 25 26 27 28 29 30 31 3233 34 35 36 37 3839 40 41 42 43 44 4546 47 48 49 50 51 52 5

II

II

I

11III1111

I

5

55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74

1

11JII11111111111

File Description Specifications
For the valid entries for a system, refer to the RPG reference manual for that system.

File Type

F

-

File Addition/Unordered

Mode of Processing

End of File

Record Address Type
Sequence

Filename

File Format

2

_~_

C
~ ~

3

4

o2
o
o4
o5
3

5 6

7

8

w

6

o

7

F

o8

F

o

g

F

1 0

F

~

l!:

Record

a:
:l

Length

.::::

Type of File
Organization or
Additional Area

--'
w

Device

;3

Symbolic
Device

r~~~~;n

Number of Extents
Tape
Rewind

Storage Index

g

E: overfl~OW
Indicator .~
e
Key Field )(

~~

Number of Tracks
for Cylinder Overflow

Name of
Label Exit

~

w

~ rLL'--'-------''-:E:-xt-er-n--:-al-::R'-eco....Jr'-:d"'':'N~ame...1-...1-'------L-=='''-'---'-i

Option

Condition
Ul-U8,
UC r - - -

Z

Continuation Lines

~

Entry

9·10 11 12 13 14 15 16 17 1819 20 21 22 23 24 25 26 27 28 29 30 31 323334 35 36 37 38 39 4041 42 43 44 4546 47 4849 50 51 52 53 54 55 56 57 56 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74

F\ttj Ott I(S TiN CP
F'
FO RD DE.T
Ie
Fff
FI TE. t\1~ 51 ~c

o

BLeIOnCgkth

>

:J U

g~

N

~r------r----t

LL

line

Extent Exit
for DAM

Length of Key Field or
of Record Address Field

File Designation

F

15 (JIi'

F

b~

F

125 hR 'AI

IWO RI( SiN

DI 511(

3

01

I

~"

F
F
ZL IL OL 69 89 L9 99 S9 "

£9 19 19 09

as as

L9 95 99 ~ £9 Z9 19 09 6t

at Lt 9t 9t tt £t Zt It Ot 6t at Lt 9t 9£ 1>1: tt ZI: It 01: 6Z 8Z LZ 9Z 9Z tZ I:Z ZZ IZ OZ 61 81 Ll 91 91 tIl:l ZI II 01 6

8

L

9

9

t

I:

Z

• Number of sheets per pad may vary slightly.

Coding Techniques

4-21

I

RPG

Ii:r~-t

GX21-9091

EXTENSION AND LINE COUNTER SPECIFICATIONS

Printed

In

UM'050·

U.S.A.

International 8usirw5S Machines Corporation

1

~----------------r---~r
I

2

75 76 77 78 79 80

Program
Identification

pagernOf_

Date

I IIIIII

Extension Specifications

E

Record Sequence of the Chaining File

~

Line

~
I-

4

5

0

1

o
o

2

3

0

4

From Filename

7

6

8

e

E
E

6

() •

-

1--1-

(Alternating

ill

a

Length
of
Entry

Comments

$

a::

Format)

c

..J

£""

CD

"-

1----- I----f- -

I

- 1-1-- -I- 1-------

- 1--

---

--- --1--.-

E

--I---

-1-------

-

-f---

-- f-

~~

---

E

- --

1----

.-.

E

--+

- -

1- -- --I---e-

I

r--- ---

- -_.

-_

i

j
I----

-f--- f-f-

-

-

"-

-1--- -I---- 1--1----

--l- I-- - 1--"- -"-

-- --

-- ---f- -t-

I

j

-1----- 1--:'-

- -- ----f-----

j

rI

- r-

1--

I

1

11'i

f

-

i

2 /'5

f-

,

,-----1----

---

--,-

plo 51 IIl~ ON s OIAi 0 liE. LI ~~
D1:$ e~ ttY II.. IN 1£5 US £D

Ojf

NU ~B £R.

(11£

QL N

1-- -

E

7

0 8

Table or
Array Name

Q

~~

DIS PL Ay

~tS f-~
v IS fO f:

[.\!fIn

-

E

o

o

Length
of
Entry

9 1011 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 3t 32 33 34 35 36 37 38 39 4041 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

AR RAY £L ~~ £IIJ T 1..£ NI6 111~
E~ NO. OF
le Me NT s IN II
E

Number
of
Entries
Per Table
or Alray

Entries
Per
Record

Efj

0 5

o

Table or
Array Name

To Filename

~
3

Number
of

Number of the Chaining Field

....

t- - --

--

1

--.1----

I

-t~ -+

_.-

- --- --

--t--

I--f-- 1--1----

i

1----1--- f - - .. -

--

Line Counter Specifications
10

L
Filename

Line

-c

3

4

1

7

5 6

8

9

1

1 2

11l
U

5
Z

~
z

1
u
0

~~

1l
5

-c

~ §

' ' "",. "'" """"' ' ' "
c:

:::;

0

..J

u.

c
.:i

5
Z

c

..J

:::; z

0

~

l

~~

--f-~I----

r- --+--+---l---1--+

5

c

:::; z

uz

1l

1~

c
.:i

u z

~ ~ ~" ~ ~ ~ ~ ~

---,-1-- -- -- -+-

:;;

1~

-"

§

z

]§

~

-"

~

1

-"

§

"'" '" """:' 'r "," "'" "
c
.:i

u

z

u z

.:i

z

c
.:i

u z

e,

1
u

~

e,

.:i

ffi

11l5

~

u z

z

~

e' eo

£

::i

~

z

12

11

I 1l5
u z

::i

~

z

~ '"" ~ " ,M .e ~ "

I 1l5
u z

:;;

c

~

:::; z

.... '" " "

- I---- - -l-I-I----f--I--

-1----1--

l
'Number of sheets per pad may vary slightly,

External Field Name

~.

Filename
r
O

8.

Record Name

~~

Line

~c:

~

~
Jl

i~

W Vl

~Ji -~ 1
:~.
-

01

e

7 8

02

IOROOET

o

3

I

o

4

I

o

5

I

o

6

I

7

o

8

I
I

o

9

I

1 0

I
I

11

NS

1 3

IITEM~ST INS

1 4

I

3

4-22

-

Position

i

~ g II
! 8 15

-

Position

Ii

J

~ g §:
! 8 15 ~

ga:

0:

From

To

Data Structure

OcTclur!
n mil

g

~

d

RPG

Length
au 61

1 CL

Z CI

,~
~

62 53 64 66 611 67 68 69

~~

1

-II1E~
C~
2

312 !RIC
ZqlaJ tDle LAIR
312 CE~ S

~3i~LNIAO
1~140 II1SR

REC()RD
q

ESC.

N

eo

Field
Indicators

i

-e &!

g ~:~ ~
~ i 0 !

3

1

~

-l3

]:!:!
r ~ ~iI

Field Name

1'i

9 1111- CUST 10

oJ1.
I

J

3

g

§,

DETAIL FILE - LI:NE ITEM ReCORD

1 2

1 6

~~
! i:l

2

8 10 11 12 13 14 15 18 17 18 18 20 21 22 23 24 25 28 27 28 28 30 31 32 33 34 38 38 37 38 39 40 41 42 43 44 45 4tl 47 4tl 49

IM~RDER

o

-

Position

a

5

1

;j; Q

u.1--~O"'.~t.---r~O+-R..-I1i .§ i
Structure
~ ':':'N P-o Z l
N.m.
3 4

Field location

Record Identification Codes

v

Plus

Zero
Minus or
Blank

81 82 83 84 85 86 67 88 liB 70 71 72 73 74

)u z~
"~1-74

I Keying I Graphic
I Instruction I Key

Program

I Date

Programmer

I
I---

Filename
or
Record Name

[
~
E

Line

~
3

4

o

1

5

6

I!*
I

8

cO

j

]

2

1

3

To

From
~

Position

~O

~

Position

~e~

Position

~O
o~

j i~

Data
o R
.~
o~~
~ ~
Structure
z u U III
z u u
zuu
~~ro z 0
Name
9 to 11 12 13 14 1516 11 18 19 20 21 22 23 24 2526 21 28 29 30 31 32 33 34 35 36 31 38 39 40 41 42

5

1

III

:J: :~
Z;

I

Page

[I]

o

0-

Occurs

"'::1

RPG
Field Name

~

Length

n Times

0

~

Data Structure

43 44 45 41;) 47 48

c
~

~

:Iv

olR itA HI 1£ Din 111 lS1 ~v ~1 IJR..f 10 !I.e F/; IEC!1 'ONE D I SfJ lilY

OS

/..,1

I

o

4

I

o

5

I

/1

32 DE S~R.

o

6

I

3A1

o

7

3'1

o

8

I
I

o

9

I

"IS

1 0

I

IAiS

1

1

I

1 2

I

1 3

I

$b
61

1 4

I

I

37 (JQ Ti'l OR.
'13 fJu DO I../I~
41./ DO T1'Ih 2u CE- NTS
15'/ £0 ot.. AR
55 DO /2.
S7 EC EN TS
65 (J1 /-IS R.R..N
t,6 OU 1L IN

1 5

I
I
I

1 8

I

1 9

I

2 0

I

-

:~;~:~::ation I

"

1/1./

--

I

5S

IIIIII

Field
Indicators

0
:§ ~
~

OJ

-5

.s

u::
~ ~

u.

Plus

Mjn\J~

;~

Zero
or
Blank

:;>u

we

2

I

~
U

3

I

..J

~

~

0

o

1 7

of

51 52 53 54 55 56 51 58 59 60 61 62 63 64

o

1 6

75 76 77 78 79 80

Field Location

-;;'1Il

w.

Card Electro Number

Record Identification Codes

~
~
:::0

i

1 I
I I

I I

I I

UM 050"

Printed in U S.A
1 2

External Field Name

~

~

I

GX21-9094

RPG INPUT SPECIFICATIONS

Iif~~ International Business Machines CorporallOil

65 66 61 68 69 70 7172 73 14

.1.(Ij LN NO
I I (JI TN BR
I
I
I

-

I
I
I
I
ZL LL OL 69 89 L9 99 99 v9 £9 Z9 L9 09 69 8S L9 99 99 ~9 C~ 19 LS 09 6~

a..

Lv

g"

S~ v~ £~ l~ Lv O~ 6C 8£ L£ 9C 9C OC CE l£ LC OC 6Z 8l Ll 9Z gZ vl £l lZ Ll Ol 6L 8L LL 9L SL ~L EL lL Ll

OL

6

B

L

9

9

0

elL

"Number of sheets per pad may vary slightly.

Coding Techniques

4-23

RPG CALCULATION SPECIFICATIONS

l!~ Internaltonal 8uslness Machines Corporation

GX21·9093 UM/050'
Printed in U.S.A.

~

Program

C

-

~

At

0;

~.5
I- "0
EE
&8 ~

3

4

5

6

7

Factor 1

Factor 2

Operation

8

Length ~

Name

E

~

9 10 "

~

0

Z

'2 13 '4 15 '6 17 18 19 20 2' 22 23 24 25 26 27 128 29 30 3' 32 33 34 35 36 37 38 39 40 4' 42 43 44 45 46 47 48 49 50 5' 52

lelf. IN 11 III ILL 21: EO 111 CIJ !II~ Ac.. 1E. I~~
o 2 Ie
I~ () V!. \
1/9 9
o 3 Ie
~o VI: \ ,
Nl/if
o Ie
Sf. 10N
IN 9 9
o 5 [pc
(
o 6 IDe
I
o 7 IDe
\
o 8 IIetiF 'iN 11 1;/f Ll ZE. ~R It iIr 1'1 IN Dft.
o

.,g

.

At

.

1

i

I

Do T1

I

Dlc 72

9

~e

Z- AD OJ.

Z- AD oj
I,e
1
IJJ e
71A6
Il'rr RiI1 t
2
l/Jelft= 'RE ~D 1I!JIf. OR /)€,R DE.. ,In IL Iflz I.E
3
CI./ AI NO RD o£T
'Ie
11'1. i1 R. It",
4 IDe
51£ 10N
SO
5 I(J e
&0 10 eND
SO

1 0
1
1
1
1
1

pc. Rc. !AD

rr Hie

11 ~.~

75 76 77 78 79 80

~~~;~f~ation I

III III

Plus IMinusl Zero
Compare

Comments

1> 2J1 < 2J1 = 2
lookup(Factor 21is
High low Equal
.4 55 56 57 58 59 60 61 62 63 64 65 66 61 68 69 70 7' 72 73 74

'Ill

4

o

0:1-

Resulting
Indicators
Arithmetic

Result Field

Indicators

~.

Line

Page~ltf

Date

Programmer

'i

20

Nt il{ ~N

50
50
I..~

MA S1 E:~ FZ t.le:

~OA Of 5~ ~t P1 Z~N
CI-I III N! TE- Ilf ,., S1
5~
1 8 ,tic
~o vf. 'IN 0 DE SC R.' DE SCIR
·S!
1 9
pe~ CII (,t.. ut. 1)11 £ £'t
:JJD £0 PP. I te, it 5£11 FOIR. lfJu 1'P U7
2 0
ql
I!~ 1E. INID
~u L.11 PR I 'It.
IJJe
iQT ~I()R.
!1
21 IfJ e
~b lilt If 'II lEND
~ID OL ~~
'E,c e~ rls I~
3..3 lie
~~ II~ ~I~ 1EI/IJ f)
2.14 lOci" 'No lJe Dill 11~ sir 11." C1 U((E NIA '1ft 1 11 () ov 1P U1 IRR itA" ~l. £~ elN1
OLIN !X
MO liE Ou TIL IN
~~ lie
1 6

1 7

Ipe

l11 N8B.

rre

1.'[pc
U

I'"

IL OL 69 89 L9 99 59 t9 &9 19 19 09 65 85 L5 9S 951'5 £5 l5 IS OS 6t lit Lt lito St ~ £t Z. It O. 6£ 8£ Lt 9£

st t£ £& Z£ It 0& liZ lIZ

Ll !II: Sl .Z &Z ZZ It OZ 61 81 Ll 91 51 .1 £1 ZI II

01 6

8

L

9

9

•

& Z

1

·Number of sheets per pad may vary slightly.

RPG CALCULATION SPECIFICATIONS

~~\I
===-=
':' =International BUSiness Machines Corporation

J

Program

C

~

At

0;

3

4

I-

5

Graphic

Key

I I
I I

I I
I I

I

Card Electro Number

Result Field

At

Factor 1

Operation

1 2
P
age

~ 0 f OJ..
_

75 76 77 78 79 80

I

Program
Identification.

III III

Resulting
Indicators
Plus lMinuslZero
Compare

Factor 2
Name

'0

&8

E

E

~

6

7

9

0

z

Length

0

z

'0 11 12 13 14 '5 16 17 '8 19 20 21 22 23 24 25 26 27 28 29 30 3' 32 33 34 35 36 37 38 39 40 4' 42 43 44 45 46 47 48 49 50 5'

.tel#! t'"' elK 110 S£iE'.. Z~ 111 'NO IF Sio Isl£ TON 11o 2 l.e
'I.
CO I4P 11.
o 3 1e
tll1.
i
~DD
X
t.
o 4 I.e
NI2.
N!~ TR RN
~DO
1
Nit rR. RI,4J
o 5 1e
NI1..
(;0 10 R..T P..N1.
o 6 1e
111116- I£INO
o 7 te
o 8 e
o 9 e
o

I

Arithmetic

~j

line

Keying
Instruction

Indicators

~

r--

I

I Date

Programmer

GX21·9093 UM/050'
Printed in U.S.A.

Comments

1> 21' < 21' = 2
lookup(Factor 21is
High low Equal
b4 55 56 57 58 59 60 6' 62 63 64 65 66 61 68 69 70 71 72 73 74

1

4-24

IJ. AIR. RAY 1:.S FQ I-L

Nt Itl1 I~t. £,. £.N1
NE- XT Il£L Rltt.
,coiR NE. X7 1..1 NE.
e!ND

OIF PH.

0"

f.R~

GX21 9090 UM1050'
Printed In U S.A

RPG OUTPUT SPECIFICATIONS

75 76 77 78 79 80

~~~~:~f:atlon I

o

Output Indicators
Field Name
or
EXCPT NdllW

I--Filename
or
Record Name

Llrlt!

'0:

4

5

6

7

8

9

I

OW OR If

Commas

II I I I I

0

-

- -

r-r--+-+-r+-+-t--1-+-+-t--r-+-+-H-+-+-+-r+-+-I-+--1-+-+-+--+-r1-+-+-~

8

0
HI-+-+-+-+--+-t--I-+--t-+--+--+--+--+-t--I-+-+-++--+-+-I-+I-+--+-- 1-- f-I 9
0
2 0

-

-

--

O~

6£

--1--- -

'+--+--+-~,I-+-+--+-+--+--+-I-+I-+-+-+--+-+--+-+-~I-+I-+-+-+~

0
0
0
0
0
0

II 1L OL 6989 L9 99 59

~9

C9

~9

190965

as

LS 95 55

~s

CS l5 15

os

6~ 8~ L~ ~ S~ ~~ £~ ~~

1P

ac

LC 9£ 5C

~C

CC lC 1C OC 6l 8l Ll 9l Sl

~l

Cl II 1l Ol 6' 8' Ll 9' 5'

~,

C' l' "

0'

6

8

L

9

5

~

C

l

,

-Number of sheets per pad may vary slightly

Coding Techniques

4-25

ACCESSING A FUNCTION CONTROL KEY OR COMMAND KEY IN AN RPG II
PROGRAM
This section presents an example that briefly outlines the steps required to
access a function control key or a command key within an RPG II program. In
this case, the Help function control key is enabled and used in the program.
In the example program, a display called DISP1 is displayed. When DISP1 is
displayed, the operator has the option of pressing the Help key for additional
information. When the Help key is pressed, the program displays help screen
called H ELP01.
In the display screen format specifications for DISP1, a Y must be entered in
column 27 and the key mask must be entered in columns 64 through 69 to
enable the desired key(s). (In this example, a key mask of 5 indicates that the
Help key is the only key enabled.) For further information about these
specifications and other key mask values, refer to the description of the $SFGR
utility program in Chapter 4 of the SSP Reference Manual. The following is the
S specification for DISP1 :

~~
~ ~.g

>.

8

~u~:~e ~

~::at

t-

!
::>

~o~

Eo

~

~ ~

"

~ ~ ~ ~!~ ~

"

"Qi

,j 8~

~ iL_~, - ~

:§A~~-;;~8<- u
EO ~ ai ~ -g :g"~,, ~
us ~g.s£~! ~ ww CD

~>

~ =

1 Reserved
~
~
~

hE;:"nt:::er:---"r-r.,. . ,w:..;.:s:.:.u. .:.o.nly:....-.....,-----I
..
Mode
~~~:w
~~~;
~..9..u~~
Record
Record

'I"

~ :~~?~~~~~~g

:~~7~~~ir~g

Reserved

Key Mask

i
~

cu>8

~i ~ ~

0:

(Q
t:
·E
1
1
2
3
u.
W 0
~~.B&:~~£
2
3
c!
I 2 3 4 ~ 6 7 8 9 10 1I1213141~1617181920 21 22232 2~ 26 2728 2930 3132 33343~36 373839404142~34445 4647 8.91s0~152535455565758~96061626364656667686970 7172 73 74757677 787980

u..

I I rr

I I I I Sl~' ISPlll I I I I I

I I I I I I I I I SI I I I I I I I I I I I I II

I I I I III

In the display screen format specifications for the help screen, HELP01, and for
all other displays issued by the program, Y should also be specified in column
27 and a key mask specified. The following is the S specification for HELP01:

!HI
Sequence
Number

>.

i~
I-

j
1 2 3 4 5 6

Format
Name

8 .8
~ Z5
e ::;

!

S
(/)

"

HU

¥c5 -g
5:~
~~ ~

5
z2

u.
7 8 9 1011 12131. 1516 1718 1920

II II sHIEILI~'UI I I I I

4-26

~

~

::;
'0

.g

c:

.8>.i!: 5
<{

Qi

0

!
~

232 252627

u:

~

u

wsu Only
Review
Mode
Record
Identifying
Indicators

Enter
Mode

l;

.g
Qi

u:

~.s.u~~

" Reserved

c.
c:

~ ] ~
~

~

'g.
~

'5

2930 3132 3334 353E 37383940 414*3

46

w

<5

~

I I ~ 1 I I I III

Key Mask

>

j]!

c:
S £9

~9 ~9

OS 6v 8v Lv 9v SV vv Cv

~v ~v

0" 6C 81: LC 9C SC VC CC

~C ~C

OC &

8~

Ll

9~ S~

vl

C~ ~~ ~~

Ol

6~ 8~

L ~ 91 51 vi CI

~~

II 01

6

8

L

9

9

v

C

~

~

In this example, the INFSR subroutine is called HELPSR and the INFDS data
structure is called INFDS.
The INFDS data structure is defined in the I specifications for the program:
External Field Name

I

j

Reco::: Name

!

S

Field Location

f

g

Filename

Record Identification Codes

El!l

W II>

E
::. '5 -8.
.f 1--~-"-'T-r:::+=-r-t.8
i :;;
Data
OR
E':; 15

line

';t 'i;; "0

3

4

5

6

7

8

01

I~ ~E~DED

I~~FD~

'-

3
4

5

2

_

Position

~

~foINni
e~
~ U is

Position

3

e
~
e~
"'NI'II
~ u ti

From

~

-.2! ~ ~

Position

~()Nca~CQ
e~~~
z u ti c'i5 It

Data Structure

Occurs

~O~

IUElP

Ins

~IUN~TION

~

RPG
Field Name

-

!

~ ~
£ ~ -e
M

.E ~
g
a ii:5
cal'll

-

.§~

Field
Indicators

J
'C

"'i

Zero

Plus Minus or
BI.nk

KEV

STA111J~

I
I
I

TO.~

.~

Structure
~ ~ ~
n Times
Length
0
(,) :0 0
;;:
N
9 ·,':;·,1 12 13 14 15 16 17 18 19 2021 22 23 24 25 26 27 29 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 596061 626364 65 66 67 68 69 70 71 72 73 74

02

o
o
o

1

g;; ta.

~_,

_. L.

._

Coding Techniques

4-27

The *STATUS subfield (shown as STATUS in this example) contains a 5-digit
code that identifies the exception condition. In this case, the code 01125
indicates that the Help key was pressed.
The HELPSR subroutine, which gets control when the H$lp key is pressed, is
coded in the C specifications for the program:

II",

RPG CALCULATION SPECIFICATIONS

I Keying
I Instruction

1 Program

I Programmer

C

I Date

E~
.f8

4

o
o

1

c~

2

c

o
o

3

c~

o

5

o

6

o

7

o
o

8

4

9

1 0
11
1 2
1 3
1 4
1 5

t 6

At

"~
~~

3

5

6

7

I I

I J

Key

-'I II

:. Card Electro Number

Result Field

Jd

Factor 1

:i i

Factor 2

Operation

Name

~

0

z

ER ~OA

S~ B Ro Urr

,

&lr ~.(U. FA Iss E:.O

~

~ .~

HE. LP ~R

rr Art' US

NCirl

cf*

C

t 9

C

2 0

c
Ie
e
c
c
c

1;:
"

~~

75 76 77 78 79 80

~~:;~f~atlon I

pagaDJof

Resulting
Indicators
Arithmetic
Plus IMinusl Zero
Compare
1 >211 <2J1-2
Lookup(Factor 2)is
High Low Equal

11-1

E.&- 5R

E- IRE

II I I II

Comments

ZL IL OL 69 89 £9 99 99

pi IS

rob ~p

prr

~IS '~

bt. 1.0 IIII\S :

HE LP

d 1 L2,

E.rr c:fF

IK~Y

r

p~

2~

IMI

zlZ
213

RkJ L 1/

2 Ie.

IR E"

~O

~~IY'

LL IJIP

L.E. ~II(

2~

Db ~~

~A ~It ~.n late

99

ilJo SR \~ GE 11 N'

~o rr~ L~

PR ~!s ~~o

1'I'g

~Io T~

~t:

I

wi,., etJ

\ J.( EL.

CO ~p

51" ~T uS

c
e
Ie
c
e
C

8

0..

~~

0

z

~l 125
.NO T!~ LI':
c*, ~T HER FV NCIT flJ iAJ KE. I\lS to ULO 8E ~I~ ec I~~~
e~
TA TUS
CO l~fI dL ltl
cl
rrA TV~
C~ I~ ~ al ~ 2Z
ITA T ().~
c~
C~ ~I" ~L LZ ,3,
"p ~" ~J. 1 24e~
TA TUS

1 8

Length

I

I 2

9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 ~ 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 sa 54 55 56 57 5859 60 61 62 63 64 65 66 67 68 68 70 71 72 73 74

C

e

1 7

~V 'CLE.

BE.GIM IIJ£W

\

!.,

~9

C9 Z919 09 69 89 £9 99 99

"Number of sheets per pad may vary slightly.

4-28

Graphic

Indicators

~
~

I--Line

GX21·9093- UM/060·
Printed In U.S.A.

Internllional Bu,in ... Machin .. Corporltion

~9

C9

~9

19 09 61> 8t

£~

8t

9~

M>

~ Z~ I~ O~

6C 8C £C 9t 9t

~t

Ct

ze

It

oe

6Z 9Z £Z 9Z 9Z

~Z

CZ ZZ IZ OZ 61 81 LI 91 91

~I

CI ZI II 01 6

8

£

9

9

I>

t

Z

I

In this example, the subroutine compares the value in STATUS to 01125 to
determine if the Help key was pressed. If the Help key was pressed, indicator
99 is on. When the EXCPT operation is processed, the HElP01 screen is
displayed. The operator can then read and use the information on the display.
Assuming there is only one help screen, the operator then presses the
Enter / Rec Adv key, and the rest of the calculations are processed.
Note: If the operator enters data on a display and then presses the Help key,
the entered data is lost when the screen is redisplayed. The screen is
redisplayed in its original form.

At the end of this subroutine, factor 2 of the ENDSR operation causes control
to return to the beginning of a new cycle. Possible values for factor 2 are:
Factor 2

Description

blank

Control passes to the RPG II error handling
routine, which in most cases causes the
program to halt.

'*GETIN'

Control returns to the beginning of
a new cycle.

'*DETC'

Control returns to the beginning of
detail calculations.

'*CANCl' Files are closed and the program
is canceled.

The following are the 0 specifications for displaying the HElP01 screen:

RPG OUTPUT SPECIFICATIONS

Tif~

GX21·9()90. UM/05O·
Printed in U.S.A.

:E:::==::i ':' =:;. International Business Machinel Corporation

1

Program

0

"§Space

~

Filename
or
Record Name

Line

!
E

3

4

a .2

S

6

7

8

0
0

0 5

0

AL

0
z

1

~

Field Name
or
EXCPT Name

0
z

....

il

I

End
Position
in
Output
Record

a:

i!
8 U
! ~

·AUTO

9 10 11 12 13 14 15 16 17 Ie 19 20 21 22 23 24 2526 27 28 2830 31 32 33 34 35 36 37 38i:Jg 40 41 42 43

01

5P L~ \'
~

0

0 4

~

$

roro j ~

....

Output Indicators

Skip

,£ ~~

~r-:-:

~~"o

O~

0 3

~

i~ e

if;'j .2
A

&
0 1

~~
e

HI& ~} I~

I--t~

~f~~ ~~
~

'.-f--t- .

_.- --

.-

-

.

f--f-...
...

. f-- .

..

2

75 76 77 78 79 80

Page [ D o , _

Date

Programmer

Zero Balances
to Print

Yes
Yes
No
No

Yes
No
Yes
No

No Sign

CR

1
2

A

B

3
4

C
0

J
K
L

M

IIIIII

X = Remove
Plus Sign 5· gY = Date
User
Field Edit
Defined
Z = Zero
Suppress

a:

::J

Constant or Edit Word

iii
ii:

1

2

3

4

S

6

8

7

9

10 11 12 13 14 IS 16 17 18 19 20 21 22 23 24 •

#~~~~~w~~~~~~~~wro~~~~~~D~~ro

-

ll(6 f-.f--

Commas

:~;~':.tion I

-1- ~\
~.

71 72 73 74

-

UE LP el'
I

Coding Techniques

4-29

4-30

Chapter 5. Sample Applications

Sample Order Entry Application
This section is an example of the steps taken during the design of a simple
order entry application. The application is not intended to be complete and
workable, but it does provide examples of some of the major design steps and
development steps. The steps described are:
• Documenting application functions
• Designing the screens
• Designing the files

Design Steps

• Designing the reports
• Documenting program logic
• Building a development library
• Building a development menu
• Creating development procedures
• Creating screen formats

Development Steps

• Coding the programs
• Testing the programs
• Creating program documentation
• Creating production procedures
• Creating production documentation

Sample Applications

5-1

DOCUMENTING APPLICATION FUNCTIONS
Ordinarily, the first step after selecting an application is to document the major
functions to be performed by the application. In this example, a diagram is
used to document the functions. This diagram:
• Identifies operator transactions that will be handled by the application
program. A transaction is the exchange of information between the operator
and the application program.
• Identifies files that will be used.
• Identifies reports to be generated. In this case, the picking slip is the only
report generated.
Figure 5-1 shows the functions to be performed by this order entry application.
Notice that screen IDs are assigned to the major screens and that files are
identified on the diagram. Also, no effort is made to identify error and
exception processing. These items will be considered later as screens are
defined and as more detailed program logic is defined.

5-2

1. The operator enters the customer number and order
number for the order.

2. The application program reads the customer's records in
the customer master file and the ship-to master file. The
application program displays the names and addresses for
the operator to verify.

3. If requested, the application program displays a screen
that allows the operator to change ship-to information
and miscellaneous information.
4. The application program writes order header and ship-to
records to the transaction file.

5. The operator enters the items ordered. one line at a time.

6. The application program reads the item's record in the
item master file. For each valid item entered, the application program writes a record to the transaction file.

7. When the order is complete, the appl ication program rewrites the order to a transaction hold file.

8. An application program prints a picking slip for each
order after it is placed in the transaction hold file.

Picking Slip

Figure 5-1. Order Entry Application

Sample Applications

5-3

DESIGNING THE SCREENS
After the major application functions are documented, the screens are usually
defined. In this example, the following screen standards are used:
• The first position of a line is usually not used; this allows you to place an
attribute character in that position rather than in the last position of the
previous line when you use SOA (Screen Design Aid).
• Each screen has a unique screen 10. The first character of the screen 10
identifies the application (E indicates order entry), and the second character
is a number. The screen 10 is the first output/input field on the screen and
is a nondisplay field in positions 3 and 4 of line 1. For debugging purposes,
the screen 10 may be displayed and then changed to a nondisplay field after
the program has been tested.
• Screen names are formed by combining a three-character abbreviation of
the application, a one-character screen designation, and the two-character
screen 10. For example, screen E1 of an order entry application named ORO
would be OROSE1.
• Each screen has a title, centered on line 2 and underlined.
• Each screen has a 48-character error message field on line 23 and/or line
24. Error message text is provided as a constant from within the program.
(A 48-character field was chosen to make coding of the RPG II output field
easier because a constant of up to 24 characters can be coded on one RPG
II output specification.)
• A legend of operator options should be shown in the lower-right corner of
the screen. If more space is required, the lower-left portion of the screen
(above the error message line) can be used. Command keys are listed in
order.
• All constants are displayed with normal intensity.
• All output/input fields are displayed with high intensity.
• When an error is diagnosed, the field in error is displayed in reverse image,
and the cursor is positio!1ed at that field. The description of the error
condition is displayed on line 23. This error description is also displayed in
reverse image. A put override operation is used to display the error screen.
The indicator used to request the put override operation is the same
indicator used to display the error message, to reverse the image of the
field in error, and to position the cursor.
• The screens usually do not instruct the operator to press the Enter/Rec Adv
key. The written operator instructions will indicate that the operator should
normally press the Enter/Rec Adv key to enter a screen.
• For all input fields on a screen, the operator must press the Field Exit, Field
+, or Field - key after entering information in the field.

5-4

• Automatic record advance is specified for the last input field on a screen so
that the operator need not press the Enter / Rec Adv key if all the fields are
entered.
• Numeric fields are right-adjusted and zero filled or right-adjusted and blank
filled by specifying a Z or B in the adjust/fill entry on the D specification for
the field.
Figure 5-2 shows the form that is used for laying out the screens used by this
application. An area is set aside on each sheet for programming notes that
apply to the screen. These notes are used when detailed logic of the
application programs is defined.
In this example, the screen design process further defines the requirements for
the programs. When each screen is designed, the error conditions and
exception conditions that can be handled by that screen are identified, and any
command keys required to handle those conditions are assigned.
Figure 5-3 shows the layout sheet for screen El, the first screen. From screen
El, the operator can:
• Key the customer number and order number and request to enter additional
information by pressing command key 1.
• Key the customer number and order number and request the screen for
entering items ordered by pressing the Enter/Rec Adv key.
• Cancel the order entry process by pressing command key 7.
Figure 5-4 shows the layout sheet for screen E2, which is displayed only if the
operator presses command key 1 from display screen El. Ship-to information
and miscellaneous order information can be entered from screen E2.
Figure 5-5 shows the layout sheet for screen E3. From screen E3, the operator
enters the individual line items in the order. The operator enters a line item on
line 20 of the screen. In this application, lines 13 through 18 show the last six
lines entered. In addition to being able to enter a new item, the operator can
use this display to step back through the order, to change or delete previously
entered line items, or to cancel the order.
Figure 5-6 shows screen· E4. Screen E4 is used to display the previously
entered lines. Because this screen is displayed using a variable line number
and because it is an output screen only, the screen ID is not coded with the
screen. The screen I D is still assigned for documentation purposes.
After all the screens are laid out, a list of all the screens, their IDs, and where
they are used can be compiled. Figure 5- 7 shows such a list for this
application.

Sample Applications

5-5

Screen Name:
Description:
Screen 10:
Display Screen Layout Sheet
COLUMN

I

1-10
11213141518171819

01

-'-.L.'_

L ..

L.

~~ ..

I

02

I

11-20

111213141518718191
L. •

.L-.~

1

03 ---'--'---'-..._.1........ .L.-L .......

•.L.-...1.-J-....

• I ••

•

I

21-30

'Itll~

.J-.-.J-"'-..&-..L...L....L....'-_+~.~ ........ ! •.
1

•

•

•.

. . . .+-•.. :. ...........J.
I

04 ............. ~L--L. ..... ..L.+...........L..--L-'-.l--'--~L-+--'--

-+-"'-'-'--....J._-'---'-'...... _+

L-...L.. ............

1 ••••
I ....

1 ••••

1 ••••

I ••••

I ••••

I • • •

I • • • •

I •.••• I
I .... I
I . . . .'1

I • • , •

I..•.

L ••••

08

•••• I • • • ,

09

,... 1 . , , ,

10

_-'_._L_... .1. -,--,--.L..

~

12
cr 13

I ' •.• •
I' ,,,
I .• ,

I , , ,

,I

I.•••• I •••.• I ••••
I .... 1 •••• 1 ....
.1_-, • . • I • • • • I . . . .
, I ' , . . 1• , • , I ' . . .

.L

, .LLI .......... L._..L

...~.. I . . . . . ........L...... 11...1
•••• I • • , •

I ................1. •.

I .......

...L...L._L._

L. ..

•

~

,

I . . .. 1 • • • , I L.'.'

.....

'-+

15

••.• I •••• I • , •• I •••• 1 •••• I , •••

I ....

••••

•••• 1 •••• 1, ••• 1 ••••

18
19

.........-'-1.............. _

20

... ~.1

•

21
22
23

I.

• • J.

.1....'-..........

.J..

• , , , 1 , '

, ,

--'----' ..L......J_L.

LJ.

I

-1 .... "'_1._1,

,I"

J..-'- . • . •

t ....

I

1....

•

,

1.............-. . . ~ ...............--'-.L ... ...............

• • , •

I ••.•
I ....

1 ••••

~ ......... I .' •. Lot .L,...... 1 .... _... "-

I •••.

I .... I
I...•I
1. . • • I

L ..

• • • • j • • • • I • • • •

I • • • •

I . ... .

J .................+................~

I • • • •

••••

I

• • • •

I . ,--,-,--I,--,--,,--,--,'--i

•.• •

I • • • •

I ••. , 1 ' . , • I , , , ,

I • .....

I ... • •

1 • • • •

.1

.1..!

!

!.

I' ,,,I
I ' , ,

!

,-.t.. . . -,---,--,--I,--,-,'-i

I ....

L

.•

. L ....

I',"

.........

...L

~.L 1-,

, ,

••

--'-~...1. . .J-.........-.• -'-.l~-'--'-.L..~.-4-1---1....

I .......... ........1.......L.1. I ............ 1. ....
~-,-.l--'--'-L~' I,
.L

L........

"

-f. . . . .
~

t ••

, , , , I •••• I •••• 1 ••

I • •• •

•••• ) ••• , I •••• j •••• I ••••

J . : " . .!-.-'.....L.L'

L

L...L..-'-'--'-'--'---''--'--'.--l

' , . , •• 1 ' , • , I •••• _+ ....... LL--'-..... ~-'-..&-..1 ~

1 ' • , ,

I.,..

1 ,.. • •

I

I ..

1

1

.j. L~ .

.L..L..-'-- .

1

!.

t...... _........._.L...L-I............""-i

--'--'-'--f--...-,-,--,-.L-,---,-,-,-

I

t ...•

._1 ..........

.L..-'

I""

71-80

L ..

L-JL......L.....J'--'--'-i

1 • • • • 1 ' , • • I • , , , 1 • . • • I • • L... 1 • • • • l.. ...-'..........f-..L-J-.J.....L..'-'-,L......L....y

I ... , I

.L.-L'

.t

...L.....LL.L..L..-..&-........

I

,

,

•

,

•

1

'-.J..-'-.....

I ' , , , L.L...L.nL.J..-!-.L L••
I ....

1 .•••• I.....L~. J

1

)

I • • ••

•

•

•

•

•

•

•

1 ....

1 ................. -+__.J. L L.1 . 0. •••

1 ,

1 ,

,_'-,

"

I,

1

+...L-L-'---'--'-I.............--'--L-I

1

L

1 ••••
.1.

'--

'L.JI,--,--,,--,--,'-i

~··I_....... ·LJ.L.....L... .....--'--

I
L.L ......

LJ...~

1......,1......,

<-,

t.

1.

"

I· .•.•

......J.. -'--'--'--'-.l..LnL.....L....

1

I

j

I

I

.1........ •

••

L

, ,

I ......·.

1
,-1'--'--'--'--'-1

j • •

I

I

I •

1

I

.L . .L ' .

~1~ 7 81910[~2~~I;I~I~~71819IJlI2131;1151~~71819IoT11~131:115~:?718191 01,12131 :115!:fiT81~~01112131:1151:f71819101112131:1151~~71819101 U2~3~~~~~:~71819LO

1
1234

1• • • •

1

~.-'---'-...L...l...L......--,-.

24

I "

L

••••

L'

I ..
1 •• L..Lt ...... .1 •• L-L+-'" •• 1, ••• I . , . ~..
1 •••• 1 ..... 1 •••• 1 •••• 1 •••• 1
I
,I
,I '
~ . . L-'--'--'-l ....... , ,I,
, •~........L....

I ••••

16

17

1

'.L L

+. . . . . . . . . . . . 1

........

,--J ...... j.....

• I • • • • 1 •.• • • I • ................ • .....

...,

I ••••

I

L...L...J.. ....

14

L

• •...... J .•.•• '. I . . . .

...

LLt .• L. . . . . 1. ........ ) . . .

1 • • , •

· .•• I , ..• I ••••1..1 ••• I •••• I ••••
I • •.• ,

1 ....

I .......~.L..L.

06 .......... L.L •••
L.L'

I •..•

I

61-70

l·.· .......1_ ................ -+ ........._L...~.-'-- ............ .l .• -'-'--.... t-.. . . .~. . . ..I...-..o.....,I...............-1

......~ ..L.Ll

........

1 ••••

11

Programming Notes:
Figure 5-2. Form Used for Laying Out Display Screens

5-6

...L.. .... ...

I ....

07 _.

I

51·-60

1 2131415161 IIBI91C 11

••• L.J ••••

05

I

41-50
12 3141

-1-1........................ .+ ................ -.1...0. ......."'-f.-.--....-...L-.-.l........J-...L......._-I---.. . . . . . .....J-L-.................... +_

I

1

I

31-40

11

Screen Name:

ORD5 E 1

Description:

Order Start Scree"

Screen 10:

E1
Display Screen Layout Sheet
COLUMN

1
01

,.1;1.

I ••

02
03
~

L.

J •.

t ••• L._1 ••..•• f

L.'

L"

••

~ L...L...L..-'--'--~+-,
~_,

.L .. ~ ,_ J ...L-.L ....

l,

I ..L..~_~
L.LL

L~

~U.STQME.R .~U...aE.~

L.

L

....

••••

I .•••

••••

I •••• I .... I •••• I .... I ••••

07

_• • • •

08

••••

12

••••

a: 13
14
15

.NUJ(~E.R .. I •••• IXXXX~X
.I_. . . . I • • • • , • • • • I •
I ' , , , I , , , • I .... I • • • • , •••• I •

...

• . • ,.

1-,--,--- •.• + •. --'--~_ l... 1 ••••
••

I ••••

t •• •.

I ..

•••• 1 ••••

•

,

••

~

••••

I •••• , ,_.

I

.L..L.J...

I

••••

I • • • • I . . • • I • • • • .\. • •.--'---' 1 .1

. , ••

1 .••• I .... I •••• , •••• I

•

20
21

•

L

~._l-'----'-n..L.--,--I-..... -'----'--'-nL-,----'--'-i.-+_"

• ••• 1 •.--'---'-'-! .•••.
•

L .•

-'--_~.J--'--'---

24

L--'

,Press

--'-n.L......L.--.L.l .. L-_.. L._ •• ,

•

l

L

.• . L . .

•••

,

~
,

•

•

•

i,

• • • , •

L L •••

L

I ....

~_L._'_n~

I

f'

L

L

....

,.

I,

I

I

-1-10-

T---

11-20

I

r

I

~~~.~1,---,---,'-1

L~_
,
..L-_L

I

,I

Initial

• I .•.• I . . . . 1 •••• I ...• tL"

Cursor
Position

. I • • • • 1• . . . 1• • . • I . • • • 1•

I ••••

1 .. , . 1 .

I •••

,

•

1 ••.••

1 •••• , •••

L_.•

1 ....

I •••• , •

L

I

I

•

I

I

,

•

I

,

,

'

,

,

,

,

!

I

,

••

I

!

! •

1 •••• , •••• 1 " , ., •••

I

I •

•

~

,

,

•

••• I

....

l

J

I • • • •

•

,

•

,

.L...L_'

1

L

I

•

J

t.l....

I

J

L

- or,~

,
I

I

21-30·-

I •• , • I

1·-·-

31"':40

IL......L.....J.--i

..L.................

'---'-.LJ....I~-i

..L-.+ •.•

'---'-.--'--+--,-I~.l-,--,---,I,----,---,'-1

I ••••

I ..

1 ••.•

1 •.-•••

I

-'--.....J....~

'-

L..'-"--l--JL...l..-l--'----'---j

I •••• , •• '-'----'1'--'--'~+1--'----'-_'___.L.._1L...l.......'____'___'---j

1 ' . . .......l......._L._L_.__1 L

I'

I,

•

-,-1 ~

••••

,

, I

I •••• , •••• I

.•..L+-...l-..L. . L_..L-I

,.

I..

,---,--",----,''-'--'-'----'--4

I ..........l- .. ·..

1 ...... ··1·.·.- •• L.

I

I , '

I

_L _L

I

1

_..L-~~...L._......L~

t .••. I . L..L.~f-..L.~~
I L.. ' •.•. 1 • "- •.. ~ . 4""."" L_~_ln..L---'._..L- ~

•

I •••• I .••• I ••••

, .. .L +

'...L.-, __ .LL.L--'--...L_-J-..L

I

~~ . 1. --'.-' L .o....J . .L......

I

L .

1

L..L' I

,

....L.-

,I, , ,
I

"CK1 Ito, EN,TE& MI,5C ,QRDE,R il,tlFO,
.. I •••• I ••••

I

I

••

I""~.~".L

,c.K.7. . ICAt.(C.EI~

~NV.ALitD.. .tJJJS]".qft{qR. ~.UM.8.E.ll,,-JlEEt«.tE....R....._.l .... I .J-,--~+,-. L.LL~
I--'----~~I~~-~..L.--L.l--'----'--'- ,

I ..... ~-t~-~.~--,-I~~--l
I

f .... ~. ,

I ..... , • , , , I •••• , •.•.

L_Ll • • • • ..t

••••

L .. L

L .•

•••• 1 ' .. ' I , ••• I . , •. I •••• -+ ••• L..L~_

•

I

I

,I. , -'--'---.\.'._~nL~--'---'----'--~--'---'--'-.'~_.~' '-n.L--'.-+ -'--_L_'-n.o.....1

I ..L.' , • I "
ENT~R/RE(j AOV
'

••• 1, ••

22
23

•.

L.J ••• , •••• I ••.•_.

17

19

J

J.....L.L'nL....L.J

•••

16

18

+ •• L ~.J

.+--'---'--_1.. •. L.........._L .• _+_.L.L' •
f ••.•
I ..... .1 •••• .I .
I •••• , ••
1., .. 1 • • • • 1 .••. 1 •••• , ••••

• .•• I •••• 1
• ••• I ••••

L_.J

1.L_L • •

L

~X)(X~X ..• ILL .. •
I~' ..

I • • • • I •• • • I • • • •

~

•••.

L_L L..L._~ •.._~ ••• • .1 ••

I •.•• p.Ro.e.RI

• ••• I , , • ,

11

+-., .•

L_~.--,-l....L....L...L_..L-_+---..L-

05

10 i--.L---'--..L.--'

I

l.~ ..L.·..L---'..I •••• ! • ~ , .. t 'n .•.. L.~. l_ L~_.L ..• 1 .•• .L.1...L_L .• • ·1 ••
I ...• tQ.K,OLLE.J~~l. E __ L~1 A rt~_..L-..L.nL~~~~+

06

09

I

21-30
!
31--40
41-50
51-60
61-70
71-80
1341516 71819 0111213 41516 71819 01 2[31415.161718J9nLOI112L3141516J71819101U21314J5.l61718l91011121314 5161781910

,.~-'---'-.+ L.U'

,

~.... _.

I

11-20
I
1213 41516'718191C 1

L--'. ..

• •• ,_I ••• ,

~

I

( 1-10
1341516178191

I"
,..

I

.. _L

..O.R.~~ L~NttR'i . . . . .I-'--'--~

.. i ' j ..... I i .

, I • , , , I , • ,....L-._l-'--..L.--'._~ l.L.....L...L... 1 •. L.~n.o....
41-50-

121314151617890123456789012345678901234567 81910 11213141 5161

r

...

51--60

I

iT8T9 rot 1 121314151617181910

1

61-70

I

1

I
[

1
71-80

1121314151617181901234151617181910

Programming Notes:

- otker error mess
LiKe. IteWl
E. ~

Screen Name:
Description:
Screen ID:

EYltr~
Display Screen Layout Sheet

COLUMN
1-10
11-20
45789012345789

21-30
124
78012

31-40
45 78

012

41-50
45
78901

71-80
45
7890

~3-,-----,--'----L....J'---'-+_-"-,----'-'-'--,---I--'--'--L-L-f-"''----''---'----'-'-1.1---,-,---,--,-+-1~L-.L--'----'--'----'---"--+I--'--'--'----'-~''--''---'--'--tl---'---'-~---'-"---'--'-,--+---~-~-'------'----'----i--'-~~-'--'-'-------'--I
02~~~~~~-~,~1,~,~,~I~,~,_~+_O~,R;,~Q~E~R~I~E~N~T~~~~~~,~,~~~~~~~~~~~

01

03

I

~---'----'--"----'----'----'-'__f_"~~~~__'___tl~---'----'--.L~~'_t___<-----'----'-----'--'----'----'--...........,

,,' 1

PROER, NO I

XX~XX

~-,-s.aLJLLIa._~::;:±;:--'----'----'----tZ:;::;::;::::LL---'---'--4.x_-,----,-_~-,---,---,--+--,-S,HI,B
, , I , , , --'---JX:'---'-----'--L--'---'---'-+=-'-----'----'---L--'----'------'---:::tA ,_

07
08

1

~-,---,----,--+--,----,---,----,--J---,----,-----,---,--t---.--,--,----,----L-,-----,--~--,-----,--~J---,--,---~4

05
06

,',

,CUST ,NO , , 1x')(XX~J(

04

_'_. _'_ __-'-- J

_J __ !

,

,

+ ' _,

!

!

.!

! __'__ .L

L+ L

_L---'----'---J __ -'-- __'_ ,

111--------'----'---'----'----~_'______' __~",',",','"
• -'- -'- 1

14 _

L_L_'

J

••

--,--G~

Lines for displaying

15
16

_

17

previously entered
'items

1 '

I '

.. ,

I-'--L_'___'_

,I ,

'

!

'

..

1 ,_----'--_'__-'1
--'-~----'-----'-_ '~---'------'-'_______'__I
L

+-'-L-,----,-L-,---,--4-,----,---,----,--1
,I

, , , '

,

"

1"

,I
'L--L---.L----'--'-----L-L--.j

L-'----'--f----...---'---'--'--l_L_'_-L __ L+--'--_'__L~ __'__ __ , __'_ ___'__l___.L-LL.Ll--'----L-'----'---+--'----'----~-'--'----'-_l___-'----'----'--'-'--'-----'-----''-----'----l

I----'------'---'--_~--'-----'--L.LJL ' , , , ' , --'---'- I , , ' ,

,

L

'

'L_'_~_-'-,' ,P,2I.C,EI ,--'--~,-'- - -'p~-=MO~.uE-'--",N'"--"T.~--'--+-~'--L--L-'----'----'-'-I

, , '

~-,-----,-I
--'--"

LL~--'---:z:z:::::::L:--'-----'---'--l--'---'_I_____<_

loe,sc.,~t.P,ItON""

-'---'----'--+, ,

t_, , , ' ,_ ' ~--'----'---'---,

L---'-----' ___

L

I-'----'-----'--~~-'-----'----+--'----L-'----'---~--'---\--t----'--~--'---'---I"

-,-LlllEL.L- II~M ,KO I , ,QTYj , "

12
0: 13

L,__~_-'--

I ' _'_ _'_ 1 , -'- _'_ __.--1 ___ _'___'_---'----'-_J __ -'---'-_-'---'-+--'--__'_--'----'-~ __'___'__ _

LSALESMN NQ -.xL+--,

USir, eo, \XXXXXJXXX;CX"

~

_L

, ,

, 1 L_' L L-f---L -'--~ _ -'---'-_~-'-:::-:::--'--'7'-'--7"-L"!""7.''---'-=---'-~--'-:"1---::::-'--::::..L_:::--'-_"::_
_ :r:::::~::::r::::::..)LL----,----,--~

---'-__--'---'--__'__l.._'_---'----'-__ ~-L:1:J::L:z:::z:t:;:::-'---LLll~--~JtM--'--

09
10

1
P
I
,TO X, ' , , , , , , , , I ' , , , I

1 '

, ,

~,

, , , I ' , , ,

I----'--'-__~~-'--'----'----'---~'---j

, --'----'----'---_~~-'----'--J-L..L---'---L-__I__-'---'---'----'-....l.-'---'----'-~-'------'--L-'---L---'---L---1---'--L--'---'--'----'--~.L.....f-'----'-----'---'----'---'-----'--'-'---l
,~ 1 ' , , , I , ,
1 ' , , , LJ --,---,--4--'-'---'---'---'---'--'-~---'----'----'----'---'--'-'--'---'-----+---'----'----'--L-J--'----'-----''-----'----l
I

,

-'---'--_---I-__ '--~'--_'__--'-- __ _'__+ __'__~ __' __ _'__l ___'___,--'--,-'--,-'---+--"1''-'!'---'!-----'-,--L.I----'-,-'----'----'-+---'--'-'----'----'~---'---'--+____'___''----'--'-----'----'--~'__i

A new item is entered

18
19

21

22
23

Programming Notes:

- Tkis SCtee~ Q.~pe.o..t-!t (1.) if fk.e.. EY\+e.r fRee. Adv ke~ wo.f:» toressed whett
sc rut\ E 11A1a~ cl (~p\Q.~ed) Or (2.) Q,f+er =ere.e.~ E. 2. Q,PPeAt"'s.
- Field backsPACe. f>koulol allow +I\e. lit\e. ~u.W\ber to ~ eIlie.toed
(lA~e.ot +0 cM.V\9~ a. l i ~ it-e.~).

- If O~\~ a.li~e. ~umber i~ eIlie.toed ) fk.e progra.m shou\d delet-e.

-fkR. Ii~e it.e.Wl.
- Li~e& 13-18

-

reee.rved to disp\a..~ u.p to six pre.\Jl0t.L6l~ e.Kier-e.& iteMs.
It~Wl Vlllm.bet- a.V'd ~ua:Ylfl+~ CAh o"l~ be e.nt.e.rea for ~eW lit\e it~ms.
dVe..

Figure 5-5. Layout of Display Screen E3

Sample Applications

5-9

Screen Name:

ORD5EY.

Description:

E~tered

Screen I D:

E4

I-tems

DiSpl~
Display Screen Layout Sheet
COLUMN

1

1

1-10
1121314516, 71819

I

1

l

11-20
21-30
31-40
41-50
51-60
11213.41516 718191C 1 21341516 718191C 11234151671819 01112131415161 718191011213141516718191

I

1

61-70
71-80
11213 415161718191C 1 231415161718191'

.

01
02

I

03
04
05

I

I

I

1

1

I

I

I

I

I

I

1

, ,

",','"

•.

~.L.L.-I----'-. __J.,.,
1

, ,

I ' , , "

'

1J

1

"I""

1

I

1

I

1

1

'

,.-1----'--'--'---'-.1.-'-.--'----'--,

1 '

I"",

,

.'-~--L-'

~,

--L-'--'--'-'+-1

'

,I,

,I"·,, I""

I ... L~.L.1~-,-,

I

j

I, ,
I, "

I

I

I

1

1

1

1

I

,~~~1~~1~~~1~~+1~~1~~~

I"""

, J.-,----,-.-,-.,-.' ' , , , I ' , , ,

I ~~L-,---

I"""", I",

I

J

I

I

' I ,

I " " " " , I " " " " , I,

~~.L-~I'--'----.L-~I~~,
08 ~, , I , , , , , ' , , , I , , , , , ' "

I

1

1

1

.' I ' , , , I ,

07

10

1

I

I

,

06

09 --__L

1

I

I

, ,

I,

I , , ,

1~.L-jt--'-I......L...L-J1L....L-.l'-'--'-f

--L--'--'- ' - ' . - ' - ' -

1--,-,-..L-,-.1~1
I
,I, ,
L.~.---,--,-I-t..-L~--1
, I'
"L
1
1

,'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 -,-.'-~-l---'-.L---,----,-.. L--~4
, , , , ' , , , I , , , , , ' , , , I , , , , 1---,-,- ~--'-., , , I ' , , , I , , , , I ' , , , I , , , , I '

I

I

I

e5

12

LL~.h, , , , ' , , , I , , , ,

I

I

I

a:

13

'-- __1...1...1. 1

1

J

J

11

14 f---'---..L..L ... L

•

.L,

L--'-

15f--.-'-L~---,-__ -,--.J-...-",I",,--J-.-"
16

-,---,.--,-,-..1.,--,

,

,

I ' , , ,I

17f--'_"---'--'-~~'
18
19
20
21
22

I

"'I

"I",!

~I

I " , ,I"

I,
1

I

I

I

I

I

1

I

I

I

I

1

J

1

J

"I""

.•• , , I •__ --'-, , I ' , ' , I , , ' ,

I, , , '

I',

I

1

, I ' , , , I,

I

"I""

~~__-'-_'"

I

, , , 1

I

,

I

I

I "

,I

I , , ,

,I

I , , , ,

'L..J.

1

I

, I, , , , I , , , , I,

I

I

I

I

I

1

I

1

1

I

",I

1

I

I

I

I

I

I

I

I

I

I

I

I

I

l

J

I

I

I

I

I

I

I ,

1

I

I

I

1

1

1

..1. ••

I, " I " " I ' , , ,
I, , , , 1--,-, , , I, , , '

I

I , , , , I

1""""1""'""1""1",1"",,,,,.1,,,,,1,

I

'~.L.I

, 1 " , 1 " " 1 " , , I·, ' , , 1 , , , , 1 , , , , I,

I

, , , I '-'-

1",,

"--f---...--,--.L.

,I, "

'"

L..L.L..1. ' , , I

23
24

I

I

"'I----'----'---'-L~~'",I"--1,I,,,.L..+-..-

I

I

I

,.,1

1

I

I

l

1
I

1-10
11-20
21-30
31-40
41-50
51-60
61-'0
71-80
1 2345161718191011121314151617181910111213141567890 1 23456789 0 1 2345678 9fo 1 234567890 1 23456789011213456781910

Programming Notes:

- Fie.lds are displCl~ed Ottty Q.fter- edifi.-.g is dOMe..
- Up to ~ Ii Me.S. ~i n be. d isplQ.~ed .
- Va.t;o.ble liKe. Kumbers will be used - stavt OK liKe \3.
Figure 5-6. Layout of Display Screen E4

5-10

Screen
10

Screen
Name

Where Used

E1

OROSE1

Order entry start

E2

OROSE2

Ship-to override and miscellaneous information

E3

OROSE3

Line item entry

E4

OROSE4

Line item display (on variable line)

Note: The screen lOs are used in the input specifications for the RPG II
program to identify the screen being read and to turn on an input indicator.
The screen names are used in the S specifications for the screens and in the
output specifications for the RPG II program to display the desired screen.
Figure 5-7. List of Display Screens Used in the Order Entry Example

Sample Applications

5-11

DESIGNING DISK FILES
At this point, disk file requirements are defined and new files designed.

Master Files
In this example, three master files are used:
• CMAST-the customer master file
• SMAST-the ship-to master file
• IMAST-the item master file
For each of these files, the fields in the file are listed along with a field
description and the field length. Alphameric fields are denoted by an A, and
numeric fields are denoted by an N. The from and to locations and the field
names are assigned. Figure 5-8 shows the list of the fields in each of the
master files. Meaningful field names are used when possible. The first
character of the name identifies the file.
Notes:
1. The record layouts do not show all the fields that would actually be required
in an order entry /billing application. For example, no on-hand quantities are
shown for inventory control.
2. Numeric fields are not packed in this example so that the example will be
easier to follow. In a real application, numeric fields are normally packed
(with two digits stored in each byte except the rightmost byte) to conserve
disk space.

5-12

File name: CMAST
File organization: Indexed
Key: Customer number (CUSNO)
Record length: 128
Field Description

Length

Record code-MA
Delete code-D (blank if not
active)

Decimal
Position

2
1

Data
Format

Location
From
To

Field Name

A

1

2

CRECCD

A

3

3

CDELETE

Customer number

6

N

4

9

CUSNO

Customer name

25

A

10

34

CNAME

Customer address
City
State

25
22
2

A
A
A

35

59

60
82

81
83

Zip code
Salesman number

5
2

0
0

N
N

84

88

CADDR
CCITY
CSTATE
CZIPCD

89

90

CSLSNO

Length

Decimal
Position

Data
Format

0

File name: SMAST
File organization: Indexed
Key: Customer number (SCUSNO)
Record length: 128
Field Description
Record code-SA
Delete code-D (blank if not
active)

2
1

A
A

Customer number
Customer name
Customer address
City

6
25
25

State
Zip code

2
5

0

N
A
A
A
A
N

Length

Decimal
Position

Data
Format

0

22

Location
From
To

Field Name

1

2

SRECCD

3

3

SDELET

4

9

10

34
59
81

SCUSNO
SNAME
SADDR
SCITY

35
60
82
84

83
88

SSTATE
SZIPCD

File name: IMAST
File organization: Indexed
Key: Item number (ITEM NO)
Record length: 128
Field Description
Record code-IT
Delete code-D (blank if not
active)
Item number
Description
Price
Warehouse location

Location
From
To

Field Name

2

A

1

2

IRECCD

1

A

3

3

IDELET
ITEM NO
IDESCR
IWHLOC

6
20

0

N
A

4
10

6

2

N
A

30

9
29
33

34

38

5

IPRICE

Figure 5-8. Record Layouts for Master Files

Sample Applications

5-13

/
Transaction Files

For this application, two transaction files are used. As an order is being built, it
is placed in a partitioned direct file called TRANS. Because, in the example, a
maximum of three display stations can be entering orders at one time, the file
has three partitions. Each partition is assigned for the use of one of the three
possible display stations.
TRANS

After an order has been completely entered, the order is copied from the
TRANS file into a file that contains all orders that have been entered. That file
is called TRANSLOG. After the order has been copied from TRANS, the
partition that the order occupied can be used for another order. In the
following diagram, the operator at display station W2 completes an order; that
order is then written to the TRANSLOG file.

TRANSLOG

The picking slip is printed from the information in the TRANS LOG file.
TRANS LOG

Picking

Slip

5-14

By using the intermediate partitioned file, the designer can achieve the faster
response times that normally result from direct file processing. Also, a simple
access algorithm is used because, after a record is written to the TRANS file,
the program simply increments the relative record number by one to determine
the location of the next record in the order. Using the two transaction files
requires less disk space than if one partitioned direct file were used. If one
partitioned transaction file had been used, each partition in that file would have
to be large enough to hold the maximum number of orders that can be entered
from any display station.
Note: An alternative to using a partitioned direct transaction file would be to
have a different transaction file for each user or display station. The unique file
names could be formed by appending the user 10 or work station 10 to the file
name (for example, FILE?WS?). The technique of using multiple transaction
files normally works well if the data entry program is an SRT program.

The following paragraphs briefly describe the file layout and record formats for
the transaction file.

TRANS File
TRANS file organization:
100101
Area used by
display station 1

200201

Area used by
display station 2

300301
Control
Record

Area used by
display station 3

Note: If orders can be entered from several display stations, consider making
the first record of each partition a control record. This reduces the sector
contention/lockout that might occur when several users require the control
record at the same time.

Records in TRANS file:

128 Bytes

...

"

Record 1

CU

2
CS

3

IT

4

IT

301

Order
Number

"

Customer
Number

"

"

"

"

"

Relative record number of
last record used in partition 1

Customer
Name

Address 1

Address 2

Ship-to
Name

Zip

It

Zip

\'

Address 1

Address 2

Item Number

Line
No.

Description

Quantity

Price

Amount

Item Number

Line
No.

Description

Quantity

Price

Amount

Relative record number of
last record used in partition 2

J
Relative record number of
last record used in partition 3

Sample Applications

5-15

The transaction file contains three different record types:
• The customer record, which is identified by a CU in the first two positions.
The customer record contains the order number, the customer number, the
customer's address, the salesman's number, and the purchase order
number.
• The ship-to record, which is identified by a CS in the first two positions.
This type of record is optional.
• The item records, which are identified by an IT in the first two positions. An
item record exists for each line item entered by the operator.
All records in the file must be the same length. In this example, the records
are 128 bytes long. Because the records must all be the same length, some
disk space is wasted in each record. If the space required for different record
types differs greatly, you might want to break the longer record into segments
or place the different record types into separate files.
Figure 5-9 shows the record layout for the TRANS file.

5-16

File name: TRANS
File organization: Direct
Record length: 128
Field Description
Record code-CU

Length

Decimal
Position

2

Delete code-D (blank if
not active)
Customer number

Data
Format

Location
From
To

Field Name

A

1

2

OCODE

A

3

3

ODELET

N

4

9

CUSNO

6

0

Order number

6

0

N

10

15

ORONO

Customer name

25

A

16

40

CNAME

Customer address

25

A

41

65

CADDR

City

22

66

87

CCITY

State

2

88

89

CSTATE

A

Zip code

5

0

N

90

94

CZIPCD

Salesman number

2

0

N

95

96

CSLSNO

Purchase order number

10

A

97

106 CPONO

2

A

1

2

OCODE

A

3

3

ODELET

Ship-to record:
Record code-CS
Delete code-D (blank if
not active)
Customer number

6

0

N

4

9

CUSNO

Order number

6

0

N

10

15

ORONO

Ship-to name

25

A

16

40

SNAME

Ship-to address

25

A

41

65

SADDR

City

22

A

66

87

SCITY

State

2

A

88

89

SSTATE

Zip code

5

N

90

94

SZIPCD

0

Line item record:
Record code-IT

2

Delete code-D (blank if
not active)

A

1

2

OCODE

A

3

3

ODELET

Customer number

6

0

N

4

9

CUSNO

Order number

6

0

N

10

15

ORONO

Order line number

2

0

N

16

17

OLINE

Item number

6

0

N

18

23

ITMNO

Item description

20

A

24

43

IDESCR

Quantity ordered

6

0

N

44

49

OQTY

Price

6

2

N

50

55

OPRICE

Amount extended

8

2

N

56

63

OAMT

Warehouse location

5

A

64

68

IWHLOC

Figure 5-9 (Part 1 of 2). Record Layout of TRANS File

Sample Applications

5-17

Field Description

Length

Control record:
Record code-QU

2

Relative record

3

Number Used by
Display Station 1
Relative record
Number Used by
Display Station 2
\ Relative record

Decimal
Position

Location
From
To

Field Name

A

1

2

ReODE

0

N

3

5

RR#1

3

0

N

6

8

RR#2

3

0

N

9

11

RR#3

Number Used by
Display Station 3
Figure 5-9 (Part 2 of 2). Record layout of TRANS File

5-18

Data
Format

TRANSLOG File
For this example, the TRANSLOG file is also a direct file. The control record,
which is the first record in the file, identifies the last record used in the file.
Orders are placed in the file as they are completed by each display station
operator. The first record of an order immediately follows the last record of
the previous order written to the file.
Note: If inquiry programs use this file, an indexed organization would probably
be better. The record key could be the order number plus the line number.
The inquiry program could locate an order by chaining to the first record of the
order. If the order file was a direct file, an inquiry program would have to
search for the first relative record number of the requested order.

TRANS LOG file organization:

Record 1

Relative record number of
last record used.

2

CU

3

CS

4

IT

5

IT

6

CU

7

CS

8

I

}

}

IT

First order
entered

Second order
entered

The record layout is the same as for the TRANS file except for the control
record.

Sample Applications

5-19

DESIGNING THE REPORT
Figure 5-10 shows the picking slip, which is printed for each order. The top
inch of the form is reserved for the company's name and address, the phone
number, report title and number, date and page number, and any instructions
to the customer.
The printed lines are arranged so that as few lines as possible are printed.
Because this form is used by warehouse personnel to pick the order, some
information has to be entered by the picker. Examples of information entered
by the picker are PICKED BY, DATE, and QUANTITY SHIPPED. The form
should be long enough to list the average number of line items in an order.
Note: If warehouse locations are used, the line items could be listed in order
by location. This type of listing requires an intermediate sort step performed
by either the sort utility program or a user-written program. The example does
not sort the line items by warehouse location.

Considerations for Designing Output Reports
Certain considerations to be taken into account when you are designing the
output report:
• Leave enough space on the left edge of the report in case you have to bind
the report.
• Separate each field on the report by at least one space from an adjacent
field.
• Group information items that are similar.
• Number all pages of a report. By using page numbers you can have the
operator restart the printing of a job from a specified page number instead
of the beginning of the job in the event that you have to restart a job that
was printing a report. To restart the printing of a job on a page number
other than page one you should use print spooling or code the restart
capability in your program.
• Provide meaningful headings for the data on the report. Abbreviations,
codes, and special symbols should be avoided. If you need more space
than is available on the output design sheet, use several lines for long
headings, rather than abbreviating them.
• Remember that the appearance of the report is important. The report should
be easy to read and self-explanatory.

5-20

1 23

11 11 11 11 11 2 2 22 22 22 2 2 3 3 33 3 3 33 33 44 44 444 44 4 ~ 5 ~ ~ ~ ~ ~ ~ ~ ~6$ 66 66 66 66 7 7 77 77 77 7 7 88 88 88 88 88t
67 89 01 23 4~ 67 89 01 23 4~ 67 89 01 23 4 5 67 89 o 1 23 456 7 8 90 1 2 34 56 78 901 23 45 67 89 01 2 3 45 II 7 89 01 23 45 67 8tO

4~

:

i".,

1'1 ElY FS ZiG rr 11111 It •
It I ~
I
IClt
~"
All ~I(] 'I~
If"" Olf NII~
If[b 1021)
I~I~ -01 let

~L IP
I.IJ /lIe

II

-

I

I"i

ILlt

rr

~IHI

I~
~

~

• tp R.1\l IElre

I.. ', •

'(

~lt ~. l~!i IHI

~J

IE

•

It

;

..

I

I~ 1)(') )(~ ~~[)

I

&.. ~,~" II&. J
~JC
)(~

•

killJ 1l:1. ,ii fHI
~Ia IC!Iir:

I

~iI::: !

I

I'~I

1r::1T,

!.:, 1\

I~'~

: l[l IAirrl:

!

I

IClI. "~I~' lif'.

11

!

~ ~~ ~~ ~~~

tNe ~r.

pfl la~ I/q
I

;

I,

...

I
IIIE

!!:Iiii'

~I

I

!

Rc !::~
I

I

!

I

Figure 5-10. Picking Slip for Order Entry Application

Determining Program Requirements
After the screens are designed, the program requirements can be further
identified. For this application, a transaction-oriented approach is used. Each
program 'processes a limited type of operator transactions.
Program names are formed by combining a three-character application
abbreviation and a three-character function abbreviation. For example,
ORDHDR is a program from the order entry application, and this program
processes header records.
Program

Function

ORDHDR

Processes the screen on which the operator enters the
customer number and the order number. This program also
allows the operator to change miscellaneous information
about the order.

ORDITM

Processes each line item after it is entered.

ORDPRT

Prints a picking slip for each order after it is entered.

Sample Applications

5-21

After the program requirements are determined, some basic design decisions
can be made. In this example, the following decisions are made:
• Keying by the operator should overlap program initiation. For ORDHDR, a
/ / PROMPT statement will be used to display screen E1 before the
ORDHDR program is loaded. Before ORDHDR ends, it will display screen
E3 so that the operator can be keying the first order line while ORDITM is
being initiated.
• ORDHDR will be an SRT program. The SRT attributei.s selected because:
Data entry overlaps program initiation; therefore, initiation time does not
significantly affect response time.
The program is in main 'storage for a relatively short time.
All three operators will probably not initiate an order at the same time.
• ORDITM will be an MRT program. The MRT attribute ,was selected mainly
because the program is in storage for a long time and because all three of
the operators will often be entering line items at the same time.
• ORDPRT will be a no-requestor-terminal (NRT) program. The NRT attribute
was chosen because ORDPRT is a resource-handling program that requires
no operator interaction.
After the progr~m requirements are identified and some of the basic design
decisions are made, the logic of the programs can be defined and documented.
In this case, the logic documentation consists of a flowchart and a written
program description that identifies:
• Data to be keyed
• Data to be sent from the program to the display station
• Required disk accesses by type (input, output, or update)
• Editing to be done
• Options available to the operator
• Calculations to be performed
Figures 5-11 through 5-13 show the flowcharts and program descriptions for
the programs in this example.

5-22

Order Header Program

ORDHDR

EOJ

Error Message
'INVALID CUSTOMER NUMBER'

Error Message
'INVALID ORDER NUMBER'

Figure 5-11 (Part 1 of 2). Logic Documentation for ORDHDR

Sample Applications 5-23

ORDHDR Program Description

ORDHDR is an RPG II SRT program that performs the following functions:
1.

Accept input from either screen E1 or E2.

2.

Enter the customer number and order number on screen E1.

3.

If command key is pressed (KG indicator on), set on external switch U1
and LR indicators. Because the program ends, skip the rest of the
calculations.

4.

From screen E1 :
a. Chain to the customer master file, CMAST, to read the customer's
record and also chain to the ship-to file, SMAST.
b. If the customer's record is not found, write the 'I NVALI 0
CUSTOMER NUMBER, REENTER' error message to screen E1.
c. If the order number is blank, write the 'INVALID ORDER NUMBER,
REENTER' error message to screen E1.
d. If the customer number and the order number are valid and if
command key 1 is pressed (KA ison), display screen E2.

5.

From screen E2, accept ship-to override and / or miscellaneous order
information.

6.

Write to the TRANS file by:
a. Using a table lookup to find which partition to use. For example:
Use an array to read three relative record numbers, RR1, RR2, and
RR3.
TABWS

TABP

W1
W2
W3

1
2
3

b. Chaining to the control record, relative record number 301.
c. If the corresponding last used relative record number (RR#, I) is blank,
Z-ADD (I x 100 + 1). If it is not blank, use RR#,1+1 to write the
customer order header, CU record code, including the user 10.
d. If screen E2 was used, chain to RR#,1+1 and write a second record,
the ship-to and miscellaneous record, CS record code.
e. Chain back to the control record and update the RR# array.
7.

Set up the line number for the items by initializing it to 1.

8.

Display screen E3 showing customer's name and address, ship-to,
miscellaneous information and headings for item entry.

9.

Set on LA.

Figure 5-11 (Part 2 of 2). Logic Documentation for ORDHDR

5-24

ORDITM

Yes

Yes

Yes

Yes

Error Message:

No

Cancel Order;
EOJ

End of this
Order; Rewrite
Records to
TRANSlOG

Read Items
Backward and
Display Them

Validate Item
by Chaining to
IMAST

No

ITEM NUMBER AND
LINE NUMBER MISSING

Error Message:
INVALID ITEM NUMBER,
REENTER

Delete Record

Yes

Write Record
to TRANS

Yes

Change Record
in TRANS

Figure 5-12 (Part 1 of 2). Logic Documentation for ORDITM

Sample Applications 5-25

ORDITM Program Description

ORDITM is an RPG II MRT program that performs the following functions:
1.

Accept input from screen E3.

2.

The item number and quantity are the minimum information to be
entered.

3.

Save the work station ID and indicators. Set up a field for the variable
line number and code the program for three display stations.

4.

If command key 8 is pressed (KH is on), the current order being worked
on should be canceled. Reset to zero the corresponding relative record
number in the TRANS file for the display station. The order will not be
written to the TRANSLOG file. Display screen E1 to enter another
order.

5.

If command key 2 is pressed (KB is on), the order is complete. Chain to
the control record of the TRANS file to find out how many records have
to be copied to the TRANSLOG file. Chain to the control record (the
first record) of the TRANSLOG file to find the last relative record used.
Read a record from TRANS and write the record to TRANSLOG until all
records for the order have been copied. At the end, update the control
record of TRANSLOG. Display screen E1 to enter another order.

6.

If command key 3 is pressed (KC is on), read the control record of
TRANS and read backwards and display one at a time using screen E4.
Display a maximum of six lines at a time. Then command key 3 can
again be pressed. Save the last relative record number displayed.

7.

If an item number is entered, chain to the item master file, I MAST, to
read the item's record. If the item record is not found, write the
'INVALID ITEM NUMBER, REENTER' error message to screen E3. If
the item is found, write the record to the TRANS file, IT record code,
and update the control record of the TRANS file.

8.

If a line number less than the current one is entered, a record will be
changed or deleted. If only the line number is entered, the line item is
deleted. Read the previously entered items backwards from the TRANS
file and tag the one to be deleted by placing a D in position 3.

9.

Add one to the line number to indicate the next item to be entered.
Display the previously entered line on screen E4. Then display screen
E3 to accept the next line item. Be sure to check the variable line's
value. Its initial value is 13. Add one for each line displayed until 18 is
reached, then reset to 13.

Figure 5-12 (Part 2 of 2). Logic Documentation for ORDITM

5-26

Picking Slip Program

I

I

TRANSLOG

Picking
Slip

ORDPRT
(NRT)

\~---"'\

-

ORDPRT Program Description

ORDPRT is an RPG II NRT program that performs the following functions:

1.

Read the control record of the TRANSLOG file to find the last record
printed.

2.

Read each record for the order and print each line.

3.

At the end of the order, update the control record with the relative record
number of the last record printed.

Figure 5-13. Logic Documentation for ORDPRT

System Flowchart

After you have completed the requirements definitions and documented the
logic needed in your programs, you should prepare a general systems flow of
your application. The system flowchart should identify the basic operations of
your programs and the resources needed by your programs, and should include
any information you find helpful in explaining the application. The system
flowchart is used to show the basic inputs, outputs, processing steps, and
processing programs.
The following diagram is a sample of a system flowchart for the order entry
application.

Sample Applications 5-27

ORG. Programmin
AUTHOR A. Programmer

DATE
PAGE

01/15/78
1 OF 1

Notes
Run Frequency: Daily
Volume: Approximately 500 transactions
per day

ORDHDR (OR-01)
Program Type: SRT
Est Elapsed Time: 1 hour
ORDHDR
Order
Entry
Processing

Accepts customer number, order
number, and ship-to information,
and writes header customer and
ship-to-records to the TRANSACTION
file.

ORDITM (OR-02)
Program Type: MRT
Est Elapsed Time: 30 minutes
Accepts item number and quantity
information, and writes an order
record to the TRANSLOG file.

ORDPRT (OR-03)

ORDPRT

Program Type: NRT
Est Elapsed Time: 10 minutes
Two-Part Paper
Form: 6311Y
Report No. 6311-A

5-28

Generates picking slips, and
updates a control record in the
TRANSLOG file.

BUILDING A DEVELOPMENT LIBRARY
Often, the first step in application development is to build a development
library. For this example a development library called TESTLIB can be built by
entering the following procedure command:
BLDLlBR TESTLlB,100,20

BUILDING A DEVELOPMENT MENU
After the development library is built, a development menu can be created. A
development menu saves much time by allowing the developer to select
often-used functions, such as modifying and compiling an RPG II program,
from a menu.
To build a development menu called TESTM and store it in TESTLlB, enter the
following SDA command:
SDA TESTM,TESTLIB
For detailed information about how you can use SDA to interactively build
menus, refer to the SDA Reference Manual.
The development menu for this example is shown below. In this case, the
developer has taken advantage of the freedom of design that free-format
menus provide by grouping related functions and separating those groups with
dashed lines.

COMMAND

W7

MENU: TESTM

!-------------------------------!-----------------------------------------:
: SDA

1. Screen Design

tlENU

13.

System functions

14. Other library functions

2. Menu Build

:--------------------~----------:--------------------- --------------------:

: SEU

3. Procedure
4. Program

MIse

:------------------------------: COMPILE

5. RPG II

6.

17.

Dlsplay file records

18. Remove library members
19. Data File Utility
20. BASIC

~1SU

!-------------------------------:
: CATALOG

15. Initialize diskette
16. Backu p 1 i brary

7. Disk
8. Diskette

:-----------------------------------------:
21. Procedure
:-------------------------------: LIST
FILE

9. Save

10. Restore
11. De 1ete

12. Rename/Reorganize

22. Program

23. Directory

:----------------------------------------CHANGE

24. Change Session library/menu

:-------------------------------:--~------------------ --------------------

ENTER NUt1BER, COt11'IAND, OR OCL.

<-

READY

Sample Applications

5-29

CREATING DEVELOPMENT PROCEDURES
After building the menu, you can use SEU to create each of the procedures
used by the TESTM menu. To create each procedure, you could enter the
following command:
SEU name,P",TESTLIB
where name is the name of the procedure being created. Or you can use item
3, once it is created, from the TESTM procedure. The following sections
describe the procedures for three of the functions on the development menu.
The procedures described are:
• Using SEU to update and recompile a program (item 4 on the menu)
• Saving disk files (item 9 on the menu)
• Changing the session library and / or menu (item 24 on the menu)
These procedures show many of the functions that can be incorporated into
procedures to make them easier to use. For further information about coding
procedures, refer to Chapter 5 of the SSP Reference Manual.
Following the descriptions of the procedures is a section that lists the screen
format specifications for the PROM PT screens displayed by the procedures and
lists the contents of the procedures.

Using SEU to Update and Recompile a Program (ZSEUR)
A procedure called ZSEUR is called when menu item 4 is selected. The
procedure intially displays a format that prompts for the source program name.
The current session library is also displayed, but the cursor is positioned at the
source program name.

SEU UPDATE OF RPG II PROGRAM

Current session
Source

libr~ry

me~ber n~me

Is member an RPG II

5-30

progr~m

--->

TESTLIB

--->

fROGA

--->

r

The RPG II compiler is not called unless the Y is entered.
The ZSEUR procedure then calls SEU execution so the user can create or
update the program or source member. After SEU execution ends, ZSEUR
displays another PROMPT screen from which the user can compile the
program.

,
COMPILE OPTION OF RPG II PROGRAM

Current session 1i brary

--->

TEST LIB

Source program name

--->

PRDGA

Standard default compile

--->

rES

Run from JOBQ

(O-no,l-yes) --->

1

XREF list req

(O-no,l-yes) --->

0

(Standard Default parameters:
Replace assumed) source and load processed from current
session library. 60 Blocks used for work files.)

If the user leaves the third field as is (YES), the program is compiled using
default parameters defined within the ZSEUR procedure. If the user enters
another value (for instance, NO) in the third field, the procedure calls the
RPG II prompt screen.
In summary, the ZSEUR procedure helps with the typical development task of
changing and recompiling a program by combining the two steps into one
procedure. The specifications for the PROMPT screens and the contents of the
ZSEUR procedure are in PROMPT screens and the contents of the ZSEUR
procedure are in Listings for Sample Development Procedures, which follows the
description of the ZSAVEF and ZLiSCHNG procedures.

Sample Applications

5-31

Saving Disk Files (ZSAVEF)
A procedure called Z5AVEF is called when menu item 9 is selected. Z5AVEF
displays the following prompt screen, which allows the user to copy all files in
a file group or to copy up to five individual files. The retention days of 999,
volume 10 of IBMIRO, and location of 51 are coded as a default, but they can
be changed.

SAVE FILE OPTIONS

Enter:

(1 to 999) --->

retention days

date if more than one file exists

--->

volume-ID of diskette

--->

location

(S1,S2,S3,M1.nn,M2.nn) --->

Enter group name if desired:

--->

Enter up to 5 file names:

--->

- all files on diskette
- an individual file

999

IBMIRD
S1

(ALL) --->

(name) --->
--->

--->

The ZSAVEF procedure allows the user to save. more than one file on diskette,
unlike the SAVE procedure (described in the SSP Reference Manual), which can
only save one. The specifications for the prompt screen and the ZSAVEF
procedure are in Listings for Sample Development Procedures, which follows the
description of the ZLlBCHNG procedure.

5-32

Changing the Session Library and/or Menu (ZLlBCHNG)

A procedure called ZLlBCHNG is called when menu item 24 is selected. The
ZLlBCHNG procedure displays the current library and allows the user to change
the session library and/ or the current menu. The ZLlBCHNG procedure
prompts the operator for the new session library name and the menu name.

CHANGE SESSION LIBRARY
CUrrent session library -->

TESTLIB

Hew session 1 i brary name --> ....
L....I.l--L.....J-..M-L-..L.............

Display new menu -->

I

I

( Enter either library name or menu name or both)

The specifications for the prompt screen and the contents of the ZLlBCHNG
procedure are in Listings for Sample Development Procedures, which follows.

Sample Applications

5-33

Listings for Sample Development Procedures

This section contains listings of the sample procedures just described. Along
with the listing of procedure contents are the specifications for the prompt
screens displayed by those procedures. The screens themselves are shown in
the preceding sections.

Listings for ZSEUR

The ZSEUR procedure, which allows the user to update and recompile a
program, contains the following statements:

* PROGRAM ENTRY FOR ZSEUR
II

IFF? 1 F' ?SLIB? ' I PROMPT MEMBER-ZRFM, FORMAT-SEU

I I IF ?3?/Y IF ?F3 'R'

I I IFF? 3? IY IF ?F3 ' S ' ? I
SEU?2R?,?3?",,?1?
I I IF ?3? IS CANCEL
I I PROMPT MEMBER-ZRFM, FORMAT-COMPILE
1/ IF? 3 ? IYES RPG ? 2? , 60 , 60 , REPLACE, ? 1 ? , ? 1 ? , , , , ? 4 ? ? 5 ?
I I IFF? 3 ? IYES HELP RPG
As shown earlier, ZSEUR issues two displays. The first display (SEU) prompts
for the session library and the source program name. The second display
(COMPILE) prompts for information required to compile the program. The
following charts are the display screen specifications for both displays.

5-34

Second Edition

GX21·9253·

Use this coding sheet only to define display screen formats for WSU
and $SFGR. This coding sheet could contain typographical errors.

System/34 Display Screen Format Specifications

UIM 050'
Printed in U.S.A.

• No. of sheets per pad may vary slightly.

WSU Only

~

Sequence

Number

r-rr

2 3

Format

I~

j
I

4 5 6

S

~ ~
~ ~
e ~

Name

~

c:

~

!

>. ~

E

~~

~

.g E

~

u:::

~.9.u~~

.!:

Reserved

0

Review

Inser't

Identifying

Identifying

~~:;rd

~

a.

1 ~, :>
1~ ~! ~ ~

~~ ~~ ~ ~ ~~ ~

j : I~ j j ii

~td~

~"O

~

Indicators

~ ~ i I !II!

1

2

~~:rd

Reserved

I

Key Mask

Indicators

3

1

2

~

3

7 8 910111213141516171819202122 232 2526272829303132333435 3E 3738394041 42~344 454647148 495051525354 555657585960 616263646566676869707172 7374757677 787980

l't~ Y

slElu

I

.

I!I I I I I II I II !III I I

Starting
Location

Field
Name
Sequence
Number

Field

~

wsu

l-

E

1 2 3

~'T

~

4 5 6

Field Name

~

Length

~~

~~

~

.~ ~

0

.8,f
~ ~ u.
8
5 ~:"~ ~ -;.2~~~tiii c
Z
_
5.;3 ~ ? ~ ~ 6~ ~
W

S

I

8

W ~
"0"0
-0;«

>

~

iii

a.U: ~

"0
-0;

o~~

Ii:

~

"0

0

" 0 a:
~EB

~]- ~ ~ ~ ~ ~ ~ ~8~

£

>
;;;

"0
-0;

c:

Ii:

.s:;

""c:

:;;

~

a

i!j,

c:

iii

>
~

~

z

~

c:

1?

a:

Reserved

!!.

0

Constant Data

JI

?

~

~

c:

8

::>8

c:

8,2345678910,1,2131415,617,8192021222

7891011121314151617181920212223225262728293031323 34 35 36 37 38 3940 41 42 344 45 46 47 4E 4! 5051 52 53 ,4 55 56 5758 59 60 61 626364 65 66 67 68 6970 71 72 73 747576 77 78 7980

o IE~ Drl~~
o £Mls£R

~

r'I

Is £Iu

I~ p ~11~

loF

~

roo.

II"

~

Of
o

• _.)

I\,
ICI_ 1.1,.

o

e

- .-)

1'1
rrlc
o riAl..

• --)

IV
I\"
o
o

1'1

10
o
o
o

o
o

Sample Applications

5-35

Second Edition

System/34 Display Screen Format Specifications

Sequence
Number

1 2

3

4

o

I.

o
o~iL)tl~

- -I ...

ole

-_1->

>

ol"IE~

DpiA r.:
°ulasl)

o-x111 E.IF

5-36

Olbla

I I 11'!lI1.11l

Use this coding sheet only to define display screen formats for WSU
and SSFGR. This coding sheet could contain typographical errors.

GX21·925J.

UIM 050"

Printed in U.S.A.
"No. of sheets per pad may vary slightly.

Second Edition

GX21·9253·

Use this coding sheet only to define display SCreen formats for WSU
and $SFGR. This coding sheet could contain typographical errors.

System/34 Display Screen Format Specifications

U/M 050'
Printed in U.S.A.

·No. of sheets per pad may vary slightly.

WSU Only

8>.

11\

~
'C
~ -g
~ ~ ~
gE
e ~ ~~ ~~ % ~~ ~
~ ~ ~ d ~ _~ ~ Vl~"O
:J

Sequence

Number

Format

~

~
1 2 ,;

4 " 6

C

!

Name

....

Enter

>

~~

~

i

~

Ii:

) 8 9 1011 111J 14151617 18 192021

III TT:+~ltT

n

"0

C

Reserved

C>

-g
0

Review

Inser'l

f~-'!u~~
~~:;rd
~~:;rd
Id t"f'
Id tOf'
d
~
I--I_n~,..-7c_~t_~r-lr~_9-4-_I_n~,..-7c_~t_~,..-I~g--l Reserve
~ ~ ~ '~I
::

a ~

iB3~~~ ~ ~~ ~ ~
U

Vi

Mode

'C

i

~~~~~~~

0.

-

l

Key Mask

'"

1

2

3

1

2

3

a:

2J 2 25262) 28 2930 3132 3334 35 31 37383940414214344 45 464)~8 49505152 5354 5556 5758596061626364656667 6869707172 73 74757677)8 )980

rf 1

I

111 I f !11f I I I I I 1 1 1 1 1

Starting
Location

Field
Name

~1

Sequence
Number

Field

~

'C

t-

WSU

j

:5 ~

Field Name

~~

:>

Length

!

d:

~2_

!

~ --g ~ ~
~
0:- ~ ~ ~ t ~ ~ ~

8

~~ ~ ~ ~~ 0
C.
_:;
~ -g ::: .~
0 ~~~~~~~ ~

:J::l

Z

.J ~

~

1'0

~ ~

w

~

0

'C'C

~~

'C

~

~~j ~ ~

~~~

w8<

~

0

<=

c

d:

:I:

a;

~

;
~

Z

E
'"

cc

~

~

Reserved

ell

~ ~

:>8

1234567891011121314151617181920212223225262728293031323 343536373839404142 3444546474E 45 505152

O~I+leIYI~

!

Constant Data

:

c
c
8,23456)89'011,2'3,4,5'617,8,9202,222
53~45551

~

57585960616263646566676869707172 73 747576 77 787980

:

Ic.~ IrlrlX
~~4-~~OJ~~_~IQ~I~~I~~~II~~~~~~~~I~c~ql~~~~~~I~.~~_~~.~~~f~b~~~~~~~~~~~_~~~'~~4-~~~+-~-+~~-+~~_~~~-+~~~I'~~~~~~
I-

Dr
II~IQN
Dle c.I~~ "I"" ~fCL ~b~ ~~~~ ~lili~~.D

1~~!~~lil~l~ 1\lilbl~I~YI~

,I~ I~I'~

0
0
0
0
0
0
D

10
0
D
D

111111:111111111111111111111111111111111111111111111111I1111111111111111111

II \ IIi

Sample Applications

1\

5-37

Listings for ZSAVEF
The ZSAVEF procedure, which allows the user to copy all files in a file group
or to copy up to five individual files, contains the following statements:

* SAVE FILES
I I PROMPT MEMBER-ZXFM,FORMAT-SAVE

I I IF ?5? I GOTO SKP1

* '? 5? GROUP FILES are BEING SAVED ON DISKETTE'
SAVEALL,?1?,?2?,?3?,?5?,?4?
II TAGSKP1
I I IF ?6? I GOTO SKP2
I I * '?6? FILE IS BEING SAVED ON DISKETTE'
II
LOAD $COPY
II
FILENAME-COPYIN,LABEL-?6?,UNIT-F1
II
FILENAME-COPYO,RETAIN-?1?,LABEL-?6?,LOCATION-?4?,AUTO-YES,
II
PACK-?3?,UNIT-I1
II
RUN
I I COPYFILE OUTPUT-DISK, REORG-NO
II END
I I TAG SKP2
I I IF ?7? GOTO SKP3
I I * '?7? FILE IS BEING SAVED ON DISKETTE'
II
LOAD $COPY
II
FILENAME-COPYIN,LABEL-?7?,UNIT-F1
II
FILENAME-COPYO,RETAIN-?1?,LABEL-?7?,LOCATION-?4?,AUTO-YES,
II
PACK-?3?,UNIT-I1
II
RUN
I I COPYFILEOUTPUT-DISK,REORG-NO
II END
I I TAG SKP3
I I IF ?8?1 GOTOSKP4
I I * '?8? FILE IS BEING SAVED ON DISKETTE'
II
LOAD $ COpy
II
FILENAME-COPYIN,LABEL-?8?,UNIT-F1
II
FILENAME-COPYO,RETAIN-?1?,LABEL-?8?,LOCATION-?4?,AUTO-YES,
II
PACK-?3?,UNIT-I1
II
RUN
I I COPYFILE OUTPUT-DISK,REORG-NO
II END
II

IITAGSKP4
I IF ?9? I GO TO SKP5
I 1* ' ?9? I FILE IS BEING SAVED ON DISKETTE'
II
LOAD $COPY

j

II

FILENAME-COPYIN,LABEL-?9?,UNIT-F1

II
FILENAME-COPYO,RETAIN-?1?,LABEL-?9?,LOCATION-?4?,AUTO-YES,
II
PACK-?3?,UNIT-I1
II
RUN
I I COPYFILE OUPUT-DISK, REORG-NO
II END

5-38

I I TAGSKP5
I I IF ? 1O? I GOTO SKP6
I I * '? 1O? FILE IS BEING SAVED ON DISKETTE'
II
LOAD $COPY
II
FILENAME-COPYIN,LABEL-?10?,UNIT-F1
II
FILENAME-COPYO,RETAIN-?1?,LABEL-?10?,LABEL-?10?,LOCATION-?4?,AUTO-YES,
PACK-?3?,UNIT-I1
II
RUN
II
I I COPYFILEOUTPUT-DISK,REORG-NO
II END
II TAGSKP6
As shown earlier, ZSAVEF issues one display (called SAVE), which prompts for
the save file options" The following listing shows the display screen
specifications for the display:

Second Edition

System/34 Display Screen Format Specifications

GX21·925J. U/M 050"
Printed in U.S.A.

Use this coding sheet only to define display screen formats for WSU
and $SFGR. This coding sheet could contain typographical errors.

"No. of sheets per pad may vary slightly.

WSU Only

~

~u~:~e I ~
~

7 8

II

I

I

f-r--g

1-----,.........,
~:J

~

:~

Length

Reserved

c

i"

D: ...

Mode
Record

~ :~~7~~~~'r~g

&

~,,~il~~I~l

D~II~~~b

.ii

-

!!!~ i

>

:: c:

LA. W

a

a~

I)

I...

Y
I~

III ~I"I
I......

III I..,

I\'
D

DplA
Dcl, f:Il~11 I.

-..

!.

.~e

Constant Data

~

8.~

C

~

c:

~iAlvl~ ~1~lll~
II:

I~ ~
I.

~

"ol~ IJla

IV

--I-I>
1'1

1\1

IV

Iv

l't
-)

~
roc

\'1

Ivla ulrcle -I]'~ ItI!Ilf.

--IV

II tl'~~ilor

U:i

Ix

I~it

Islx.

l't

I~
Dklolt\it ID

c:

Reserved

81-1-2-3-4-5-6-7-8-"7"9-:10-1-:1:":12":-:13:"":"1':""4:":15":":16:"":"1:-71:":8"':":19:-:2:-02:71::
22:-:::1
2
4g50515253~45556 575859606162636465666768697071727374757677787980

I~

Iv

ILll I+I~ 1C;lq~
l.. i.IOIIl#

~

~

3

0

Q.

'N

"i
Dli IJ e 1fII.!il:11 iI;,+1s
DltlA1iG
~
DI£~lf

]

g

W!l!

L~

""'111111

Key Mask

I I I I 1 \ 1 1 1 1 1 1 1 1 1.1 J 1JJ I 1 1 \

.

.0._._

D

Reserved

252627282930 31323334353E 373839404142\4344454647 8491&051525354555657585960616263(6465666768697071727374757677187980

g

~llll

:~~7~~~~~g

2312

u;Jl~&:~Q:Q:

7 8 910111213141516171819202122232 25262728293031323 343536373839404142 34445 4E 474li

D

Insert'
Mode
Record

G.I>u

i:Li:"E~";; .~~ " ~ ~!j,
~
ell
.! .. d ~.2 !. ~ ~ is Ii:
£5 ~ ~ Li: ~u..-.!i!
E ...
->OQ,! ..... c
-a:t;;
E
... 5C ~'-Ec
i 2 ~ ! I- ~ ~ t,l S :~ ~ g 0 l!! .c ~ -g ~ -8.2
5 £ 8 ~ ~ ~ ~ ~ ~ i ~ ~ 8~ £ £ i6 ~ £ :5 8
~

Field

g

I I Y \ \ .\ I I I

I
Starting
Location

~ wsu
:5~
~ Field Name i ~

1 2 3 4 5

I

i-"~~~

~ ! !
-8 ~
~is en-'·M~~i~§~~~
i ~ ~
:fg.3~~3: ~ JiLfi iii w 0 ~

Field
Name

re

~

~-B-~8«u..8a

9101112131415~617181920212223;

S5~

Saquence
Number I ~

"

~

Review

~ode

til

!

-!:

~o

1234 5

~

~~:at

I~

Enter

5 ~>
c: -g
~ ~ ~ ~ ~! ~ ~ ~

8

1--->
IV

1'1

Sample Applications

5-39

IBM

Second Edition

System/34 Display Screen Format Specifications

Use this coding sheet only to define display screen formats for WSU
and $SFGR. This coding sheet could contain typographical errors.

D

:l

Sequence
Number

.!

§ :.::l~

Starting
Location

u::

~

wsu

E

Field Name

~~

1

2

3

1 I
.~

>
u: wc:
>..:..!=
".2 ! ~
>2

:l

Reserved

Key Mask

1

~
51

3

2

&!

.! ~
g ~
Z

~i
d
8~ I-

~~~

£ ~ ~! ~I )~~

.§

~;t:

co

g

ac:
0

~

~~

a.ii:'E

..,
Q;

d~§ u::

I

T

1

r

Tl T I I 11 II I I I I I I

g
>
.~

~
E 2 ~ "§.

I»oa:

~

/

11

.. c:
w ~

£

..,
Q;

u:

8.

~

~

'"c: ~

1
~

t

c:

~

I!

;3

i,

i

~ ~
~

Reserved

0

Constant Data

"c:

1:

I..

il!1n 111:1&.1 !a'" ~1tc.1'(

--

Dig"

011\ IjlN 1,,11
011: IL~ lilt. Ie
0
0
01F I. ~ inl'!lllJi

I..
bi. I~tlolll
I.
IDifa 1.:;1,

I~

"

II.ID L.I~II I~I' I~IJ
IP.~ 11::11

o.
I.

1.1...

I.. I... ~

o~ I. r., 1,,1,1,

5-40

Inser,
Mode
Record
Identifying
Indicators

~

c:
a:
:l
Z
-

t---r-Field
Length

!

1 2 3 4 5 6

-5
Q;

I
Field
Name

is

Q;

7 8 9 10 II 121314 1516 1718 1920 2122 232 2526 2728 2930 3132 3334 3531 37 J8 3940 4142 ~3 44 4546 4714849 051 5253 5455 657 5859 6061 6263 164 65 66 67 68 6970 7172 73 74757677787980

S

u.

c: c:

"E

Enter
Mode

..,

0

JiJ
Sequence
Number

,,~

~o

123 4 5 6

1

~ >
>"

~..,

~ z
Reserved
.~
u::
>2: ~ i ~ g
e "c: '0 " &.8"c: < .reS
i >§
a
:.::l U ~~
-g
K
?;·E ~
~
15:0
"
"
~
~
3
gu o ~ 5iiil
c:
co co '"
~~~i ~.S! "
u; z.9 ..Ja:
~ 0 &
&!~ ~ ~~ iii
u.
"'wwa: a:ctct

Format
Name

I!

!

iTT

WSU Only

-;:
C
0

GX21·9253- U/M050"
Printed in U.S.A.
"No. of sheets per pad may vary slightly.

I(~ /L L..I)

t1

Inl. I... )

Iv

I~

--

I\'

Iv

I~

I~

Iv

rt'

-)

--

I.

I•. It. i-tlrJ Is

f ; lie Ina III Ie

-)

I- )

lv

Iv

l~

I~

~

l't

I~

i~

~

't

I'W

- 101111

-

IGII'!

1-- -)

-- ->

IC:li Il~lc IDII'I

Idr

~I.

i 11'1 I~I' Ivli Idl.i 1111, \.Fl. II t.!

I,ll

I...

Listings for ZLlBCHNG

The ZLlBCHNG procedure, which allows the user to change the session library
and/or the current menu, contains the following statements:

* PROCEDURE TO CHANGE SESSION LIBRARY
/
/
/
/

/
/
/
/

(ZLIBCHNG)
IFF? 1 F' ?SLIB?'? / PROMPT MEMBER-ZRFM, FORMAT-LIB
IFF ?2? / LIBRARY NAME-?2?, SESSION-YES
IFF ?2? / IFF ?3? / MENU?3?, ?2?
IF ?2? / IFF ?3? / MENU?3?

As shown earlier, ZLlBCHNG issues one display (called LIB), which prompts for
the session library name and the menu name, The following listing shows the
display screen specifications for the display:

GX21·9253·

U/M 050'
Printed in U.S.A.

Second Edition
Use this coding sheet only to define display screen formats for WSU
and $SFGR. This coding sheet could contain typographical errors.

System/34 Display Screen Format Specifications

'No. of sheets per pad may vary slightly.

WSU Only

~t~~
"

i

~

E

~ u:::~ _~
:I

88~~~

Review
Mode

Sequence

~~~:1Ying
Indicators

I-r' ]

g.

Reserved

VI

""~

Inser,
Mode

~~~:1Ying
Indicators

Reserved

Key Mask

J

~ ]'i i i Iii

l ~ ~ ~ j

1
2
3
1
2
3
cc
28293031323334353/ 3738394( 4142 344454647108 4~Is05152535455S6S758S96061626364656667686970 7112 73 747576 77 781980

~

I

I

I

I I I

I I I I 1'1

, I I , , ,

I I

Starting
Location

Field
Name
Sequence
Number

Field'~

~

!

I-

I

2 3

-g

4 5 6

1l~

WSU

ii

CIl

Field Name

Length

~
~~

7 8 9 1011 121314 IS 16 17 18 19202122 23 2 2526

0" •

11I1tJ!1nI1.

o __

>
:=c:

.8 11.
! ~ »
5 .~o_c: s,. 0~ 8~
0).2
Z
i~
S :r: ~] i :E:E
Jf'{

LLW

2829

~

U

"

0.
::I

c

0

~

)

0

323 34

8.

>

i

~·_~c ~>~ Oo)~
..
u: ~
c ~
~~~1Q)~ct

i

iii

z

~

:J8

Reserved

.~

5

Constant Data

~

....

c::

'E

c

8

81234~6789101112131415161718192021222

3738 3940 41 42~3 44 45 46 47 46 4950 5152 53 ~4 55 56 5758 59 60 61626364 65 66 67 68 69 70 7172 73 74757677 78 79 80

Y

~.

I.

-

~~~I<~nl~

II

_IA

1rJ1Llu..~~·L'I·'7It!II,'
,Ill. q ~
~

I'
II ... '"I

~1tI.1~IQ II ~II QI~

o
o

Sample Applications

5-41

CREATING DISPLAY SCR'EEN FORMATS
To create the display screen formats used in this example, you could select
item 1 from the TESTM menu. All display screen formats used by one
program must be placed in a single display screen format load member. For
RPG II programs, the member name must be the name of the program
followed by the characters FM. If you select item 1 from the menu, you will be
prompted for the name of the program that uses the formats. If you enter
OROHOR, the following command statement is generated:
SOA OROHORFM,TESTLlB,OROHORFM
When the SOA menu appears, you could select option 1 and then enter an N
for the column indicator mode so that the first line on the screen can be used.
Using the screen formats designed earlier, enter the information from the
screen layout sheet onto the SOA blank screen. When the entire screen has
been entered, you can press command key 9.
In this example, the developer would like to be prompted for field attributes;
therefore, an * is entered in front of each input or output field, a c is entered in
front of each constant, and a t is entered after each field.
An alternative method of prompting for attributes could be used by entering a
Y for automatic prompting on the initial SOA menu. For this method, I for
input and E or B for output are used rather than asterisks. SOA automatically
prompts for additional attributes for these fields.
For screen E1 in display screen formatOROSE1, Figures 5-14 and 5-15 show
the screen entry and attribute screens.
For screen E2 in display screen format OROSE2, Figures 5-16 and 5-17 show
the screen entry and attribute screens.
For screen E3 in display screen format OROSE3, Figures 5-18, 5-19, and 5-20
show the S specification, screen entry, and attribute screens.
Figure 5-21 shows the $SFGR output generated when screens E1, E2, and E3
are built. All the display screen formats used by the OROHOR program are
built in one SOA run.
If changes are later required to formats that have been built, you can use the
SOA update function to make changes. This function allows you to use SEU to
make changes and automatically regenerates formats. An alternative method of
changing formats is to use SEU directly and then use the FORMAT procedure
to regenerate the formats.
Because the next program, OROITM, uses screens E1 and E3, which were
designed already, only screen E4 is created. Figures 5-22, 5-23, and 5-24
show the S specification, screen entry, and the attribute screens for screen E4.
The specifications for screens E1 and E3 are included using SEU. Figure 5-25
shows the $SFGR output generated when the display screen formats used by
OROITM are built.

5-42

E1
ORO ERE N TRY

CUSTOMER NUt16t:R
ORDER NUMBER

xxxxxx
xxx XXX

- or -

Press ENTER REC/ADY

CK1 - TO EtHER MISC ORDER INFO
CK7 - CANCEL ORDER ENTRY

Mt-'Mt-1t1t1MMt1MMMHHMMHMMHt1MMMMMMtlHMMMMMMM~'MHMMMMr1MMt1M

Figure 5-14. Screen Entry for Screen E1

*Elt
*0 R D ERE N T R Yt

cCUST0I1ER HUMBERt

*XXXXXXt

cORDER HUMBERt

*XXXXXXt

cPress ENTER REC/AOY

- or -

CKI - TO ENTER MISC ORDER INFOt

cCK7 - CANCEL ORDER ENTRYt
MMMMMMMMr-1Mr1MMMMHt1t1MMMMMMMMMMt1Ht1MMMHt111Ht1l1HHHt1MMHM t

*

Figure 5-15. Attribute Screen for Screen E1

Sample Applications

5-43

E2

o R D ERE N TRY
CUST NO

XXXXXX

ORDER NO

SOLD TO XXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX XX XXXXX
CUST PO XXXXXXXXXX

XXXXXX
SHIP TO XXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXX XX XXXXX

SALESMAN NO XX

Figure 5-16. Screen Entry for Screen E2

*E2t
*0 R D ERE N T R yt
cCUST Not *XXXXXXt

cORDER NOt *XXXXXxt

cSOLD TO*XXXXXXXXXXXXXXXXXXXXXXt
cSHIP TO*XXXXXXXXXXXXXXXXXXXXXXXXXt
*XXXXXXXXXXXXXXXXXXXXXXt
*XXXXXXXXXXXXXXXXXXXXXXXXXt
*XXXXXXxxxxxxxxxxxxx*xX*XXXXXt
*XXXXXXXXXXXXXXXXXXXXXX*XX*XXXXXt
cCUST PO*XXXXXXXXxxt

cSALESMAN NO*XXt

Figure 5-17. Attribute Screen for Screen E2

5-44

FORMAT NAME
WSU FORMAT 10
START LINE NUMBER
NUMBER OF LINES TO CLEAR
LOWERCASE ALLOWED
RETURr~ INPUT
RESET KEYBOARD
SOUND ALARt1
ENABLE FUNCTION KEYS
BLINK CURSOR
ERASE INPUT FIELDS
OVERRIDE FIELDS
SUPPRES INPUT
KEY MASK

STARTPRIORITYRECORD 10 1INSERT 10 1-

ORDSE3

ENABLE COMMAND KEYS
99

****** WSU ONLY *******
ENTER MODE SEQUENCE
ENDREQUIREDREPEATPREPROCESSREVIEW MODE INDICATORS
RECORD 10 2RECORD 10 3INSERT MODE INDICATORS
INSERT 10 2INSERT 10 3-

Figure 5-18. S Specification Display for Screen E3

E3
ORO ERE N TRY
CUST NO

XXXXXX

ORDER NO

SOLD TO XXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX XX XXXXX
CUST PO XXXXXXXXXX
LINE

ITEM NO

01

XXXXXX

QTY

XXXXXX-

XXXXXX

SHIP TO XXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXX XX XXXXX

SALESMAN NO XX
DESCRIPTION

XXXXXXXXXXXXXXXXXXXX

MHM~1t"1MI'1HI'11'1~1mtl'lMMMHl'lMMMl'fMHMMHMMMHt1MMMHl'lHMMMMMMMM

PRICE

AMOUNT

XXXXXXX
XXXXXXXXCK2 - END OF ORDER
CK3 - PAGE BACKWARDS ON ITEMS
CK8 - CA~~CEL THIS ORDER

Figure 5-19. Screen Entry for Screen E3

Sample Applications

5-45

*E3t

*0 R D ERE N T R yt

cCUST Not *XXXXXXt

cORDER NOt *XXXXXXt

cSHIP TO*XXXXxxxxxxxxxxxxxxxxxxXXXt
cSOLD TO*XXXXxxxxxxxxxxxxxXXXxXt
*XXXXXXXXXXXXXXXXXXXXXXt
*XXXXXXXXXXXXXXXXXXXXXXXXXt
*XXXXXXXXXXXXXXXXXXXXXX*XX*XXXXXt
*XXXXXXXXXXXXXXXXXXX*XX*XXXXXt
cCUST pot*XXXXXXXXXXt
cLINE

ITEM NO

QTY

cSALESMAN NO*XXt
DESCRIPTION

PRICE

AMOUNTt

*Olt *XXXXXXt *XXXXXX-t *XXXXXXXXXXXXXXXXXXXXt *xxxxxxxt *XXXXXXXX-t
cCK2 - END OF OROERt
cCK3 - PAGE BACKWARDS ON ITEMSt
MMt1NMMMHMHMMHMMH~1HMNMNNNHMMNNNNNt111M~fNH~1t1t1~lMt1t1MMt cCK8 - CANCE L TH IS ORO ER t

Figure 5-20. Attribute Screen for Screen E3

5-46

SOURCE

INPUT SCRE~N FJRMAT

S~~RCE

Ou~200SC:)OE

000300T ITLE
OO~4'lOFLOOO3

000500CUSNO
000600FLOO05
OOC7000RONO
000!lOOFLOO07
000900
00 I OOOFLOO08
OOllOOV
OO12~LlERRMSG

SPECIFICATIJ~S

JATF

02/12/19

TI"Ie

08.34

99

OOOlOSOROSEI
00020103Y
00210231V
00150511Y
OOOo0531V
OO120711v
00060731 V
0;)702011 V
CKl
00242£'HY

~El

CO ROE R
t ~ T R Y
CCuSTOMER -"U"IBt:R
V ZV
COKDER IIIU14SER
V f>
-

TO ENTER 141 SC L.lRDER

004d230199

~~C/AOV

CP

ENHR

::; CK7 -

CANCEL JRJER ENTRX

INFO

99

EXECUTION TI"'E OUTPUT BUFFER JESCRIPTION
FIEUl
NA14E

LFN:;TH

CUSNO
ORONO

b
48

ER~MSG

START
PJSITION

POSITIJN

I
7
13

b
12
60

E~D

INPUT EWFFEo< DE SCR I Pi! ON
F'IELD
NA'-'E

LENGTH

STAR T
POSITION

E'W
POSITION

SCODE
CUSNO
ORONO

SOURCE

14

INPUT S:REEN FJR."IAT SJURCE SPECIFICATILlNS

OO130S0ROSE2
OOl'tODSCODE
OO150DTITLE
OO160DFLOO03
OO170DCUSNO
OO180DFLOOOS
OG 190DORDNO
00200DFLOOO7
00210DCNAME
002200FLOOO9
00230DSNAME
00240DCAODR
00250DSADOR
002600CC lTY
002700CSTATE
00260DCZIPCO
00290DSClTY
003000SSTATE
003100SZIPCO
003200FLOO19
D03300CPONO
003400FLOO21
003500CSLSNO

, F2
~O R '1 E R
CCUST NO

00020103Y
00210231Y
0OO7040oY
00060410V
00080431V
OOOb0442V
OOC70603v
0025C'611Y
0007004.2Y
002SC'650V
00250711 Y
002S0750V
00220811 V
00020834V
00050837V
00220650V
00020873Y
00OS087bV
0OO7l003Y
00101011Y
0011102bY
0002103BV

E N TRY

V Y
COR)~R

"10

V V
CSULD TO
Y Y
C SHIP TO
V
V Y

V Y

CCUST PO
(SALESMAN "l0

EXECUTIO"l TIME OUTPUT BUFFER LlESCRIPTION
FIELD
NA"'E
SCOOE
CUSNO
ORONO
CNAME
SNAME
CAODR
SAOOR
CCITY
CSTATE
CZIPCO
SCtTY
SSTATE
SZIPCD
CPONO
CSlSNO

LEN:;TH

0
b
25
25
25
25
22
2

5
22

2
5
10

2

START
POSITION

E"IO
POSITION

I
3
9
15
40
b5
90
115
131
139
144
Ib6
168
173
163

14
39
64
89
114
13b
138
143
165
161
172
182
184

START
PtJSITION

E"ID
POSITIJN

INPUT RUFFER OESCiUPT ION
FIELD
NA"E
SCODE
(USNO
ORONO
CNAME
SNAME
CAODR
SAOOR
CCITY
CSTATE
CllPCO
SC lTY
SSTATE
SZIPCO
CPONO
CSLSNO

LENGTH

1

3
b
25
25
25
25
22
2
S
22
2
S
10
2

9
15
40
65
90
115
137
139
144
Ibb
1b8
173
183

2
8
14
39
64
89
114
136
13t!
143
165
167
172
182
184

Figure 5-21 (Part 1 of 2). $SFGR Output for Display Screen Formats Used by ORDHDR

Sample Applications

5-47

SOURCE INPUT S:REEN cORM4T SOuRCf SPECIFICATIONS
00360S0ROSE3
003730SCOOE
003800TITLE
003900FL0003
004000C USNO
004100FL0005
0042000RONO
004300FL0007
004400CNAME
004500FL0009
004bOOSNA ME
004 700C 400R
004800SAOOR
004900CCITY
005000CST4TE
OO'HOOClIPCO
005200SCITY
005300SSTATE
005400SlIPCO
005500FL0019
005600CPONO
005700Fl0021

DATE

99

00020103Y
00210231Y
00070406Y
00060416Y
00080431Y
00060442Y
00070603V
00250611Y
00070642Y
00250650Y
00250711 Y
00250750Y
0022J811Y
00020834Y
00050837'1'
00220850Y
00020873Y
00050876Y
00071003Y
001010llY
001llJ26v
005800CSLS~O
00021038Y
005900FLOOOI
00651203'1'
006000 DESCRIPTION
OO!>100ELlNE
00022003Y
OOb200ITEMNO 00062008'1'
0063300 TY
0006201 ]V
0064003ESCR
00202026Y
006500PRICE
00062049'1'
00663DAMDUNT 00082059Y
006730FLOOOB 001tl2150V
006800FL0009 00292250Y
006900 ITEMS
007030ERR MSG 0048230199
007100FLOOIl 00232350Y

CF3
CO ROE R
CCUST NO

E "I T R Y

Y Y
(ORDER NO
Y Y
(SOLO TO
Y Y
(SHIP TO
Y Y
Y
Y Y
Y 'I'
Y 'I'

CCUST PO
~SALESMAN

(LINE
PR IC E

~O

IHM NO

OTY

AMOJNT

BY

CCI(2 - ENO OF QRDER
C(K3 - PAGE 8ACKWARDS ONX
99
((K8 - CANCEL THIS OROER

EXFcurrON T I ~E OUTPUT BJF FER llFSCIHPTION
F P'LD
NA~E

LfriGTH

CUSNO
ORaND
CNAME
SNAME
CAOOR
SAOOR
CCITY
CSTATE
CllPCO
SC ITY
SSTATE
Sll PC 0
CPONO
CSLSNO
ELINE
ITEMNO
OTY
OESCR
PR I (E
AMOUNT
ERRMSG

STAR T
POSITION

Ef'lD
POSITION
6

6
25

25
25
25
22

2
5
22
2
5

10
2
6
20
48

7
13
38
63
88
113
135
137
142
164
166
171
1 III
183
185
191
197
217
223
231

12
37
1>2
87
112
134
136
141
163
165
170

180
182
184
190
196
216
222
2 ~o
278

INPUT BUFFER tJfSCRIPTION
FIELD
NA'IE

LEt~GTH

SC:JDE
C:USNO
ORDNO
CNAME
SNAME
CAOOR
SAODR

l.
6
6
25

CCITY
CSTATE
CII PC 0
SCITV
SSTATE
Sll PC 0
CPOND
CSLSNO
ELINE
ITEMNO

22

OEseR
PRJ C E
AMOU'IIT

20
6
8

ORO-tlJRF"

1S

'to
65
90
115
137
139
144
Ib6
168
173
183
185
167
193
199
219
225

2

b

FORMAT UROSEI
FCJR:~~ r OROSE2
FORMAT OROSE3

9

25

5
U.
2
5
10
2
2

SCREEN

1
3

25
2?

ory

START
POSITION

FOr<~AT

Ri:.OUJRE)
REOuIRF.S
ReQUIReS

E~O

POS! TION

,

8
14
39
64
f!9
114
136

138
143
165
167
172
182
184
186
192
19t1
218
224
232

LUAD MEMBER
512 ~YES JF srORA('E
7~8 BYTES OF STORA('F.
1024 8YTES OF STORAGE

Figure 5-21 (Part 2 of 2). $SFGR Output for Display Screen Formats Used by ORDHDR

5-48

02112179

TI"e

08.34

FORHAT NAME
FaRHAT 10
START LINE t~UMB'ER
NW~SER OF LINES TO CLEAR
LOWERCASE ALLOWED
RETURN INPUT
RESET KEYBOARD
SQu~m ALAR!'!
EN~BLE FUNCTION KEYS
BLIt~K CURSOR
ERASE INPUT FIELDS
OVERRIDE FIELDS
SUPPR~S IHPUT
KEY NASK
~SU

STARTPRIO~ITY-

RECORD 10 1INSERT 10 1-

ORDSE4

v

ENABLE COMMAND KEYS

****** WSU ONLY *******
ENTER MODE SEQUENCE
ENDREQUIREDREPEATPREPROCESSREVIEW HaDE INDICATORS
RECORD 10 2RECORD 10 3INSERT NODE IUDICATORS
INSERT 10 2INSeRT 10 3-

Figure 5-22. S Specification Display for Display Screen E4

xx xxxxxx

xxxxxx- xxxxxxxxxxxxxxxxxxxx

XX,XXX.XX

XXX,XXX.XX-

Figure 5-23. Screen Entry for Display Screen E4

Sample Applications

5-49

,.
*XXt*xxxxXXt *xxxxxx-t *XXXXXXXXXXXXXXXXXXX*XX,XXX.XXt*XXX,XXX.XX-t

Figure 5-24. Attribute Screen for Display Screen E4

5-50

SOURCE I~PUT SCREEN FJ~~AT SOURCE S~ECIFILATIO~S
00C10S0R~SEl

0002:JOSCOOE
00030iH ITlE
00040L>FLOO03
OJ0500CUS,,"0
000600FLOO05
0007000RO'l0
0008:JOFLOO07
000900
DO 1 J.DOF L 0008
001100Y
0012DOERRMSG
0013 0*

EXECUTIO~

F 11'LD
NA"'E
CUSNO
ORON!)
ERRMSG

JATF

02/1£/7'1

TIME

Ofl.33

99
00020103Y
00210231V
0Ol,0,11V
00060531V
00120711 V
00060731V
00702011 V

::1'1
CO ~ D E ~
E 'IJ T
lCUSTOMFR NI)MBeR

~

V

V ZY
CORDER

~UMBEK

CP

E'-HER RE:C/AOV

CCK7 -

CANCEL ORuER E"JTRX

V B
CI(I

-

TO ENTER 'H SC u~DE"

I"IFO

002'tU51Y
99

0041:1230199

TiME OUTPUT qJFHk JESCIUPTION

LE'NGTH

START
POSITION

END
POSITIJN

1
7
13

6
12
60

START
POSITION

E'lO
POSITIJN

b

48

INPUT BUFFER DESCRIPTIO:;
FIELO
NAME
scaDE
CUSNO
ORONO

LENGTH
2
6

2
8
14

SOURCE INPUT SCREEN FORMAT SOURCE SPECtFICATIJNS
00140SJRDSE3
OO1500SC.00E
00020103Y
00160DTITU:
00210231V
00011')406Y
00110DFLOO03
001600CUSNO
00060 .. 16Y
00190DFLOO05
00080431Y
0020DOORDNO
00060442Y
00210DFLOOC1
00070603Y
OG220DCNAME
00250611V
OJ230uFLOO09
00010642Y
OOZ .. ODSNAME
00Z50650Y
OOZ 50DC ADDR
0025011lY
00250750Y
OOZ60DSAODR
002700CCITY
00220811Y
00280DC.STATE
00020834Y
00Z900ClIPCD
00050837V
003000SC I TV
D0220850V
00310DSSTATE
00020d73Y
00050876V
0032DOSlIPCO
00)30DFLOO19
00071U03v
00340DCPONO
00101011 Y
00350DFL0021
00111026Y
00360DCSLSNO
00021::J38Y
00651203Y
0031 DFLOOOI
0038 0 DESCRIPTION
00022003V
0039 DELI NE
0040 01 TEMNO
00062008Y
0041 DQTV
00062017Y
0042 DDESCR
OQ2U2026V
00062049Y
0043 OPRICE
V
Y
0044 DAMOUNT
00082059Y
0045 OFLOO08
00182150V
0046 OFLOO09
00292~50V
0047 D ITEMS
0048230199
0048 DERRMSG
0049 OFLOOll
00232350V
0050 0'-'

99
CE3
CO ROE R
CCUST NO

E N T

~

Y

Y Y
CORDER NO
Y V
CSOLO TO
V V
C SHIP TO
Y Y
V
Y V
V Y
Y V

CCUST PO
C.SALESMAN NO
CLINE

ITEM NO

CCK2 CCK3 -

END OF QRQER
PAGE BACKoiARDS ONX

ceK8 -

CANCEL THI S ORDER

OTY

AMOUNT

PRICE

By
V
V
V

99

EXECUTION TIME OUTPUT BUFFER DESCK I P TI ON
FIELD
NAME

LENGTH

START
POSITION

CUSNO
ORD~O

CNAME
SNAME
CADDR
SADDR
CCITY
CSTATE
ClIPCD
SC.ITY
SSTAlE
SlIP(D
CPIJNO
CSLSNO
ELINE
ITEM"IO
OTY
DESCR
PRICE
AMOUNT
ERRMSG

I'>

7

25
25
25
25
22

13
38
63
81'
113
135
137
142
1b4
166
171
Ull

~

5

22
2

:>
10
2
l.
6
I'>

20
6
6
48

un

185
191
191
217
223
231

E"JD
POSITION
6
12
37
62
87
112
134
136
141
163
165
170
180
182
184
190
196
216
2Z2

230
276

Figure 5-25 (Part 1 of 2). $SFGR Output for Display Screen Formats Used by ORDITM

Sample Applications

5-51

!i'

25
25
25
25
22

cerTY

eSTATE
elIPCD
seITY
SSTATE
SlIPeD
(POND
eSLS'IIO
ELINE
I TEMfIIO
OTY
OESeR.
PRICE
AMJU'IT

15
40
65
90
115
137
139
144
,166
168
173
183
185
Itl7
193
199
219
225

2

:;

22
2
IJ
2
2
6
6
20

SOUR:: E I'IIPUT SCREEfII FOR.,'1AT
00510S0RDSE4
00520DLlNENO
00530DCUSNO
005400QTY
005500QES(R
00560DPRleE
005700AMT

SOURCE

SPF.C IFIeATIOfllS

V
00020103Y
00060107Y
00070116V
00200126V
00090147V
00l10158V

EXEeUTIOfll T II.lE OUTPUT BUFFER JESeRIPTION
FIELD
fIIA"E

LENGTH

LINi:roJO
CUSNa
OTY
OESeR.
PR ICE
AMT

START
POSITION

EroJD
POSITION

9
16
36
45

35
44
55

6
7
20

9
11

8
15

S:;R.EEN FOR'lAT LOAD MEMBER

FORMAT ORDSEI
FORMAT OROSE3
FORMAT ORDSE:4

REQUIRES
REOUIR~S

RE QU IRE S

512 BYTES OF STORAGE
1024 BYTES OF STORAGE
256 BYTES OF STORAGE

Figure 5-25 (Part 2 of 2). $SFGR Output for Display Screen Formats Used by ORDITM

5-52

CODING THE PROGRAMS

Coding with RPG II
After the display screen formats are generated, you can use SDA to generate
the RPG II specifications for the formats. To do this, select item 1 from the
TESTM menu and enter the program name (for example, ORDHDR). Select
option 8 on the SDA menu. Enter RPG for the type of program and the
control specifications. Figure 5-26 shows the SDA entries required to build the
ORDHDR program. After SDA generates the program, use item 20 from the
TESTM menu to list the program. Figure 5-27 shows the ORDHDR RPG II
program generated by SDA. You can follow the same procedures for the
ORDITM program. Figure 5-28 shows the ORDITM RPG II program generated
by SDA.
The file specifications are entered next. By executing item 4 from the TESTM
menu, all the file specifications are entered under the name FILES. Figure 5-29
shows a listing of each of the file specifications. SEU will be used to copy the
file specifications needed into each RPG II program.
Modular programming is used. That is, the program is modified to set on the
proper indicators in the input and output specifications, and subroutines are
also set up. The detail calculations will be added later. Using the program
flowchart, basic program functions are easily identified.
It is easier to test and debug a smaller program than a larger one. If possible,
do not code all functions into the program without testing parts of it. Use
comments in the program to make testing and maintenance easier.
Figure 5-30 shows the ORDHDR RPG II program partially coded.

SDA NENU

ENTER THE NUl'lBER ASSOCIATED WITH THE OPERATION YOU WOULD
LIKE TO PEFORM:
1 CREATE A NEW $SFGR/WSU SOURCE MEMBER
2 ADD TO AN EXISTING $SFGR/WSU SOURCE MEMBER
3 UPDATE AN EXISTING $SFGR/WSU SOURCE MEMDER
4 DISPLAY THE FORnAT IN AN EXISTING $SFGR 08JECT I'tEr'!8ER
5 DELETE A FORMAT FROM AN EXISTING $SFGR/WSU SOURCE MEMBER
6 UPDATE EXISTING $SFGR/WSU SOURCE STATEMENTS VIA SEU
7 BUILD A MENU INTERACTIVELY
8 BUILD WSU PROGRAM OR RPG II SPECIFICATIONS FOR WORKSTN FILE
8

COL IND MODE? ENTER Y OR N. DEFAULT IS Y...................
WSU FORt'I;.\T rlH!8ER? ENTER Y OR N. DEFAULT IS
AUTOMATIC PROMPTING? ENTER Y OR N. DEFAULT IS N.............

N...............

Cmlt'fAND FUNCTION KEY 7

Y
N
N

TO END JOB

Figure 5-26 (Part 1 of 3). SDA Entries for Generating ORDHDR RPG II Program

Sample Applications

5-53

ENTER RPG OR WSU •••••••• RPG

Figure 5-26 (Part 2 of 3). SDA Entries for Generating ORDHDR RPG II Program

CONTROL SPECIFICATION ENTRIES
NUt~8ER

OF

fOR~lATS •••••••••••••••••••••••••••••••••••••••

NAI-l:: TO CALL RPG SOURCE MEt~8ER •••••••••••••••• ~ •••••••••
WO~KSTN

05
02DHDR

FILE DESCRIPTION ENTRIES

NAME OF HORKSTN FILE ••••••••••••••••••••••••••••••••••••• SCREEN

RECORD l.H!GTH FRm1 $SFGR CUi PUT ••••••••••••••••••••••••• ~ 1000
NU~i3ER OF DISPLP,,( STATlmlS •••••••••••••••••••••••••••••••
NW1GER C;= INDIC;.\ TORS TO Sj\VE •••••••••••••••••••••••••••••
NA~jE OF DATA STRUCTURE TO SAVE •••••••••••••••••••••••••••
/tAME OF FIELD Cm-·lTAHUNG vt,~~I/.sLE START LINE NUi'13r:R •••••

tPJ1E OF FIELD CmHAINING DIS?Lt,Y STATION 10 ••••••••••••••

NAME OF FORMAT LOAD MEMBER ..••••••••••..•....•..•..•..••.

Figure 5-26 (Part 3 of 3). SDA Entries for Generating ORDHDR Program Header (H) Specification

5-54

TESTlU
TYPE

MEM!lEIl

''lAI4E
JROHOR

JU E
[)lSI(

AOO~

3771>171)5:311

03/09179
TJUl

TIME

llo17

N:lM TEJ(f/RECORJ

05

H

FStREEN CP F·
100)
ISCIHEN
100 FORMAf- JROSEl
I
I

UHIBUTES
))J;)O)

80/5:)

710007

LI'H 40JII/'lJIiI STIilT

'HJ olSP

ENTitV AJ)R

I>~'):;

SIZE

MRT lEVEl

88/0058
ORO-iOR

"ORI(ST~

00010002 StJOE
00030008 CUS,'lO
00090014 :)ID 'I 0

I
100 FORMAT- OROSE2
I
I
I
I
I

I
I
I
I
I
I
I
I
I
I

00010002
00030008
00090014
00150039
0040006"
00(5)089
00900114
0115)136
0137:)139
01390143
0144Jl1>5
01U:Hb7
01b80172
0173J182
0183J184

StOOE
CUS'lO
)R)'lO
tI'llA'fE
SI'II4ME
tAOH
SADoR
tCITY
tSUTE
tllPCO
SeITV
SSUTE
SlIPCO
:PJ'lO
CSLS,.O

00010002
000300')9
00090014
00150039
0040;)J"4
00"50089
00900114
0115;)136
0137013B
01390143
ollt1t:) 165
01b"J1&7
01bB;)172
0173)182
0183;)184
018501U
0187:lU2
01930U8
01990218
02UJ224
0225,)232

SeJOE
CUSNO
OR J:o.I 0

It FORMAT- !lRDSE3
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I

I
I
I
OStREEN

o
o
o
o
o
a
a
o
o
o
o
o
a
o
o
a
o
o
a
o
a
a
o
o
Q
o
o
a
o
o
o
o
a
o
o
o
o
o
o
o
o
o

99

(US'lO
ORD'40
ERRI4SG
scaOE
CUSIIO
JRO'40
CNAME
SNAIilE
(AODR
SADDR
(CITV
CSUTE
(ZIPCD
SClTv
SSTAfE
SZIPeD
CPOIIO
(SlSNO

99

(USIIIO
ORO'40
CNAIiIE
S,.AIiIE
(AOOR
SAODR
(CITV
eSTATE
(ZlP(D
SCITV
SSTAlE
SZIP(O
: POliO
( SlSNO
ELIIIIE
I T.,"INO
;,)TV
OES::R
PRI :E
AMJJ'4T
ERRIiISG

C~4"E
S~AIIIE

::ADJR
SADJII
C(In
:SUTE
ClIPCO
seITv
SSTATE
SlIPCO
CPO'40
CSLS,.O
EL l'4E
ITEIilNO
:ITV
OES:R
PRICE
, .. :lUIIIT

K.8 'O~OSE1
0001>
0012
00&0
K.8 ")RJSE2
0002
OOOB
0014
0039
00&4
0089
0114
013&
0138
0143
'Olb5
01b7
0172
0182
0184
I(B "aRDSEJ
0006
0012
0037
0062
0087
0112
0134
o 13b
J1ltl
o1ttl
o lb5
J17)
0180
;)182
J184
0190
019b
J216

JZ22
0230
J278

Figure 5-27 Listing of ORDHDR RPG II Program

Sample Applications

5-55

TESTLHl
TYPE

MEMBE~

ilfAME

DATE
O[SK

OROITM

AO()~

02112179
TJTAl

6b 328/:>1 0318

TI"'''

5/000S

80/S0

H
FSCREE~

CP

1000

.. ORI(ST~

F

ISCREEili
FORMAT-

I~

0001000Z SCDGE
00030008 CUSNO
00090014 ORONO

1

FORMAT- OROSE3

1

0001000Z
00030009
00090014
00150039
004000b4
00b'50089
00900114
01150136
01310138
01390143

I
1
I

1
I
I
I
I
I
I
I

014401b5
01b601b7

1

01be0172
0173018Z
01830184
01850186

I

I
I
1
I
1
1
1
I~

J181019Z

01930198
019902111
OZ190224

FORMAT-

02l'50232

O~OSF4

uSCREE~

o
o
J
o
o
o
o
o
o
o
o
o
o
o
J
o
o
o
o
o
o
o
o

99

CNAME
S'IA"E
eAOOR

K8 ·OIlOSE 1
11006
0012
OObO
1\.8 'UROSE)
0006
0012
0031
0062
0087

SAOD~

011Z

CCITY
eSTATE
(,Z[peD

0134
0136
01 .. 1
0lb3

CUSt-.lO
ORL)t-.lO
ERR"'SC;
eust-.lo
ORIl~O

~(ITY

SSTATE
5Z [peD
CPOilfO
eSLSNO
Ellt-.lE

L INE':~O
CU~t-.lU

000'1

TE'I'~n

.,TY
(JESC"
PRice
A"'OlJ"IT

o
99

ERi\'1~G

U

o

o
o
u
u
(J

01bo;

0170
0180
QUI2
0184
0190
0196
,,216
J2.2?
0230
0278
KA 'JII JSE4
OO;)?

I

lJ

J

... TV'

Jf)C"
PRICE:
AliT

001'!
00)0;
JOlt"

JOS'!i

Figure 6-28. Listing of ORDITM RPG II Program

5-56

os

~KOSEI

1

ATTRIBUTES
000000

KSl~

I
I~

08.3[1

NUM TEKT/RECORJ

SCOOE
CUSNO
ORO~O

(NAME
SNAME
CAOOR
SAODR
CCITY
CSTATE
CZIPCO
SCITY
SSTA TE
SZI;>CO
CPOIllO
CSlSIllO
elINE
ITEMNO
:JTY
OESCR
PIHCE
AMOulllT

l111fK

AOOR/~UM

65/0041
OR')ITM

SllNE

STMT

RLO O[SP

ENTRY AJ)R

PRO; SIZE

MRT lEVEL

TESTLl8

FilES
0001
0002
0003
0004
ODDS
OOOb
0001
0008
0009
0010
0011
0012
0013
0014
0015
001b
0017
0018
0019
DOlO
0021
0022
0023
0024
0025
002b
0027
0028
0029
0030
0031
0032
0033
0034
003;
003b
0037
0038
0039
0040
0041
0042
0043
0044
0045
004b
0047
0048
0049
00;0
00;1
0052
005)
0054
0055
OOSb
00S7
0058
OOS9
OObO
OObl
00b2
00b3
00b4
00b5
OObb
00b7
00b8
00b9
0070
0071

DATE

MEMRER

F 12E1 128R bAl
F 128 128R bAl
F 128 128R bAl
F 128 12AR
F 128 128R
2 C.A
1 c."l
11

lZ

13

1 C.S

1 C.I

2 CA

Z CT

CS

rT

ATTRIBUTES

9blbO

000000

lll'iK AOi)R/"lUM ST"'T

RlO 01 SP

El'iUY

Ai)~R

PROG SHE

"'RT lEvEL

1110Q41

4 01 SK
4 IlISK
DISK
01 SK
3 C
1
3
4
10
3S
bO
1J2
84
89

2 CREC.C.O
3 CORET
90CUSNO
34 C.NAME
59 CAOOR
81 CCITY
83 CSTATE
880ClIPCO
900C.SlSNO

1
3
4
10
)5
bO
8Z
84

2 SRECCO
3 SOElET
90SC.USl'iO
34 SNAMf
59 SAOOR
1J1 Sc.tTY
83 SSTATE
880SllPCD

1
3
4
10
)0
34

2 IRECCD
3 10ELET
901TlilNO
29 IOESCR
3321pRICE
38 1"'4l0C.

1
3
b
9

2 ORECC.D
;ORR/a
80RR::2
110Rk::3

3 C

3 C

01

15

1 C.C

Z c.u

3 C.
1
2 ORECCO
3 ODELET
3
4
90CUSl'iO
10 l;OOROl'iO
lb 40 CNA .. E
1t1 b; C.AOIlR
bb 81 CCITY
88 89 CSTATE
90 940C.lIPCO
9; 9bOCSlSNO
97 lOb CPONO

1b

17

I

1
I
I
I
I
I
I
I
I
I

11.51

4 DISK

I

I
I
I
I
I
I
I
I
I
I
I
1
I
I
I
I
1
I

U"E

NUM TEXT/RECORD

7/0007

221871t/0lb2Al

FCMAST
IC
IC
FSMAST
FIMAST
Uc.
Uc.
FTRANS
FTRANSlO:;UC
lolA
IC.MAST
I
I
I
I
I
I
I
I
I
SA
ISMAST
I
I
I
I
I
I
I
I
IIMAST
IT
I
I
I
I
I
I
ITUNS
au
I
I
I
I
CU
I
I
I
I
I

12129118
TUTAl

DISK ADDR

'\!AlliE

TYPE

1 C.C

1 C.I

2 CS

2 CT

) C
1
3
4
10
1b
41
bb
88
90

2 RODE
3 ODELET
90CUS'IO
l;OOROHO
4:! SNAME
b5 SADDR
87 SC tTy
89 SSTATE
940SllPCO

1
3
4
10
1b
18
24
44
50
5b
b4

2 ORECCO
3 ODELET
90CUS'l0
15QORONO
1100LlNE
2301T"l'lO
43 IOfSCR
4900,jTY
SS20pIHCE

) C.

b320A~T

b8 II'I'4LOC.

18

Figure 5-29. Listing of File Specifications

Sample Applications

5-57

TESTllfl
TYPE

DROHOR

DATE

MEMflE~

221881/0362f19

17.57

NUM TEXT/RECORD

17/0011

96/60

H
F SCREEN
1000
CP F
FCMAST
Ie F 128 128R 6AI
F 128 lZ!lR 6AI
FSMAST
IC
F 128 lZ8R
FTRANS
ue
MA
1 CM
2 CA
ICMAST
11
I
I
I
I
I
I
I
OOH I
0015 I
2 CA
12
0016 ISMAST
SA
1 es
0017 [
0018 ,I
0019 I
0020 I
0021 I
0022 I
0023 I
0024 J
0025 ITRANS
01
0026 I
0027 I
0028 I
0029 J
0030 I
Cu
15
1 CC
2 CU
0031 I
0032 I
0033 I
0034 I
0035 I
0036 I
0037 I
0038 I
0039 I
0040 I
0041 I
16
0042 I
CS
1 ec
2 CS
0043 I
0044 I
0045 I
00'tt! I
0047 I
0048 I
0049 I
0050 I
0051 I
0052 I
IT
17
1 CI
2 CT
0053 I
0054 I
0055 1
0056 I
0057 1
0058 I
0059 I
0060 I
0061 I
0062 I
0063 I
0064 I
III
0065 1(1 FORMAT- JROSEI
0066 ISCREEN
01
1 eF
2 Cl
0067 1
0068 I
0069 I
0070 1(1 FORMAT- OROSE2
0071 I
02
1 CE
Z C2
0072 I
0073 I
0014 I
0075 I
0076 I
0077 I
0078 I
0079 I
0080 I
0081 I
0082 I
0083 I
0084 I
0085 I
008b I
0087 I
10
0088 1(1 FORMAT- OROSE3
0089 I
0090 I
0091 I
0092 I
0093 I
0094 1
0095 1
0096 I
0097 I
0098 I
0099 I
0001
0002
0003
000't
0005
0006
0007
0008'
0009
0010
0011
0012
0013

Tf'oll:

12129/78
TOTAL

DISK AODR

'UME

ATTRIBUTES
000000

05
WORKHN
4 DISK
DISK
4
DISK
3 e

't
10
35
60
82
84
89

CREeco
3 COELET
90CUS'II0
34 CNAME
59 CAO;)R
81 CCITY
83 CSTATE
880ClIPCO
900CSlSNO

1
3
4
10
35
60
82
84

2 SREeco
'3 SOElEr
90SCUSNO
34 SNAME
59 SAOOR
81 SCITY'
83 SSTATE
880SlIPCO

1
3
6
9

2 DRECCO
50RRIH
80RRII2
110RRII3

1

'3

3.'

au

3 e
2 ORECCO
1
3
3 OOElET
90CUS'II0
4
1500RONO
10
16 40 CNAME
05 CAOOR
41
66 87 CCITY
89 CSTATE
88
90 940ClIPCO
95 960CSlSNO
97 106 CPJNO
3 e
1
3
4
10
16
41
66
88
90

2 ReOOE
3 ODELET
90CU Sill 0
1500ROIII0
40 SNAME
65 SAOOR
iH selTY
89 SSTArE
940SllPCO

1
3
4
10
16
18
24
44
SO
56
64

2 ORECCO
3 ODELET
90CUS,'II0
1500RO'll0
1700lINE
230ITMNO
43 10ESCR
4900QTY
5520PRICE
6320A"'T
68 hlHloe

3 C

00010002 se~uE
00030008 CUS'~O
00090014 ORO,'IIO
00010002
00030008
00090014
00150039
00400064
0060;0089
00900114
0115013&
01370138
01390143
01440165
016601b7
;)lb80172
01730182
01830184

SClOE
CUSNO
ORONO
CNAME
SNAME
CAOOR
SAOOR
CeITY
CSTATE
elIPCO
seITY
SSTA TE
SlIPCO

00010002
00030008
00090014
00150039
00400064
00650089
00900114
0115;)136
01370138
01390143
0144;)105

SeJOE
cuSI'lO

CPO,~O

CSlSNO

ORD,~O

CI'lA"le
SNAME
CAO:lR
SAOOR
CCITY
CSTATE
ClIPeo
se lTV

Figure 5-30 (Part 1 of 2). Partially Coded ORDHDR Program

5-58

I I Nf(. AOOR/'h/'" ST"'T
170/00AA
OROHOR

RlO 01 SP

ENTiU AJ)R

PltD:> SIZE

"IRT LE'VEl

0100
0101
0102
0103
0104
0105
')l06
0107
0108
0109
0110
01 LL
0112
0113
011,.
0115
0116
0117
OLl8
0119
0120
'H21
0122
0123
012,.
0125
0126
0177
0128
0129
0130
r) 1 31

0132
0133
0134
0135
('130
0137
'Jl3B
0139
0140
J 141
()L42
0143
014,.
0145
0146
')147
014!l
01,.9
010;0
010;1
010;2
'11 53
0154
0155
010;6
010;7
0156
'Jl59
0160
01bl
01b2
01h3
'H64
0165
0166
0167
0166
0169
0170

01660167 SS TA TE
I
01660112 Sl I PC D
I
01130162 (PO'lO
I
01830184 CSLSNO
I
01850186 EL I:~E
I
01a7019Z ITFMNO
I
01930198 :lTV
I
01990216 OEseR
I
02190224 PRI:E
I
02250232 AMJUNT
I
C* IF SCREEN E 1, STAIH, CHECK FOR CANCEL
EXSR BEGIN
C
01
c.* IF SCRREN E2, IIR ITE REC.JRO ANO SETON LR
EXSR WRITE
02
C
C*
BEGSR
BFG 1'1
C
CUSNO
CHA1/04CMAST
99
C
E'IJ SR
C
C*
WR I TE
l:lEGSR
C.
CHAI'lSMAST
C
C.USNO
21
E'lOSt<
C
C* PUT OUT SCREEN E:l IF SCREEN El OJ AS READ A'lO THEr(E IS A'I ERROR, 99 O·'l
JSCRHN
0
01 99
K8 'ORJSEl
0
0
CUSNO
0006
I)
uRONO
0012
99
J
0060
I~VALlO
0* PUT OUT SCRE EN E2 IF SCREEN El WAS READ ANO CKl WAS PRESSED, KA ON
a
01 '(A
0
K8 'URl)SE2
Q
SCODE
0002
0
cuS'lO
0008
0
URDNO
0014
Q
CNA'4E
0039
0
SNA'4E
0064
CADDR
0089
0
SAD!)R
0114
J
0
CCITY
0136
0
CSTATE
0136
CZIPCD
0143
J
0165
0
0
0167
SSTATE
,)Z I PCD
J
0112
0
CPO'lO
01d2
0
CSLSNO
il184
0'- PUT OUT SCREE'l E 3 WHE'l UN SCREE,'l t: 1 cln WAS NOT PRESSEO, OR FROM E2
01'll(A
0
0
OR
02
0
K8 'UROSE3
J
0
CUS'lO
0006
URO'lO
0
0012
(NA'IE
0037
0
SNA'IE
0062
0
(AOOR
0087
0
SADOR
0112
0
C.ClTy
0
0134
CSTATE
013b
0
Q
01,.1
ell PCD
0163
0
a
SSTATE
0165
SZIPCD
a
0170
CPONO
0180
0
Q
C SL SNO
0182
0164
Ell "IE
0
1 TE'4NO
0190
0
IolTY
0196
0
OESCR
0216
0
PRI CE
0222
0
0230
AMOU'lT
0
99
ERR"ISG
0278
0*

.

sun

sun

Figure 5-30 (Part 2 of 2). Partially Coded ORDHDR Program

Sample Applications

5-59

Coding with COBOL
You can also use COBOL (Common Business Oriented Language) to read data
from and write data to a display station. You define the constants and fields
that appear on the display screen with display screen format specifications.
You can either enter the display screen format specifications explicitly or
generate these specifications by using the Screen Design Aid. COBOL also
allows your program to pass data to and read data from another application
p'rogram through the use of the Interactive Communications Feature (SSP-ICF).
Your program can communicate with a program running on the same
System/34 or with a program running on another system. For more
information on the SSP-ICF feature, refer to Chapter 2 in this manual or to the
Interactive Communications Feature Reference Manual. For more information on
using COBOL to read and write data from a display station, refer to Transaction
File Considerations in the COBOL Reference Manual.

IBM System/34 COBOL-Supplied Procedures
IBM supplies several library procedures for use with System/34 COBOL.
When the operator enters an appropriate command statement, the
IBM-supplied library procedure is either executed or placed on the input job
queue. For information on how to place a job on the input job queue, refer to
the Operator's Guide.
Library procedures provide for COBOL compilation and link-editing, execution
of COBOL programs, movement of a diagnosed source file to a library, and
screen prompts, by using the following command statements:
• COBOL-compile a COBOL program.
• COBOLCG-compile and execute a COBOL program.
• COBOLG':""execute a COBOL program with user-provided procedure for
additional OCL statements.
• COBSYSIN-compile and link-edit a COBOL program entered from the
current SYSIN device.
• COBMOVE-move a COBOL diagnosed source file to a library.
• COBOLP-provide screen prompts for entering, compiling, executing, and
correcting COBOL programs.

5-60

TESTING THE PROGRAMS
To test the programs, procedures are built using SEU. The procedure name to
execute a program is called by the same name as the program.

II
II
II
II
II
II

I'RUhll'T hlt:hloft(-URUH[)Rt-hl,FuRMAT-uRLJ5E:I,PLJATA-VI:S
Lr)A') )KOI1D"
FILE ~AMt;-Ll~"S T "JI ,P-S"R
riLE ~A"'t:-SMAST,UISP-SHR
FILE ~A"'E-TQA'IS,uIS"-5rl~
kU;l

~
II
II
II
II
II
II

ATTR MKTMAA-j
L ':lAO ORD ITM
FILE ~A"'t:-TPA~:),lll,P-SrlR
fiLE ~AM~-TRA~SL~G,JISP-S~"
HLf '1A";:-I"AST.JI>P-Srl~
t(U~

~
II LOAf) Ot(OPRT
II HLF '1A"t;-T~A'I!>LuG,')ISP-:''io{
II k!JN

The entire order entry procedure will be called by the procedure named
ORDERS.

ORDERS

*

RulLO TkANS FILl: IF '1uT

PKF~ENT

II IFF OATAFI-TRA~S f'L:1~ ILf TKA'lS,:J,RcCuRU$,';OO.U8
II IFF UATAH-TKA .. SLO'; oLuFILt TRA~SLuG,D,RtCJRuS,2uDu,128

o FxELUTE OKDcR HcAuEK

PRJ~"AM, AN S~T
Oll.DI101l.
':' TI1F,'l THE LINt ITEM PRcJ(,,,AM, A,~ MRT
0,,01 TM
REL~AS< Trlf Tt~MTNAL A'IU LALL PKI~T PKO~RA"',
II ATTR Rt:Lt:A,E-VcS
OkDPR T
II IF' SoIITCr1\-\ CA'ILfL
I I KE,E T LlRUEKS

*

A~

'1KT

Before executing any procedure, the files used by each procedure must be on
the system. DFU is used to build sample master files. Only a very small
sample is entered.
Because the TRANS and TRANS LOG files are new files, they could be built
using:
BLDFILE TRANS,D,RECORDS,500,128
BLDFILE TRANSLOG,D,RECORDS,2000, 128
These statements are part of the final order entry procedure, ORDERS.

Sample Applications

5-61

Considerations for Program Testing
Program testing is an important factor in the development of your application.
Program testing is the process of running a program with the· intent of finding
errors in the program. By testing your program, you can verify if:
• Your program is correctly accepting input data.
• Your program is correctly processing the input data.
• Your program is generating output correctly, whether the output is a file,
screen format, or a report.
• Your program can handle unexpected and erroneous data.
You should be aware of the following considerations when you begin to test
your programs.

Adequate Time for Testing

Allow. plenty of time for testing your programs. If you have a complex
program, you may need more time than you did to write the program.

Test Schedule and Testing Logbook

Documenting the testing process is important. You should have a written
record of the level of testing that your program was subject to. When you
document your testing, be sure you have, for all cases, a description of the test
data used as· input to the program and a description of the correct output you
expected for the test data. You should also assign some unique identification
to each task in the testing process to aid you in the logging of the testing
process.

Manageable Tasks

Divide the testing process into manageable tasks that proceed from the simple
to the complex in terms of the functions performed in the program. Each task
should build upon the functions of the preceding task. For example, if your
program has to read three different record types, you should test to see if the
program can read one, two, and then all three record types. Generally, the first
task you should perform is an inspection of the code contained in the program
for errors in logic or syntax.

5~62

Appropriate Test Data

Test your programs with data that checks whether the program is correctly
performing its intended functions. In most cases, your program cannot be
tested in a single test because certain functions must be tested individually.
You must also check the way these functions interconnect in your program.
Label your test data for each test, and retain this data for future use in the
event that you have to modify your program due to errors found in it during
testing.
Your test data should cover the following conditions:
• Normal and expected data
• Error and unexpected conditions

Normal and Expected Data

When you test normal and expected conditions, use data that is representative
of the real data that you will be using in the program. For example, in testing
an order entry application, data could be used to test the following conditions:
• Opening of a new account
• Updating an existing account
• Closing an existing account
• Updating multiple existing accounts
• Generating a picking slip report

Error and Unexpected Conditions

Use data in testing for error and unexpected conditions that is not
representative of the data that you would use in running your program. Error
data is important because you may discover that your program is generating
errors when used in a new or unexpected way. By using data that is erroneous
or unexpected, you will have a way of seeing whether your program performs
predictably. Some examples of error condition testing are:
• Attempting transactions against nonexistent account numbers.
• Updating closed accounts.
• Using input data with invalid dates, incorrect totals, or invalid ranges of
values in key fields.
• Using combinations of data that have multiple errors or data that has a
combination of valid and invalid values.

Sample Applications

5-63

Some examples of unexpected condition testing are:
• Using no data as input to a program
• Running two days' worth of data as one day's
• Running a program with the wrong inputs
It is important when you are testing error conditions to ensure that your
program is issuing error messages that describe the errors encountered in
testing.

Other Testing Considerations
Check the following when you are testing a program:
• Have you successfully tested the restart or recovery procedures?
• Are the personnel who have to use the program familiar with the procedures
needed to use or run the program?
• Does the program pass the right data to other programs that have to use
the program's output?
• Are the system operators familiar with the requirements for the program?
• Has the program been tested for all phases of processing? For example, if
the program has to generate weekly and monthly reports, have you merely
tested for weekly report generation? That is not a sufficient level of testing.
Program coding and testing should continue until all program functions are
coded and tested. Using the DEBUG operation in complicated programs can
shorten testing. If DEBUG is used, condition each DEBUG operation with an
external indicator (for example, US). Thus, the program can be tested with or
without debugging without recompiling it.
As each program is being developed, changes may have to be made to the
original specifications. For example, it may be easier to keep a field of
information on the screen rather than in the control record. This would mean
changing the screen and the logic of the program.

5-64

DOCUMENTING THE APPLICATION PROGRAM
This section provides some guidelines that you can use when documenting
your application programs. Documentation of your programs can serve to
provide the following functions:
• Definition of the purpose of the application program.
• Definition of the inputs to the program, such as screen formats, type of
records, and organization of the inputs. (Are the inputs sequential on disk or
diskette? Is the input passed from another application program?)
• Definition of the outputs from the program. (Is the output in the form of a
screen format? Is the output a file on disk or a report and if so what is the
format of the file or report?)
• Written documentation of the logic of the current version of the program.
• A history of the revisions that have been made to the program.
• Program accounting information.
• List of persons to contact for further information regarding the application
program.
When documenting your program(s), you should establish a program packet
that is readily accessible to persons who have to work with the application
program. This program packet should be in a central location. Figure 5-31
shows items that you could place in your program packet.

Sample Applications

5-65

• General program descriptions
Program name
Run frequency
General input descriptions
General output descriptions
Purpose of program
• Flow diagram of input and output to the program
• Detailed record layouts of input and output to the program 1
• Printer layout of output report(s)
• Screen format descriptions of program input and output
• Narrative description of program logic
• Program source listing
• Sample of output

· oel to

run the program, or procedures necessary to run the program

• Operator instructions
• Program modification history log
• Message identification codes used by the program
Description of what these codes mean
-

Procedures to follow when these codes occur

• Restart/ recovery information

.- --.--_..... -..........

. ... _--

Iyou may wish to have aI/record descriptions in a central location to facilitate revising
these record descriptions and to make sure that each program has an up-to-date
record description.

Figure 5-31. Sample Program Packet list

The following eight pages make up a sample program packet for the ORDPRT
program.

5-66

COMPUTER PROGRAM DESCRIPTION SHEET
Documentation Reference

Program Name

OR-03

ORDPRT
Run Frequency

Language/Util ity

RPG

Library

Account Number

01

Date

07/29/80

Input From Program

Input Format

1&1 Disk

DAILY

Version

11801

ORDLIB

ORDITM

Input Screen Formats

j

1
Output Report Number

I

Output Report Name

63l1-A

PICKING SLIP

1

I

Output File Name

TRANSLOG

Output Used by Program
Documentation
Name
Reference - -

-- I

Department

User Contact

INVENTORY

A G SMITH

Responsible Programmer

Program Used by

ORDER ENTRY, WAREHOUSE DEPARTMENTS

AG SMITH

GENERAL FLOW DIAGRAM

TRANSLOG
ORDPRT
Print
Picking
Slip

-

-,
\

Transaction
Hold
File

/
I

\

r

PICKING
Slip
6311-A
........

TWO-PART PAPER
6311-Y
FORM:
REPORT NUMBER:

6311-A

-

PAGE10F ______________

Sample Applications

5-67

COMPUTER PROGRAM DESCRIPTION SHEET
Documentation Reference

OR-03

Program Name

Print Picking Slip (ORDPRT)

Date

08/01/80

Program Segment _ _ _ _p_u_r.....;:p;;...o_s_e_ _- Narrative Description:

The purpose of the print picking slip program is to produce
the picking slip by reading the TRANSLOG file and, for each
order contained in the file, to produce a picking slip.

PAGE _ _ __

5-68

OF _ __

COMPUTER PROGRAM DESCRIPTION SHEET

Documentation Reference

Program Name

Date

Print Picking Slip (ORDPRT)

OR-03

08/01/80

Program Segment _ _ _ _
I_N_P_U_T_ _ _ __

NARRATIVE DESCRIPTION
1.

TRANSLOG File (Transaction Hold File)
File Organization:
Record Length:
Sequence:

Direct

128 characters

Record Code, Customer Number

PAGE _ _ __

OF _ __

Sample Applications

5-69

INPUT/OUTPUT Record Description

TRANSACTION HOLD

Record Name
File Name

System

Trans10g

Page _ __

S YSTEM/ 34
~

Disk

File No. _ _ _ _ __

0 Diskette

of _ __

Date _ _ _ _ _ __

Sequence Record Code, Customer Number Prepared by A. Smith
Direct
Record Length _1_2_8_ _ _~_ _ __
Key Customer Number
Key Length_6_ _ _ _ _ _ __
File Organization

Created by

0

RD I TM

Values

Used by

ORDITM, ORDPRT

Field Description

Field Name

Updated by _O;;...R....;D;;;...P~R;.;;;.T_ _ _ _ __
Length

Decimal
Format
Pos.

Location
To
From

Relative Record Number
128
N
1
*Customer Record Information
Record Code
CV
OCODE
2
A
1
D or blank
Delete Code
ODELET
1
A
3
Customer Number
CUSNO
6
N
4
Order Number
ORDNO
6
10
N
Customer Name
CNAME
25
A
16
Customer Address
CADDR
25
A
41
City
CCITY
22
A
66
State
CSTATE
2
88
A
Zip Code
CZIPCD
5
N
90
Salesman Number
CSLSNO
2
95
N
Purchase Order Form
CPONO
10
A
97
*Ship to Record Information
Record Code
CS
OCODE
2
A
1
Delete Code
ODELET
1
A
3
Customer Number
CUSNO
6
N
4
Order Number
ORDNO
6
N
10
Ship-To Name
SNAME
25
A
16
Ship-To Address
SADDR
25
A
41
City
SCITY
22
A
66
State
SSTATE
2
A
88
Zip Code
SZIPCD
5
90
N
*Line Item Record occurs 1 to 3 times for each Customer Record
Record Code
2
A
1
Delete Code
3
1
A
Customer Number
6
4
N
Order Number
6
10
N
Order Line Number
2
16
N
Item Number
18
6
N
Item Description
20
A
24
Quantity Ordered
44
6
N
Price
6
N
50
Amount Extended
8
56
N
Warehouse Location
5
64
A

5-70

128
2
3
9
15
40
65
87
89
94
96
106
2
3
9
15
40
65
87
89
94
2
3
9
15
17
23
43
49
55
63
68

COMPUTER PROGRAM DESCRIPTION SHEET

Documentation Reference

Program Name

Date

PRINT Picking Slip (ORDPRT)

OR-03

Program Segment

08/01/80

Switch Settings and Local Data Areas

Narrative Description:

Switch Settings Used:

None

Local Data Area Use:

None

PAGE _ _ __

OF _ __

Sample Applications

5- 71

COMPUTER PROGRAM DESCRIPTION SHEET

Documentation Reference

OR-03

Program Name

Print Picking Slip (ORDPRT)

Date

08/01/80

Program Segment _O~U~T_P....;;U;...T_ _ _ _ _ _ __
Narrative Description:

1.

Picking Slip Report
Form Number:
63llY
Report Number:
63ll-A
Two-Part Paper
Frequency: Daily

2.

TRANSLOG File
File Organization:
Direct
Record Length:
128 characters
Sequence: Record Code, Customer Number

PAGE _ _ __

5-72

OF _ __

J

66

1 1 1 1 1 1 11,111112 2 2 21212121212 2 3 3 3 3 3 3 13 3 3 13 4 4 4 14 14 144 4 44 15 5 5 5 5 5 5 5 5 5 66 6 6 6 6 6 6
7 7 7 7 17 7 17 7 1 7 8 8 8 8 8 8 8 18 81819 99
12345678190 1 2345611181910 I 2314151'17\890' 2345\67 ril9 0 1 213141~ 618910 I 234567890 I 2345678901 2,1451, 7 890' 2345 617 ri~!)2. 1 2

R PIO T #.110: e311 I -iA: i

I

! ;

~~~~~~~~~~.-+

t'

rl( N~ 'Sll[P, !!

I

.+~~--

1,

M

L

f-

; i!

'i

1

I!

;,1:11 'SiD UTH S'T;RE:I-.'T

, I

!

~

I

':O!Rf; iE Ir'E:RP!R:IJ5 IES!

i

'

I

I

i

:

"
! .

'I

! ,

,I i "

,I

! , .

'~"'I/ n

nv V'V

I

'PA~b I~)C~

I

,

' :1 I

.....

'I . . .

I

. "

__.

,

~::::j~~:.~I:!~:::~~~=::=::~~==::::::~~~!~:~::!'::::~~=::=-_._-~__-=.:-~~ _-+.~_t_·~~~_·~~_·~~rr~!·~~4~._.~~.~:::::'_~~;
___.'_.~~,.~~,+~++_-+-r.~.~.~.~~~,'
::
I

I

!

I

i'
!
!
:
H-++++-t-1-+-t-+~-t-tI_1:-+-:~-t-+t-t--.-+-----:-' "
it--t--·...;....-HI-+-...---....~

+-r.. - "'+,---', ...--rt·---<-i
.:
. t--'1'T+_~~
!,.
;:
+:
, , .
t++-+I~-r-+.... ---..--+--t-+------;----~~·.....-t_t--~~++~-+-...... -+--T--.+---+-~.....-+·-~ +

j'

+.,- -.....,...•.+-;...

~ I~-t.•.
'

H-++~~-f-t-+~_t_t,-1I·-lrr~7~~--~-+~!~~.~,f--~~~~-----~~~~~---~
I

.

) ' :

-

!:

+4~~~~~~+~----

~

~++~~--~-+4;4!--~-+j'~4-----~~H_~I~'~-.~'~'~-r--~-r-+~-r..--··-,
.~-~
H-++++-t-1_rt-+~-H-+-'-+--++t~-----.--+- ,~:.'. ~,
. ++~-.
r--.-t_+_--.-~++~__t_-+--_7-+.,--t----_t_+_t~-+----.-___++-- -+-, I ,

!

! ... "

I

. !

: I

'

.•. --t------ -j-'-+........-------t--~

!

~

~rr+++_r+++_~~~~~~--____-++++i~+~4!+i44~~~~~t_+_~+_r+T~I++++_+_~~~~~~~_r~~~ __ ~
•

!i

,

I

!

! !

~

.

I

i I ;

i i i

I

I I

;

I

234~67890

!

. I :

i

; I

t

~

!

:

!:

i

. I . ,

! .

i,

I

:

i

i !I
i
i
!
: i i : , i
I II i ' :
i
I I I ,11 ,111111 22 2 21212121~1,2 2 3 333 3313133134441414144444155555555556 ,1666
6 6 7 7 7 7 177 171 7 7888' 8 8 ,18 88 19, 9 ~
1 234J.U1718190 123(4(51617)890 12345,61819012131415678;10' 234~67890 1234567"0,2314&167 890123456/789/0' 2:
I

1

! .

I

I

I

1

i

!.

; I

11

I

!

1

I

! '

,

,I"

1

Sample Applications

5- 73

COMPUTER PROGRAM DESCRIPTION SHEET

Documentation Reference

Program Name

Date

Print Picking Slip (ORDPRT)

OR-03

Program Segment

08/01/80

Processi_ng Logic

Narrative Description:

1.
2.

Open input file and outputs.
,Read the control record of the TRANSLOG file to find the
last record printed.

3.

Read each record for each order in the file and, for each
record, produce a line on the picking slip report (63ll-A).

4.

At the end of the order, update the control record with the
relative record number of the last record printed.

PAGE _ _ __

5-74

OF _ __

System Test
When each application program has been tested and is working properly with
minimum data, the application is ready for a system test.
The system test is the final phase in the development of an application. The
system test makes sure that the application meets the objectives it was
designed for and tests whether the system can be run as operational. During
system testing you can test for the following items:
• Are the programs easy to use?
• Are the error messages provided by the programs meaningful?
• Is the final output correct?
• Does the system run as fast as it was intended to on the computer?
• Does the system meet its goals in terms of response time for display station
operations?
• Do the recovery or restart functions work correctly?
By the end of the system test, you should have detailed instructions for the
system operator and a set of instructions for the people who have to use the·
application.

User's Run Book
You should develop a user's run book after your application has been tested
and implemented. A user's run book is written for people who have to use the
application but were not involved in programming the application. The user's
run book explains how the application works and gives detailed instructions for
using the application.
Some of the items you should have in a user's run book are:
• A general description of the application and how the application works
• A description of the input to the application
• A description of the output of the application
• A detailed description of the procedures required to run the application
• Samples of all forms or documentation used by the application
• Error correction procedures

Sample Applications

5- 75

Operator Program Run Book
The operator program run book contains the procedures to be carried out when
you run the application program on the computer. You should have procedures
to run every program so that the system operator can obtain the proper inputs
to the program, set up the inputs correctly, and make sure the job executes
correctly. Generally, entries in an operator program run book can be contained
on one 8 1/2 by 11 inch sheet of paper and should contain information
necessary for proper execution and setup of the program.
Sample items that can be included in an operator program run book are:
• A system flowchart of the application
• A list of the inputs used by the program
• Procedures for the setup of the job
• Procedures for error handling
• Procedures describing output distribution that can be used by either the
system or subconsole operator
• Procedures for restarting or rerunning the job
Figure 5-32 is a sample of an operator program run book entry.

5-76

OPERATOR INSTRUCTIONS

1

PROGRAM NAME: PR85

LIBRARY USED: PAYROLL

PROGRAM PURPOSE: This program is responsible for writing a Deduction Register
I

I

I

I

FILES
USED

FILE
NAME

;
I
I

I
I

FILE
MEDIUM

i
I
I

I

.

I

DIS K/D IS KETTE/
LABEL

I

I

I
I
I

I

DRIVE

I
I

DISPOSITION
AFTER USE

~-------T-------T-----------+------+--------

I
I

DEDUCT

I

.
I

I

I

DISK

I

I
I
I

N/A

I
I

.

I

I

I

N/A

I

I

PRINTER USED

FORMS USED

SYSTEM

3-PART STOCK

REMAINS
ON DISK

I

DISTRIBUTION
Original and one copy to
payroll; one copy remains
in the file.
NEXT
PROGRAM

PREREQUISITE
PROGRAM

RUN FREQUENCY

I
I

BIWEEKL Y as a part of each payroll cycle.

NONE

PR87

INSTRUCTIONS REQUIRED TO RUN THE PROGRAM
// LOAD PR85
// FILE NAME-DEDUCT
// RUN

OR

// MENU DEDUCT, PAYROLL
USE OPTION 6

EXPECTED ERRORS/RECOVERY
UNIDENTIFIED RECORD IN THE FILE-take recovery option 1 and continue
UNEXPECTED ERRORS/RECOVERY
WRITE DOWN ERROR MESSAGE CODE, THE MESSAGE TEXT, AND TAKE RECOVERY OPTION 0 OR
1. IF 0 OR 1 ARE NOT VALID OPTIONS, CONTACT THE PROGRAMMER OR MANAGER.

OPERATOR NOTES:

COMPARE CONTROL TOTALS To THOSE IN THE. CONTROL BOOK •••
I

ALERT PAYROLL IF THE'!' DON'T BALANC.E , DON)T RUN 'PR87
CD j"l t'l (~~I ND

1.
2.
3.
4.
5.
6.
7.
8.
9.

:to ,.

JOURNAL ENTRIES
INQURIY-JOURNAL FILE
MASTER FILE LISTING
EDIT TIME CARDS
ALLOWABLE VARIANCE
DEDUCTION REGISTER
PAYROll CHECKS
PAYROLL REGISTER
COPY PAYROLL FILE

:1.:1. .\
:t ::::.\

i"lENt.!: D[DI...IC,,(,
:I. ::5 .'.
:t -4.,
:I. ~::; .'.

:1.6 ..
:1.7 . .

:t ~::: .\

:1.9.,
;?O .,
2:1.
...." .., . .
.-::...::. :.
"':t"'Z
........\

~:

24.,

ENTER NUMBER, COMMAND, OR OCl.
Figure 5-32. Operator Program Run Book Entry

Sample Applications

5-77

5-78

Appendix A. Display Station Operations Requested by Basic Assembler Programs

This appendix describes the basic operations that can be requested by a Basic
Assembler program when it calls work station data management. When the
program calls work station data management, two bytes in a data area called
the DTF (define the file) determine the requested operation. These two bytes
can request a combination of the basic operations. An example is the
put-no-wait with invite operation. This operation is a combination of the
put-no-wait and invite input operations.
The following information lists and describes the operations that can be
requested by a Basic Assembler program when it calls work station data
management. The macro instruction, operation code, or operation modifier that
is used to perform an operation is listed in parenthesis beneath the operation.
Refer to the Basic Assembler and Macro Processor Reference Manual for further
information.

Operation

Description

Open
($OPEN)

Prepares for the processing of all display station
operations requested by the user program. During
the open operation, work station data management
builds an index that points to all display screen
formats in the display screen format load member
used by the program. If specified in the DTF, work
station data management builds a table containing
information supplied on the WORKSTN OCL
statements. In Basic Assembler programs, you must
request an open operation before you request any
other operations for the display station file.

Put
(PUT)

Sends data to a specified display station. Work
station data management returns control to the user
program when the data transfer is complete.

Put-no-wait
(PNW)

Sends data to a specified display station. Control
returns to the user program when the operation is
scheduled. The program can then change its record
area, indicators, or DTF without affecting the
scheduled operation. If the program attempts a
second put-no-wait operation to the same display
station, work station data management waits for the
first operation to be completed before it schedules
the second operation.

Display Station Operations Requested by Basic Assembler Programs

A-1

Operation

Description

Put for
read-under-format
(PRUF)

Sends dc;lta to a display station and allows the next
job step to read the data back in. Two types of
PRUF operations can be requested:
• Auto PRUF, which can only be requested from a
Basic Assembler program. An auto PRUF
operation uses the display screen to temporarily
store data between job steps. The keyboard is
locked when the format is displayed. Th~ format
is returned to the next job step in response to
the first accept input operation requested from
the step. To perform an auto PRUF operation,
the Basic Assembler program must request an
auto-PRUF-put-no-wait-invite operation.
• Interactive PRUF. An interactive PRUF operation
occurs if the last display station operation before
termination of a job step is an invite type
operation. The keyboard is unlocked for an
interactive PRUF operation, and the operator can
key information while the next step is loading.
After the operator enters the display, work
station data management returns the format to
the next job step in response to the first accept
input operation requested from the job step.
Note: Either PRUF operation can occur when going
from (1) an MRT program to another MRT program,
(2) an MRT program to an SRT program, (3) an SRT
program to an MRT program, or (4) an SRT
program to another SRT program. After requesting
a PRUF operation, an MRT program should release
the display station. After requesting a PRUF
operation, an SRT program should end.

A-2

Operation

Description

Put override
(OVR)

Sends data to a specified work station but transmits
only indicator-controlled output fields and attributes.
A program uses a put override operation to override
(change) information previously displayed without
retransmitting the entire format. During a put
override operation, the following events occur:
• If a field had an indicator specified in the output
data entry (columns 23 and 24 of the D
specification) and that indicator is off, the data in
the field is unchanged. If data was entered in the
field, that data is unchanged. Any field that had
V, N, or blank specified in columns 23 and 24 is
also unchanged.
• If a field had an indicator specified in the output
data entry (columns 23 and 24 of the D
specification) and that indicator is on, the field is
retransmitted and contains data from the
program. Any data that was entered in the field
by the operator is lost. Output information is
displayed from the same location in the output
record area as for a normal put operation.
• For all fields, the use of indicator-controlled
attributes, such as highlight or reverse image, is
determined by the state of that indicator. All field
attributes that are not controlled by indicators are
unchanged.
Note: If an indicator is specified in the protect field
entry (columns 37 and 38 of the D specification),
that indicator is ignored during the override
operation.

Unformatted request
(UNF)

Modjfies any of the put operations and informs
work station data management that the information
in the program's record area is in a format suitable
for transmission to the display station. (The
information already contains all the required control
information and attribute characters.) Work station
data management transmits the information to the
display station without formatting the information.

Display Station Operations Requested by Basic Assembler Programs

A-3

Operation
Invite input
(lNV)

Description
Signals the display station that the program is ready
to receive data. The invite input operation is in
effect until (1) the program issues a get input
. operation for the display station, (2) an accept input
operation receives data from the display station, (3)
the program requests a stop invite operation for the
display station and the stop invite is successful, or
(4) the program requests an output operation to the
display station.
Note: A display station operator can interrupt an
MRT program (by pressing the Attn key) only while
an invite input operation is in effect for the display
station.

Get
(GET)

Receives data from a specified display station. After
placing the data in the program's record area, work
station data management returns control to the user
program.

Accept
(ACI)

Receives data from any display station that
responded to a previous invite input operation. For
example, if a program issues three invite input
operations for three display stations (W" W2, and
W3) and then issues an accept input operation, the
data the program receives can be from anyone of
those display stations. Work station data
management places the ID of the display station
that returned the data in the program's DTF.

Stop invite input
(STI)

Cancels a previous invite input operation to a
specified display station. If the display station
operator enters the display before the stop invite
input operation is performed, work station data
management informs the user program via a return
code in the DTF. The program can then request a
get or accept operation to read the information
entered by the operator, or the program can request
an output operation to the display station. If the
program requests an output operation, the
information the operator entered is lost.
Note: The user program does not have to issue a
stop invite operation to override an invite input
operation. For example, a program can issue two
consecutive put with invite operations. However,
any information the operator enters in response to
the first invite operation is lost.

Acquire
(ACQ)

A-4

Allocates the specified display station to the
program that requests the operation. If the acquire
operation fails, a return code is passed back to the
user program.

Operation

Description

Release
(REL)

Releases the specified display station from the
program that requests the operation. A release
operation is valid only from an M RT program.

Write error
(ERROR)

Writes up to 78 high-intensity characters of data on
the bottom line of the display screen. The keyboard
locks, and the operator must press the Error Reset
key to restore the previous contents of the bottom
line.

Get attributes
(GTA)

Places an 8- byte string of data in the user
program's record area. The data string is a series of
bytes that describes the attributes of the specified
work station.

Extended get
attribute
(EGTA)

Places a 16-byte string of data in the user program
record area. The data string is a series of bytes that
describes the attributes of the specified
ideographic-capable display station.
Note: The get attributes (GTA) operation can also
be used for an ideographic-capable display station,
but some of the attributes for the specified display
station will not be returned.

Print
(PRINT)

Prints, on a specified printer, the contents of a
specified display screen.

Roll
(ROLL)

Rolls a specified group of lines up or down on the
display screen. The user program's DTF specifies
the starting and ending line numbers of the area to
be rolled, the number of lines to roll, the direction
of the roll, and whether or not vacated lines should
be blanked out.

Erase
(ERS)

Erases (blanks out) the contents of the input fields
on the display. An erase operation instead of a put
operation is performed when you specify erase input
fields (columns 31 and 32 of the S specification). If
an invite or get operation is not requested along
with the erase operation, the keyboard is locked
following an erase operation. Otherwise, the
keyboard is reset.

Clear
(CLR)

Erases (blanks out) the entire display screen,
including attribute bytes. You can request the clear
operation only from a Basic Assembler program.

Display Station Operations Requested by Basic Assembler Programs

A-5

Operation

Description

Status inquiry
(SIQ)

Causes work station data management to set a DTF
return code, which indicates:
• Whether any invite. input operations have
completed.
• Whether the system operator has used the STOP
SYSTEM command to cause shutdown of system
operations.
Note: Status inquiry can also be requested by
passing to work station data management a value of
hexadecimal 'FFFF' in index register 2. Work station
data management returns the status information in
index register 2.

A-6

Glossary

abnormal termination: A system failure that does not
allow an operator to sign off successfully. For example,
an abnormal termination occurs after a message that
has only a 3 option or after a failure that stops the
system but does not cause a message to be displayed.
active program: A program that is in main storage or
in the swap area on disk.
active program list: A system-maintained list of all
active programs.
active user library: The library used by most functions
performed during execution of a customer-written
program. If a required member is not in the active user
library, the system library (#LlBRARY) is searched for
the member.
application: A particular data processing task such as
inventory control or payroll.
assign/free area: The available space in the supervisor
for control areas.
audit trail: A general recording of who did what and in
what sequence.
autowriter: A function that causes the spool writer
program to be loaded without operator intervention
whenever output exists in the spool file.
BASIC (Beginners All-Purpose Symbolic Instruction
Code): An interactive programming language designed
for ease of use.
basic display station configuration record: A disk
record that contains the basic display station
configuration information on the IBM-supplied PID
diskettes.
batch classification: A classification assigned to
programs by the System/34 swapping function. A
program is assigned the batch classification when it
executes for longer than a system-determined time limit
without accepting input from a display station. See also
interactive classification.

batch processing: A method of running jobs that does
not require continuous operator attention; that is,
processing that is not interactive. Contrast with
interactive processing.
block: A 10-sector unit of disk storage that contains
2560 bytes. A block is also a group of records, treated
as a logical unit, that is read or written by the computer.
COBOL (Common Business Oriented Language): A
standardized business language for programming a
computer.
command display station: A display station that can
request and initiate jobs.
command mode: A mode that a display station can be
placed in. In command mode, a display station is
capable of requesting jobs or initiating jobs.
command processor: The SSP function that initially
processes information entered by the operator.
data communications configuration record: A disk
record that contains information about the data
communications configuration. Each command display
station has an associated data communications
configuration record.
DFU (Data File Utility): Part of the Utilities Program
Product used to create, maintain, and display or print
data files.
direct file: A disk file in which records are assigned
specific record positions. Regardless of the order in
which records are put in a direct file, they always
occupy the assigned position in the file.
directory: See library directory.
disk data management: The SSP function that controls
the flow of data to and from disk files.
dispatching function: The System/34 function that
allows multiple programs in main storage to share
processing time.

Glossary

B-1

display screen format: A table that defines a display
presented by work· station data management.
display station local data area: A 256-byte area on
disk that can be used to pass information between jobs
and job steps during a session. A separate local data
area exists for each command· display station.
erase input operation: A work station data
management operation that erases (blanks out) the
contents of the input and output/input fields on the
display screen.
external indicators: Eight indicators (U1-U8) that are
normally set by the SWITCH OCl statement before job
execution. These indicators can be tested and changed
during execution.
fixed-format menu: A type of menu generated by the
$BMENU utility program. A fixed-format menu contains
two columns of menu items, with 12 items in each
column.
FORTRAN (formula translation): A programming
language primarily used to express arithmetic formulas
via computer programs.
free-format menu: A type of menu generated by the
$BMENU utility program. For a free-format menu, the
programmer defines the contents of lines 3 through 20.
history file: An area on disk in which a log of specified
types of system actions and operator responses is
recorded.
IFILE: An attribute of an indexed file that allows
sequential-by-key access to added records without
sorting the keys.
initiator: The SSP function that reads and processes
Oel statements from the system input device.
inquiry: 1. A request (entered from a display station)
for information in storage. 2. A request for information
that puts the system in inquiry mode. (The operator
initiates an inquiry by pressing the Attn key.)
inquiry latch: An indicator that informs an interrupted
program of an inquiry request. The operator causes the
inquiry latch to be set on by selecting option 4 on the
Inquiry display.

8-2

interactive classification: A classification assigned to
programs by the System/34 swapping function. If a
program executes for longer than a system-determined
time limit without accepting input from a display station,
the program loses its interactive priority. See batch
classification.
interactive processing: A method of processing in
which each operator action causes a response from the
system or a program, as in an inquiry system or an
airline reservation system. See batch processing.
I PL (initial program load): A sequence of events that
loads the system programs and prepares the system for
execution of jobs.
job: One or more related procedures or programs
grouped into a first-level procedure.
job file: A disk file created with a retain parameter of J.
A job file can be used by all the job steps in a job. The
job file is defined only within the job and does not exist
after the job ends.
job region: The amount of main storage ensured by the
SSP for use by a job. The job region is specified by the
REGION DCl statement, the SET procedure, or the
$SETCF utility program.
job step: A unit of work represented by a single
program. The lOAD OCl statement, RUN DCl
statement, and other OCl and utility control statements
define the job step within a procedure.
library: An area on disk that can contain load members,
procedure members, source members, and subroutine
members.
library control sector: The first sector in a library
directory. The library control sector contains a record of
the used and available space in the library.
library directory: A variable-sized area that contains
information, such as name and location for each
member in the library.
library member: A named collection of records or
statements in a library.
line printer (5211 or 3262 printer): A device that prints
all characters of a line in a single operation. Contrast
with serial printer, matrix line printer.

linkage editor: A program that prepares subroutines or
the output of language translators for execution. The
linkage editor resolves symbolic cross-references,
generates overlay structures on request, and produces
executable code (a load member) that is ready to be
loaded into main storage.
load member: A collection of instructions that the
system can execute to perform a particular function,
regardless of whether the function is requested by the
operator or specified in an OCl statement. load
members can also contain screen formats and message
members. load members are stored in a library.
local data area: See display station local data area.
LR (last record) indicator: An RPG II indicator that
signifies when the last data record is processed; the lR
indicator is used to condition all operations that are to
be done at the end of the program.
master file: A collection of permanent information,
such as a customer address file, that is often processed
along with a transaction file.
matrix line printer (5225): A device that prints all the
characters of a line in a single operation, and each
character is formed by a matrix of wires.
menu: A displayed list of items (usually jobs) from
which the operator makes a selection.

NRT (non-requestor terminal) program: A program
that is evoked by another procedure or program or has
no requesting display stations allocated to it. Contrast
with SRT and MRT.
eel (operation control language): A progamming
language used to identify a job and its processing
requirements to the SSP.
operator control command: A command statement
used by an operator to control system or display station
operation. A control command does not run a
procedure and cannot be used in a procedure.
override fields operation: A work station data
management operation that allows a program to override
(modify) fields on a display without retransmitting the
entire display.
password security: An optional SSP function that
helps prevent the unauthorized use of a display station.
permanent file: A file that remains in existence until
deleted by using the $DElET utility. A permanent file is
created with a retain parameter of P for disk or 999 for
diskette.
PID: Program information department. An IBM group
responsible for distributing programs and publications.

memo updating: An interactive file updating technique.

print intercept routine: The routine that causes printer
output to be placed in a spool file in disk storage rather
than going to the printer.

MRT (multiple requestor terminal) procedure: A
procedure that calls an MRT program.

print spooling: A part of the SSP that provides
temporary storage of print data on disk.

MRT (multiple requestor terminal) program: A
program that can process requests from more than one
requesting display station concurrently.

printer data management: The SSP function that
controls the flow of information to the printer.

multibatch processing: The processing of two or more
batch programs concurrently.

priority processing: A method used in a
multiprogramming environment that determines the
sequence in which programs are processed by the
system.

NEP (never-ending program): A program that uses
system resources for a long period of time and was
defined as a never-ending program (NEP-YES) on the
COMPilE OCl statement.

priority program: A program to which the priority
attribute was assigned by the operator or programmer.

nonswappable storage: The amount of user storage
used by nonswappable programs.

procedure: A set of related eCl statements and,
possibly, utility control statements, that cause a specific
function or set of functions to be performed. A
procedure in a library is called a procedure member.

Glossary

8-3

procedure command: A command statement that runs
a procedure. A procedure command is a special form of
the INCLUDE OCl statement.
procedure member: A procedure that is stored in a
library.
production run: The normal operational running of an
application system.
program ready list: A system-maintained list of
programs that are in main storage and ready to execute.
put override: See override fields operation.
record mode: A method of operation in which data is
transferred by the SSP one record at a time.
resource security file: A file that contains information
about each protected file or library.
RPG II: A commercially oriented programming language
specifically designed for writing application programs
that meet common business data processing
requirements.
scratch file: A file that can be used only by the job
step creating it. A scratch file does not exist after the
job step ends if the file is created with a retain
parameter of S.
SOA (screen design aid): A part of the Utilities
Program Product used to create, change, and delete
display screen formats and menus. SDA can also be
used to build RPG " programs and WSU programs.
sector: 1. A 256-byte area on disk reserved to record
data. 2. The smallest amount of data that can be
written to or read from a disk or diskette during a single
read or write operation.
sector mode: A method of operation in which data is
transferred by the SSP one sector at a time.
serial printer (5256 Printer): A printer that prints
characters one at a time. Contrast with line printer,
matrix line printer.
session: 1. The time during which programs or devices
can communicate with each other. 2. The elapsed time
that starts when an operator signs on the system and
ends when the operator signs off the system.
SEU (source entry utility): A part of the Utilities
Program Product used by the operator to enter, update,
and print procedures and source programs in a library.
8-4

single program mode: A method of ~per~tion during
which one job (either batch or interactive) IS completely
processed before another job is begun.
source member: A collection of records (such as RPG
" specifications or sort sequence specifications) that is .
used as input for a program. Source members are
stored in a library.
SRT (single requestor terminal) program: A program
that can have only one requesting display station at a
time.
. SSP: System support program product.
standby mode: A method of operation in which a
display station is waiting to be acquired and used by a
program running on the system.
subroutine member: A subroutine that needs to be
link-edited before being loaded for execution.
Subroutine members are stored in a library.
SUBR22: An IBM-written subroutine that allows an
RPG " program to read records from a transaction file
created by a WSU program.
SUBR95: An IBM-written subroutine that allows an
RPG " program to perform an inquiry function.
supervisor: A program that manages system resources
such as the printer(s)' display station(s), main storage,
input job queue, and spooling.
suppress input operation: A work station data
management operation that does not invite input from a
display station.
swapping function: The System/34 function of placing
programs or segments of programs temporarily on disk;
swapping allows the total amount of user storage
required by concurrently executing programs to exceed
the amount of main storage normally available for user
programs.
system library: The library containing members that are
part of the SSP in addition to non-SSP members. The
system library is labeled #LlBRARY and cannot be
deleted from disk.
system list function: An SSP function that prints
output for some SSP utility programs and service aids.

system printer: The printer, named at system
configuration time, that is used for system and display
station printed output unless the output is specifically
directed to another printer.
temporary file: A file that cannot be automatically
deleted until after its expiration date. A temporary file is
created with a retain parameter of T for disk or 001
through 998 for diskette.
terminator: The System/34 function that performs the
system action necessary to end a job or job step.
transaction file: A file containing relatively transient
data that, for a given application, is processed together
with the appropriate master file.
user storage: The area of main storage that is not used
by the SSP.
work station data management: The SSP function
that enables a program to present data on a display
screen by providing only a string of data fields and a
format name.
WSU (work station utility): A part of the Utilities
Program Product that performs an interactive data entry
and edit function.

Glossary

8-5

8-6

Index

// *

2-12

abnormal termination
affect on
file updates 2-67
files with key sort 2-19
new files 2-19
nonshared files 2-19
records added to shared files 2-62
description 2-19
access algorithm
deriving relative record numbers 2-54
determining 3-39
examples 3-42
access methods
affect on physical I/O 3-35
description 2-53
acquired display station
for MRT program 2-112
for SRT program 2-107
releasing from a job 2-118
releasing from an MRT program 2-112
releasing from an SRT program 2-107
status during an inquiry 2-107
active program 2-29
active program list 2-29
active user library
changing 2-96
description 2-97
saving a diskette 2-99
specifying 2-79
activity
disk 3-61
file 3-24
add files, sharing 2-63
added records, accessing
after key sort 2 - 68
among logical files 2-71
in a shared file 2-62
ADDROUT file, using for relative record
numbers 2-54, 2-56
adjust/fill editing 3-57
advantages of print spooling 2-81
algorithm, access
deriving relative record numbers 2-54
determining 3-39
examples 3-42
allocation of file space 2-74
alphameric fields 3-27

application
design 3-49
example design 5-1
Assembler program
ending 2-114
specifying number d display
stations 2-113
stopping a never ending 2-115
assign/free area 2-4
aSSign/free space 3-60
ATTN Key to release r;~play station from
MRT program 2-115
ATTR Oel statement 2-23, 2-111, 2-113
attributes, field 2-42
attributes, program
affect on disk activity 3-61
choosing 3-57
description 2-105
autocall capabilities 2-132
autowriter option

backup and recovery 3-65
badge reader as data entry device 3-54
badge security 2 -123
batch program, on active program
list 2-24
block 3-32
block length 3-32
block number locations on disk 2-74
blocking records
advantages 3-32
considerations for random
processing 3-33
description 3-32
minimizing physical I/O 3-34
buffer
sharing 3-38
work station 2-43, 3-81

cancelling a M RT program 2-115
changing and aligning forms 2-86
checkpoint facility 2-139
considerations 2-140
restrictions 2 -141

Index

X-1

COBOL program
ending 2-114
number of display stations 2-113
procedures supplied 5-59
stopping if never ending 2-115
coding techniques 4-1
command key
displaying error information 3-10
in RPG II program 4-20, 4-26
legend 3-8
command processor 2-10
communications with office products 1-2
compatibility editing 3-57
COMPilE OCl statement
for MRT program 2-112
for SRT program 2-106
indicating a never-ending program 2-115
specifying a maximum number of display
stations 2-113
COMPRESS procedure 2-}0
conditional output field 2-46
consecutive processing
description 2-53
for active files 3-24
CONSOLE file 3-52
control field as relative record
number 3-39
controlling print spooling 2-82
cursor position 3-8

data
passing to an MRT program 2-111
passing via PROMPT OCl 4-12
data display station 2-105
data entry programs
comparison of coding methods 3-50
DFU 3-50
editing 3- 54
input forms design 3-19
RPG II 3-52
WSU 3-51
data management
disk 2-17
printer 2-79
SSP-ICF 2-129
work station (see work station data
management)
data processing security 3-70
data security 3- 70
data accuracy 3-70.
input controls 3- 70
limited access to data 3- 70
output controls 3- 70
processing controls 3- 70
fire protection 3-69
limited access to the computer 3-69

X-2

data processing security (continued)
physical location 3-69
physical security 3-69
data stream, reducing for remotes 3-80
data structure
for multiple line displays 4-19
for the local data area 4-5
date editing 3-57
deadlock condition
description 2-64
preventing 2-65
default printer 2-78
default value editing 3-56
delete-capable files 2-56
delete code 3- 27
DFU program, data entry 3-50
direct file
access algorithm 3-39
adding records 3-24
advantages 3- 20
control record 3-23
description 2-54
processing consecutively 2-54
relative record numbers 3-39
synonym records 3-40
direct organization
for master files 3-21
for transaction files 3- 22
for volatile files 3- 24
directory
changing its size 2-94
description 2-94
size 2-94
disk accesses
factors affecting number of 3-61
for attaching display stations 3-61
for loading programs 3-61
disk data management 2-17
disk drive implementation for extended
capacity 2-74
disk file (see file)
dispatching 2-26
display
accepting input from 2-44
acknowledging operator input 3-9
consistency 3-6
design considerations 3-2
documenting 3-10
error correction 3-9
headings 3-3
inquiry for an MRT program 2-113
inquiry for an SRT program 2-108
multiple line 4-19
operator responses 3-8
printing copies of 3-10
providing error information 3-10
readable 3-4
sending a format to 2-43
showing via PROM PT OCl statement 4-7
single idea 3-8

display (continued)
title 3-2
display screen format
data fields 2-40
field attributes 2-42
programmer definition 2-38
sending multiple 2-49
sending to remote work station 2-44
transmission time 3-81
used by work station data
management 2-38
display station
acquiring in an MRT program 2-112
acquiring in an SRT program 2-107
attaching to an MRT program 2-110
data 2-105
disk activity for attaching 3-59
local data area (see local data area)
maximum number for an MRT
program 2-113, 3-59
releasing from a job 2-107
releasing from an M RT
program 2-112,2-114
releasing from an SRT program 2-107
distributed disk file facility 2-149
documentation
for backup/recovery procedures 3-67
for displays 3-10
for program testing 5-61
for programs 5-65
record description 3- 28
record formats 5- 20
run book 5- 75
system flowchart 5-28
system operator run book 5-76
user run book 5-75
DROP operation code
releasing acquired display station from
anMRT 2-112
releasing acquired display station from
an SRT 2-107
releasing requesting display station from
an MRT 2-114
duplication 3-57

editing
data entry program 3-54
WSU program 3-52
EJ indicator 2-115
erase input fields operation 2-46
error correction 3-9
error message
display design considerations 3-9
displaying via a put override
operation 3-81

execution priority 2-23, 2-25, 2-26, 2-27,
2-29, 2-30
execution time limit 2-29
EXTEND parameter 2-57
extendable disk files 2-57
external indicators
accessing from an M RT program 2-111
for no-requestor-terminal program 2-118
reading and updating 3-67
testing and setting 3-67

field
alphameric 3-27
attributes 2-42
conditional output 2-46
editing 3-55
erase input 2-46
in display screen format 2-40
input 2-40
length 3-26, 3-27
naming 3-27
nondisplay 3-6
numeric 3- 26
output 2-41
output/input 2-42
ownership 4-16
placement on printer forms 3-16
size 3-26
file
activity
affect of number on disk
activity 3-61
factor for choosing file
organization 3-24
reducing 3- 24
allocation rules 2-74
backup 3-71, 4-4
delete-capable 2-54
design 3-20, 5-12
direct (see direct file)
disk, using as two or more logical 2-71
extendable 2-55
groups 2-51
indexed (see indexed file)
labels 2-51
logical 2-71
master (see master file)
offline multivolume 2-73
organization
design considerations 3-20
file activity considerations 3-24
for master file 3-21
for transaction file 3-22
types 2-52
password security 2 -120
processing methods 2-54

Index

X-3

file (continued)
rebuild 2-69
record mode 2-98
recovery 2-69, 3-71
resource security 2-126, 2-127
saving 2-99, 5-32
sactor mode 2-99
security 2-126
sequential 2-52
sharing
accessing added records 2-62
affect of abnormal termination 2-62
affect on physical I/O 3-38
considerations 2-63
in multiple program mode 2-62
record blocking consideration 3-34
updating technique 2-67
types that can be shared 2-62
types that cannot be shared 2-62
update program 2-65, 3-59
volatility 3-24
file and library security 2-125
file locking and IFILlE'S 2-60
finance support subsystem 2-133
fixed format menu 2-100
format (see display screen format)
forms
backup 3-72
design 3-16
input 3-19
output 3-16
printer 3-16
free format menu 2-100
function control keys 4-26

headings, display 3-3
help, providing for a display 3-10, 4-26
HISTCRT procedure 3-79
history file
event review 3-76
performance consideration 3-60, 3- 79
home location 3-39
home record 3-39

I/O
logical 3-35
physical 3-35
shared 3-38
IFILE support 2-58
index 2-52

X-4

indexed file
adding records 3-24
advantages 3- 20
description 2-52
key sort 2-68
processing consecutively 2-54
processing sequentially by key 3-24
reconstructing an index 2-69
records-within-limits processing 2-54
total-file-by-key processing 2-54
with IFILE attributes 2-58
indicator
EJ 2-102
external (see external indicators)
for conditioning a displayed
message 3-9
for conditioning field attributes 3-9
for positioning cursor 3-9
LR 2-114
initiating a program 2-25
for never-ending programs 2-25, 2-115
initiation time
shortening 3-61
initiator
functions 2-11
M RT procedure processing 2-12
input
acknowledging 3-9
inviting 2-38
input field 2-40
input forms, designing 3-19
input job queue priority 2-24
input job queue program 2-118,2-119
inquiry display
for an MRT program 2-113
for an SRT program 2-114
inquiry latch 2-108
inquiry program
and IFILEs 2-73
design
3-59
file processing allowed 2-72
file usage in single program mode 2-72
inquiry request
for an MRT program 2-113
for an SRT program 2-108
interactive communications feature 2-128
sample applications 5-61
interactive program
data entry 3-50
file update 3-59
inquiry 3-59
typical 3-49
IPL file rebuild 2-69

job
assigning priority 2-36
description 2-2
file 2-111,2-118
priority 2-36
processing 2-3
starting 2-10
stop 2-3, 2-18
without a requestor 2-105
job management 2-23
job scheduling 2-23
JOBQ control command 2-105

key
length 3-26
sorting 2-68
keys, standardizing use 3-6
KEYSORT procedure 2-68
keysorts and IFllE'S 2-61

length
field 3-28
record 3-29
library
active user
changing 2-97
description 2-97
specifying 2-97
changing size 2-94
control sector 2-94
description 2-93
directory 2-94
format 2-94
member
storing in a file 2-98
reusing space 2-96
search order 2-97
security 2 -126
sharing 2-98
size 2-94
list
active program 2-29
program ready 2-27
list check editing 3-56
listings of sample procedures 5-33
load member 2-93
local data area
accessing from an MRT program 2-112
accessing via SlJBR21 4-5
example of using 3-67
extracting data from 3-67
for no-requestor-terminal program 2-118

local data area (continued)
loading for an MRT program 4-5
loading for an SRT program 4-5
performance considerations 2-12
providing input 3-67
used by RPG II 3-67
used by SDA 3-67
used by SMF 3-67
used by WSU 3-67
using to increase Sort flexibility 4-16
local inquiry program 5- 78
lOCAL OCl statement 3-67
logging OCl, performance
consideration 2-13
logical file
accessing added records 2-71
description 2-71
updating records 2-71
logical I/O operation 3-35
lR indicator 2 -114

magnetic stripe format
main storage
used by MRT program 3-62
mandatory field entry 3-56
mandatory fill 3-57
mandatory menu 2-110
master file
memo update 4-1
organization 3-21
reducing activity 3- 24
master security officer 2-121
member, library 2-93
memo updating 4-1
menu
chaining 3-13
description 2-100
design 3-13
displaying 2-100
fixed format 2-102
free format 2 -102
items 3-13
mandatory 2-123
on 1920-character display 2-103, 2-104
on 960-character display 2-103, 2-104
security 2-123
message
display design consideration 3-9
from input job queue 2-118, 2-119
waiting-for-resource 2-1 i 8
M RT procedure
calling 2-109
considerations 2-112
creating 2-110
initiator processing 2-3, 2-11

Index

X-5

MRT program
accessing external indicators 2-112
accessing requestors local data
area 2-112
acquiring a data display station 2-112
authorization to run 2-126
calling 2-109
cancelling 2-115
changing number of requests 2-110
coding 2-112
COMPilE OCl statement 2-110
considerations 2-111
deciding when to use 3-59
description 2-109
disk activity for loading 3-61
ending 2-114
file update considerations 2-67
initiating 2-109
inquiry into 2-113
maximum number of display
stations 2-113, 3-60
MRTMAX parameter 2-112
never ending 2-115
passing data to 2-112
protecting records from concurrent
updates 4-12, 4-15
reducing swapping 3-59
releasing display stations 2-112, 2-114
using A TIN key to release display
station 2-115
using job files 2-111
using the local data area 4-5
M RTMAX parameter
for an MRT program 2-112
for an SRT program 2-106
multiple line displays 4-19
multiple program mode, file sharing 2-62
multiple requestor terminal program (see
MRT program)

NEP (see never ending program)
NEP-YES 2-115
never ending program
coding 2-115
deciding when to use 3-59
disk activity for loading 3-61
ending 2-116
input job queue program 2-115
MRT program 2-115
SRT program 2-115
no-outstanding-invites return code 2-114
no-requestor-terminal jobs 2-118
nondisplay field 3-6
nonrestartable job step 2 -144
nonswappable program 2-37
nonswappabl.e storage 2-37

X-6

normal termination
affect on disk VTOC 2-18
affect on job files 2-18
affect on system data areas 2-18
affect on system resources 2-18
affect on the requesting display
station 2-18
nucleus 2-3, 2-5
numeric field 3-26

o member

2-93
OCl
minimizing processing time 2-12
performance considerations 2-12
showing a display 3-64
testing and setting external
switches 3-67
officer
master security 2-121
security 2-122
offline multivolume files 2-73
operation
erase input 2-46
logical I/O 3-44
modified work station data
management 2-46
normal work station data
management 2-44
override fields 2-46
physical I/O 3-39
suppress input 2-49
operator input, acknowledging 3-9
operator response 3-8
organization, file (see file organization)
output field
conditional 2-46
in display screen format 2-41
output forms, designing 3-16
output/input field 2-42
output, spooling to remote printer 3-81
overflow area, index 2-52
overlays, versus swapping 3-62
override fields operation 5-4
ownership field 4-15

P member 2-93
packed field 3-26
parameters, passing via PROMPT OCl
password security
description 2-120
file 2-121

4-8

PDATA parameter
for passing data 4-12
for passing parameters 4-9
performance consideration 2-87
performance considerations
disk accesses 3-61
excessive headings 3-3
interval polling of remote display
stations 3-81
library sharing 2-98
OCl considerations 2-12
overlapping keying and program
initiation 3-64, 4-12
overlays 3-63
override fields operation 2 -13
physical I/O 3-35
polling remote work stations 3-81
program attributes 3-57
program size 3-60
reducing amount of data
transmitted 3-80
remote work stations 3-80
RUF (read under format) 3-64
sequential processing 3-38
work station buffer size 2-43, 3-81
performance considerations for
IFllE'S 2-61
physical I/O
description 3-35
factors affecting 3-35
polling
interval 3-81
nonproductive 3-81
primary area, index 2-52
print intercept routine
printer
changing default 2-79
data management output 2-79
default 2-79
forms design 3-16
spooling (see spooling)
system 2-77
system list output 2-79
types 2-77
work station 2-77
printer data management
output 2-79
programs that use 2-79
printer, remote 3-81
priority assigning 2-25
execution priority 2-23, 2-36
input job queue 2-24
procedure
call an MRT 2-109
creating an MRT 2-110
member 2-93
passing parameters to 4-8
processing jobs 2-10

processing method
consecu~ve
2-54
random 2-54
records within limits 2-54
sequential 2-54
sequential by key 2-54
total file by key 2-54
processor, command 2-10
PROF procedure 2-121
profile, password security 2-121
program
active 2-29
attribute
affect on disk accesses 3-61
choosing 2-105, 3-59
description 2-105, 3-59
batch 3-49
data entry 3-50
disk activity for attaching display
stations 3-61
disk activity for loading 3-61
documenting 5-63
execution time limit 2-29
file update 2-67, 3-59
initiating
description 2-25
overlapping with keying time 3-66,
4-11
input job queue 2-24,2-25,2-118
inquiry 2-72, 3-59
interactive 3-49
MRT (see MRT program)
never ending (see never ending program)
nonswappable 2-37
read-under-format 3-64
ready list 2-26
size 3-61
SRT (see SRT program)
swapping in 2-27
swapping out 2-28
updating using SEU 5-29
user 2-17
using the local data area 3-65, 4-5
program ready list 2-26
program testing considerations 5-60
PROMPT OCl statement
format 4-7
PDATA parameter 4-8, 4-11
performance considerations 2-13
UPSI parameter 4-7
using to show a display 3-64, 4-8
protection
against concurrent record
updates 2-63,4-13,4-15
sector 2-63
PRTY control command 2-23, 2-119
public access level 2-126
put override operation 3-81

Index

X-7

R member 2-93
random file processing 2-54
range check editing 3-56
read under format 3-64
rebuild, IPL file 2-69
record
accessing those added to a shared
file 2-63
adding to a direct file 3-24
adding to an indexed file 3-24
blocking 3-32, 3-35
delete code 3- 28
design 3-25
documenting layout 3-29
extra space 3-28
home 3-40
layout 3-29
length 2-12,3-29
naming fields 3-28
number, relative (see relative record
number)
protection from concurrent
updates 4-13, 4-15
relative number (see relative record
number)
removing 3-28
synonym 3-40
updates in logical files 2-67
record mode file 2-98
records-within-limits file
processing 2-54
recovery 3-67
region size 3-62
REL operation code
for an MRT program 2-114,2-116
for an SRT program 2-107
relative record number
assigning 3-39
description 2-54, 2-55
determining with an access
algorithm 3-39
using an ADDROUT file 2-54
RELEASE-YES parameter 2-118
releasing
a display station 2-107, 2-114, 2-116,
2-118
a sector 2-65
remote inquiry program 5-80
remote printers, spooling 3-81
remote work station
avoiding unnecessary data 3-4
considerations 3-80
nonproductive polling 3-81
performance considerations 3-80
receiving input from 2-44
transmitting a format to 2-44
using erase input fields operation 2-46
using override fields operation 2-46
REQD-YES parameter 2-107, 2-114

X-8

requesting display station,
releasing 2-115,2-121
required field entry 3-56
resource conflicts, avoiding 3-59
resource security file 2-126
response time
affected by acknowledging operator
input 3-9
affected by file organization 3-20
affected by unnecessary data 3-4
direct file advantage 3-22
shortening by assigning priority 2-36
shortening by using two MRT
procedures 2-112
shortening via MRT programs 3-59
shortening via SRT programs 3-60
restart facility 2-142
return code,
no-outstanding-invites 2-115,2-120
RPG II program
data entry 3-52
ending 2-114
number of display stations 2-113
stopping a never ending 2-116
RUF (read under format) 3-64

S member 2-93
sample inquiries using SSP-ICF 5-77
sample procedures, listings of 5-33
sector
deadlock 2-64
description 2-63
protection 2-63
release 2-66
sector-mode file 2-99
sector protection and IFILE'S 2-65
security-file listing 2-127
security, system
classifications 2-121
description 2-120
file and library 2-126
officers 2 -121
public access level 2-126
resource file 2-126
sign on
badge 2-123
menu 2-123
password 2 -120
self check editing 3-57
separator pages 2-87
sequential-by-key processing
2-53
sequential file
advantages 3-20
description 2-53
processing consecutively 2-54
processing randomly 2-54

sequential processing
affect on physical I/O activity 3-38
method 2-54
SET /KEY data entry method 3-52
shared file (see file sharing)
shared I/O, affect on physical I/O 3-38
shared libraries 2-98
shared processor time 2-26
sign-on security
badge 2-123
menu 2-124
password 2-120
single program mode, file usage 2-72
single requestor terminal program (see SRT
program)
sort program 2-54, 4-17
sorting keys 2-69
source member 2-93
spool commands 2-88
spool file 2-82
spool file size 2-83
spool intercept buffer 2-84
spool intercept routine 2-84
spool writer program 2-85
spool writer programs
spooling
description 2-81
remote printers 3-81
spooling options during
configuration 2-82
SRT program
acquiring a display station 2-107
coding 2-106
COMPilE OCl statement 2-106
deciding when to use 3-59
description 2-106
disk activity for loading 3-59
interrupting 2-108
MRTMAX parameter 2-106
never ending 2-116
passing data to 2-106
releasing display stations 2-107
SSP-ICF 2-129
sample application 5-78
STOP SYSTEM command 2-68, 2-115
storage
index 3-35
nonswappable 2-37
swappable 2-37
storage concepts
disk storage
task work area 2-2
main storage
assign/free 2-4
assign/free size 2-4
nucleus size 2-5
system nucleus 2-3
transient area 2-3
user area 2-5
storage contents 3-35

subconsole operator 2-122
subroutine
member 2-93
reading and updating external
indicators 3-67
SUBR21 4-5
SUBR22 3-51
suppress input operation
description 2-49
for remote work stations 3-81
swap area 2-29
swappable storage 2-28
swapping
affect on performance 3-62
description 2-27
of priority jobs 2-28
reducing via MRT programs 3-59
time taken 2-35
using active program list 2-32
versus overlays 3-62
SWITCH OCl statement 3-67
switches parameter of the PROMPT OCl
statements 4- 8
synonym records
description 3-40
example 3-42
system input (SYSIN) processing 2-3, 2-21
system list. programs using 2-78
system operator security
classification 2-122
system printer 2-77
system secu rity 2 -1 21
system testing 5-75
system/34 and distributed
processing 2-146
System/34 as host system 2-147
System/34 as PEER connection 2-149
System/34 as processor terminal 2-146
System/34 as subhost system 2-148

table lookup editing 3-58
task work area 2-2
termination, abnormal (see abnormal
termination)
termination, normal 2-18
terminator 2-18
testing
program testing 5-61
system testing 5-75
third and fourth disk drives 2-74
total-file-by-key processing 2-54
transaction file
backup 3-67
choosing a file organization 3-22
created by a WSU program 3-22, 3-51
organization 3-22
transmission rate 3-81

Index

X-9

update file, sharing 2-62
update program, file 2-67,3-58
updates, file
common errors 2-67
in logical files 2-71
memo updating 4-1
protecting against concurrent
updates 4-13, 4-15
technique 2-67
UPSI 3-67
user library, active
changing 2-97
description 2-97
specifying 2-97
user program 2-17
U1 through U8 3-67

vertical line spacing 2-80
volatility, file 3-24
VTOC, verifying entries 2-69

work station buffer 2-43, 3-81
work station data management
description 2-38
input operations 2-43
modified operations 2-46
normal operations 2-44
operations requested by Assembler
programs A-1
output operations 2-43
work station printer 2-77
WORKSTN file 3-52
WORKSTN OCl 2-107, 2-110
WSREloperation 2-107,2-110,2-112
WSU program
data entry 3-51
ending 2-114
local data area usage 3-66
never ending 2-116
stopping a never ending 2-116

X.21 interface

X-10

2-133

zoned decimal field

3262
5211
5225
5256

printer
printer
printer
printer

3-26

3-16
3-16
2-80, 3-16
3-16

READER'S COMMENT FORM

IBM System/34

SC21-7742-3

Concepts and Design Guide

Please use this form only to identify publication errors or to request changes in publications. Direct any requests
for additional publications, technical questions about I BM systems, changes in I BM programming support, and so
on, to your IBM representative or to your nearest IBM branch office.

D

If your comment does not need a reply (for example, pointing out a typing error) check this box
and do not include your name and address below. If your comment is applicable, we will include it
in the next revision of the manual.

D

If you would like a reply, check this box. Be sure to print your name and address below.

Please contact your nearest IBM branch office to request additional
publications.

Name
Company or
Organization _-...,_ _ _ _ _ _ _ _ _ _- -_ _ _ _ __

IBM may use and distribute any of the information you supply
in any way it believes appropriate without incurring any
obligation whatever. You may, of course, continue to use the
information you supply.

No postage necessary if mailed in the U.S.A.

Address

City

State

Zip Code

SC21-7742-3

Fold and tape

Please do not staple

Fold and tape

IIIIII
BUSINESS
FIRST CLASS

REPLY

NO POSTAGE
NECESSARY IF
MAl LED IN THE
UNITED STATES

MAIL

PERMIT NO. 40

ARMONK, N. Y.

POSTAGE WILL BE PAID BY . . .

IBM CORPORATION

General Systems Division
Development Laboratory
Pu bl ications, Dept. 245
Rochester, Minnesota 55901

Fold and tape

Please do not staple

Fold and tape

IBM Sy~tem/34 Concepts and Design Guide (File No. 534-34) Printed in U.S.A.

SC21-7742-3

E>

11111111

M

11111111

~
,......

·11··

N

~

11:11:11

N

11111111

en

U



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                     : 2015:08:08 20:39:13-08:00
Modify Date                     : 2015:08:08 20:18:04-07:00
Metadata Date                   : 2015:08:08 20:18:04-07:00
Producer                        : Adobe Acrobat 9.0 Paper Capture Plug-in
Format                          : application/pdf
Document ID                     : uuid:f71741ed-0aa7-f541-ada1-a1f1a2db41cc
Instance ID                     : uuid:df8f67d5-8b58-9747-9969-cc75b5194b81
Page Layout                     : SinglePage
Page Mode                       : UseOutlines
Page Count                      : 376
EXIF Metadata provided by EXIF.tools

Navigation menu