Improving Input/Output Performance [ HP RPG/XL Programmer's Guide ] MPE/iX 5.0 Documentation
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