IBM i Work Management

Objectives of this Document

This guide is designed to give you basic understanding of IBM i work management and file management concepts.

Note that this discussion contains many useful, but equally dangerous commands. As you are likely working on a system that is used by other developers or by a business without adequate safeguards 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.

The Object

On the IBM i everything worth talking about is an object. This is not an 'object', in the object-oriented sense of the word. People more familiar with Windows/DOS or Linux/Unix can replace the word object with the word 'file' or 'thing' if it makes you more comfortable. You will notice that IBM i people will go on and on about their objects.

For instance, if you want to see all the objects in libary QSYS, type

	                               Work with Objects                                
 Type options, press Enter.                                                     
   2=Edit authority        3=Copy   4=Delete   5=Display authority   7=Rename   
   8=Display description   13=Change description                                
 Opt  Object      Type      Library     Attribute   Text                        
      QADVSEC     *LIB      QSYS        PROD                                    
      QCA400W     *LIB      QSYS        PROD                                    
      QCBL        *LIB      QSYS        PROD                                    
      QCBLLE      *LIB      QSYS        PROD                                    
      QCBLLEP     *LIB      QSYS        PROD                                    
      QCPPLE      *LIB      QSYS        PROD                                    
      QANZAGENT   *USRPRF   QSYS                    Trace Analyzer Agent Server
      QAUTPROF    *USRPRF   QSYS                    IBM-supplied User Profile  
      QBRMS       *USRPRF   QSYS                    IBM-supplied User Profile  
      QCLUMGT     *USRPRF   QSYS                    IBM-supplied User Profile  
      QCLUSTER    *USRPRF   QSYS                    IBM-supplied User Profile  

 Parameters for options 5, 7 and 13 or command                                  
 F3=Exit   F4=Prompt   F5=Refresh   F9=Retrieve   F11=Display names and types   
 F12=Cancel   F16=Repeat position to   F17=Position to                          

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 IBM i including commands, controllers, data areas, device descriptions, files, line descriptions, menus, output queues, programs and user profiles.

The Library

All IBM i objects are organized into libraries. Each object must belong to a library. Even a libraries belong to a special library called the QSYS library. An object can belong to only one library. IBM i libraries are organized as a single-level hierarchies, unlike the directory structure found in Windws and Linux which may have multilevel hierarchies.

DOS or Unix files, such as the example below, may be referenced within a multilevel hierarchy illustrated with directories, and subdirectories.

The IBM i 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. Here are a few common libraries

QSYS - System Parent Library
QSYS2 - System Library for CPI's
QHLPSYS - Online Documentation Library for Users
QTCP - TCP Connectivity Utilities
QAFP - Advanced Function Printing
QGPL - General Purpose Library
QTEMP - Job specific temporary Library (deleted when the job ends)

To uniquely identify an IBM i system object you need the name both the library the object. The IBM i identifies objects by their qualified name, which takes the form of LIBRARY/OBJECT. For example, to accurately refer to 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.

IBM i libraries and file names are limited to 10 characters.

The Library List

The Library List is the list of libraries within scope at any given time. The Library List is similar to the concept of Path in Linux or Windows.

If an object is within scope of the Library List, them the object can be referenced with a relative reference. In the following example, we call a program by name, without using the qualifying library name


If an object is not in the Library List it has to be referenced with an absolute reference that explicitly identifies the library. Example:


You are permitted 25 libraries in the User Portion of the library list. Later versions of the OS have increased this to 250. Library lists can be changed with the folling 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 	

These commands are only applicable for the current session. When you exit the session library list will be lost

Type of Files

On the IBM i, data is arranged into data files. The IBM i has many different types of files. These include Physical files (tables), Logical file (indexes), Printer files, Save files. The physical (or data file) is similar to the SQL 'Table' on other systems.

To see all of the files on your system:


When you run this command, note that your files come with different attributes See if you can spot these types of files below Physical files(PF), Logical Files (LF), Printer files (PRTF), Display Files(DSPF), Tape Files (TAPF), Save Files (SAVF).

	                        Work with Objects

	 Type options, press Enter.                                                     
	   2=Edit authority        3=Copy   4=Delete   5=Display authority   7=Rename   
	   8=Display description   13=Change description                                
	 Opt  Object      Type      Library     Attribute   Text                        
     __   QADSPAUD    *FILE     QSYS        PF          System supplied outfile for 
     __   QADSPAUP    *FILE     QSYS        PF          System supplied outfile for 
     __   QAMOPVT1    *FILE     QSYS        LF          OPTICAL PVR LOGICAL VIEW 1    
     __   QAMOPVT2    *FILE     QSYS        LF          OPTICAL PVR LOGICAL VIEW 1    
     __   QAS9CEEVT   *FILE     QSYS        DSPF          
     __   QCRFDWNL    *FILE     QSYS        ICFF                       		  
     __   QTAPE       *FILE     QGPL        TAPF        Default tape data device fi 		  
     __   ZENDPHP7    *FILE     QGPL        SAVF        ZEND SERVER 9 PRODUCT SAVF  
	 Parameters for options 5, 7 and 13 or command                                  
	 F3=Exit   F4=Prompt   F5=Refresh   F9=Retrieve   F11=Display names and types   
	 F12=Cancel   F16=Repeat position to   F17=Position to   F24=More keys  

Physical Files

The IBM i Physical File, often called simply File or Data File, contains the actual data that is stored on the system, and a description of how data is to be presented to or received from a program.

The Physical File is equivalent to an SQL Table. It may be defined using the propriatory IBM DDS (Data Description Language) or standar SQL DDL langauge. On the IBM i, a Physical File can be placed in any library on the system. Placement of Physical Files does not have rigid rules often found on Linux and DOS/Windows databases. Physical Files are identified by their name and library. They also have a record format. They may have key field(s). Data may be unique be unique on the keyed field.

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.

This is what a DDS file definition looks like:

What to take note of here:

  • Record Format DETRC
  • Keyed (K) on DTORDNO
  • Primary Key DTORDNO because of combination of Key and work UNIQUE
  • Use of different data types including AlphaNumeric, Signed Numeric, Packed Numeric, Binary, Float, Date, Time and TimeStamp

Physical File Members

Physical files contain 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 by company grouping (divsion, department) or over time (month, year). You can think of a Physical File Members as drawers in a filing cabinet. Each drawer is the same size but likely contains different data.

Typically a business application might have created a new member for each month of the year or for each corporate division. In the past, the use of multiple membered files could be justified by concerns of storage limitations and disk access speed. Today speed or storage concerns should not be an excuse for using multi-membered files. Furthermore, multiple membered files does not fit in SQL rules. 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 headers and details 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.

Logical Files

The Logical file is a special type of file used to help programs access physical file data more quickly. Logical files are a linked to one or more physical file. They are similar to SQL concepts of indexes and sometimes closer to SQL views. They provide facility to 1) select columns 2) join tables, as well as 3) order rows (sort).

Logical Files combine the features of both SQL Views (column selection and table joining) and SQL Indexes (row ordering). They usually function as an Index. Logical files can also have select/omit statements, which filter which rows of the PF.

The differences between iSeries file/logicals and standard SQL tables/indexes is related to the fact, that IBMs DB2/400-system was created a long time ago when SQL was a still in development and had not yet been implemented in a commercial system. IBM has come a long way in supporting both its legacy file formats as well as SQL table on the IBM i, but there are differences and challenges to overcome in bridging the two.

Some command to learn about your files and objects

  • show me all objects that start with "A" in all libraries
  • object info


  • shows all logicals on physical
  • one file or many at a time
  • results can be piped to printer or outfile table for use in Excel or other desktop tool

  • show all fields in file
  • one file or many at a time
  • results can be piped to printer or outfile table for use in Excel or other desktop tool

  • shows everything else about file (including number of members, triggers, journaling etc...)
  • one file or many at a time
  • results can be piped to printer or outfile table for use in Excel or other desktop tool

    To learn more about your files, try commands DSPDBR (Display database attributes) DSPFD (Display file description) and DSPFFD (Display file field description). Examples:

    What is Work Management?

    Our discussion of Work Management has nothing to do with DayTimers or staying in the office to 6 PM .

    Work Management in the IBM i context refers to the functions that control the IBM i'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 IBM i systems with all tools necessary to run typical operations. This may be why it is often over-looked and under emphasized in many companies. However if you understand work management, you know what effects the various pieces of the system, and how to change them so they operate more efficiently.

    IBM i Commands

    The IBM i native command language is called CL (Command Language). Like Windows/DOS and Linux batch files, most CL commands can be run at the command line or strung together in a batch file. Unlike Windows/DOS and Linux, batch files on the IBM i are compiled.

    What does the IBM i Command line look like? Here is one below:

        F3=Exit F4=Prompt F5=Refresh F12=Cancel F24=More keys

    The IBM i 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 IBM i was very popular in small and medium businesses, 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, IBM i commands are more consistently constructed compared to other operating systems. IBM i commands like English sentences are generally composed of at least a verb and a subject portion and often an object

    Examples of verb segments:

    WRK (work with), CRT (create), DLT (delete), CHG (change), DSP (display)	

    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.

    For example: CRTLIB or DLTLIB.


    If you have not already used it, try the IBM i menu Command GO MAJOR. GO MAJOR is an on-line index of most IBM i commands. (Press 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
        Selection or command
        F3=Exit F4=Prompt F9=Retrieve F12=Cancel F13=Information Assistant
        F16=IBM i 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 

  • 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
        F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel 
        F13=How to use this display F24=More keys 

    The F1 key is a 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 IBM i Input-Processing-Output Model

    On the IBM i, the classic data processing "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).

    DSPDBR - Display database attributes

    DSPDBR gives us list of logical files that access the physical file.

    	   29/03/01              Display Data Base Relations                        
     DSPDBR Command Input                                                       
       File  . . . . . . . . . . . . . . . . . . . : FILE       QADBPKG         
         Library . . . . . . . . . . . . . . . . . :            *LIBL           
       Member  . . . . . . . . . . . . . . . . . . : MBR        *NONE           
       Record format . . . . . . . . . . . . . . . : RCDFMT     *NONE           
       Output  . . . . . . . . . . . . . . . . . . : OUTPUT     *               
       Type of file  . . . . . . . . . . . . . . . :            Physical        
       File  . . . . . . . . . . . . . . . . . . . :            QADBPKG         
         Library . . . . . . . . . . . . . . . . . :            QSYS            
         Member  . . . . . . . . . . . . . . . . . :            *NONE           
         Record format . . . . . . . . . . . . . . :            *NONE           
         Number of dependent files . . . . . . . . :                4           
     Files Dependent On Specified File                                          
       Dependent File         Library       Dependency   JREF    Constraint     
           QADBLPKG           QSYS          Data                                
           SYSPACKAGE         QSYS2         Data                                
           SYSPACKAGE         OAWWW         Data                                

    DSPFFD - Display file description

    The DSPFFD command is used to list the fields that make up a record format in a file. Each field is listed along with its characteristics -- data type, length, position in the record and others.

                                 Display File Field Description                            
     Input parameters                                                                      
       File  . . . . . . . . . . . . . . . . . . . :  QADBPKG                              
         Library . . . . . . . . . . . . . . . . . :  QSYS                                 
     File Information                                                                      
       File  . . . . . . . . . . . . . . . . . . . :  QADBPKG                              
         Library . . . . . . . . . . . . . . . . . :  QSYS                                 
       File location . . . . . . . . . . . . . . . :  *LCL                                 
       Externally described  . . . . . . . . . . . :  Yes                                  
       Number of record formats  . . . . . . . . . :      1                                
       Type of file  . . . . . . . . . . . . . . . :  Physical                             
       File creation date  . . . . . . . . . . . . :  14/06/05                             
       Text 'description'. . . . . . . . . . . . . :  SQL Package physical file            
     Record Format Information                                                             
       Record format . . . . . . . . . . . . . . . :  QDBPKG                               
       Format level identifier . . . . . . . . . . :  41DE8159867B9                        
       Number of fields  . . . . . . . . . . . . . :     17                                
       Record length . . . . . . . . . . . . . . . :    450                                
       Format text . . . . . . . . . . . . . . . . :  SQL Package physical file            

    The Job

    A job on the IBM i 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 IBM i, all jobs run in a Subsystem. Subsystems are the "staging ground" for all work performed on the IBM i. Each Subsystems is described in a subsystem description object. Some standard IBM i Subsytems include:


    Basic Subsystem, (primary subsysten on smaller CPUs)


    For interactive jobs


    Controlling subsystem


    Communication jobs


    For programmer's batch jobs


    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


    Display subsystem description


    Work with subsystems


    Work with subsystem description


    Work with subsystem jobs


    End subsystem


    Start subsystem


    Change subsystem description


    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 IBM i 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 IBM i 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:


    Other ways of submitting a job to a job queue.


    Start Database Reader
    STRDKTRDR Start Diskette Reader
    STRPRTWTR Start Printer Writer

    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 IBM i, 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


    Clear Output Queue


    Delete Output Queue


    Hold Output Queue


    Work with Output Queue


    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 
    F3=Exit F4=Prompt F5=Refresh F12=Cancel F24=More keys 

    The Work with Active Job

    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 
    __  QINTER        QSYS   SBS   .0               DEQW 
    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 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 
    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 IBM i 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 IBM i: 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 IBM i is SQL.

    DB2/400 is integrated into the IBM i 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. 

    IBM i Architecture and software independence

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

    IBM i Similar to Definition
    Physical File SQL Table Physical files contain the actual data that is stored on the system, and a description of how data is to be presented to or received from a program. They contain only one record format, and one or more members. Records in database files can be externally or program-described.
    Record Format no equivalent The IBM i allows a single file to have one or more types of records or "record formats". This was useful at one time, for instance, to have both headers and detail records in the same file. This feature was included in ealy IBM systems to accomodate migration from punch card machines.
    Physical Files Members no equivalent A Physical Files Member is a means of grouping records in the file together. Most physical files on the IBM i have a single member, but they can have others added using the ADDPFM (Add Physical File Member) command. This was commonly used to seperate data by month, or by division. It facilitated file management, backups etc... Source files are prime examples of multi-member files.
    Logical File SQL View Logical files do not contain data. They contain a description of records found in one or more physical files. A logical file is a view or representation of one or more physical files. Logical files that contain more than one format are referred to as multi-format logical files.