HP 3000 Manuals HP 3000 Manuals
Operation (Columns 28-32)
This field contains a word that directs RPG to perform a certain action.
Each type of operation is discussed in this section of this chapter. The
operations are further broken down in the next section with a detailed
alphabetical description of every RPG calculation specification
operation.
Arithmetic Operations
You perform arithmetic operations by entering numeric fields, literals,
tables, arrays, or array elements in the Factor 1 (columns 18-27) and
Factor 2 Fields (columns 33-42). Enter a numeric field, table, array, or
array element in the Result Field (columns 43-48).[REV BEG] The length of
fields used in arithmetic operations cannot exceed 15 digits. Do not
enter a literal or alphanumeric field in the Result Field. The Factor 1,
Factor 2, and Result Fields can all contain the same field or different
fields. Fields used in Factor 1 and Factor 2 are unaffected by
arithmetic operations unless these fields are also named in the Result
Field.[REV END]
If Factor 1 or Factor 2 contains an array name, the Result Field must
also contain an array name (unless this is an XFOOT operation). If you
use more than one array name in an operation, and the arrays contain
different numbers of elements, the operation is performed for the number
of elements in the smallest array. When you use a single field and an
array name, the field is applied to each element in the array.
[REV BEG]
With arithmetic operations, the Result Field will overflow and data will
be lost if the Result Field is not large enough to hold the result of the
operation. With full numeric overflow checking enabled (through the
$CONTROL OVFLOCHK compiler command) an arithmetic overflow initiates the
overflow error trap. You can control how your program handles the
overflow trap with entries in the Header Specification, columns 55 and
65. If you disable full overflow checking for some calculations with the
$CONTROL NOOVFLOCHK compiler command (or if you haven't enabled full
checking), RPG may left-truncate the calculated value instead of
initiating the overflow error trap. This happens when either Factor 1 or
Factor 2 is the same size or larger than the calculated value of the
operation. If the size of the calculated value is larger than the size
of each of Factor 1, Factor 2, and the Result Field, then RPG initiates
the overflow error trap, regardless of the setting of OVFLOCHK.[REV END]
The arithmetic operations are listed below and are described in the pages
which follow:
ADD, DIV, MULT, MVR, SQRT, SUB, XFOOT, Z-ADD, Z-SUB
Move Operations
Move operations move all or part of Factor 2 to the Result Field. Factor
2 remains unchanged. Do not use the Factor 1 field, resulting indicators
field, or half adjusting field. When data are moved to numeric fields,
no decimal alignment takes place. For example, if the number 2.35 has
two decimal positions and is moved to a field with one decimal position,
the result is 23.5.
You can convert a numeric field to an alphanumeric field by entering the
numeric field name in the Factor 2 Field and the alphanumeric field name
in the Result Field. Packed decimal data are converted to unpacked
format.
You can convert an alphanumeric field to a numeric field by entering the
alphanumeric field name in the Factor 2 Field and the numeric field name
in the Result Field. Unpacked data are converted to packed decimal
format. The Factor 2 Field must contain numeric data only, except for
the sign position which can contain a digit 0-9 or a letter A-R.
The move operations are listed below and are described in the pages which
follow:
MOVE, MOVEA, MOVEL
Move Zone Operations
These operations move the sign bits from the high-order (leftmost) or
low-order (rightmost) position of the Factor 2 Field to the high-order or
low-order position of the Result Field. The digit portion of the
high-order or low-order position can be moved in a similar manner. Thus,
these operations are useful for converting from one character
representation to another.
Factor 2 can be a literal or a field. (Do not use the literal "-0" to
make a field negative. RPG does not recognize it as a valid negative
quantity. Instead, use the literal "-".) The Result Field must contain
a field name. When Factor 2 is a numeric field, the sign moved to the
Result Field is either positive (1100), negative (1101), or unsigned
(1111).
The move zone operations are listed below and are discussed in detail in
the pages which follow:
MHHZO, MHLZO, MLHZO, MLLZO
Compare and Test Operations
The compare and test operations test fields for certain conditions. The
results of the test are reflected by the status of the resulting
indicators you enter in the Resulting Indicators Field (columns 54-59).
The operations do not alter the contents of the fields being tested.
The compare and test operations are listed below and are discussed in the
pages which follow:
COMP, TESTB, TESTN, TESTZ
Branching Operations
Calculation Specifications are executed in the order you enter them.
Occasionally, you may want to change the order of execution. For
instance, under certain conditions you may want to bypass one or more
calculations or you may want to repeat a group of operations several
times in the same program cycle.
The branching operations are listed below and are discussed in detail in
the pages which follow:
GOTO, TAG
Internal Subroutine Operations
When a program performs the same operations under different conditions,
you can code the operations once as an internal subroutine and then
branch to the subroutine to perform the operations. You code internal
subroutines as part of the RPG program. (External subroutines are not
part of the program. They are generally routines that are used by many
programs.)
Figure 8-7 shows how to enter an internal subroutine. Internal
subroutines follow all other Calculation Specifications in the program.
You can identify them by entering an SR into the Control Level Field
(columns 7-8), although this is optional. The BEGSR operation (line 2)
marks the beginning of the internal subroutine. Enter a unique name for
the subroutine in the Factor 1 Field. The name can be the same as a
field name but must not be the same name used with a TAG operation or
another BEGSR operation. The operations that are part of the internal
subroutine follow the BEGSR operation (line 3). The ENDSR operation ends
the internal subroutine (line 4). The internal subroutine is executed
from the main program by the EXSR operation (line 1).
___________________________________________________________________________________
| |
| 1 2 3 4 5 6 7 |
| 678901234567890123456789012345678901234567890123456789012345678901234|
| _______________________________________________________ |
| |
| C . |
| C . |
| C (main program code) |
| C . |
| C . |
| 1 C EXSR SUBNAM |
| C . |
| C . |
| 2 CSR SUBNAM BEGSR |
| CSR . |
| CSR . |
| 3 CSR (subroutine body) |
| CSR . |
| CSR . |
| 4 CSR ENDSR |
| |
| |
___________________________________________________________________________________
Figure 8-7. Using an Internal Subroutine
Within a subroutine, you can condition an operation by entering
indicators in the Indicators Field (columns 9-17). You cannot use
control-level indicators in the Control Level Field (columns 7-8) to
condition them; however, you can use them to condition the EXSR operation
that performs the subroutine. You can define fields inside or outside of
an internal subroutine. Fields that you define within the subroutine can
be referenced outside of it also.
There is no limit to the number of internal subroutines you can use in a
program, and you do not have to enter them in the order in which they are
executed. Subroutines can contain EXSR operations that call other
internal subroutines. However, a subroutine cannot call itself nor can
it call a subroutine that calls it. Do not nest subroutines.
You can share internal subroutines with other programs by putting them
onto disk and incorporating them into the programs by placing $INCLUDE
statements at the points where the subroutine would normally be coded.
When you do this, be careful to use the correct names for fields or
labels used in the subroutine.
The internal subroutine operations are listed below and are described in
the pages which follow:
BEGSR, ENDSR, EXSR
External Subroutine Operations
External subroutines are subroutines written in C, Pascal, COBOL, SPL (CM
only), or FORTRAN that are executed from the RPG program. Use external
subroutines for routines that are common to many programs.
You must compile external subroutines separately from the RPG program and
place them in executable libraries (see the HP Link Editor/iX Reference
Manual for details on placing compiled subroutines in executable
libraries).
You execute (call) external subroutines using the EXIT operation. You
pass information (parameters) to and from the subroutine using either, or
both, the RLABL or PARM operations. Parameters can be fields, tables,
and arrays. Additionally, if you use RLABL, you can pass indicator
settings.
RPG passes data to an external subroutine by giving it the byte address
of the data. If the data is numeric (all numeric data is stored
internally in packed decimal format) and the external subroutine is
written in COBOL, define the data as COMP-3. If you're not using COBOL,
you must convert the numeric data yourself. When defining (declaring)
data in an external subroutine, be sure to use the correct field type and
length.
When compiling COBOL external subroutines to be run in MPE/iX
compatibility mode, include the ANSIPARM parameter in the $CONTROL
compiler directive. This parameter aligns parameters on byte boundaries,
which RPG expects. (When compiling COBOL external subroutines in MPE/iX
native mode, byte alignment is automatic.)
NOTE When coding in C, the procedure name must be in lowercase. If
coding in Pascal, FORTRAN, or COBOL, the compilation process will
do any downshifting necessary.
The external subroutine operations are listed below and are discussed in
the pages which follow:
EXIT, PARM, RLABL
Structured Programming Operations
Structured programming operations let you use structured programming
techniques. Structured programming is a coding discipline that seeks to
keep routines in manageable, functional units that can be tested and
debugged separately. Routines in structured programs are modular and
insulated from other routines; no direct branching into and out of them
is allowed.
The RPG structured programming operations make a program easier to read,
they reduce the number of Calculation Specifications, and they eliminate
complex use of indicators. The structured programming operations are
listed below and are described in detail in the pages which follow:
CABxx, CASxx, DO, DOUxx, DOWxx, ELSE, END, IFxx
Indicator and Bit Setting Operations
These operations let you turn indicators On and OFF at will. They also
let you turn individual bits in a one-character alphanumeric field ON and
OFF.
When you're turning record-identifying indicators ON and OFF using the
indicator operations, remember that they are reset automatically
whenever a record is read from the associated file. Similarly, the
record-identifying and the control-level indicators (L1-L9) are turned
OFF at the end of detail-time processing.
The indicator and bit setting operations are listed below and are
discussed in the pages which follow:
BITOF, BITON, SETOF, SETON
Table and Array Operations
The table and array operations let you search an array, a single table,
or alternating tables. To ensure that arrays are in ascending or
descending sequence before you search them, you can use the SORTA
operation.
The table and array operations are listed below and are described in the
pages which follow:
LOKUP, SORTA
File Operations
The file operations let you perform all file handling functions. Some
operations read records from chained, demand, indexed and full procedural
files. There are operations that let you obtain exclusive access to a
TurboIMAGE or KSAM file. You can perform input and output during
Calculation Specification processing and you can specify the file from
which the next record will be read.
The file operations are listed below and are described in the pages which
follow:
CHAIN, CLOSE, EXCPT, FORCE, LOCK, READ, READE, READP, RESET, SETLL, UNLCK
Display Operations
The display operations let you display data and messages on the terminal.
You can also use them to enable the function keys on the keyboard and to
sense when the user presses them.
The display operations are listed below and are described in the pages
which follow:
DSPLM, DSPLY, MSG, SET
Debugging Operation
This operation facilitates the debugging process by displaying (at any
point in the Calculation Specifications) the indicators that are ON and,
optionally, a field in the program.
The debugging operation is listed below and is described in the next
section:
DEBUG
System Operations
[REV BEG]
The system operations listed below let you use or access various
operating system functions without directly using system intrinsics or
system commands:
FNDJW, FNUM, PUTJW, SUSP, TIME, TIME2
Two additional system operations let you call system intrinsics directly
from your RPG program:
INTR, IPARM
For information on the system intrinsics discussed in the following
sections, see the MPE/iX Intrinsics Reference Manual.[REV END]