Managing fields manually
Overview
This chapter describes the REDEFINE, DELETE, and RENAME commands, which allow you to redefine many field attributes, to delete a field's description and all its occurrences in the data, and to rename fields. For the complete syntax and description of the commands, see the Model 204 Parameter and Command Reference.
After creating a file and adding fields, you can perform the following field management tasks:
- Redefine fields
- Monitor field retrievals
- Deleting fields
- Renaming fields
- Reclaiming space in files
Redefining fields
The REDEFINE command and the IFRFLD Host Language Interface function allow you to alter a field definition without requiring that the file be reinitialized.
Exception: In order to redefine fields that have the OCCURS attribute, you must reinitialize the file.
The format of REDEFINE is:
Syntax
REDEFINE [FIELD] {field_desc [field_desc ...] | fieldname WITH attribute [attribute ...]}
where:
field_desc takes the form:
fieldname [(attribute [,[attribute ...]])]
- fieldname is the name of a field in the open Model 204 file.
- attribute is one of the attributes listed in Redefining fields. In the REDEFINE command, you need to specify only the attributes being changed for the field.
Example
The following command changes two attributes of the previously defined CUSTID field:
Before:
DEFINE FIELD CUSTID WITH FRV KEY
After:
REDEFINE FIELD CUSTID WITH NON-FRV NON-KEY ORDERED CHAR
Not all the field attributes that can be specified in the DEFINE command can be changed by a REDEFINE command. Redefining fields summarizes the supported options.
| Field description attribute | Abbreviation |
|---|---|
|
KEY NON-KEY |
- NKEY |
|
[NUMERIC] RANGE NON-RANGE |
NR NNR |
|
ORDERED NON-ORDERED |
ORD NORD |
|
FRV NON-FRV |
- NFRV |
|
DEFERRABLE NON-DEFERRABLE |
DEF NDEF |
|
FEW-VALUED MANY-VALUED |
FV MV |
|
UPDATE IN PLACE UPDATE AT END |
UP UE |
| LEVEL k | LVL k |
|
UNIQUE NON-UNIQUE |
UNIQ NUNIQ |
Field attributes are introduced in Field Descriptions and Attributes .
Changing a field's security level to 0 desecures the field. Refer to See Field-level security for more information.
Note: Redefining fields will take a substantial amount of CPU time. When a KEY, NUMERIC RANGE, or ORDERED attribute is changed for a VISIBLE field, Model 204 must modify the index entries that correspond to each occurrence of the field in Table B.
When a field is redefined to add an indexed attribute, every record containing that field will have its index entry in Table C or D updated.
Redefining UNIQUE fields
UNIQUE fields must be ORDERED. A field can be redefined as UNIQUE only if there are no nonunique values for that field in the file.
Redefining KEY, NUMERIC RANGE, ORDERED, or FRV fields
Model 204 adds entries to the index when the KEY, NUMERIC RANGE, ORDERED, or FRV fields are redefined. If the index fills up, Model 204 displays an error message and the redefine fails. If TBO is enabed, the field is restored to its original status. If TBO is disabled (FOPT=x'02') and the redefine fails, the file will be broken.
Redefining INVISIBLE fields
If an INVISIBLE field is redefined to change or add an indexing attribute, such as KEY, ORD CHAR, or ORD NUM, only values of the field added to the file after the redefinition are recorded in the index. Values of the field existing before the redefinition cannot be generated into the indexes.
You cannot use the REDEFINE command to add a new index to a field with the INVISIBLE attribute that is in a file that has been used, so that MSTRADD statistic value parameter is set to nonzero. For an invisible field the REDEFINE command cannot specify the KEY, ORD CHAR, and ORD NUM attribute nor the NUMERIC RANGE attribute, unless the field was originally defined with that attribute.
If an INVISIBLE field is redefined to be FRV, only values of the field added to the file after the redefinition are recorded in Table A. Values of the field existing before the redefinition cannot be generated into Table A.
Redefining NUMERIC RANGE fields
Model 204 does not allow fields that have the NUMERIC RANGE attribute to occur more than once in a record, and it does not permit the addition of subsequent occurrences to a record for NUMERIC RANGE fields. If a field is redefined to NUMERIC RANGE and Model 204 detects that it is multiply occurring, any redefinition stops. If TBO is enabed, the field is restored to its original status. If TBO is disabled (FOPT=x'02') and the redefine fails, the file will be broken.
Redefining fields with security levels
If a field that is being redefined has a security level defined for it (see See), you must have a field security level that permits some type of access.
Deleting fields
Use the DELETE FIELD command and the IFDELF Host Language Interface function to delete a field definition and all occurrences of data and indices for that field for every record in the file. The command is issued in the form:
Syntax
DELETE FIELD fieldname
where:
fieldname is the name assigned when the field was defined.
A DELETE FIELD command cannot be used to delete record security fields or sort and hash key fields. If the field being deleted is in a file that has record security, you must have record security override privileges (see See Record security). If the field has a security level defined for it, you must have a field-level security level that permits update access.
Other uses of the DELETE command are discussed in the Model 204 Parameter and Command Reference.
DELETE FIELD with date-time stamp fields
The DELETE FIELD command is prohibited for the DTSFN field in a file when the FOPT=X'10' is set.
Renaming fields
The RENAME command and the IFNFLD Host Language Interface function allow you to rename a field. The command is issued in the form:
Syntax
RENAME FIELD oldname,newname
where:
oldname is the current name of the field.
newname is the name that you want to assign.
This command is not executed if the old field name does not exist or if the new name cannot be added to the internal file dictionary, either because it already exists or because there is not enough space.
Note
If a TABLE C FULL condition occurs during the renaming of a KEY or NUMERIC RANGE field, the file is left in a broken state. This happens even if the file is a transaction back out file. To prevent this condition, issue a TABLEC command to check for available space and/or back up the file before renaming a field.
Record security fields and sort and hash key fields can be renamed. If a field that is being renamed has a security level defined for it (see See Field-level security"), you must have a field security level that permits some type of access.
The RENAME command cannot be used to rename an INVISIBLE field. If you do want to rename an INVISIBLE field, delete all occurrences of the old field and then add them to the record under the new name.