If systems support has granted a user the right to cache his or her files, the user can identify his or her I/O-critical files by means of appropriate file attributes. Files to be identified in this way should be selected with the specific aim of reducing I/Os, i.e. the files selected should be those which exhibit an above average share of DMS I/Os (the SM2 monitoring system can be used as a decision-making tool here).
Users can assign the attributes PERFORMANCE, USAGE and DISK-WRITE to their selected files by means of the commands CREATE-FILE, MODIFY-FILE-ATTRIBUTES, and ADD-FILE-LINK, or the FILE and CATAL macros.
The PERFORMANCE file attribute describes the weight (i.e. importance) of the required improvement in I/O performance and can be assigned the following values:
STD
The file is to be processed without caching.HIGH
The file is to be processed using a cache, but may be partially migrated if memory is scarce. This specification will only be effective if CONCURRENT-USE or EXCLUSIVE-USE authorizations have been entered for the user ID in the user catalog of the pubset.VERY-HIGH
The file is to be permanently maintained in the cache even if memory is scarce. This specification is only effective if EXCLUSIVE-USE authorization has been entered for the user ID in the user catalog of the pubset.USER-MAXIMUM
The file is to be given the highest I/O attribute that is entered for the user in the user catalog.
The file attribute USAGE indicates the caching mode and can be specified with the following values:
READ
The enhanced performance requirements are for read operations only (read cache).WRITE
The enhanced performance requirements are for WRITE operations only (write cache).READ-WRITE
The requirements are for both READ and WRITE operations (read-write cache).
The file attribute DISK-WRITE specifies the point in time at which data must be in a consistent state following a write operation. This operand allows the user to implicitly indicate that his or her files are to be processed in a secure, nonvolatile cache medium.
IMMEDIATE
The data in the file must be in a consistent state as soon as a write operation is completed, which implicitly means that the file should not be processed via a volatile write cache. The data is to be written back to a secure, nonvolatile medium. Immediate data consistency after every write operation should therefore be requested for files which contain important data.From BS2000 OSD/BC V11.0 onwards, non-volatile cache media are no longer supported.BY-CLOSE
Data consistency for the file is not required until after CLOSE processing; the user forgoes processing in a nonvolatile storage medium.
It should be noted in this case that when a file is processed via a volatile write cache, the data contained in the file will not be in a consistent state until after CLOSE processing. System errors that occur during the processing phase could thus lead to inconsistencies.
Therefore only files which are relevant to the current application only should be assigned this attribute (e.g. compilation result lists).
The user can assign the required file attributes either statically or dynamically. File attributes are assigned statically via the CREATE-FILE and MODIFY-FILE-ATTRIBUTES commands or the CATAL and FILE macros. Only users with the file owner's access rights in the user catalog can create the appropriate catalog entry. If the required authorization is not available, the file is assigned the maximum performance attribute that is possible for the user ID.
Another option available to the user is to disable the attribute stored in the catalog entry for special file processing without modifying the catalog entry itself (dynamic assignment of file attributes). The weight of the PERFORMANCE and USAGE file attributes can be reduced by the ADD-FILE-LINK command or via the FCB interface. Here the file attributes stored in the file catalog are left unchanged.
The current performance attributes are evaluated by DMS when opening the file. Specifications in the catalog entry, dynamically defined values, and the authorization in the user catalog are all compared at this time. Simultaneously a further check is made to ensure that the user's specifications are compatible with the applicable cache assignment of the pubset in question. If all values are compatible, the file is processed in the cache; otherwise, no cache is used. Inappropriate authorization or incompatible configurations do not result in the OPEN being rejected.
The following table shows the interactions between systems support specifications for the user ID in the user catalog and those of the user for his/her files:
Cached files | Authorization in the data pubset | Performance attributes permitted to the user on this data pubset |
|---|---|---|
BY-USER-SELECTED | NONE | None |
CONCURRENT-USE | File attribute PERFORMANCE=HIGH | |
EXCLUSIVE-USE | File attribute PERFORMANCE=HIGH/VERY-HIGH | |
ALL / BY-SYSTEM | NONE | File attribute PERFORMANCE=HIGH |
The START-FILE-CACHING command can be used to start caching for files that are already open. The PERFORMANCE and USAGE operands are used to determine the file's performance level and cache mode characteristics. The preconditions for the activation of caching for files that are already open are:
the caller must possess access authorization to the file (file owner or systems support)
the pubset on which the file is located must
possess a valid, activated cache allocation
be locally accessible
the command must be issued on the same system if the cache assigned to the pubset is operated on the local system
the necessary cache authorization must have been granted to the caller by systems support
If the file is already open or is already being processed with caching then the START-FILE-CACHING command is rejected.
The STOP-FILE-CACHING command terminates caching for an open file or a file for which data is still present in the cache. Data that is still present in the cache is written back (exception: read-only cache) and the cache contents are invalidated. The same conditions as for START-FILE-CACHING apply to command execution.