The data management system is described in the manuals "DMS Introduction" [4 (Related publications )] and "DMS Macros" [3 (Related publications )]. Here we will just look at the special features of DMS in relation to the MSCF network.
The system parameter FSHARING is described in the “Introduction to System Administration [5 (Related publications )].
The interfaces of DMS include operations at file and at data level. A shared pubset network therefore presupposes that these interfaces are fully covered. In this environment, DMS operations are then implemented as follows:
accesses to metadata (e.g. file catalog) are carried out on the master processor
accesses to data (records, blocks) are carried out on the local processor.
This means that at file level, the entire range of functions (e.g. creation, enlarging, reducing, and deletion of files) are available as local functions. This also applies more generally to the protection of files with access profiles (GUARDS). Discrepancies only arise when opening files.
When a file is opened, a check should be made as to whether the required OPEN mode is compatible with file open operations that have already been carried out. Each opening of a file is represented by a file lock; the compatibility is checked by the "file lock manager" function unit. The file locks are also metadata which for shared pubsets is managed on the master processor. In a shared pubset network, the compatibility matrix of file locks within one processor is distinct from the compatibility matrix that relates to all the processors (see the "DMS Introduction" [4 (Related publications )], section dealing with multi-user mode). The more restricted, network-wide compatibility is because in the shared pubset network (if the sharers do not belong to the same XCS network) there is no mechanism for synchronizing access to data on all of the processors. It does not therefore make sense to allow simultaneous file updating on all of the processors.
In contrast to HIPLEX MSCF, DMS cannot distinguish a processor failure from a connection failure. From the point of view of the DMS, both events result in a loss of the connection to the master processor, and possibly to the termination of processing due to a pubset export. In the case of a lost connection, DMS waits (see also "Connection clear-down/loss in a shared pubset network "), in the case of a pubset export it terminates.
In any case, HIPLEX MSCF will periodically attempt to reestablish lost connections or change the master. It this fails, the connection remains lost for the DMS and it stays in waiting status.