Das Deployment Cockpit ist eine komfortable grafische Benutzeroberfläche, um die TABEX Server zu definieren und parametrisieren, die für die Web-Anwendung zur Verfügung stehen sollen.

Öffnen Sie dafür die von BOI ausgelieferte Webapplikationsdatei (Datei mit Erweiterung WAR oder EAR). Klicken Sie dann auf den Button "Connection settings": Nun werden alle TABEX Server aufgelistet, die beim Login-Bildschirm angezeigt werden.

Die Parameter der einzelnen Serververbindungen werden übersichtlich und gruppiert je Verbindung angezeigt.

Folgende Parameter können für jeden TABEX-Server eingestellt werden:

• Monitor-Einstellungen (Host, Port, Timeout, ...)
• Debug-Einstellungen (Debug- und Trace-Level, Log-Pfad, ...)
• Layout-Einstellungen (Verhalten des Scrollbalken, ...)
• RACF-Monitor-Einstellungen (Host, Port, Timeout, ...)

Um sich Konfigurationsaufwand zu ersparen, können auch Defaultwerte definiert werden. Diese werden dann bei Parametern herangezogen, deren Werte nicht verändert wurden.

Die Serververbindungen können verschiedenen Gruppen zugewiesen werden. Diese Zuweisungen werden in einer übersichtlichen Matrix angezeigt. Eine Serververbindung kann mehreren Gruppen zugeordnet werden.

Während der Bearbeitung können die Definitionen zwischengespeichert werden. Dabei besteht die Möglichkeit, innerhalb der aktiven Session auf eine ältere zwischengespeicherte Definition zu wechseln (undo).

Nach Abschluss der Konfiguration kann durch Speichern der WAR- / EAR-Datei die Webapplikationsdatei inklusive der eingestellten Parameter erstellt werden.

Die vorgenommenen Einstellungen können mittels „Save configuration“ gespeichert und für das nächste Release wiederverwendet werden. Letzteres erreicht man, indem man die neue WAR- / EAR-Datei öffnet, die gespeicherte Konfiguration mittels „Open saved configuration“ wieder lädt und anschließend die neue WAR- / EAR-Datei daraus erstellt.

Für den TABEX4 Table Manager gibt es folgende Verwendungen für Kontrollparameter:

• Systemparameter
• Instanz-Parameter (nur für die Instanz-Konfiguration)
• Benutzer-Profil-Parameter (nur für Benutzer-Profile)

Eine genaue Auflistung aller Parameter und deren Beschreibungen finden Sie in BOIDOC-209a.

Wenn temporäre Einstellungen für einen Parameter möglich sind, muss das Suchpfad-Zeichen "T" das erste Zeichen in der Suchpfad-Definition für diesen Parameter sein.

Der initiale Wert des Parameters wird durch Suche des Parameters ohne das führende "T" im Suchpfad bestimmt.

Beispiel für Suchpfad "TUS": Der initiale Wert wird bestimmt durch die Suche mit dem Suchpfad "US". Dieser initiale Wert wird im Dialog zum Setzen des temporären Parameters angezeigt (zum Beispiel: setzen des Druck-Parameters).

Siehe auch:

BOIDOC-209a

Im folgenden Beispiel wird der Wert des Parameters RELOGIN abhängig vom definierten Suchpfad in den Kontrolltabellen ermittelt.

RELOGIN ist ein Schalter (Y/N), der angibt, ob ein ReLogin-Icon angezeigt werden soll oder nicht.

• Y ... ReLogin-Icon wird angezeigt.
• N ... ReLogin-Icon wird nicht angezeigt.

Default: N

Der Suchpfad in der Steuertabelle $TAB4PTC57 lautet UIS. D.h. es werden zuerst die Benutzer-Tabellen, dann die Instanz-Konfiguration und anschließend die Parameter-Tabellen nach dem Parameter RELOGIN durchsucht.

• Wird in den Benutzer-Tabellen kein Eintrag gefunden, durchsucht TABEX4 die Instanz-Konfiguration nach dem Parameter RELOGIN (in diesem Fall ist das die Tabelle $ICFG_000).
  Sie kann unter Administration/logische Instanzen/Standard Inst. bearbeiten bearbeitet werden.

• Im Alloc-Script im Unix-Verzeichis "etc" sind die Teildatenbanken der Summary-DB zu definieren mit Anweisungen:

  ALLOC FI(ddname) ...

   
• Im Sysparm der Web-Anwendung wird der DD-Name einer Datei angegeben, die die Summary-Spezifikationen enthält. Er wird in der Datei boiadmin.properties im WEB-INF Verzeichnis der Tabex-Anwendung definiert.
  Annahme: Die Datei mit den Summary-Spezifikationen soll DDDEFS heißen. Erweiterung des Sysparm um einen Eintrag "CTDD":

  vorhandene-sysparm-angaben,CTDD=+DDDEFS

   
• Die Datei (DDDEFS) muss ebenfalls im Alloc-Script eingetragen werden. Sie muss eine Textdatei mit fixer Satzlänge 80 sein:

  ALLOC FI(DDDEFS) ...

Siehe auch:

BOIDOC-201_Basis

Gültig ab TABEX4 Version 4.1.0

Für eine Chain-Summary-DB:

Zum Beispiel:

Durch den Login eines Benutzers wird eine neue TABEX4 Monitor-Session gestartet, bei der in mehreren Stufen Allokationen von Datenbanken ausgeführt werden.

Folgende Stufen der Allokation gibt es:

1. Monitor-Allokation-Skript (zOS) oder JCL-Datei (Unix, Linux, Windows)
2. Dynamische Allokations-Tabelle der Session (sysparm Einstellungen)
3. Dynamische Allokations-Tabelle des Benutzers (Benutzerprofil-Einstellungen)
4. Dynamische Allokations-Tabelle der Instanz (Instanz-Konfiguration-Einstellungen)

Durch Exit-Implementierungen sind weitere durch den Kunden definierte Allokationen möglich.

Bitte beachten Sie: Wird für einen DD-Namen eine Datei allokiert, darf weder in der gleichen noch in einer anderen Stufe eine weitere Allokation unter dem gleichen DD-Namen erfolgen.

Weitere Allokationen können in Kunden-Exits codiert werden, beispielsweise durch einen Instanz-Initialisierungs-Exit zwischen den Stufen 3 und 4.

Siehe auch: BOIDOC-209a_Config

Folgende TABEX Datenbanken und die dazugehörigen Verkettungsdatenbanken müssen in der Stufe 1 allokiert werden:

Folgende TABEX Datenbanken und die dazugehörigen Verkettungsdatenbanken müssen spätestens in der Stufe 3 allokiert werden:

Siehe auch:

BOIDOC-209a_Config

Gültig ab TABEX4 Version 4.2.0

Eintrag in Profil vom Benutzer BOI

Durch den Eintrag DYNALC = DYNALC_BOI-99999999(OPSMSG) im Profil vom Benutzer BOI wird in der Datenbank OPSMSG die Einversionstabelle DYNALC_BOI gesucht und die darin definierten Allokationen durchgeführt.

Die Struktur der Eintragungen in Einversionstabelle DYNALC_BOI sieht für zOS wie in Beispiel 1 "Monitor-Allokation-Skript für zOS aus und für Unix, Linux, Windows wie in "JCL-Datei für Unix, Linux, Windows".

Eintrag in der Instanz-Konfigurations-Tabelle

Durch den Eintrag DYNALC = DYN_INST05-99999999(OPSMSG) in der Instanz-Konfiguration der Instanz $ICFG_005 wird in der Datenbank OPSMSG die Einversionstabelle DYN_INST05 gesucht und die darin definierten Allokationen werden durchgeführt.

Die Struktur der Eintragungen in Einversionstabelle DYN_INST05 sieht für zOS wie in Beispiel 1 "Monitor-Allokation-Skript für zOS aus und für Unix, Linux, Windows wie in "JCL-Datei für Unix, Linux, Windows".

Der Betriebssystem-Login im zOS wird unter Verwendung des externen Moduls BOISUID durchgeführt. Es werden mehrere Funktionen der C Runtime-Library aufgerufen.

Endet ein Aufruf mit Fehler, so kommt es zu folgenden Meldungen:

• BRW663(E) External password check failed (error=..., reason=...)
• BRW664(I) ...

error
Die erste Nummer (error) zeigt an, welche Funktion der C Runtime-Library den Fehler gemeldet hat. Die Nummer ist zugleich die Nummer in der Aufrufsequenz im Modul BOISUID:

• 1 Parameterfehler (keine Library-Funktion)
• 2 Fehler bei Funktion __passwd
• 3 Fehler bei Funktion getpwnam
• 4 Fehler bei Funktion setgid
• 5 Fehler bei Funktion initgroups
• 6 Fehler bei Funktion setuid

reason

Die zweite Nummer (reason) zeigt die Fehlernummer (errno) der C Runtime-Library an. Die Nummern sind in der IBM-Literatur in Form symbolischer Konstanten dokumentiert, etwa als EPERM für einen Berechtigungsfehler. Die Abbildung auf Nummern, wie in reason angezeigt, erfolgt in C im Header-File errno.h. Dort ist beispielsweise EPERM als Konstante 5 definiert.

Das Programm "BOI Remote Diagnostic Tool" (boirmtdiag) kann zum Testen der Verbindung zu einem TABEX Monitor oder TABEX Callserver verwendet werden. Voraussetzung ist nur, dass sich auf dem System eine Java-VM befindet.

Dieser Test beinhaltet nicht nur den Test auf Netzwerkebene, sondern auch auf Ebene höherer Protokolle.

Aufruf von boirmtdiag

Das Programm kann aus einer command line aufgerufen werden:

java -jar boirmtdiag.jar

Optionen beim Aufruf

• Option -? zeigt den Hilfe-Bildschirm an. Dies entspricht der Ausgabe ohne Angabe von Optionen.
• Mit Option -h und -p können Host und Port des zu testenden TABEX Monitors oder TABEX Callservers definiert werden.
• Mit Option -i wird der „interaktive Modus“ eingeschaltet. Mit diesem werden die Optionen über das Terminal eingegeben. Es werden die Defaults vorgeschlagen.
• Mit Option -n wird eingestellt, wie oft die Verbindung geprüft wird (analog zu ping).
• Mit Option -l werden die TABEX Monitor-Daten abgerufen.
• Mit Option -t wird der Verbindungs-HEX-Trace eingeschaltet.
• Die Optionen -l und -t funktionieren nur bei Verbindung zu einem TABEX Monitor.

Beispiel:

java -jar boirmtdiag.jar -h myServer -p 1997 -n 5 -l -t

Erklärung:

boirmtdiag verbindet sich zu einem TABEX Monitor auf Host „myServer“ und Port 1997 und führt 5 Zugriffe aus. Zusätzlich werden die eingestellten Monitor-Parameter und ein Verbindungs-Trace ausgegeben.

Zur Fehleranalyse bei BOI werden im Normalfall folgende Informationen benötigt:

1. Log-Dateien mit Informationen zum Abbruch (Register, Aufrufkontext)
2. Formatierter Dump

Wichtig für die Analyse: alle Dateien müssen von derselben Browser-Session erzeugt worden sein.

Verzeichnis und Namen für die Log-Dateien sind durch folgende Monitor-Parameter festgelegt:
  MON-SESSION-JOBLOG-FILE
  MON-SESSION-OUTPUT-FILE
  MON-SESSION-ERROR-FILE

Mit Setzung der Standardwerte werden die Log-Dateien im Unterverzeichnis logs des TABEX4 USS-Verzeichnisses erstellt:
  MON-SESSION-JOBLOG-FILE  ?HFSP?/logs/log%u
  MON-SESSION-OUTPUT-FILE  ?HFSP?/logs/out%u
  MON-SESSION-ERROR-FILE  ?HFSP?/logs/err%u

(?HFSP? ist das TABEX4 USS-Verzeichnis und %u wird vom Monitor durch die Session-Nummer ersetzt.)

Organization: PS

Record format: VBA

Record length: 125

Block size: 1632

Regeln für die Vergabe von Tabellennamen werden mittels Prüftabelle definiert. Für die Erstellung der Prüftabelle sind folgende Schritte notwendig:

• Eintragen der Prüftabelle mit Funktion Administration / Anwendung / Allgemeine Einstellungen / Prüftabelle zuordnen

• Erstellen der Prüftabelle in Datenbank TABCNT mit den Funktionen
  TABEX Datenbank / Neu / Tabellenkopie erstellen und
  TABEX Datenbank / Verwaltung / bearbeiten ohne Datenprüfungen
  
  Der Tabellenname ist als Feld TI_TABLE, das Versionsdatum als TI_FROMDAT und die Versionsinformation als TI_INFO anzugeben.

• ENQ-Einträge sind Einträge, die im letzten Record der TABEX Datenbank gespeichert werden.
  Sie werden im Rahmen der TABEX Standard-Anwendungen als Sperreinträge für Tabellen verwendet (Details siehe unten).

• Es sind pro TABEX Datenbank maximal 215 Einträge möglich.

• ENQ-Einträge sind zur temporären Sperre vorgesehen und werden im Zuge der Datenbankreorganisation gelöscht.

• ENQ-Einträge sperren nicht automatisch, sondern müssen im Rahmen der Anwendung abgefragt werden.

• Für das Setzen, Abfragen und Löschen von ENQ-Einträgen gibt es die API-Funktionen 'BD', 'BE', 'BQ', 'BR', 'BT' und 'BU' (siehe BOIDOC-211a) bzw. die SSL-Funktion 'TABENQ' (siehe SSL-Handbuch).

• ENQ-Einträge können gruppiert werden (Details bei der Beschreibung der o.g. Funktionen).

• Im Rahmen der Browser-Tabellenverwaltung werden ENQ-Einträge automatisch mit Default-Gruppe 'TABVSAM' gesetzt.
  Bei Verwendung einer Modifikations-DB, werden ENQ-Einträge immer in die Modifikations-DB gespeichert.

• Die TABN02- bzw. TABN05-Funktionen ENQ/DEQ speichern ENQ-Einträge ebenfalls mit Default-Gruppe 'TABVSAM', aber immer in die aktive Datenbank.

• Bei TBVW01- bzw. TBVW02-Funktionen werden ENQ-Einträge wie in der Browser-Tabellenverwaltung automatisch gesetzt.

• Im Rahmen der TABEX-Console und der SSL-IDE werden keine ENQ-Einträge gesetzt.

Setzen Sie

racflogin = false

Die in früheren TABEX4 Versionen zusätzlich benötigte Started Task für RACF-Passwortprüfung (Modul BOITPSA) ist in aktuellen TABEX4 Versionen nicht mehr erforderlich. Das frühere Verfahren ist veraltet und wird nicht mehr empfohlen.

Folgen Sie den Schritten von Handbuch BOIDOC-209a_Config

Die wesentlichen Schritte

Zuerst müssen die Monitor-Module für "Program Control" nach folgendem Schema definiert werden (Eine vollständige Auflistung finden Sie in der Doku):

rdefine program ... addmem('...'/BOI001/NOPADCHK) UACC(READ)
 
... (weitere Module)
 
setropts when(PROGRAM) REFRESH

Ein einziges Modul ist im Unix-Unterverzeichnis "bin" des TABEX Verzeichnisses gespeichert und muss auf folgende Art definiert werden:

extattr +p /.../.../bin/boimprc

Das in der Doku beschriebene Recht superuser.kill wird für das Verfahren ohne Identity Change nicht benötigt, da Monitor und Session-Prozesse im System unter derselben User-ID laufen. Sie können das überspringen.

Auch das Erweitern der Berechtigungen im Unix-Dateisystem ist nicht erforderlich, wenn kein Identity Change gemacht wird.

Abschluss

ACHTUNG!

Vor Aktivierung des Identitätswechsels: Ein Tabex-Administrator, der auch das Recht hat, sich ins Betriebssystem einzuloggen, muss der Benutzergruppe :ADMIN zugeordnet werden, BEVOR der Betriebssystem-Login aktiviert wird! Sonst kann sich kein Administrator nach Aktivierung des Betriebssystem-Logins anmelden!!! In den meisten Fällen ist der TABEX Administrator ADMIN nicht auch als Betriebssystem-Benutzer definiert.

Aktiviert wird das Login-Verfahren ohne Identity Change durch Kopieren des Moduls $TABI4BMEE aus der BOI-INTMOD auf den Namen $TABI4BMEL in die vorgelagerte INTMOD. Wenn es noch Probleme mit Program Control oder Systemberechtigungen gibt, werden diese als Meldungen auf der Systemkonsole sichtbar, und normalerweise entstehen auch im Unix-Unterverzeichnis log-Dateien mit diesen Meldungen.

Siehe auch:

BOIDOC-209_Config