Pubsets as file containers

In BS2000 OS DX, files and job variables are stored on pubsets, as well as the associated metadata required at DMS level (e.g. file catalog, user catalog, GUARDS catalog etc.). Among other things therefore, the metadata required to address files and file contents are available on pubsets (i.e. the file catalog). A pubset therefore represents a unit in terms of the data and its associated metadata.

To be able to start a pubset on a processor, additional metadata for the pubset which is partly static and partly dynamic must be available on that processor. The metadata includes attributes such as name (= catalog ID), status, connection properties and operating parameters. These attributes are grouped together for each pubset in an entry in the MRSCAT which is stored in memory as a table during a BS2000 session. In addition, the static parts of an MRSCAT entry are also stored on the home pubset as records of the
$TSOS.SYSTEM.MRSCAT file.
A pubset is made known on or removed from a processor by adding or deleting a corresponding entry in the MRSCAT (see "Commands ").
For more detailed information on this subject, see the manuals "Introduction to System Administration" [5 (Related publications )] and "System-Managed Storage" [17 (Related publications )].

Files and job variables are addressed in two stages from one processor via MRSCAT and the file catalog TSOSCAT, as shown in figure 7 for a pubset known to two processors. This corresponds to addressing via the catalog ID (CATID) and file name with user ID.

Figure 7: Two-stage addressing of files via MRSCAT and file catalog TSOSCAT

An MRSCAT entry includes the following data which is necessary for the operation of an MSCF network:

• Catalog ID(Catid)
  The catalog ID unambiguously identifies each SF or SM pubset. Systems support is responsible for the processors in an MSCF network must ensure that the catalog IDs in that particular network are unique.

• Operating status:

  • INACC: the catalog cannot be reached from the processor.

  • QUIET: the connection to the catalog is temporarily interrupted.

  • ACCESSIBLE:
    If the catalog is accessible, sub-statuses decide how the pubset is to be operated:

    LOCAL‑HOME:	Status of the home pubset after successful system initiation. The home pubset must be available at all times during the entire session.
    LOCAL‑IMPORTED:	The pubset was put into operation as a data pubset with the IMPORT-PUBSET command. This can be done exclusively for one processor or also as a shared pubset. In the latter case, the MRSCAT is also given the specification whether the processor has assumed the role of master or slave processor.If it has become a slave processor, it is also informed of the processor name of the master processor.
    REMOTE‑HOME/ REMOTE‑IMPORTED	From a local point of view, this is a severely restricted operational startup of a pubset; the pubset is exclusively imported as the home pubset or as a data pubset or in master mode on a remote processor to which there is an MSCF connection. Only the LCS function is available.

       For further details on the operating status of shared pubsets, see "Operating states of a shared pubset " .

  • Host name:
    An MRSCAT entry is where the name of the processor that manages the pubset is stored. In INACCESSIBLE status, the name is not necessarily up-to-date. When a pubset is put into operation, the information is updated on transition to ACCESSIBLE status.

    At the interfaces for managing the MRSCAT, processors are always identified by "HOST" or "PARTNER-NAME"; in line with the terminology introduced for HIPLEX MSCF (see "Processor identification " ), this is the processor name of the processor.

  Since, in addition to the data, the processing-related metadata is also stored on the pubsets, in the case of shared pubsets there is the problem of coordination across all the processors when this data is updated. This problem is solved by the fact that the master processor is declared the owner of the metadata. Any changes to the metadata must be made via the master processor. This principle is implemented in two ways:

  • Operating system functions for updating are only available on the respective master processor.

  • On a slave processor, functions for accessing metadata are sent to the master processor as jobs. In relation to the slave processors of a pubset, the master processor therefore acts as a server when it comes to carrying out operations on the metadata of that pubset.

  It is mainly the second variant that is implemented in BS2000. For most of the interfaces relating to file management, the master/slave attributes of a processor are therefore as transparent as the shareability of a pubset.