Use of the V-VERSION configuration variable sets the default format for new Vision files. New files may be created in Version 4,Version 3, or Version 2 format, depending on the value for this variable. The filename-VERSION variable allows you to set the file format on a file-by-file basis. See Appendix H in Book 4, "Appendices" for more details on these configuration variables.
On many (but not all) systems, the runtime system allows an indexed file to be opened for input when the user does not have write-access to the file.
Vision files allow up to 120 keys for sorting. One key is the primary key, all others are alternates. In a record, a key may not occupy physical space that exceeds the minimum record length. Thus, a 10-byte key cannot occupy positions 20-29 in a record with a minimum record length of 28.
You can specify whether duplicates are allowed for each alternate key. If duplicates are allowed for a particular key, it is possible to write a record whose key fields contain exactly the same data as the key fields of an existing record. In this case, the records are stored in chronological order. Primary keys do not allow duplicates.
Every alternate key causes significant additional overhead. (Keys have the least amount of overhead when duplicates are allowed to occur.) The keys for a data file are automatically stored in a compressed form.
A key may be a contiguous part of the records, or it may be split into as many as 16 segments. Note that if you are compiling for compatibility with versions earlier than Vision Version 4, you can have no more than six segments. You must use Vision Version 4 if you want more than six segments.
Suppose you have the following record structure in a file called AJAX-SUPPLIES:
01 CUSTOMER-RECORD.
03 CUSTOMER-NO PIC 9(6).
03 CUSTOMER-BALANCE PIC S9(9)V99.
03 CUSTOMER-NAME PIC X(30).
03 CUSTOMER-CONTACT PIC X(30).
To use CUSTOMER-NAME as the primary key, you would use the syntax shown in the last line below:
FILE-CONTROL.
SELECT AJAX-SUPPLIES
ASSIGN TO DISK "INDEX.DAT"
RECORD KEY IS CUSTOMER-NAME.
If data elements are contiguous and defined in the order that would be used for sorting, they may be grouped and defined together as a key. For example, suppose you wanted to use CUSTOMER-BALANCE, CUSTOMER-NAME as an alternate key. Because these two fields are contiguous and are defined in the same sequence they will be used for sorting, the most efficient way to define the alternate key is to establish a group item that includes both fields. For example:
01 CUSTOMER RECORD
03 CUSTOMER-NO PIC 9(6).
03 CUSTOMER-BALNAME.
05 CUSTOMER-BALANCE PIC S9(9)V99.
05 CUSTOMER-NAME PIC X(30).
03 CUSTOMER-CONTACT PIC X(30).
Then, to define CUSTOMER-BALNAME as an alternate key, you would use the syntax shown in the last line below:
FILE-CONTROL.
SELECT AJAX-SUPPLIES
ASSIGN TO DISK "INDEX.DAT"
RECORD KEY IS CUSTOMER-NAME
ALTERNATE KEY IS CUSTOMER-BALNAME.
Suppose now that you want to define a sort sequence that uses fields that are not contiguous, or are defined in a different order from the sorting order. In this case, you could either:
Split keys allow you to specify up to 16 segments of data elements as the components of a key. (Note that if you compile for compatibility with versions earlier than Vision Version 4, you can have no more than six segments. The 16-segment capability is available in Vision Version 4 only.) The data segments need not be contiguous and need not be listed in the order they appear within the record. The composite length of a split key cannot exceed 250 bytes, and no key can be defined beyond the minimum record length.
For example, to define an alternate key consisting of CUSTOMER-BALANCE, CUSTOMER-NAME, and CUSTOMER-NO, use the syntax shown in the last two lines below:
FILE-CONTROL.
SELECT AJAX-SUPPLIES
ASSIGN TO DISK "INDEX.DAT"
RECORD KEY IS CUSTOMER-NAME
ALTERNATE RECORD KEY IS CUSTOMER-BALNAME
ALTERNATE RECORD KEY IS BAL2-KEY =
CUSTOMER-BALANCE, CUSTOMER-NAME, CUSTOMER-NO.
In this example, BAL2-KEY is a user-defined word and is the name you would use in your READ and START statements. Note that BAL2-KEY is not defined in Working-Storage. This is the only definition of the key.
Vision files have a block size of either 512 or 1024 bytes, depending on the BLOCK CONTAINS clause. If the BLOCK CONTAINS clause is omitted, then files have 512 bytes per block. Indexed files may be assigned only to disk files.
Vision can optionally compress and/or encrypt records. Record compression uses a simple run-length compression algorithm. Encryption uses a byte transformation algorithm that is unique to every byte in the file. Encrypted files may not have records extracted by the Vision utility program vutil. Records are stored internally in the least amount of space required. Furthermore, they are packed together and span block boundaries, so no disk space is wasted.
Vision maintains a user count for each file. This count is normally zero. When a file is opened for update, then the user count is incremented; when the file is closed the user count is decremented. The user count is thus the number of currently updating processes for the file. If a program dies catastrophically, however, then the user count will not get decremented. (For a definition of "catastrophic," see section 6.7, "Exiting from ACUCOBOL-GT Programs.") This will result in the count never reaching zero. Thus, if this value is ever non-zero when there are no users active, it indicates a catastrophic program failure and suggests that corrective action may need to be taken. At the very least, the file should be checked for integrity, but depending on the program that died, perhaps more significant action should be taken. Basically a non-zero user count indicates that someone knowledgeable about the system should intervene and ensure that everything is okay. This can be used as an early warning system to head off some problems. Note that a non-zero user count is not a fatal error to Vision. It is used only as an indicator of potential problems.