HP 3000 Manuals HP 3000 Manuals
The Input Specification Fields
The fields you can use in the Input Specification are described in the
sections which follow in this chapter. Each field has a unique name and
occupies specific positions (columns) in the specification.
Sequence Number (columns 1-5)
This field contains the source record sequence number, described in
Chapter 2.
Specification Type (Column 6)
This field contains an I to identify this line as an Input Specification.
File and Record Description Fields (columns 7-41)
These fields describe the record types contained in input, combined and
update files.
Group all Input Specifications for a file together. Define the first
record type by entering the File and Record Description Fields, leaving
columns 43-70 on that specification line blank. Follow this line by one
or more specifications that describe the fields for the record type (see
the Field Description Fields (columns 43-70)). Repeat this specification
sequence until all record types are defined.
Example
Figure 7-2 shows two record types for the file ORDER. Lines 1 and 5
contain the File and Record Description Fields for each record type.
Lines 2 through 4 and 6 through 7 contain the Field Description Fields
for the record types.
___________________________________________________________________________________
| |
| 1 2 3 4 5 6 7 |
| 678901234567890123456789012345678901234567890123456789012345678901234|
| _______________________________________________________ |
| |
| 1 IORDER NS 01 44 CA |
| 2 I 1 10 CUSNUM |
| 3 I 11 40 CUSNAM |
| 4 I 41 42 DSCNT |
| 5 I NS 02 44 CB |
| 6 I 1 8 PROD |
| 7 I 9 120QTY |
| |
| |
___________________________________________________________________________________
Figure 7-2. Entering Input Specifications for a File
File Name (columns 7-14).
This field names the file to which this and subsequent Input
Specifications apply. Enter the name of an input, combined, or update
file defined by a File Description Specification. Do not enter the name
of an output or display file.
---------------------------------------------------------------------------------------------
| | |
| Columns 7-14 | Description |
| | |
---------------------------------------------------------------------------------------------
| | |
| Valid file name. (File names contain from one to eight | Name of an input, update, or |
| characters, beginning with a letter. The remaining | combined file being described |
| characters can be letters or digits. Embedded blanks | by this Input Specification. |
| are not allowed.) | |
| | |
| Data structure name (columns 7-12). | Name of the data structure |
| | being described by the Input |
| | Specification. |
| | |
---------------------------------------------------------------------------------------------
If you enter more than one Input Specification for this file, you do not
have to repeat the file name on each line. The name remains in effect
until a new one is encountered.
AND/OR (columns 14-16).
This field lets you assign a record identification code longer than three
characters to a record type (AND). It also lets you assign more than one
record identification code to the same record type (OR). This field is
used in conjunction with the Record Identification Codes Field (columns
21-41).
--------------------------------------------------------------------------------------
| | |
| Columns 14-16 | Description |
| | |
--------------------------------------------------------------------------------------
| | |
| AND | Identifies this Input Specification as an AND line. |
| | |
| OR | Identifies this Input Specification as an OR line. |
| | |
--------------------------------------------------------------------------------------
You can intermix AND and OR lines.
To enter AND lines, follow these steps:
1. Make sure that the first three characters of the record
identification code are described by the previous specification.
2. Enter AND in columns 14-16 with up to three additional record
identification code character descriptions in columns 21-41.
Leave columns 17-20 blank. AND lines indicate that all
record-identifying characters must exist before the associated
record-identifying indicator is turned ON.
3. Continue entering AND lines until all of the record identification
codes are defined. A record must contain all characters defined
for the code before its associated record-identifying indicator is
turned ON.
To enter OR lines, follow these steps:
1. Make sure that from one to three characters of the record
identification code are described by the previous specification.
2. Enter OR in columns 14-15 with up to three additional record
identification code character descriptions in columns 21-41.
Leave columns 16-18 blank. Record identification codes in an OR
line and any AND lines which follow it have an AND relationship
(all of them must exist before the associated record-identifying
indicator is turned ON).
3. Continue entering OR lines until you define all of the record
identification codes.
4. You can enter a record-identifying indicator in columns 19-20 of
each OR line. If you do not use one, the last indicator that you
entered applies.
Example
Figure 7-3 shows how three record types are identified by record
identification codes. Lines 1 and 2 specify that records for the first
record type have the letter A in positions 1-3 and the letter B in
position 4. Records for the second record type (lines 3 and 4) have the
letter A in positions 1-3 or a Z in position 80. Records for the third
record type (lines 5-8) have the letter A in positions 1-5 or the letter
Z in positions 76-80.
___________________________________________________________________________________
| |
| 1 2 3 4 5 6 7 |
| 678901234567890123456789012345678901234567890123456789012345678901234|
| _______________________________________________________ |
| |
| 1 IMYFILE AA 01 1 CA 2 CA 3 CA |
| 2 I AND 4 CB |
| I . |
| I . |
| 3 I BB 02 1 CA 2 CA 3 CA |
| 4 I OR 80 CZ |
| I . |
| I . |
| 5 I CC 03 1 CA 2 CA 3 CA |
| 6 I AND 4 CA 5 CA |
| 7 I OR 76 CZ 77 CZ 78 CZ |
| 8 I AND 79 CZ 80 CZ |
| |
| |
___________________________________________________________________________________
Figure 7-3. Using AND and OR Lines to Identify Record Types
Group Sequence (Columns 15-16).
This field lets you specify the order of record types, if any, in a file.
Records types (see the Record Identification Codes Field (columns 21-41))
identify different data record formats in a file. This field is
required.
---------------------------------------------------------------------------------------------
| | |
| Columns 15-16 | Description |
| | |
---------------------------------------------------------------------------------------------
| | |
| 01-99 | Assign this sequence number to the record type specified |
| (right-justified, leading | in the Record Identification Codes Field (columns |
| zeros are not required) | 21-41), and verify this sequence on input. |
| | |
| Two alphabetic characters | No group sequence applies. Do not sequence-check input |
| | record types. |
| | |
---------------------------------------------------------------------------------------------
Use this field when a file contains more than one record type, the record
types are in a specific order, and you want that order verified when the
file is processed. For example, when a file contains a customer
identification record followed by one or more invoice records for each
customer, you may want this order verified. If the record types are not
in the order you specify, an error message is printed and the program
terminates. Group sequences only ensure that within a group, all data
records are in order by the record type entered in the Record
Identification Codes Field (columns 21-41). Other fields on the record
are not sequence-checked. To sequence-check other data fields, use the
Sequence Field (column 18) of the File Description Specification.
You must use 01 for the first record type. For the remaining record
types, enter any set of numbers that are in ascending sequence. For
example, 01, 02, 05, and 52 is a valid sequence.
Within a file, you can use group sequences for some records and not for
others. Enter the Input Specifications for the records that do not use
group sequences first. (The actual data records for these specifications
can appear anywhere in the file and can be interspersed with group
sequence records.) You cannot enter group sequence numbers on AND and OR
lines. For more information see the AND/OR Field (columns 14-16). For
OR lines, the group sequence from the previous line is used.
Example
The file INP contains three different types of records that relate to a
company's sales staff. Each type is identified by a letter in position
10 of the record: A gives the sales person's name, B gives the sales
person's territory and C contains the sales person's sales quota.
NAME A
TERRITORY B Group 1
QUOTA C
NAME A
TERRITORY B Group 2
QUOTA C
NAME A
TERRITORY B Group 3
QUOTA C
To specify that record type A is first for each sales person followed by
record types B and C, enter the numbers 01, 02, and 03 in the Group
Sequence Field on consecutive Input Specifications. On the group 01
sequence line, enter an A in column 27. On the group 02 sequence line,
enter B in column 27 and on the group 03 sequence line, enter C in column
27.
___________________________________________________________________________________
| |
| 1 2 3 4 5 6 7 |
| 678901234567890123456789012345678901234567890123456789012345678901234|
| _______________________________________________________ |
| |
| IINP 011 10 CA |
| I 1 20 NAME |
| I 021 10 CB |
| I 1 5 TERRIT |
| I 031 10 CC |
| I 1 92QUOTA |
| |
| |
___________________________________________________________________________________
Figure 7-4. Defining Group Sequences
Number of Records (Column 17).
This field specifies the number of records allowed for the record type in
the group sequence. Use this field only if you entered a number in the
previous field, Group Sequence (columns 15-16).
--------------------------------------------------------------------------------------
| | |
| Column 17 | Description |
| | |
--------------------------------------------------------------------------------------
| | |
| N | One or more records of this type are allowed in the group. |
| | |
| 1 | Only one record of this type is allowed in the group. |
| | |
| blank | There are no restrictions on the number of records per record |
| | type in the group, or you entered alphabetic characters in the |
| | Group Sequence Field. |
| | |
--------------------------------------------------------------------------------------
Do not enter this field on specifications containing AND or OR in columns
14-16. (If this is an OR line, the number of records for the record type
is taken from the previous Input Specification).
Option/LDA (Column 18).
This field specifies whether the record type is required or optional in a
group sequence (see the Group Sequence Field (column 15-16)). This field
also identifies a data structure as a Local Data Area.
--------------------------------------------------------------------------------------
| | |
| Column 18 | Description |
| | |
--------------------------------------------------------------------------------------
| | |
| O | Records of this type are optional and may or may not be |
| | present in each group. (Prevents sequence errors when a |
| | record is absent.) |
| | |
| U | The data structure defined in this specification is the Local |
| | Data Area. |
| | |
| blank | At least one record with this record type must be present in |
| | each group, or alphabetic characters are entered in the Group |
| | Sequence Field. |
| | |
--------------------------------------------------------------------------------------
Do not enter this field on specifications containing AND or OR in columns
14-16. (If this is an OR line, the value for this field comes from the
previous Input Specification).
U (Local Data Area)
The Local Data Area is a file named LDAFILE which contains 1 record. The
record can contain up to 32 segments of 256 bytes each (the number of
segments depends on how it is created). The Local Data Area provides a
way to pass data between RPG programs.
The Local Data Area is created and initialized (to blanks) by the RPGINIT
utility. RPGINIT is often run by a logon UDC. See the RPG Utilities
Reference Manual for information about RPGINIT.
The Local Data Area is loaded into the User Data Structure at run
time. To create a User Data Structure, define it in the File and
Record Description line of the Input Specification with a U in
the Option Field (column 18). Also enter a DS in the Record
Indicator/Look-Ahead/Trailer/Data Structure Field (columns 19-20) of that
specification. You can follow the File and Record Description line with
Field Description lines describing the LDAFILE record, though this is
optional. Define the record using an array that is the same length as
the LDAFILE record, with an element length of one byte. You can use and
modify the array using Calculation Specifications. When the program
ends, the User Data Structure contents overwrite the Local Data Area.
The following steps show how Program A uses a Local Data Area to pass
information to Program B. (Assume that the Local Data Area has already
been created using the RPGINIT utility.)
1. Program A loads the Local Data Area File into its User Data
Structure.
2. Program A modifies the User Data Structure during calculations.
3. At end-of-job, Program A updates the contents of the Local Data
Area.
4. Program B loads the Local Data Area File into its User Data
Structure.
5. Program B uses the data passed in in the Local Data Area from
Program A.
Example
To use the Local Data Area in a program, enter a U in column 18, and a DS
in columns 19-20. Figure 7-5 shows how to define a Local Data Area
in the Input Specifications.
___________________________________________________________________________________
| |
| 1 2 3 4 5 6 7 |
| 678901234567890123456789012345678901234567890123456789012345678901234|
| _______________________________________________________ |
| |
| I UDS |
| I 1 20 USER |
| I 21 21 OPT1 |
| I 22 22 OPT2 |
| I 23 23 OPT3 |
| I 24 290BGNDAT |
| I 30 350ENDDAT |
| |
| |
___________________________________________________________________________________
Figure 7-5. The Input Specifications for a Local Data Area
Record Indicator/Look-Ahead/Trailer/Data Structure (Columns 19-20).
This field assigns a record-identifying indicator to the record type. It
also lets you specify whether the record type contains look-ahead fields,
whether the next lines define the trailer portion of a spread record, or
whether they define a data structure.
---------------------------------------------------------------------------------------------
| | |
| Columns 19-20 | Description |
| | |
---------------------------------------------------------------------------------------------
| | |
| Record-Identifying Indicators: | |
| | |
| 01-99 | Assign this general indicator. |
| | |
| F0-F9 | Assign this function key indicator. |
| | |
| H0-H9 | Assign this halt indicator. |
| | |
| KA-KN, | Assign this command key indicator. |
| KP-KY | |
| | |
| L1-L9 | Assign this control-level indicator. |
| | |
| LR | Assign the last-record indicator. |
| | |
| MR | Assign the matching-record indicator. |
| | |
| OA-OG, OV | Assign this overflow indicator. |
| | |
| U1-U8 | Assign this user indicator. |
| | |
| 1P | Assign the first-page indicator. |
| | |
| Look-Ahead: | |
| | |
| ** | This record contains one or more look-ahead fields. |
| | |
| Trailer: | |
| | |
| TR | The next specification lines define the trailer portion |
| | of a spread record. |
| | |
| Data Structure: | |
| | |
| DS | The next specification lines define a data structure. |
| | |
| blank | Do not assign an indicator to the record type, or this |
| | record does not have look-ahead fields, or the next |
| | lines do not define the trailer portion o spread record |
| | or do not define a data structure. |
| | |
---------------------------------------------------------------------------------------------
Record-Identifying Indicators
When a file contains several types of records and you want to perform
different operations on each type, use this field to assign a different
record-identifying indicator to each type. At the beginning of each
logic cycle, all assigned record-identifying indicators are turned OFF.
Each time a record is read and selected for processing, the indicator
assigned to it is turned ON and remains on for the entire logic cycle.
You can use a record-identifying indicator to condition a Calculation
Specification operation by entering it in one of the indicator fields
(columns 9-17) of the specification. You can use a record-identifying
indicator to condition an output operation by entering it into one of the
output indicator fields (columns 23-31) of the Output Specification. You
can also use a Calculation Specification to change the setting of a
record-identifying indicator.
Use record-identifying indicators only when:
* You are processing more than one record type in a file.
* You are updating a file (to ensure that updates are made only
after the appropriate records are read).
When using record-identifying indicators, be sure you understand how they
are processed in the RPG logic cycle, especially how they are used in
processing heading, detail, and total records. See the HP RPG
Programmer's Guide for information on the RPG logic cycle.
When you're using chained files, several record-identifying indicators
can be on simultaneously, since several records can be processed at the
same time.
When you're doing multiple reads from one or more demand files during the
same logic cycle, the record-identifying indicators assigned to the
file(s) remain on throughout the cycle if the previous READ operations
were executed successfully. To make sure that these indicators are off,
you must explicitly turn them off using a Calculation Specification.
You can assign record-identifying indicators in any order on the Input
Specifications. You can use OR lines (see the AND/OR Field (columns
14-16)) to assign the same indicator to several record types. Normally,
when using AND lines (see the AND/OR Field), you enter only one
record-identifying indicator (since the AND lines specify all of the
conditions to be met by the record type).
01-99 (General Indicators)
General indicators identify record types in a file. They are the most
frequently-used indicators. When a record associated with a general
indicator is read and selected for processing, the indicator is turned ON
and all operations conditioned by that indicator are performed.
Example
Line 1 in Figure 7-6 shows how to assign general indicator 03 to the
first record type in file READX. Every time a record is processed for
this record type, the ADD Calculation Specification operation (line 2) is
executed.
___________________________________________________________________________________
| |
| 1 2 3 4 5 6 7 |
| 678901234567890123456789012345678901234567890123456789012345678901234|
| _______________________________________________________ |
| |
| 1 IREADX 011O03 05 CX |
| I . |
| I . |
| I 021O 05 CY |
| I . |
| I . |
| I 031O 05 CZ |
| I . |
| I . |
| |
| 2 C 03 STOREA ADD STOREB RESF |
| |
| |
___________________________________________________________________________________
Figure 7-6. Using a General Indicator
F0-F9 (Function Key Indicators)
You can use function key indicators the same way you use general
indicators.
Function key indicators have special meanings when used with the RPG
VPLUS Interface. They are used by VPLUS to signal "events" that take
place at the user terminal. When the user presses ENTER, F0 is turned
ON. When the user presses f1 to f8, the corresponding function key
indicator is turned ON. When an event 9 or greater takes place, function
key indicator F9 is turned ON. See Chapter 10 for a complete discussion
of the RPG VPLUS Interface.
Function key indicators F1-F8 also have special meanings when used in
conjunction with the SET, DSPLY, and DSPLM Calculation Specification
operations (see these operations in Chapter 8 for details).
H0-H9 (Halt Indicators)
Assign these indicators to record types that you want to cause a halt.
When a halt indicator is turned ON, a message is displayed on the
terminal, and the program stops at the end of the current cycle's
detail-time processing. You can continue the program, if you wish. When
the program is continued, the halt indicator is turned OFF.
KA-KN, KP-KY (Command Key Indicators)
You can use command key indicators the same way you use general
indicators.
When you use an RPG Screen Interface (RSI) file, the command keys may
have a special meaning. A user at a terminal keyboard presses f1
followed by a key from the top row of the keyboard to turn on one of the
twenty-four command key indicators. The RPG Screen Interface then
performs the appropriate action. You enable the command key indicators
when you build the screen forms file. You can use command keys that have
not been enabled the same way you use general indicators. See Chapter 11
for information on the RPG Screen Interface and the RPG Utilities
Reference Manual (SIGEDITOR) for information on creating an RSI forms
file.
NOTE In an RSI application program, all command key indicators are set
off prior to the READ of the workstation file.
L1-L9 (Control-Level Indicators)
You can use control-level indicators the same way you use general
indicators. They are turned OFF before the next record is read,
regardless of how you use them.
You can assign control-level indicators to record types in any order.
For example, you can assign the indicators L5, L1, and L7 in that order.
You can also associate control-level indicators with individual fields on
a record (see the Control Level Field (columns 59-60)). Doing this
identifies where the fields fit in the control-break hierarchy.
LR (Last-Record Indicator)
This indicator identifies the record that signals end-of-file. When this
record is encountered, calculations and output conditioned by this
indicator are performed, and the program ends.
MR (Matching-Record Indicator)
This indicator is turned ON before detail-time calculations when a match
occurs on matching fields (see Matching/Chaining Fields, columns 61-62).
The indicator is turned OFF if a match does not occur. The indicator
remains set through total and output calculations in the next cycle.
OA-OG, OV (Overflow Indicators)
These indicators are normally used in Output Specifications to signal
page overflow. However, if you use them on an Input Specification, they
function the same as general indicators. When a record associated with
an overflow indicator is read, the indicator is turned ON and all
operations conditioned by it are performed.
U1-U8 (User Indicators)
You can use these indicators, much the same way you use general
indicators, to condition operations.
1P (First-Page Indicator)
Normally, you use this indicator in Output Specifications to print
headings on the first page of a report. After the headings are printed,
however, you can use it the same way you use a general indicator (the 1P
indicator is turned OFF after each detail-time output).
** (Look-Ahead)
Place ** in columns 19-20 when the record contains one or more look-ahead
fields. Look-ahead fields let you examine the contents of a record
before the record is available for processing. For input files,
look-ahead fields are located on the next record. For a update and
combined files, look-ahead fields are located on the current record. Do
not use look-ahead fields with chained or demand files or with files
containing spread records. Do not use this field on AND or OR lines.
For more information, see the AND/OR Field (columns 14-16).
You can enter as many look-ahead fields for a record as necessary. They
apply to all records in a file, regardless of the record type. Define
look-ahead fields after a record type that has alphabetic characters in
the Group Sequence Field (columns 15-16). Look-ahead field names must be
unique. Do not define them elsewhere in the program.
You cannot alter the contents of look-ahead fields. Do not use them in
result fields or clear them. If you want to use the contents of a
look-ahead field before and after the record is selected for processing,
define it as a look-ahead field and also as a regular field (with a
different name).
When end-of-file is reached in a file containing look-ahead fields, the
look-ahead fields are automatically filled with ASCII 9's (for
alphanumeric fields) and packed +9's (for numeric fields).
Example
Figure 7-7 shows how to define the look-ahead field LOOKHD for the
file OVERLD. Line 1 contains ** in columns 19-20. Line 2 defines the
field name and its location in the record.
___________________________________________________________________________________
| |
| 1 2 3 4 5 6 7 |
| 678901234567890123456789012345678901234567890123456789012345678901234|
| _______________________________________________________ |
| |
| IOVERLD AA 01 |
| I 1 10 MINE |
| I 11 20 YOURS |
| 1 I AB ** |
| 2 I 1 10 LOOKHD |
| |
| |
___________________________________________________________________________________
Figure 7-7. Defining a Look-Ahead Field
TR (Trailer Records)
When a file consists of a header record followed by one or more records
that contain information related to that header, you can condense the
file by formatting the records in a spread format. When you use a spread
record, place the header and related information on the same record. You
can use spread records with primary and secondary files. You cannot use
spread records with update or combined files or files that have
look-ahead fields.
When a file contains several record types, any or all of them can have
spread records. On the Input Specifications, define a spread record as
one logical record. It consists of a header portion followed by a
trailer portion. Follow these steps when defining the spread record:
1. Define the header portion by entering all fields that you're going
to use in the program. Define each field as you normally do,
using the File and Record Description Fields and Field Description
Fields. If you're using record identification codes, control
levels or matching fields, define them as part of the header. If
you entered a number in the Group Sequence Field (columns 15-16),
you must also enter N in the Number of Records Field (column 17).
2. Start the trailer portion by entering TR in the Record Indicator
Field (columns 19-20) in the line following the last header field.
Leave the rest of the specification blank. (Enter only one TR
line per spread record. You can specify as many spread records as
necessary for a file.)
3. Define the trailer fields used in the program. If the trailer
fields repeat on the data record, define them only once. Define
each field as you normally do using columns 44-51 and 53-58 in
each specification line (leave columns 7-42, 59-62 and 71-74
blank). Do not overlap the header portion with the trailer
portion and do not specify control levels or matching fields for
the trailer portion.
When formatting the data records, you can enter as many sets of
trailer fields as the record length allows. If the logical record
does not have enough room for all of the trailer fields, continue
the data on another line and begin that line with the header.
Make sure that the header and trailer fields have the same format
as specified in the Input Specifications.
Example
A hardware and carpentry supply house uses a file that contains a header
record for each general class of item stocked (such as saws, hammers, and
screwdrivers). Each header record is followed by records that show the
quantity of each specific type of item on hand, one record for each type.
For instance, one item record might show 63 cross-cut saws, another might
indicate 15 rip saws. The three records below show how to format the
header and item information into spread records. Notice that the fields,
TYPE, PART, and QTY are repeated three times in each record.
TOOL TYPE PART QTY TYPE PART QTY TYPE PART QTY
| | | | | | | | | |
v v v v v v v v v v
Record 1: SAW CIRCULAR 00031 65COPING 00032 14CROSSCUT 00033 107
Record 2: SAW HACK 00036 27KEYHOLE 00035 29RIP 00036 75
Record 3: SCREW DRIVPHILLIPS 00051 35REGULAR 00052 209RIGHT-ANG 00053 82
In the above records, the header and trailer fields are as follows:
Header Field: TOOL
Trailer Fields: TYPE PART QTY TYPE PART QTY TYPE
PART QTY
Notice that the trailer fields for SAW span two logical records, while
those for SCREW DRIV are contained in one logical record. Figure 7-8
shows how to define the Input Specifications for the spread records shown
above. Lines 1 and 2 define the header field, TOOL. Lines 3-6 define the
trailer fields, TYPE, PART, and QTY.
___________________________________________________________________________________
| |
| 1 2 3 4 5 6 7 |
| 678901234567890123456789012345678901234567890123456789012345678901234|
| _______________________________________________________ |
| |
| 1 IINVEN 01N AA |
| 2 I 1 10 TOOL |
| 3 I TR |
| 4 I 11 20 TYPE |
| 5 I 21 25 PART |
| 6 I 26 30 QTY |
| |
| |
___________________________________________________________________________________
Figure 7-8. Defining a Spread Record
DS (Data Structure)
Data structures let you break a field or an array into subfields that can
be referenced in Calculations and Output Specifications. Data structures
can also be used to group individual fields together so that they can be
used as a unit.
Whenever a data structure is modified its subfields are automatically
modified. Conversely, if a subfield is changed, its data structure is
also changed.
Data structure specifications follow all other Input Specifications.
When defining a data structure, enter the File and Record Description
Fields (columns 7-41) as follows:
1. Enter an I in column 6.
2. If you wish, enter a data structure name in columns 7-12 (if you
do not, an internal name is assigned by the compiler). The name
must conform to the naming conventions used for fields and arrays
and cannot exceed 6 characters. The name cannot be an array
element or a table. Enter one of the following for the data
structure name:
[REV BEG]
* A name not used elsewhere in the program. The data
structure is created as an array with a one-byte element
length. The number of elements is equal to the data
structure length (the highest end positions of its
subfields).[REV END]
* The name of an alphanumeric array defined in a File
Extension Specification.
* The name of a field in an Input Specification.
[REV BEG]
* The name of a previous alphanumeric data structure subfield
(alphanumeric data structure subfield definitions can be
nested, but numeric fields cannot).[REV END]
* If this is the User Data Structure for the Local Data Area,
enter the name LDA (other names are ignored).
3. If this is the data structure for the Local Data Area, enter a U
in column 18. The subfields of the data structure are initialized
from the Local Data Area at the beginning of the program and used
to update the LDA at end-of-job.
4. Enter DS in columns 19-20 to indicate that this is a data
structure.
5. Leave all of the other columns blank.
Define data structure subfields, using the Field Description Fields
(columns 43-70), as follows:
1. Enter an I in column 6.
2. Leave columns 7-43 blank.
3. Enter the starting position of the field in columns 44-47. The
starting position is relative to the first position of the data
structure. The starting position can overlap other subfields in
the data structure.
4. Enter the ending position of the field in columns 48-51. The
ending position is relative to the first position of the data
structure. The ending position can overlap other subfields in the
data structure.
If the subfield is part of a data structure whose length is
already defined, the subfield must be entirely contained within
the data structure (the ending position cannot extend beyond the
length of the data structure).
5. Enter the decimal positions (0-9) for a numeric field in column
52, or leave column 52 blank to indicate that the subfield is
alphanumeric.
6. Enter the subfield name in columns 53-58. A subfield name:
* Can be a new name (not already used in the program).
* Can be a name which has been previously defined as an input
field of a data record. If so, the field length and number
of decimals must be the same as the original definition.
Use columns 44-51 (From and To Fields) to define the
location of the field within the data structure (not within
the original data record).
* Can be an alphanumeric array name defined in a File
Extension Specification. Columns 44-51 must specify the
entire length of the array. An array element cannot be
specified as a data structure subfield.
* Can be redefined as a data structure, with its own
subfields (the data structure and subfield definitions can
be nested).
* Cannot be an array element or a table.
* Cannot have the same name as a subfield in another data
structure.
NOTE The HP RPG implementation of data structures does not redefine the
same internal area multiple times as other implementations of data
structures do. This allows nesting and greater latitude in
referencing data structures within calculations.
Example
Figure 7-9 shows how to use a data structure to define subfields of
the input field PRODID. The subfields are CATALOG, VENDOR, and PRD#.
Changes to any of the subfields will automatically be reflected in the
data structure. If, for example, a calculation changes the subfield
VENDOR, PRODID also changes.
___________________________________________________________________________________
| |
| 1 2 3 4 5 6 7 |
| 678901234567890123456789012345678901234567890123456789012345678901234|
| _______________________________________________________ |
| |
| IDATA NS 01 |
| I 1 10 PRODID |
| I 11 40 DESC |
| I 41 482PRICE |
| IPRODID DS |
| I 1 2 CATLOG |
| I 3 5 VENDOR |
| I 6 10 PRD# |
| |
| |
___________________________________________________________________________________
Figure 7-9. Using a Data Structure to Subdivide an Input Field
Figure 7-10 shows how to use a data structure to consolidate two
separate fields, PROD and DSCNT. These fields contain a product number
(from an order file) and a discount code (from a customer master file).
These fields are placed together by the data structure PKEY so that they
can be used as the key field for reading another file.
___________________________________________________________________________________
| |
| 1 2 3 4 5 6 7 |
| 678901234567890123456789012345678901234567890123456789012345678901234|
| _______________________________________________________ |
| |
| ICUSTMR NS 01 |
| I 1 10 CUSNUM |
| I 11 40 CUSNAM |
| I 41 42 DSCNT |
| IORDER NS 02 |
| I 1 8 PROD |
| I 9 120QTY |
| IPRICE NS 03 |
| I 1 10 KEY |
| I 11 172COST |
| IPKEY DS |
| I 1 8 PROD |
| I 9 10 DSCNT |
| |
| |
___________________________________________________________________________________
Figure 7-10. Using a Data Structure to Consolidate Two Separate Fields