Der Shared-Pubset-Betrieb setzt die Erfüllung folgender Bedingungen voraus:
Der Pubset muss sich auf Geräten befinden, zu denen die Rechner direkte Hardwarepfade besitzen.
Eine ausgewogene Konfiguration muss vorliegen.
Ein leistungsschwacher Master-Rechner mit eventuell mehreren leistungsstärkeren Slave-Rechnern, die zudem auch noch hohe DVS-Verwaltungslast (z.B. Open/Close) erzeugen, ist als falsch konfigurierter Shared-Pubset-Verbund zu werten. Aus Performancegründen soll bei hoher DVS-Verwaltungslast möglichst der Rechner als Master-Rechner bestimmt werden, auf dem die höhere DVS-Verwaltungslast zu erwarten ist.Anzahl der MSCF-Servertasks
Eine hohe DVS-Verwaltungslast kann zu einer Vermehrung der MSCF-Servertasks führen. Um ein unbegrenztes Anwachsen der Servertask-Anzahl zu vermeiden, muss eine Maximalanzahl für Servertasks festlegt werden. Beim Erreichen dieser Schranke wird die DVS-Verwaltungslast vom System automatisch eingeschränkt, ein Umstand, der sich durch eine deutlich verschlechterte Performance bemerkbar macht. Leistungsfähige Konfigurationen erlauben, eine höhere Grenze für die Servertask-Anzahl festzulegen. Dies geschieht in der MSCF-Konfigurationsdatei mit dem Kommando SET-MSCF-ENVIRONMENT, Operand SERVER-TASK-LIMIT. Bei der Entscheidung über die Maximalanzahl der Servertasks (siehe MSCF-Konfigurationsparameter SERVER-TASK-LIMIT (Globale Steuerungsparameter )) spielt auch eine Rolle, wie viele Tasks bzw. Systemtasks im gesamten System zugelassen sind.Robustheit der Plattenüberwachung
Als Shared-Pubsets sollten grundsätzlich die zuverlässigsten Platten (im Hinblick auf Platten-Ein-/Ausgaben) verwendet werden.
Für jeden Shared-Pubset wird ein gesondertes Plattenprotokoll geführt, egal, ob es sich bei dem Shared-Pubset um einen SF- oder einen SM-Pubset handelt. Somit ist jeder Shared-Pubset ein gesonderter Überwachungspfad, ein Umstand, der die Robustheit der Plattenüberwachung bestimmt.Das SM-Pubset-Konzept erlaubt, alle Shared-Pubsets zu einem einzigen Shared-Pubset zusammenzufassen. Diese Lösung läuft jedoch der Anforderung nach einer robusten, ausfallsicheren Plattenüberwachung zuwider. Es wird empfohlen, mindestens zwei auch physikalisch getrennte Shared-Pubsets (d.h. getrennte Kanal-Pfade, Platten-Controller etc.) zu verwenden.
Für alle Rechner, die auf einen Shared-Pubset zugreifen, wird empfohlen, identische Speicherplatz-Sättigungsstufen (im MRSCAT) zu setzen, da andernfalls ein Master-Wechsel zu Problemen führen kann.
Systemparameter TEMPFILE
Soll mit temporären Dateien (TEMPFILES) bzw. mit Jobvariablen gearbeitet werden, so müssen alle dem Verbund angehörenden Rechner dies tun. Arbeiten sie mit TEMPFILES, müssen gleiche Präfixe definiert sein.Systemparameter FSHARING
Dieser Zugriffsschutz für Pubsets muss bei allen Rechnern, die auf einen Shared-Pubset zugreifen, übereinstimmen (siehe Handbuch „Einführung in die Systembetreuung“ [5]).SYSEAM auf Shared-Pubsets
Die Unterstützung von SYSEAM-Dateien auf Shared-Pubsets hängt von der Einstellung des Systemparameters EAMSPVS ab:
Einstellung „00“: Der Rechner darf SYSEAM-Dateien auf den Shared-Pubsets einrichten, deren Master er ist.
Einstellung „01“: Der Rechner darf SYSEAM-Dateien auf allen Shared-Pubsets einrichten.VM-Betrieb mit Shared-Pubset
Wird ein Shared-Pubset an zwei Gastsystemen desselben Hypervisors importiert, so müssen die Volumes des Shared-Pubsets in der VM als „shared“ definiert sein. Daraus folgt, dass jede Ein-/Ausgabe auf diesen Platten zwei Hypervisor-Unterbrechungen verursacht. Bei hoher Ein-/Ausgabelast kann dadurch die Leistungsfähigkeit des gesamten VM-Rechners erheblich beeinträchtigt werden.System-Dateien auf Shared-Pubsets
Meldungsdateien, SDF-Syntaxdateien, SM2-Messwertdateien und POSIX-Dateisysteme (außer /root und /var) können auf Shared-Pubsets liegen.
Andere Dateien, die von Systemtasks belegt werden (z.B. Abrechnungsdateien), sollten nicht auf einen Shared-Pubset gelegt werden, da das Exportieren des Shared-Pubsets und damit die Rekonfiguration des Shared-Pubset-Verbunds dadurch evtl. verhindert wird.