An Introduction To As400 System Operations
An Introduction To As400 System Operations
Table of Contents
Index
C5250 Data Stream, 178
Option 3, 42
Option 4, 42
Option 5, 42
Option 10, 42
Option 11, 42, 137
Option 75, 42
Option 80, 42
Sign-On screen, 43
See also Operational Assistant
Assistance levels
Basic, 81-86
changing, 20
defined, 20
Intermediate, 86-91
types of, 20
*AUDIT special authority, 23
Auditing, 17
Authorities, 8, 22-24
*ALL, 23
*CHANGE, 23
data classifications, 34
*EXCLUDE, 23
group, 25
predefined values, 33
*PUBLIC, 31
search path, 35-36
special, 23-24
*USE, 23
See also Security
Authorization lists (*AUTL), 31-34
authority types, 32-33
defined, 31
displaying, 32
uses for, 31
Authorized program analysis report (APAR), 144
Automatic configuration, 114
daily, 126
diskette considerations, 130-134
examples of, 126
quarterly, 126
tape considerations, 127-130
time for, 124
weekly/monthly, 126
See also Restoring
Backup Tasks menu, 138
Backups, 16
collating sequence, 130
inventory list and, 134
restricted, 138
running, 136-144
Save commands and, 124-125
save files, 139-141
setting up, 138-139
storage reclamation, 134
*BASIC assistance level, 20, 81-86
Batch jobs, 27, 28, 57
holding, 58, 64
releasing, 64-65
removing, 65
submitting, 57-58
verifying status of, 62-64
viewing, 63
See also Jobs
Batch subsystem, 3-4
BCHJOB (Batch Job) command, 27
Binary Interchange File Format (BIFF) format, 185
*CHANGE authority, 23
Change Printer Output screen, 84
CHGCLNUP (Change Cleanup) command, 135
CHGMSGQ (Change Message Queue) command, 73-74
additional parameters, 75
screen, 74
CHGSHRPOOL (Change Shared Storage Pool) command, 157
CHGSPLFA (Change Spooled File Attributes) command, 92
CHGSYSVAL (Change System Value) command, 154
CL commands, 43-50
abbreviations, 44
checking syntax of, 28
in CL programs, 46
defined, 43
display, 46
entering, 8
general structure, 51
information display, 48
keyword notation, 50-51
major groups, 45
Operational Assistant, 43
parameters, 46-47
positional notation, 51-52
question mark and, 48
redisplaying syntax for, 50
verb, list of, 46
See also specific commands
CL (Control Language), 8
Cleanup, 134-136
customizing, 135
ending, 135
starting, 135-136
See also Backup plan
Cleanup Tasks menu, 134-136
accessing, 134, 135
illustrated, 135
Client Access for OS/400
Client Access/400 for Windows option, 174
client/server programming, 188-189
data queues, 188
data transfer/file transfer, 183-187
defined, 173-174
Extended DOS option, 174
features, 177-178
install overview, 174-175
install overview on PC, 176
ODBC, 188
PCSMENU program and, 178
Personal Communications/400, 179-180
references, 189
RUMBA/400, 179
shared folders, 181-183
starting, 177
files, 192
Define Audit Control screen, 202-203
Define General Information/Indexed File screen, 201-202
Define the Query screen, 208
Device descriptions (*DEVD)
categories of, 106
copying for display stations, 114-117
creating, 113-121
creating for display stations, 117-118
defined, 103
for diskette drives, 119-120
for displays, 106-108
for printers, 109-110, 120-121
for terminals, 106-108
troubleshooting, 118-119
working with, 106-107
See also Devices
Device Status Task screen, 104-105
defined, 104
displaying, 108
illustrated, 105
Devices, 103-113
automatic configuration, 114
managing, 103
naming, 116-117
port number, 116
relationship with lines and controllers, 101
selecting, 115
status, 104
for diskette drives, 112-113
for printers, 108-109
for tape drives, 110-112
for terminals and display devices, 105-106
support of, 104
switch setting, 116
viewing, 103
See also Device descriptions (*DEVD)
Diskette drives
device description creation for, 119-120
device status for, 112-113
Display Device Description screen, 113
Work with Configuration Status screen, 113
Diskette menu, 131
Diskettes, 130-134
displaying volume identification, 131-132
initializing, 132
sizes, 130
See also Backup plans; Backups
Display Command (DSPCMD) command, 47
Display Commands menu, 46
Display Device Description screen, 107-108
diskettes, 113
page 1, 107
page 2, 108
showing auto configuration, 110
specific device selected, 108
for specified printer, 110
tape device, 112
Display devices
device description, 106-108
device status, 105-106
See also Devices
Display Diskette (DSPDKT) command, 131-132
Display Installed Licensed Programs screen, 175
Display List Details screen, 72
Display Message Details screen, 71
Display Report screen, 211
Display Spooled File screen, 85
Display stations
configuring/addressing, 117-118
copying device description for, 114-117
creating device description for, 117-118
specifying device description for, 115
*DLT data authority, 34
Documents (*DOC), 12
DOS format, 184
DSPDIRE (Display Directory Entry) command, 89
DSPMSG (Display Message) command, 47
DSPOBJAUT (Display Object Authority) command, 34-35
defined, 34
operator authority for, 34
security administrator and, 35
See also Authorities
DSPPTF (Display Program Temporary Fix) command, 150-151
DSPSYSVAL (Display System Value) command, 19, 154
accessing, 154
screen, 155
See also System values (*SYSVAL)
DSPTAP (Display Tape) command, 128
screen, 129
See also Tape drives; Tapes
DSPUSRPF (Display User Profile) command, 22
Help, 52-55
Extended, 53-54
function levels, 52
key, 52, 53
Operational Assistant, 52-53
HIPER PTFs, 145, 150
Individual PTFs
cover letter, 144
defined, 144
loading, 146-148
See also PTFs
Informational messages, 68
InfoSeeker function, 55
defined, 55
display, 55
Initial program load (IPL), 141, 147
Inquiry messages, 29, 68
*INTERMED assistance level, 20, 86-91
Interactive Data Definition Utility (IDDU), 192
Interactive jobs, 57
Interactive subsystem, 3-4
Inventory list, 134
Inventory Maintenance screen, 206
INZDKT (Initialize Diskette) command, 132-133
accessing, 132
screen, 133
INZTAP (Initialize Tape) command, 128
accessing, 128
screen, 128
*IOSYSCFG special authority, 23
holding, 66
releasing, 66
status of, 66
working with, 65-66
Job states, 161-162
Jobs
active, 165-166
batch, 27, 57
date started, 29
deleting, 84
holding, 64
interactive, 57
names of, 58-59
priority of, 29
queued, 63
run priorities, 161
schedule entries, 60-62
scheduling, 58
sequence, changing, 64-65
types of, 57
working with by status, 63-64
Journal (*JRN), 12
cleaning up, 134
defined, 12
Journal receiver (*JRNRCV), 12
cleaning up, 134
defined, 12
Key lock, 16
Keyword notation, 50-51
Libraries, 8-11
creating, 9
current, 26
defined, 8
IBM-supplied, 9-10
QDCT, 9
QDOC, 9, 10
QGPL, 9, 10, 26
QHLPSYS, 9, 10
QOFC, 9
QPDA, 9
QPFR, 9
QPWXALIB, 9
QPWXCLIB, 9
QRPG, 9, 11
QRPGLE, 9
QSPL, 9, 10
QSQL, 9
QSYS, 9, 10
QTEMP, 10-11
QUSRSYS, 10
saving, 140-141
See also Objects
Library list, 30-31
accessing libraries not in, 31
defined, 30
displaying, 30-31
specifying, 30
Licensed Internal Code (LIC), 2
Lines, 102
description of, 102
relationship with controllers and devices, 101
types of, 102
Load Program Temporary Fix (LODPTF) screen, 148, 149
Logical files, 198-200
temporarily changing, 96
values, 72
See also Queues
Messages
additional information about, 69-70
categories, 70
delivery method, 73
error, 70
function of, 68
handling, 68-76
informational, 68
injury, 29, 68
printer, 92-93
severity level, 73
spooled output, 89
Microcode Fixes (MFs), 146, 147
Model Unique Licensed Internal Code (MULIC), 2, 124
Modification level, 3
Objects, 8-12
authority, 8, 22-24
defined, 8
document, 12
folder, 12
journal, 12
menu, 12
message file, 11
owner of, 8, 24
program, 12
qualified name, 9
restoring, 141-144
user-specific, 20-22
Pages, 163
Passwords
length of, 21
modifying, 21, 42
PC Support/400
client/server programming, 188-189
data queues, 188
data transfer/file transfer, 183-187
defined, 173-174
features, 177-178
install overview, 174-175
install overview on PC, 176
ODBC, 188
PCSMENU program and, 178
references, 189
shared folders, 181-183
starting, 177
145, 150
individual, 144
installation verification, 149-151
IPLs and, 147
LIC, 2
lists, 3
loading cumulative, 148-149
loading individual, 146-148
Microcode Fixes (MF), 146, 147
numbers, 145
ordering, 144-145
OS/400, 3
System Fixes (SF), 146
types of, 146
*PUBLIC authority, 31
PWRDWNSYS (Power Down System) command, 169
function of, 169
screen, 170
QRPGLE library, 9
QSECURITY system value, 7, 18
QSFWERRLOG system value, 5
QSPL library, 9, 10, 154
QSQL library, 9
QSRLNBR system value, 5
QSTRPRTWTR system value, 5
QSYS library, 9, 10
QSYSLIBL system value, 6
QSYSOPR message queue, 22-23, 96
QSYSPRT file, 71
QTEMP library, 10-11
QTIME system value, 4
QTOTJOB system value, 5
Queries
defining, 208
sorted listings, 209-210
working with, 207-208
Query for OS/400, 207-210
defined, 207
report generation, 208-210, 211
Query/400 User's Guide, 207
Queues
data, 188
defined, 11
job, 58
message, 71, 72-76
output, 84-85, 95-96
QUPSDLYTIM system value, 18
QUPSMSGQ system value, 6, 18
QURPSDYTIM system value, 5
QUSRLIBL system value, 6
QUSRSYS library, 10
QYEAR system value, 4
Restoring
objects, 141-144
steps for, 142-143
See also Backup plans
Ring topology, 100, 101
RNMOBJ (Rename Object) command, 114
RUMBA/400, 179
QDEVNAMING, 5
QDSCJOBITV, 5, 18
QDSPSGNINF, 7, 17
QHSTLOGSIZ, 6
QINACTITV, 5, 18
QINACTMSGQ, 7, 18
QIPLDATTIM, 5
QIPLSTS, 5
QIPLTYPE, 5
QJOBSPLA, 6
QKBDBUF, 5
QKBDTYPE, 5
QLMTDEVSSN, 17
QLMTSECOFR, 7
QMAXACTLVL, 6
QMAXSGNACN, 7, 17
QMAXSIGN, 7, 17
QMCHPOOL, 6
QMODEL, 5
QPRBHLDITV, 6
QPRTDEV, 5
QPWDEXPITV, 7, 22
QPWDMAXLEN, 21
QPWDMINLEN, 7, 21
QPWDRQDDIF, 7
QPWRRSTIPL, 5, 18
QRCLSPLSTG, 6
QRMTSIGN, 5
QSECURITY, 7, 18
QSFWERRLOG, 5
QSRLNBR, 5
QSTRPRTWTR, 5
QSYSLIBL, 6
QTIME, 4
QTOTJOB, 5
QUPSDLYTIM, 18
QUPSMSGQ, 6, 18
QURPSDYTIM, 5
QUSRLIBL, 6
QYEAR, 4
System values (*SYSVAL), 4-7
allocation control values, 6
changing, 4
Tape drives
device description creation for, 119-120
device status for, 110-112
Display Device Description screen, 112
support of, 127
Work with Configuration Status screen, 111
Tape menu, 127-128
Tapes, 127-130
CUM, 148
density of, 130
displaying, 128
erasing, 128, 130
initializing, 128-130
rewinding, 130
unloading, 130
volume ID name, 130
volume name, 130
See also Backup plans; Backups
Terminal devices
device description, 106-108
device status, 105-106
signing off, 105
Terminal emulation, 178-180
Time slices, 161
Transfer requests, 183-187
AS/400 to PC, 185-186
defined, 183
PC to AS/400, 187
recalling, 184
Troubleshooting
device description creation, 118-119
illustrated, 67
WRKACTJOB (Work with Active Jobs) command, 165-166
powering down and, 168
screen, 168
screen sample, 166
system overhead and, 166
See also Jobs
WRKDEVD (Work with Device Description) command, 96
WRKDSKSTS (Work with Disk Status) command, 167
WRKFLR (Work with Folders) command, 181
WRKJOBQ (Work with Job Queues) command, 65-66
screen, 65
See also Job queues
WRKJOBSCDE (Work with Job Schedule Entries) command, 60-62
accessing, 61
options, 61-62
screen, 61
WRKOBJPDM (Work with Objects Using PDM) command, 192, 193
WRKSBS (Work with Subsystems) command, 154-155
WRKSBSJOB (Work with Subsystem Jobs) command, 168
WRKSHRPOOL (Work with Shared Pools) command, 157
WRKSPLF (Work with Spooled Files) command, 43-44, 86-92
accessing, 87
Attributes option, 89
Change option, 89
displays, 87
Message option, 89
with OUTQ CL command, 92
SCHEDULE parameter, 88
Send option, 89
status codes, 88
View 1, 87-88
View 2, 89
View 3, 90-91
Work with printing status option, 96
See also Printing; Spooled file members
WRKSYSSTS (Work with System Status) command, 159, 162-165
accessing, 162
sample from, 164, 165
screen, 163
WRKUSRJOB (Work with User Jobs) command, 168
Table of Contents
Preface
Chapter 2Security
Security
System Values
Security Levels
Assistance Levels
User Profiles and User-Specific Objects
User Classes and Object Authorities
Group Profile Concerns
Job Descriptions
Library List
Authorization Lists
Display Object Authority Command
Authority Search Path
Key Terms
Review Questions
Exercises
Save Commands
Sample Backup Plan
Tape Considerations
Initializing Tapes
Diskette Considerations
Reclaiming Storage
Cleaning Tasks
Running a Backup
Using Save Files
Restoring Objects
Program Temporary Fixes (PTFs)
Loading Individual PTFs
Loading Cumulative PTFs
Verifying PTF Installation
Key Terms
Review Questions
Exercises
Client Versions
Install Overview
Install Overview for PC Supportand Client Access on the PC
Starting PC Support
Starting Client Access
Using PC Support and Client Access Features
Terminal and Printer Emulation
Shared Folders
Data Transfer/File Transfer
Transfer Requests: AS/400 to PC
Transfer Requests: PC to AS/400
Other Features
Virtual Printer
Submit Remote Command
Data Queues
ODBC for Microsoft Windows
Client/Server Programming
Additional References for PC Support and Client Access
Key Terms
Review Questions
Exercises
Appendix A
Appendix B
Index
Table of Contents
Preface
Preface to Instructors
A lucky few of you will have an AS/400 dedicated to instruction. Some of your institutions probably
even grant extended system privileges and authorities to students studying system operations, and those
students will be able to change system values, among other things. However, a great many of you are
probably thrilled just to have permission to use your administrations AS/400 for a few courses. The
majority of the schools that will be using this text probably have a core of courses taught on an AS/400
shared by the administration and the instructional departments, with limited levels of authority granted
to the students.
To further complicate matters, the number of AS/400 models continues to increase, with all types and
manner of hardware that may be attached to these various models. Open architecture and interconnection
among non-IBM hardware will not simplify the AS/400s operating environment.
These greatly diverse situations explain the difficulty we experienced in producing a systems operations
text that is versatile enough to be useful in your particular AS/400 scenario. With these constraints in
mind, we have attempted to provide a text that covers typical daily AS/400 operational duties, as well as
weekly and monthly tasks, using Version 3, Release 1, Modification 0 of OS/400, the AS/400s operating
system. To ensure that the examples in the text will match your situation, we assume you are operating
at a security level of 30 or higher. Even within those parameters, you may find that examples of screens
we have included in this text may differ from screens you (and your students) will find on your system.
This is because the screen view may vary depending on the security level at which your system is set,
the authorities granted to the current user, and the assistance level at which the user is operating.
Preface to Students
When we set out to write an operations text, we were unsure what hardware, software, and authorities
your school would be able to provide to you, the system operations student. Generally, we expect you to
have some knowledge of the AS/400, probably in the form of an introductory course. We expect that
you have learned how to sign on to the system, how to work with your particular keyboard to access the
function keys, and how to access AS/400 on-line information. System operators typically help users
resolve problems; separate printed output to be routed to the appropriate users; perform scheduled
programs such as month-end procedures; and run the batch job queue. To facilitate your learning such
functions, we assume you will have the appropriate authority to a task; and we expect the display of the
AS/400 commands to be on your screen. We have provided descriptive text relating to how and when a
task is done, to place this material in context. However, the figures in this text may vary from the display
on your screen because your system may have a different security level. Even more likely, the figures
may vary because your assistance level is not the same as that represented for a particular example.
As with other versions of OS/400, V3R1 generally places the keyboard in lowercase format. After the
user or operator presses the Enter key, the text is converted into uppercase. The AS/400 operating
system supports many types of keyboards, each capable of supporting different keyboard mapping
schemes. To further increase the confusion, displays produced by the AS/400 are shown in both
uppercase and lowercase, depending on the command submitted. In this text, all commands to be keyed
from the text material are printed in uppercase. At the keyboard, you may enter the commands in
uppercase or lowercase, whichever is easier for the keyboard type you are using and its mapping defaults.
Dedication
To Rod, Megan, and Robin: Who washed dishes, folded laundry, and did without my attention, so that I
had time to write.
P.G.
H.R.
Special thanks to Catherine Stoughton, Bob Yeager, Lisa Oedekoven, Luke Greene, Charlie McLean,
and to Debbie Hendershot and Gale Shenefelt, for their time, effort, and resources in helping us
complete this text.
Table of Contents
Chapter 1
Introduction to the AS/400
Objectives
To understand
AS/400 Architecture
The AS/400 has a highly complex architecture that includes hardware, software, security, and other
components. To effectively manage this complex system and the daily tasks it performs, system
operators must understand the AS/400s basic architectural concepts and related terminology. The
AS/400 supports a great variety of hardware devices and software, but in this text we will discuss only
the most commonly used components and those that a system operator typically needs to know about or
work with.
Concepts and terms we will discuss in this chapter include the systems single-level storage approach to
memory, licensed internal code, how IBM keeps the systems operating system (OS/400) current,
subsystems (batch and interactive), system values, the AS/400s Control Language, objects, libraries, and
queues.
One of the unique characteristics of the AS/400 is its use of the single-level storage concept. Other
hardware manufacturers separate storage management into two separate hardware components: main
memory, which is also called RAM (random access memory), and disk (more correctly called DASD,
for direct access storage devices). With single-level storage, these two hardware devices are combined
into a logical unit, because they are inseparable. To help you understand this concept, consider your car.
The transmission and the engine are two separate, physical pieces of hardware; but if either one is not
functioning, the car doesnt run. Single-level storage (or storage management) applies the same principle.
Both components of memory must be functioning and be properly integrated, or the user will not be able
to access the data (s)he needs.
Another storage management concept that is designed into the AS/400 is the non-traditional method of
storing data on the disk drives and disk platters. Traditionally, a file is stored contiguously. If a part of
the disk is unused but too small for a particular file, the operating system will bypass the small space in
preference for a larger space. This approach causes gaps on the disk platter and results in the need for
the system to compress these unused spaces.
On the AS/400, for improved performance, a single database object is usually spread over several disk
drives and multiple disk platters. This approach allows for several users data to be retrieved (seemingly)
simultaneously and quickly displayed on multiple display station screens. The disk drives actually
retrieve data at the same speed as before; but data retrieval appears faster to the user. This method not
only improves performance but also eliminates the need to compress unused disk space. Having data
distributed in this way does, however, make comprehensive backup mandatory.
Licensed Internal Code (LIC), also called system licensed internal code, is software that relates directly
to the AS/400 hardware. LIC typically performs the following functions: storage management, pointer
and address management, program management, expectation and event management, data management,
I/O management, and security management. To support specific hardware models and processors of the
AS/400, IBM also issues Model Unique Licensed Internal Code (MULIC) or, for some models, Feature
Unique Licensed Internal Code (FULIC). MULIC/FULIC programs are model or processor dependent
and change as more models are added and others are upgraded. You as the system operator may be
required to install Program Temporary Fixes (PTFs) for Licensed Internal Code. A new release of LIC
may be required when a new machine is being installed if the IPL disk has crashed, or if you are
restoring your system after a complete system loss. We discuss installing LIC PTFs in the next section
and in greater depth in Chapter 7.
The AS/400 is not a static, unchanging combination of hardware and software. IBM provides continuous
repairs to address reported problems and make improvements to OS/400 software so the system remains
at top efficiency for its users. These repairs and improvements take the form of versions, releases,
modifications, and Program Temporary Fixes (PTFs). A new version of OS/400 contains significant new
code or functions for the OS/400 operating system. A new release represents a major improvement to
the operating system (see the Preface for the version and release being used for this text). A release is a
new product, or new functions or PTFs made permanent, for an existing version of the operating system.
A release can take the form of a smaller upgrade than a version. A modification level is frequently a
collection of PTFs issued since the previous modification, release, or version; this collection of PTFs
may be shipped as a single package. A change in modification level does not add new functions to the
release.
IBM may ship a new release with a modification level of zero. When the release is shipped with one or
more additional changes incorporated, the modification level is incremented accordingly (i.e., for
Version 3, you might receive Release 2, Modification 3). PTFs are generally small corrections to a
specific device or to pieces of software. PTFs are used to correct problems or potential problems found
within a particular IBM licensed software product; for example, RPG/400, COBOL/400, PC
Support/400, Client Access for OS/400, and RUMBA. PTF lists are updated daily and should be
reviewed regularly for applicability to your hardware and software. PTF lists are available via IBMs
Electronic Customer Support, which gives on-line access to IBM service facilities, technical
information, and marketing support information.
Subsystems
The AS/400 hardware and software join together to make a secure and efficient platform for jobs
performed on the system and the work management concepts associated with these jobs. One
management tool available on the AS/400 is the capability to divide the system into separate work
groups, called subsystems. All work on the AS/400 is done within a subsystem. The AS/400 can be
divided into a myriad of subsystems for more efficient processing of different types of jobs. The
subsystem description (*SBSD) is an object used to describe a subsystem and to control what tasks the
subsystem performs. The subsystem and subsystem description allocate resources and manipulate
system objects for the most efficient use of the different hardware and tasks the system has been
designed to perform.
Subsystems may run either interactive jobs or batch jobs. Interactive jobs begin when a person signs on
to the terminal, and they usually have a higher priority than other tasks. Generally, interactive jobs
require the user to type a command, wait for the machine to display the requested material, type another
command, and so on. While waiting for the user to enter the next instruction, the operating system is
either checking (polling) to see whether other users have completed a command, or it is executing tasks
for another user.
A batch job generally runs with minimal (or no) interaction with the user. Batch jobs usually run on a
lower priority than interactive tasks; consequently, they usually run when the AS/400 has time available.
An example of a batch job might be posting all the detail journals to the general ledger. Batch jobs may
also be held until a certain time of day. For example, a given batch job may be automatically run each
night at 11:00 p.m. An example of such a batch job would be the nightly deletion of work files before a
system backup.
System Values
System values, *SYSVAL, are AS/400 attributes that allow each installation to customize the machine
to the organizations own needs and specifications. Consider, for example, the differing needs of an
AS/400 installed in China and one installed in Holland. Each machine would need different alphabet
characters, different displays of the time and date, and probably different security levels and hardware.
A user must have proper authority to change a system value; in many installations only the security
officer has sufficient authority to make these changes. However, operators must be aware of many of the
nearly 100 system values, because these values provide a convenient method for modifying small
portions of the operating system they control how a given command, or even the entire system, will
perform. Particular system values control system performance; others define the security levels; yet
others simply provide defaults to command options that were unspecified. System values can be divided
into eight categories: Date/time, editing, system control items, library lists, allocations, message logging,
storage values, and security values.
Consider the date system value QDATE, which may be either a 5-digit or 6-digit field. A 6-digit field
could hold a date such as 11-28-96, while a 5-digit field would be used for a Julian date. Julian dates
have no days or months; instead, they contain a single value for the day of the year. For example, the
first day of January expressed as a Julian date is 1, while December 31 is 365 (or 366 in a leap year).
Another system value is QYEAR, which would hold only the year value in this example, 96.
QDATFMT (an editing system value) defines how your machine will use the date value. Several options
are available for this, including mm-dd-yy, used for most reports; yy/mm/dd, convenient for sorting; or
dd:mm:yy, used in military format, and in many European countries. You can also customize the type of
separators; the previous examples show three such options the hyphen, the dash, and the colon.
The time value, QTIME, represents the system time of day. It comprises three other system values,
QHOUR, QMINUTE, and QSECOND. QHOUR is based on a 24-hour clock. For example, 1:00 p.m. is
13. The system value QCURSYM determines the currency symbol, which is country dependent; for
example, the yen, lira, franc, and dollar use different symbols.
Control Language
Control Language (CL), an integral part of OS/400, is a set of commands by which users control
operations and request system-related functions on the AS/400. A CL command usually is made up of
three-character words; up to 10 characters (usually three words) can be merged together to form
commands. For example, in CL, work is abbreviated as WRK, system is abbreviated as SYS, and status
is abbreviated as STS. The command WRKSYSSTS, therefore, is translated as Work with the System
Status. CL commands can be entered on the command line or executed from within a program. When
commands are entered via a program or menu, the user selects options that are displayed in more
friendly, English-type format. The program then translates the selected option into the appropriate CL
command or commands. We will discuss CL commands further in Chapter 3.
Every item stored on the AS/400 is considered to be an object. Because every stored item is an object,
backup and restore procedures become more manageable. Objects are categorized by type, which allows
the user to specify what types of objects are required for a given task or backup procedure. Objects
include data files, user profiles, job queues, message queues, print queues, compiled programs, word
processing documents, menus, and so on. Some file objects may contain other items, called members,
depending on the characteristics of the main file object.
Each object is assigned an owner when it is created. The owner is either the user or the group profile that
created the object. When the object is created, the owner is given all the object and data authorities to
that object. If ownership of the object is given to another user profile, the original owner has the option
to keep all the object and data authorities the same, or to remove all authority to the object. If the
creating user has specified that the group profile should be the owner of the object, then all members of
the group profile have authority to the object. If the owner of an object is a group profile, then any user
assigned to the group may add, modify, or delete records in the object, assuming all data authorities are
provided. This feature is helpful when data sharing is necessary. Consider a company that takes orders
by telephone. Each clerk taking orders would need to access all the customer records, so each clerk must
be a member of a group profile that includes authority to the object containing customer records. We
will present additional information about group profiles in Chapter 2.
Objects on the AS/400 exist within a special object called a library. A library acts as a holding area for
related objects. The AS/400 uses a library in much the same way that personal computers use
directories. Libraries and directories are holding areas for related material. For example, one library
might be dedicated to payroll programs, another to inventory control. Libraries generally contain many
other objects. Unlike directories, however, libraries cannot contain other libraries (with one exception
library QSYS, discussed below). To find an AS/400 object requires the name of the library and the name
of the object. The AS/400 identifies objects by their qualified name, which takes the form LIBRARY/
OBJECT. For example, to reference the EMPMASTER file in the PAYROLL library, youd usually refer
to PAYROLL/EMPMASTER.
IBM supplies several libraries with the AS/400; some of these libraries contain the objects that make up
the operating system; others hold the programs, data files, and other objects that make up licensed
program products, such as language compilers, or OfficeVision. Independent software vendors also
supply their own libraries with the objects that make up their applications. You can also create libraries
to hold your own organizations programs and data files. Most IBM-supplied library names begin with
the letter Q. Therefore, you generally should avoid creating libraries with a first letter of Q. Figure 1.2
lists the common AS/400 libraries.
QSYS is the system library for the AS/400. It contains the programs and other objects that make up the
operating system. QSYS must exist on an AS/400 for the system to work. Other libraries on the AS/400
exist within the context of the QSYS library; it is the only library that can contain other libraries. A few
special objects, such as user profiles and I/O configurations, can exist only within QSYS. You should
never modify or delete any object within the QSYS library, because the operating system might stop
working if you do. Only in unusual circumstances would you ever add an object to QSYS; you would
normally create objects only within a user-defined library.
QUSRSYS is a library where user objects can exist and also be available to the system. QUSRSYS is
frequently used to hold message queues for individual users and to hold a common message file for an
applications error messages.
QHLPSYS contains the on-line help information that is displayed when the Help key or the extended
help function keys are pressed.
QGPL is the general-purpose library that contains IBM-provided objects. The system places newly
created objects that are not specifically placed in a distinct library in QGPL. User objects that are
inadvertently placed in QGPL should be moved to the appropriate user library.
QSPL holds the spooled, printed output pages that have not yet been printed. As system operator, you
should not manipulate the QSPL program or command files.
OfficeVision for OS/400 and Client Access for OS/400, both licensed IBM products, use QDOC to
contain folders and documents. OfficeVision for OS/400, PC Support/400, and Client Access for
OS/400 use folders and documents to store the users work. You can also use PC Support and Client
Access to upload/download or convert files from the AS/400 EBCDIC format to DOS (ASCII) format.
QTEMP is a library that is created for each job. Each time a user signs on, the system creates a QTEMP
library for this interactive job. If the user submits a job to the batch queue, another QTEMP library is
created for the batch job. The QTEMP library is deleted when the job ends. QTEMP is used to store
temporary objects, such as work files, that a job might need. Because each jobs QTEMP is deleted at the
end of a job, any objects in QTEMP will also be deleted. QTEMP objects are private to a job. A job can
access only those QTEMP objects in its own QTEMP, not those in any other jobs QTEMP libraries.
Most AS/400s contain the QSYS, QUSRSYS, QHLPSYS, QGPL, QSPL, and QDOC libraries. These
libraries are usually required to run the system and support common user needs. With the introduction of
OS/400 Version 3, Release 1, multiple new system libraries and directories are included for the
integrated file and system programs. You can generate other IBM libraries, depending on the IBM
products your organization purchases. Product libraries contain IBM licensed program products that are
self-contained software packages, and each product resides in a separate library. For example, the
RPG/400 compiler and RPG/400 support programs are loaded into the QRPG library.
In most installations, the system administrator creates user libraries. User libraries are commonly created
to hold one individuals work; for example, each programmer should have his or her own user library.
The administrator can create as many user libraries as are convenient; the only limit is the amount of
disk space available in DASD.
Queues
Objects that are of special importance to operators are queues. Queues are holding areas for messages,
printed reports, batch jobs, and other work that is waiting to be received, released to the CPU, or
accessed by a specific user. For example, when a message is generated and sent, it is then retained in the
users message queue.
Message Queue, *MSGQ, is an area for holding messages. Users may choose to delete unneeded
messages after they have read them. The system automatically creates message queues when the user
profile is created.
Output Queue, *OUTQ, is a holding area for reports that are waiting to be printed. We will discuss
output handling in detail in Chapter 5.
Other Objects
A message file has an object type of *MSGF. Message files hold predefined message texts and their
corresponding message numbers. When a program detects an error, rather than display a message
number, the system shows a predefined message text to the user. The text may suggest appropriate
actions to correct the error or it may direct the user to contact the computer center. The system message
files include QCPFMSG and many more in the QSYS library. Some program products have their own
message files; for example, the RPG compiler holds messages in the QRPGMSG message file in library
QRPG. All together, there are more than 26,000 predefined messages. A common example of a
predefined message is Device STAT1 is no longer communicating.
Documents, which are object type *DOC, must be stored in the QDOC library. Documents typically are
word processing letters, memos, and other types of text files, including files in PC formats. Document
library objects can be processed by OfficeVision for OS/400, PC Support/400, or Client Access for
OS/400.
Folders, with object type *FLR, are objects similar to paper folders in the respect that they are a
container of other documents. All folders have a name and reside in a library. Folders are processed by
Journal and the Journal Receiver, with object types *JRN and *JRNRCV, are objects that record events
that have happened in the system. Any file may use journaling; but generally database file operations
such as adding, deleting, or changing records are tracked automatically whenever the journaling system
is active. Changes are recorded in a journal object to provide an audit trail of modifications.
Menus, which have an object type *MENU, are objects used to list a choice of predefined or related
activities. Each activity is displayed on the screen and the user chooses an option. The menu program
then runs the users choices by calling the appropriate CL commands and other programs. Generally,
menus have message files associated with them to explain any errors or problems to the users.
Programs, having an object type *PGM, are objects stored in machine language for faster execution. The
*PGM object is not a displayable file but has a source file object linked to it. The source is written in
languages such as RPG/400, COBOL/400, or CL; the source file is displayable.
Key Terms
Review Questions
Exercises
1. Access the user profile by typing DSPUSRPRF on any command line. A screen showing the
fields User Profile, Type of Information, and Output will be displayed. Type your user profile on
the User Profile line and press <Enter>, then press the <Print Screen> key to copy the user profile
to your queue. Print the user profile, write your name on the printed list, and turn the results in to
your instructor.
2. Access the system values by typing DSPSYSVAL on any command line. A screen that
includes the options of System Value and Output will be displayed. Place the cursor on the
System Value field and use the prompt function <F4> to get a list of system values that can be
displayed. Type QACTJOB and press <Enter>. Use the <Print Screen> key to copy the
QACTJOB screen to your queue. Press <Enter> to return to the command line. Print the screen,
write your name on the printed screen, and turn the results in to your instructor.
3. Press the <F9> key (Retrieve) to display the last command that was executed. Arrow over to
QACTJOB and change this to QBASPOOL. Press <Enter> to display the system values. Use the
<Print Screen> key to copy the QBASPOOL screen to your queue. Press <Enter> to return to the
command line. Print the screen, write your name on the printed screen, and turn the results in to
your instructor.
Chapter 2
Security
Objectives
To understand
Security
Information is one of a companys most valuable assets. Imagine attempting to process an order with
only the customers credit card slip, while the file with the customers name, address, and product order
numbers were lost. What if the companys inventory was in multiple warehouses throughout the country
and the inventory file was destroyed? Imagine trying to pay suppliers if the accounts payable file had
been corrupted. Realistically, loss of the corporate database may cause a business to fail. Security isnt
just a matter of proper backups; rather, it requires comprehensive thinking. Envision a jeweler putting
the gold and diamonds into a vault at night. The next morning, the jeweler can open the vault, look
around and determine whether any items were stolen. Now picture the computer center manager,
looking at the disk drives. Unlike the jeweler, the manager cant be sure that the data files werent copied
and sold to a competitor. Keeping the corporate data confidential and accurate is of utmost concern in
maintaining a successful business.
Security has three separate aspects: physical security of the hardware, backup of the data files, and
prevention of unauthorized access to the data files. Physical security of the system unit, display stations,
and printers must be part of any security considerations. The AS/400 includes a key lock to help prevent
unauthorized access to the functions on the control panel of the system unit. Data-file backup media
should be stored off site to avoid damage or loss of information in the event of disaster (flood or fire) to
the system unit, or any event that involves data loss. Backup and restore are such important topics that
we devote Chapter 7 to the subject. But in todays world of connectivity, fire and floods pale when they
are compared to the risk of corporate data being accessed by unauthorized outside users. Security
violations within the corporation are often unintentional incursions by employees; nonetheless, such
violations can cause many problems.
The AS/400 security system allows a wide range of configurations to control and monitor authorized
user access both on-site and via outside connectivity. The AS/400 security system is built into the
operating system, allowing for consistent security between the operating system and other licensed
programs. This configuration ensures that an application program cannot easily bypass security, because
the security features are integrated into the operating system.
The AS/400s operating system provides several methods using many different tools to create a secure
environment. System values, security levels, assistance levels, user profiles, group profiles, and
authorization lists work together to allow the manipulation and control of data on the AS/400. Higher
security levels require a user to sign on with a predefined, unique user ID and a password. The user ID
can be defined in a user profile created for each user. System values work with the user profile by
supplying default values for assistance-level and group-profile parameters when a user profile is created.
System Values
As we discussed in Chapter 1, system values are attributes that can change how the entire computer
system functions. Some system values can be used within other commands if *SYSVAL is specified as
the parameters value. The operating system uses the contents of the corresponding system value to
execute the command. For example, the security audit journal, QAUDJRN, is provided with the
operating system. The system value that determines what is logged in the audit journal is QAUDLVL,
the audit level system value. Some of the values that can be specified within QAUDLVL are *NONE to
inactivate the auditing function, *AUTFAIL to log authority failure events, *CREATE to log when
objects are created, *DELETE to log when objects are deleted, *JOBDTA to log job start, stop, and
disposition information, *OBJMGT to log when objects are moved or renamed, *PGMFAIL to log
system integrity violations, *SAVRST to track restore operations, and *SECURITY to log security
changes and related functions. There are also a number of other options that provide a full range of
security auditing.
The QCRTAUT (System Default Create Authority) system value determines the public authority of a
new object. This system value usually works in conjunction with the CRTAUT (Create Authority)
parameter of the library description where the new object is being placed. The public authority values
consist of *CHANGE, *ALL, *USE, and *EXCLUDE. The public is considered any valid AS/400 user
who did not create the object. Those users with public authority can change newly created objects if the
authority value is *CHANGE, but they can only view objects if they have been granted the *USE
authority value. These users are not allowed to view or change an object with the *EXCLUDE value. If
you create an object with *ALL public authority, public users have complete control of the object. The
*CHANGE value is recommended for this system value, because several IBM-supplied libraries
CRTAUT parameter value is *SYSVAL, and *CHANGE is required for some operations. Additionally,
some objects located in the IBM-supplied libraries must be accessed before users are allowed to sign on.
Certain system value changes will be effective immediately; more frequently, however, the change will
become effective only after the next system IPL.
To monitor a users profile and password, the system value QDSPSGNINF (Display Sign-on
Information) can be activated. This system value lets you show the user additional sign-on information
each time s(he) signs on to the system. The sign-on information includes the date of last sign-on, the
number of any sign-on attempts that were not valid, and (if there are fewer than seven days remaining)
the number of days until the password will expire. A value of 0 for this parameter specifies that the sign-
on information is not to be displayed. A value of 1 specifies that the sign-on information is to be
displayed when the user signs on to the system.
To foil unauthorized users from attempting to sign on to the system, the maximum sign-on attempts
system value, QMAXSIGN, can be used. The maximum number of consecutive invalid sign-on attempts
allowed is stored in the QMAXSIGN system value. When the specified value is reached, an action
specified in the QMAZSGNACN system value is executed. The possible actions are to disable the
device, disable the user profile, or disable both the device and the user profile. Valid entries for the
QMAXSIGN system value are 1 through 25 and *NOMAX. Three sign-on attempts are recommended to
allow authorized users enough attempts to correct typing errors before the system disables the device.
See Appendix A for information about how to reactivate the device.
System values also determine what action the system should take if a user forgets to sign off a
workstation. The QINACTITV (Inactive Job Time-Out Interval) system value specifies how long an
interactive job can be inactive before the system should intervene. The QINACTMSGQ (Inactive Job
Message Queue) system value dictates what action the system should take when the QINACTITV
parameters value has been reached. If the QINACTMSGQ value is *ENDJOB, the job is terminated. If
the QINACTMSGQ system value is *DSCJOB, the job is suspended and the workstation returns to the
sign-on screen. The suspended job can be resumed if the same user signs on to the same workstation.
The QDSCJOBITV (Disconnected Job Time-out Interval) system value determines how long a job can
remain suspended before the system ends it.
System values control how the system reacts during a power failure. The system value QUPSMSGQ
(Uninterruptable Power Source Message Queue) determines the queue to which power-related messages
will be sent. The system value QUPSDLYTIM (Uninterruptable Power Source Delay Time) specifies
how long to wait on standby power before powering down the system. The system value QPWRRSTIPL
(Power Restart Initial Program Load) determines whether the system should begin an automatic IPL
when power returns. To help clarify the QUPSMSGQ and QUPSDLYTIM system values, the
Uninterruptible Power Supply (UPS) referenced in each value is a battery pack. You can purchase a UPS
with enough batteries to keep your system running for 30 minutes and longer. For example, a hospital or
police dispatch that runs on an AS/400 may require a UPS with battery packs for 48 hours. Therefore,
the UPS-related system values must be defined according to the UPS your company has purchased. Lets
assume that your companys UPS has 12 hours worth of power and that shutting down the machine takes
90 minutes. In this case, it might be wise to set the QUPSDLYTIM system value to begin the shut-down
after 10 hours on the UPS battery packs.
Security Levels
OS/400 supports five security levels. Each level has varying degrees of security support (see Figure 2.1).
Each increase in the security level increases the safety of objects, but it also makes sharing objects more
difficult. The system value that activates the security level on the AS/400 is QSECURITY. A summary
of security level descriptions, based on the system value QSECURITY, is shown in Figure 2.1.
You can find out the security level of the system you are working on by using the DSPSYSVAL
(Display System Value) command. For example, to display the screen shown in Figure 2.2, perform the
following sequence of steps:
Press F4 to prompt
Type QSECURITY
Press Enter
As you can see, this system operates with level 30 security, meaning passwords and object authority are
verified for each request.
Press F3 to "Exit"
Assistance Levels
You can minimize user mistakes by eliminating menu items and function key options that do not relate
to the users job. The systems assistance levels customize the users view of the displays with additional
information or with information in less technical terms. Three assistance levels are supported on the
AS/400. The basic assistance level, *BASIC, provides an Operational Assistant interface for beginners
using friendly, non-technical language. Intermediate assistance level, *INTERMED, uses the system
interface with more functions available; *INTERMED is for users more accustomed to technical
computer terms. Advanced assistance level, *ADVANCED, uses the expert system interface.
Frequently, the *ADVANCED level does not display the option numbers and the function keys. The
advanced assistance level is for sophisticated users familiar with commands and function key activities.
The system value for assistance level is QASTLVL.
The assistance level can be changed on any display that allows the use of the F21 function key, or with
the commands that have the assistance-level parameter. Not all displays have more than one assistance
level. The Operational Assistant interface retains different assistance level values for the following
groups of displays: Printer Output, Printers, Jobs, Handling Messages, Device Status, User Enrollment,
and System Status. If the user signs off the system, the current assistance level for each display remains
stored until the user signs on and changes it. If the assistance levels system value is not suitable for a
users needs, the user profile can be modified to override the system value.
The user profile is an object that defines system access for the user: what objects can be accessed, what
libraries can be used, what authorities are assigned, and to what special groups the user belongs. When
your system is set at security level 20 or higher, the user profile must be created before the user can sign
on. The user profiles User ID value can be up to 10 characters in length, but it cannot begin with a
number. OS/400 is not case sensitive, and it will display user profile listings in alphabetical order
regardless of whether the entries are uppercase or lowercase. Several IBM licensed programs, including
Client Access for OS/400, suggest limiting the User ID to eight characters. This limitation is mandatory
when you are linking to certain communications networks.
A user profile must be generated for each user before a user can access the system. Security level 10
automatically generates the user profile before a new user finishes the sign-on process. A problem with
how security level 10 generates the user profile, however, is that the new user profile will be generated
even if the user misspells his or her sign-on name. Systems using security levels 20, 30, 40, and 50 must
have the user profile completed by the Security Officer or System Administrator before the users first
sign-on.
The user ID and password are combined to complete the sign-on process. User IDs and passwords
should be kept private. For security reasons, it is recommended that passwords should exceed several
digits in length, because longer passwords are harder to guess. The password length is determined by
two system values, QPWDMAXLEN (Password Maximum Length), and QPWDMINLEN (Password
Minimum Length). A value from 1 to 10 is allowed, but a minimum of five characters is recommended.
Like the user ID, the password may not begin with a number. A users password cannot be displayed on
the AS/400. If the user has forgotten his or her password, the Security Officer or System Administrator
can modify the user ID, giving it a new password. For convenience in this situation, the password is
generally changed to the same characters as the user ID value; the user should then choose a new
password when (s)he next signs on. See Appendix A for more information about how to modify a users
password.
The user profile information will be displayed, as shown in Figure 2.3 and Figure 2.6. These figures are
the first and second pages of the Display User Profile screen generated by the DSPUSRPRF command.
We will discuss only the entries in these figures that are of concern to the system operator.
Figure 2.3 Display User Profile Screen at the Basic Assistance Level
The DSPUSRPF (Display User Profile) command provides such information as the date and time of the
previous sign-on, and sign-on attempts that were not valid. This information could assist in verifying
unauthorized access. For example, this field may show sign-on attempts during a time period when a
user was on vacation or otherwise not available to use the system. To monitor whether an unauthorized
person has been attempting to gain access to the system, the number of invalid sign-on attempts is
included in the information retrieved by the DSPUSRPF command.
The Status field determines whether the user profile is valid for sign-on. Possible parameter values are
*ENABLED and *DISABLED. The profile must be enabled to allow the user to sign on. To enhance
security, a users profile may be disabled while (s)he is on vacation or for whatever reason is not using
the system for a period of time.
The Date password last changed field and the Password expiration interval field help determine whether
users should change their passwords. If the password is not modified before the preset interval, the
operating system will display the Change Password screen. The Password expiration interval field can
use *NOMAX if no change is required, *SYSVAL to use the predefined value from the QPWDEXPITV
system value, or any number from 1 to 366 to denote the number of days a password will remain valid.
The Set password to expired field can be defined as *YES to force the user to change his or her
password. You use this field in conjunction with the Set password to expired parameter when you are
creating a new user profile. When the Set password to expired system value is *NO, the user is not
prompted to change his or her password and may continue to use the current password indefinitely.
Assuming that the system security is at level 30 or higher, there are five user profile classes: security
officer (*SECOFR), security administrator (*SECADM), programmers (*PGMR), system operator
(*SYSOPR), and system users (*USER). Each user profile class has special default authorities based on
the security level. Unless users specifically need to use other system functions, their user class should be
set to *USER. The *USER user profile class results in a modified view of the menu and limits the use of
certain commands. Reducing options and commands for most users should not, however, be considered
detrimental or punitive; rather, such management allows users to focus on their actual job functions.
With the *SYSOPR user class, the system operator can perform tasks such as backing up libraries and
objects, restoring objects from tape, or powering down the system. Usually, a system operator will
monitor a special message queue, named QSYSOPR. The QSYSOPR message queue receives the
system error messages, and informational messages about the batch jobs that are running or about jobs
that have special needs. For example, a job may request that invoice forms be loaded into the printer.
This type of message will be sent to the QSYSOPR message queue. Because batch jobs are disconnected
from the interactive user who started the job, batch jobs also are handled by the system operator. If a
batch job requires additional information or has special instructions, the request is sent to the QSYSOPR
message queue.
Each object, whether it is a library, a menu, or a queue, has authorities attached to the object. These
authorities are the normal authorities and can be *ALL, *CHANGE, *USE, or *EXCLUDE. *ALL
authority gives the user the ability to create, delete, or modify the object. *CHANGE authority lets the
user modify the object but does not allow the user to delete the object. *USE authority gives the user the
right to view the object, but nothing more. *EXCLUDE authority removes all rights to the object,
including the authority to view the object.
The Special authority field in Figure 2.3 extends the actions a user can be authorized to perform on the
system resources or on groups of objects. These authorities include saving the system, controlling other
users jobs, using the system service tools, controlling spooled output files, and creating user profiles.
Multiple values are possible for the Special authority field. The system value *USRCLS (user class) can
be used to grant a user the authorities that correspond to that individuals user profile. The *SECADM
special authority name can also be used in this parameter. If the user needs no special authority, you can
use the value of *NONE. (*NONE is normally used with a group profile to define the groups
authorities.)
Individual authority values can be entered in the Special authority field. The various authorities and their
associated actions are shown in Figure 2.4. The User Class column lists the user classes that include a
special authority by default (at security level 30).
A group profile is similar to a users profile except it gives the same set of authorities to multiple users. A
user whose profile is a member of a group profile generally has the same authorities as the group. In rare
instances, a user profile may be defined to override the authority of the group profile. Group profiles are
frequently created to provide every user in the department with the same authority to the same objects.
When a group profile is connected to a user profile, the user is automatically granted object management
*OBJMGT and *CHANGE authorities to the group profiles objects.
When an individual user creates an object, ownership of the object is clearly defined. However, when a
member of a group creates an object, the ownership can be confusing. The Owner parameter in the user
profile is employed to aid in defining ownership of any objects the user creates. Ownership values can
be *USRPRF (when the individual user owns any newly created objects) or *GRPPRF (when the group
profile is considered to be the owner of all newly created objects).
The Group authority field in the user profile works in conjunction with the Owner field in the group
profile to further define ownership of newly created objects. See Figure 2.5 for further explanation.
As Figure 2.5 suggests, using the group profile allows more flexibility in the security scheme and is less
complicated for the security officer or system administrator responsible for managing a large number of
profiles.
Press F3 to "Exit"
As we discussed earlier in the chapter, the ASTLVL (Assistance level) parameter defines the assistance
level for the user profile, and it can be *SYSVAL (as shown in Figure 2.6), basic, intermediate, or
advanced. The ASTLVL parameter initiates control at sign-on and functions for all commands executed
from the command line. The *SYSVAL entry refers the user profile back to the QASTLVL system
value. If the QASTLVL value contains the basic assistance level, the user profile will be set at the basic
assistance level. A menu may have a separate assistance level value. Operational Assistant has a
predetermined value, but the user can override the initial value by requesting a different assistance level.
Figure 2.6 Display User Profile Screen at the Basic Assistance Level
HINT:
In Figure 2.6, the current library is listed as QSYSOPR. This library is not shipped with the
computer, but the authors have found that creating a common library for the operators on the
various shifts can be quite helpful. The shared library also provides a single location for custom-
built programs or menus that make the operators functions easier.
The Current library value specifies the name of the current library for the user. The current library is
where any new objects that the user creates reside by default. The system will search the current library
before it looks for information in any other user libraries. The *CURLIB value is used in many other
commands. *CURLIB is accessed from the user profiles Current library value. The CRTDFT (Create
default) command specifies that the user has no current library. If the *CURLIB value is used with the
CRTDFT command, the QGPL library becomes the current library. As we discussed in Chapter 1,
QGPL should be reserved for IBM needs. Therefore, you should avoid using *CRTDFT. Specifying a
library name for this parameter helps users save new objects in the proper library. Any library can be
specified as the current library. You can use the current library to enhance system organization; however
a user can place new objects into any library to which (s)he is authorized. Before you can specify a
current library for a user, you must have already created the library.
The Initial program field determines the program to be executed immediately after sign-on is completed.
Any valid program name can be used. The Library value is the library that contains the program. For
example, consider the accounting staff at a hospital. The bookkeepers may prefer that when they
complete sign-on, the billing program is displayed automatically.
The Initial menu field determines the menu displayed after sign-on. The available options include
MAIN, the AS/400 systems main menu; SYSTEM, the menu for operational tasks; or any valid menu
name. If the value of *SIGNOFF is entered, the user is automatically signed off the system after the
initial program completes. *SIGNOFF can be used to lock a user into only one program, thus enhancing
security. OfficeVision/400 users can use this field to go directly to OfficeVision/400 and bypass the
initial menus.
Press F3 to "Exit"
The User Profile screen includes many other parameters you can make use of; the few items we have
discussed here only introduce you to the power of the AS/400s security system and the user profiles
place in that system.
Job Descriptions
A users job description is another aspect of security. A job description can be attached to a single user or
it can be assigned to a group of users sharing the same authorities and job requirements. Job descriptions
should be set up for batch jobs to control how those jobs will enter the operating system.
A job description includes attributes such as where the job is executed, the priority of the job, the printer
to be used (if printer output is part of the job), and how message logging is to be handled. The use of job
descriptions provides flexibility and control over the jobs execution. IBM supplies some job
descriptions, such as QBATCH or QPGMR; you can also create your own job descriptions.
HINT:
A job description should be created for any user who can submit a batch job. Creation of the job
description will prevent future batch job problems.
Two Control Language (CL) commands relate to batch jobs: The BCHJOB (batch job) and SBMJOB
(submit job) commands can override the values in the job description. A user profile name, usually that
of an interactive user, is required to start a batch job. However, in a batch job situation, the user who
scheduled or started the batch job is disconnected from the job once the job is submitted.
The job description information will be displayed, as shown in Figure 2.7. As with the User Profile
information, we will discuss only the entries that are of concern to the system operator.
On the Display Job Description screen, the name of the job description and the associated library are
displayed. The User profile parameter is shown as *RQD, indicating that a valid user ID must be
associated with the job description.
The CL syntax check parameter allows you to check the syntax of CL commands as you submit the job,
rather than when the job actually runs. In Figure 2.7, no checking will occur until the job runs. By
specifying an option here, a job description can provide for early diagnosis of syntax errors. The CL
syntax check program assigns numeric values to an error based on the severity of the error. Values of 00
through 99 are possible, with zero indicating the least serious error. By specifying a value 00-99 in this
job description parameter, you can control how serious a syntax error must be before it ends the
processing of the job. In most instances, the End severity level of 30 is appropriate.
A job will automatically be held on the job queue if the value of the parameter Hold on job queue is
*YES. If a job is held on the job queue, the batch job will not be run until it is released by an authorized
user or operator who has *JOBCTL authority. This is a valuable option when you are submitting large
batch jobs and holding them until a later (and probably less busy) time. The default for this value is *NO
and informs the operating system to process the job when it reaches the top of the job queue.
The Job date parameter is the date on which the job was started. If *SYSVAL is the value of this
parameter, the date stored in the QDATE system value is used.
The Job switches parameter specifies the initial settings for a group of eight job switches. You can use
these switches to control the flow of programs. The initial setting for the Job switches parameter is all
zeros (or all off). Programmers can modify these switches to call CL or other high-level programs,
depending on the circumstances. Job switches are a remnant from the punch-card era of computing and
are rarely used in todays processing.
An inquiry message is a message that requires a response from the user or operator. The Inquiry
message reply parameter determines how inquiry messages are to be answered. The options for this
parameter are *RQD (require a reply), *DFT (reply with the messages predefined default reply), or
*SYSRPYL (reply with a reply stored in the system reply list). Normally, *RQD is used so that the
inquiry messages are displayed with the various answer choices. If *RQD is specified, the messages
must be answered before the job continues running. The *SYSRPYL value tells the operating system to
check the system reply list for an answer. If a reply is located, the system uses the reply just as if the
operator had entered it. The reply list commonly is used when the system is retrying a failing device or
restarting a communications line that has gone down. These conditions do not necessarily require an
operator to input the answer.
When a job is submitted to batch, the Job priority parameter determines the scheduling priority for this
job on the job queue (i.e., its relative position in the line of jobs waiting to execute). The highest job
priority is a 1, with the lowest priority being a 9. If two batch jobs are submitted to the job queue at
nearly the same time, the job priority parameter will determine which job will be executed first. If the
two batch jobs have the same job priority, the job received on the queue first will be processed first,
assuming that no higher priority job is in the queue.
The Output priority parameter determines the priority for spooled files to be printed. As with job
priorities, the highest priority is a 1 and the lowest priority a 9. If a spooled output file with priority 3 is
received at the same time as a spooled output file with priority 6, the spooled output file with priority 3
will be sent to the printer first. If two job descriptions have the same priority specified, the first job on
the queue will be printed first.
Most computer centers use various printers for different reports. The Printer device parameter in the job
description specifies which printer will receive the spooled output from a job. If the *USRPRF value is
used, the printer specified in the users profile will receive the output. This parameter allows a user to
change printers as needs and conditions vary.
The Output queue and Library parameters determine where the spooled output files will be stored until
the files are sent to a printer. Allowing multiple output queues to hold spooled files helps keep both the
user and the operator organized. If the parameter value *USRPRF is entered, the value specified in the
users profile will determine the output queue that will receive the spooled files.
Press F3 to "Exit"
Library List
The library list provides an effective method to help programs locate objects on the system. If a program
or a user doesnt specify an object by qualified name (library/object), the system will search the library
list to locate the object. Standardized library lists can be specified by name, or the QUSRLIBL and
QSYSLIBL system values can be used. The system searches only the libraries included in the library list
on the Display Library List screen to locate objects the user has requested. The libraries are searched in
the sequence in which they are listed.
The Display Library List screen, as shown in Figure 2.8, lists the library search path. The library name,
text description, and the library type are displayed. The operating system uses standard abbreviations for
library types. A system library is identified by SYS. A production library is identified by PRD. A users
current library is identified by CUR, and other user libraries are identified by USR.
Option 5 offers an easy way to determine whether an object is located within a users library. When you
specify this option for a particular library, a list of all the objects in the library and the library name will
be displayed. This display is functionally similar to the DOS directory list. If two objects share the same
name but are located in different libraries (and both libraries are included in the library list), when the
first object is located from the library placed highest in the library list, the search will be concluded.
Press F3 to "Exit"
Using the library list does not prevent a user from accessing objects in libraries not included in their
library list. If a user has authorization and specifies the correct name of any library, the operating system
will search the library for the listed object. To prevent unauthorized use of a library or other objects,
object authority must be limited for each object that requires protection.
Authorization Lists
OS/400 offers great flexibility in creating an environment where users can access the same library but
have individual limitations to the objects within that library. For example, the payroll administrator
should have access to all payroll information, yet another user with the same group authority as the
payroll administrator might only need access to monthly totals for reports. The payroll administrator
should be given all rights to the objects within the payroll library. On the other hand, the user should be
given read-only authority to payroll objects and perhaps no authority to salary items. Authorization lists
facilitate establishing differing access for multiple users to the same object. Authorization list authority
can be granted to the public, to a group of users, or to an individual user. An authorization list must exist
in QSYS and can be attached to any number of objects.
For example, consider a group of users in this case, all members of the same department. The security
administrator can create an authorization list for the members of the department to have access to their
departments data. By generating one authorization list, it is easier for the security administrator to add
and delete authorized employees to and from this list.
Authorization lists also are helpful when objects need to be set at different levels of authority for a
specific group of users. Consider the following situation: The company president has approved a new
procedure for the accounts receivable department. This object needs to have *PUBLIC access, but other
departments should not be bothered with the new procedure. In this case, the authorization list can
provide the *PUBLIC authority to the group profile of the users in the accounts receivable department.
The authorization list provides access to the accounts receivable department but only this department,
thus solving many issues with one authorization list.
Press Enter
(Ask your instructor to provide the name of a valid authorization list.)
Authorization lists (*AUTL) are objects created to simplify security access to other objects, as shown in
Figure 2.9. The authority listed for a user in the Object Authority column indicates a users authority to
an object secured by this authorization list. An X located in the List Mgt column denotes that the user
has been granted authority to manage the authorization list. Management includes adding and deleting
users authorized to the list.
The Display Authorization List screen (Figure 2.10) shows the further details about authorities allowed
for each user included in this particular list.
As shown in Figure 2.10, the right side of the screen relates specifically to the objects controlled by the
authorization list. There are five types of authorities. Object operational (Opr) authority allows users to
access the object as specified by the objects data authorities; we discuss these authorities further in
Figure 2.11. Object management (Mgt) authority allows the object to be moved and renamed, and it
allows members to be added to the object. Object existence (Exist) authority allows the object to be
deleted, or removed from existence. Alter (Alter) authority allows changes to the attributes of an object,
such as adding or removing triggers for a database file. Object reference (Ref) authority allows for
modification of how the object is related to other objects.
OS/400 supplies predefined object authority values to use for individuals or for groups. All authority,
*ALL, allows users full authority to operations on an object. Change authority, *CHANGE, allows the
user to change, modify, or view an object. Use authority, *USE, allows the user to only view
information in the object or execute a program object. The *EXCLUDE value grants no authority to or
use of the object.
Authority to an object is divided into two categories: object authority and data authority. Object
authority determines what specific functions can be applied to the entire object. Data authority usually
applies to the operations (generally read, add, change, or delete) allowed on the contents of an object
that contains data. A users authority can also be custom defined with object and data authority
classifications, such as those listed in Figure 2.11. Data authority, as shown in Figure 2.11, has five
classifications.
Press F3 to "Exit"
The DSPOBJAUT (Display Object Authority) command allows the operator to view the authorized
users for an object. This approach is the reverse of that for viewing the user profile, group profile, or
authorization list. In the previous material, the operator always viewed access from the user at the top to
the data object at the bottom. With the DSPOBJAUT command, the operator is looking from the bottom
upward. Assume that a user is receiving an error message saying that the user does not have access, or is
unauthorized, to the object. The operator would likely find it helpful to review the objects authorities.
The operator must have the authority to use the DSPOBJAUT command.
You must specify the name of the object, along with the library in which the object is located, and the
object type. There is an option to view on-screen or to print the output.
HINT:
Position the cursor on a field you may have questions about, then press the F4 function key. A list
of the available options will be displayed.
The Display Object Authority screen, as shown in Figure 2.12, displays the authorities allowed for the
user.
HINT:
Press the F11 function key to view details of the screen (similar to the detail shown in Figure 2.10
on page 33).
If a user owns an object, the user should have all authorities to that object. If the operator wishes to see
all users and their authorities to an object, the operator must have object management authority. The
security administrator can use the DSPOBJAUT (Display Object Authority) command to list all users
and their authorities to an existing object.
Any time access to an object is requested, the operating system examines authorities in a specific
sequence. It is important to understand this sequence, because the system will discontinue the search if
sufficient authority is given at any level of examination. The search path is shown in Figure 2.13.
Your AS/400s security should be configured according to the search path, or a security risk may be
involved. For example, if a users special authority (item B1) to an object is *EXCLUDE, but the user is
also included in an authorization list (item A3) with authority of *CHANGE, the user will have change
authority.
Press F3 to "Exit"
Security on the AS/400 supports many different needs for diverse organizations. Because of the AS/400s
provisions for assistance levels, library lists, and the user profiles first menu option, unauthorized users
can be limited to a narrow view of the system, should they gain access. Through the use of group
profiles and authorization lists, security becomes easier to maintain. The user profile and job description
combine to control both interactive and batch jobs by enforcing the security of the object authorities. A
major advantage of the AS/400 is its capability to let you combine the various objects to create
customized security configurations to meet the differing needs of users.
Key Terms
Assistance Levels
Basic
Intermediate
Advanced
Authorization Lists
Authority Search Path
Current Library
Group Profiles
Job Description
Library List
Data Authorities
*ADD
*DLT
*READ
*UPD
*EXECUTE
Object Authorities
*ALL
*CHANGE
*EXCLUDE
*USE
System Values
Security Level
Level 10
Level 20
Level 30
Level 40
Level 50
Uninterruptible
Power Supply (UPS)
User Classes
Security Officer
Security Administrator
Programmers
System Operator
Users
User Profile
User ID
Password
Review Questions
1. What system value determines the default public authority of a new object?
2. A user profile exists and a password is required at what security level(s)?
3. What parameter in the user profile works with the user class to limit users access?
4. Explain the difference between a group profile and an authorization list.
5. How does a job description affect security?
Exercises
1. Display the system values that determine how the system reacts during a power failure.
2. Display your user profile and determine whether you are attached to a group profile.
3. Display object authority for your library and determine the publics authority for it.
Chapter 3
The User Interface
Objectives
To understand
The AS/400s General System Tasks menu does not apply to the majority of users; it is commonly
displayed as the first screen to those with a user class of *SYSOPR. This menu, as shown in Figure 3.1,
usually will appear as soon as the system operator signs on. Because many of the same tasks are
available through the General System Tasks menu and the Operational Assistant, this text will
concentrate on the more friendly Operational Assistant. Other users on the system are generally shown
the AS/400 Main Menu.
The General System Tasks screen allows you as the operator to accomplish tasks from among the
following options: Jobs; Status; Display system operator messages; Messages; Files, libraries, and
folders; Save; Restore; Device operations; Communications; and other system tasks. You frequently are
the initial contact point for resolving user problems. Therefore, you also need to be familiar with the
AS/400 Main Menu, shown in Figure 3.2.
To access the AS/400 Main Menu from the General System Tasks menu,
HINT:
If there is a name in the top left corner of any menu, you may go directly to the menu by typing
GO (menu name) on any command line; for example, GO MAIN.
After a careful review of the various menu options, you might be concerned that the average user may
have access to areas that do not seem appropriate. But any option the user selects will activate the
security system, and unauthorized users will be denied further access.
Press F3
Operational Assistant
Operational Assistant consists of a series of user-friendly menus that aid the operator in performing
routine tasks: controlling jobs, printer output, message handling, power on/off tasks, and system
backups. You can access the Operational Assistant menu (Figure 3.3) by pressing the Attention key (if
the system value QATNPGM is set to *ASSIST), or by typing GO ASSIST on any command line:
Option 1 of the Operational Assistant menu gives you access to the Work with Printer Output display.
You will be able to view and control all the spooled output printer files for output that has not been
printed. The printing options are covered in greater depth in Chapter 5.
Option 2, Work with jobs, lets you hold, delete, release, display messages, or work with printer output
from the jobs that are running within the system. Chapter 4, Working with Jobs and Message Handling,
covers these topics in greater depth.
Option 3, Work with messages, displays all the messages in the system operator message queue (if your
user profile has been assigned the QSYSOPR message queue). As the system operator, you receive all
messages concerning batch jobs and jobs requiring special attention. Chapter 4, Working with Jobs and
Message Handling, covers these topics in greater depth.
Option 4, Send messages, allows you to send a message to any single user or group of users, whether or
not they are currently signed on to the system.
Option 5 lets you Change your password, permitting a new password to be entered. This option is
limited to changing the password for the user ID that is currently signed on.
Option 10, which lets you Manage your system, users, and devices, is quite versatile. You can display
the system status; run a backup; work with system operator messages, printer output, jobs, signed-on
users, device status tasks; and customize the system, users, and devices. Chapter 6, Device
Configuration, covers this topic in more depth.
Option 11 is used to customize the AS/400 configuration. This option will lead the Security Officer to
other menus to create new user IDs or to edit existing functions. Menus for creating new devices or
changing configurations for existing devices are accessed through this menu option.
Option 75 provides tools for accessing valuable information about procedures to assist in problem
resolution.
Option 80 provides the user or operator with a temporary sign-off. This option is valuable when a user is
required to leave his or her workstation unattended for a period of time when (s)he is in the middle of an
activity or program. A temporary sign-off allows the user to suspend the application, thus saving the
users time because (s)he does not have to pass through all the menus to return to his or her activity, and
system security is maintained. When the user returns to the system, the AS/400 will automatically return
to the application screen that was displayed at the time of temporary sign-off.
If you are in the middle of an application and want to temporarily sign off the system, you must access
the AS/400 Operational Assistant menu. From this menu,
To return to the application that was in use before you accessed the AS/400 Operational Assistant menu,
you must press F3.
CL Commands
The first five Operational Assistant menu options have corresponding AS/400 Control Language (CL)
commands that execute the same programs triggered by the menu options. The table shown in Figure 3.5
displays the commands that correspond to the menu items.
Note: The Operational Assistant Menu does not actually use any CL command to perform its
task, but the SNDMSG command accomplishes a similar function.)
CL consists of more than 1,000 commands that execute OS/400 functions. The naming structure IBM
uses to create CL commands is English-like in nature, which makes the commands easy to comprehend.
CL commands can consist of a verb and a noun, or a verb, an adjective, and a noun. Figure 3.6 shows an
example of the CL command WRKSPLF (Work with Spooled File), which consists of a verb, an
adjective, and a noun.
As you can see, abbreviations are used to construct CL commands. Vowels are rarely used in a CL
command. Figure 3.7 shows a table of the most frequently used command abbreviations.
Many experienced AS/400 users prefer to use commands rather than menus, because this allows them to
access the tasks directly without traveling through the menu layers. In this text we will attempt to
provide both the menu options and the CL commands as appropriate. To enter CL commands, you must
use a command line. If a command line is not visible when you are displaying the Operational Assistant
Menu,
Whenever you enter a CL command, at least three function keys are available to you as the operator or
user. These function keys are F4=prompt, F9=Retrieve, and F12=Cancel.
The F4 function key provides prompting help to view the CL command groups. To access the Major
Command Groups menu,
Figure 3.8 shows the major CL command groups (e.g., object management commands, file commands,
print commands). By choosing a certain command group, you can narrow the search for a specific
command. For example, operators are frequently interested in verb commands because of all the actions
they need to perform on the system.
To access the first screen of a list of verb commands from the Major Command Groups menu,
Press Enter
The Verb Command menu, shown in Figure 3.9, which displays all possible subcategories for verb
commands, requires you to further narrow the search for the appropriate command.
You can continue, pressing the Page Down key to see more verb commands. Lets work through an
example using the Display Commands that operators use quite frequently. Continue scrolling through
the Verb Command menu until you come to item 31, Display commands.
You will now be viewing all the various display commands, as shown in Figure 3.10. You can choose a
command by selecting the corresponding number from this menu.
CL commands do not always need to be typed on a command line. CL commands can be incorporated
into a CL program and programmers can actually create new CL commands. CL programs are similar to
batch files on a PC, but CL programs are much more flexible and sophisticated.
Most CL commands have additional parameters that can be specified if the default values are not
applicable to the job at hand. In fact, some CL commands require that additional parameters be
specified. The Display Command screen (Figure 3.11) lets you view optional and required parameters
for any CL command. To access the Display Command (DSPCMD) screen and see these additional
parameters,
The Display Command screen requires that you enter the name of the command you want to view.
Optional parameters are the library name and the output device. The library name is required if the
library is not contained in the library list. The default output device option (*) lets you view the
information on your workstation screen. If you want a printed copy, change the output option to
*PRINT. If, for example, you wanted to view parameters for the DSPMSG command, you would
All the current assigned parameter values for the DSPMSG command would be shown in the Display
Command Information screen (Figure 3.12).
The parameter values listed on the Display Command prompting screen (Figure 3.11) are defaults or
assigned values. When you type a command on the command line and press the Enter key, the command
will be executed according to the command parameter default values, assuming the command has
required parameters associated with it.
Many times, however, the defaults are not suitable for the task at hand. Pressing the F4 function key
while the cursor is located on a parameter will provide you with more parameter values that you can
choose instead of using the default values. The parameters listed will depend on which CL command is
displayed. Some CL commands have pages of required parameters, and others have none for example,
the Signoff command, which needs no parameters.
Press F3 to "Exit"
For example, lets use a value other than the default message queue value on the Work with Messages
(WRKMSG) screen (Figure 3.13). To access the Work with Messages (WRKMSG) screen,
HINT:
Typing a question mark before the command name on the command line has the same effect as
pressing the F4 (Prompt) key after the command is entered. This is an alternative when you are
accessing a system with a modified keyboard mapping program and the F4 key has another
purpose.
HINT:
You can press the F11 key even if it is not one of the keys shown at the bottom of the screen. You
may press any valid key, whether or not it is shown. As you become more familiar with the keys,
you can skip pressing F24.
When you are viewing a command screen that has been prompted, the keyword and the values are
shown in an English-like format. However, when the command is sent to the operating system for
execution, it is restructured into CL syntax. To redisplay the previous CL command syntax,
Press F9 to retrieve
In this example, there are two parameters: the message queue name and the output method.
Advanced users frequently wish to type their command on the command line and specify the values for
the parameters, rather than prompting the command. To practice entering CL keyword notation, type the
previous CL command on the command line:
Although we specified a value for the OUTPUT parameter, the default is to view the output on screen.
As you have worked through this chapter, you have seen how the help functions and the CL commands
insert keywords and the appropriate values to complete a CL command. If you or other users must
perform the same task more than once, the F9 function key minimizes the typing that would otherwise
be required. The F9 function key will display the previous CL command that was typed, along with the
related keywords. The previous command is saved in a buffer for the users current session. Each time
you press F9, the system will back up an additional command, so you can browse through previous
commands until you find the one you want to repeat. During sign-off, the buffer is cleared.
CL Keyword Notation
A CL command can be broken down into parts. In a simplified form, the command name is followed by
the parameters. Each parameter has two parts: the keyword and the value. Keywords help you learn the
CL commands and their options. Each CL command has a general structure as follows:
Any CL command that has parameters will be structured this way. Each parameter shown in Figure 3.13,
for example, has a keyword associated with it.
In Figure 3.14, the corresponding keywords for each parameter are listed in the center column, with the
default values in the right column. The message queue keyword is MSGQ. The library does not show an
associated keyword and is indented two spaces under the message queue name because it is part of the
MSGQ keyword. The message queue is a qualified name with two parts; first is the name of the message
queue, next is the name of the library. If the library value is not specified, the library list, *LIBL, will be
searched.
Figure 3.14 Work with Messages (WRKMSG) Screen with Keywords Displayed
When you are using keyword notation, the parameters can be in any order. Therefore, the message
command above can also be entered as
Notice that the value for the MSGQ parameter is listed with two parts, the library name and the message
queue name. For technical reasons, when you are using keyword notation, the order of the values within
a qualified name is the reverse of the order for the same qualified name on the command prompting
screen (Figure 3.14).
CL Positional Notation
Three methods exist to execute CL commands. The easiest approach is to use the command line and the
F4 prompt function. Another method some operators prefer is to type the commands on the command
line using keyword notation. Finally, as you become more familiar with the CL command parameters,
you might use positional notation. When parameter values are entered by position, they must be entered
in the order in which they are specified within the command syntax. The F4 prompt function lists the
parameters in sequence. Positional notation saves typing, but entries must be accurate. You should
reserve this method for commands with brief parameter lists until you have more experience using CL
commands.
As an example of using positional notation to enter a CL command, the WRKMSG (Work with
Messages) command would be typed as
WRKMSG userlib/userid *
Most commands limit the number of parameters that you can enter using positional notation.
You can also use a combination of keyword notation and positional notation. For example, the
WRKMSG command can be typed as
When you use a combination of keyword and positional notation, the positional parameters must occur
first; once keyword notation is used, positional notation is no longer valid, and any additional parameters
must be specified in keyword notation.
AS/400 Help
AS/400 Help provides users with several levels of Help functions. The AS/400 supports on-line help for
menus, entry screens, and prompt functions. The user also can search the Help database for information
while (s)he is using an index. For example, if you press the Help key while the cursor is located on a
menu (or a menu option), the system will retrieve a description and instructions about how to use the
menu (or option).
HINT:
If the cursor is still located on the command line, you will receive help information for the
command line instead of the Help menu.
To display the Operational Assistant help, you may have to first type GO ASSIST on any command line,
then
The Help screen, as shown in Figure 3.15, overlays the Operational Assistant menu with information
about the Operational Assistant. This is general information relating to the menu. The information
included in the Help function will vary depending upon the current AS/400 display and the position of
the cursor on that display. The on-line Help lets you and other users successfully use the appropriate
parameters to accomplish your tasks without having to reference a manual printed on paper.
Figure 3.15 AS/400 Operational Assistant Menu with Help Screen Overlay
To further explore the on-line help capabilities, lets experiment with the help information covering the
GO command. First, it is necessary to cancel the information on the Operational Assistant Help screen.
Then we will be able to start the on-line help functions.
You will now see the Go to Menu (GO) screen, as shown in Figure 3.16.
To gain further information about a parameter, position the cursor somewhere within the parameter, then
press the Help key. Information specific to the parameter will be overlaid on the existing display.
Figure 3.17 Go to Menu (GO) Screen with Return Point Help Overlay
Press arrow keys to position the cursor somewhere on the Return point
line
Press Help to activate the overlay
As shown in Figure 3.17, the F2=Extended help option is located within the help area so users can
access the information relating to the entire screen. When parameters are listed for an entry, the cursor
must be positioned on an entry field. To access the extended help, a user must first access the Help
function.
Figure 3.18 represents a sample of an extended help screen. The extended help information was selected
for the GO command.
To return to the General System Tasks screen in preparation for the exercises at the end of this chapter,
InfoSeeker Function
The InfoSeeker function on the AS/400 lets you and other users obtain information by searching on-line
documentation stored on the AS/400. When InfoSeeker is active, you can press F11 to show the
InfoSeeker display, which contains a list of on-line bookshelves and books. You can open one of these,
or type in keywords to begin a search to look for specific information. To use InfoSeeker, your machine
must have the documentation stored on-line. Otherwise, the function will not be available. The AS/400
user interface is designed to provide all levels of users multiple methods to accomplish their tasks. All
techniques for interacting with the system are interchangeable, allowing advanced users to fall back to
the easy to use menus and beginners to progress as their own needs dictate. It is important to remember
to always read the screen for options, function keys, and other information. The on-line help available on
the AS/400 is a valuable, time-saving tool that lets you obtain information quickly.
Key Terms
CL commands
Command structure
Command groups
Command information
Keyword notation
Positional notation
Extended help
InfoSeeker
Main menu
Operational Assistant menu
On-line help
Review Questions
Exercises
Chapter 4
Working with Jobs and Message Handling
Objectives
To understand
AS/400 users and operators accomplish their tasks by executing jobs. A job can be one short, simple
function or it can be a series of programs working together to complete a complex task.
The two basic types of jobs are interactive jobs and batch jobs. During an interactive session, the user
types a request (and presses Enter or a function key) and the system responds to the request. These
sessions, called interactive jobs, begin when a user signs on to a display station and end when the user
signs off.
When constant system interaction with the user is not required, the job can be run as a batch job. Once
submitted, a batch job disconnects from the workstation, allowing the workstation to be available for
further interactive tasks or for additional batch jobs. Two common examples of jobs that are run in batch
mode are printed Query reports and month-end data posting.
A batch job is submitted to a job queue, as shown in Figure 4.1. A job queue is a waiting area for
pending batch jobs. Assuming that the job priorities are the same among batch jobs, each new batch job
is entered at the bottom of the job queue. The subsystem will retrieve these jobs in order of receipt and
execute them. Jobs can be held; or if the subsystem is inactive, the batch jobs will be postponed
indefinitely. Jobs may be intentionally submitted to an inactive job queue to control scheduling for an
unattended night shift. The operator starts the subsystem at the end of the work day and job processing
will begin automatically.
Another method to control scheduling on a one-time basis is to use the SBMJOB (Submit Job)
command. The Submit Job screen, shown in Figure 4.2, has many options and parameters available. If
the job to be submitted is a program, type the word CALL and the name of the program for the
Command to run parameter; for example, CALL PAYROLL. A CL command can be executed in the
same way by typing the command as it would be entered on a command line. To access the Submit Job
screen,
HINT:
To access additional information, from the Submit Job (SBMJOB) screen, position the cursor and
press the Help key to view the possible parameter values.
Job Names
Each job on the AS/400 has a unique, qualified job name that incorporates three parts: job name, user
name, and job number. When a user submits a job to batch, (s)he can either specify his or her own job
name or accept the system default value. The system default value, *JOBD, uses the name of the job
description indicated on the Job description parameter. The user name included in the qualified job name
is the name of the user profile for the job that is executing. The job number is assigned by the system.
Examples of valid qualified job names might be 000667/QSYSOPR/PAYROLL for a submitted batch
job, or 135792/QSYSOPR/DSP01 for an interactive workstation session.
The next options related to the Submit Job (SBMJOB) screen that are of interest to the operator are the
Schedule date (SCDDATE) and Schedule time (SCDTIME) parameters; but these options are not
displayed on the initial screen. To display these and other additional parameters, use the F10 function
key:
Press F10
Press Page Down twice
The SCDDATE parameter specifies the day the job is to be released to the job queue. The SCDTIME
parameter specifies the time of day the job will be released to the job queue. To release the job
immediately to the job queue, you can use the *CURRENT value for both the SCDDATE and
SCDTIME parameters.
The SBMJOB command allows for many types of jobs, including programs and CL commands, to be
submitted at a convenient time and have a delayed execution.
To experiment using the SBMJOB command, use the Page Up key so that the initial Submit Job screen
is displayed. Then send a message to yourself with a three-minute delay. Use Figures 4.2 and 4.3 for
reference.
Another job scheduling tool that is available on the AS/400 is the WRKJOBSCDE (Work with Job
Schedule Entries) command. This command contains the information you need to submit a batch job at
regular intervals. This tool also has an easy-to-use interface that lets you submit any type of job or
command at specified times. Adding a job schedule entry will cause a job to be submitted at the
specified time. Removing a job schedule entry will stop the job from being submitted. Other types of
changes in job schedule entries are allowed, such as holding and releasing entries in the job scheduler.
Each job schedule entry has a unique job name and entry number.
To schedule a job once, weekly, or monthly, use F6=Add on the Work with Job Schedule Entries screen,
as shown in Figure 4.4. The job scheduler submits the job automatically at the specified time.
Commonly used options on the Work with Job Schedule Entries screen are shown in Figure 4.5.
2=Change Option 2 modifies the job schedule entry for the selected job but does
not affect any jobs already submitted.
4=Remove This option will permanently delete a job schedule entry so that the job
is not executed on the schedule.
3=Hold Holding a job schedule entry will result in the job entry being bypassed
if the scheduled time occurs while the job is held.
6=Release This option releases a held job schedule entry. If the scheduled time has
not passed, the job will be submitted for execution. If the scheduled
time has passed, a warning message is displayed indicating that job
wasmissed. As operator, you can submit the job manually or use Option
10 to submit it immediately.
10=Submit immediately The "Submit immediately" option can be used when a held job's
scheduled time has passed. This option is also helpful for clean-up
activities; occasionally, it is necessary to run these functions
immediately, usually because of problems.
Whenever you have changed the status of a batch job, you should verify the change. To check the status
of batch jobs, use the Operational Assistant (GO ASSIST) menu to access the Work with Jobs screen:
HINT:
Job Schedule Entry jobs do not appear on this display until they are submitted to the batch job
queue.
HINT:
To view or manage the jobs of other users, including batch jobs, you must have job control
(*JOBCTL) authority.
HINT:
To display the status of a single user, you can type the users ID in the user parameter. If you
forget the user ID, you can press F4 to prompt for a list of all user IDs.
To see all batch jobs (you must have *JOBCTL authority), type *ALL in the user parameter on the
Work with Jobs screen and press the Enter key. You can enter a generic name; for example, D* shows
all the jobs for all users whose names start with a D, such as David, Diana, or Duke. You can enter a
generic name on the Select Other Jobs display.
The Work with Jobs screen is displayed with the User parameter (see Figure 4.7). Accessing this screen
provides a convenient method to determine which user submitted each job. The default on the Work
with Jobs screen is to sort by job queue and within each job queue by status.
Most AS/400 systems have great quantities of jobs in the batch queue. Generally, the system operator is
responsible for ensuring that the queued jobs are progressing quickly and efficiently. To help you
process jobs, you may find it useful to obtain the status of jobs by category. For example, you may be
concerned with jobs that have a status of hold because of an unanswered message. To view the various
choices (Figure 4.8),
Press F14 to "Select other jobs" on the Work with Jobs screen
Figure 4.8 Work with Jobs Screen, Select Other Jobs Option
The default on this display is to select *ALL for the User parameter and to include all jobs in any status
except Printer output. Excluding the finished jobs with printer output waiting helps to reduce the volume
of the display. To clear specific job types from this display, type N for no next to each job status youre
not interested in. After you press the Enter key, only the selected jobs will be displayed. To return jobs
to the display, change the status column to Y for yes.
To see when jobs were submitted, press F11 on the Work with Jobs screen to Display dates/times. The
operator can view the lag time on the job queue to attempt to predict waiting times until a job has begun
to execute.
Occasionally, a batch job is submitted that must run immediately. To expedite the critical job, you as
operator will have to hold all currently running jobs, all batch jobs that have a higher priority, and any
jobs that are in the queue before the critical job. To hold the executing job, use option 3 from the Work
with Jobs screen. The status of the job(s) will be changed to Running job held, or to Held. Press the F5
key to refresh the screen and ensure the job status has changed.
After the critical job has been completed, all the held jobs must be released. To release a batch job on
the Work with Jobs screen, select option 6, Release, for the job or jobs you want released. The status of
the jobs should be changed to Released. Again, press the F5 key to refresh the screen and ensure the job
status has changed. The status of the released jobs should be changed to Running, Waiting to run, or
Scheduled.
Occasionally, a job is submitted at an inappropriate time or by accident. To remove a batch job, use
option 4 on the Work with Jobs screen to Delete, or End, the job. The Confirm Delete message will be
shown. Press the Enter key to confirm the end of the job, or press F12 to cancel and to keep the job.
When you delete the batch job, it no longer appears on the display. However, the ended job will still be
displayed if the job had printer output waiting, and you had specified a status of Yes for the Printer
output parameter on the Select Other Jobs display.
Most system operators are required to monitor other job queues, as they do the batch queue. You can
accomplish this easily using the Work with Job Queues screen:
You can now view job queue activity information, as shown in Figure 4.9.
On the Work with Job Queues screen, you can hold or release any job queue. Individually holding every
job submitted to the job queue prevents those jobs from actually running, but it does not prevent newly
submitted jobs from running. Using this display to inactivate the entire queue at once is faster and more
error-free, because no jobs in the queue will run.
To hold a job queue using the Work with Job Queues screen, use option 3, Hold, for the job queue that
must be held. The status of the job queue will change to Job queue held. The Work with Job Queues
screen shows only job queues that have waiting or running jobs. If there are no active jobs associated
with a job queue, the Work with Job Queues screen appears empty.
HINT:
Always use the F5 function key to refresh your display to ensure that you are viewing the most
current display.
Option 6, Release, releases a job queue. The status of the job queue changes to *Job queue released.
Another system operator function is to monitor the subsystem QINTER that runs interactive user jobs.
Interactive users may not use the largest share of AS/400 resources, but these users frequently have the
highest priority for system use. Therefore, smooth functioning of interactive users jobs is paramount. To
display all users who are currently signed on the system and what they are working on, select option 12
from the Manage Your System, Users, and Devices menu.
The Work with Signed-On Users display, shown in Figure 4.10, allows messages to be sent to all the
users currently signed on; it also allows the operator to display details about interactive jobs. This
display can also be used to sign off users who have forgotten to sign off.
HINT:
Signing off a user stops his or her interactive job regardless of any processing that may be active.
Therefore, it is important to use caution when signing a user off the system. Ending a users
interactive job that is performing a file update can cause the file to be updated incorrectly.
If you are sure that a user must be signed off the system, use option 4, End, on the Work with Signed-On
Users screen. Press the Enter key to confirm the sign-off, or press F12, Cancel, to leave the user signed
on. The Work with Signed-On Users screen will no longer show the User ID(s) of the user(s) who have
been signed off the system.
Assume that the operator needs to send a message to a user but cant remember the correct spelling of the
users ID. The users profile name is required for the SNDMSG command but this name is not readily
available when many users are signed on to the system. To display a signed-off users name, enter the
first few characters of the users name in the Find user area. The display will begin at the first user profile
name that matches the supplied characters. The list is initially sorted by user profile name and it shows
each users activities.
You can also include on the display those users who are temporary signed off:
Users who are temporarily signed off are not initially included in this list. To include these users, type a
Y in the Include temporarily signed off users field in the Select Other Users and Display Stations
display.
There are two ways to display additional information about the users currently signed on to the system.
For a single user listed on the Work with Signed-On Users screen, select option 5, Display details. The
Display Details screen presents the user, the display station description, and the current activities.
To get additional information for all users shown on the Work with Signed-On Users screen, use the
Display additional information function key. This displays a pop-up window, shown in Figure 4.11,
where you can select the type of information you want. The selections are Activities, Display station
descriptions, or User descriptions.
Press F3 repeatedly
Message Handling
Messages provide the means for you to communicate with the system and with the users of the system.
When you as the operator, or when the user, asks the system to do something, the system may respond
with messages indicating the status of that request. In addition, you can communicate with other users of
the system through messages that are sent via the system.
As the system operator, you receive messages from system users and programs that communicate
conditions you must respond to and indicate actions you need to take. As a system user, you receive
messages in response to your actions at a workstation. These messages are placed in message queues.
The system sends informational or inquiry messages for certain system events. Informational messages
are generated by the system and give a status report about what the system is doing. Inquiry messages
request a reply. These messages are sent to either the system operators message queue (QSYSOPR), to a
users message queue, or to the workstations message queue.
HINT:
The Send Message display is set to interrupt users who are working. If you do not want to disturb
them, change the Interrupt user field to N.
You can find out more about messages on the Work with Messages screen from the Operational
Assistant menu. Then use the Display details and reply option:
Usually, one of the causes listed on this screen will help you to identify the problem. See Figure 4.12 for
a sample of the Additional Message Information screen. Occasionally, these message explanations may
be misleading and the suggested solutions might not correct the problem; the listed causes are only
probable explanations for what might be causing an error.
HINT:
If you select option 5, Display details and reply, for a message that does not need a reply, the
additional information is about the message. If the message requires a reply, type the answer in
the field provided at the bottom of the Additional Message Information screen you see when your
system is set at the Basic Assistance level.
Press the Page Down key to see the remaining information about the message. When you have read the
information, type an answer in the Reply field and press the Enter key.
The Additional Message Information screen includes the message ID. The system uses the message ID
to keep track of its messages. Programmers use these identifiers to handle error messages within their
programs.
The error message is accompanied by a letter and number code, as shown in Figure 4.12. This is the
message identifier, or message ID, that distinguishes one message from another in the message file. The
first three letters indicate the message category. Some typical message categories are shown in Figure
4.13.
The remaining four digits in an error message (which may include hexadecimal values) indicate the
sequence number of the message. In Figure 4.12, the message ID indicates this is a message from the
operating system (CPA) and the message is numbered 57EF. A message ID is shown when you use the
Help key to request the Display Additional Message screen.
The lower right corner of the screen includes the More... notation, and a second page includes details
about the message, as shown in Figure 4.14. To view these additional details,
HINT:
To see all the information about a message on one display, switch to the Intermediate Assistance
level using the F21 key while you are on the Additional Message Information screen.
Press Enter
To print an individual message, use the F6=Print option on the Additional Message Information screen.
This prints all the information about the message shown on both screens of the display. The output is
sent to a spooled file named QSYSPRT; the output can be viewed or printed from the output queue.
Occasionally, a problem seems to grow as efforts are made to correct it. When problem resolution
becomes lengthy, printing out the sequence of error messages is one of the best things you can do to help
resolve the problem. Rather than print each individual message, you may find it is easier to print the
entire message queue.
Press F12 several times until the Operation Assistant menu is shown
Press F9 to get a command line
Type WRKMSG on any command line
Press F4 to prompt the command
Type MSGQNAME your message queue name
Type *PRINT for the output parameter value
Press Enter
When you specify the *PRINT parameter on the Work with Messages command, the output will be
placed in your output queue, where you can display it or send it to the printer of your choice.
Message Queues
Previously in this chapter, we discussed messages generated by the system in response to a problem or
as a request for action by the operator, such as changing paper forms. The QBATCH subsystem usually
sends all system operator messages to the message queue named QSYSOPR. During an interactive
session, messages sent from other users and messages sent by the system are typically placed in the
interactive users message queue.
A message queue is like a mail box. Each workstation has a message queue with the same name as the
workstation ID and each user has a message queue with the same name as the user ID. To view the setup
of your message queue, use the Display list details option on the Work with Messages screen, as shown
in Figure 4.15:
A discussion of the various portions of the Display List Details screen follows. This display shows
details about both the workstation message queue and the user message queue. This discussion applies to
the most commonly used parameters for both message queues.
The Message queue value is the name of the message queue that contains the messages. This is generally
the same name as the display station name or the user ID.
The Library parameter is the library that stores the message queue. The library values should be included
in the users library list.
The Delivery value is the method by which messages are delivered the message either will interrupt the
user at the time of delivery, sound an alarm, hold until answered, or automatically send a default reply.
The Program entry is more appropriately called the break message handling program. This entry names
a program that the system will call if a message of sufficient severity arrives at a message queue that is
in *BREAK (interrupt) mode. The program may activate an error-correction sequence, stop the job
stream, or call a message program. The severity value is usually defined by a programmer. The default
value is *DSPMSG, to use the system-supplied message display program.
The Severity parameter determines whether a message has a level equal to or greater than the severity
value that has been established. If so, the operating system will either interrupt the user or turn on the
message-waiting light, depending upon the designated Delivery value.
The Description entry is the description of the message queue; this information is commonly entered
when the message queue is created. When message queues become overly full, it is helpful to have both
the name and phone extension of the message queue owner included in this description.
When an interactive user signs on to the system, his or her message queue is put into the delivery mode
specified in the users profile. The system operator using the user profile QSYSOPR is assigned the
message queue QSYSOPR. Message queues can be changed to customize the values listed in the above
text. To change the information displayed on the Display List Details display, use the CHGMSGQ
(Change Message Queue) command, as shown in Figure 4.16.
As the operator, you will frequently be selecting and modifying the delivery mode, DLVRY. You can
select one of four values: *BREAK, *NOTIFY, *HOLD, and *DFT. The *BREAK value specifies that
when a message is received, the users work is interrupted and a message is displayed on his or her
screen. This value can be overridden if a program was specified to handle the message condition. For
example, the *BREAK value can be used when you as the system operator need to shut down the
system. The shut down message would interrupt all interactive users and allow them time to close their
jobs and sign off their workstations.
The *NOTIFY value specifies that when a message is received, the users work is not interrupted. The
message turns on the workstation attention light (or message-waiting symbol), and an alarm may sound.
Not all workstations are equipped with an alarm. To display the message, use either the DSPMSG
(Display Messages) command or the WRKMSG (Work with Messages) command.
The *HOLD value acts as a silencer. The user is not notified in any way when a new message arrives.
The message queue retains the messages until the user requests his or her messages, using the DSPMSG
(Display Messages) command or the WRKMSG (Work with Messages) command.
The *DFT value can potentially cause problems and should be used with caution. When you use the
*DFT value, all informational messages are ignored. Messages requiring a reply are sent a system-
supplied default reply. Messages may be sent to other users or workstation message queues, but none of
the messages are kept in the receiving queue if the receiving queue is in *DFT delivery mode. The
system operators message queue, QSYSOPR, is treated differently these messages are kept in the queue
and logged in the history log, QHST. For unattended operations, you can use the *DFT value.
The next value of interest is the severity code. You can use the severity code in *BREAK mode to filter
out messages that interrupt the users work. For example, if a message severity code of 59 is defined, the
system will break into the users work only if messages with codes of 59 or greater are detected. Any
message with a severity code of less than 59 will be sent to the message queue and the Display message
symbol will be lit. (This is assuming that the Program value is *DSPMSG).
Now assume we have the same message severity code of 59 but that the message queue is in *NOTIFY
mode. In this case, the system notifies the user of any messages received that have a severity code of 59
or greater by lighting the Message waiting symbol and/or sounding the alarm, if the display station has
one. Any message with a severity code of less than 59 will be sent to the message queue, but the Display
message symbol will not light. The message will be saved until the user reads and deletes it.
The Text description value should be a description of the message queue. As an aid in trouble shooting,
the authors recommend that for message queues assigned to users, the Text description contain users
names and phone extensions, as shown in Figure 4.16.
To access additional parameters from the Change Message Queue (CHGMSGQ) Screen,
Press F10
The Break handling program (PGM) parameter is more frequently called the Break message-handling
program. This program specifies the program name and library location for a program to be executed if
the normal default, *DSPMSG, is not desired.
Specify *NO for the Reset old messages parameter to prevent a message you have already read and
viewed from being redisplayed in your message queue. Specifying *YES to the Reset old messages
parameter makes the operator review the messages again and again until the messages are deleted.
The Force to auxiliary storage parameter is usually specified as *SAME, to use the value specified in the
message queue. The message queue will usually have this parameter specified as *NO to indicate that
changes made to the message queue, including its messages, are not immediately forced into auxiliary
storage. When *YES is specified, then all changes made to the message queue description and each new
message in the queue are immediately forced to auxiliary storage and duplicated in DASD. The *YES
option is an important message-queue recovery tool that provides communications between programs,
but it slows down system performance and uses additional disk space.
Key Terms
Delivery mode
Job schedule entry
Severity code
Job queue
Message ID
Job name
Message queue
Review Questions
1. What are the two basic types of jobs that an AS/400 operator commonly deals with?
2. What is the purpose of the Submit Job command?
3. What is the purpose of the Job Scheduling Entry?
4. What happens to a Job Scheduling Entry that has a Held status when it is released to the job
queue?
5. What are the three parts of the qualified job name?
6. What is a job queue?
7. How can the operator change the sequence of the jobs on the job queue?
8. How do you find a specific user signed on to the system?
9. What command allows changes to message queues?
10. What do the first three letters of the message identifier indicate?
Exercises
1. Change your message queue to interrupt you whenever you receive a message.
2. Print a message that you have received.
3. Schedule a batch job to send a message to your instructor at a certain time.
4. Using the Work with Jobs screen from the Go Assist menu, display all the jobs that are
running and all the running jobs that are held. Use the <Print Screen> key to capture the results;
print these results and turn them in.
Chapter 5
Managing Print Functions
Objectives
To understand
Printing
AS/400 programs generally do not send data directly to printers. While the AS/400 does support direct
printing, which may be suitable for PCs with one workstation and one printer, this approach is generally
unacceptable in a multitasking environment. Consider that interactive jobs are not completed until the
user signs off, possibly at the end of the work day. And when direct printing is used, the printer is
dedicated to one job and is unavailable to any other jobs until that one job is completed.
Programs create images of printer output; these images are called spooled file members in AS/400
terminology. On the AS/400, spooled file members are placed on output queues until a printer is
available to print them. Like other queues, an output queue is a holding area in this case, of spooled file
members waiting to print. A single output queue may have spooled file members from many different
jobs and many different users. In some cases, a single job might place spooled file members on more
than one output queue. This would mean that each user who requires the job output must have his or her
own copy within an output queue that (s)he can access. Many times, however, users do not need to print
the entire job; within a large output report, a user may need only a small portion of the job. In that case,
the user can then print only the pages (s)he requires, or (s)he may be able to view the data and not even
require a printed report.
As operator, you should encourage users to review their reports at the terminal before they print. Then
hopefully, if an error occurs, they can delete the spooled file, correct the input that caused the error, and
rerun the job without requiring that you be involved in the process at all.
Instructions from application programs or system-supplied programs combine with data to create the
spooled files. The software and the printer device file further interact to determine how printed reports
can be formatted. Format information is usually stored separately from the program that creates the
report. Certain aspects of a report format can be changed before the report is printed, such as the number
of lines to be printed on a page, what type of form to use, and whether to use large or small font types.
Printer formatting capabilities are stored in a printer device file. Before you switch a spooled print file to
another printer, it is important to know the formatting capabilities of the printers. For further information
about printer formatting, see Appendix A.
The Operational Assistant lets you as the operator work with queued printer output in many different
ways (e.g., by user, printer, job, job status, or output name). A series of menus helps you perform these
routine tasks of controlling jobs and printer output. Often, much of your job involves directing and
controlling the printing process. This is particularly true in a multitasking, multiple-printer environment.
To access the Operational Assistant Menu,
If you select Operational Assistants option 1, Work with printer output, you will be shown the Work
with Printer Output screen, which offers you a user-friendly interface by which you can work with all
types of printer output. As the system operator (with QSYSOPR authority), you will be able to view and
control all the printer output files for all users who have unprinted reports.
HINT:
You can substitute the CL command WRKSPLF for the GO ASSIST command and option 1,
Work with printer output. At the Basic Assistance level, both of these methods will show the
same display.
The assistance level at which a user is operating causes different screens to be displayed from Option 1
on the Operational Assistant menu. To ensure that your work and the text are in agreement, check to be
sure your assistance level is set to *BASIC:
As the operator, you will use the Work with Printer Output screen shown in Figure 5.2 to inspect the
flow of spooled print jobs as they proceed to the printer. Spooled output reports that are assigned to a
printer (assuming that everything else is prepared) will be printed according to their output priority. Jobs
are assigned an output priority by a programmer or administrator before the jobs are run.
Lets assume that all the jobs in a queue have the same output priority level. When another job adds a
spooled file with the same priority to the queue, the AS/400 operating system will place the new spooled
file at the bottom of the queue. However, if the new job has the highest output priority, the spooled file
will be placed in the queue above all the other jobs files and thereby be printed next. The operating
system will not stop a lower priority file in the middle of the printing process to allow a higher priority
file access to the printer. If it is necessary to interrupt the spooling program to print a higher priority
report, you as the operator must hold the spooled output. We discuss this process in the next section.
Typing the user profile ID in the User field will display only one individuals spooled output. The screen
will be displayed as shown in Figure 5.2, with the name of the user (in this case, QSYSOPR) to limit the
number of queued reports on the display. The Work with Printer Output screen divides the spooled
output by printer name. Spooled output with a status of Not assigned to a printer will appear last on the
display. To view all the printer output, type *ALL in the User field. The queued printer output in Figure
5.2 is sorted by printer name.
HINT:
If you do not know the user ID, press F4 to display a complete list of users.
HINT:
A partial name can be entered in the User field together with the asterisk wild-card character. For
example, if you want to see output that starts with AR, type AR* in the User field.
Working with Printer Output Options and Function Keys at the Basic Assistance
Level
The following material is a discussion of the options and commonly used function keys you will be
working with as you direct and control the printing process in a multiple-printer environment via the
Work with Printer Output screen. Several of the options display additional screens for review or for
modification.
Option 2, Change, lets you modify the print attributes. To practice with this option,
The attributes of a spooled print job, as shown in Figure 5.3, include, among other items, the printer
device, the number of copies to be printed, and the type of forms to be placed in the printer. You may
specify the device name of a printer to use to print a report. Use this field to assign a printer to a report
that has not been assigned, or to move a report from one printer to another.
HINT:
If you do not know which printer to use, press F4 to see the Select printer list.
To change the number of copies to be printed, type the desired number in the Number of copies field. To
specify the page number that this printer output should begin printing on, type the page number in the
First page to print field. If it is unnecessary to print the entire report, type a page number in the Last page
to print field. These two fields can be used together if, for example, part of the report was damaged by a
paper jam or you want to print only a portion of a report.
To change the form type, key the desired name of the form in the Type of forms field. This can be useful
during application testing for example, to verify check or invoice alignment by printing the spooled
output on plain paper.
To change when printer output prints and to move printer output to the front of the queue for printing,
type a Y in the Print this output next field. The user who owns the spooled printer output has authority to
make this change. As operator you can also make these changes if you have been granted *SPLCTL
authority (the user profile defines the highest print priority allowed for this profile). The printer output is
placed with other reports with the same priority and forms type. Higher priority print jobs will be printed
first.
To save the printer output after printing, type a Y in the Save printer output field. Normally, you would
delete printer output to avoid cluttering up the system. However, for output that prints on special forms,
it may be helpful to save the spooled output. If alignment problems are discovered after the output has
printed, you can reprint without having to rerun the program (which may be impossible to do without a
great amount of effort). If the printer output is currently printing, you can change the Number of copies
and Save printer output fields. If it is necessary to modify other options, first hold the printer output,
make the change, and then release the printer output. This sequence will provide you with all the print
options.
Press F3 to "Exit"
You use option 3, Hold, to specify the spooled output to be held. When spooled output is held, the status
will change to Held and the spooled file will not be printed until an operator releases it. Once released,
the job will be sequenced according to its priority. Select option 6, Release, for the spooled output to be
released, and note that the status of the spooled output changes to Released.
Use option 4, Delete, to permanently remove spooled output from the Work with Printer Output screen,
and press Enter. Press Enter again to confirm the delete. The spooled output that was deleted should no
longer appear on the Work with Printer Output screen. If the spooled output remains visible, press F5 to
refresh the display.
As operator, you should use extreme caution when deleting jobs from the output queue, because it may
not be possible to regenerate spooled output. For example, some print jobs simply report on the contents
of the users database files and these can be deleted and rerun with no long-term consequences. However,
you should not delete any reports that serve as an audit trail for a database file update. These output
reports frequently cannot be regenerated without restoring a previous version of the file and re-entering
the file updates. In rare cases, a user who deletes audit trail reports may actually be committing fraud or
embezzlement. You can protect yourself by asking for approval from a supervisor to delete the output
report, or by moving the report to an unassigned output queue. Moving the report to a different output
queue will provide several advantages. First, the report will not show up on the users output queue;
second, the job will not inadvertently move up to the printing position in the job queue; and third, if the
report is indeed necessary, the output can be moved back to an active queue for printing.
HINT:
Before deleting printer output created by another user, consider whether your user profile contains
*SPLCTL authority.
Type 5 in the option column on the Work with Printer Output screen
Press Enter
The ruled line marks the beginning of the actual data in the printer output, as shown in the example
Figure 5.4. You can use the Control and Find fields at the top of the display to locate information within
the spooled output. Two effective entries in the Control field are T for top and B for bottom. The Find
field will locate any text typed in the variable area with an exact match in the spooled file. For more
information about either of these fields, place the cursor on the appropriate line and press the Help key.
Option 7, Message, will display any messages relating to the spooled output. We will discuss printer
messages in greater detail later in this chapter.
Use option 10, Start printing, on the Work with Printer Output screen to assign spooled output to a
printer. Type the name of the printer to be used in the Printer field, or press F4 to select from a list of all
the printers on the system. If the printer is not started, the Start Printing message will be shown. The
spooled output now appears under the name of the printer.
Option 11, Restart printing, is used when a job has been stopped in the middle of printing or more
likely, when there has been a paper jam.
Occasionally, printed output is misplaced, or a spooled file may inadvertently be placed in a held output
queue. One method that can help you locate the report is to verify that the spooled file was actually
printed. To display the completed printer output screen,
Because the completed output lists are generally lengthy, your may find it helpful to sort the information
using the F10=Sort list function key. The Sort list option is useful for locating a specific report when
numerous spooled output jobs are on a queue. (Note: F6 and F10 will be available on your AS/400 only
if the systems job accounting function is active and is collecting printer completion information.)
The Date/pages/forms view shows when the spooled output was created, the total number of pages, what
types of forms are being used, and how many copies are to be printed. The date/time columns are helpful
for you to calculate how long a job has been on the output queue and to predict approximately how long
it will be before the job will begin printing.
Occasionally, you may make an error while you are typing in the printer name, or you might belatedly
realize that a lengthy job has started printing. Fortunately, the F22 function key allows you to control the
printers on your system. From the resulting Work with Printers display, you can start, stop, or restart a
printer, or you can respond to messages that may indicate printer problems.
The AS/400 assistance level is designed to meet the changing needs of both users and computer center
staff members. The WRKSPLF (Work with Spooled Files) command is an interesting example of this
process, because the assistance level will display two different screens. You may find it helpful to set the
assistance level to Intermediate when you are working with spooled files and print writers.
HINT:
The F9 key is available to display a command line on screens that do not provide one
automatically.
Compare Figure 5.2, Work with Printer Output, with the system set at the Basic Assistance level, and
Figure 5.5, Work with All Spooled Files, with the system set at the Intermediate Assistance level. Note
that the Intermediate Assistance level displays a completely different screen of the same data. Typing
the WRKSPLF command with the ASTLVL parameter *BASIC would display the Work with Printer
Output screen.
Figure 5.5 Work with All Spooled Files Display, View 1 (Default)
The Work with All Spooled Files screen has three different displays, each providing you with slightly
different information. The default view, or View 1, shown in Figure 5.5, lists the name of the job (under
File), what user or program submitted the job, and the output queue where the spooled output is located.
View 1 lists the spooled files in the order they are to be printed, assuming that all the spooled files have
the same priority.
The status column, Sts, reveals the condition of the job. Notice the first spooled file on the figure has a
status of writer, WTR, while other spooled files are ready to print, RDY, or are held, HLD. For more
information about status codes, see Figure 5.6.
The Spooled output schedule (SCHEDULE) parameter controls whether a spooled file is available to
print as soon as the individual report is closed, or whether the report must wait until the entire job that
created it has finished. This parameter is particularly important for any spooled file that is created by an
interactive job. Remember: An interactive job does not end until the user signs off. Any spooled file
created with *JOBEND specified as the Spooled output schedule parameter (SCHEDULE) waits in an
output queue with a status of CLO until the user signs off, possibly at the end of the day. If the operator
notices a job that is on the output queue for an extended period of time, it may be appropriate to contact
an administrator or programmer to request a change to *FILEEND, to print the job as soon as the
spooled file is closed. This can be helpful if one program creates multiple reports. If the report must wait
until the entire job has finished, use *JOBEND for this parameter.
Many of the option and function keys perform the same function at both the Basic and the Intermediate
Assistance levels. Therefore, this section will cover only the options or functions that are new or have a
modified function at the different assistance levels.
Use option 1, Send, on the Work with All Spooled Files screen, to send a spooled file to another system,
or to another users output queue on the same system. Type the user ID and network address for the user
who will receive the file on the Send Network Spooled File (SNDNETSPLF) display. This option is
helpful because most users do not have access to or authority to view or work with another users output
queue. If a user needs to view or work with a spooled file that is located in another users output queue or
system, it may be easier for you as the operator to copy the output to the current users output queue. This
function is not the same as changing the output queue for a printed report (Option 2). When you use
Option 1, you are sending a copy of the printed output to another output queue, and the original will still
remain in its original queue.
If the user receiving the spooled file is a user on another AS/400, the name of that system must be in the
system directory. The system directory is a listing that identifies all users and systems allowed to
communicate with your AS/400 and its users.
HINT:
Use the DSPDIRE (Display Directory Entry) command to view the list of users and systems in
your communications network.
HINT:
To ensure that all the attributes of the spooled file are sent, press F4 and type *ALLDATA in the
Data format field.
Use option 2, Change, on the Work with All Spooled Files screen to assign a spooled output report to a
printer, and to change other attributes of the printed output. Before the report is accepted for formatting
by the print writer, you or the user must designate the printer to be used. Type the name of the printer to
be used in the Printer field.
Option 7, Message, will display any messages relating to the spooled output. In general, messages relate
to a printer request. We will discuss printer messages in greater detail later in this chapter.
Option 8, Attributes, displays the attributes that are listed when the program, the data, and the printer
device files are combined. Certain attributes can be modified (using option 2), such as the number of
copies to be printed. Other attributes, such as the number of lines on a page, cannot be altered.
The second view of the Work with All Spooled Files screen, shown in Figure 5.7, has several new pieces
of information that are of interest to the operator. The Form Type states what kind of paper is to be used
for the printing process. To display an alternate view from the default screen,
View 2 shows that all the spooled files are requesting standard forms. In the early days of computers,
most documents for internal use were printed on green and white striped paper. Non-standard forms
were typically preprinted documents, such as invoices or pay checks. Today the corporate standard is set
partially by the printer hardware available and partially by individual preference. A chain printer with a
wide carriage may still use the green and white striped paper, while a laser printer may be unable to use
any paper wider than 8 ½ inches. Your computer center should have a list of the abbreviations and the
forms that you are to use.
The priority of the spooled file is shown in View 2. Priorities may be assigned from a high of 1 to a low
of 9. Notice in Figure 5.7 that all the jobs have the same priority; therefore, the spooled files will print in
the order displayed.
The third view of the Work with All Spooled Files screen, shown in Figure 5.8, lists the File name, the
User name, and the Job number. You can combine these three pieces of information to construct the
qualified job name. (We discussed the qualified job name and its importance in Chapter 4, Working with
Jobs and Message Handling.) To display the next view from View 2,
To return to View 1,
Press F11
Print Writers
The print writer is an AS/400 system program that sends spooled output from an output queue to a
physical printer. Any spooled file members on an output queue remain in the queue until a print writer
has sent the report to a printer. For more information about print formatting, see Appendix A.
At the Intermediate Assistance level, use option 2, Change, to assign output to a specific printer. Next,
type the name of the printer to be used in the Printer field.
During a work shift, you may send hundreds of jobs to the print writer and, therefore, to the printer. To
send the output to be printed, you or the user must type in the name of the appropriate printer. Lets
assume that 100 jobs are ready to be moved to the printer named PRTMFG. You would need to type a 2
in the Option column, press Enter, and type PRTMFG. This process would then need to be repeated 99
additional times. As you can see, this is a time-consuming process and surely some entries will be typed
incorrectly. An easier and more error-free method would be to type the 2 in all the Option columns and
then enter a single CL command parameter on the command line. The parameter, as shown in Figure
5.9, is OUTQ(printer name). When the system processes this change, all the jobs will be transferred to
the print writer. Note that this technique requires the assistance level to be set to Intermediate for this
user ID. To understand why this technique works, you need to first understand that Option 2 invokes the
CHGSPLFA (Change Spooled File Attributes) command; OUTQ is a valid parameter for this command.
When you type Option 2 in front of one or more reports, and include a value for the OUTQ parameter,
the CHGSPLFA command executes for each report, using that parameter value.
Figure 5.9 Work with All Spooled Files Screen, with OUTQ CL Command
As system operator, you will find a myriad of messages associated with the printer. In this section, we
will discuss the technique for answering messages in general, rather than discussing specific messages.
The AS/400 supports many types of messages. All messages provide a communications channel from
the system to an operator or user. You should encourage users to view their message queue and delete
their messages as soon as practical. This method will help ensure that messages are actually read and
that disk space usage is kept to a minimum. However, as in Figure 5.10, it is recommended that you (as
system operator) not use option 4, Remove, and the F16 function key to remove messages not requiring
a reply. These messages provide an audit trail for system activity (as does the job log). These messages
provide copious information about system actions and they allow you to review actions taken earlier that
may have caused the current problem.
As shown in Figure 5.10, the operator has a message relating to forms alignment. The forms alignment
message provides you with five choices for the proper reply: I, C, G, N, and R. Because the AS/400 has
many messages with multiple choices, as a novice operator you may wish to display the details before
trying to answer the message. Typing a 5 in the option column for the message will display additional
details about the message. Specific information about how to answer the message will be provided, as
shown in Figures 5.11 and 5.12. You should type the appropriate response and press Enter.
Most AS/400 installations have multiple printers connected to the system, and the status of each printer
may be different. To look at printer status, and to work with printers at the Intermediate Assistance level
(Figure 5.13),
Press F22 "Printers" to display the Work with All Printers screen
Press Enter
A print writer may have a status of END for many reasons: The printer may need repairs; a printer could
be stopped after regular hours for security reasons; or if the paper jam occurred after hours, there would
be no one available to correct the problem. To end a print writer, use option 4, End, on the Work with
All Printers screen. Press the Enter key on the Confirm End of Writer screen. After a printer is stopped,
it must be restarted before any output can be generated. Use option 1, Start, to begin the process to
activate the printer. Press F5 to refresh the screen. When the printers status is changed to start, STR, the
system is in the process of activating the printer.
A forms-alignment message may appear when the printing restarts. If the status changes to Message
waiting, there may be a forms-alignment message that requires a response. Use option 7, Display
messages, to view the message and provide the appropriate response. Once the response has been
accepted, the STR status will be shown.
Option 3, Hold, allows you to hold the printer. All print jobs assigned to this printer are held. Printers
that have been held have a status of *HLD or HLD.
To release the printers, use option 6, Release, on the Work with All Printers screen. The status of the
printer changes to RLS. Press F5=Refresh and the status changes to started, STR. If a printer is held,
release it using option 6 on the Work with All Spooled Files display.
Option 8 allows you to change, hold, or release files on the output queue instead of having to work
directly with the associated printer device.
Normally, an output queue exists for each printer on the system. Often, output queues have the same
name as the printers on the system. These output queues are called default output queues. A system may
have special output queues that do not have a printer name associated with them. For example, an output
queue may be set aside for all printer output requiring special forms. As the operator, you would need to
check this queue periodically to decide when to assign reports to a printer and what forms are needed.
Another AS/400 system may have a separate output queue reserved for job logs.
To start a printer and assign it to a different output queue, enter the STRPRTWTR (Start Printer Writer)
command and press F4 to prompt. In the printer parameter, specify the name of the printer to start. In the
output queue parameter (OUTQ), specify the output queue name to use. If the output queue is not in the
QGPL library or a library from your library list, type the name of the library and the output queue before
the name of the output queue. For example, type lib/xxxxxxxx where lib is the name of the library and
xxxxxxxx is the name of the output queue.
HINT:
To change the characteristics of an output queue, use the CHGOUTQ (Change Output Queue)
command.
Output queue descriptions can affect how output prints. The job separators parameter (JOBSEP), found
in the output queue description, controls whether separator pages are printed between spooled files. Job
separator pages provide identifying information about a spooled file. These pages are useful to help
users locate their printed reports when many different people use a printer, or when a printer generates a
large volume of output.
The order of the spooled output files on a queue controls the sequence in which output prints. The SEQ
parameter controls the sequencing of the output. New spooled files are put after others on the queue
(first in, first out), or they may be ordered by the time the job creating the output entered the system.
You may find the volume of messages in the QSYSOPR message queue is quite large. If so, it may be
helpful to separate the messages for each printer to a different message queue, especially if the printers
are in remote locations. To temporarily change the message queue, start the printer using the
STRPRTWTR (Start Printer Writer) command, press F4, and change the parameter of the message
queue name, MSGQ, to a valid message queue on the system.
HINT:
To permanently change where print messages are located, use the WRKDEVD (Work with
Device Description) command to specify the name of the printer whose message queue is to be
changed, and the new message queue/library name, as appropriate.
The Work with Spooled Files display is very helpful in determining why a report is not printing. Once
you have located the spooled printer output on one of the displays, determine why that information is not
printing. The Status column on the Work with Spooled Files screen will usually tell you. For more
information, use option 9, Work with printing status. The Work with Printing Status screen provides
more detailed status descriptions than are available on other displays. The Work with Printing Status
screen might also have more than one status message for the printer output. Use option 5, Detailed
description, on the Work with Printing Status screen for an explanation of the status and a list of
alternative actions. This information can be helpful in solving any printer problems you might encounter.
A report may have already printed, but was distributed to the wrong person. In this case, you will want
to display completed printer output. The system must be configured to save information about completed
printer output. To display completed printer output on the Work with Printer Output screen, press
F6=Completed printer output. On the Display Completed Printer Output screen, sort the information
using function key F10=Sort list.
To further investigate why the spooled output isnt printing, gather information about the job and the
output, such as the job name. If the output was created interactively, the job name is the name of the
workstation the person was using. If the output was created by a batch job, the job name is assigned on
the SBMJOB (Submit Job) command. Other questions to consider include the following: What user ID
was used to create the output? On which printer does the output usually print? Does it print on special
forms? How many pages is it? What is the output name? When was the job run? Based on the
information you gather, where the report has been queued usually becomes obvious.
Key Terms
Assistance level
Basic
Intermediate
Display a spooled file
Control field
Find field
Hold status
Message queues
Output queues
Print writer
Printer attributes
Qualified job name
Status of a spooled file
Change
Deferred
Held
Message waiting
Open
Pending
Printing
Ready
Released
Saved
Sent
User ID
User profile
Review Questions
1. How do you access the Operational Assistant at the Beginning Assistance level?
2. What criteria does the operating system use to select the next spooled output file for printing?
3. Why would you hold or release a spooled output file?
4. What is the difference between releasing a spooled output file and using option 10 to start
printing?
5. If a user signs off from his or her terminal when (s)he goes to lunch, how would this affect the
printing of the users spooled output files?
6. What is a print writer? Why is it important?
7. In what situations would an operator need to change spooled output files to a different printer?
8. How do you stop a printer? Why would it be necessary to stop a printer?
9. Get two examples of common printer messages. Why do these messages occur?
10. What are the default message queue and default output queue? Why do they exist?
Exercises
Chapter 6
Device Configuration
Objectives
To understand
To be able to
Network Topologies
All devices on the AS/400, whether physical or logical, must connect in some orderly fashion to ensure
that all data and requests are passed to the CPU and processed in sequence. The arrangement for how
data is passed to the CPU and back to the user is referred to as the systems topology. After the topology
scheme is defined, communications are passed down via lines, line controllers, and device addresses;
finally, a connection to the device is established. Because communications and connectivity is a
complex subject, we will discuss only the three most common network topologies in this chapter. We
will then concentrate on connectivity tasks that the operator commonly performs, including setting up
controllers, display devices, printers, tape drives, and diskette drives. We will first present an overview,
and then walk you through the process of creating the device descriptions and of varying the devices on.
The three common network topologies are bus, ring, and star (see Figure 6.1). The bus topology is the
most commonly used. In a bus topology, one node of the network is connected to another by a single
cable until the last node is reached; bus topology has two distinct ends. In a ring topology, the
connections come full circle; in other words, the last node is connected to the first node to form a
complete ring. In a star topology, a main server or computer handles or directs the communications, and
all the nodes are attached to the main computer.
Once the particular topology has been selected, lines, controllers, and device addresses are required
before a device can be connected and communications established with users.
The most common method for attaching display terminals to an AS/400 is a direct connection using
twinaxial cable with a bus topology that is attached to a port. The port, in turn, attaches to a line
extending out of the AS/400 (see Figure 6.2). Each display terminal is attached to an adapter that
physically attaches to the twinaxial cable. The number of ports available depends on the AS/400 model
and the hardware purchased.
Twinaxial data link control, *TDLC, is a direct link to an AS/400 using twinaxial cable. The *TDLC
link is configured with a bus topology. Another type of connection, Ethernet, also employs a bus
topology. Ethernet networks using the bus topology are frequently used in a PC LAN.
Other types of bus topology are available. Synchronous data link control, *SDLC, is generally used for
communications between two remotely connected computers. The sending and receiving stations are
commonly connected with each other, usually through telephone lines.
Token-Ring networks are generally the arrangement used in a PC LAN. Token-Ring networks send data
in one direction throughout the ring by using the symbol of authority (a specialized transmission frame,
consisting of starting, ending, and controlling bit sequences) called a token. The token controls the
transmission, allowing any sending station in the network to send or receive data when the token arrives
at the station. The flow of the token is a logical ring, regardless of how the network is physically cabled,
so the token always ends up at the originating system. Think of the token as a person who delivers the
mail to your house and returns to the post office when all the mail has been delivered. When the mail
carrier comes to your mail box, you can send and/or receive mail. If you place a letter in your mail box
after the mail carrier has passed your house, your letter must wait until the next day. This is the same
concept Token-Ring topology uses; of course, Token-Ring is much faster.
In the star topology, each workstation connects directly to a port, providing exceptionally fast access.
The AS/400 listens for the user to press the Enter key. When the AS/400 hears the request, it responds
virtually immediately.
Figure 6.3 displays the hierarchy of the relationship between lines, controllers (discussed in the next
section), and devices (discussed on page 103).
Lines
Most systems have multiple lines linking the AS/400 to its devices. Lines can be actual cables, phone
lines, or other virtual types of lines; lines are the first level of connection from the AS/400. Because
lines come in a variety of types, each line must have a line description, *LIND. A line description is an
object that describes the attributes of a communications line for another system, controller, or network.
More than one line description may exist for an individual line, but only one description can be varied
on at a time. There are different categories of lines for different types of communications; for example,
twinaxial data link control, *TDLC, is the category for a twinaxial connection.
Controllers
Controllers are a combination of a hardware card and software programs that are designed to handle a
certain level of device transmission traffic. You might think of controllers as traffic cops. A police
officer will allow a certain number of cars to pass though an intersection and will then stop the traffic,
allowing the converging cars to have their turn crossing through the intersection. Controllers have a
similar function of monitoring traffic to allow all the devices access to the CPU. Controllers exist to
handle the hardware devices that are unique to a particular line, regardless of whether the devices are
remote or local. Because controllers can support a variety of devices, a controller description is required.
Controller descriptions define the type of physical devices that the controller will be handling.
Line and controller descriptions are created as part of your AS/400 installation and rely upon the type of
communications topology installed. Operators are generally not responsible for maintaining and creating
these descriptions. On the other hand, devices are added or removed frequently, such as for maintenance.
And often it is the operators job to maintain and control the changing of these devices.
Addresses
An AS/400 address is a means of uniquely identifying each device that is attached to the system. Refer
to Figures 6.2 and 6.3, noting that each device has a unique address. An AS/400 computer address
consists of two parts: a port and a switch setting. The port is the place where the line is physically
attached to the AS/400. The switch setting uniquely identifies each device along the line. Two devices
on the same line cannot have the same switch setting. The address is much like a street address, which
includes a house number and a street name, such as 1000 College Drive. In computer terms, addresses
are reversed, with the street name first (port number) and the house number last (switch setting), such as
College Drive, 1000. Switch settings may range from 0 to 6. As long as a switch setting is not duplicated
on a line, devices may be attached in any order. The address for the system console must always be 0,0.
Devices
A device description contains the attributes and characteristics of the device it describes. Because the
AS/400 is capable of supporting many varieties of devices (i.e., workstations, printers, or tape drives), a
device description is always required. The device description, *DEVD, provides a connection between a
physical (or logical) device and the AS/400 with which it is communicating. A device description must
exist for each device connected to a controller. The device description includes the type of device, the
name of the controller to attach with, and the devices unique address.
Operational Assistant offers the system operator an easy menu-driven method to manage and view the
various devices. Option 10 of the Operational Assistant menu includes many options, including Display
system status, Run a backup, Work with system operator messages, Work with printer output, Work
with jobs, Work with signed-on users, Device status tasks, and Customizing your system, users, and
devices. To access these options (Figure 6.4),
Figure 6.5 describes options 1, 2, 3, 10, 11, 12, and 20 specified in Figure 6.4.
Device Status
The AS/400 supports a number of peripheral devices, including display devices, printer devices, and
tape devices. Devices can be turned on or off, may be disconnected from the system while they are being
repaired, or may be upgraded. Generally, the operator is responsible for controlling the various states of
these hardware devices.
To access the Device Status Task menu from the Operational Assistant menu,
Type 20
Press Enter
The Device Status Task menu subdivides hardware devices into display devices, printer devices, tape
devices, and diskette devices, as shown in Figure 6.6.
HINT:
To view the following screens with more specific information, you must be at the Intermediate
Assistance level. While you are displaying one of the screens, you can change your assistance
level by pressing F21 and choosing option 2.
To access the Work with Display Devices screen (Basic Assistance level) or the Work with
Configuration Status screen (Intermediate Assistance level),
The Work with Configuration Status screen, as shown in Figure 6.7, contains the status of each display
device on the system. You can make a device available, VARIED ON, or unavailable, VARIED OFF,
by typing a 1 or a 2 in the Option column preceding the device type. You can use the Varied on and
Varied off options to enhance security. For example, a device in a public place can be made unavailable
during the evening and night hours. Any VARIED OFF device cannot be accessed after hours. You will
need to vary the device on in the morning, making the device available before the first shift. The Vary
on option and the Vary off option each takes some time to complete. Therefore, the system will display
the VARY ON PENDING or VARY OFF PENDING message until the device status has changed.
Users should be encouraged to sign off their terminals whenever they will be gone for any length of
time, such as to lunch or to a meeting. Again, this technique will enhance system security. When a user
has signed off but has left the terminal powered on, the terminal status displayed will be SIGNON
DISPLAY.
Refer to Figure 6.7 and note that the status of ACTIVE may be further defined to include ACTIVE/
ALLOCATE, ACTIVE/DETACHED, ACTIVE/READER, ACTIVE/SOURCE, ACTIVE/TARGET,
and ACTIVE/WRITER. The jobs that have ACTIVE further defined are generally jobs that are called
automatically and that are required for support or as a supplement to another job that is running.
The recovery pending (RCYPND) status indicator is generated when the system has noted an error and
has automatically started an error-recovery task. Generally, these error-recovery tasks are for network
interfaces, lines, and controllers. The system frequently will be able to correct the problem and the
RCYPND status indicator will be replaced with VARY ON PENDING.
The three columns on the right in Figure 6.7 under the heading Job show three items of information.
These three items are the same ones that make up the qualified job name. For interactive jobs, the first
column contains the terminal or station number. For batch jobs, the job name will be the name of the
batch job. The next column contains the user ID or user sign-on name. The last column contains a six-
digit numeric number. These numbers are called job numbers and are assigned automatically by the
system.
Device descriptions fall into several broad categories: terminals, PCs with terminal emulation, remote
devices, and the system console. An operator typically spends a large portion of time working with
devices. Because devices provide the user with input and output capabilities to the system, the
*IOSYSCFG special authority is required to work with devices.
Type 8 on the option line for the device to be displayed, in this case,
OPERATOR
Press Enter to go to the Work with Device Description screen
Type 5 to display the description
Press Enter to access the Display Device Description screen
The system console is shown in Figures 6.8 and 6.9. The name of the device is OPERATOR and the
category of the device is a standard 3476 terminal, *DSP, which is directly cabled to the CPU as a local
device, *LCL. The next several lines give the device type and model number. Note that IBM requires
that the system console must be at port zero and switch zero to accommodate access during IPL and
servicing.
The second page of the Display Device Description screen (Figure 6.9) repeats the first three lines of the
device name, option, and device category for clarification. The new data on this screen describes the
default printer and any customizing performed on this device.
To view the device descriptions for a terminal, select the appropriate device and proceed as shown in the
previous steps. An example is shown in Figure 6.10. Local terminal devices are those devices that have a
port and switch address in this example, port 5, switch 3. Local devices are generally connected to the
AS/400 via a cable. These devices have a class of local, *LCL.
There are many types of display devices available on the AS/400, depending on how a device is
connected. The previous discussion shows only a small sample of local display devices.
Press F12 repeatedly until the Device Status Tasks menu is again
displayed
Type 2 for the Work with printer devices option
Press Enter
Generally, the AS/400 has a variety of printers connected to the AS/400. Figure 6.11 shows the Work
with Configuration Status screen with three printers attached. We recommend that printer names be
descriptive to help differentiate between similar printers at different locations. In Figure 6.11, the
printers are named by location, with one in the accounting department and the other on the
manufacturing floor.
A printer, like every other device attached to the AS/400, must have a description to identify its
attributes to the AS/400. To work with the description, from the Work with Configuration Status screen,
The printer (*PRT) in Figure 6.12 represents a locally attached (*LCL) printer (*PRT) that
communicates through the CTL01 controller. The display devices in the earlier examples were attached
to the CTL02 controller.
Note the Port number and Switch setting parameters. Unlike tape units and diskette drives, printers
attached locally must have an address, like a display station. If auto configuration was the method used
to generate the device description, the Text parameter will be Created by auto-configuration, as shown in
Figure 6.13.
With most standalone PCs, backup consists of copying files to a floppy drive. While this approach to
backup may be inconvenient for the PC user, it is manageable. However, with the AS/400s single-level
approach to memory storage and the large volume of objects stored on the CPU, tape backup becomes
mandatory. The following material explains how to display a tape drives status and device description.
Press F12 repeatedly from the Display Device Description screen until you return
to the Device Status Tasks screen; then
Choose option 3 from the Device Status Tasks screen to Work with tape devices
Type 8 on the option line of the Work with Tape Devices screen for the device
to be displayed; in this case, TAP01
Press Enter to go to the Work with Device Description screen
Type 5 to display the description on the Work with Configuration Status screen
Press Enter
Figures 6.14 and 6.15, presented in the order in which you will access them on the system, show the
status of the tape drive.
Tape devices must be VARIED ON and therefore made available for use like other devices on the
AS/400. You can modify the status of the device from the Work with Configuration Status screen.
The tape device description, TAP01, represents a 6341 tape device, online at IPL. Note that the Text
parameter is blank. Unlike the printer device description referred to earlier, this tape drive was not
generated by automatic configuration. However, text could have been entered when the tape drive
device description was created. The tape drive device description does not display or require a local
address, because tape drives are directly connected via a controller card, through a special address called
a resource name.
Type 8 on the option line of the Work with Devices screen to Work with
description for the device; in this case, DKT01
Press Enter to go to the Work with Device Description screen
Type 5 to display the description on the Work with Device Description screen
Press Enter
Figures 6.16 and 6.17 show the status of the diskette drive. The diskette drive device description does
not display a local address because diskette drives connect directly to a controller card, through a
resource name.
Before you add new devices to the AS/400, you should first document your system hardware. Draw a
layout of the physical location of your local twinaxial devices (a simplified layout is shown in Figure
6.2). Be sure to include the device addresses in this document. The AS/400 Device Configuration Guide
contains Form C1, a Local Work Station Diagram (Twinaxial Cabling) to document your addresses and
other information needed to configure displays, printers, and other devices. Use Form E1 for Tape and
Tape Controllers. Use Form E2 for Diskette and Diskette Controllers. Make as many copies of these
forms as you need for the number of ports or controllers on your system. Refer to the literature with each
display station, printer, and other devices to complete Form C1. The Local Work Station Diagram will
bring together in an organized manner most of the information you need to create your display and
printer device descriptions. You can use various forms located in your AS/400 Device Configuration
Guide (you will find copies of these forms in Appendix B of this text) to document your hardware
information. You will find these forms to be exceptionally helpful, but you need to be sure to keep them
up-to-date. And if devices are moved or replaced, update all related forms.
Now that you as the operator are comfortable with the concept of device descriptions and how to access
existing descriptions, the next question is, How are descriptions created? There are several methods
available to configure devices. The AS/400 can configure devices automatically. For automatic
configuration, the system value Automatic Configuration, QAUTOCFG, must be set to 1 (on). As the
operator, you will plug in a new device and ensure the device is turned on; the AS/400 will then
configure the device and vary it on during the next IPL.
Automatic configuration has several disadvantages. If the QAUTOCFG system value is allowed to
remain on, each IPL sequence may create extraneous device descriptions for devices that are powered
on. This understandably creates confusion for operators and system staff. The authors recommend that
auto-configuration is turned off immediately after a device description has been created. To turn
automatic configuration off, change the QAUTOCFG system value to 0.
Another disadvantage of automatic configuration is that the system staff has no control over the name
assigned to the device. The system will assign a name that probably will mean nothing to the operator.
The staff usually will find it more convenient to have names that are easy to identify for later problem
resolution. The AS/400 lets you change object names with the RNMOBJ (Rename Object) command,
but this is an extra step.
Configuring other devices manually is frequently faster than auto-configuration, and manual
configuration also provides meaningful names for the new devices. If you need to configure a display
station that is the same type as one that already exists, copy the description of the existing display station
and change the old address to the appropriate address for the new device.
To display the Work with Device Descriptions screen (shown in Figure 6.18),
In large AS/400 shops, the Work with Device Descriptions screen may be many pages in length.
Prompting the WRKDEVD command lets you choose the specific types of device descriptions to work
with, filtering out the others. This gives you a more user-friendly working environment.
As Figure 6.19 shows, many different types of devices can be attached to the AS/400. As you might
expect, the device descriptions are either three- or six-character words. To specify a device description
for a display station,
Figure 6.19 Specify Value for Parameter Device Description (DEVD) Screen
To copy a device description, position the cursor on the option column for the 3476 display device
named TEST, as shown in Figure 6.18.
When you copy the device description, you must provide a new name and new address for the new
device, as shown in Figure 6.20.
The operator must name the device and change the Port number and Switch setting to the correct address
of the new device. Device addresses must be unique. To replace a device that requires maintenance, see
Appendix A. To name the device and change the port number and switch setting,
If you choose to, or need to, create a display station description because one does not exist to copy, type
CRTDEVDSP (Create Device Description Display) on the command line and press Enter. A screen
similar to Figure 6.21 will be shown. After you have completed entering the parameters, press Enter.
Now that the AS/400 operating system is prepared for a new display station, the display station itself
must be programmed. Locate the documentation that accompanied the hardware to find out how to
access the address screen. Some of the newer IBM models require that you hold the space bar down
while the device is powering on. Other older IBM or System/36 stations require you to adjust actual
physical switches on the device. When the address screen is available, enter the same port and switch
setting that you defined on the Create Device Description screen.
HINT:
Add to Form C1 how to access the address screen for each display station.
After the display station has been configured and addressed, turn the power off and then on again. Go to
an operators console and vary the new device on. Use the Work with Device Description display to
verify that the new device has VARIED ON.
Troubleshooting
If the newly installed display station will not vary on, ensure that the following steps have been
successfully completed:
1. Create the device description, including selecting a unique port and switch address.
2. Assign the same port and switch address to the display station address screen.
3. Vary the device on.
If the display station will not vary on, it is possible that the controller is not active. The controller for the
port must be active for the devices attached to it to function. The CTL02 in Figure 6.22 is the description
for the controller that handles the device description TEST2. Use option 1, Vary on, next to the
controller name. When the controller is shown as ACTIVE, vary the display device on. The new display
station should now be ready for use.
Press F12
You can create tape and diskette descriptions the same way you create display device descriptions by
copying one that already exists. You should update Form E1 for every new tape or tape controller
device. You should use Form E2 for a diskette or diskette controller unit connected to your system.
If you wish to create a new tape drive description manually instead of copying an existing one, use the
CRTDEVTAP (Create Device Tape) command, as shown in Figure 6.23. When you are creating a tape
device description, use the information on the E1 form.
To create a new diskette unit description instead of copying an existing one, use the CRTDEVDKT
(Create Device Diskette) command, as shown in Figure 6.24. When you are creating a diskette device
description, use the parameters with the information from the E2 form.
If you wish to create a new printer device description manually, use the CRTDEVPRT (Create Device
Printer) command, as shown in Figure 6.25.
The screen in Figure 6.25 is the first screen that will appear after you type the CRTDEVPRT (Create
Device Printer) command. After you supply the parameters with the correct information from your
printer documentation, a screen similar to Figure 6.26 will be displayed.
You can find the parameter information (other than the device description) for creating a printer
description on the C1 form. Maintaining the system layout and C1, E2, and E3 forms are important
operator tasks to provide smooth transitions while you are adding new devices or dealing with devices
that require maintenance. Meaningful device names and mapping locations of devices are also helpful
for troubleshooting purposes. This level of organization is invaluable when hardware device problems
arise and users are in immediate need of a replacement device.
Key Terms
Addresses
Configuration status
Controllers
Devices
Device descriptions
Device status
Display stations
Lines
Port
Terminals
Topology
bus
ring
star
Review Questions
Exercises
1. Fill out form C1 to describe a workstation and a local twinaxial printer. Copy the form from
Appendix Bas required.
Chapter 7
Backup, Restore, and PTFs
Objectives
To understand
To be able to
Backing up your system is a time-consuming, but necessary, task. If your system crashes and the
information it contained was not backed up, the loss to your company, both in time spent trying to re-
create the data lost and in the dollars lost for data that cannot be replaced, can be critical. Many
scenarios would require backed-up information to be restored. For example, someone accidentally or
intentionally deletes an object, a disk drive is damaged, or a virus enters your system. Whatever the
scenario, the need to back up your system regularly is critical, and your backup plan should always be
documented.
In all backup plans, it is necessary to balance the time required to back up an object with the time
constraints for restoring the object. Because restoring data generally represents an emergency situation,
most backup plans emphasize the time required to restore an object. The backup guidelines used in this
text represent a balance between the recovery time of a potential disaster and the time required to back
up all data as required for a potential disaster recovery. So a primary question becomes When and how
often should a given object be backed up? One good rule of thumb is to back up objects whenever there
is a significant change to the data. For example, a payroll system may need to be backed up weekly,
while a customer order-entry system probably requires daily backups.
Save Commands
To prevent data loss, a dependable backup plan must ensure that every object and every category of
object is saved regularly. The AS/400 operating system offers seven separate save commands to back up
different classes of objects. The following material discusses the various save commands and then ties
these commands into a comprehensive quarterly, weekly, and daily procedure.
The simplest save method uses the SAVSTG (Save Storage) command. SAVSTG saves every object on
the system. The disadvantage of this command is that it saves a sector-by-sector copy of the total
contents of DASD storage. With SAVSTG, you cannot restore individual libraries or objects. A
SAVSTG is a disk-image save and is not very flexible. But a SAVSTG backup is the quickest way to
restore an exact copy of all data to the same hardware configuration when a complete restore is required.
Because SAVSTG is not very flexible for restoring objects to a system, most installations opt for an
organized strategy of full system backup, using other backup commands.
The SAVSYS (Save System) command saves the AS/400 Licensed Internal Code (LIC), the operating
system, and all security data. This save command requires the system to be in a restricted state, which
means users cannot be signed on to the system during the SAVSYS procedure.
HINT:
Before the release of the AS/400 64-bit PowerPC boxes, many AS/400 hardware systems required
Model Unique Licensed Internal Code (MULIC) or Feature Unique Licensed Internal Code
(FULIC), installed from tapes supplied in the AS/400s service kit. These tapes contained licensed
internal code specific to your model. These tapes are very important, and management should
decide where they should be kept. If the MULIC/ FULIC tape is damaged and is not immediately
available for restoration, the system may not function. If your tape is damaged or lost, you can
request a new one from IBM and receive it within 48 hours.
The SAVLIB (Save Library) command saves libraries that contain IBM licensed programs, such as
RPG/400, COBOL/400, OfficeVision/400, and so on. SAVLIB also saves IBM-defined libraries such as
QGPL, QUSRSYS, QRCL, and most other libraries that begin with Q but that are not related to a
specific licensed program. More importantly, SAVLIB saves user libraries. User libraries usually
contain the corporate data and represent the largest volume of variable information that requires backup.
The SAVSECDTA (Save Security Data) command saves all security data including user profiles and
authorization lists that allow access to your system. This information is also saved by the SAVSYS
command, mentioned earlier.
The SAVCFG (Save Configuration) command saves configuration objects such as lines, controllers,
devices, and other communications objects defined to support AS/400. These objects are also saved by
the SAVSYS command, mentioned earlier.
The SAVDLO (Save Documents Library Object) command saves documents stored in folders for
OfficeVision objects.
The SAVCHGOBJ (Save Changed Objects) command saves objects only if they have been changed
since the last backup. IBM-supplied libraries such as QGPL, QUSRSYS, QRCL, and all other Q*
libraries may not have changes. The SAVCHGOBJ backup command will conserve time and is
commonly used in the daily backup cycle.
The SAV (Save) command can save the entire system. We recommend, however, that you continue to
use existing backup commands, as discussed above, and that you use the SAV command for the
Integrated File System (IFS) objects.
Now that we have briefly discussed some of the save commands, what is a reasonable way to implement
a backup plan? Figure 7.1 shows a suggested schedule for backing up all objects on the system. The
various save commands presented combine to save all the system objects at a minimum of every three
months. This comprehensive backup plan incorporates the various save commands to isolate data in
relatively small blocks. The small size of the objects balances the varying needs of changing objects and
keeps restore time to a minimum. Note that different save commands require different restore
commands, as presented in Figure 7.1.
Notice the Accept path (ACCPTH (*YES)) parameter in the SAVLIB and SAVCHGOBJ commands in
Figure 7.1. This parameter specifies that the access paths are to be included in the save. Saving the
access paths does increase backup time and requires more storage on backup media, but doing so greatly
reduces restore time when you are restoring during a full system recovery. However, each organization
should evaluate the savings balanced with the additional time required to save these access paths. Saving
access paths can take at least 20 percent to 50 percent longer for production data libraries. Those same
libraries may see as little as a 10 percent reduction in restore time. Also, more tapes are required if
access paths are saved. Finally, with all of this in mind, how often has your MIS department had to do a
full recovery? Some businesses will not see an advantage in saving access paths.
You should implement the quarterly save procedure every three months and after PTFs have been
applied.
You should follow the monthly save procedure every month on the same relative day; for example, the
last day of the month, whether it is February 28th, August 30th, or September 31st. A general monthly
backup should be performed after month-end processing.
You should also perform the weekly save procedure the same day every week, after any required weekly
processing is complete.
You should conduct the daily save procedure each day at the end of the day (e.g., 5:00 p.m.), after the
days processing has been completed.
HINT:
You can run the procedures in Figure 7.1 from your command line or they can be set up by your
Security Officer in Operational Assistant, which allows customized menus to execute your saves.
Tape Considerations
The most common media for backing up your system is tape. The AS/400 supports numerous types of
backup tape devices, including ½-inch reels,½-inch cartridges, ¾-inch cartridges, and 8mm cartridges.
You can use diskettes to back up smaller objects (because of their smaller storage capacity) or to transfer
files between computer systems. Whatever the media, the basic backup procedures are the same.
As you can see, the Tape menu provides nearly all the commands you will need for tape functions or to
resolve a tape problem.
The stored header information (option 1, Display tape information) provides you with a summary of data
concerning the tape currently in the drive. To access this information from the Tape menu,
The Display Tape (DSPTAP) screen shown in Figure 7.3 will be presented. As this figure shows, the
parameter Tape device defines a valid tape drive. This name will be required in later processing. The
Output parameter allows either *PRINT (printer spooled file to be generated) or * (information to
display on the screen). If the AS/400 system has multiple tape drives, you may wish to print the Display
Tape screen if youre a novice operator, to help you remember the correct spelling of the tape device
name. The Data type parameter gives you the option to display the labels or to display the save/restore
Initializing Tapes
Initializing a tape is similar to formatting a diskette on a DOS system, and the initialization must be
completed before information can be stored on a tape. Additionally, the initialization process will set up
the tape label and other required parameters, as shown in Figure 7.4. You can also use the INZTAP
(Initialize Tape) command to erase data from a tape before you reuse the tape.
To return to the Tape menu from the Display Tape (DSPTAP) Screen,
You will now see the Initialize Tape (INZTAP) screen shown in Figure 7.4.
To begin the initialization process, you must enter the Tape device parameter. This is the name of your
tape drive defined on the Display Tape screen. A maximum of 10 characters is allowed.
The New volume identifier parameter, NEWVOL, attaches an internal volume ID name to the tape.
Volume IDs help to keep multiple tapes from the same application separate and confirm when a tape is
approved for reuse. Volume IDs can have a maximum of six characters.
The New owner identifier parameter, NEWOWNID, writes an owners name to the tape. An application
name is commonly used here and is more effective than the owners name. A maximum of 14 characters
is allowed.
The Volume identifier parameter, VOL, is the volume name that was attached to this tape the last time it
was initialized. To change the volume ID, enter a maximum of six characters. Each tape should have a
unique volume ID to avoid unintentionally overwriting data. This parameter value can also be
*MOUNTED. If the value is entered as *MOUNTED, the initialization will continue for any tape
regardless of the previous name.
The Check for active files parameter, CHECK, specifies whether the AS/400 operating system checks
for active files on the tape before initialization. If *YES is specified and the system finds data on the
tape, the system will not initialize the tape.
The Tape density parameter, DENSITY, should always be specified as *DEVTYPE so that the tape is
initialized to the density supported by the tape drive.
The collating sequence of the backup refers to the CODE parameter. For continued use on the AS/400,
this parameter value should be *EBCDIC. Use the value *ASCII to restore this tape to an ASCII
computer system.
The End of tape option, ENDOPT, indicates whether the tape should only be rewound, or rewound and
unloaded (ejected) after initialization is complete. Generally, *UNLOAD is preferred only for
unattended backups.
The Clear parameter, CLEAR, defines whether the tapes data is to be deleted before initialization.
Clearing the data takes more time and the initialization process will duplicate this step. Therefore, this
parameter value is generally *NO.
Diskette Considerations
Diskettes are another magnetic medium you can use for system backup. The AS/400 supports two sizes
of diskettes: 8-inch and 5.25-inch. Both diskette types are considered local devices on the AS/400. Many
AS/400s connect with PCs, which have either 5.25-inch or 3.5-inch diskettes as part of the hardware.
We will not discuss these PC diskettes here as a backup medium because they use ASCII as their base
language, and they are considered either remote or virtual devices by the AS/400 operating system.
Lets go to the Diskette menu now so you can become familiar with the options there. From the Initialize
Tape (INZTAP) screen,
Press F3 to Exit
Type GO DISKETTE on the command line
Press Enter
The Diskette menu shown in Figure 7.5 provides the functions you will need to work with a diskette
Taking option 1 on the Diskette menu will display the diskettes volume identification and the data file
names stored on the diskette. This list is similar to a DOS directory listing and is called a file list. The
stored directory information provides you with a summary of data concerning the diskette drive. To
access the Display Diskette (DSPDKT) screen shown in Figure 7.6,
Type 1
Press Enter
As Figure 7.6 shows, the Diskette device parameter defines a valid diskette drive. The diskette device
name will be required in later processing. The Output parameter allows either a spooled file to be
generated (*PRINT), or the information to display on the screen (*). If the AS/400 system has multiple
diskette drives, you may wish to print the Display Diskette screen to help you remember the correct
spelling of the diskette device name. The Data type parameter gives you the option to display the label
or to display the save/restore information that is stored on the diskette.
You must initialize a diskette before its first use; you can also use the initialization procedure to remove
all data files on a diskette before it is reused. Initializing a diskette serves the same purpose as formatting
a DOS diskette.
To access the Initialize Diskette (INZDKT) screen from the Diskette menu,
As Figure 7.7 shows, you must enter the Diskette device parameter (DEV). This is the name of the
diskette drive that is holding the diskette that is to be initialized. A maximum of 10 characters is allowed
for the device name. You can find this device name in the Display Diskette (DSPDKT) screen (Figure
7.6). The Data type parameter on this screen gives you the option to display the labels or to display the
save/restore information that is on the diskette. The Output parameter allows you to have the
information moved to a spooled print file (*PRINT) or allows the information to be displayed on the
screen (*).
The New volume identifier parameter (NEWVOL) attaches a volume ID name to the diskette. Volume
IDs can have a maximum of six characters.
The New owner identifier parameter (NEWOWNID) attaches an owners name for this diskette.
Frequently, the owner identifier is an application name.
You use the Diskette format parameter (FMT) either for save/restore (*SAVRST) operations or to save
other formats for exchange between other systems and the AS/400.
The Sector size parameter (SCTSIZ) specifies the sector size for the format indicated in the FMT
parameter. Sector size is comparable to the tape density parameter. The default standard value *STD is
commonly used to ensure that the sector size is supported by the diskette drive.
The Check for active files parameter (CHECK) specifies whether the system checks for active files on
the diskette. If *YES is specified and the system finds data on the diskette, an error message will halt the
initialization. Leave this value at *YES if you would like to be notified if the diskette contains data. If
you wish to overwrite all the data files on the diskette, enter *NO.
The Code parameter (CODE) is the collating sequence of the backup. For the AS/400, this value should
always be *EBCDIC. You can use the value *ASCII if you are going to restore this diskette of
information to an ASCII computer system.
Press F3
HINT:
Another way to erase diskette data is to use the CL command CLRDKT DEV(device name) VOL
(*MOUNTED) CHECK(*NO)
HINT:
Initialize all tapes and/or diskettes before you begin a backup procedure. Wise operators usually
have extra tapes and diskettes prepared, because file sizes generally grow rather than shrink.
HINT:
All archived media should have an associated inventory list. This list should include the volume
ID and the purpose of the data. The off-site media should be physically inventoried annually.
Reclaiming Storage
Periodically reclaiming storage is important to the maintenance of single-level storage on the AS/400.
Remember that single-level storage allows main memory and DASD to be treated as a single accessible
unit. As a result of power or equipment failures, an object may be lost or damaged (an object that cannot
be found in a library or that has no ownership connection is considered to be lost). A damaged item is
not usable. The RCLSTG (Reclaim Storage) command may correct damaged or lost data. The RCLSTG
command searches for all objects that are not in a library, all objects without an owner, and all damaged
or destroyed objects. When the Reclaim Storage process finds objects that meet these requirements, the
system creates a library named QRCL. The RCLSTG command copies these reclaimed objects to the
QRCL library and then deletes them from the inappropriate locations. You must run the RCLSTG
command interactively from the system console; it cannot be submitted to batch. You must first be sure
all subsystems are ended. Finally, its important to know that reclaiming storage may be a lengthy
process, so you should schedule it accordingly.
Cleaning Tasks
After the diskettes and tapes are prepared and storage has been reclaimed, it is important to clean up old
files and objects that no longer are useful and should not be saved via backup. Each time a program is
compiled, a backup object is created in library QRPLOBJ. The system gives the backup object a name
that starts with a Q and ends with a number. In companies that employ programmers, the QRPLOBJ
library typically becomes very full. You should routinely clear out these objects with the CLRLIB (Clear
Library) command. Using positional notation, you can enter this command as
CLRLIB QRPLOBJ
The OS/400 keeps journals, journal receivers, and logs for tracking system activity. These objects
accumulate information daily and use DASD storage. Cleaning up old journals and journal receivers
helps keep your system running smoothly. You can automatically clean up objects that are no longer
needed by scheduling clean-up activities using the Operational Assistants Cleanup Tasks menu. To
access the Cleanup Tasks menu,
The Cleanup Tasks menu option 1 allows customization of the cleanup activities. You can also use the
CHGCLNUP (Change Cleanup) command to modify the options. The cleanup options include when to
automatically start cleanup, what objects to delete, and after how many days. To use the Cleanup
command or menu option, you must be signed on as security officer or have been given authority to use
this command. Objects located in the QRCL library (created by a Reclaim Storage activity) should be
moved to proper locations or deleted if they are unusable.
Option 2 will schedule the cleanup activities to be run automatically. These cleanup tasks are frequently
scheduled daily on second or third shift. The CL command to start cleanup at the scheduled time is
STRCLNUP OPTION(*SCHED). The cleanup will start automatically at the time specified in option 1.
Hint:
You can also access the Cleanup Tasks menu via the Operational Assistant menu. To do so, type
GO ASSIST on any command line, then choose Customize your system, users, and devices
(option 11). Next, select Cleanup tasks (option 2).
Option 4 allows you to end the cleanup tasks immediately. End cleanup will terminate the cleanup job if
it is waiting on the job queue, or you can use the ENDCLNUP command to terminate cleanup activities.
Start cleanup immediately starts the cleanup job immediately. This allows the cleanup job to run on
demand instead of waiting for its scheduled time. You can also use the CL command STRCLNUP
OPTION(*IMMED).
For practice, lets Start cleanup at the scheduled time. From the Cleanup Tasks menu,
When the cleanup tasks are completed, you can start the actual system backup.
Running a Backup
Now that the backup plan has been completed, ensuring that all objects will be saved, the diskettes or
tapes have been initialized, storage has been reclaimed, and the cleanup tasks are finished, you can start
the system backup. As with all AS/400 commands, there are multiple ways to complete a given task. In
this text, we will use the Operational Assistants customization feature.
The AS/400 Operational Assistant menu will be displayed as shown in Figure 7.9.
From this menu, select option 11, Customize your system, users, and devices.
The customization menu, as shown in Figure 7.10, provides access to the backup procedures.
HINT:
You can access the customization menu directly by typing GO SETUP on any command line.
To begin the backup tasks from the Customize your System, Users, and Devices menu,
If your Security Officer has created a backup procedure for your system, choose option number 1 in
Figure 7.11. Otherwise, you can only use the Set up backup option if you are signed on with either
Security Officer authority or have been granted authority to use this menu. For practice purposes,
assume you have this authority and choose the Set up backup option:
The Set Up Backup menu will be displayed as shown in Figure 7.12. This menu allows for changes to
the daily, weekly, or monthly backup procedures. Additionally, you can change the library backup list,
the folders backup list, or the backup schedule from this menu.
After you have defined the backup procedures as appropriate, press F3 to return to the Backup Tasks
menu (shown in Figure 7.11).
The backup procedures should be run under a user profile with *SAVSYS (Save System) authority.
SAVSYS authority speeds up the backup because the system does not have to perform authority
checking on each object.
Restricting access to the system when you are performing saves is a good practice. Many save
commands do not require restricted access, but that is the only way to ensure the save contains the most
current object a user may be using. If any user has an update or exclusive lock on a file while you run
your backups, the object cannot be saved.
Before you do a restricted backup, send all users a message telling them to sign off the system. Use the
SNDMSG (Send Message) command or the SNDBRKMSG (Send Break Message) command. For either
command, always specify the time the system will be taken down and when the users can expect the
system to be available.
You must end all subsystems except the controlling subsystem QCTL for a complete system save. Use
the ENDSBS (End Subsystem) command for each subsystem. As an alternative to using separate
ENDSBS commands, you can use the ENDSYS (End System) command, which ends all subsystems and
brings the system to a restricted state.
Now you are ready to do the system backup. Choose option 1, Run backup, to begin copying data to the
tapes. Follow the displayed instructions until the backup is complete.
If your backup strategy requires that you occasionally do an unattended backup, when you might not
have an operator available to change tapes, you can consider the option of saving objects to a save file.
A save file is an object you as the operator must create to hold a compressed version of backed-up
objects. All the objects you have requested for backup will be compressed and placed into this save file.
The save file can be transferred to a tape at a later date.
HINT:
You cannot do a save operation on a file that is being updated or that is allocated exclusively to
another job, with the exception of a journal receiver.
It is important to use caution in this process, because saving to a save file requires a great deal of DASD.
Make sure that, when the amount of memory required by the files you are saving is added to existing
DASD storage, you will not be creating a total DASD usage in excess of 80 percent. DASD usage in
excess of 90 percent will seriously degrade system performance. And if an error is made and DASD is
over-committed (more than 100 percent), then it will be necessary to do a total reload of the system.
The Create Save File screen will be displayed as shown in Figure 7.13.
To practice creating a save file, on the Create Save File (CRTSAVF) screen,
Type Your name for a practice save file name. (A descriptive name
usually is preferred.)
Type Practice as the text description of the file
Press Enter
After you have created a save file to store information, save your library to the save file using the
SAVLIB command.
At this point, the Save Library screen will be displayed, as shown in Figure 7.14.
This command saves your entire library to a save file on disk. After a save file exists on disk, you can
copy it to tape with the SAVSAVFDTA command (see Figure 7.15).
Restoring Objects
Hopefully, the ultimate disaster will not strike your system, but it is important to be organized and
prepared if the worst should happen. You must use the restore commands, with the corresponding save
commands, to replace damaged or deleted objects. At first glance, our sample backup plan may appear
to be overkill. However, you can only restore objects in a certain way. In other words, how the objects
were saved determines how the restore can be executed. The sample backup plan furnished in the text
provides flexibility for restoring quickly.
Before any backup plan is complete, you must be sure that full system backups are done on the Alternate
Load IPL Device. An initial program load (IPL) requires that the tape device be specified as the
Alternate Load IPL device. Check with your system administrator to see which device is your Alternate
Load IPL Device.
To completely restore your system, you should take the following steps:
1. Restore licensed Internal Code (LIC) and Model Unique Licensed Internal Code (MULIC).
IBMs Backup: Recovery Basic Guide, explains how to restore the LIC and MULIC. Restore the
LIC from your most recent SAVSYS tapes.
If your system displays system reference code A6xx6051 (where xx is a MULIC tape number),
restore the MULIC from your service kit tapes. Then restore the operating system from your
SAVSYS tapes.
Your sign-on must be as the Security Officer, QSECOFR. If the Security Officers password has
changed since the last system save, you must use the old password to ensure a password match.
2. Type GO RESTORE and press Enter to go to the Restore menu.
3. Take Option 21, System and user data. This will restore all the IBM Licensed Program
Products, user libraries, document library objects, and IFS objects, all with full prompting.
4. At the End Subsystem command prompt, press Enter.
5. Press Enter to respond to informational messages.
6. At the User Profile command prompt screen,
Press F10 for additional parameters.
Change Allow object differences to *ALL.
Change Output member options replace or add records to *ADD.
Press Enter.
7. At the Configuration command prompt screen,
Change System resource management to *NONE.
Press F10 for additional parameters.
Change Allow object differences to *ALL.
Change Output member options replace or add records to *ADD.
Press Enter.
8. At the Restore Library command prompt,
Press F10 for additional parameters.
Change Database member option to *ALL.
Change Allow object differences to *ALL.
Change Output member options replace or add records to *ADD.
Press Enter.
9. At the Restore Document Library Objects command,
Press F10 for additional parameters.
Change Allow object differences to *ALL.
Change Output member options replace or add records to *ADD.
Press Enter.
10. At the Restore Authority command, press Enter.
11. At the Start Subsystems command, press F3 to exit.
12. Type SIGNOFF *LIST to send the JOBLOG to an output queue and press Enter.
13. Sign on.
14. Turn the keylock to normal.
15. Type PWRDWNSYS *IMMED and press Enter.
16. When the IPL is complete, use DSPTAP to inventory the latest SAVCHGOBJ tapes so you
know which libraries and objects are represented.
17. Using the DSPTAP lists, use the RSTOBJ command to restore changed objects.
When a complete system restore is not required, you may find it more convenient to use the following
menu options:
Figure 7.16 displays the restore commands explained earlier in the text. Use the prompt screen for
additional options.
As weve said, the need to restore an object or to recover from a disaster will, hopefully, never occur; but
good planning and documentation will provide an organized process to correct any unforeseen problems.
Regular system backups are a necessary prerequisite for peace of mind.
When IBM becomes aware of a problem in its software (problems are either discovered by IBM staff or
reported to IBM by AS/400 users), IBM first generates an authorized program analysis report (APAR) to
study the problem. If necessary, IBM creates a program temporary fix (PTF) to correct the problem. A
PTF is labeled temporary because IBM documents the problem and incorporates the correction into the
next release or modification of the software. When a PTF is generated, it usually corrects one problem
and is called an individual PTF. However, IBM also puts together cumulative (CUM) PTF packages,
which are aggregates of the individual PTFs. A convenient way for you to manage PTFs is through the
cumulative PTF packages.
Individual PTFs include a cover letter that explains what device or software required the correction, as
well as other pertinent information. Always read the cover letter, because you may find important
information there about how the PTF will correct a problem your system may be experiencing. Follow
the instructions exactly.
You can order PTFs through IBMs Electronic Customer Support (ECS) system. When you use ECS, the
cover letter is stored in a file named QAPZCOVER in the QGPL library. Version 2 users will note that
the QAPZCOVER file will contain a member name starting with a P followed by the PTF number.
Version 3 users will note that the member name now starts with a Q. To display the cover letter, use the
DSPPFM (Display Physical File Member) command or print the cover letter with the CPYF (Copy File)
command, specifying QSYSPRT for the To file parameter.
High-impact and pervasive (HIPER) PTFs are critical PTFs, because they fix problems that can crash
the computer or severely degrade performance, or they correct a multitude of machine problems. HIPER
PTFs are usually in a separate classification from other PTFs and should receive top priority to be loaded
onto the system.
To order individual PTFs, you will need the PTF number. IBM has created some reserved PTF numbers
that you can use to order particular types of PTFs. In the list that follows in Figure 7.17, v is the OS/400
version number, r is the release number, and m is the modification level. Therefore, for V3R1M0, vrm
would be replaced by 310. Note that some of the PTFs are informational reports, not program objects.
To order PTFs through ECS, use the SNDPTFORD (Send Program Temporary Fix Order) command. In
Figure 7.18, the parameter PTF Parts offers a choice of receiving the cover letter and the PTF code,
*ALL, or just the cover letter, *CVRLTR. Because your particular AS/400 may not have the hardware
or the software associated with the PTF, it may be helpful to initially download only the cover letters.
The Delivery method parameter with the *ANY value indicates that if the PTF is small enough, it should
be transmitted electronically through the ECS modem line. Most PTF listings and reports are delivered
electronically. The delivery method parameter of *ANY is replaced with the *LINKONLY value and
the PTF is sent through the ECS line. The ECS program will download the PTF save file to DASD. If
the PTF exceeds the *LINKONLY size, such as with a CUM PTF, IBM will mail a tape within 48 hours
of when you placed the order.
The Order parameter with the *REQUIRED value performs additional PTF verification. If the needed
PTF has a prerequisite, both PTFs will be sent. You can request the *PTFID value, which lists the
prerequisite PFT IDs. This may be helpful to determine whether the earlier PTF has previously been
installed.
The Reorder parameter value can be either *YES or *NO. Specifying *NO will cause the system to
check whether the PTF is already loaded and/or applied on your system. If the PTF is loaded, the
SNDPTFORD command ends with an error. The system is attempting to avoid a duplicate order.
To reorder the cover letter only, specify *CVRLTR for the value of the PTF parts parameter and change
the Reorder parameter to *YES.
Figure 7.18 shows a sample of an order for an individual PTF. To order a cumulative PTF package, type
the following command: SNDPTFORD SF99vrm. The vrm is the version, release, and modification
level of your system. For example, to order a CUM tape for Version 3 Release 1 Modification level 0,
type SNDPTFORD SF99310.
From time to time, you may need to apply individual PTFs. You can order them in small groups of up to
20 at a time via the ECS modem. If the ECS modem is a 2400 bps modem, or if the quantity of PTFs is
more than just a few, then you can change the DELIVERY method to *ANY, so you can receive the
PTFs on tape. Custom Preventive Service Packages are usually mailed within 48 hours after order
placement..
PTFs are of two general types: Microcode Fixes, or PTFs that begin with MF; and System Fixes, for all
other PTFs that begin with SF. All PTFs can be applied Permanent, applied Temporary, and some may
be applied Immediate. Most fixes are best applied Temporary, but occasionally they must be applied
Permanent right away. Consult the cover letter that comes with the PTF. Look for special instructions,
and follow them. You can usually remove temporarily applied PTFs if they cause a problem. You cannot
remove permanently applied PTFs.
PTFs usually require an IPL before they are applied. There are PTFs that you can apply Immediate.
Even PTFs that are Immediate usually carry special instructions to become active, and they may be more
conveniently applied with the next unattended IPL.
Any and all PTFs can be Loaded and Applied during regular hours and marked for Apply at the next
IPL. Because you can normally do an IPL after a weekly unattended full-system save, the PTFs will be
applied without any additional effort. You should be aware that applying PTFs during an IPL can greatly
increase how long it will take to perform the IPL.
Microcode Fixes (MFs) carry special importance because they affect basic machine functions, or those
basic services that are below the machine interface (MI). Because of their importance, there are actually
two copies of these fixes: One group contains all the Permanently applied MFs and is called the A side;
the other group contains all of the MFs, including the latest Temporary applied MF PTFs. Because of the
importance of the Microcode to the entire computing environment, if a new Temporary applied MF PTF
causes a problem, the system can be IPLed to the A side and, in essence, be restored immediately.
The front panel of the AS/400 can show an A or a B, but that is not the best place to look to see on
which side of the Microcode the system is running. Often, during the automatic install process of a CUM
tape, the front panel can show A but the system is actually running on the B side. The system is just
looking ahead. To make sure, type DSPPTF and press Enter. The first group of PTFs displayed will be
the MFs, and the top of the screen is the last IPL source. Most systems in a normal production
environment should run on the B side. Most temporary PTFs are running on the B side. When the PTFs
are made permanent, they are, essentially, copied to the A side; the machine will then IPL from side A.
Figure 7.19 displays the Program Temporary Fix menu. All the options needed to manage PTFs are
located on this menu. Temporary fixes that are not transferred electronically from ECS are mailed either
on tape or diskette media, and they need to be loaded onto the system.
Option 1 on the above menu loads individual PTFs from tape, diskette, or a save file (*SAVF).
(Remember, a save file is a compressed and unreadable file.) To load a PTF,
This will take you to the Load Program Temporary Fix (LODPTF) screen, shown in Figure 7.20. The
PTF numbers to select and the PTF numbers to omit options shown in this figure are referring to the PTF
numbers that identify the PTFs. All PTFs are identified by a unique number, to connect the PTF with the
hardware device or application software problem that necessitates the correction.
Press F3 to Exit
CUM tapes should be installed using the instructions sent with the tape. Usually, those instructions will
lead you through many preparatory steps that are necessary to ensure the successful installation on the
CUM PTFs. The CUM tape can be installed during normal business hours. Just remember to change the
option Automatic IPL after install?, as shown in Figure 7.21, to *NO. Additional PTFs may also be
applied and marked for IPL action. Then let the next unattended IPL, after the dedicated system save,
apply all the above.
Now youre ready to load the cumulative PTFs. From the Program Temporary Fix (PTF) menu,
Use the Manage Licensed Programs menu to verify that the PTFs were successfully installed. To access
this menu,
The system presents a series of messages that inform you whether the PTF was installed successfully.
Look for the word failed anywhere in the messages, such as Loading of PTFs failed or Marking of PTFs
delayed, application failed or even Applying PTFs failed. Occasionally, IBM issues PTFs that do more
damage than good; these PTFs are reported in the HIPER PTF packages as PTFs in error. Anytime
before a PTF is applied permanently, you can remove it with the Remove a program temporary fix,
option 4, on your Program Temporary Fix menu. Ensure that the PTFs are, in fact, working properly
before you apply them permanently.
Press F3 to Exit
Anytime after you load and/or apply PTFs, and before you apply PTFs permanently, you should display
them. The DSPPTF (Display PTF) command, in its simplest form, provides a list of all PTFs currently
on the system and their status. The status can be applied temporarily, permanently, loaded, or
superseded. To display the PTF status, go to the PTF menu, then
This will take you to the Display Program Temporary Fix (DSPPTF) screen, shown in Figure 7.22.
This additional information is brief (and sometimes confusing), but it can be helpful. The DSPPTF
(Display Program Temporary Fix) command accepts several parameters to help you narrow the list of
PTFs. For example, prompt the Product parameter to select just the PTFs for a particular application
package. Request that the list be sent to *PRINT to generate a spooled output file, then place the report
with other system documentation.
Press F3 to Exit
PTFs are a necessary part of AS/400 maintenance. We recommend that you load and apply a CUM PTF
package every three or four months. If your system has problems that you cant seem to pinpoint, the
solution may already be waiting in a PTF. To further avoid problems, you should keep a printed list of
all PTFs near the CPU. If your computer is experiencing problems and cannot IPL, this list can be very
beneficial to the IBM support group as they help you resolve the problems.
Key Terms
Backup
PTF
cumulative
temporary
Review Questions
6. The Delivery method parameter with the SNDPTFORD command defines what? What is the
difference between the value choices? Why choose either one?
7. PTFs should be loaded and installed on what area displayed on the CPU panel?
Exercises
Chapter 8
Subsystems and Performance
Objectives
To understand
To be aware of
To be able to
Subsystems
As we mentioned in Chapter 1, all work on the AS/400 is carried out in subsystems. Subsystems are
started when the AS/400 powers up and loads the operating system and other necessary objects into
main memory. When the AS/400 is first installed, practically all work, including interactive and batch
jobs, is performed by subsystem QBASE. This simple arrangement is convenient for installation but
doesnt take advantage of the systems capabilities. Separating the work load into additional subsystems
improves performance; in fact, some individual software applications available on the AS/400 are
designed to run in their own subsystems. Many administrators have found maximum AS/400 efficiency
by placing each specific type of job into its own subsystem. For example, establishing separate
subsystems for batch, interactive, and communications jobs provides much more control over creating
system performance consistency.
The AS/400 comes preloaded with the basic subsystems to be used in a multiple subsystem
configuration: QCTL, QINTER, QSPL, QCMN, and QBATCH. QCTL is the controlling subsystem in a
multiple subsystem configuration. QINTER is the subsystem that supports interactive jobs. The QSPL
subsystem handles spooled file jobs, including placing files or jobs into disk storage for later processing
or printing. The QCMN subsystem supports communications jobs. Finally, QBATCH is the subsystem
that supports batch jobs. Although the AS/400 allows for virtually any combination of jobs within
subsystems, you should not override the defaults because doing so will reduce the systems efficiency.
The system console is attached to the QCTL subsystem. This configuration is important for many
reasons, but the most important concerns IPL. When the AS/400 performs an IPL, the system console is
the only display station capable of carrying out functions until the IPL is complete. Specifically, QCTL
begins an auto-start job at IPL. The auto-start job then starts the four system-supplied subsystems:
QINTER, QSPL, QCMN, and QBATCH.
HINT:
To change the controlling subsystem requires Security Officer authority. If you have the
appropriate authority, you would use the CHGSYSVAL (Change System Value) command to
change your controlling subsystem.
To check whether the controlling subsystem on your AS/400 is QCTL, use the DSPSYSVAL (Display
System Value) command, as shown below.
Press Enter
You will be shown the Display System Value screen, represented in Figure 8.1, which displays the value
for the controlling subsystem. In this example, QCTL is the controlling subsystem and it is located in
library QSYS.
To work with a subsystem on the AS/400, use the WRKSBS (Work with Subsystem) command. To
designate a particular subsystem, type WRKSBS [subsystem name] using positional notation. The
default for the name of the subsystem parameter is *ALL. To access the Work with Subsystems screen
(shown in Figure 8.2),
The Work with Subsystems screen shows all the subsystems that are currently active. If a subsystem is
not active, it will not be displayed.
HINT:
To start a subsystem, use the STRSBS (Start Subsystem) command on any command line.
The WRKSBS display lets you as the system operator Work with subsystem jobs by typing 8 in the
option column next to the appropriate name of the subsystem. This is a convenient way to verify if, and
how many, jobs are running in a subsystem.
System Pools
As we have discussed, subsystems are generally created to improve system performance for different
departments, or for different users needs. Each subsystem is defined to run in a system pool based on
how many resources the job is likely to require. A system pool, also called a storage pool, is a logical
division of main memory reserved for processing a job or group of jobs. AS/400 subsystems are
preassigned to main memory pools by the operating system.
We can compare system pools to multiple swimming pools. A reasonable approach to sharing the
swimming pools would be to dedicate each swimming pool to a particular type of swimmer. One pool
might be dedicated to lap swimming, one to diving practice, and one to children for splashing and
playing. System pools work in the same way, with work divided into types of jobs.
Each storage pool has a predefined size and activity level. Activity levels are the maximum number of
jobs that can be run simultaneously in the particular storage pool. We can also relate activity levels to
the swimming pools example. The lap pool might only have eight lanes, while the diving pool may be
able to efficiently handle a dozen divers, and the childrens pool may have a maximum limit of 75
children.
By limiting the number of jobs sharing the storage pool, each job secures just enough resources to run
efficiently. Having a large number specified for the activity level will allow many more jobs to enter
main storage. These jobs will compete for system resources, ultimately slowing the completion of all the
jobs.
When the AS/400 is shipped, all of main storage resides in two system pools: the machine pool
(*MACHINE) and the base pool (*BASE). The machine pool must be defined to support your system
hardware; the amount of main storage allocated to the machine pool is hardware-dependent and varies
with each AS/400.
The base pool is the main storage that remains after the machine pool is reserved. *BASE can be
designated as a shared pool for all subsystems to use to process work, or *BASE can be divided into
smaller pools of shared and private main storage. Other shared storage pools you can define include
*INTERACT (for interactive jobs), *SPOOL (for printers), and *SHRPOOL 1 to *SHRPOOL 10 (for
pools that you can define for your own purposes).
Shared pool sizes are controlled via the CHGSHRPOOL (Change Shared Storage Pool) or
WRKSHRPOOL (Work with Shared Storage Pools) commands. Figure 8.3 shows a WRKSHRPOOL
screen, on which the pool size or activity level can be modified simply by changing the entries.
The AS/400s default controlling subsystem (QBASE) and the default spooling subsystem (QSPL) are
configured to take advantage of shared pools. QBASE uses the *BASE pool and the *INTERACT pool,
while QSPL uses *BASE and *SPOOL.
To see what pools a subsystem is using, use the DSPSBSD (Display Subsystem Description) command;
for instance, when you execute the command in keyword notation:
the following pool definitions for QBASE will be listed (if the defaults have not been changed):
The parentheses group together two definitions, each containing two distinct parts (the subsystem pool
number and size. In this example of the QBASE pool definitions, the (1 *BASE) represents the
subsystem pool number of 1 and the special value of *BASE to indicate the pool size, meaning that the
system will use all of the *BASE as a shared pool. A third part of the pool definition doesnt appear on
this screen: the activity level. The system value QBASACTLVL contains this value. The second pool
definition for QBASE is (2 *INTERACT). Because pools can be modified by other commands (such as
CHGSHRPOOL or WRKSHRPOOL), the activity level is not listed for this subsystem description.
Be careful not to confuse subsystem pool numbering with system pool numbering. The AS/400s two
predefined system pools, *MACHINE and *BASE, are defined as system pool number 1 and system
pool number 2, respectively. (The *MACHINE storage pool is reserved for hardware needs. The *BASE
storage pool is shared and drawn from as needed for batch jobs or other jobs not able to acquire enough
memory from other pools. The *SPOOL storage pool is used for spooling output jobs, and the
*INTERACT pool is used for interactive jobs. The values for pools will vary depending on your system
hardware resources.)
Pool numbering within a subsystem is unique to that subsystem, and only the routing entries in that
subsystem use it to determine which pool jobs will use, based on the routing data associated with each
job. As subsystems define new storage pools (shared or private) in addition to the two predefined system
pools, the system simply assigns the next available system pool number to use as a reference on the
WRKSYSSTS display.
For example, with the above pools for QBASE and the following pools for QSPL,
the system pool numbering might correspond to the subsystem pool numbering shown in Figure 8.4.
A private pool is a specific allocation of main storage reserved for one subsystem. Its common to use a
private pool when the system uses the controlling subsystem QCTL instead of QBASE. Although using
QBASE as the controlling subsystem lets you divide main storage into separate pools, using QCTL is
inherently easier to manage and administer in terms of controlling the number of jobs and performance
tuning.
Now lets look again at Figure 8.2 (page 155). In this example, the Subsystem Pools area (numbered 1-
10) identifies which system storage pools are used by each subsystem storage identifier. The numbers
below the Subsystem Pools heading, which correspond to the subsystem name, are the identifiers for the
system pools. To attach a name to the system pool number in use, you will need to access the
WRKSYSSTS (Work with System Status) display, shown in Figure 8.5. To do so,
The System Pool column in Figure 8.5 displays the number that corresponds to the system pool numbers
displayed vertically in Figure 8.2 on the Work with Subsystems display.
Ending Subsystems
You can use the ENDSBS (End Subsystem) command to end any subsystem. For example, you might
want to end a remote subsystem at the end of the day so there is no access at night. But remember to be
careful not to end subsystems while users are running valid jobs within them.
When you need to end a subsystem with the ENDSBS command (the End Subsystem command screen
is displayed in Figure 8.6), the system will prompt you for the name of the subsystem you wish to end;
the prompt is for either a controlled end, *CNTRLD, or an immediate end, *IMMED.
A controlled end allows all active jobs to continue for as long as the Delay time parameter specifies.
You can change the value of the Delay time parameter for a given number of seconds, or you can
specify no maximum, *NOLIMIT, so that all active jobs continue indefinitely.
Immediate end forces the system to take drastic measures to end the jobs; if users are updating files
(especially keyed files), the AS/400 operating system may have to repair the files the next time you IPL,
which could cause the IPL to take much longer.
System Performance
Everyone who has worked on an AS/400 has experienced days when the system seems especially slow.
Interactive processing needs usually are high between 8:00 a.m. and 5:00 p.m.; at midnight of the same
day, processing needs are generally quite different. Disk storage (DASD), main memory (storage pools),
central processing Unit (CPU) time slices, run priorities, and job states combine to execute the system
duties and user tasks with various degrees of efficiency.
The AS/400 automatically adjusts pool sizes and activity levels with the QPFRADJ (Automatic
Performance Adjustment) system value. The QPFRADJ value indicates whether the system should not
adjust resources, should adjust resources at IPL or at regular intervals, or should do both. Activity level
and pool sizes will be calculated by the system and changed during IPL if the value 1 is specified. The
system will calculate and change pool sizes and activity levels at regular intervals and at IPL if the value
2 is indicated. A value of 3 for the QPFRADJ system value indicates that the system will calculate and
change resources at regular intervals but not at IPL.
However, many systems can benefit from additional minor tuning changes to improve their
performance. The AS/400 MIS staff can monitor system performance and tune the AS/400 for maximum
efficiency. Security Officers are generally the only people who can actually modify the system.
However, system operators often monitor AS/400 performance; it is the job of the system operator to
inform the Security Officer that changes may be needed. The following discussion will demonstrate how
to observe and calculate the best performance balance for your system, and how to prevent bottlenecks
from occurring.
The computer department should first define the organizations preference for system performance goals.
One possible definition might be that programmers should have system priority for compiles and testing.
Another definition might be that the customer-support department have the highest system priority. By
pinpointing the areas within the organization where performance is most important, the computer
department can more easily balance DASD, main memory, and the CPU. Any one of these areas can
become a bottleneck. Main memory and DASD are finite resources, having room for only a certain
number of jobs. The OS/400 operating system effectively manages the efficient use of the AS/400s disk
drives. But it is necessary to monitor disk usage to ensure that total disk usage does not exceed 80
percent of the available disk space. If disk usage exceeds 80 percent, performance may become very
poor and the possibility of a system crash is significant. If disk usage does exceed 80 percent, removing
seldom-used applications or purchasing more DASD may be necessary.
CPU considerations are varied and are considerably different from those related to main memory and
DASD. The CPU uses time slices, run priorities, and job states to effectively manage the jobs that are
submitted for processing.
A time slice is the amount of processor time a job has available before the CPU moves to other jobs of
equal or higher priority. The run priority indicates the importance of the job. Within a single storage
pool, the job that has been given higher priority will acquire system resources first. On the AS/400, the
run priority number is a ranking from 1 to 99, with 1 being the highest priority. Do not confuse the run
priority (which determines the priority of the job while it is executing) with the job priority (which
determines the relative order of a job waiting on the job queue).
As an example of how the system prioritizes jobs, AS/400 print writers have higher priority than
interactive jobs, because printers use so little processor time that they dont significantly delay other jobs.
Giving print writers high priority makes better use of the printer and speeds system throughput.
Additionally, the system values usually give higher priority to interactive work than to batch jobs, just as
you would give higher priority to people who are waiting on the phone than to requests you have
received in the mail. Batch jobs generally have the lowest priority and access system resources only
when jobs with higher priority are inactive.
Job States
Another concept related to jobs is the job state. Jobs running on the AS/400 are in one of three states:
active, waiting, or ineligible. A job is considered active when it is occupying storage, using the
processor, and has not exceeded the activity level of the storage pool. We can relate the active status to a
swimmer actually swimming in the lap pool and using one of the lanes.
A waiting job is generally inactive until the next user request is initiated. For example, the interactive
user may be discussing a problem with a customer and not currently entering any data into the computer.
This job takes one of the activity level slots because the user may press a function key or the Enter key
at any time.
An ineligible job cannot occupy storage or use the processor because the activity level has reached its
maximum limit.
Jobs shift between job states automatically, depending on the systems work load. For example, when a
user presses the Enter key at the workstation and there is room within the activity level range, the users
interactive job passes from the wait to the active mode. If, however, the activity level limit has been
reached for that storage pool, the job changes from wait to ineligible and remains ineligible until some
other job leaves the active state. The ineligible job will then make the job transition from ineligible to
active. If an active job request reaches the end of the time slice without conclusion, the system checks to
determine whether some other job of equal or higher priority in the same storage pool is in the ineligible
state. If a job is ineligible, the active job transfers from an active to an ineligible state to allow the other
jobs to run. This means, then, that if another job of equal or higher priority in the same storage pool is
ineligible, the current job becomes ineligible when it reaches the end of its time slice. This lets other
jobs move into the active or wait states to be executed or wait their turn. When a job is completed or an
interactive user signs off, the job is removed from the system.
Now that you have the information you need to understand the basic concepts underlying system
performance, lets look at how you can specifically measure that performance.
You can identify system performance values by observing the Work with System Status
(WRKSYSSTS), the Work with Active Jobs (WRKACTJOB), and the Work with Disk Status
(WRKDSKSTS) screens and then completing some minimal calculations. For a one-week period, run
these three commands several times a day, trying to do so at approximately the same time each day.
Take your measurements during a busy time. Take five snapshots of each screen about one minute apart
to record average response times for interactive jobs. An easy way to do this is to use the Print Screen
key and the F5 (Refresh) key.
The machine shown in Figure 8.7 has four system pools. The pool size is the amount of main memory
storage available, expressed in pages. Pages are blocks of information set aside to hold information
required for the jobs that are running. If a pool is not large enough to hold all the information needed for
the job, then the information must be retrieved from DASD. This retrieval time will slow job completion
and may cause other jobs to be placed in an ineligible job state.
The machine pools reserved size shows the amount of memory that is reserved for each pool. The
system calculates the reserved size using storage pool sizes and activity levels. You cannot directly
change it.
The maximum number of jobs that can be in main storage simultaneously is shown in the next column.
This number is not the same as the maximum number of jobs that are currently active.
Database Faults is the value that indicates the number of times per second that database information was
requested but was not available in main storage. This data must then be retrieved from disk and placed
into main storage, ultimately slowing down the system. Database Pages is the rate per second that
database pages (512 byte blocks of information) are being retrieved from disk into main storage. The
Non-Database Faults and Pages columns indicate the same information for data that doesnt fall into the
database category, such as program code.
The machine pool (system pool 1), which contains low-level system code and OS/400 licensed
programs, plays a significant role in affecting system performance. The size of the machine pool is held
in system value QMCHPOOL. You will not usually change this system value, because setting the
storage pool too small will adversely affect performance. You can monitor general system performance
by observing the machine pool faulting and paging rates on the WRKSYSSTS display. The chart in
Figure 8.8a illustrates typical faulting ranges, and how they usually affect performance.
Figure 8.8a Sample from Work with System Status (WRKSYSSTS) Screen
If monitoring reveals that the machine pool performance is poor, you should make your Security Officer
aware of the actual values.
Other Pools
The guidelines for system pools 2, 3, and 4 are not as simple as those for the machine pool (see Figure
8.8b). You must consider each of these pools individually. The purge attribute of jobs in the pool and the
AS/400 model affect the evaluation of system performance. The purge attribute is a work management
tuning parameter. The PURGE parameter value is either *YES or *NO. The recommended value for
most environments is *YES. The *YES purge attribute is the capability of a job to be removed from
memory (or to be paged out) at the end of its time slice. If there are long waiting times, or if a job
requires great quantities of memory, the *YES frees memory for other jobs to use. The purge value of
*NO tends to create higher default rates. When jobs are small or memory is plentiful, however, *NO lets
a job stay in main storage until the job can become active again.
Figure 8.8b Sample from Work with System Status (WRKSYSSTS) Screen
For each pool, add the database faults and the non-database faults to create a result. Find the figure from
Table 8.1 that applies to your systems hardware model type. You can use the appropriate figure, purge
attribute, and the result calculated above to evaluate your systems performance.
If monitoring reveals that a pool performance is poor, you should inform your Security Officer of the
actual values.
In summary, find the system memory pools that have the highest page-faulting rates, and look for any
unusual causes for faulting. For example, these might include compiles in the wrong pool, large queries
running simultaneously, and/or interactive save/restore operations. Determine whether the causes for
high faulting are likely to occur regularly; if so, scheduling changes may be in order. If your system
needs a more permanent solution, purchasing additional memory or disk drives may be necessary.
Possible signs of bottlenecks would involve variations in job priority within the same storage pool,
unusually high CPU usage, and slow response time. Jobs in the same memory pool with different
priority may cause problems, because jobs with low priorities cannot compete with jobs of higher
priority. Because programmers tend to have higher system priority and use more resources when they
are compiling or testing applications, other users could become locked out. One possible suggestion to
prevent this from happening might be to separate programming jobs from other interactive users by
giving programmers a separate subsystem.
To monitor the CPU usage of individual jobs, access the Work with Active Jobs screen by typing
WRKACTJOB on a command line and pressing Enter. Using the same measuring techniques as you did
for the WRKSYSSTS screens, collect the new data (an example is shown in Figure 8.9). From the initial
display, press the F11 key to generate the Elapsed Time display, then print the screen. You rarely use the
WRKACTJOB screen, because displaying the information for each job requires considerable system
overhead. In this text, we specifically do not have all the students perform the WRKACTJOB command
during the class period, because when everyone in a large class requests this screen, the system response
time will degrade dramatically.
Figure 8.9 Sample from Work with Active Jobs (WRKACTJOB) Screen
If CPU usage is high since a particular job has begun, it might be wise to submit this job as a batch job
instead of an interactive job. For example, query jobs use great quantities of CPU time, effectively
locking out other interactive users; such jobs are generally better if they are submitted as batch jobs.
Another area that can point out problems in performance is the Rsp column of the Work with Active
Jobs, Elapsed Time screen, as shown in Figure 8.9. This column represents the average interactive
response time for a job, expressed in seconds. Response is generally expressed numerically. However, if
the response is noted as a series of pluses (+++), then this particular job or workstation is not getting its
share of time slices. Many factors could contribute to this situation. It is possible that the job is not
getting its time slice because it is sharing a pool with jobs that have a higher priority. Another reason
might be that all the system resources are being used on a large job that might better be submitted at
night. Another reason might be that a large number of interactive users are active, requesting the same
resource at the same time. Sometimes, the +++ will appear for only a few seconds until the system
processes the requests the +++ should not occur for long periods. If the situation persists, notify your
Security Officer.
One disk unit will always be used more because this unit contains the system programs. This is also the
disk unit from which the operating system will load. All other non-system unit usage should be
relatively balanced. As we previously mentioned, the total disk storage used should not exceed 80
percent of the total available space. If any of the non-system disk units becomes exceedingly full, poor
performance and possible disk crash may result.
This will display the Work with Disk Status screen (Figure 8.10). Again, please note that the following
figure is only a portion of this screen.
The unit column in Figure 8.9 refers to the number assigned to each individual disk drive. The % Busy
value should not exceed 40 percent. When the busy percentage is high, the AS/400 will have long
queues of waiting jobs and all the time slices will be used as the system attempts to access the data
required for the jobs in the queues. Users will note system degradation and longer turnaround times.
Scheduling jobs at non-peak periods may be one way to relieve the daytime load on the system. If
rescheduling jobs does not correct the problem, your organization may have to purchase additional
DASD for the system.
If system performance has degraded because of excessive disk usage, you should delete unnecessary
files from the disk. Occasionally, you may be able to back up seldom-used application packages and
programs and remove them from the system. You can place these programs back in DASD when they
are needed. One such example might be a budget package that is only used during one or two months of
the year.
An AS/400 Performance Tools program is also available from IBM. The Performance Tools program
supplies tools to measure performance and interprets the results and makes recommendations from the
results. Often, the Performance Tools program recommends running batch jobs when the system is not
so busy.
Powering down a computer system as sophisticated as the AS/400 is not like turning the power switch
off on a personal computer. Often, the system will be running jobs that you might not even be aware of,
and you must be careful to not interrupt those jobs by powering down the system. For example, the
AS/400 may be running batch jobs that communicate with remote systems or that are printing reports.
You can check system activity with the WRKACTJOB (Work with Active Jobs) command. The Work
with Active Jobs screen, shown in Figure 8.11, shows what jobs are currently active that is, what jobs
are actually running. Some jobs are system jobs that youll see all the time, even when youre the only
user on the system. To access the Work with Active Jobs screen,
Remember that you should use the WRKACTJOB command infrequently because the system requires
considerable overhead to display information about each job.
If you dont need to see all active jobs during your normal daily work, you should consider using the
WRKUSRJOB (Work with User Jobs) command, which displays jobs by user profile name, or the
WRKSBSJOB (Work with Subsystem Jobs) command, which displays jobs by subsystem name (Note
that the easiest way to confirm that no new jobs start on the system is to end all the subsystems.)
You should send a message to all your users before you power down. This message should be friendly
yet authoritative. Allow users plenty of time to end the tasks theyre performing. The best way to
announce an anticipated power down is to send everyone a break message using the SNDBRKMSG
(Send Break Message) command. This command sends a message that is immediately displayed at the
users screen, interrupting whatever the user is doing. The user will probably read the message and be
forced to press the Enter key to return to whatever (s)he was doing. The Send Break Message
(SNDBRKMSG) command screen is displayed in Figure 8.12.
In the example shown in Figure 8.12, the same message is sent to all display stations. Unfortunately, this
means that, for any display stations that are not active at the time the message is sent, the message will
be displayed to the next user who signs on at that station, possibly the next day.
The PWRDWNSYS command actually turns off the system. As shown in Figure 8.13, the screen is
similar to that displayed with the ENDSBS command, in the respect that this screen also has a How to
end parameter that accepts either *CNTRLD or *IMMED. This parameter is of value only if you havent
ended the subsystems beforehand. If all subsystems are ended, the value you select in this parameter is
irrelevant. Shutting down the system with the PWRDWNSYS command doesnt cut electrical power
from peripheral devices such as display stations and printers; these devices must be shut off individually.
The Restart after power down parameter of this command is very important. Specifying *NO for this
parameter causes the system to actually shut itself down, removing electrical power from all CPU
components. If you choose *YES for the Restart after power down parameter, the system goes through
the motions of powering down; but before the power is shut off, it starts again. This is how you can
perform an IPL without shutting down the system entirely.
Key Terms
Database faults
Page
Subsystems
Job states
QCTL
Time slices
Machine pool
QBASE
Non-database faults
Shared pools
Review Questions
1. When you are running the AS/400 in multiple-subsystem configuration, what are the four
basic subsystems? What is the controlling subsystem?
2. Subsystems are created for what purpose?
3. When you are ending a subsystem, define the difference between a controlled end and an
immediate end.
4. What is the disadvantage of using the WRKACTJOB command during your normal daily
activities?
5. Looking at the screen below, what is the +++? Why is this happening?
6. Looking at the screen print below, is this acceptable performance for an AS/400 Model C25
system with more than 12 MB of memory? Is the Purge Attribute *YES acceptable for the model
C25?
Exercise
1. Using the WRKSBS display, print the subsystem description for the QINTER subsystem.
Chapter 9
PC Support/400 and Client Access for OS/400
Objectives
To understand
PC Support/400 and Client Access for OS/400 are IBM licensed software products that provide AS/400-
to-Personal Computer (PC) connectivity and communications. These products provide such features as
terminal and printer emulation, data transfer, and shared folders, among others. We will discuss the
details of these and other PC Support and Client Access features in later sections of this chapter. Before
Version 3 of OS/400, IBM's AS/400-to-PC connectivity and communications product was called PC
Support/400. With Version 3 of OS/400, PC Support/400 was replaced with Client Access for OS/400.
Because many AS/400 shops have not upgraded to OS/400 Version 3, as a system operator you are
likely to encounter both PC Support/400 and Client Access for OS/400 (referred to as PC Support and
Client Access from here on). The two products share many of the same capabilities, but their features
may be presented differently depending on whether the DOS or Microsoft Windows version is used.
PC Support and Client Access are implementations of client/server technology. The client application
resides on the PC and the server application resides on the AS/400. The philosophy behind client/server
technology is that certain tasks can be performed better on one computer platform than on another.
Tasks are distributed to the appropriate platform to achieve optimal performance, reliability, and
usability. For example, the AS/400 is an excellent database server, while the PC uses a Graphical User
Interface (GUI) to enhance the appeal and usability of applications. The AS/400 provides the data while
the PC is responsible for formatting and displaying the data. Client/server technology has become very
important in the world of computers as more users' terminals have been replaced by PCs on their desks.
Users depend on PC applications as well as on AS/400 applications to do their jobs.
As you become familiar with PC Support or Client Access, you'll find different variations on how to
install and use the software. The following sections describe the different versions, present an
installation overview, and discuss how the features of each product are commonly used.
Client Versions
Like many software applications, PC Support and Client Access have different options that can be
installed. Each install option has different hardware and software requirements.
The DOS option provides the basic connectivity and communications features using a terminate-and-
stay-resident (TSR) program under theMS-DOS conventional memory structure. Under this
conventional memory structure, only 640K of the computer's memory is used to run programs. The DOS
option has the fewest hardware requirements and runs on most PCs. The DOS option, however, does not
take advantage of any extended memory that most of today's PCs have - nor does it offer a graphical
user interface.
With the Extended DOS option, part of the application is loaded in extended memory, saving valuable
conventional PC memory for other applications. Extended memory uses memory in the PC over the
640K boundary. With PC Support, the Extended DOS option provides features to run PC Support under
Microsoft Windows.
Client Access provides a DOS and an Extended DOS option as well, but Client Access also has a Client
Access/400 for Windows option that allows it to be installed and operate within the Windows
environment. The Client Access implementation is enhanced to provide better Windows operability than
PC Support's implementation with Windows.
At the time of this writing, IBM recently released Client Access for Windows 95. The Client Access/400
for Windows version mentioned above does not work with Windows 95. And though we do not discuss
it in this text, IBM provides a version for OS/2 as well.
Install Overview
Because PC Support and Client Access are client/server applications, there is an install process for the
AS/400 and for each PC. Before the software is installed, the PC must be able to communicate with the
AS/400 through some type of physical connection. The PC can be connected to the AS/400 directly with
a twinaxial emulation card wired to the AS/400's workstation controller. The PC also can be connected
to the AS/400 via a local areanetwork (LAN), where the PC has a network card and network access, and
the LAN provides the access to the AS/400. For remote communications, the software can be configured
to work over modems.
On the AS/400, the server portion is usually loaded when you initially install the operating system or
when you upgrade from a previous version. If the AS/400 operating system is upgraded to Version 3,
Client Access replaces PC Support during the upgrade process. To view the version currently on the
AS/400, follow these steps:
As shown in Figure 9.1, the Display Installed Licensed Programs screen displays the licensed program
number, the description, and the current version. Use this information to verify that the version of the
client application being installed on the PC is compatible with the version of the server application on
the AS/400.
If PC Support or Client Access needs to be installed on the AS/400, select option 11, "Install Licensed
Programs," from the Work with Licensed Programs menu.
Once the licensed program is installed on the AS/400, you can perform many tasks from the PC Support
Task menu and Client Access Task menu, including enrolling users in PC Support and Client Access.
You must have Security Officer authority to enroll users. To display the task menu,
Before installing the client software, you should be familiar with the DOS operating system and
Microsoft Windows if you are installing any of the Windows options. You also should have read
through the install guide that is available with PC Support and Client Access. Both products offer
several install options that affect how the products work and appear to the user. The additional reference
section at the end of this chapter lists the IBM books on CD that explain each option and the related
requirements for installation.
The install process for PC Support and Client Access require that the PC has enough random-access
memory (RAM) and hard disk space to accommodate the options you select. As a general guide, the
DOS version requires a PC with 640K of RAM and a single diskette drive. The Extended DOS version
requires a PC with 1 MB of RAM, a hard drive, and a single diskette drive. The Windows version
requires a PC using Windows 3.x, 1 MB of RAM, a hard drive, and a single diskette drive. With
Windows, the more memory and hard drive space you have the better an application will run.
PC Support and Client Access provide install programs that guide you through the process. Depending
on the type of connection to the AS/400, you may need to know the name of the AS/400, a workstation
address, the connection type, or a TCP/IP address. Be aware that the install process may modify your
AUTOEXEC.BAT and CONFIG.SYS files, so it is important that you create a backup of these files
before you begin the install.
PC Support can be installed from diskettes; Client Access can be installed from diskettes or compact
disk (CD). To begin the installation process using DOS, load the first diskette and, from a PC prompt,
Type <drive>:INSTALL
During the install process, you will indicate where the software is installed, the type of connection to the
AS/400, and start-up options. For most installs, the application is copied to a directory named PCS or
CAWIN on the hard drive of the PC. A start-up batch file named STARTPCS.BAT is created that
contains start-up commands and start-up options that were selected during the install process. A
configuration file named CONFIG.PCS is also created that contains configuration and connection
information. If you install either PC Support with the Microsoft Windows feature or Client Access for
Windows, group windows are created with icons by which you can access the various programs.
Starting PC Support
You usually run the batch file STARTPCS.BAT to start PC Support. You can place STARTPCS.BAT in
the AUTOEXEC.BAT file, so that STARTPCS.BAT starts when the PC is powered on. STARTPCS.
BAT contains calls to other PC Support programs. Most importantly, STARTPCS.BAT calls the
programs that load the adapter handler and the router. The adapter-handler program communicates with
the PC hardware device that handles the communications with the AS/400. Each adapter handler
program works with the specific hardware device. The adapter-handler program for a twinaxial card is
different from the adapter-handler program used for connecting through a LAN. The router handles the
receipt and transfer of the requests and data between the PC and the AS/400. It is the routers job to play
traffic cop and make sure requests and data are routed to the AS/400 or to other PC Support programs.
After the adapter handler and router are loaded, other options in STARTPCS.BAT are loaded. These
other options may include starting a terminal emulation session, starting a shared folder, or establishing
a virtual printer where the PC can print to an AS/400 printer. The options that load are initially set
during the installation process, but you can change them at any time by modifying the STARTPCS.BAT
file or by running the CFGPCS program.
Similarly to PC Support, the DOS versions of Client Access can be started with STARTPCS.BAT. With
Client Access for Windows, however, this is not necessary because the application runs through
Windows. With the icons provided within the Client Access group, you can click with a mouse on an
icon and start Client Access. The two icons that start Client Access are shown in Figure 9.2.
The Client Access Startup icon establishes the connection with the AS/400, and it can start other Client
Access options such as terminal emulation, shared folders, and virtual printers. The AS/400 Connection
icon only establishes the connection with the AS/400. If you use the AS/400 Connection icon, you must
start other features separately by selecting their icons.
Once PC Support or Client Access is connected to the AS/400, either through the adapter handler and
router under DOS or through the session connection icons under Windows, you can use other features of
the products. The DOS versions of Client Access appear similar to the DOS versions of PC Support.
When we explain features in the following sections, we show the sample screens as DOS or Windows
screens. Though the screens look different depending on whether you are using the DOS or Windows
version, the functionality of the features is the same.
We cover shared folders in detail in a later section, but it is important to note here that depending on
how PC Support and Client Access was installed, the program names mentioned may be located in the
PCS subdirectory on the PCs hard drive, or the programs may reside on the AS/400 in a shared folder.
The advantage of using a shared folder on the AS/400 is that it minimizes the amount of hard-drive
space that the products require on the PC. The disadvantage to shared folders is that accessing the
AS/400 is slower than accessing the PCs local hard drive, so you must consider the performance impact
when you use shared folders.
Using DOS, you can configure and perform many PC Support and Client Access features using the
PCSMENU program. As shown in Figure 9.3, the PCSMENU program provides easy access to many of
the applications features from a menu. You can also access the features by typing in the programs name
at a DOS prompt. For example, to transfer data from the AS/400 to the PC, you can either select
Transfer data from the menu or type in the command RTOPC at the DOS prompt.
With Windows, you access the features by clicking on icons in the group window. Figure 9.4 displays
the group window for Client Access.
Terminal emulation allows the PC to act as, or emulate, a terminal. The AS/400 communicates with
terminals using a data packet format called the 5250 Data Stream. The terminal emulation program
translates the data stream between the AS/400 and the PC.
Printer emulation allows a printer attached to the PC to emulate an AS/400 printer, which can provide an
inexpensive and convenient method for users to print reports close to their work area.
Under DOS, terminal and printer emulation are handled by the Work Station Function programs. The
Work Station Function programs create and save session information. A session can be a terminal
emulation session or a printer emulation session. The CFGPCS program is used to configure sessions.
The WSF program is used to start the sessions.
Under Windows, Client Access provides two emulation packages that can be installed: Personal
Communications/400 from IBM, and RUMBA/400 from Wall Data, Inc. Both solutions provide quick
and easy ways to define a terminal or printer session. The Personal Communications/400 package
appears as the Start/Configure Session icon in the Client Access/400 for Windows group window.
RUMBA/400 has its own group window with icons to define sessions. Figure 9.5 shows the AS/400
sign-on screen using Personal Communications/400. Emulation software usually provides features such
as custom screen and keyboard layout, macro maintenance, and copy/pastefeatures for use with other
Windows programs. (Macros are files that contain key strokes than can be played back at a later time.
Using macros can simplify repetitive keystroke tasks and reduce the risk of keying errors.) The toolbar
that displays below the menu options lets users access key features of the software simply by clicking on
an icon in the toolbar.
You can create a printer session by using the Communication-Configure option and selecting Printer as
the session type. Advanced features let you customize the type of printer and the printer characteristics
such as font, the drawer of a laser printer to pull the paper from, and message queue. When the printer
session is activated, the output queue and writer device are created on the AS/400. The session then
displays a window indicating the current status of the emulated printer, as shown in Figure 9.6. The
figure shows that the emulated printer is PC01P2, and that PC01P2 is on-line and ready to print.
Anybody on the AS/400 can send spooled files to PC01P2 and the spooled files will print on the printer
attached to the PC.
Shared Folders
Shared folders are AS/400 folders that are assigned as a PC directory so the PC can use the AS/400s
DASD just as the PC would use a hard drive. If you are using shared folders, files that need to be
accessed by multiple individuals can be maintained and shared on the AS/400. For example, an
accounting department can store its Microsoft Excel budget spreadsheets in an AS/400 folder named
BUDGET. Individuals in the accounting department can view, edit, and save the spreadsheets to the
BUDGET folder from their PCs. This process saves the tedious and error-prone task of sharing PC files
by copying the files to a floppy diskette and reloading the files on another computer.
Another use for shared folders is to archive PC files. PC files can be copied to a shared folder and then
saved using AS/400 backup hardware as part of a centralized backup plan. Continuing with our
accounting department example, if the department contained 20 PCs, backing up all the necessary files
on 20 individual PCs would be a labor-intensive job. Using shared folders, important documents can be
copied to the AS/400 folder from each PC; and as part of the nightly AS/400 backup, the folder is saved
with other important AS/400 objects.
From the AS/400, you maintain folders with the WRKFLR (Work with Folders) command. Figure 9.7
shows the Work with Folders screen. Documents are stored in folders. The documents can be AS/400
documents or PC files. The WRKFLR command allows you to create, remove, and work with the
documents within the folders. You can also create folders within other folders. Using our accounting
department again as an example, additional folders could be created within the BUDGET folder to keep
the budget files separated by fiscal year.
Before a PC can use an AS/400 folder as a shared folder, the folder must be assigned or connected to the
PC. As shown in Figure 9.8, multiple folders can be assigned to different drive letters, allowing the PC
to access several folders at once. Figure 9.8 shows that three drives letters I, J, and K have been
assigned to three AS/400 folders. From the same program, connected drives can be disconnected when
access to the folder is no longer needed.
Wherever a shared folder can be assigned, the program offers the option of browsing the AS/400 to view
the folders. The browse feature helps you find folders on the AS/400. The browse feature allows you to
select folders, view folders within folders, or view folders on a different AS/400. Figure 9.9 displays the
Browse Folder window when you are connecting shared folders from Client Access for Windows.
After the shared folder has been assigned or connected, PC applications are aware that the folders are
available to use. Figure 9.10 shows the Windows File Manager program. The drive icons indicate that
drives I, J, and K are available. The file listing displays the documents stored in the AS/400 folder
named IMAGE, which the PC is using as the K drive.
For DOS versions, folders are assigned and configured the same way as they are with the Windows
version. You use the STARTFLR command to start shared folders. You use the FSPC command to
assign and release the shared folders. In the following DOS batch file example, the commands start the
shared folders function, assign the folder IMAGES to the K drive, and copy files from the PCs hard
drive to the shared folder:
In summary, shared folders offer a simple and convenient way for PCs to use AS/400 DASD as a hard
drive. Shared folders facilitate users sharing files and provide a method for archiving PC files with an
automated and centralized process.
Data transfer, or file transfer, involves transferring files from the AS/400 to the PC, known as
downloading, or transferring files from the PC to the AS/400, known as uploading. To transfer files, a
transfer request is created that indicates where the file is coming from (the source), where the file is
going (the target), which records to transfer, and the source-file and target-file formats. Transfer requests
can be saved so they can be recalled to use again or to modify. The source-file format is how the data is
currently stored on the source computer. The target-file format is how the data will be stored once it is
transferred to the target platform. When the transfer takes place, the data is automatically converted from
EBCDIC to ASCII and vice versa, unless the transfer request specifically indicates not to convert to the
target computers character code set.
On the AS/400, file formats are straightforward; the files will fit one of the following structures:
A data file where each record is defined by multiple fields with varying data types and lengths.
An example would be an address book where each record is defined by fields for the name,
address, city, state, zip code, and phone number. This is the most common format on the AS/400.
A data file where each record has a fixed length but does not have any defining field structure.
This type of file is often used for text or is the result of copying spooled files.
On the PC, file formats are more complicated, because each vendors application has its own file format.
Microsoft Excel, for example, does not have the same file format as Borlands Paradox or Lotus Notes.
Fortunately, most of these applications export and import data using a format that the data-transfer
program can use. The common file formats used by the data transfer programs are
Comma Separated Variable (CSV) or BASIC Sequential. Such files place commas between each
field in the record and quote marks around character information. This format works well for
transfers where the record structure contains multiple fields. Many PC applications, including
Microsoft Excel and Lotus 1-2-3, import and export this file format. As an example, if the
AS/400 record structure contained a numeric field for item number, a character field for
description, a character field for image reference, and a salesperson ID, Figure 9.11 shows what
the CSV file would look like after it was transferred from the AS/400.
Text or DOS. These files are straight ASCII files without field delimiters. Records may be
appended with a carriage return and line-feed character. These file formats are best suited for
transferring source code, spooled file data, or word-processing text.
Binary Interchange File Format (BIFF) and Data Interchange Format (DIF). These files are
created from some spreadsheet and database applications. These file formats are best suited for
applications that do not import and export comma-separated files.
Many reasons exist for transferring files from the AS/400 to the PC. Data may need to go to another
company with a different type of computer that requires ASCII data. Or PC applications such as
Microsoft Excel may be used to import data and prepare graphical presentations and reports. If the
AS/400 is not equipped with fax or e-mail software, data may be transferred to the PC to accomplish
these tasks.
Likewise, there are many reasons for transferring files from the PC to the AS/400. Many vendors
provide information only in a PC format, so the data must be transferred and placed in an AS/400
database so applications can use the data. An example would be vendors who send their product
information on a PC disk in CSV format and that information is transferred to your AS/400s purchase-
order system.
When creating a transfer request from the AS/400 to the PC, you have several options for how the data
will be transferred. Figure 9.12 shows the two entry screens for creating a transfer request with Client
Access for DOS. With the DOS versions, the RTOPC command is used to work with AS/400-to-PC
transfers. With Windows, you access the file-transfer program by selecting the File Transfer icon, as
shown in Figure 9.4. The Windows version looks different but operates on the same principles.
The FROM entry in Figure 9.12 is the name of the AS/400 file that is transferred. The SELECT entry
indicates what fields from the AS/400 database file are transferred. An asterisk (*) indicates that all
fields are transferred. If you need only certain fields, enter the fields names, separated by a comma.
Pressing F4 with the cursor in the SELECT entry displays a list of fields from the file. You can select
fields from the list to build the SELECT entry. The WHERE entry indicates that records from the file are
conditionally selected for transfer. As Figure 9.12 shows, only records where the field ITMSP is equal to
2000 are transferred. The ORDER BY entry indicates the sort order of the transferred records. If the
entry is blank, records are transferred in the same order in which they are in the AS/400 file. If you need
a sort order, enter field names separated by a comma. Pressing F4 with the cursor in the ORDER BY
entry displays a list of fields from the file. If you are familiar with Structured Query Language (SQL),
the format of the FROM, SELECT, WHERE, and ORDER BY entries follows SQL syntax.
The option to save the transfer description saves the AS/400 file-selection information into a file-
definition file (FDF). The FDF can then be used by the program that transfers PC data to the AS/400
file. The FDF is different from the transfer-request file that is saved, and it is only used in the PC-to-
AS/400 transfer process.
After the transfer information is entered, press F5 to run the transfer. If all the entries are valid, the
records are transferred from the AS/400 file to the output device selected. If the output device is a file,
the records are transferred to the PC file named in the To . . . entry. You can save the transfer request to
a PC file and recall it later to run again or to modify the file. You also can use the transfer-request file in
a DOS batch file to automate the file-transfer process.
When you create a transfer request from the PC to the AS/400, the options are simpler than those for the
AS/400-to-PC transfer. Figure 9.13 shows the entry screen for creating a transfer request with Client
Access for DOS. With the DOS versions, you use the RFROMPC command to work with PC-to-AS/400
transfers. With Windows, you use the same File Transfer program that you use to request file transfer
from the AS/400 to the PC to transfer files from the PC to the AS/400. Again, you access the file-
transfer program by selecting the File Transfer icon (shown in Figure 9.4).
In Figure 9.13, the Use PC file description entry is the name of the file-definition file (FDF) saved with a
previous AS/400-to-PC transfer; this file indicates the format that the PC data should be in when it is
transferred to the AS/400. The information in the FDF file is compared to the record structure of the
AS/400 file to make sure they are compatible.
After you have entered the transfer information, press F5 to run the transfer. If all the entries are valid,
the records are transferred from the PC file to the AS/400 file. You can save the transfer request to a PC
file and recall it later to run again or to modify it. You can also use the transfer-request file in a DOS
batch file to automate the file-transfer process.
Other Features
Terminal and printer emulation, shared folders, and data transfer are common features used with PC
Support and Client Access, but they are not the only features of the products. PC Support and Client
Access offer several other features that some AS/400 shops use sparingly and some AS/400 shops
probably use every day.
Virtual Printer
For many years and its still the case in some companies printers were few and people had to share the
printer as a resource. If your company needs to share printer resources, the Virtual Printer feature of PC
Support and Client Access can help. PCs can use an AS/400 printer as if it were attached directly to the
PC via Virtual Printer Support. Because the AS/400 printer is not actually attached to the PC, it is called
a virtual printer. When the PC prints a report, the report is routed to the LPT port assigned to the virtual
printer. Virtual printers are best suited for text-based reports, where a company may want to take
advantage of the high speeds that some AS/400 printers offer.
The Submit Remote Command feature allows a PC to send a command to the AS/400 without using a
terminal emulation session. The command is sent as a valid AS/400 command line, such as CALL PGM
(QGPL/PROCA). This feature lends itself well to creating AS/400 objects or calling processing
programs. For example, after a file transfer, you can use the Submit Remote command to call the
AS/400 program that processes the transferred data into another AS/400 database and prints a report.
Data Queues
Data queues are AS/400 objects that are often used for program-to-program communications. One
program can be on the AS/400 while the other program is on the PC. Data queues are similar to AS/400
physical files, in the respect that they have a defined length and contain entries similar to records.
Entries can be placed on the data queue, retrieved from the data queue, and removed from the data queue
by programs on the AS/400 or by using PC Support and Client Access commands.
Open Database Connectivity (ODBC) is a programming interface designed for Microsoft Windows that
allows applications to work with a database regardless of where the database is or what type of database
it is. With ODBC, for example, Microsoft Excel could open a database called MYDB and work with the
records regardless of whether MYDB is an AS/400 database, a PC database, an Oracle database, or some
other database. Client Access provides an ODBC driver for accessing AS/400 databases. The application
on the PC must be able to work with the ODBC specifications for you to use the feature.
Client/Server Programming
Situations exist where the supplied programs you have arent quite enough. In these cases, PC Support
and Client Access allow you to develop your own client/server applications. Both versions supply you
with documentation and samples showing how to write a program using the programs internally called
functions, called Application Program Interfaces (APIs). You can use PC programming languages such
as BASIC, C, and Pascal to develop client applications. You might develop an application in Microsoft
Visual Basic that prompts the user for an item number and then uses the Client Access file-transfer APIs
to retrieve the items sales history and load the history into Microsoft Word.
The following table lists the books found on IBMs Softcopy Library CD, which is distributed with the
AS/400s operating system. The books listed below focus on setup and on using the basic features. Other
books also are available on CD to help with advanced topics such as Client/Server programming.
Book on CD Description
Key Terms
Review Questions
1. The PC Support/400 and Client Access for OS/400 products provide what features for the
AS/400 user?
2. Why is it important to create a backup of a PCs AUTOEXEC.BAT and CONFIG.SYS files
before installing PC Support or Client Access for DOS on a PC?
3. What is the name of the batch file that starts PC Support for DOS ?
4. What is the adapter handlers function?
5. What is the advantage and disadvantage to using the Shared Folders function on the AS/400?
6. What reasons exist for transferring files from the AS/400 to a PC?
7. What is a PC file description in reference to the transfer function?
Exercises
1. Using the Windows File Manager, browse the folders available on your AS/400.
2. Transfer a file specified by and supplied from your instructor to a diskette on your PC.
Chapter 10
Accessing the AS/400 Database
Objectives
To be able to
Overview
A companys business information must be handled efficiently, and employees must have access to up-to-
date information. Database management system software frequently provides the most effective way to
manage data files and the relationships between them.
The AS/400 is shipped with a database management system named DB2/400 as an integrated part of the
OS/400 operating system. A database integrated into the operating system provides a consistent user
interface, consistent security access, and more efficient system management. For example, a security
officer can use the same CL security commands to maintain the database objects as (s)he uses for other
AS/400 objects.
As system operator, you may be responsible for keeping an inventory of purchased and used hardware.
Creating a database for reference and reports would be helpful for tracking such equipment. In this
chapter, we will supply an example of the procedures required to create and access an inventory file
such as you might use for equipment tracking. You can describe and create DB2/400 files in various
ways on the AS/400. You can use an AS/400 licensed program such as SQL, COBOL, or RPG. You can
use the Interactive Data Definition Utility (IDDU) to create database file descriptions, but IDDU is
limited to describing only physical files. OS/400s data description specifications (DDS) provides a way
to externally define physical and logical files. You must create a DDS source member using a source
editor and then compile the program to create the *FILE object.
This chapter will give you the information you need to create and access DB2/400 files using the utilities
provided with OS/400. In this chapter, you will use the Source Entry Utility (SEU) to enter DDS and
create source members. You will use the Program Development Manager (PDM) to work with and
manipulate the source members to compile and thus create objects. With the Data File Utility (DFU),
you can quickly (but possibly without audit trails) create, update, or delete data within the physical file
object. Then you will be able to create reports using Query for OS/400. This sequence will give you an
overview of how to create a database, enter data into the object, and then create printed reports from the
data.
The first step in creating a database is to access the appropriate tools to make this a simple task. The
operating system supplies the Program Development Manager (PDM) to work with objects and
members. The PDM screens represent a user-friendly interface, including lists of objects, and members
with options to process these objects.
The objects that exist in your library will be listed on this screen, shown in Figure 10.1. Source members
must be created within a source type file with a PF-SRC attribute.
The Work with Members Using PDM display (Figure 10.2) is where you can see a list of all source files
and work with them. You can edit, delete, display, print, and rename files (among other options) from
this screen.
SEU is the editor OS/400 provides for creating source members. SEU is a full-screen editor that
provides prompts for an easy user interface. SEU is a programming editor, not a word processor; so
word wrap is not available with SEU. When entry errors are made, the SEU syntax checker will
highlight the line with the error.
To access the Start Source Entry Utility (STRSEU) screen, shown in Figure 10.3,
Now lets work through an example in which you will enter DDS in SEU to create a physical data file
specification. The Source file parameter in Figure 10.3 represents the file that will contain the members
you create in the SEU session. The Source file Library parameter is the library that contains the source
file. This Source member is the name of the member you are creating with the source entry utility. The
*PRV default represents the previous member you have worked with using SEU; this provides a quick
way to return to previous SEU sessions. The Source type entered will determine the prompt available for
use within the SEU session. On the Start Source Entry Utility (STRSEU) screen,
When the SEU Edit Screen first appears (Figure 10.4), the End-of-data line will be located at the bottom
of the screen. This display is useful for advanced users and for making corrections. Your library name
and source file name will be displayed in the upper right-hand corner. The cursor is located in the right-
hand corner of your display screen. Pressing the Enter key will position the cursor at the beginning of
the source code entry and compress the blank lines.
For experienced SEU users, free-form entry is available. The type of source code being created will
determine the acceptable position or column location in which code can be entered. The prompt utility
provides the user with easy-to-use, fill-in entries with headings, and it places the values in the proper
position. The SEU command line (located near the top of the display) offers access to SEU commands,
including SAVE, CANCEL, and CHANGE.
HINT:
Press the Help key for instructions for SEU display commands and tools.
Figure 10.5 represents the SEU Edit screen with blank lines deleted. You will use this screen as you
work through the steps required to create files with DDS.
On the above screen, the cursor should be located in the bottom half of the screen, in the Name Type
field. You should use the Field exit key to move to the next field. If you make a mistake, move back to
the previous field by holding down the Shift key and pressing the Tab key. When all entries for the
record are correct, use the Enter key to complete the entry. For our example,
Press Enter
For a data description specification, the first line entry always specifies the name of the record being
described. The R in the Name Type parameter identifies this as a record format statement. In our
example, the name of the record is INVTRYR. Enter the records field descriptions as shown in the
following steps:
The field PRODID is defined above as a six-character-long alphabetic field with the column heading of
PRODUCT ID.
Using the following information, continue to enter the field descriptions for INVTRY. Remember that
the first two lines have already been completed.
You can use the FILE SEU command at any time within your SEU session to save the DDS description
and then return to editing.
Option 14 on the Work with Members Using PDM screen lets you compile a source member. When the
source members compilation is complete, the operating system will send a message related to the
success or failure of the compile. From the Work with Members Using PDM screen,
The compilation message will inform you that the compile completed normally or abnormally. During
compilation, the operating system sends a spooled file related to the compile to the output queue. This
spooled file is valuable for correcting errors in the source code.
If there are errors noted in the compilation listing, return to the WRKMBRPDM display and use option
2 to edit the member. If you prefer CL commands, type STRSEU on any command line and press Enter.
To return to the previous source member edit session, leave the default *PRV and press Enter.
Logical Files
Unlike a physical file, a logical file does not contain data. A logical file provides an alternate access path
to records stored in a physical file, perhaps by sorting the records differently or by including only
selected data records. This alternative can be extremely helpful because it is very difficult to modify
physical files once data has been included in the object. For our example, lets choose to access our
physical file by department number, so we will create a logical view for our physical inventory file,
INVTRY, with the department number as the key.
We will also use SEU to create the logical file member for the physical file, as shown in Figure 10.6. To
access this screen,
At this point,
The Functions parameter is used here to make the connection between the physical file and the logical
file.
Continue to enter the field descriptions for the INVTRYR record in the logical description, as follows:
Type Name
R INVTRYR PFILE(INVTRY)
PRODID
DEPTNO
SNUM
DESC
K DEPTNO
You do not need to enter the field length, data type, and functions again, because these attributes will be
accessed and retrieved from the physical file.
Type FILE on the SEU command line to save the source member
Press F3 to exit the SEU Edit screen
Type 14 in the option column for member INVTRYL1
Press Enter
Type DSPMSG on a command line to determine whether compilation was
successful
Press Enter
Press F12 to exit the Display Message screen
Type WRKSPLF on the command line to view the spooled file
Press Enter
Type 5 to display the spooled output file created during
compilation
Press Enter
HINT:
If there are errors noted in the compilation listing, return to the WRKMBRPDM display and use
option 2 to edit.
You can use the Data File Utility (DFU) to add, update, or delete physical file records. Most installations
purchase or create their own custom programs to update data files. These systems provide adequate
protection via audit trail reports to reduce unauthorized data modification, and this method is preferred.
At times, however, this approach is not feasible because of time constraints. For our example, DFU
provides a quick method for creating update entry programs to enter actual data into the INVTRY file.
To start DFU,
Type STRDFU
Press Enter
Type 2 to Create a DFU program
Press Enter
To customize a DFU program, you can use either the Create a DFU Program screen (Figure 10.8) or the
Create a Temporary DFU Program screen. The second option requires no programming, but it provides
only the default specifications.
The Create a DFU Program screen prompts you for the name of the program to be created and the data
file that will be used by the program. The default for the Library parameter should be your current
library, *CURLIB.
HINT:
Press F4 (Prompt) to select the data file for your DFU Program.
In the example, the logical file INVTRYL1 will be used, allowing access to the file in departmental
order.
For our purposes, we will name the DFU program INVNTPR. Therefore, all programs relating to the
INVTRY file will have the same initial characters and can easily be identified as part of the inventory
system.
The Define General Information/Indexed File screen, as shown in Figure 10.9, allows you as the
operator to control the general characteristics of the program. You should assign a job title that the
program can recognize later. The Display format parameter offers you four choices of display formats.
Select 4 to be row oriented.
This screen offers other customization options. For users accustomed to the System/36 environment, the
S/36 style parameter is available. Additionally, you can edit numeric fields for format, and updates can
be disallowed.
On this screen,
HINT:
Press the F14 key for further display definition or the Help key for information about the display
as a whole.
The Audit report parameter specifies whether an audit report should be spooled. You should specify a Y
for this value. A new screen will appear for further definition of the Audit report.
This will take you to the Define Audit Control screen. The Define Audit Control screen, shown in Figure
10.10, provides you with control over what type of updates will be included within the audit report.
Always print additions, changes, and deletions to attempt to prevent unauthorized modifications. The
printer options are available so you can define the paper size being used for the audit report.
The next screen you see, the Work with Record Formats screen, lists the record formats in the file
specification. If a file specification has more than one record format, all formats will be listed. In our
example, one record format, INVTRYR, should be listed, as shown in Figure 10.11.
You use the Specify option to select the record format. The Multiple Records specification allows
multiple records to be entered on one screen.
You can customize data entry using the Select and Sequence Fields screen shown in Figure 10.12 to
allow control over what fields can be viewed or accessed for update and in what order the fields will be
displayed on the Update Entry screen.
You select and sequence fields by typing the preferred sequence in the Sequence column option field.
The Work with Fields screen, as shown in Figure 10.13, will appear with your selected fields displayed
in the new order.
You can access the Extended Field Definitions screen from this display using option 2. Extended field
definitions may not be available if they were previously assigned within this display screen. Pressing the
F21 key would specify that all fields can be designated for extended field definitions, thus leading you to
an additional screen for each field. If extended definitions are not defined, the validation keywords from
the DDS file description are assumed. To exit the Extended Field Definition display,
Press Enter
The Exit DFU Program Definition screen lets you save, run, or save and then run, a newly defined DFU
program. As shown in Figure 10.14, the INVNTPR program will be saved and the records can be added
to the INVTRY physical file, via the INVTRYL1 logical file.
The F17=Fast path function key provides a direct way to execute the program. We will not cover other
displays or optional screens in this discussion. To execute the program automatically,
You can enter multiple records on the Inventory Maintenance screen (this is the next screen you see), as
shown in Figure 10.15 (the Multiple Records parameter was specified as Yes on the Work with Record
Formats display).
The standard function keys are available on the Inventory Maintenance screen. You use the Field exit
key to move from field to field.
Add the following six records to the record format on this screen:
The End Data Entry screen will be displayed, revealing the number of records that have been added,
changed, or deleted.
The audit report will be spooled when the DFU session is ended. In these examples, we created a
physical and logical file with DDS, and the data was entered into the physical file with a newly created
DFU program.
As we mentioned at the beginning of this chapter, keeping track of inventory in a large company is
sometimes difficult. Knowing what equipment was distributed to what department would be helpful.
Query for OS/400 is an IBM licensed program that provides an easy method for creating reports by
selecting and filtering data to provide useful information. Data does not become information until it is
produced in an organized way to be useful to people. We will provide information here about building a
basic Query report using either a physical file or a logical file. For more information about Query
utilities, see IBMs Query/400 Users Guide.
The Work with Queries screen prompts the user for choices related to working with queries. From this
screen a user can create a new query, run an existing query, or copy, delete, display, change, or print the
definition of an existing query. A user can name the query definition within the Work with Queries
display or later when (s)he is exiting from the Query utility.
On this screen,
You will see on the Define the Query screen, as Figure 10.17 indicates, that you can define and
customize a Query report in many ways; the only required option for a Query report is to Specify file
selections.
This will take you to the Specify File Selections Screen, shown in Figure 10.18.
On this screen, you must specify the File name parameter either by typing the file name or by prompting
to view available files.
In this example, the physical file description is used to run the Query report; but the logical files name
could have been entered in the same way. A greater-than sign ( > ) will be visible next to the Specify file
selection option, to inform you that a file selection has been completed. You could run the report by
pressing F5; but if you do, the listing will be in record order.
To specify a sorted listing from the Define the Query screen, use the Select sort fields option on the
Define the Query screen (Figure 10.17).
Type 1 in the Select sort fields option column on the Define the Query
screen
Press Enter
This will take you to the Select Sort Fields screen, shown in Figure 10.19.
The fields included here are from the DDS for physical file INVTRY. TheSort Priority column defines
how the database should be sorted. In this example, we wish to list our report with Department Number
in ascending order, and Product ID in ascending order, to show what items are located in each
department. To do this,
The query has now been defined using the physical file named INVTRY, and it will list the records in
alphabetical order by product within ascending order by department number, as shown in Figure 10.20.
To generate the Query report,
Summary
Many methods exist to access DB2/400 files created on the AS/400. This chapter has stepped you
through the process for creating a DB2/400 file and for printing a Query report. We used DFU to enter
data. Following is a summary of the process we have used in this chapter to ultimately generate a
spooled output report:
Key Terms
Review Questions
1. What is DB2/400?
2. How does the AS/400 use DB2/400?
3. What do the initials SEU stand for? What function does SEU perform?
4. Why does SEU create a member within a source file?
5. Why does the member need to be compiled?
6. What do the initials DFU stand for? What function does DFU perform?
7. How can DFU be customized? How can a user access the default DFU program?
8. Using DFU, how would a user enter data?
9. What is the function of Query for OS/400?
10. How can Query for OS/400 use a logical file?
Exercises
1. Change the Query report to use the logical file. Run the report.
2. Change the Query report sort sequence to sort by description. Run the report.
3. Add the following records using DFU:
4. Create a new logical file to key the report by serial number. Name the logical file INVTRYL2.
5. Print the report using the logical file INVTRYL2.
Table of Contents
Appendix A
Commonly Used Commands
This appendix contains a summary of commands that the novice operator may be asked to use. We have
found these generally helpful, and they may be the solution to problems that initially are not obvious.
Frequently, the commands require Security Officer or System Administrator authority.
User-Related Activities
To delete all objects from a library, use the CLRLIB (Clear Library) command. This command does not
delete the library itself. If no current library exists or no current library is specified, then the library list
in QGPL will be cleared. Therefore, we suggest that you always enter the library name when you use
this command. These options require Security Officer or System Administrator authority.
Type CLRLIB
Press F4 to prompt
Enter library name
To change an individuals object authority, use the following commands: EDTOBJAUT (Edit Object
Authority), GRTOBJAUT (Grant Object Authority), or RVKOBJAUT (Revoke Object Authority).
Activity: To change a password that has been forgotten or doesnt work any longer because it has
expired.
Type CHGUSRPRF
Press Enter
Type the User ID
Press Enter
Change the Password parameter to the same as the User ID
Change the Set password to expired parameter to *YES
Press Enter
Sign on with the password that is now the same as his or her User ID
Type CHGPWD
Press Enter
Follow instructions on the Change Password screen
To print a data file without having to do a screen dump, use the CPYF (Copy File) command. The
spooled file will be placed in the output queue to which you are signed on.
Type CPYF
Press F4 to prompt
Enter name of file to print (such as the from file)
Enter *PRINT for the to file entry
Press Enter
Programmer-Related Activities
To look for backup objects from compiled programs, use the WORKOBJOWN (Work with Object
Owner) command. Any users, but generally programmers, might receive an error message indicating
that they have exceeded the maximum storage for their user profiles. Each time a source member is
compiled, a new object is created in the current library and in a library called QRPLOBJ. The system
assigns the backup object a name that starts with a Q and ends with a number. To display the Q... object,
execute the following command:
Press Enter
Look through the objects on the display. If this particular area has multiple Q... files, the backup objects
could be causing the message. You can delete these objects without concern. System Administrator or
Security Officer authority is required.
To delete all backup objects from the QRPLOBJ library (generally created from source member
compiles), use the CLRLIB (Clear Library) command. Use this command to delete all the Q... files.
These options require Security Officer or System Administrator authority.
The user must then sign off and then sign back on.
A program generally loops during the development stage. If a program is looping, the Input Inhibit
indicator stays lit on the workstation and the keyboard is locked. To end the program, the request to the
system must be ended. Ensure that the programmer is notified of the program name and that the program
was ended.
Press Enter
Choose Option 2 to End the previous request
If there is no version number listed in the right-hand column of the Installed Licensed Programs screen,
then the licensed program has not yet been loaded.
After you move a device from one location to another, the device must be re-addressed. No two devices
can have the same address at any time, whether the devices are varied on or off. As operator, you must
assign a non-existent address to the old device, possibly the matching port number with a switch setting
of 99. Next, change the new device to the appropriate port and switch settings.
Then change the Port and switch settings for the old device:
Repeat the previous steps to change the port and switch setting for the new device. Then vary on the new
device.
Activity: To test whether the modem is working before you use ECS for the Electronic Customer
Support.
The AS/400 stores pieces of information concerning printing in five different objects. The system will
move through the list until it has gathered enough information to print a given report. The following list
shows the location and the order the AS/400 uses to find the information for printing output:
Some values for devices and output queues can cause this sequence to change. IBMs Guide to
Programming for Printing (SC41-37133) has more specific information about these exceptions. The
following table represents a summary of the information.
To change the Printer Device Change the DEV (Device) parameter value on the CHGPRTF (Change
File Printer File) command or on the OVRPRTF (Override Printer File)
command.
To change the Job Change the PRTDEV (Print device) and OUTQ (Output Queue)
Description parameters on the CHGJOBD (Change Job Description) command.
To change the Work Station Use the WRKDEVD (Work with Device Description) command; use
Description option 2 (Change) for the device to change. Then change the PRTDEV
(Print Device) and OUTQ (Output Queue) fields.
To change the User Profile Use the PRTDEV (Print Device) and OUTQ (Output Queue)
parameters on the CHGUSRPRF (Change User Profile) command.
To change the Default Printer To change the default printer for the entire system, use the Default
system printer field on the Change System Options display. To find
this display, type GO SETUP on any command line and press the Enter
key. Then select option 1 (Change system options).
The option to power off the system from the console can only be used if at least 40 minutes are available
to complete the power down.
Type GO POWER
Press Enter
Select Option 3 to Power off immediately
You can answer most of the screens that will appear after sign-on by pressing the Enter key.
Table of Contents
Table of Contents
Appendix B
System Hardware Documentation Forms
As we discussed in Chapter 6, it is important to document your system hardware before you add new
devices to the AS/400. To help you do this, we have included the following sample forms from the
AS/400 Device Configuration Guide:
Form C1 Local Work Station Diagram (Twinaxial Cabling). Use to document your addresses
and other information needed to configure displays, printers, and other devices.
Form E1 9406 Tape Controller and Tape Unit Diagram. Use to document your tape and tape
controller information.
Form E2 9406 Diskette Unit Diagram; Form E3 9402 and 9404 Tape Unit and Diskette Unit
Diagram. Use to document your diskette and diskette controller information.
Table of Contents