Vision files have a block size (physical record size) of between 512 and 8192 bytes (in 512 byte increments). The block size specifies how large a node is in the Vision index tree. The block size of Vision Version 2, 3 or 4 files is restricted to 1024 bytes. The block size is specified by the BLOCK CONTAINS clause. If the BLOCK CONTAINS clause is omitted, the file contains 512 byte blocks. See BLOCK CONTAINS Clause for more information.
Each index node holds a number of key entries and pointers to other nodes or record data. The larger the block size, the more key entries each node can store. Also, larger block sizes produce shorter index trees. However, larger index nodes can cause Vision to spend more time performing linear searches of each node to find the desired key entry. Therefore, it is important to determine the optimal block size for your particular key and data structure. If you have very large keys, a larger block size can help keep the tree height manageable. If you have smaller keys, a large block size will produce a short tree, but performance may be lost in the time it takes Vision to scan each of the large nodes.
Some experimentation will help you determine the optimal block size for your application and hardware. In the past, Vision has used 512 and 1024 byte block sizes. Users have reported good results with these values. If your keys are small- or medium-size, try using the 512 or 1024 block sizes. If you have a file with large keys and you are using Vision 5 or Vision 6 files, you might want to experiment a larger block size.
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. Compression is discussed in more detail in Compression.
Vision maintains a user count for each file. This count is normally zero. When a file is opened for update, 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, the user count will not get decremented. This results in the count never reaching zero. Thus, if the value is non-zero when there are no active users, 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. See Exiting From ACUCOBOL-GT Programs for a definition of catastrophic.