Externally described DISK files are identified by an E in position 22 of the file description specifications. The E indicates that the compiler is to retrieve the external description of the file from the system when the program is compiled. Therefore, you must create the file before the program is compiled.
The external description for a DISK file includes:
These specifications result from the DDS for the file and the OS/400 create file command that is used for the file.
Record Format Specifications
The record-format specifications allow you to describe the fields in a record and the location of the fields in a record. The fields are located in the record in the order specified in the DDS. The field description generally includes the field name, the field type, and the field length (including the number of decimal positions in a numeric field). Instead of specifying the field attributes in the record format for a physical or logical file, you can define them in a field-reference file.
In addition, the DDS keywords can be used to:
This shows an example of the DDS for a database file, and Figure for a field-reference file that defines the attributes for the fields used in the database file. See the above Web site for more information on field-reference files.
The description of an externally described file contains the access path that describes how records are to be retrieved from the file. Records can be retrieved based on an arrival sequence (non-keyed) access path or on a keyed-sequence access path.
The arrival sequence access path is based on the order in which the records are stored in the file. Records are added to the file one after another.
For the keyed-sequence access path, the sequence of records in the file is based on the contents of the key field that is defined in the DDS for the file. For example, in the DDS shown in Figure CUST is defined as the key field. The keyed-sequence access path is updated whenever records are added, deleted, or when the contents of a key field change.
Example of the Data Description Specifications for a Database File
The sample DDS are for the customer master logical file CUSMSTL. The file contains one record format CUSREC (customer master record). The data for this file is contained in the physical file CUSMSTP, which is identified by the keyword PFILE. The UNIQUE keyword is used to indicate that duplicate key values are not allowed for this file. The CUST field is identified by a K in position 17 of the last line as the key field for this record format.
The fields in this record format are listed in the order they are to appear in the record. The attributes for the fields are obtained from the physical file CUSMSTP. The physical file, in turn, refers to a field-reference file to obtain the attributes for the fields. The field-reference file is shown below.
Example of a field Reference File
This example of a field-reference file shows the definitions of the fields that are used by the CUSMSTL (customer master logical) file as shown in Figure. The field- reference file normally contains the definitions of fields that are used by other files. The following text describes some of the entries for this field-reference file.
Valid Keys for a Record or File
For a keyed-sequence access path, you can define one or more fields in the DDS to be used as the key fields for a record format. All record types in a file do not have to have the same key fields. For example, an order header record can have the ORDER field defined as the key field, and the order detail records can have the ORDER and LINE fields defined as the key fields.
The key for a file is determined by the valid keys for the record types in that file. The file’s key is determined in the following manner:
The file’s key is field A–the key field common to all record types.
In an ILE RPG program, you can specify a search argument on certain file operation codes to identify the record you want to process. The ILE RPG program compares the search argument with the key of the file or record, and processes the specified operation on the record whose key matches the search argument.
Valid Search Arguments
You can specify a search argument in the ILE RPG operations CHAIN, DELETE, READE, READPE, SETGT, and SETLL that specify a file name or a record name.
For an operation to a file name, the maximum number of fields that you can specify in a search argument is equal to the total number of key fields valid for the file’s key. For example, if all record types in a file do not contain all of the same key fields, you can use a key list (KLIST) to specify a search argument that is composed only of the number of fields common to all record types in the file. If a file contains three record types, the key fields are defined as follows:
The search argument can only be a single field with attributes identical to field A because field A is the only key field common to all record types. The search argument cannot contain a floating point or null-capable field.
For an operation to a record name, the maximum number of fields that you can specify in a search argument is equal to the total number of key fields valid for that record type.
If the search argument consists of one or more fields, you can specify a KLIST, a figurative constant, and in free-form calculations only, a list of expressions (enclosed by parentheses) or a %KDS. If the search argument consists of only one field, in addition to the above, you can also specify a literal or variable name.
To process null-valued keys, you can:
For the latter two, the current value of the %NULLIND() for the search argument is used in the search.
The attributes of each field in the search argument must be identical to the attributes of the corresponding field in the file or record key. The attributes include the length, the data type and the number of decimal positions. The attributes are listed in the key-field-information data table of the compiler listing. See the example in “Key Field Information”. For search arguments in a list or %KDS used in an I/O operation in free-form calculations, the search argument only needs to match in type. Length and format may be different than the key defined in the file.
In all these file operations (CHAIN, DELETE, READE, READPE, SETGT, and SETLL), you can also specify a search argument that contains fewer than the total number of fields valid for the file or record. Such a search argument refers to a partial key.
Referring to a Partial Key
To specify a partial key, you can use a KLIST with fewer KFLD specifications. In free-form calculations, you can also use %KDS with a second parameter indicating the number of keys, or a list of expressions with as many keys as you want. For example, if the file has three keys, but you only want to specify two keys, you can specify the partial key in any of the following ways.
The rules for the specification of a search argument that refers to a partial key are as follows:
If a search argument refers to a partial key, the file is positioned at the first record that satisfies the search argument or the record retrieved is the first record that satisfies the search argument. For example, the SETGT and SETLL operations position the file at the first record on the access path that satisfies the operation and the search argument. The CHAIN operation retrieves the first record on the access path that satisfies the search argument. The DELETE operation deletes the first record on the access path that satisfies the search argument. The READE operation retrieves the next record if the portion of the key of that record (or the record of the specified type) on the access path matches the search argument. The READPE operation retrieves the prior record if the portion of the key of that record (or the record of the specified type) on the access path matches the search argument.
Record Blocking and Unblocking
By default, the RPG compiler unblocks input records and blocks output records to improve run-time performance in SEQ or DISK files when the following conditions are met:
Note: If RECNO is used, the ILE RPG compiler will not allow record blocking. However, if the file is an input file and RECNO is used, Data Management may still block records if fast sequential access is set. This means that updated records might not be seen right away.
The RPG compiler generates object program code to block and unblock records for all SEQ or DISK files that satisfy the above conditions. Certain OS/400 system restrictions may prevent blocking and unblocking. In those cases, performance is not improved.
You can explicitly request record blocking by specifying the keyword BLOCK(*YES) on the file-description specification for the file. The only difference between the default record blocking and user-requested record blocking is that when BLOCK(*YES) is specified for input files, then the operations SETLL, SETGT and CHAIN can be used with the input file and blocking will still occur. If the BLOCK keyword is not specified and these operations are used, no record blocking will occur.
You can also prevent the default blocking of records by specifying the keyword BLOCK(*NO) on the file-description specification. If BLOCK(*NO) is specified, then no record blocking is done by the compiler, nor by data management. If the keyword BLOCK is not specified, then default blocking occurs as described above.
The input/output and device-specific feedback of the file information data structure are not updated after each read or write (except for the RRN and Key information on block reads) for files in which the records are blocked and unblocked by the RPG compiler. The feedback area is updated each time a block of records is transferred.
You can obtain valid updated feedback information by preventing the file from being blocked and unblocked. Use one of the following ways to prevent blocking:
IBM - RPG Related Interview Questions
|IBM-ILE Interview Questions||IBM Informix Interview Questions|
|IBM DB2 Interview Questions||SQL Database Interview Questions|
|IBM AIX Interview Questions||SQL Interview Questions|
|AS400 Interview Questions||DB2 SQL Programming Interview Questions|
|IBM Integration Bus Interview Questions||Synopsys Interview Questions|
|Rpgle Interview Questions|
Ibm - Rpg Tutorial
Overview Of The Rpg Iv Programming Language
Rpg Programming In Ile
Program Creation Strategies
Creating An Application Using Multiple Procedures
Using Source Files
Creating A Program With The Crtbndrpg Command
Creating A Program With The Crtrpgmod And Crtpgm
Creating A Service Program
Running A Program
Calling Programs And Procedures
Rpg And The Ebusiness World
Obtaining A Dump
General File Considerations
Accessing Database Files
Accessing Externally Attached Devices
Using Workstn Files
Example Of An Interactive Application
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.