AS/400 Work Management: Basic Concepts
OK, your AS/400 is up and running. Your software vendor has completed a week of configuration and training and is now sitting on a plane half-way back to Cleveland enjoying his third Martini. You sit back and relax knowing you have the world's most reliable computer running the world's most reliable software.
Wonderful, you say, until the telephone starts ringing… Where is my report? I can't log in. The system is slow. Chicago is down. Are the Day-End jobs STILL running? My downloads are not are on the server…
The AS/400 may be the world's most reliable computer scalabilite. However this machine does require a bit of 'care and feeding'.
Some issues can be traced to human error such as poor coding techniques or poorly trained users. Jobs may compete for files and lock up, users will re-boot their PCs lock themselves out of an application. Others are mechanical problems like jamming printers or resources that mysteriously vary themselves off.
Objectives of this Document
This guide is designed to give you basic understanding of AS/400 work management concepts.
Note that this discussion contains many useful, but equally dangerous commands. As you are likely working on a live production system without adequate security to prevent you from messing up, please remember that any modifications or deletions of objects may jeopardize system integrity or performance. Consult multiple references, your security officer or systems administrator before you get too creative. Remember, when you are starting out you rarely get more than one opportunity to screw up per job.
Note that IBM may or may not have re-named the AS/400 to the IBM iSeries, but I will continue to call it the AS/400 until such time that the name is used in places other than IBM sales brochures and press releases.
What is Work Management?
Our discussion of Work Management has nothing to do with DayTimers or staying in the office to 6PM every night.
Work Management in the AS/400 context refers to the functions that control the AS/400's workload and distribute resources among all its jobs. Work management defines a job's environment: where it enters the system, what resources it uses for processing, and where its output goes.
Because IBM ships all AS/400 systems with everything necessary to run typical operations, it is not essential to master this subject. This may be why it is often over-looked and under emphasized in many companies. However if you understand work management, you know what affects the various pieces of the system, and how to change them so they operate more efficiently.
AS/400 CommandsThe AS/400 native command language is called CL (Command Language). Like DOS and Unix batch files, most CL commands can be run at the command line or strung together in a batch file. Unlike DOS, batch files on the AS/400 are compiled.
What does the AS/400 Command line look like? Here is one below:
===>___________________________________________________________
F3=Exit F4=Prompt F5=Refresh F12=Cancel F24=More keys
The AS/400 has a very rich vocabulary of commands covering a diversity of tasks including file management, backup, scheduling, security, printing, communications, device configuration and much more. One of the reasons that the AS/400 is popular with management is that it does not require many add-on or third party packages to perform basic operating systems functions. Most of the tools you need are included with the operating system.
In general, AS/400 commands are more consistently constructed compared with other operating systems. AS/400 commands are generally composed of at least a verb and a subject portion.
o Examples of verb segments:
WRK (work with), CRT (create), DLT (delete), CHG (change), DSP (display)
o Example of subject segments:
PGM (program), LIB (Library), OBJ (Object), JOB (Job)
Often you can combine the verbs and nouns and simply guess the commands out of thin air. for example CRTLIB or DLTLIB.
If you have not already used it, try the AS/400 menu Command GO MAJOR. GO MAJOR is an on-line index of most AS/400 commands. (Pushing F4 at the command line will get you there as well.) The commands are indexed in several handy ways including by verb and by subject.
-----------------------------------------------------------------
MAJOR Major Command Groups System: SYS23
Select one of the following:1. Select Command by Name SLTCMD
2. Verb Commands VERB
3. Subject Commands SUBJECT
4. Object Management Commands CMDOBJMGT
5. File Commands CMDFILE
6. Save and Restore Commands CMDSAVRST
7. Work Management Commands CMDWRKMGT
8. Data Management Commands CMDDTAMGT
9. Security Commands CMDSEC
10. Print Commands CMDPRT
11. Spooling Commands CMDSPL
12. System Control Commands CMDSYSCTL
13. Program Commands CMDPGM
More...
Selection or command
===>___________________________________________________________
F3=Exit F4=Prompt F9=Retrieve F12=Cancel F13=Information Assistant
F16=AS/400 Main menu
When unsure of a command, type the first few characters followed by the wild card star. This will give you all commands that begin with the prefix specified. For example DSP* will prompt the operating system to enumerate all commands that begin with DSP such DSPSBSD and DSPOBJD.
On CL commands (and elsewhere), the F4 key is the prompt key. It shows a screen that prompts you for all the possible parameters you might want to enter for a command. Example: Type 'SBMJOB' and then hit F4. The system will prompt you for values. Some fields are blank and you must fill them in, others are filled in with default values for you. Note that for many commands, the F10 key will give you additional (and more obscure) option(s).
Here is the CPYF (copy file command) before and after pushing F4:
Before
Selection or command
===> CPYF FROMFILE(MYLIB/MYFILE) TOFILE(YOURLIB/YOURFILE)
After:
Copy File (CPYF)
Type choices, press Enter.
From file . . . . . . . . . . .> MYFILE Name
Library . . . . . . . . . . . > MYLIB Name, *LIBL, *CURLIB
To file . . . . . . . . . . . .> YOURFILE Name, *PRINT
Library . . . . . . . . . . . > YOURLIB Name, *LIBL, *CURLIB
From member . . . . . . . . . . *FIRST Name, generic*, *FIRST, *ALL
To member or label . . . . . . . *FIRST Name, *FIRST, *FROMMBR
Replace or add records . . . . . *NONE *NONE, *ADD, *REPLACE...
Create file . . . . . . . . . . *NO *NO, *YES
Print format . . . . . . . . . . *CHAR *CHAR, *HEX
Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keysThe F1 is context sensitive help which is often helpful. Pushing F1 two times will give you the "How to Use Help" screen which contains some explanation on commonly used function keys.
The AS/400 Input-Processing-Output Model
On the AS/400, the classic data processing Hierarchical "Input-Processing-Output" model usually looks something like this -
JOBQ >>>> SBS >>>> OUTQ
where the Job Queue (JOBQ) receives the work, the Subsystem (SBS) processes the work and delivers the results to the specified Output Queue (OUTQ).
The Object
On the AS/400 everything worth talking about is an object. This is not 'object' in the object-oriented sense of the word. DOS-folks can replace the word object with the word file or thing if it makes you more comfortable. (You will notice that AS/400 people will go on and on about their objects.)
For instance, if you want to see all the objects in libary QSYS, type
WRKOBJ OBJ(QSYS/*ALL)
An object is made up of a set of attributes that describe the object and some form of data. The attributes of an object include its name, type, size, the date it was created, a short description, and the name of the library in which it is stored.
There are dozens of objects types on the AS/400 including commands, controllers, data areas, device descriptions, files, line descriptions, menus, output queues, programs and user profiles.
On the AS/400 objects are categorized by type, which allow the user to specify what type of objects are required for a given task. There are OS/400 objects and MI system objects. Some AS/400 objects map one to one with MI system objects, but other have a one to many mapping. This is because some AS/400 objects need to map to multiple MI system objects. All AS/400 objects map to at least one MI system object. The 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.
The Library
All AS/400 objects are organized into libraries. Each object must belong to a library (Even a library belongs to a library!). An object can belong to only one library. AS/400 libraries are organized as a single-level hierarchies, unlike the directory structure found on PCs which may have multilevel hierarchies.
DOS files, such as the example below, may be referenced within a multilevel hierarchy illustrated with directories, and subdirectories.
c:\mydirectory\mysubdirectory\mysubsubdirectory\mydata.dat
On the AS/400 a file object would be stored and referenced within a single hierarchical level.
To identify an AS/400 system object you need the name both the library the object. The AS/400 identifies objects by their qualified name, which takes the form of LIBRARY/OBJECT. For example, to accurately the object VENDOR in the library APLIB you would reference this as APLIB/VENDOR. Two or more objects can have the same name but they must be different types of objects. For example you could have a program named TEST and a data space named TEST, but not two programs named TEST in a single library. An object can exist in only one library.
AS/400 libraries and file names are limited to 10 characters. Due to limitations RPGII and RPGIII, many system use only 7 or 8 character file names.
The AS/400 comes with several default libraries. Default libraries (and all default IBM object begin with the letter "Q"). The QSYS library contains the base operating system components, as well as other libraries. It is special in that it is the only library that can contain other libraries.
The Library List
The Library List is similar to the concept of Path in UNIX or DOS. The Library List is the list of libraries within scope at any given time.
If an object is in the Library List, them the object can be referenced with a relative reference. Example:
CALL MYPGM
If an object is not in the Library List it has to be referenced with an absolute reference that explicitly identifies the library. Example:
CALL BAKUPLIB/MYPGM
You are permitted 25 libraries in the User Portion of the library list. These can be changed with commands
EDTLIBL Edit library list
ADDLIBLE NEWLIB Add a new library called NEWLIB to the library List
CHGLIBL Change the whole library list
CHGSYSLIBL Change System Library List
DSPLIBL Display Library List
EDTLIBL Edit Library List
RMVLIBLE Remove Library List Entry
The File, Record and Member
On the AS/400, data is arranged into files. The AS/400 has many different types of files. These include Physical files, logical file (indexes), printer files, save files.
To see some of the files on your system:
WRKOBJ OBJ(*ALL) OBJTYPE(*FILE)
Physical File
In a data processing environment the most important file is the physical file. The physical file is a database file that actually contains data records. A physical file actually has two parts. The first part contains the file attributes and field descriptions. The file attributes include the file’s name, owner, size, number of records in the file, key fields, and other attributes. The field descriptions hold the attributes for each field in the record. The second part of a physical file contains the data.
Physical File Members
The data records are grouped into physical file members. A physical file may have zero, one or multiple members. Each member within a file would have identical structure, but may contain different data. New members may be created to isolate data or limit the growth of large file members. Typically a business application might have created a new member for each month of sales or for each corporate division. In the past, the use of multiple membered files could be justified by concerns of CPU and disk speed. Today with good indexing practices on AS/400 recent models, speed concerns should not be an excuse for using multi-membered files. Furthermore, multiple membered files does not fit in well with relational database theory and SQL/ODBC environments. Most application vendors have converted their multiple membered files to single-membered files.
Normally, physical files have only one member which, by default, is added to the file when the file is created. Each member of a physical file has a single access path.
To add more complexity to the subject, a physical file may have multiple record types. Each record type may have a different structure. Typically record types were used to store a transaction header and transaction detail in the same physical file. For example, Invoice headers may be stored in RECHEAD and each header line would have the leading character '8'. Invoice details would be stored RECDET and contain the leading character of '9'. This is a very old practice dating back to the days of punch cards! Multiple records is very rare and indefensible these days but every programmer is likely to stumble over this in legacy code.
To learn more about your files, try commands DSPDBR (Display database attributes) DSPFD (Display file description) and DSPFFD (Display file field description).
On the AS/400, changing the structure of an AS/400 physical file can be a long process for a number of reason.
The Job
A job on the AS/400 is the smallest unit of work. Well actually since somewhere around V4, jobs can be broken into multiple threads, but I won’t go into that here.
The Subsystem
On the AS/400, all jobs run in a Subsystem. Subsystems are the "staging ground" for all work performed on the AS/400. Each Subsystems is described in a subsystem description object. Some standard AS/400 Subsytems include:
QBASE
Basic Subsystem, (primary subsysten on smaller CPUs)
QINTER
For interactive jobs
QCTL
Controlling subsystem
QCMN
Communication jobs
QPGMR
For programmer's batch jobs
QSPL
Printer spooling jobs
QBATCH Batch jobs Custom subsystems can be added by the system administrator. They are usually added for tasks that have special system needs. High priority tasks such as billing or the customer service may have their own dedicated subsystem. Lower priority tasks may be submitted into the common QBATCH Subsystem.
When a Subsystem is created, parameters include the maximum number of jobs to run in the Subsystem, and how the Subsystem uses defined "pools" of system memory.
A Subsystem has to be started in order for jobs to run in the subsystem. They also have to be free of messages to function properly. Sometimes Subsytems are brought down during system backups or system maintenance and are not re-started. The command WRKSBSD will tell you if the subsystem is started. The Command WRKACTJOB will show you if a subsytem in has any messages waiting. (More on WRKACTJOB later)
Note the Q prefix on each of these Subsystem names. Note that all IBM objects begin with the letter Q. It is considered bad practice to create objects that begin with the letter Q.
Here are some useful Subsystem Commands
DSPSBSYSD
Display subsystem description
WRKSBS
Work with subsystems
WRKSBSD
Work with subsystem description
WRKSBSJOB
Work with subsystem jobs
ENDSBS
End subsystem
STRSBS
Start subsystem
CHGSBSD
Change subsystem description
DSPSBSD
Display subsystem description
The subsystem description includes general definitions as well as Storage Pool definitions. The General Definition includes the Subsystem Name, Description and Maximum number of Jobs that can run in the subsystem.
The Storage Pool attributes determine how the subsystem uses memory for work. The Storage Pool can be:
1) Shared with other subsystems
2) A private pool can be set up for the jobs to be run in
3) Or both a shared and private pools can be setup
The storage pool definition also sets the maximum number of jobs to be run in the respective pools.
Shared or Private Subsystems:
Shared subsystems are the most efficient because more than one subsystem can use the storage pool. If you have limited main storage this is the best choice. Private subsystems reserve storage so that activity levels will remain constant for the users of the subsystem. Share/private subsystems may give you the advantage of both if you have enough main storage.
The Job Queue (JOBQ)
The job queue is the place where jobs wait in line for processing. The AS/400 typically makes use of both batch and interactive jobs. Batch jobs are those jobs that get submitted in a queue, gets processed when resources are available, and stores the output in a file or output queue for future reference. Batch jobs are submitted into one of an AS/400 job queues. Interactive jobs tend to have a human user waiting for a quick reply. Interactive jobs run directly in the QINTER subsystem. Interactive jobs do not have to wait in line for system resources to become available.
If you CALL a program interatively, (eg: CALL MYLIB/MYPROG) it runs on your screen during its excecution and run in the Subsystem QINTER.
If you wish to submit a program to batch, then use the SBMJOB command.
A typical SBMJOB will look like this:
SBMJOB CMD(CALL PGM(MYLIB/MYPROG)) JOB(MYJOBNAME)
- Other ways of submitting a job to a job queue.
STRDBRDR
Start Database Reader STRDKTRDR Start Diskette Reader STRPRTWTR Start Printer Writer SBMDBJOB Submit Database Jobs
TFRJOB Transfer Job The Create Job Queue (CRTJOBQ) command creates a new job queue. A job queue contains entries for jobs that are waiting to be processed by the system. After you create a new job queue, you must add an entry for it in the appropriate subsystem description. To do this use the Add Job Queue Entry (ADDJOBQE) command.
The Output Queue
On the AS/400, whenever a report is printed, the output goes to an output queue as a spooled file. A spooled files is a member of an output queue. The spooled file stays in the output queue until it is directed to a printer or removed. Usually there is an output queue associated with each printer.
Here are some Output Queue Commands:
Create Output Queue
CRTOUTQ
Clear Output Queue
CLROUTQ
Delete Output Queue
DLTOUTQ
Hold Output Queue
HLDOUTQ
Work with Output Queue
WRKOUTQ
The Work with Output Queues (WRKOUTQ) command allows the user to display and work with either some or all output queues.
-----------------------------------------------------------------
Work with All Output Queues
Type options, press Enter.
2=Change 3=Hold 4=Delete 5=Work with 6=Release 8=Description
9=Work with Writers 14=Clear
Opt Queue Library Files Writer Status
__ INVOICE QGPL 0 INVPRT RLS
__ NEWYORK QGPL 0 NYPRT RLS
__ PGMRMV QGPL 0 RLS
__ QDKT QGPL 0 RLS
__ QPRINT QGPL 25 RLS
__ QPRINTS QGPL 34 RLS
__ QPRINT2 QGPL 0 RLS
__ RDAYEND QGPL 11 RLS
__ ROUTQ QGPL 0 RLS
__ ROUTQ QGPL 1 RLS
__ BOB QGPL 0 RLS
More...
Command
===>___________________________________________________________
F3=Exit F4=Prompt F5=Refresh F12=Cancel F24=More keys
-----------------------------------------------------------------Here is a small utility to copy the entire contents of an outq on one AS/400 to an outq on another AS/400.
Work with Active Jobs
The Work with Active Jobs command displays the performance and status information for jobs that are currently active on the system.
The jobs are ordered on the basis of the subsystem in which they are running. Jobs that run in a subsystem are alphabetized by job name and indented under the subsystem monitor job field they are associated with.
Most programmers and operators use this screen extensively. It is useful for many things including catching program messages, and CPU hogs.
Pressing F5 and F10 on this screen helps monitor CPU usage. A job with high CPU usage over a prolonged period may be characteristic of a job that has gone into an infinite loop.
-----------------------------------------------------------------
Work with Active
Jobs
SYS2
18/01/01 23:40:08
CPU %: 54.6 Elapsed
time: 00:15:47 Active jobs:
167
Type options, press Enter.
2=Change 3=Hold 4=End
5=Work with 6=Release 7=Display message
8=Work with spooled files
13=Disconnect ...
Opt Subsystem/Job User
Type CPU % Function Status
__
BILLING QSYS SBS
.0
DEQW
__ DISTRIBUTION QSYS SBS
.0
DEQW
__ QBATCH
QSYS SBS
.0
DEQW
__ APPDAYEND ENDDAY BCH 53.7
IDX-LBI1205P RUN
__
QCMN QSYS
SBS
.0
DEQW
__
QCTL QSYS
SBS
.0
DEQW
__ QSYSSCD QPGMR
BCH .0 PGM-QEZSCNEP EVTW
__
QYPUMON HARSHA BCH .0
PGM-QYPUDQMN DEQW
__
QINTER QSYS
SBS
.0
DEQW
More...
Parameters or
command
===>___________________________________________________________
F3=Exit
F5=Refresh F7=Find F10=Restart statistics
F11=Display elapsed data
F12=Cancel F23=More options F24=More
keys
-----------------------------------------------------------------
There is a great deal of useful information in this screen and
associated screens. Note the column at left that allows an option next
to a job. Option "5=Work With" allows you to drill down into an active
job and retrieve an outstanding amount of job information including library
list, open files and job log.
-----------------------------------------------------------------
Work with
Job
System: SYS2
Job: BILLING
User: QSYS Number:
022216
Select one of the following:
1. Display job
status attributes
2. Display job definition attributes
3.
Display job run attributes, if active
4. Work with spooled
files
10. Display job log, if active or on job queue
11.
Display call stack, if active
12. Work with locks, if
active
13. Display library list, if active
14. Display open
files, if active
15. Display file overrides, if active
16.
Display commitment control status, if
active
More...
Selection or
command
===>___________________________________________________________
F3=Exit
F4=Prompt F9=Retrieve F12=Cancel
-----------------------------------------------------------------
Change Job
While in Work With Active Jobs (WRKACTJOB) or WRKJOBQ you can change attributes of a job (CHGJOB) that is running or waiting to run. For example, you can:
o Change the job queue priority
o Change the run priority
o Change the output priority
o Move a job to a different job queue or output queue
Job Logs
A job log contains information related to jobs, such as commands in the job, commands in a CL program, and messages. A special type of log, a history log (QHST), contains system data, such as a history of job activity on your system. DSPLOG gives an interesting summary of jobs entering and completing.
The commands in a CL program if the CL program was created with the LOG(*YES) option or with the LOG(*JOB) option and a Change Job (CHGJOB) command was run with the LOGCLPGM(*YES) option
Each job has an associated job log that can contain commands and messages.
At the end of the job, the job log can be written to the spooled file QPJOBLOG so that it can be printed. After the job log is written to the spooled file, the job log is deleted. You can prevent a job log from being written for successfully completing jobs.To prevent a job log from being produced at the completion of a batch job, you can specify *NOLIST for the message level text of the LOG parameter on the Batch Job (BCHJOB), Submit Job (SBMJOB), Change Job (CHGJOB), Create Job Description (CRTJOBD), or Change Job Description (CHGJOBD) command. If you specify *NOLIST for the message text value of the LOG parameter, the job log is not produced at the end of a job unless the job end code is 20 or greater. If the job end is 20 or greater, the job log is produced.
For an interactive job, the value specified for the LOG parameter on the SIGNOFF command takes precedence over the LOG parameter value specified for the job. .DB2/400 Database – The Integrated Database
The AS/400 contains a relational database called DB2/400. IBM has now started to call it the Universal Database or UD400 or something like that. We used to call it 'the database' or DDS. There are two interfaces to the AS/400: The Data Description Specifications (DDS) and Structured Query Language (SQL). The DDS, or the native interface, was carried over from the IBM System/38. The second interface for the AS/400 is SQL.DB2/400 is integrated into the AS/400 partly above the MI and partly in the LIC. Conventional databases are separate software components that reside on top of the operating system. Since DB2/400 is integrated throughout the entire system it can achieve a higher level of efficiency because it is tightly integrated with the components with which it communicates.
AS/400 Architecture and software independence
The AS/400 is designed to separate the software and hardware so changes in one have little effect in the other. This is accomplished through the Machine Interface (MI) which is a software programming interface between the application, the operating system and hardware. The MI is a complete Application Programming Interface (API) set that all applications must use in order to get to the to the hardware. This is
how the AS400 achieves the software independence.