Public disks are grouped into volume sets or single-feature (SF) pubsets. One or more volume sets form a system-managed (SM) pubset. A multiple public volume set (MPVS) enables several pubsets to be simultaneously installed in one and the same session. Net-Storage volumes can be mounted on a pubset. However, they are not part of the pubset (IMPORT-PUBSET is also possible without mounted Net-Storage volumes).
One special pubset called the “home pubset” must always be available whenever the system is running, since it contains the data needed for loading, operating and terminating the system. The other pubsets can be imported and exported by systems support. Users' default pubsets should always be imported.
All volumes of a pubset are handled and managed by the system as a single unit. Every user who has been authorized by systems support with the ADD-USER command or the system parameter FSHARING may use any DMS function to create, process and delete files on imported pubsets.
There are two different types of pubset: SF pubset (Single Feature pubset) and SM pubset (System Managed pubset). They have different features, operating parameters and service attributes.
SF pubsets
All volumes of an SF pubset have the same physical features. An SF pubset offers a limited and homogeneous set of services.
SM pubsets
An SM pubset consists of one or more volume sets. Each volume set must be
homogeneous with respect to the features of its volumes. No file can be distributed over more than one volume set. Each volume set in an SM pubset represents a specific service type which is taken into account when the storage location is selected for a file. The selection is based on the user's specification (via the logical file attributes) of the services requested.
Pubset operating modes
Shared pubset
Where the product MSCF is used with an appropriate hardware configuration, it is possible to access a common pubset simultaneously from BS2000 systems. Up to 16 BS2000 systems can be linked in a common MSCF network, and can access this shareable pubset as „sharer“ via a direct hardware path. One of these networked processors is named as the temporary owner of the pubset, and it then manages the files, the users and the accesses
to the pubset for all the other systems. All management requests from a subordinate processor, known as a “slave sharer”, must be directed via MSCF to the owner system (the “master”). If the owner system crashes, a pubset-specific job variable is set in all the dependent systems. If a backup owner was defined by systems support with the SET-PUBSET-ATTRIBUTES command, this slave sharer can assume the role of the crashed master processor (master change). If no such backup owner is defined, systems support can then export the pubset to the slave sharer and specify a new owner in a subsequent IMPORT-PUBSET command.
The overall concept of shared pubsets (hardware configuration, pubset management and data access) is described in detail in the “HIPLEX MSCF” manual [11 (Related publications)].
XCS pubset
HIPLEX MSCF offers an enhanced network functionality: the XCS (cross-coupled system) XCS results in a closer coordination of the networked systems. Each system has a consistent and complete view of the entire network. The XCS network thus offers mechanisms for implementing distributed applications. It is primarily designed for availability and load sharing in BS2000. The XCS network thus offers mechanisms for implementing distributed applications.
Distributed lock manager (DLM):
This function implements cross-system lock management, thus supporting crosssystem synchronization and serialization. SFS (see below) is based on this function.Shared file system (SFS):
SFS permits cross-system updating of files on shared pubsets within the XCS network; the pubsets do not necessarily have to be XCS pubsets. HIPLEX MSCF supports this global shared update for both block-oriented and byte stream-oriented access methods i.e. UPAM, FASTPAM and DIV.
The following conditions apply to XCS networks:
Any one system can be part of no more than one XCS network.
The network must be fully intermeshed, i.e. all systems participating in the network must be interconnected via MSCF connections.
The XCS network must include at least one XCS pubset, and access paths to this pubset must exist from all systems in the network.
An XCS pubset is the central storage location for all data that must be accessible on a network-wide basis. XCS pubsets are automatically imported by the system.
The overall concept of the XCS network (functionality, generation and operation) is described in detail in the “HIPLEX MSCF” manual [11 (Related publications)].
Pubset copies created using SHC-OSD
Special pubset copies (mirror disks) can be created locally on the disk storage system concerned using SHC-OSD in order to back up pubsets in disk storage systems. Two variants are available:
Pubset copy created using Clone Units (e.g. for backing up a consistent status of the pubset with HSMS or FDDRL)
Pubset copy created using Snap Units, also called a Snapset (see the section "Pubsetbackup with Snapsets")
Pubset copies are permanently assigned to the pubset. The VSNs of their volumes comply with a special syntax (see "Special VSN name for pubset copies" in the next section). Only read access is permitted to these copies. For details, see the manuals “HSMS” [10 (Related publications)] and “Introduction to System Administration [7 (Related publications)].
Naming conventions for pubsets
The syntax of the names of disks assigned to a volume set/SF pubset must match that of the name of the volume set/SF pubset. A distinction must be made between single- and multiple-character volume set and pubset names:
the PUB notation must be used for single-character names
the period notation must be used for names with two to four characters.
Default names of Net-Storage volumes which are assigned to a pubset have a special format depending on the pubset notation, see "Notation of Net-Storage volumes" in the "Introduction to System Administration" [7 (Related publications)].
VSN in PUB notation
The character string “PUB” is a mandatory and invariable component of any VSN formed using this type of pubset addressing. The Term “PUB” stands for public and thus identifies the disk as a shared disk.
A VSN in PUB notation always consists of 6 characters and has the following format:
PUBpxx
| invariable component to distinguish public from private disks (3 characters “PUB”) = type identifier |
| catalog ID (catid), (1 character; A..Z, 0..9) |
| sequence number within the pubset/volume set, (2 characters; 00..31) |
Up to 36 pubsets or volume sets, comprising up to 32 disks each, can be addressed with a single-character catalog ID.
Examples: PUBA00, PUBA25, PUB502
VSN in period notation
A period is used to separate the sequence number within the pubset/volume set from the catalog ID in any VSN formed using this type of identification. A VSN in period notation always identifies a public disk.
A VSN in period notation always consists of 6 characters and has the following format:
pp[pp].[xy]z
| catalog ID (catid), (2-4 characters from the range A..Z, 0..9), the prefix “PUB” is not permissible |
. | period (1 character) = type identifier |
| sequence number within the pubset/volume set, (1-3 characters from the range 0..9) |
A pubset or volume set in period notation may include up to 255 disks.
Examples: AA.001, AB.309, XYZ.23, OTTO.0, J19P.8
The catalog ID of an SF pubset is identical with the “catid” part of the VSN. The catalog ID of an SM pubset is always different from all volume set names of this SM pubset and thus also different from the “catid” part of the VSNs of all disks of the pubset.
Special VSN name for pubset copies
The VSNs of a pubset copy created using Clone Units are formed from the original VSNs. In the case of PUB notation the “U” in the “PUB” string is replaced by a colon, and in the case of dot notation the dot is replaced by a colon.
The VSNs of a pubset copy created with SHC-OSD using Snap Units, i.e. of a Snapset, are formed from the original VSNs in accordance with the following rule:
Up to the 26th Snapset (i.e. for Snap IDs a through z):
In the case of PUB notation the “U” and “B” in the “PUB” string are each replaced by the Snapset ID in lowercase letters.
In the case of dot notation the dot is replaced by the Snapset ID in lowercase letters.
From the 27th Snapset (i.e. for Snap IDs A through Z):
In the case of PUB notation the “P” and “U” in the “PUB” string are each replaced by the Snapset ID in lowercase letters.
In the case of dot notation the dot is replaced by the Snapset ID in lowercase letters and at the same time its character position is changed:
In the case of a 4-character catid the Snapset ID is inserted after the first character of the catid.
In the case of a 3-character catid the Snapset ID is inserted before the first character of the catid.
In the case of a 2-character catid the Snapset ID is inserted as the last character of the VSN.
Examples
Volume configuration of an SF pubset:
The SF pubset with the catalog ID ABC consists of three disks.
Assuming a file whose file name is “MY.LIST” exists under user ID “MISCELLA” on any of the disks of SF pubset ABC, the path name to that file would be:
“:ABC:$MISCELLA.MY.LIST”.
An associated Snapset with the Snapset ID x would then consist of the volumes with the VSNs ABCx00, ABCx01 and ABCx02.
Volume configuration of an SM pubset:
The SM pubset with catalog ID XYZ consists of three volume sets.
Assuming a file with the file name “PHONELIST” exists under user ID “GENERAL” on any of the disks belonging to any of the volume sets of the SM pubset XYZ, the path name to that file would be: “:XYZ:$GENERAL.PHONELIST”; this means that the internal structure of the SM pubset and the exact location of the file are irrelevant for the way it is addressed.
An associated Snapset with the Snapset ID m would then consist of the volumes with the VSNs PmBA00, B12m00, B12m01, B12m02, PmBC00 and PmBC01.
User catalog
Each pubset contains a user catalog and its own file catalog.
Each entry in the JOIN file determines who, or which user ID, may access a pubset. Users who have no JOIN entry for a pubset cannot access any file in that pubset, even if such files are shareable, unless this is globally permitted by the system parameter FSHARING.
The JOIN file also defines the pubset-specific rights of each user listed in it. If the JOIN entry contains the specification PUBLIC-SPACE-LIMIT=0, for example, the user cannot create any permanent files on that pubset but may access all the shareable files cataloged in it. The creation of temporary files on the pubset may be suppressed with TEMP-SPACE-LIMIT=0 (see "Requesting storage space" for details on storage space management).
Specifying NET-STORAGE-USAGE=*ALLOWED specifies that the user may occupy storage space on Net-Storage.
Any user can obtain information about his/her JOIN file by means of the SHOW-USER-ATTRIBUTES command.