HP 3000 Manuals HP 3000 Manuals
Entering Efficient Specifications
The next five sections suggest ways to code RPG Specifications that will
reduce the size of your program and make it execute faster.
Header Specification
* Use the Error Dump File Name (columns 7-14) to avoid lengthy program
dumps to the terminal.
* Use N for the Line # Option (column 20) to decrease code segment
size. (Leave this field blank during testing.)
File Description and File Extension Specifications
* When you don't need to process a KSAM file in key order, put a C in
column 32 of the File Description Specification. This accesses a
file chronologically and does not use the key file. For information
on accessing a KSAM file chronologically, see "Reading a KSAM File
Chronologically" in Chapter 3.
* Use the DSNAME facility to access a file more than one way, rather
than using file equations. DSNAME files share a common file buffer.
For information on the DSNAME feature, see "Reading a KSAM File
Randomly and Sequentially Using Different Keys" in Chapter 3.
* Use the file blocking guidelines for MPE and KSAM files and
TurboIMAGE data bases in this chapter.
Input Specifications
* When files have more than one record type, start with the one that
occurs most often.
* Define only those record types in a file that are used in the
program.
* Define only those fields in a record that are used in the program.
* Define record identification codes as characters (C in column 26, 33
or 40) rather than zones or digits. This speeds up the processing of
those records.
* Only describe a field as numeric when it is used in arithmetic
operations or is edited for numeric contents.
* Avoid describing a numeric field as unpacked numeric or binary. RPG
does all arithmetic in packed decimal format, so it must first pack
non-packed fields.
* Use data structures to reformat fields instead of Calculation
Specification MOVE operations.
* Do not define fields that are not used.
Calculation Specifications
* Minimize the number of work fields by reusing them.
* Minimize the number of indicators by reusing them.
* Define a work field with the minimum size possible.
* Use *BLANK and *ZERO to initialize fields instead of work fields
containing blanks or zeros.
* Only define a work field as numeric when it is used in an arithmetic
operation.
* CLOSE files as soon as you're finished with them. This frees system
resources and makes the files available to other programs.
* Use GOTO operations to branch around calculation lines rather than
conditioning the calculation lines with indicators.
* In MULT operations, enter the smallest field in the Factor 2 field.
* To zero a field, subtract the field from itself. This is more
efficient than using Z-ADD or moving zeros to the field.
* When doing table searches, decide whether the table should be
searched sequentially or in a binary fashion. If most of the
searches in the table are for a few items, put those items first in
the table and search it sequentially (column 34 in the Header
Specification is blank). If the table consists of a large number of
items that are searched with about the same frequency, place the
items in the table in either ascending or descending sequence and
perform a binary search (column 34 in the Header Specification is B).
Correctly placing items in a table and selecting the right search
method reduces the average time to find an item.
* Minimize the number and length of table entries. This reduces the
size of the run-time data segments.
* Get rid of indicators that are not used. They cause warnings to be
printed during compilation.
* If a file has only one input record type defined, do not condition
Calculation Specification operations with its associated indicator.
* Wherever possible, use subroutines (EXSR) to avoid duplicate code.
The execution of subroutines can be conditioned by indicators. Use
external subroutines for operations that can be handled more
efficiently in other languages (for example, string manipulation).
Output Specifications
* Put the most frequently used Output Specifications first.
* When conditioning output, place the most frequently used indicator
first in the OR lines.
* Use record lengths that match the number of characters actually
written. For example, if a report requires only 60 characters, enter
60 as the record length rather than 132 (maximum length).
* If terminal output ($STDLST) includes long and short messages, define
a file for each type. Terminal output records are padded with blanks
before being displayed. Longer record lengths require more memory
and transmission time.