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 Commands

The 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 keys 

  The 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.

MYLIB/MYFILE

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 

     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.

 

Link to the AS/400 Learnin' Project    

1
Hosted by www.Geocities.ws

1