HP 3000 Manuals

HP RPG/XL Programmer's Guide

Improving Input/Output Performance 

You can decrease the time it takes to process disc files by observing a
few simple guidelines.  These relate to the physical placement of files
on disc and their blocking factors.  The next four sections discuss the
efficiencies to employ whenever you're working with disc files.  (Refer
to operating system manuals, such as Accessing Files Programmer's Guide,
for more information on the disc files used with RPG.)

MPE Files 

MPE files are sequential and random files.  They are not KSAM files or
TurboIMAGE databases.  When you use MPE files, follow these guidelines:

 *  Use block lengths that are multiples of 256 bytes.

    This ensures efficient use of input/output buffers.

 *  If the file is processed sequentially, make the block length as large
    as possible.

    This reduces the number of physical reads to the disc.  Since disc
    I/O is the primary factor in throughput, choose the block length
    carefully.  For example, you might enter a record length of 80 bytes
    and a block length of 32 records as follows:

    :BUILD DFILE;REC=-80,32,F,ASCII;DISC=24000

    A block length of 32 records requires 750 disc accesses to process
    the entire file of 24,000 records.  A block length of 3 requires
    8,000 disc accesses.

 *  Use address-out sorts when available disc space is limited.

    Address-out sorts produce output files containing 4-byte record
    addresses.  You use these record addresses to retrieve data records
    in sorted order.

    The RPG utility, XSORT, can be used to create address-out (ADDROUT)
    files (for detailed information on XSORT, see the RPG Utilities 
    Reference Manual).  Figure 9-1 and Figure 9-2 show how to use XSORT
    and how to process the address-out file in an RPG program.  Figure
    9-1 lists the job file that performs the sort and runs the RPG
    program.  The input file, SEQ1, is sorted by zip code, last name and
    first name.  Only records whose zip codes equal 95501 and whose Type
    Codes equal AA are sorted.  The XSORT parameters are placed after the
    !RUN XSORT.PUB.SYS command in the job file and the output
    (address-out) file is SEQ2.


          Figure 9-1.  Creating an address-out File With XSORT 

When XSORT finishes, the job file executes program, PROG1.  PROG1 reads
the ADDROUT file, SEQ2, created by XSORT and uses its record addresses to
access the data records in SEQ1.  Figure 9-2 lists the File Description
and File Extension Specifications that process these files.


          Figure 9-2.  Using an address-out File - Program PROG1 

            Comments 

 1       This line defines the input file, SEQ1.  This is the data file
         that was input to XSORT.

         Column 31 contains I to specify that this file is processed by
         relative record number.

 2       This line defines the ADDROUT file, SEQ2, produced by XSORT.

         Column 16 contains R to specify that this file is a Record
         Address (address-out) file.

         Column 32 contains T to specify that this is an address-out
         file.

 3       This line identifies SEQ2 as the address-out file containing
         addresses for records in SEQ1.

KSAM Files 

When you use KSAM files, follow these guidelines:

 *  Try to use no more than two keys.

    When you use more than two, system performance degrades as the file
    is updated.  See the KSAM/3000 Reference Manual for details on using
    KSAM files efficiently.

 *  When you do not need to access records in order by key, read the file
    chronologically.  See "Reading a KSAM File Chronologically" in
    Chapter 3.

 *  When accessing a file sequentially, use large block lengths.

 *  When accessing a file randomly, use small block lengths.

 *  When appropriate, temporarily override a file's block length via the
    BUF parameter of the operating system FILE command.

    If a file was created with a large block length and you are
    processing it randomly, enter 1 for the BUF parameter.  Conversely,
    if a file was created with a small block length and you need to
    process it sequentially, enter a large number for the BUF parameter.
    The following FILE command overrides 2, which is the default number
    of buffers, and requests that 4 buffers be used for the file, DFILE.
    The program, GL050, is executed next.  When is processes DFILE, 4
    buffers are used.  Finally, the number of buffers is reset to 2 by
    the RESET command:

    :FILE DFILE;BUF=4
    :RUN GL050
    :RESET DFILE

 *  For systems with two or more discs, allocate the KSAM key file to one
    disc and the data file to the other.

    The following example assigns the KSAM data file DFILE to device
    DATADISC (a symbolic name for disc drive 1).  The KSAM key file is
    assigned to device KEYDISC (a symbolic name for disc drive 2).

    :RUN KSAMUTIL.PUB.SYS
    >BUILD DFILE;DEV=DATADISC;BUILD KEYFILE;KEYDEV=KEYDISC;....

 *  Use multiple file extents to optimize disc space.

    When you divide a file into extents, you specify how many equal parts
    it can be divided into when stored on disc.  Extents enable the
    system software to allocate disc space as it is needed.  Extents also
    help prevent file overflow errors.  For large files, use a large
    number of extents.  The following BUILD command divides the file
    GLDETAIL into 24 extents.  It also specifies that the file contains a
    maximum of 24,000 records.

    :BUILD GLDETAIL;DISC=24000,24;....

 *  Use address-out sorts when available disc space is limited.

    XSORT is an RPG utility sort that can be used to produce address-out
    files.  See "Reading a KSAM File Sequentially by a Non-Key Field"
    under "Reading a KSAM File Sequentially" in Chapter 3 for an example
    of how to use XSORT with a KSAM file.

TurboIMAGE Databases 

When you use TurboIMAGE databases, follow these guidelines:

 *  When desirable, change the block length of a data set via the
    $CONTROL schema statement (for details about $CONTROL, see the
    TurboIMAGE/XL Database Management System manual).

    When you create a database using TurboIMAGE, it automatically
    optimizes file blocking.  In some instances, you may want to change
    those block lengths.  For example, if you're using a small data set
    to validate account numbers, you may want to read all of the account
    numbers into memory at one time (one block).

    There are two steps to changing the block length of an TurboIMAGE
    data set.  First, you create the database letting TurboIMAGE compute
    the block lengths.  Second, using the information computed by
    TurboIMAGE, you calculate a new block length.  And finally, you
    recreate the database using your new block length figure.  For
    example, assume that the M-SOURCE data set (see the schema for this
    data set in Figure 3-23) contains 29 records and all 29 records must
    be read into memory to validate source codes.  The database (MARKET)
    containing this data set must first be created using the following
    $CONTROL statement.  This statement directs TurboIMAGE to compute the
    optimum blocks lengths automatically:

    $CONTROL TABLE,LIST

    Once the database is created, TurboIMAGE produces a schema listing
    that gives the computed block lengths.  Figure 9-3 shows that the
    computed block length for the M-SOURCE data set is 506.


          Figure 9-3.  The Block Length in an TurboIMAGE Schema Listing 

    The computed block length of 506 accommodates only 16 (BLK FAC)
    records from the M-SOURCE data set.  Since the program must read 29
    records, the computed block length must be changed.  To do this,
    calculate the new block length as follows:

    M-SOURCE MED REC * M-SOURCE CAPACITY + 2
         (27)        *       (29)        + 2 = 785

    Now, recreate the MARKET database using this $CONTROL statement:

    $CONTROL TABLE,BLOCKMAX=785,LIST


NOTE  Using BLOCKMAX changes the block length for all data sets in the
      database.


 *  For small master data sets that you want to access sequentially by
    key, read them into an array, then use SORTA to sequence the array.

    Master data sets cannot be accessed sequentially by key.  You must
    sort the data set to do this.  Figure 9-4 shows how to put the
    M-SOURCE data set in sequence by SRCCD (SOURCE-CODE). The program
    reads each M-SOURCE record saving the SOURCE-CODE in the SRC array.
    When all records have been stored, the SORTA operation sorts the
    array.  Finally, the program uses the sorted array to output the
    ordered SOURCE-CODES.


          Figure 9-4.  Using SORTA to Sort an TurboIMAGE Master Data Set 

            Comments 

 1       This line defines the array, SRC, that contains the SOURCE-CODEs
         from the M-SOURCE data set.

         Column 45 is blank to indicate that the array elements are in
         ascending sequence (D indicates descending).

 2       This line defines the SOURCE-CODE field, SRCCD, in the M-SOURCE
         data set.

 3       This line fills the SRC array with SOURCE-CODEs from the
         M-SOURCE data set.

 4       This line sorts the entries in the SRC array when all of the
         SOURCE-CODEs have been retrieved from the M-SOURCE data set.

 5       This is the first line in the loop that accesses each (sorted)
         SOURCE-CODE in the SRC array.

 6       This line defines the exception output record written by the
         loop starting on line 5.  SOURCE-CODEs are written in ascending
         sequence, one per output record.

Releasing Printer Files 

When you want to print data from a printer file before a program
finishes, release the data using column 16 of the Output Specification
(enter R into column 16 of the last Output Specification line you want to
print).

Normally, when you use a printer file, information accumulates during
program execution and is actually printed when the program ends.  There
are occasions, however, when you may want to print data immediately, but
continue with the program.  For example, when customers deposit money at
a bank, they get deposit receipts immediately.  The online program that
processes deposits must "release" the printer file in order to print
these receipts.

Figure 9-5 shows how to release a printer file.  The last line to be
printed (line 3) contains an R in column 16.


          Figure 9-5.  Releasing a Printer File 

            Comments 

 1       This line defines the printer file, ONEPAGE.

         Columns 40-46 contain SLOWLP which is a symbolic name for the
         printer device.

 2       This line starts the output definition of the ONEPAGE record.

 3       This line starts the detail print record.

         Column 16 is R to specify that once this detail record is
         processed, the printer file will be released, reopened and the
         program will continue.

 4       This line defines the last detail field in the printer record.

MPE/iX 5.0 Documentation