WIKI Suche

TABEX4 WIKI

Allgemeine Fragen zu TABEX4

Was muss ich beim Release-Wechsel beachten?

Einleitung

Beim Upgrade auf ein neues TABEX4 Release, beim Einspielen von Fixes und während der Konfiguration tauchen immer wieder Fragen zu Steuertabellen auf.

In diesem Artikel stellen wir Ihnen das Konzept und die Vorgangsweise in den einzelnen Fällen vor.

TABEX Konzept für das Upgrade der Steuertabellen

In TABEX4 ist eine strikte Trennung zwischen Kundensteuertabellen und Systemsteuertabellen implementiert.

Dieses Konzept erlaubt den problemlosen Wechsel auf neue Releases. Außerdem schafft es Sicherheit für den Kunden bei der zur Konfiguration des Produktes notwendigen Bearbeitung von Steuertabellen.

Systemsteuertabellen werden nur von BOI gepflegt und sind immer in den BOI-Datenbanken gespeichert. In vorverketteten Kundendatenbanken dürfen Systemsteuertabellen nur nach Anweisung durch den BOI-Support eingespielt werden.

Kundensteuertabellen sind im Produkt-Auslieferungsstand vorerst ebenfalls nur in den BOI-Datenbanken gespeichert. Sie sind dort entweder leer oder beinhalten Beispieleinträge.

Vorgangsweise bei der Konfiguration

Kundensteuertabellen werden üblicherweise im Administratormenüpunkt „Steuertabellen bearbeiten“ des TABEX4 Table Managers gepflegt.

Für einige Steuertabellen sind auch eigene Menüpunkte vorhanden. Ein Beispiel hierfür ist „Administration → Datenbanken  → TABEX Datenbank  → Datenbankverwendung bearbeiten“.
Auch einige Funktionen der Admin-GUI ändern Kundensteuertabellen.

Nach Bearbeitung einer Kundensteuertabelle mit einer der oben angeführten Methoden wird diese Tabelle in der vorverketteten Kundendatenbank gespeichert.

Beim Laden der Steuertabelle durch die Anwendung hat die Kundendatenbank Vorrang vor der BOI-Datenbank, sodass die Kundenanpassungen wirksam sind und die Originaltabelle unwirksam.

Alle nicht im Namensschema von BOI enthaltenen Tabellen sind ebenfalls Kundentabellen.

Auch sie können mit dem Administratormenüpunkt „Steuertabellen bearbeiten“ editiert werden. Dazu müssen sie lediglich in eine Tabellenliste eingetragen werden. Hierfür stehen die Administratormenüpunkte „Kundensteuertab. einfügen“ und „Kundensteuertab.-Texte einf.“ bereit.

Vorgangsweise beim Release-Wechsel

Beim Release-Wechsel werden die BOI Datenbanken und damit alle Systemsteuertabellen ausgetauscht.

Unsere Empfehlung ist, die Kundensteuertabellen in den vorverketteten Datenbanken weiterzuverwenden, damit die gesamte Konfiguration im neuen Release wieder wirksam ist.

Manchmal erfordert ein Release-Wechsel Anpassungen an den Kundensteuertabellen. Diese können mit dem Batch-Job ADAPTCTL weitgehend automatisiert erledigt werden.

Das Verfahren erlaubt auch das Überspringen von Releases, ohne jedes Zwischen-Release temporär installieren zu müssen.

In seltenen Fällen sind zusätzlich manuelle Anpassungen an Steuertabellen erforderlich.

ADAPTCTL und die manuellen Anpassungen sind im Handbuch zum Release-Wechsel der jeweiligen Version, BOIDOC_250…, beschrieben.

Wichtig: Beim Überspringen von Releases müssen manuelle Anpassungen aller Zwischen-Releases ebenfalls durchgeführt werden.

Vorgangsweise bei Vorab-Erweiterungen und Fixes

Anpassungen zum installierten Release, die von BOI in Form von Steuertabellen und Programmtabellen bereitgestellt werden, sollen beim Kunden vorerst immer in die vorverketteten Datenbanken eingespielt werden.

Sollte der Test der Anpassung in der Kundenumgebung nicht erfolgreich verlaufen, kann die Anpassung durch Löschung aller eingespielten Tabellen aus den vorverketteten Datenbanken sehr einfach wieder rückgängig gemacht werden.

Wichtig: Nach erfolgreichem Test müssen die übermittelten Systemsteuertabellen von den vorverketteten Datenbanken in die dahinter verketteten BOI-Datenbanken verschoben werden. Dieser Schritt ist notwendig, um Probleme beim nächsten Release-Wechsel zu vermeiden.

Würden die Systemsteuertabellen in den vorverketteten Kundendatenbanken verbleiben, hätten sie im neuen Release Vorrang gegenüber den neuen und möglicherweise geänderten Systemsteuertabellen von BOI. Diese Situation kann verschiedenste Funktionsstörungen zur Folge haben und ist mühsam zu bereinigen.

Die Funktionalität von Vorab-Erweiterungen und Fixes, die für ein bestimmtes Release bereitgestellt wurden, wird in den neuesten Entwicklungsstand bei BOI aufgenommen und ist dadurch im kommenden Release automatisch wirksam.

Handelt es sich bei der beim Kunden installierten Version nicht um das letzte Release, so ist die Anpassung in aller Regel für die schon freigegebenen Folgereleases nicht verfügbar, sondern wird erst im kommenden Release wirksam.


Siehe auch:

BOIDOC-250...

Was sind TABEX Views?

TABEX Views sind Views auf Daten relationaler Datenbanken oder TABEX-Datenbanken.

TABEX Views werden definiert durch Angabe eines SELECT-Statements analog zu Views in relationalen Datenbanken.

Um einen TABEX View auf eine Tabelle einer relationalen Datenbank definieren zu können, muss die Tabelle als SQLT-Tabelle vorliegen.
SQLT-Tabellen sind TABEX-Tabellen, welche eine Verbindung zu einer relationalen Datenbank aufweisen.

Soweit als möglich entsprechen die SELECT-Statements eines TABEX Views in Syntax und Möglichkeiten den SELECT-Statements von Views relationaler Datenbanken.


Beispiel:

SELECT STAT_CODE,STAT_NAME,CONT_NAME
FROM STATES
LEFT JOIN CONTINENTS
ON STATES.CONT_CODE=CONTINENTS.CONT_CODE
WHERE CONTINENTS.CONT_CODE='EU'


Hinweis: Views können nicht bearbeitet werden. Sie dienen ausschließlich Ansichtszwecken.


Siehe auch:

BOIDOC-201_Basis

Wie funktioniert die SHS-Archivierung?

Um für Anwendungsprogramme immer einen konsistenten Tabellenstand im Dataspace verfügbar zu haben, erfolgt das Neuladen des Dataspace mit Hilfe eines zusätzlichen Work-Dataspace.

Nach erfolgreichem Laden der aktuellen Tabellen in den Work-Dataspace wird dieser per sogenanntem „Switch“ aktiviert: Work-Dataspace und bisher aktiver Dataspace werden vertauscht.

Nach dem Switch wird die SHS-Archivierung gestartet, in deren 1. Stufe ein Dataspace-Änderungsprotokoll gespeichert wird.

Protokolliert wird, welche Änderungsaktion (Daten geändert, Definition geändert, Tabelle gelöscht, ...) sich für welche Tabelle aus dem Neuladen ergeben hat.

Mit der optionalen 2. Stufe werden alle geänderten und neu geladenen Tabellen in einer Archivdatenbank gespeichert.

Mit Hilfe spezieller Auskunftsfunktionen kann später der zu einem angegebenen Zeitpunkt aktive Stand von Tabellen abgefragt und angezeigt bzw. gelistet werden.

Was ist TABEX4 JAVA ACCESS Remote Connection Factory?

Lastverteilung und Ausfallsicherheit

Mit den TABEX4 JAVA ACCESS Produkten TABEX4 JAVA ACCESS flexible und TABEX4 JAVA ACCESS unlimited wird gleichzeitig die sogenannte TABEX4 JAVA ACCESS Remote Connection Factory bereitgestellt, mit deren Hilfe Lastverteilung und Ausfallsicherheit von Datenzugriffen aus Anwendungen implementiert werden können.

 

Überblick über die Remote Connection Factory

Einen Überblick über die Remote Connection Factory finden Sie in folgendem PDF:

TABEX4 Java Access & Remote Connection Factory

 

Einschränkungen

  • Nur TABEX APIs für den lesenden Zugriff über TCP/IP können aufgerufen werden.
  • Dieses Interface ist nicht geeignet für die Änderung von Daten.
  • Die Daten, auf die zugegriffen werden sollen, müssen auf allen teilnehmenden Call Servern (Services BOITPSV) identisch sein. Dies kann z.B. durch Replikation gewährleistet werden.

Welche Application Server werden unterstützt?

TABEX4 unterstützt folgende Application Server (jeweils die von den Anbietern gewarteten Versionen):

  • Apache Tomcat
  • IBM Websphere
  • JBoss


Voraussetzung für den TABEX4 Table Manager
Eine Servlet-/JSP-Engine muss installiert sein.

Mindestanforderung:

  • Servlet 2.5
  • JSP 2.1

 

Bekannter Fehler in Tomcat
Ein Fehler im JSP-Compiler des Servlet-Containers von Tomcat bewirkte, dass im Hauptbereich des TABEX4 Table Manager kein Inhalt angezeigt werden konnte.

Folgende Tomcat-Versionen sind von dem Fehler betroffen:

  • 8.0.8 (fixed in 8.0.9)
  • 7.0.54 (fixed in 7.0.55)

Bug-Link: https://issues.apache.org/bugzilla/show_bug.cgi?id=56561

Welche Möglichkeiten gibt es, um Tabellendaten zu prüfen?

In TABEX4 gibt es mehrere Mechanismen zur Prüfung von Tabellendaten:

  • Prüfungen mittels Prüftabellen
  • Prüfung der referentiellen Integrität (RI-Prüfung)
  • Key-Prüfungen
  • Feldprüfungsroutinen

Prüfungen mittels Prüftabellen

Prüfregeln für Daten können in Form sogenannter Prüftabellen definiert werden.

Mithilfe dieser Prüftabellen kann z.B. die Eingabe von Daten auf bestimmte Werte bzw. Wertebereiche eingeschränkt werden.

Eine große Anzahl von Prüfoperatoren erlaubt die Implementierung beliebiger Prüfsequenzen.

Prüfungen, die über die Möglichkeiten der Standard-Prüfoperatoren hinausgehen, können Sie mit Programmen realisieren, die über einen Exit-Operator aufzurufen sind. Auch externe Prüfprogramme können aufgerufen werden.

Bei einer Regelverletzung ist das Speichern der geänderten Tabelle nicht möglich, und es wird eine Meldung angezeigt.

 

Beispiel einer einfachen Prüftabelle:

CNTFIELDCNTOPCNTV1CNTV2
 M6MYMSGTABMSG001
PRODNRGL10009999
 M6MYMSGTABMSG002
PRODNAMEN  

In diesem Beispiel werden die Inhalte der beiden Felder PRODNR (Produktnummer) und PRODNAME (Produktname) geprüft.

Der Inhalt des Feldes PRODNR muss >= 1000 und <= 9999 sein. Ist das nicht der Fall, so wird eine Meldung mit Schlüssel MSG001 in einer Meldungstabelle MYMSGTAB gesucht und diese Meldung dann ausgegeben.
Weiters darf das Feld PRODNAME nicht leer sein. Ist das Feld leer, so wird eine Meldung mit Schlüssel MSG002 in einer Meldungstabelle MYMSGTAB gesucht und diese Meldung dann ausgegeben.

Eine detaillierte Beschreibung der Prüftabellen finden Sie in unserer Dokumentation BOIDOC-201, Abschnitt "Checking the Input (Check Tables)" von Kapitel „Table types“.

Prüfung der referentiellen Integrität (RI-Prüfung)

Die RI-Prüfung stellt die Konsistenz der Daten im zugrunde liegenden Datenmodell sicher.

Einerseits können keine Werte eingetragen werden, die in zugeordneten Parent-Tabellen nicht vorhanden sind (Join-Prüfung).

Andererseits wird das Löschen von Schlüsselwerten verhindert, wenn diese in Child-Tabellen noch vorkommen (Delete-Rule).

Bei einer Regelverletzung wird eine Meldung angezeigt und die Daten können nicht gespeichert werden.

Key-Prüfungen

Die Eindeutigkeit von Schlüsselfeldern wird überprüft. Ist der gleiche Schlüsselwert mehrfach vorhanden, kann die Tabelle nicht gespeichert werden.

Feldprüfungsroutinen

Für Felder können eigene Prüfroutinen erstellt werden, die beim Speichern ausgeführt werden.

Die Prüfroutine wird durch ein Kennzeichen in der Felddefinition festgelegt. (Siehe BOIDOC-201, chapter „Field definitions“, Beschreibung für FLD_VERI in den Felddefinitionen.)

Standardmäßig sind Feldprüfungsroutinen Entries eines SSL-Programmes mit Namen $TBXC_$FDV.

Der aufgerufene Entry ist ENT_x, wobei „x“ der in FLD_VERI definierte Buchstabe ist.

Die zu definierenden Entry-Parameter sind ebenfalls in Kapitel „Field definitions“ von BOIDOC-201 beschrieben.

 

Siehe auch:

BOIDOC-201_Basis

Was ist die SHS-Adressierungstechnik?

Die SHS-Adressierungstechnik erlaubt das zentrale Speichern von Daten im Hauptspeicher und den gemeinsamen Zugriff auf diese zentral geladenen Daten durch mehrere Anwendungen.

Als zentrale Speicherbereiche werden Common Dataspaces im Fall von z/OS bzw. Shared Memory im Fall von Unix, Linux und Windows verwendet.
Als allgemeiner TABEX4 Begriff wird „SHS-Datenbereich“ bzw. „Dataspace“ benutzt.

Die zentrale Speicherung garantiert, dass ein und dieselbe Kopie einer Tabelle in unterschiedlichen Anwendungen adressiert wird.
Außerdem muss aus den Anwendungen kein Datenbankzugriff erfolgen.

Anwendungen können deshalb hochperformant und speicherschonend auf die Daten zugeifen.

Im z/OS nutzt TABEX4 die Enterprise System Architecture (ESA) von IBM:

Mit der Einführung der Enterprise System Architecture durch IBM wurde der Einsatz von Dataspaces neben den Address Spaces möglich.

TABEX nutzt seither diese zusätzliche Funktionalität dahingehend, dass es Tabellen in Dataspaces laden und diese bei lesenden Zugriffen aus Anwendungen adressieren kann.

So lässt sich die Zugriffsperformance durch die gemeinsame Nutzung von im Speicher geladenen Tabellen durch mehrere Anwendungs-Regions wesentlich steigern.

 

Folgende Möglichkeiten ergeben sich durch die Verwendung der SHS-Technologie in TABEX4:

  • Lesende Zugriffe mit High-Performance-Calls
  • Das Befüllen bzw. Reorganisieren von Dataspaces kann ohne Auswirkung auf Anwendungen durchgeführt werden (unterbrechungsfreier Switch zwischen aktivem Dataspace und Work-Dataspace nach dem Ändern oder Reorganisieren von Daten).
  • keine Synchronisation erforderlich
  • Getrennte Dataspaces für die verschiedenen integrierten Gesellschaften (Mandantenfähigkeit) analog zu IMS und DB2
    Zur Mandantentrennung werden unterschiedliche Suchpfade und Projektkennungen verwendet.
  • Mehrere Dataspaces können parallel aktiv sein und mit unterschiedlichen Tabellen befüllt werden.
    Durch anwendungsspezifische Pfadangaben (diese definieren den Suchpfad) und Projektkennungen kann die Reihenfolge der Suche z.B. für Instanzen, Mandanten, verschiedene Umgebungen etc. gesteuert werden.
  • Durch die Adressierung jeder Tabelle mittels Name, Datum und File-ID ist neben der Versionierung auch die Abbildung der IT-Organisation durch organisatorische Zugriffssteuerung des Kunden möglich.
    Über die zusätzliche Projektkennung können unterschiedliche Instanzen oder Teststufen abgebildet werden. Es wird sichergestellt, dass immer auf die richtige Version der Tabellen zugegriffen wird.

Organisation und Verwaltung der SHS-Dataspaces

Unter einem Subsystem mit 4-stelliger Subsystem-ID können bis zu 16 Dataspaces angelegt werden. Die TABEX-Namen der Dataspaces sind einstellig (Ziffern oder Großbuchstaben).

In z/OS müssen die Subsysteme im Betriebssystem eingetragen werden. Ein diesem Subsystem zugeordneter Holder-Task erzeugt die Dataspaces und sichert die Erhaltung derselben zur Nutzung in Anwendungen und TABEX4 selbst. Mit MVS-Modify-Befehlen oder TABEX-Utility-Befehlen können Dataspaces gelöscht und angelegt werden.

In anderen Betriebssystemen als z/OS erfolgt die Verwaltung der SHS-Dataspaces mit dem TABEX Utility TABN14.

Die Holder-Tasks für SHS-Dataspaces sind für den 24-Stundenbetrieb ausgelegt und sollten NIE gestoppt werden! Sonst sind Datenräume unerwartet nicht mehr für Anwendungen verfügbar, was diverse Exceptions zur Folge hat und den Betrieb aller (!) Anwendungen unterbricht, die auf TABEX4 Dataspaces zugreifen!

Laden von Tabellen in SHS-Dataspaces

Die Dataspaces S und 0 haben spezielle Bedeutung:

  • S ist als Statistik-Dataspace definiert. In diesem werden Zugriffszähler gespeichert.
    Aktivierung, Deaktivierung und Auswertung der Statistikzähler können mit dem Utility TABN04 durchgeführt werden.
  • 0 ist der Work-Dataspace. Dieser wird verwendet, um beim Neuladen bzw. Nachladen von Daten einen unterbrechungsfreien Zugriff auf die Daten zu gewährleisten.

Beim Neuladen wird dabei zuerst der Work-Dataspace mit den neuen Daten geladen. Ist dieser Ladevorgang abgeschlossen, erfolgt das Aktivieren des neuen Datenbestandes durch Switch (Namensaustausch) zwischen Work-Dataspace und aktivem Dataspace (z.B. Dataspace 1).

Wird der Work-Dataspace für mehrere numerische Dataspaces verschiedener Größe verwendet, muss er vor dem Ladevorgang in der jeweiligen Größe neu erstellt werden.

Auch wenn die Dataspaces gleich groß sind, empfehlen wir das Neuanlegen vor jedem Ladevorgang, bei dem ein Switch ausgeführt wird, da durch den Switch auch die Belegungszuordnung für das 'paging' übertragen wird.


Beispielablauf TABN04-Utility für z/OS:

  • Neuerstellen des Work-Dataspace
    S,TABXESA,CRE0FOR1,,TBX1,0
  • Verbindung zum Work-Dataspace von Subsystem TBX1 herstellen
    *,TBX1,0
  • Initialisieren des Work-Dataspace
    I
  • Laden der Tabellen (ein oder mehrere Ladebefehle)
    L,....

    ...

    L,....
  • Aktivieren Work-Dataspace als Dataspace 1
    A,1

Das Nachladen einzelner Tabellen kann mit TABN04, Befehl N direkt in den Dataspace erfolgen.

Die 'alte' Tabelle wird nach dem Laden der neuen Tabelle mit einem Delete-Flag versehen, der Speicher aber physisch nicht freigegeben.


Beispielablauf TABN04-Utility:

  • Nachladen einer Tabelle in Dataspace 1
    X,TBX1,1

    N,.....

Muss der Dataspace reorganisiert werden, ist wieder der Work-Dataspace zu verwenden.

Man kann z.B. TABN04-SHSOCC verwenden, um über Job-Steuerung abhängig von der Dataspace-Belegung in % das Reorganisieren aufzurufen.


Beispielablauf Reorganisieren für z/OS:

  • Neuerstellen des Work-Dataspace
    S,TABXESA,CRE0FOR1,,TBX1,0
  • Verbindung zum Work-Dataspace von Subsystem TBX1 herstellen
    *,TBX1,0
  • Initialisieren des Work-Dataspace
    I
  • Kopieren des aktiven Dataspace in den Work-Dataspace
    E,1
  • Reorganisieren des Work-Dataspace
    R
  • Aktivieren Work-Dataspace als Dataspace 1
    A,1

 

Steuerung der Tabellenzugriffe auf SHS-Dataspaces


Um zu steuern, in welcher Reihenfolge die Dataspaces nach den aufgerufenen Tabellen durchsucht werden, sind folgende SHS-Pfadangaben zu setzen:

  1. Subsystem-ID
  2. maximal 10 Dataspaces in der gewünschten Suchreihenfolge.
  3. Projektkennung, um zwei oder mehrere Umgebungen, Mandanten, Teststufen u.dgl. abzubilden. Dazu können gleichnamige Tabellen unter verschiedenen Kennungen geladen werden. Über die Projektkennung wird festgelegt, nach welchen Kennungen in welcher Reihenfolge gesucht wird.


Je nach Systemumgebung gibt es verschiedene Möglichkeiten, die SHS-Pfadangaben zu spezifizieren:

  • im z/OS Batch als Programm namens TABEXSSI, welches die Angaben an den Aufrufer (= TABEX4-Zugriffslogik) retourniert
    Ein Beispiel-Sourcecode (Assembler) für dieses Programm wird mit TABEX4 mitgeliefert.
  • in Non-Mainframe-Umgebungen als Umgebungsvariable BOICLSSI
  • im CICS als Steuerungsangaben beim Start des Zugriffssystems durch die TABEX4-Starttransaktion
  • generell per Funktionsaufruf im Anwendungsprogramm

Für jedes Subsystem muss ein Holder-Task (TABEX-Utility TABN14) laufen, der die Verwaltung der Subsysteme und Dataspaces übernimmt.

Dieser ist für den 24-Stundenbetrieb ausgelegt und sollte NIE gestoppt werden!

Sonst sind Datenräume unerwartet nicht mehr für Anwendungen verfügbar, was diverse Exceptions zur Folge hat und den Betrieb aller (!) Anwendungen unterbricht, die auf TABEX4 Dataspaces zugreifen!

Die Administration der Dataspaces wird mittels TABEX4 Utility TABN14 durchgeführt:

  • Starten und Stoppen eines Subsystems
  • Löschen eines Dataspace
  • Reorganisieren eines Dataspace
  • Starten und Stoppen des Holder-Task

 

Siehe auch:

BOIDOC-201_Basis
BOIDOC-206_Utility

Wie sind SHS Dataspaces in TABEX4 Windows implementiert?

SHS Dataspaces sind in TABEX4 Windows als Shared Memory Segmente in Form von Windows File Mapping Objects implementiert.

Damit die TABEX4 Dienste und Programme in neueren Windows-Versionen auf diese globalen Systemobjekte zugreifen können, müssen die unten angeführten Konfigurationen bearbeitet werden.

Windows-Berechtigungen

Erteilen Sie die Windows-Berechtigung "Erstellen globaler Objekte" für jene Benutzerkennungen, unter denen TABEX4 Dienste bzw. Batch- und Konsolenprogramme laufen.

TABEX4 Systemparameter

In den TABEX4 Systemparametern (Datei boiparam.txt im TABEX4 Unterverzeichnis "sys") muss der Eintrag WINOBJ auf den Prefix "Global\" eingestellt werden, damit die Objekte im globalen Namensraum adressiert werden und nicht z.B. Objekte der eigenen Session.

Möglicherweise ist der erforderliche Eintrag bereits unter Kommentarklammern in der Parameterdatei zu finden.

In diesem Fall sind die Kommentare zu ändern, sodass der gewünschte Eintrag aktiv und der bisherige inaktiv wird.

Andernfalls ist der Eintrag, wenn bereits vorhanden, zu ändern, sonst neu einzufügen.

Allgemeine technische Fragen

Was ist das Deployment Cockpit?

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.

Wie kann ich Kontrollparameter des Table Managers bearbeiten?

Verwendung der Kontrollparameter

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.

Definition der Kontrollparameter

Die Verwendung der einzelnen Kontrollparameter ist wie folgt als Suchpfad in Steuertabellen festgelegt:

  • Kunden-Suchpfade können in der Steuertabelle $TAB4PTC21 definiert werden.
  • Die System-Suchpfade sind in der Steuertabelle $TAB4PTC57 definiert.
  • Nach dem Suchpfad wird in dieser Reihenfolge gesucht:
    1. Kunden-Tabellen $TAB4PTC21
    2. System-Tabellen $TAB4PTC57
  • Die Suchpfad-Definition ist in Spalte SEARCHPATH einzutragen
  • Wenn kein Suchpfad gefunden wurde oder dieser leer ist, wird der Suchpfad "S" angenommen.

Valide Suchpfad-Zeichen

Suchpfad-
Zeichen
Parameter-Tabellen in denen gesucht wirdParameter-Tabellen-Namen
UBenutzer- oder Default-ProfilZum Beispiel $_$DEFAULT(OPSMSG)
IInstanz-KonfigurationZum Beispiel $ICFG_000(TABCTL)
SParameter-Tabellen
(zuerst Kunden-Tabelle, dann System-Tabelle)
Zuerst Suche in $TAB4PTC06(TABCTL), dann in $TAB4PTC02(TABCTL)
TTemporäre Settings-Tabelle
Anmerkung: Dieses Zeichen muss das erste im Suchpfad sein
Der Name, spezifiziert in der Spalte SEARCHPATH, zum Beispiel $T4_PRINT (in der Datenbank TABCTL)
Initialer Wert für temporäre Parameter (Suchpfad-Zeichen "T"):

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.

Beispiele für Definitionen

Suchpfad-DefinitionBeschreibung
UISSucht zuerst im Benutzer-Profil, dann in der Instanz-Konfiguration und anschließend in den Systemparameter-Tabellen
ISSucht zuerst in der Instanz-Konfiguration und dann in den Systemparameter-Tabellen
SSucht nur in den Systemparameter-Tabellen
USSucht zuerst im Benutzer-Profil und dann in den Systemparameter-Tabellen
TUSSucht zuerst in den temporären Einstellungen (Set in einem Dialog, zum Beispiel Druck-Einstellungsdialog), dann im Benutzer-Profil und anschließend in den Systemparameter-Tabellen

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

Anwendungsbeispiel RELOGIN

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

1. Ermitteln des Suchpfads

In der kundenspezifischen Kontroll-Tabelle $TAB4PTC21(TABCTL) wird nachgesehen, ob ein Suchpfad für den Parameter RELOGIN eingetragen wurde. TABEX4 findet in $TAB4PTC21 keinen Eintrag, daher wird in $TAB4PTC57(TABCTL) gesucht:

2. Suche gemäß angegebenem Suchpfad

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.

  • Zuerst werden die Benutzer-Tabellen (das Default-Profil und das Benutzer-Profil) durchsucht. Das Default-Profil kann unter Berechtigungssystem/Pflege/Standard Profil bearbeiten um den Parameter RELOGIN erweitert werden. Das Benutzer-Profil kann mit Einstellungen/Benutzer-Profil bearbeiten angepasst werden.
  • 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.

  • Wurde in der Instanz kein Eintrag gefunden, werden die Parameter-Tabellen $TAB4PTC06 bzw. $TAB4PTC02 durchsucht.

    Die kundenspezifische Parameter-Tabelle $TAB4PTC06 kann unter Administration/Anwendung/Allgemeine Einstellungen/Systemeinstellungen bearbeitet werden.

    Die System-Parameter-Tabelle $TAB4PTC02 kann unter Administration/Anwendung/Allgemeine Einstellungen/Original-Systemeinst. angezeigt werden.

Wie definiere ich eine Summary-Datenbank für die Verwendung in einer TABEX4 Browseranwendung?

Vorgehensweise

  • 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

Beispiel

  • NameSummary-DB ... MYSUM
  • Name 1. Teil-DB ... MYPARTA
  • Name 2. Teil-DB ... MYPARTB


Die Eintragung in die Datei DDDEFS muss folgenden Aufbau haben:

Für eine Summary-DB:

ddsummary:dsn>dd1-dd2(-dd3-..ddn)

Zum Beispiel:

MYSUM:MYSUM-VIRTDSN>MYPARTA-MYPARTB

 

Für eine Chain-Summary-DB:

ddsummary:dsn>>dd1-dd2(-dd3-..ddn)

Zum Beispiel:

MYSUM:MYSUM-VIRTDSN>>MYPARTA-MYPARTB

 

Welche Allokations-Stufen für die TABEX Datenbanken gibt es?

Allgemeines

Durch den Login eines Benutzers wird eine neue TABEX4 Monitor-Session gestartet, bei der eine stufenweise Allokation von Datenbanken ausgeführt wird.

Folgende Stufen der Allokation gibt es:

  1. Monitor-Allokation-Skript (z/OS) 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 Stufen der Allokation möglich.

Stufe 1: Monitor-Allokation-Skript (z/OS) oder JCL-Datei (Unix, Linux, Windows)

Nachdem der Monitor eine neue Session gestartet hat, liest die Session ein Skript/JCL-File und führt die darin definierten Befehle aus.

Siehe auch: BOIDOC-226_Tcpip-monitor (für z/OS) und BOIDOC-224_cs_admin (für Windows, Unix, Linux) und das Beispiel zu Stufe 1 (siehe unten).

Stufe 2: Dynamische Allokations-Tabelle der Session (sysparm Einstellungen)

Wenn das Schlüsselwort SESALCID für eine Dynamische Allokations-Tabelle der Session im sysparm gefunden wird, werden zusätzliche Session-Allokationen aus einer TABEX Tabelle gelesen und ausgeführt.

Siehe auch: BOIDOC-209a_Config und das Beispiel zu Stufe 2 (siehe unten).

Stufe 3: Dynamische Allokations-Tabelle des Benutzers (Benutzerprofil-Einstellungen)

Wenn das Schlüsselwort DYNALC im Benutzer-Profil gefunden wird (oder in einem Copybook, das im Benutzer-Profil eingebunden ist), werden weitere benutzerspezifische Allokationen aus einer TABEX Tabelle gelesen und ausgeführt.

Siehe auch: BOIDOC-209a_Config und das Beispiel zu Stufe 3 (siehe unten).

Stufe 4: Dynamische Allokations-Tabelle der Instanz (Instanz-Konfiguration-Einstellungen)

Wenn das Schlüsselwort DYNALC in der Instanz-Konfigurations-Tabelle gefunden wird, werden zusätzliche Instanz-spezifische Allokationen aus einer TABEX Tabelle gelesen und ausgeführt.

Siehe auch: BOIDOC-209a_Config und das Beispiel zu Stufe 4 (siehe unten).

Weitere durch den Kunden definierte Stufen der Allokation (Exit-Implementierung)

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

Allokationen der TABEX4 Auslieferungsdatenbanken

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

 
  • INTSRC
  • INTMOD
  • OPSMSG
  • TABLGG, TABLGE
 

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

 
  • TABCTL
  • APPLGG, APPLGE
  • TABTMP
 

Siehe auch:

BOIDOC-209a_Config

Gültig ab TABEX4 Version 4.2.0

Allokations-Beispiel Stufe 1

Monitor-Allokation-Skript für z/OS

ALLOC FI(INTSRC) DA(TABEX4.CUST.INTSRC) SHR
ALLOC FI(INTMOD) DA(TABEX4.CUST.INTMOD) SHR
ALLOC FI(OPSMSG) DA(TABEX4.CUST.OPSMSG) SHR
ALLOC FI(TABLGG) DA(TABEX4.CUST.TABLGG) SHR
ALLOC FI(TABLGE) DA(TABEX4.CUST.APPLGG) SHR
ALLOC FI(TABCTL) DA(TABEX4.CUST.TABCTL) SHR
ALLOC FI(APPLGG) DA(TABEX4.CUST.APPLGG) SHR
ALLOC FI(APPLGE) DA(TABEX4.CUST.APPLGE) SHR
ALLOC FI(INTSRC1) DA(TABEX4.BOI.INTSRC) SHR
ALLOC FI(INTMOD1) DA(TABEX4.BOI.INTMOD) SHR
ALLOC FI(OPSMSG1) DA(TABEX4.BOI.OPSMSG) SHR
ALLOC FI(TABLGG1) DA(TABEX4.BOI.TABLGG) SHR
ALLOC FI(TABLGE1) DA(TABEX4.BOI.APPLGG) SHR
ALLOC FI(TABCTL1) DA(TABEX4.BOI.TABCTL) SHR
ALLOC FI(APPLGG1) DA(TABEX4.BOI.APPLGG) SHR
ALLOC FI(APPLGE1) DA(TABEX4.BOI.APPLGE) SHR

JCL-Datei für Unix, Linux, Windows

FILE = INTSRC '<tabexcus>/.tdb'<tdb>
FILE = INTMOD '<tabexcus>/.tdb' <tdb>
FILE = OPSMSG '<tabexcus>/.tdb' <tdb>
FILE = TABLGG '<tabexcln>/.tdb' <tdb>
FILE = TABLGE '<tabexcln>/.tdb' <tdb>
FILE = TABCTL '<tabexcus>/.tdb' <tdb>
FILE = APPLGG '<tabexcln>/.tdb' <tdb>
FILE = APPLGE '<tabexcln>/.tdb' <tdb>
FILE = INTSRC1 '<tabextdb>/INTSRC.tdb' <tdb>
FILE = INTMOD1 '<tabextdb>/INTMOD.tdb' <tdb>
FILE = OPSMSG1 '<tabextdb>/OPSMSG.tdb' <tdb>
FILE = TABLGG1 '<tabexlng>/TABLGG.tdb' <tdb>
FILE = TABLGE1 '<tabexlng>/TABLGE.tdb' <tdb>
FILE = TABCTL1 '<tabextdb>/TABCTL.tdb' <tdb>
FILE = APPLGG1 '<tabexlng>/APPLGG.tdb' <tdb>
FILE = APPLGE1 '<tabexlng>/APPLGE.tdb' <tdb>

Allokations-Beispiel Stufe 2

sysparm = SESALCID=XY

Durch diesen Eintrag in der Datei boiadmin.properties wird in der Datenbank OPSMSG die Einversionstabelle $TABI4ATXY gesucht und die darin definierten Allokationen durchgeführt.

Der Inhalt der Einversionstabelle $TABI4ATXY sieht für z/OS wie in Beispiel 1 "Monitor-Allokation-Skript für z/OS" aus und für Unix, Linux, Windows wie in "JCL-Datei für Unix, Linux, Windows". Sie darf aber nicht wieder die selben Datenbanken allokieren wie in Stufe 1.

Allokations-Beispiel Stufe 3

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.

Der Inhalt der Einversionstabelle DYNALC_BOI sieht für z/OS wie in Beispiel 1 "Monitor-Allokation-Skript für z/OS aus und für Unix, Linux, Windows wie in "JCL-Datei für Unix, Linux, Windows". Sie darf aber nicht wieder die selben Datenbanken allokieren wie in Stufe 1 und 2.

Allokations-Beispiel Stufe 4

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 durchgeführt.

Der Inhalt der Einversionstabelle DYN_INST05 sieht für z/OS wie in Beispiel 1 "Monitor-Allokation-Skript für z/OS aus und für Unix, Linux, Windows wie in "JCL-Datei für Unix, Linux, Windows". Sie darf aber nicht wieder die selben Datenbanken allokieren wie in den Stufen 1-3.

Welche Fehlermeldungen sind beim Login ohne Identitätswechsel möglich?

Der Betriebssystem-Login im z/OS 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) ...

Fehlermeldung BRW663

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.

Fehlermeldung BRW664

In Meldung BRW664 wird die der Fehlernummer (errno) zugeordnete Systemmeldung der C Runtime-Library ausgegeben. Die Abfrage des Meldungstextes erfolgt in Modul BOISUID durch Verwendung der Funktion perror().

Für eine Beschreibung von Funktionen, Fehler-Codes (errno) und Meldungen der C Runtime-Library wird auf die entsprechende IBM-Literatur verwiesen.

 

Siehe auch:

BOIDOC-209a_Config für eine detaillierte Beschreibung über die Implementierung eines Betriebssystem-Logins mit bzw. ohne Identitätswechsel

Wozu dient das BOI Remote Diagnostic Tool?

Das neue Programm "BOI Remote Diagnostic Tool" (boirmtdiag) kann zum Testen der Verbindung zu einem TABEX Monitor oder Callserver verwendet werden. Mit diesem kann jetzt von jedem System, auf dem sich eine Java-VM befindet, die Verbindung zum TABEX Monitor oder TABEX Callserver geprüft werden.

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:

Der Befehl 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.

Wie erzeuge ich unter z/OS einen Dump einer TABEX4 Browser-Session?

Notwendige Informationen zur Fehleranalyse

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.

Log-Dateien

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 und %u wird vom Monitor durch die Session-Nummer ersetzt.)

Dump

Der Dump wird vom System in eine als SYSUDUMP zugeordnete Datei geschrieben. Um das zu erreichen, müssen folgende Vorkehrungen getroffen werden:


Ändern der Aufrufparameter in der Start-JCL für den Session-Monitor:
Es muss bei den Optionen für Language Environment die Angabe TRAP(ON) geändert werden auf TRAP(OFF), z.B.:

//SETLEPAR SET LEPAR='POSIX(ON),TRAP(OFF),ENVAR("TZ=CET-1CEST")'

//MON1 EXEC PGM=BOIPMON,PARM=('&LEPAR / DD:MONPARM')

Achtung: Für Normalbetrieb ist die Angabe TRAP(ON) erforderlich. TRAP(OFF) verhindert die Zustellung von Signalen in Posix-Anwendungen.

 

Hinzufügen ALLOC-Statement für SYSUDUMP im Alloc-Script für die Monitor-Sessions:

Bei Verwendung der Default-Monitorparameter befindet sich das Script unter dem namen alloc  im Unterverzeichnis etc des TABEX4 USS-Verzeichnisses.

Format der Dump-Datei

Organization: PS

Record format: VBA

Record length: 125

Block size: 1632

Wie kann ich Regeln für die Vergabe von Tabellennamen definieren?

Vorgehensweise

In TABEX/3 war es möglich, Regeln für die Vergabe von Tabellennamen durch den Exit CHECKNAME zu definieren. In TABEX4 wurde der Exit durch eine Prüftabelle ersetzt.

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 der TABEX4 Konsole oder 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.

Beispiel

  • Eintragen der Prüftabelle:
    Tabelle: $TAB4PT001
    Steuertabelle: prftab
    'prftab' ist der frei vergebbare Name der Prüftabelle
  • Einfaches Beispiel für die Prüftabelle:
CNTFIELDCNTOPCNTV1CNTV2
 MSName muss aus ABCDEF bestehen
TI_TABLEVFABCDEF 

 

Was sind ENQ-Einträge (Tabellen-Sperreinträge)?

  • 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 gesetzt.
  • Im Rahmen der Entwicklungsumgebung ($TABX3_DVL) werden keine ENQ-Einträge gesetzt.

Wie konfiguriere ich das Login-Verfahren „Betriebssystem-Login ohne Identitätswechsel“ für z/OS?

Webanwendung (boiadmin.properties)

Setzen Sie

racflogin = false

 

Monitor

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

Wie debugge ich SSL-Programme?

Um SSL-Programme zu debuggen, sollten vorher Breakpoints gesetzt werden. Breakpoints können über die Tastenkombination Ctrl+Shift+B oder über das Menü „Run > Toggle Breakpoint“ gesetzt und zurückgesetzt werden. Ein blauer, gefüllter Kreis vor der Zeile im SSL-Editor bedeutet, dass ein Breakpoint in dieser Zeile aktiv ist.

Das Programm kann im Debug-Modus ausgeführt werden. Die Ausführung des Programms wird durch “Debug As > SSL application” aus dem Kontextmenü des SSL-Editors oder dem gleichnamigen Kontextmenüeintrag aus dem SSL-Explorer gestartet. Das Programm wird dann kompiliert und ausgeführt. Wenn Kompilierfehler im SSL-Source-Code gefunden werden, wird das SSL-Programm nicht ausgeführt.

Wenn ein Breakpoint erreicht wird, zeigt der graphische Instruction Pointer auf die aktuelle Source-Code-Zeile, wo der Breakpoint gesetzt wurde. Generell zeigt der Instruction Pointer auf die nächste auszuführende Anweisung. Der Inhalt der Variablen wird im „Variables View“ angezeigt. Der Wert der Variablen kann geändert werden, indem der Cursor in das Wertefeld der zu editierenden Variable positioniert und ein neuer Wert eingegeben wird.

Im Beispiel wurde ein Breakpoint in Zeile 16 eines SSL-Moduls gesetzt. Im Fenster „Variables“ ist zu erkennen, dass es eine Variable „i“ gibt. Im Fenster „Debug“ ist zu erkennen, dass der aktive SSL-entry „$_TENTRY“ heißt.

Im angezeigten Zustand wartet die Debug-Sitzung auf Benutzereingaben. Im „Run“-Menü werden die verfügbaren Optionen zur Beeinflussung der Debug-Sitzung angezeigt. Shortcuts und Icons können diesem Menü entnommen werden.

Das Fenster „Console“ zeigt die Ausgaben des SSL-Programmes an.

Die einzelnen Fenster lassen sich beliebig in ihrer Proportion ändern, indem der Mauszeiger zwischen den Fenstern positioniert wird, bis ein Doppelpfeil zu sehen ist, und anschließend mit gedrückter Maustaste gezogen wird.

Fragen zum TABEX4 Table Manager

Wie ist der TABEX4 Table Manager aufgebaut?

Der TABEX4 Table Manager gliedert sich in folgende Bereiche:

  1. Navigationsleiste
  2. Login-/Logoutbereich
  3. Explorer-Menü
  4. Separator zum Aus- und Einblenden des Explorer-Menüs
  5. Icon-Leiste
  6. Selektionsliste "weitere Aktionen"
  7. Aktiver Bereich (rot umrandet), auf welchem der Fokus liegt. In der Abbildung ist der Dialogbereich mit der Tabelle aktiv. Der Tabellenpflegebereich ist inaktiv.
  8. Filter für das Filtern von Zeilen unter Verwendung von Filteroperatoren
  9. Dialogbereich mit Tabelle
  10. Funktionen zum Bearbeiten des Tabellenpflegebereichs
  11. Wahlweise Tabellenpflegebereich oder Änderungsformel für Massenänderungen. In der Abbildung sieht man den Tabellenpflegebereich.
  12. Meldungsbereich für Meldungen von TABEX4 an den Benutzer

Über die Selektionsliste "weitere Aktionen" können zusätzliche Funktionen aufgerufen werden, die über die mittels Icons angebotenen Funktionen noch hinausgehen, z.B. „Import einer XLS-Datei (ergänzen)“.


Über folgende Gruppen-Icons können weitere Icons ein- und ausgeblendet werden:

Dieses Icon blendet die Icongruppe für Sortieroperationen ein.

Dieses Icon blendet die Icongruppe für Zeilenoperationen ein.

Dieses Icon blendet die Icongruppe für Spaltenoperationen ein.

Dieses Icon blendet Icons für das Arbeiten mit dem Tabellenpflegebereich und der Änderungsformel ein.

Icons einer eingeblendeten Icongruppe bleiben während einer Sitzung eingeblendet, auch dann, wenn man zwischen verschiedenen Menüpunkten der TABEX4 Browseroberfläche (z.B. "Tabelle bearbeiten", "Tabelle anzeigen" usw.) wechselt.

Weitere Informationen zum Bildschirmaufbau, zu den Icons, weiteren Aktionen, Filteroperatoren, dem Tabellenpflegebereich und der Änderungsformel finden Sie in der TABEX4 Hilfe Ihrer TABEX4-Installation unter „Grundlagen“.

Wie kann ich meine Icon-Favoriten zusammenstellen?

Wie kann ich meine Icon-Favoriten, auch benutzerspezifisch, zusammenstellen?

Viele Iconleisten werden erst durch Group-Icons angezeigt.

Weitere Aktionen können mit Hilfe der Selektionsliste „weitere Aktionen“ (Icon 'Schraubenschlüssel') eingeblendet werden.

Durch Konfiguration können Icons ausgewählt werden, die in der Iconleiste permanent angezeigt werden sollen.

Weiters können auch Funktionen aus der Selektionsliste „weitere Aktionen“ ausgeblendet werden.

Allgemeines

Viele Iconleisten müssen erst durch Group-Icons oder über das Schraubenschlüssel-Icon "weitere Aktionen" aufgeklappt werden.

Durch den Parameter GRP_ICO_ON in der Steuertabelle $TAB4PTC06(TABCTL), bearbeitbar durch den Menüpunkt Administration / Anwendung / Allgemeine Einstellungen / Systemeinstellungen bearbeiten, kann angegeben werden, welche Group-Icons nach dem Login aktiviert sein sollen.

Für einen schnelleren Zugriff kann man Icon-Favoriten auch in einer eigenen Leiste zusammenstellen.

Nach Konfiguration der Favorit-Icons wird die Leiste durch das Icon "Favorit-Icons ein-/ausschalten" oder durch den Systemparameter GRP_ICO_ON ein- bzw. ausgeblendet.

Sie wird in zweiter Reihe angezeigt. Favorit-Icons werden am linken Ende der Icon-Leiste eingereiht.

Systemweite Eintragung

Bei der Eintragung in den Systemeinstellungen gelten die definierten Icon-Favoriten für alle Benutzer und Instanzen.

Führen Sie dazu folgende Schritte durch:

FAVICO_TAB eintragen

Der Parameter FAVICO_TAB wird in die Tabelle $TAB4PTC06(TABCTL) eingetragen. Der Wert ist die ID der Tabelle, welche die Favorit-Icons beinhaltet.

Die Systemeinstellungen werden bearbeitet unter: Administration / Anwendung / Allgemeine Einstellungen / Systemeinstellungen bearbeiten.

Im obigen Beispiel enthält die Tabelle FAV_SYS die Favorit-Icons des Systems.

Der neue Parameter FAVICO_TAB und dessen Wert wird erst nach einem ReLogin aktiv. => Führen Sie bitte einen ReLogin durch.

Icon-Favoriten ändern

Die Zuordnung, welche Icons als Favorit-Icons angezeigt werden, erfolgt unter: Administration / Anwendung / Allgemeine Einstellungen / Icon-Favoriten ändern.

Es wird dabei die Tabelle, welche in $TAB4PTC06(TABCTL) für den Parameter FAVICO_TAB eingetragen wurde, angelegt (wenn noch nicht vorhanden) oder bearbeitet.

Im rechten Panel Icon-Vorrat befinden sich alle verfügbaren Icons. Von dort können Sie nach links zu den Icon-Favoriten verschoben werden. Im Feld show? kann angegeben werden, ob das Icon angezeigt (Y) oder nicht angezeigt (N) werden soll.

Im obigen Beispiel wurden die Icons "Speichertabellen anzeigen", "Layouteinstellungen speichern" und "gespeicherte Layouteinstellungen löschen" hinzugefügt.

Das Icon für "Speichertabellen anzeigen" ist ausgeblendet (show?=N).

 

Ergebnis des Beispiels:

Das Ergebnis des obigen Beispiels sieht nach erfolgreichem Speichern wie folgt aus (ein ReLogin ist nicht nötig):

Die rot eingerahmten Icons sind die neuen Favorit-Icons.

Sie werden in der Selektionsliste "weitere Aktionen" nun nicht mehr angezeigt:

Achtung: Auch der Eintrag "Speichertabellen anzeigen", welcher mit show?=N ausgeblendet wurde, wird nicht mehr angezeigt!

Benutzerspezifische Eintragung

Bei der Eintragung im Benutzer-Profil gelten die definierten Icon-Favoriten nur für den aktuellen Benutzer.

Führen Sie dazu folgende Schritte durch:

Suchpfad ändern

In der Steuertabelle $TAB4PTC21(TABCTL) wird der Suchpfad eingetragen, welcher angibt, ob zuerst die Einstellungen des Benutzers oder des Systems wirken.

Im obigen Beispiel werden für den Parameter FAVICO_TAB zuerst die Benutzereinstellungen (U) und anschließend die Systemeinstellungen (S) durchsucht, sollte für den Benutzer nichts konfiguriert sein.

FAVICO_TAB in Benutzer-Profil eintragen

Unter Einstellungen / Benutzer-Profil bearbeiten wird der Parameter FAVICO_TAB eingetragen.

Der Parameterwert ist die ID der Tabelle, welche die Favorit-Icons für den aktuellen Benutzer beinhaltet.

Im obigen Beispiel enthält die Tabelle FAV_BOI die Favorit-Icons des Benutzers BOI.

Icon-Favoriten ändern

Die Zuordnung, welche Icons als Favorit-Icons angezeigt werden, erfolgt unter: Administration / Anwendung / Allgemeine Einstellungen / Icon-Favoriten ändern.

Es wird dabei die Tabelle, welche im Benutzerprofil für den Parameter FAVICO_TAB eingetragen wurde, bearbeitet.

Beim ersten Hinzufügen eines Icons und Speichern wird die Tabelle in der Datenbank TABCTL angelegt, sollte sie noch nicht vorhanden sein.

Im obigen Beispiel wurde das Icon "Wechsel zw. horizontal/vertikal" hinzugefügt.


Ergebnis des Beispiels:

Das Ergebnis des obigen Beispiels sieht nach erfolgreichem Speichern wie folgt aus (ein ReLogin ist nicht nötig):

Das rot eingerahmte Icon ist eines der neuen Favorit-Icons.


Hinweis:

Wird der Eintrag FAVICO_TAB aus dem Benutzerprofil gelöscht, wirkt die Systemeinstellung.

Folglich werden die Favorit-Icons der Systemeinstellung (in den obigen Beispielen die Tabelle FAV_SYS) verwendet.

 

Siehe auch:

BOIDOC-209a_Config

Gültig ab TABEX4 Version 4.2.0

Was ist der Tabellen-Pflegebereich?

Der Tabellen-Pflegebereich vereinfacht die Pflege mehrerer Datensätze.

Mit dem Tabellen-Pflegebereich können in einfacher Weise Massenänderungen durchgeführt werden.

Der Tabellen-Pflegebereich kann mit dem Warenkorb eines Online-Shops verglichen werden: Es werden Datensätze für die spätere Bearbeitung gesammelt.
Dann können z.B. Massenänderungen (mit der Änderungsformel) auf alle Datensätze im Tabellen-Pflegebereich durchgeführt oder ausgewählte Sätze gedruckt werden.

Das Icon "Tabellen-Layout-Änderungen ein-/ausschalten" blendet die Icongruppe für die Einstellung der unterschiedlichen Layouts ein. Die Symbole in den Icons haben dabei folgende Bedeutung: die weiße Tabelle im Icon ist der Tabellenbereich, die gelbe der Tabellen-Pflegebereich und die rote Zeile ist die Änderungsformel.

Mit der Pflegebereichs-Navigationsleiste können Datensätze zwischen dem Tabellenbereich (oberer Bereich) und dem Tabellen-Pflegebereich (unterer Bereich) kopiert und verschoben werden.

Weitere Informationen zum Tabellen-Pflegebereich finden Sie in der TABEX4 Hilfe Ihrer TABEX4-Installation unter „Grundlagen > Tabellen-Pflegebereich“.

Wie kann ich Hilfetexte für Tabellen und Felder erstellen?

Hilfetexte für die Tabellen- oder Feld-Hilfe können mit einer einfachen Wiki-Syntax definiert werden.

Ein Konvertierungsprogramm kann TABHLP-Tabellen im TABEX/3-Format in TABEX4-TABHLP-Tabellen mit Wiki-Syntax umwandeln.

Folgende Zeichen sind für die Wiki-Syntax reserviert:

Anker setzen: {{ … }}

Überschrift 1: == … ==

Überschrift 2: === … ===

Fett-Schrift: ''' … '''

Beispiel für einen Hilfetext der Tabelle CONTINENTS in Wiki-Syntax:

{{Allgemeines}}

Lorem ipsum dolor sit amet, consetetur sadipscing elitr,

sed diam nonumy eirmod tempor invidunt ut labore et

dolore magna aliquyam erat, sed diam voluptua. At vero

eos et accusam et justo duo dolores et ea rebum.

 

 

{{cont_code|KoKode}}

Nam liber tempor cum soluta nobis eleifend option congue

nihil imperdiet doming id quod mazim placerat facer

possim assum.

 

 

{{cont_name|Kontinent}}

At vero eos et accusam et justo duo dolores et ea rebum.

Stet clita kasd gubergren, no sea takimata sanctus est

Lorem ipsum dolor sit amet.

Die HTML-Seiten können aus den TABHLP-Tabellen, die als TABEX-Tabellen gepflegt wurden, folgendermaßen erzeugt werden:

  • manuell durch Ausführung des TABN03 Befehls TABHTML:
    tabhtml,continents,,/tmp/tabhlp,&name.html,,$TAB4PTC89(TABCTL)

  • manuell mittels Administrator-Menüpunkt

  • automatisch mit einem Protokoll-Exit. Dieser erzeugt automatisch die HTML-Seite, wenn eine TABHLP-Tabelle gespeichert wird.

Siehe auch:

BOIDOC-209a, Abschnitt "Create HTML files from TABHLP tables"

Welche Bedeutung haben die 'KeepAlive'-Parameter?

Allgemeines

TABEX4 Monitor und TABEX4 Table Manager sind so vorkonfiguriert, dass die TABEX-Sitzung ohne weitere Vorkehrungen nach 30 Minuten Inaktivität mit einem LOGOUT beendet wird. Siehe auch BOIDOC-209a, Kapitel „Configuration of the TABEX4 session monitor“.

Die Inaktivitätseinstellungen können verändert werden, indem die Systemparameter KEEPALVVAL, KEEPALVCNT und KEEPALVACT angepasst werden.

Mit diesen KeepAlive-Parametern kann festgelegt werden, nach wie vielen Minuten und mit wie vielen Wiederholungen eine Aktion ausgeführt werden soll (die den gesamten Kommunikationsweg durchläuft, aber auf die Anwendung keinen Einfluss hat ('NoAction'-Aktion)) und was nach der letzten Aktion geschehen soll.

KEEPALVVAL: KeepAlive-Wert in Minuten

Mit dem Parameter KEEPALVVAL wird festgelegt, in welchem Zeitabstand in Minuten ein 'NoAction' gesendet werden soll. Dies führt dazu, dass die in Kapitel „Configuration of the TABEX4 session monitor“ von BOIDOC-209a beschriebenen Timeouts wieder zurückgesetzt werden.

KEEPALVCNT: KeepAlive-Zähler

Mit dem Parameter KEEPALVCNT wird festgelegt, wie oft ein 'NoAction' gesendet werden soll.

KEEPALVACT: letzte KeepAlive-Aktion

Mit dem Parameter KEEPALVACT wird festgelegt, welche Aktion beim erreichen des letzten Keepalive-Wertes durchgeführt werden soll. Üblicherweise ist dies eine Logout-Aktion.

Standardeinstellungen

Folgende Einstellungen sind vorbelegt:

  • KEEPALVVAL = 20
  • KEEPALVCNT = 3
  • KEEPALVACT = LOGOUT

 

Diese Einstellung führt zu folgendem Ablauf der Inaktivitätsbehandlung:

  1. Der TABEX4 Table Manager sendet 20 Minuten nach der letzten Benutzeraktion 'NoAction' an die Monitor-Sitzung.
  2. Der TABEX4 Table Manager sendet nach weiteren 20 Minuten 'NoAction' an die Monitor-Sitzung.
  3. Der TABEX4 Table Manager sendet eine LOGOUT-Aktion an die Monitor-Sitzung.

Die mögliche Inaktivitätszeit bis zum Logout beträgt mit den Standardeinstellungen daher 60 Minuten.

 

Auswirkung von KEEPALVACT = NOP

Wenn der Parameter KEEPALVACT auf NOP (statt LOGOUT) eingestellt wurde, wird bei Erreichen der letzten Aktion der Inaktivität eine Aktion 'NoAction' gesendet.

Wurden die Auslieferungseinstellungen lt. BOIDOC-209a, Kapitel „Configuration of the TABEX4 session monitor“ wie empfohlen nicht geändert, erfolgt nach 30 Minuten ein LOGOUT seitens des TABEX4 Table Managers. Dieser Wert „30 Minuten“ entspricht dem eingestellten Sitzungs-Timeout des jeweiligen Application Servers und kann daher variieren.

 

Kunden-Erfahrungen

Bei unseren Kunden kam es vor, dass die TCP/IP-Verbindung nach nicht ganz 30 Minuten Inaktivität von einem System auf der Kommunikationsstrecke beendet wurde, obwohl das Sitzungs-Timeout des Application Servers höher konfiguriert war.

Wir empfehlen daher, den Parameter KEEPALVACT=LOGOUT zu setzen. Dadurch beendet der letzte KEEPALVCNT die Anwendung mit einem LOGOUT.

 

Siehe auch:

BOIDOC-209a_Config

Welchen Vorteil bietet es, mehrere TABEX-Server zu Gruppen zusammenzufassen?

Die Konfiguration der TABEX-Server, zu denen sich der TABEX4 Table Manager verbinden kann, kann in Gruppen eingeteilt werden.

Dies hat den Vorteil, dass eine Serverdefinition in mehreren Gruppen vorkommen kann, ohne mehrere TABEX4 Table Manager Deployments mit mehrfach definierten Server-Definitionen erstellen zu müssen.

 

Siehe auch:

Was ist das Deployment Cockpit?

BOIDOC-209a_Config

BOIDOC-241_Deployment

Warum gibt es bei "Tabellenstruktur ändern" einen Bereich “neue Tabellenfelder”?

Man kann “aktuelle Tabellenfelder” mit dem Systemparameter CHGTBXPROT sperren. Damit kann verhindert werden, dass ein Benutzer die Reihenfolge bereits bestehender Felder verändert.

Wenn “aktuelle Tabellenfelder” gesperrt ist, dürfen neue Zeilen ausschließlich in “neue Tabellenfelder” eingegeben werden.

Die Reihenfolge bestehender Felder soll beispielsweise nicht verändert werden, wenn die Felder bereits in Programmen verwendet werden.

Siehe auch:

BOIDOC-209a_Config

Wie kann ich die Farben der Navigationsleiste und des Hintergrunds ändern?

Man kann die Farbe der Navigationsleiste und die Farbe des Hintergrundes des TABEX4 Table Managers mit Hilfe der Instanzparameter INSTNAVCOL und INSTBCOLOR setzen. Darüber hinaus kann man mit dem Instanzparameter INSTLOGO ein Bild angeben, welches im Browserfenster des TABEX4 Table Managers angezeigt werden soll.

Weitere Informationen zu den genannten Parametern finden Sie in BOIDOC-209a_Config.

Was muss ich tun, damit das Fenster der TABEX4 Webanwendung unter Windows maximal angezeigt wird?

Anzeige der TABEX4 Webanwendung

Die TABEX4 Webanwendung wird in einem neuen Browser-Fenster ohne Menü- und Navigationsleiste geöffnet. MS Windows unterstützt  das Öffnen dieses Browser-Fensters in maximaler Größe nicht.

Die TABEX4 Webanwendung kann daher nicht automatisch den gesamten Bildschirm für die Anzeige nutzen.

Problem

Die im Browser angezeigte Index-Datei ist in der folgenden Abbildung in maximaler Größe, dennoch wird das geöffnete Anmeldefenster verkleinert angezeigt:

Die gestartete TABEX4 Webanwendung wird ebenfalls verkleinert angezeigt:

Wird nun die Anwendung per Icon maximiert, erscheint folgende Meldung:

Wird der Dialog durch Drücken des Buttons "Abbrechen" abgebrochen, dann bleibt die Anzeige klein.

Wird der Button "OK" gedrückt, passt sich zwar die Anzeige an. Wird jedoch das Browser-Fenster geschlossen, wird beim nächsten Start von TABEX4 wieder die ursprüngliche Browser-Größe übernommen.

Nach dem Schließen und dem neuerlichen Öffnen der Anwendung wird der Anmeldebildschirm verkleinert angezeigt:

Lösung / Workaround

MS Windows merkt sich die Größe des Browser-Fensters, welches als erstes geöffnet wurde.

Um die Fenster der TABEX4 Webanwendung möglichst in voller Größer anzeigen zu lassen, muss die Größe des ersten Fensters manuell eingestellt werden.

Führen Sie dazu folgende Schritte durch:

Anmeldebildschirm verkleinern

Verkleinern Sie den Anmeldebildschirm durch Klick auf das "Verkleinern"-Symbol auf der linken Seite des roten "Schließen"-Symbols.

Fenster größer ziehen

Maximieren Sie das Fenster manuell, in dem Sie die Ecken des Fensters bis zum äußeren Bildschirmrand ziehen.

Das Ergebnis sollte sein, dass das Fenster den gesamten Bildschirm ausfüllt, das Icon "Maximieren" jedoch immer noch angezeigt wird:

Browser schließen, TABEX4 starten

Schließen Sie den Browser und starten Sie die TABEX4 Webanwendung. MS Windows hat sich die Browser-Fenstergröße gemerkt.

Der Anmeldebildschirm und die Anwendung werden nun in der von Ihnen gewählten Größe angezeigt:

Siehe auch:

BOIDOC-209a_Config

Wie kann ich Massenänderungen durchführen?

Massenänderungen können mit Hilfe der Änderungsformel durchgeführt werden.

Die Änderungsformel kann auf selektierte Sätze der aktuellen Tabelle oder des Tabellen-Pflegebereichs angewendet werden.

Das Panel für die Eingabe der Änderungsformel wird mit den Icons "Tabelle und Änderungsformel-Fenster anzeigen" und "Änderungsformel-Fst. und Tabelle-Pflegeber. anzeigen" aus der Icongruppe "Tabellen-Layout-Änderungen ein-/ausschalten" eingeblendet.

Mit dem Icon "Änderungsformel in selektierten Zeilen ausführen" wird die Änderungsformel auf die selektierten Sätze der ausgewählten Tabelle bzw. des Tabellen-Pflegebereichs angewandt. Beispiele: einfache Wertzuweisung oder komplexe Abläufe (TABEX-Programm).

Das Icon "Tabellen-Layout-Änderungen ein-/ausschalten" blendet die Icongruppe für die Einstellung der unterschiedlichen Layouts ein. Die Symbole in den Icons haben dabei folgende Bedeutung: die weiße Tabelle im Icon ist der Tabellenbereich, die gelbe der Tabellen-Pflegebereich und die rote Zeile ist die Änderungsformel.

Mit der Pflegebereichs-Navigationsleiste können Datensätze zwischen dem Tabellenbereich (oberer Bereich) und dem Tabellen-Pflegebereich (unterer Bereich) kopiert und verschoben werden.

Weitere Informationen zur Änderungsformel finden Sie in der TABEX4 Hilfe Ihrer TABEX4-Installation unter „Grundlagen > Änderungsformel“.

Wie kann ich einen BOIPRINT erzeugen?

Einleitung

Der TABEX4 Table Manager ermöglicht das Einstellen von debug-, trace- und BOIPRINT-Levels. Dazu muss die Anzeige der Navigationsleiste umgeschaltet werden.

Umschalten zu den debug/trace/BOIPRINT-Einstellungen

Umschalten können Sie:

  • mit dem Hotkey [Ctrl]+[Shift]+[Alt]+[Num]
  • durch Doppelklick auf das Copyright-Symbol oben rechts im Browser-Fenster:

Nach dem Umschalten sehen Sie die Einstellungen der debug-, trace- und BOIPRINT-Level:

BOIPRINT-Einstellungen ändern

Wenn Sie die Einstellungen des BOIPRINT-Levels ändern, wird automatisch ein ReLogin durchgeführt.

"debug window" öffnen

Mit dem Link "debug window" können Sie ein Browser-Fenster mit dem Titel "debug info and trace info from TABEX4" öffnen.

Dieses enthält gemäß den debug/trace/BOIPRINT-Einstellungen Informationen zu den letzten Aktionen:

Wenn Sie dieses Fenster geöffnet lassen, wird jede weitere Aktion mitgeloggt.

 

Siehe auch:

BOIDOC-209a_Config

Gültig ab TABEX4 Version 4.1.0

Was soll ich tun, wenn nach einem Monitor-Timeout alle offenen Datenbanken gesperrt sind?

Wenn ein Monitor-Timeout eintritt, wird die betroffene Monitor-Sitzung abgebrochen. Zu diesem Zeitpunkt vorhandene Datenbanksperren bleiben aufrecht, damit keine inkonsistenten Daten über mehrere Datenbanken hinweg entstehen.

Eine Überprüfung der Daten und ein manuelles Aufheben der Sperre(n) sind in jedem Fall notwendig; auch wenn nur eine Datenbank betroffen ist.

Bei Operationen mit mehreren Datenbanken ist zusätzlich zu beachten, dass nicht immer sichergestellt ist, welche Datenbanken bereits aktuelle Daten beinhalten und welche noch nicht.

 

Auf Monitor-Seite sind die beiden Timeouts MON-TIMEOUT-IDLE-SEC und MON-TIMEOUT-RUNAWAY-SEC zu unterscheiden.

MON-TIMEOUT-IDLE-SEC bezeichnet das Sitzungs-Timeout. Dieses Timeout tritt ein, wenn keine Benutzeraktionen innerhalb einer bestimmten Zeit gesetzt werden. Siehe auch KeepAlive Parameter, wie diese Zeit erhöht werden kann.

Es ist zum einen als Sitzungs-Timeout des Application Servers und zum Anderen durch die Einstellung der in KeepAlive Parameter beschriebenen Parameter konfigurierbar.

MON-TIMEOUT-RUNAWAY-SEC bezeichnet ein Roundtrip- (Request-Response-) Timeout. Die Zeit zwischen dem Setzen einer Benutzeraktion im TABEX4 Table Manager bis zur Antwort des User Interfaces auf diese Aktion wird als Roundtrip-Time bezeichnet.

Es ist in boiadmin.properties in Parameter montimeout definiert. Dieses Timeout sollte gleich dem Timeout MON-TIMEOUT-RUNAWAY-SEC sein. Möglicherweise ist in seltenen Fällen die Konfiguration eines geringfügig größeren Werts für dieses Timeout sinnvoll. Die Zusammenhänge zwischen den einzelnen Timeout-Parametern sind in BOIDOC-209a, Kapitel „Configuration of the TABEX4 session monitor“ beschrieben.

 

Siehe auch:

BOIDOC-209a_Config

BOIDOC-226_Tcpip-monitor

 

Warum werden bei einer SQLT-Tabelle Zeilen angezeigt, obwohl sie aus der TABEX Tabelle gelöscht wurden?

Bei ‘TABEX Datenbank’ – ‘Pflege’ – ‘SQLT Änderungen aktivieren’ kann man “Löschen Zeilen aus TABEX Tabelle” entweder auf Y oder N setzen.

Wenn man Y setzt, werden beim Aktivieren der SQLT-Änderungen die Zeilen aus der TABEX Tabelle gelöscht. Im Tabellen-Index wird für die Tabelle 0 Zeilen angezeigt.

Wenn man N setzt, werden die Zeilen nicht aus der TABEX Tabelle gelöscht.

Wird die Tabelle zum Anzeigen oder Bearbeiten ausgewählt, wird in beiden Fällen die Tabelle mit Zeilen anzeigt. Wenn die Tabelle 0 Zeilen hat, wird beim Anzeigen der Tabelle automatisch der Inhalt aus der relationalen Datenbank geladen.

Export/Import/Druck

Wie kann ich den Export/Import/Druck einrichten?

Für die Konfiguration der Export-, Import- und Druck-Funktionen wird das BOI Administration Interface benötigt. Dieses wird über "Administration/Administrations-GUI aufrufen" gestartet.

Wählen Sie den Punkt"Configure PDF, CSV, XLS, HTML and MAIL" aus.

Generell werden die Export-, Import- und Druck-Einstellungen in Projektform abgewickelt. Ein Projekt ist eine komplette Konfigurationsinformation für PDF-Druck/-Export, CSV-Druck/-Export/-Import, XLS(X)-Druck/-Export/-Import, HTML oder MAIL. Der Projektname besteht aus maximal vier Zeichen und wird als Registerkarte im Konfigurationsdialog dargestellt.

Der Dialog kann entweder im "normal mode" oder im "expert mode" verwendet werden. Per default stellt der "normal mode" alle Konfigurationsparameter zur Verfügung, welche als Eingabe benötigt werden.

 

Es werden zwei Informationen für den Konfigurationsdialog benötigt:

  • Browser hyperlink base path: öffentlicher Ressourcen-Name des lokalen Basis-Pfades des Web Application Servers
  • Local base path on the application server: lokaler Basis-Pfad einer Web Application am Web Application Server. Er wird dazu verwendet, um hinaufgeladene Dateien für Import-Zwecke zu speichern und macht exportierte/gedruckte Dateien für Benutzer, die mit einer Browser Session arbeiten, verfügbar.

 

Die einzige Einschränkung bei der Pfadkonfiguration ist, dass der Pfad durch die TABEX Web Application erreichbar sein muss. Es wird empfohlen, dass der Pfad für die exportierten, gedruckten und importierten Dateien ein Web Application-Pfad ist, auf demselben Web Application Server, auf dem die TABEX Web Application deployed wurde.

 

Der "expert mode" sollte verwendet werden, wenn eine oder mehrere der folgenden Situationen zutreffen:

  • Das TABEX root directory (verwendet für die Datei-Allokation) soll aus einem bestimmten Grund manuell geändert werden.
  • Eine der folgenden DD-Namen werden bereits von TABEX verwendet:
    CSVDATO oder CSVDATI
    HTMLOUT
    PDFDATA oder PDFMETA
    XLSDATA oder XLSMETA
  • Wenn der PDF list and tool path nicht "[TABEX_ROOT]/pdf/input" lauten soll.

Beispiel

Die Dateien sollen auf einem Apache Tomcat Servlet-Container verfügbar gemacht werden:

  • Die TABEX Web Application wird am Kontext "tabex" deployed, auf demselben Web Application Server.
  • Zum Speichern der Dateien wird ebenfalls ein Kontext "tabex" verwendet. Im Unterverzeichnis "temp" werden die Dateien gespeichert.
  • Der Web Application Server läuft auf "localhost" und hört auf den Port 8080. Der lokale Installationspfad des Web Application Server lautet "C:\Programme\Apache Software Foundation".
  • Die Tomcat-Installation verwendet die Konfiguration "webapps" um zu laufen.

Folglich werden folgende Pfade verwendet:

  • Browser Hyperlink Base Path: localhost/tabex/temp
  • Local Base Path am Application Server: C:/Programme/Apache Software Foundation/Tomcat 7.0/webapps/tabex/temp

Konfigurationsschritte

Ein neues Projekt kann durch Drücken des "add"-Buttons am oberen Fensterende hinzugefügt werden. Ein Dialog wird angezeigt, in welchem der Projekttyp und der Projektname spezifiziert werden:

Anschließend können die Pfade definiert werden.

Ein Projekt kann mittels "delete"-Button gelöscht und mittels "rename"-Button umbenannt werden. Bei letzterem wird ein Dialog angezeigt, um das Projekt umzubenennen:

Wurde die Konfiguration abgeschlossen, kann diese mittels "Save"-Button gespeichert werden. Via "Cancel"-Button werden die Änderungen verworfen. Nach dem Drücken des "Save"-Buttons erscheint ein Popup-Dialog, wenn die Speicherung erfolgreich war:

Nach dem Befolgen der Instruktionen des Popup-Dialogs ist die Export-/Import-/Druck-Konfiguration beendet.

Der Expert Mode

Mit dem Button "Expert mode..." kann man auf diesen Modus wechseln und der Bildschirm ändert sich:

Nun können ein anderes TABEX root directory und andere DD-Namen festgelegt werden.

Situation: "kein Projekt definiert"

Wenn die Option "Configure PDF, CSV, XLS, HTML and Mail" gewählt wurde und noch kein Projekt definiert ist, wird der "Add project"-Dialog angezeigt:

Wird dieser Dialog durch Drücken des "Cancel"-Buttons verlassen, kehrt das BOI Administration Interface zurück zum Options-Auswahlfenster.

Wenn ein Projektname eingegeben und der "OK"-Button gedrückt wurden, wird das Projekt hinzugefügt und in einer neuen Registerkarte angezeigt.

Wurden alle Projekt gelöscht, wird ein leerer Bildschirm mit dem Button "add" angezeigt.

Siehe auch:

BOIDOC-240_AdminInterface

Gültig ab TABEX4 Version 4.1.2

Welche Einstellungen gibt es beim Export/Import/Druck?

Mit der Funktion "Druck und Export-/Import-Einstellungen" (auswählbar über die Selektionsliste "weitere Aktionen" oder über den Menüpunkt "Einstellungen") kann der Export/Import/Druck konfiguriert werden.
Diese Einstellungen sind nur temporär während der Sitzung gültig.

Für den Export/Import/Druck können folgende Parameter eingestellt werden:

Druck-Modus
Beim Druck-Modus kann entweder CSV, PDF, TEXT oder XLS eingestellt werden. Diese Setzung bestimmt, ob das Icon "Druckausgabe" bzw. der Hotkey Ctrl+P eine CSV-, PDF-, Text- oder MS Excel-Datei erzeugt.


Inhalt der PDF Info am Deckblatt
Eine vierstellige Kombination von Y (für eingeschaltet) und N (für ausgeschaltet) kann eingegeben werden:

  • Der erste Buchstabe gibt an, ob das Selektionskriterium ausgegeben wird.
  • Der zweite Buchstabe definiert, ob auf dem Deckblatt die Feldnamen der nicht gedruckten Felder ausgegeben werden.
  • Der dritte Buchstabe gibt an, ob das Sortierkriterium angeführt wird.
  • Der vierte Buchstabe definiert, ob die (Original-)Feldnummern der Tabelle vor dem Umreihen der Felder ausgegeben werden.
     

PDF Zeilennummern-Ausgabe
Folgende Werte können eingegeben werden:

  • 'D' (drucke Zeilennummern, wenn diese angezeigt werden)
  • 'P' (drucke keine Zeilennummern)
  • 'Q' (drucke Zeilennummern)
     

PDF Seitenformat (Hoch/Quer)

  • Durch Angabe von PORTRAIT wird in Hochformat gedruckt.
  • Die Angabe von LANDSCAPE erzeugt ein PDF im Querformat.

Achtung: Das PDF-Seitenformat beeinflusst den PDF-Druck sowie den PDF-Export.


CSV Import Trennzeichen, CSV Export Trennzeichen

  • ';'
  • ','


Export-Modus

  • 'CSV'
  • 'PDF'
  • 'XLS'


Import-Modus

  • 'CSV'
  • 'XLS'

Export/Import/Druck von XLS(X)-Dateien

Der Export von Tabellendaten ist ein beliebtes Feature des TABEX4 Table Managers.

Folgende Möglichkeiten stehen zur Auswahl:

  • Drucken in Form von CSV, PDF, XLSX oder in Form einer Text-Datei
  • Ausgabe der Editor-Einstellungen als PDF
  • Exportieren in Form von CSV und PDF
  • Importieren von CSV im Modus "Ersetzen" bzw. "Ergänzen"


Eine komfortable Möglichkeit bieten der Export, Import und Druck von MS Excel-Dokumenten in den Formaten .xls und .xlsx:

Es werden beim Drucken und Exportieren MS Excel-Dokumente (im Format .xlsx) erzeugt, welche in MS Excel bearbeitet und gespeichert werden können.

Der große Vorteil dabei ist, dass TABEX4 beim Export das MS Excel-Dokument direkt generiert und die passenden Datenformate und Darstellungen je Tabellenspalte setzt. MS Excel nimmt keine automatischen Datenformatänderungen mehr vor. Es ist somit ein korrekter Import von .xls und .xlsx-Dateien möglich.


Der Export-/Import-Ablauf mit TABEX4 und MS Excel ist in folgender Abbildung dargestellt:

Über einen zusätzlichen Systemparameter XLSRGTTRIM ist beim Druck und Export aus TABEX4 steuerbar, ob nachfolgende Leerzeichen je Zelle abgeschnitten werden sollen, um eine komprimiertere Anzeige im MS Excel-Dokument zu ermöglichen.

Siehe auch:

BOIDOC-209a_Config

BOIDOC-240_AdminInterface

Gültig ab TABEX4 Version 4.4.0

Export und Import von CSV-Dateien

Export von CSV-Dateien

Dieses Icon startet die Aktion "Exportieren als CSV-Datei".

Wird das Icon nicht angezeigt, so müssen die Einstellungen für Druck/Export/Import umgestellt werden: Diese Funktion ist über "weitere Aktionen" > "Druck- und Export-/Import-Einstellungen" durch Eingabe von CSV bei Export-Modus anwählbar.

Mit der Wahl dieser Aktion wird die aktuelle Tabelle im CSV-Format gespeichert.
In der ersten Zeile stehen die Spaltennamen separiert durch ;
Darunter stehen die Datensätze der Tabelle. Strings sind unter " " gesetzt. Die Trennung der Spalten erfolgt durch ;

Beispiel:
"PERSONALNUMMER";"NACHNAME";"VORNAME";"STRASSE";"PLZ";"ORT"
"4001";"Mayer               ";"Fritz     ";"Grünwaldstraße 5    ";"1234 ";"Walddorf       "
"4444";"Mustermann       ";"Heinrich  ";"Hausweg 87          ";"1342 ";"Weggen         "
"4511";"Schröder            ";"Cornelius ";"Stadtplatz 14       ";"1423 ";"Hambach        "
"4623";"Schenker            ";"Eva       ";"St. Georgen 37      ";"1313 ";"Steinhausen    "


Im Browser wird eine Meldung angezeigt, dass die CSV-Datei generiert wurde. In dieser Meldung wird ein Link zu dieser generierten CSV-Datei angezeigt.

Durch Klick auf den angegebenen Link (der unterstrichene Teil in der Meldung) wird das mit CSV verknüpfte Programm (z.B. MS Excel) aufgerufen und die CSV-Datei angezeigt.

Je nach Browsereinstellung wird zusätzlich auch dieses Fenster angezeigt (das erspart das Klicken auf den Link):

Mit "OK" wird das mit dem CSV-Format verknüpfte Programm (z.B. MS Excel) geöffnet und die CSV-Datei angezeigt.

Import von CSV-Dateien

Es gibt zwei Varianten, um CSV-Daten wieder in TABEX-Tabellen zu importieren:

Die erste Variante ersetzt die TABEX-Daten durch die importierten Daten.

Dieses Icon startet den ersetzenden Import.

Dabei werden die Daten geprüft und, wenn keine Fehler gefunden wurden, die bestehenden Tabellenzeilen durch die neuen Zeilen ersetzt. In diesem Zuge werden auch eventuelle Delete-Rule-Verletzungen der ersetzten und nicht mehr im neuen Datensatz vorhandenen Zeilen geprüft und die Übernahme abgelehnt.

Die zweite Variante ergänzt die TABEX Daten mit den importierten Daten.
Sie wird über die Selektionsliste "weitere Aktionen" mit dem Eintrag "Import aus CSV-Datei (ergänzen)" gestartet.

Bei dieser Variante werden die neuen Zeilen an die bestehenden Zeilen angefügt und als "noch zu prüfen" gekennzeichnet. Spätestens bei der Speicherung durchlaufen alle noch nicht geprüften Zeilen die unterschiedlichen Prüfungen (Prüftabellen, RI-Prüfungen, ...).

Wie können Felder mit führenden Nullen in TABEX4 korrekt als CSV importiert werden?

Wenn Daten aus TABEX4 exportiert, in MS Excel geändert und wieder in TABEX4 importiert werden, können Probleme mit Änderungen auftreten, die von MS Excel automatisch durchgeführt wurden (z.B. Entfernen führender Nullen).

Ein Beispiel für eine Exportdatei:
"PRODNR";"PRODNAME";"PRODGRP";"PRODPREIS"
"000010";"Zange ";"Werkzeug ";"65"
"000012";"Relay ";"Elektrik ";"52,12"
"000013";"Saege ";"Werkzeug ";"89,99"
"000045";"Welle ";"Mechanik ";"39,59"
"000050";"Spray ";"Werkzeug ";"20,8"


Wird in MS Excel aus der Exportdatei eine CSV-Datei erzeugt, fehlen diese führenden Nullen.

In unserem Beispiel wurde von MS Excel folgende Datei erzeugt:
PRODNR;PRODNAME;PRODGRP;PRODPREIS
10;Zange ;Werkzeug ;65
12;Relay ;Elektrik ;52,12
13;Saege ;Werkzeug ;89,99
45;Welle ;Mechanik ;39,59
50;Spray ;Werkzeug ;20,8


Um diese Datei korrekt in TABEX4 importieren zu können, müssen die betreffenden Character-Felder in TABEX4 mit dem Format Numeric (N) oder als Picture (PI) definiert werden. Dann ergänzt TABEX4 beim Import wieder die führenden Nullen.


Der Tabellenvergleich von TABEX4 kann verwendet werden, um die zu importierenden Daten vor dem Speichern mit dem letzten Stand der Daten in TABEX4 zu prüfen.

Dazu sind folgende Schritte nötig:

  • Daten importieren, aber Tabelle nicht speichern.

  • Auf Icon "mit anderer Tabelle vergleichen (Ctrl+D)" drücken.

  • Im folgenden Dialog"Auswählen Datenbank für Vergleich" keine Datenbank auswählen, sondern nur auf das Icon "auswählen (Alt+Ctrl+Shift+Right)" klicken (dadurch wird die aktuelle TABEX-Datenbank ausgewählt) und die Tabelle auswählen.

  • Danach werden alle Änderungen in Form eines Differenz-Protokolls angezeigt.

  • Mit dem Icon "Vergleichtabellen ein-/ausblenden" können die Vergleichtabellen (vorheriger und aktueller Stand) ausgeblendet werden. Dann wird das gesamte Differenz-Protokoll angezeigt.

Batch-Jobs

Ich möchte einen Parameter in einen Job einsteuern, aber die Ersetzung funktioniert nicht

Ein Parameter soll in einen Batch-Job eingesteuert werden. Dieser Parameter soll in den Systemeinstellungen definiert werden.

Vorgehensweise:

  • Verwenden Sie den Platzhalter in der Job-Inputtabelle.
    Z.B.: ‘database=&actdb’
  • Definieren Sie den Parameter in der Job-Parametertabelle.
    Z.B.: PAR=ACTDB; VAL=&P:DD_DEFAULT
  • Falls noch nicht geschehen, definieren Sie den Parameter in den User-Einstellungen, der Instanzkonfiguration oder den Systemeinstellungen.
    Z.B.: PAR=DD_DEFAULT; VAL=TABVSAM
  • Nach der Auswahl des Jobs werden die Parameterwerte angezeigt. Sie können so feststellen, ob die Platzhalter korrekt mit den Parameterwerten ersetzt wurden.

Wird der Parameter nicht übernommen, hat dies folgenden Grund:

  • Die Ersetzung der Platzhalter in der Input-Vorlage ist auf max. 8-stellige Namen beschränkt.
  • Daher muss der Parameter auf max. 8 Stellen gekürzt werden.
  • Ebenso muss der Parameter in der Parametervorlage und der Platzhalter in der Inputvorlage entsprechend geändert werden.

Siehe auch:

BOIDOC-209a_Config

Exits/Protokoll-Exits

Welche Exit-Möglichkeiten gibt es?

Was sind Exits?

Exits sind Programme der TABEX-eigenen Programmiersprache SSL. Sie können vom Kunden in TABEX4 eingebunden werden, um an gewünschter Stelle eigene Prüfungen, Nachbearbeitungen, usw. durchzuführen.

SSL bietet auch die Möglichkeit, externe Programme (PL/I, Cobol, C usw.) aufzurufen.

Exit-Möglichkeiten

  • Instanzinitialisierung (nach dem Laden der Instanzkonfigurationstabelle)
  • Setzen eines Wertes eines Systemparameters
  • nach Selektion eines Menüpunkts
  • Erzeugen eines TABEX View Statements für die dynamische Viewanzeige
  • Berechtigungsprüfung
  • Spezifizieren eines SSL-Programms als Handler für ein kundenspezifisches Icon
  • nach Selektion einer TABEX Tabelle aus dem TABEX Datenbankindex
  • Vorgabe für neues Tabellenversionsdatum
  • nach Commit eines Updates einer TABEX Tabelle
  • nach Online-Transfer von der Modifikationsdatenbank in die Produktionsdatenbank
  • nach Batch-Transfer von der Modifikationsdatenbank in die Produktionsdatenbank (TBVW02-TRANSFER)
  • Definieren von Sichten für das Laden von Daten aus relationalen Datenbanken (mit technischen Feldern bei Zeilenversionsführung)
  • nach dem Laden von Daten aus relationalen Datenbanken
  • vor dem Update von Daten in relationale Datenbanken
  • Übertragen von Jobparameterwerten
  • Protokoll-Exits, wenn in der Web-Applikation die Protokollierung eingeschaltet ist, bzw. für die Commands der Utilities TBVW01 und TBVW02. Protokoll-Exits können bei sämtlichen Tabellenänderungsmenüpunkten aufgerufen werden. (Die Namen der kundenspezifischen MOD-IDs müssen mit 'MY' beginnen.)
  • Ermitteln der TabellenID für den nächsten Step einer Tabellensequenz

Programmierhilfen

Für die Exit-Programmierung werden Table Manager Interfacefunktionen zur Verfügung gestellt, die in der Implementierung der Exits verwendet werden können:

  • Abfragen der aktiven Instanz
  • Abfragen der aktiven Datenbank
  • Löschen des aktiven TABEX Tabellenindex, sodass das System diesen Index wieder erneut aufbauen muss
  • Lesen des Tabellenstatus
  • Schreiben von Kundendaten (10 Bytes) in den Tabellenstatus
  • Methoden zur Ausgabe von Textzeilen und Messages
  • Starten von Jobs
  • Lesen von Systemparameterwerten
  • Abfragen der Modul-Parameter
  • Aufbauen einer Verbindung zu einer relationalen Datenbank
  • Laden einer RDB-Tabelle als TABEX DB in den Speicher
  • Abfragen der MOD-ID
  • Abfragen von Berechtigungen
  • Abfragen von Freigabeverfahren
  • Erstellen von Kunden-Protokolleinträgen
  • Abfragen von Tabellen-Sperreinträgen
  • Ausführen einer automatischen Datenbank-Allokation

Wenn Sie Fragen zur Exit-Programmierung haben, wenden Sie sich bitte an unseren Support. Gerne unterstützen wir Sie im Rahmen eines Consultings bei der Implementierung Ihrer Exits.

Siehe auch:

BOIDOC-209a_Config

Ich möchte einen Exit nach der Tabellenselektion, aber vor der Tabellenpflege aufrufen. Wie erreiche ich das?

Soll der Exit zwischen Selektion der Tabelle und Durchführung der aufgerufenen Funktion, wie z.B. der Pflege der Tabelle, aufgerufen werden, dann ist der Exit über Steuertabelle $TAB4PTC24 zu definieren. Details zu den Steuertabelleneinträgen und ein Beispiel finden Sie in BOIDOC-209a_Config.

 

Siehe auch:

BOIDOC-209a_Config

Wie kann ich in einem Exit eine selbstdefinierte Meldung ausgeben?

Wie kann ich eine überschriebene Tabelle aus der TABEX Datenbank auslesen?

Allgemeines

Wenn es sich bei der TABEX Datenbank um keine Random-Datenbank handelt und sie noch nicht reorganisiert wurde, können überschriebene Tabellenversionen mittels der Datenbank-Nummer noch gelesen werden.

Dabei ist als Tabellenname ‚&&nnnnnnnn‘ zu verwenden, wobei ‚nnnnnnnn‘ die Datenbanknummer ist.

Die Datenbanknummern zu den Tabellen einer TABEX Datenbank ist in Feld ‚TI_POSITION‘ der Datenbank-Indextabellen zu finden.

Datenbank-Indextabellen sind in BOIDOC-201_Basis beschrieben.

Funktion zur Ermittlung der Datenbank-Nummer

Im Table Manager Interface $TAB4PTINF gibt es die Funktion getDDNbr, welche zu einer erweiterten Tabellen-ID die Datenbank-Nummer zurückliefert.

Details zu der Funktion und ein Beispiel finden Sie in BOIDOC-209a_Config.

 

Siehe auch:

BOIDOC-201_Basis

BOIDOC-209a_Config

Wie kann ich im Protokoll-Exit feststellen, welche Instanz gerade aktiv ist?

Die aktuelle Instanz kann über das TABEX4 Interface abgefragt werden.

Das TABEX4 Interface muss mittels "%use $TAB4PTINF" in Ihr Exit-Programm eingebunden werden. Die aktive Instanz kann dann mittels "$TAB4_INTF.getInst()" abgefragt werden, z.B.:

[...]

%use $TAB4PTINF

dcl instance char(08)

instance = $TAB4_INF.getInst()

[...

Siehe auch:

BOIDOC-209a_Config

Gültig ab TABEX4 Version 4.1.2

Wie kann ich in einem Exit eine selbstdefinierte Meldung ausgeben?

Eigene Meldungen erstellen

Eigene Meldungen können mit Menüpunkt Administration / Anwendung / Explorer-Menü / Meldung bearbeiten in die Kunden-Meldungstabelle $TAB4PL030 eingetragen werden.

 

Beispiel:

Meldungseintrag in $TAB4PL030:

Nachr.Nr

Typ

Nachricht

PRO0001

E

Testmeldung für Tabelle &1 im Fehlerfall

Ausgabe von Meldungen per Interfacefunktion

Mit den Interfacefunktionen $tab4_intf.putTXT und $tab4_intf.putMSG können Meldungen und Texte ebenfalls ausgegeben werden.

Details finden Sie in BOIDOC-209a_Config.

Ausgabe von Meldungen per Exit-Parameter

Hat der Exit Parameter für Meldungsnummer und Meldungsparameter, so kann im Fehlerfall durch entsprechende Setzung dieser Parameter die Ausgabe einer Meldung veranlasst werden.

Beispiel für Protokoll-Exit PROT_OPEN:
Im Fehlerfall (apprc > ' ') wird die Meldung PRO001 ausgegeben, nachdem der Platzhalter &1 durch den Tabellennamen ‚TAB001‘ ersetzt wurde.

Setzung im Exit-Programm:

dcl tabname char(10) inppar 03 /* table name */

dcl apprc char(01) outpar 07 /* return code: apprc<>' '=> no logging */

dcl msg_id char(07) outpar 08 /* message ID */

dcl msg_prm char(450) outpar 09 /* message parameter */

apprc = 'E'

msg_id = 'PRO0001'

msg_prm = tabname

Siehe auch:

BOIDOC-209a_Config

Instanzensystem

Was sind Instanzen und wozu dienen sie?

Neben der allgemeinen Konfiguration von TABEX4 für das Unternehmen können für einzelne Organisationseinheiten des Unternehmens Instanzen als eine Art Sub-System konfiguriert werden.

Eine Instanz ist ein definiertes Konfigurations-Set, mit dem der Inhalt und die möglichen Funktionen je Instanz eingeschränkt bzw. vorausgewählt werden können.

Das Konfigurations-Set "Instanz" kann beispielsweise folgendes beinhalten:

  • Welcher Menübaum wird angezeigt?
  • Welche Berechtigungen kommen zum Tragen?
  • Welche Datenbanken werden verwendet?
  • Welche Voreinstellungen gibt es (z.B. SQL-Creatorname)?
  • uvm.

Wenn Instanzen aktiviert sind, wird vor die Anzeige des Explorer-Menüs die Instanz-Auswahl geschaltet. Die von einem User zuletzt gewählte Instanz wird bei der nächsten Anmeldung automatisch wieder ausgewählt.

Um eine andere Instanz auszuwählen, muss in der Navigationsleiste "TABEX4 Table Manager" ausgewählt werden.

Wie richtet man eine Instanz ein?
Was eine Instanz ausmacht, ist im Wesentlichen in einer sogenannten Instanz-Definitionstabelle in Form von Parameterzuweisungen (Name=Wert) gespeichert.
Zur Konfiguration der Instanzen stehen im Menü der TABEX-Anwendung entsprechende Administratorfunktionen zur Verfügung, zum Beispiel:

  • Instanzentext bearbeiten
  • Instanzenbaum bearbeiten
  • Instanzenkonfiguration bearbeiten

Daneben besteht die Möglichkeit, mit Hilfe der TABEX Utility TBVW01 Instanzen automatisiert zu erzeugen. Diese Batch-Methode hat gegenüber den interaktiven Menüfunktionen den Vorteil, dass damit eine große Anzahl von Instanzen in einem einzigen Programmdurchlauf erstellt werden kann.

Wie kann ich Datenbanken instanzabhängig verwalten?

Neue Datenbank anlegen

Das folgende Beispiel zeigt, wie eine neue Datenbank TABTEST in der TABEX-Anwendung definiert und einer bestimmten Instanz zugewiesen wird.

Unter Administration/Datenbanken/TABEX Datenbank/Datenbankverwendung bearbeiten können die Datenbank, Sicherheitsstufe und Datenquelle angepasst werden.

Hier kann die Datenbank TABTEST eingetragen werden:

Unter Administration/Datenbanken/TABEX Datenbank/Datenbanknamen bearbeiten wird der Datenbank TABTEST eine Beschreibung zugeordnet:

Unter Administration/Datenbanken/TABEX Datenbank/Datenbanktypen bearbeiten wird der Datenbank TABTEST ein Typ zugeordnet:

Neue Datenbank als Standard-Datenbank einer Instanz festlegen

Die zuvor angelegte Datenbank TABTEST wird der Instanz Produktion 005 zugewiesen. Unter Administration/logische Instanzen/Inst. Konfiguration bearbeiten wird die Instanz ausgewählt.

Anschließend wird die Konfiguration der Instanz Produktion 005 angezeigt. Um TABTEST als Standard-Datenbank zu verwenden, muss der Parameter DD_DEFAULT mit dem Wert TABTEST eingetragen werden:

Nach der Speicherung der Tabelle muss das Instanzensystem aktiviert werden.

Beim nächsten Aus- und Einloggen kann die Instanz Produktion 005 ausgewählt werden, wobei automatisch TABTEST als Datenbank ausgewählt wird.

Instanzspezifische Datenbanken hinzufügen

Um Instanzen TABEX-Datenbanken zuzuweisen, muss unter Administration/logische Instanzen/Inst. Konfiguration bearbeiten die jeweilige Instanz ausgewählt und eingestellt werden.

Im folgenden Beispiel wird die Instanz "Produktion 005" bearbeitet. Dazu wird der Parameter ("PAR") DBCON_TBXI mit der Tabellen-ID als Parameter-Wert ("VAL") in die Konfiguration der Instanz eingetragen:

Unter Administration/logische Instanzen/Inst.-TABEX-DB-Verwendg. bearb. wird der Inhalt der Tabellen-ID von DBCON_TBXI bearbeitet. (Sollte die Tabelle der Tabellen-ID nicht verfügbar sein, wird eine leere Kopie der Systemtabelle $TAB4PTC50 erstellt.):

Anmerkung:

Wird der Inhalt von DSNAME nicht unter Apostroph gesetzt, wird die Benutzer-Id des eingeloggten Benutzers als First Qualifier abgerufen. Wird dieser Modus verwendet, können benutzerspezifische Datenbanken, deren DSN auf das Namensschema userid.contens-of-dsname passen, verwendet werden. Ist der Benutzer im obigen Beispiel eingeloggt als BOI, dann tritt die dynamische Allokierung mit BOI.INST1.TDB ein.

Wenn Sie nicht für jeden benutzerdefinierten DDNAME eine Beschreibung setzen wollen, können Sie eine Beschreibung für alle leeren DDNAME-descriptions im Menüpunkt Administration/Datenbanken/TABEX Datenbank/Datenbanknamen bearbeiten setzen. Fügen Sie dazu eine neue Zeile mit leerer Datenbank und einer Beschreibung wie folgt ein:

&DSN wird später durch den DS-Namen der Datenbank ersetzt.

Nun (wenn der Benutzer die nötigen Security-Rechte besitzt) sieht der Benutzer zusätzlich die instanzspezifischen TABEX-Datenbanken in der TABEX-Datenbank-Auswahlliste unter TABEX Datenbank/Verbindung herstellen:

Siehe auch:

  Wie kann ich das Instanzensystem aktivieren und konfigurieren?
BOIDOC-209a_Config
BOIDOC-209b_SecInst

Wie kann ich das Instanzensystem aktivieren und konfigurieren?

Zur Aktivierung des Instanzensystems werden zwei Systemparameter-Tabellen benötigt:

  • $TAB4PTC02 (TABCTL) (= originale Systemeinstellungen)
  • $TAB4PTC06 (TABCTL) (= kundenspezifische Systemeinstellungen)

Der Parameter FL_INSTANC der Tabellen zeigt an, ob die Instanzen aktiviert ("Y") oder deaktiviert ("N") sind. "N" bedeutet, dass die Standard-Instanz immer verwendet wird (standardmäßig "N").

Der Parameter kann über Administration/Anwendung/Allgemeine Einstellungen/Original-Systemeinst. anzeigen gefiltert und angezeigt werden:

Parameter FL_INSTANC der Systemparameter-Tabelle $TAB4PTC02:

Um das Instanzensystem zu aktivieren muss der Parameter FL_INSTANC auf "Y" gesetzt werden. Dazu wird er im Verzeichnis Administration/Anwendung/Allgemeine Einstellungen/Systemeinstellungen bearbeiten eingetragen, wobei der Parameter der Tabelle $TAB4PTC02 ignoriert wird:

Geänderter Parameter FL_INSTANC in der Systemparameter-Tabelle $TAB4PTC06:

Folgende weitere Schritte sind durchzuführen:

  • Definition des Instanzenbaums
  • Konfiguration der einzelnen Instanzen

Beim Aus- und erneutem Einloggen sind die Instanzen unter Login >> BOI >> TABEX4 Tabellenverwaltung sichtbar:

Siehe auch:

BOIDOC-209b_SecInst

TABEX4 Protokolldatenbanken (TABPRO, TABCMP, TABPCA)

Was wird in den Datenbanken TABPRO und TABCMP gespeichert?

Was wird in TABPRO gespeichert?

In TABPRO werden Protokolleinträge gespeichert. Diese sind keine Tabellen, sondern vergleichbar mit Statuseinträgen und daher im Tabellenverzeichnis nicht sichtbar.

Was wird in TABCMP gespeichert?

Zugehörige Differenztabellen bzw. Utility-Protokolle werden in TABCMP gespeichert, welche auch im Menüpunkt Revision/Änderungsprotokoll anzeigen angezeigt werden können.

Siehe auch:

BOIDOC-206_Utility

Was bewirken die TABEX4 Utility-Funktionen PROTARCH und PROTPSUM?

Mit TBVW01-PROTPSUM werden die Protokolleinträge eines durch den 1. Parameter bestimmten Zeitraumes zu einer Version der Tabelle $TAB4PTPRA zusammengefasst, die in der Datenbank viel kompakter gespeichert werden kann.

Mit TBVW01-PROTARCH können ältere Versionen von $TAB4PTPRA und die zugehörigen Tabellen von Datenbank TABCMP in die Archiv-Datenbank TABPCA ausgelagert werden. Als erster Parameter ist dabei die Anzahl der Versionen von $TAB4PTPRA anzugeben, die in TABPRO verbleiben. TABPCA sollte als Massendatenbank angelegt werden.

Die bei PROTPSUM und PROTARCH verwendeten Reo-Files werden nach fehlerfreier Durchführung nicht mehr benötigt.


Siehe auch:

BOIDOC-206_Utility
BOIDOC-201_Basis

Wie können Protokolldatenbanken TABPRO bzw. TABCMP reorganisiert oder vergrößert werden?

Die Datenbanken TABPRO und TABCMP enthalten einerseits Spezialeinträge (Protokolleinträge), die vom "normalen" Reorganisieren nicht erfasst werden. Andererseits hängen die Daten dieser beiden Datenbanken zusammen. Aus diesen Gründen dürfen die Datenbanken TABPRO und TABCMP nicht mit den Utility-Befehlen TABN03-SAVE bzw. TABN01-LOADDB reorganisiert werden!


Wird die Datenmenge in TABPRO und/oder TABCMP zu groß bzw. die Datenbanken voll, stehen folgende Möglichkeiten zur Verfügung:

  • Zusammenfassen der Protokolleinträge in Tabellen mit der Utility-Funktion TBVW01-PROTPSUM
  • Auslagern der Protokolleinträge und Tabellen in die Protokoll-Archivdatenbank TABPCA mit der Utility-Funktion TBVW01-PROTARCH
  • Vergrößern der Datenbanken

Vergrößern der Datenbanken TABPRO bzw. TABCMP

Um die Datenbank TABPRO und/oder TABCMP zu vergrößern, sind jeweils folgende Schritte durchzuführen:

  1. Erzeugen eines Reo-Files mit allen Einträgen und Tabellen mit folgenden TABN03-Befehlen:

    DBOSELECT,**********,**,ALL
    DBOSAVE

  2. Erstellen einer Datenbank in der gewünschten Größe (TABN01-INIT): Das sollte sowohl für TABPRO als auch für TABCMP eine Standard-Datenbank MIT Komprimierung sein (Init-Typ 'T3C', dieser ist bei TABN01-INIT die Annahme).
  3. Laden aller Daten aus dem in Schritt 1. erzeugten Reo-File in die in Schritt 2. erzeugte Datenbank mit dem TABN01-Befehl TABN01-DBOLOAD


Siehe auch:

Was bewirken die TABEX4 Utility-Funktionen PROTARCH und PROTPSUM?

Mit welchem Datenaufkommen muss bei den Protokolldatenbanken TABPRO und TABCMP gerechnet werden?

BOIDOC-206_Utility

Mit welchem Datenaufkommen muss bei den Protokolldatenbanken TABPRO und TABCMP gerechnet werden?

Das Datenaufkommen ist sehr individuell, und hängt von der Anzahl der protokollierten Aktionen ab, bzw. bei welchen Aktionen Protokolle in TABCMP geschrieben werden.

Die Konfiguration ist mit den Funktionen unter Administration/Änderungsprotokoll möglich.


Zu den Protokolleinträgen in TABPRO:

  • Pro Datenbank-Record können 20 Einzeleinträge gespeichert werden.
  • Nach Zusammenfassung in $TAB4PTPRA-Versionen bringt man pro Datenbank-Record ca. 100 Einträge unter.

Siehe auch:

BOIDOC-206_Utility

Wie werden Protokolleinträge archiviert?

Die Datenbanken für die Protokollierung (TABPRO und TABCMP) dürfen NICHT wie andere TABEX-Datenbanken mit TABN03-SAVE bzw. TABN01-LOADDB reorganisiert werden, da sonst die Protokolleinträge verloren gehen!

Für das Zusammenfassen von Protokolleinträgen in Tabellen gibt es die Utility-Funktion TBVW01-PROTPSUM.

Mit TBVW01-PROTARCH erfolgt das Übertragen von Protokollierungsdaten in eine Archivdatenbank bei gleichzeitiger Reorganisation von TABPRO und TABCMP.

TABEX4 Utility-Funktionen

Wie vergrößere ich TABEX-Datenbanken, die keine Protokolldatenbanken sind?

Grundsätzliches

Vergrößern von TABEX Datenbanken

Die im folgenden beschriebene Vorgehensweise bezieht sich auf 'normale' TABEX Datenbanken mit und ohne Komprimierung sowie Random-Datenbanken mit und ohne Komprimierung.

Da TABEX Massendatenbanken sich automatisch erweitern, ist ein Vergrößern aus TABEX-Sicht nicht möglich. Sollte es nötig sein, für eine TABEX Massendatenbank einen anderen Basis-File (z.B. VSAM-Cluster) anzulegen, kann diese Vorgehensweise auch für diesen Datenbanktyp angewendet werden.

 

Vergrößern von Protokolldatenbanken

Für TABEX-Datenbanken, die als Protokolldatenbanken verwendet werden (TABPRO, TABCMP, TABPCA) gibt es ein eigenes Verfahren. (siehe Wie können Protokolldatenbanken TABPRO bzw. TABCMP reorganisiert bzw. vergrößert werden?) Das unten beschriebene Verfahren DARF für Protokolldatenbanken NICHT verwendet werden, da sonst Daten verloren gehen!

Verfahren 1

Schritt 1

Sichern der Daten in einem TABEX-SAVE-File mit Utility TABN03:

  • Variante 1 - es sollen nur die aktiven Daten gesichert werden:
      SAVE
  • Variante 2 - es sollen auch überschrieben Versionen gesichert werden:
      SAVE,,ALL

Achtung: Gelöschte Versionen werden mit keiner der beiden Varianten mitgesichert.

 

Schritt 2

Wenn nötig, ist jetzt im Filesystem ein geeigneter File (z.B. VSAM-Cluster) anzulegen.

 

Schritt 3

Initialisieren der TABEX Datenbank mit gewünschtem Typ in geeigneter Größe mit TABN01-INIT.

 

Schritt 4

Einspielen des in Schritt 1 erzeugten SAVE-Files mit TABN01-LOADDB.

Verfahren 2

Dieses Verfahren kann ab TABEX-Version 3.2.0 verwendet werden. Bei diesem Verfahren wird das Sichern in Form allgemeiner Datenbankobjekte durchgeführt.

Im Gegensatz zum obigen Verfahren werden hier

  • Tabellen-Statuseinträge, Texttabellen und AI-Tabellen auch dann in den SAVE-File geschrieben, wenn es keine Datentabelle dazu gibt.
  • Statuseinträge aller Typen (nicht nur Tabellen-Statuseinträge sondern z.B. auch Protokolleinträge) in den SAVE-File geschrieben.

Schritt 1

Sichern der Daten in einem TABEX-SAVE-File mit Utility TABN03:

  • Variante 1 - es sollen nur die aktiven Daten gesichert werden:
      DBOSELECT,**********,**,VAL DBOSAVE
  • Variante 2 - es sollen auch überschrieben Versionen gesichert werden:
      DBOSELECT,**********,**,ALL DBOSAVE

Achtung: Gelöschte Versionen werden mit keiner der beiden Varianten mitgesichert.

 

Schritt 2

Wenn nötig, ist jetzt im Filesystem ein geeigneter File (z.B. VSAM-Cluster) anzulegen.

 

Schritt 3

Initialisieren der TABEX-Datenbank mit gewünschtem Typ in geeigneter Größe mit TABN01-INIT.

 

Schritt 4

Einspielen des in Schritt 1 erzeugten SAVE-Files mit TABN01-DBOLOAD.

Siehe auch:

Utility-Befehle: BOIDOC-206_Utility

TABEX-Datenbanktypen: BOIDOC-201_Basis

Was bedeutet die Meldung 'Zweite Vergleichstabelle nicht vorhanden' bei der Änderungsprotokollanzeige bzw. TBVW01-PROTREP?

Bei protokollierten Aktionen erstellt TABEX4 ein Differenzprotokoll, sobald bei dieser Aktion eine bereits bestehende Tabellenversion überschrieben wird. Mit dem Menüpunkt ‚Änderungsprotokoll anzeigen‘ können Sie sich dieses Differenzprotokoll anzeigen lassen.

Gab es jedoch noch keine bestehende Version (d.h. die Tabellenversion wurde bei der protokollierten Aktion neu erzeugt), kann TABEX4 kein Differenzprotokoll erstellen. In diesem Fall wird stattdessen oben angeführte Meldung angezeigt, wenn Sie versuchen, sich den Protokolleintrag zur Aktion (im unserem Fall ‚Online-Transfer in Produktion‘ oder ‚Batch-Transfer in Produktion‘) anzeigen zu lassen.

Das Vergleichen verschiedener Versionen ist im Rahmen von "Tabelle anzeigen" möglich.

Wie kann ich ein Utility-Logfile via E-Mail versenden?

Utility-Logfiles können mit der Utilityfunktion SENDMAIL versendet werden.

Als Standard-Utility-Logfile ist die Datei SYSPRINT festgelegt.

Durch die SYSPARM Einstellung 'USDLG=Y' wird die Utilityfunktion SENDMAIL verwendet, um eine Kopie des Utility-Logfiles als E-Mail Anhang zu verschicken.

Die Angaben für diese Verschickung (E-Mail-Adresse, Kopienempfänger usw.) werden aus Systemparametern ermittelt. Diese sind in der Steuertabelle $TAB_UTUSP einzutragen.

 

Mit dem Befehl UTLSETTING können temporär Systemparameter für den aktuellen Ablauf gesetzt werden.

Folgende Systemparameter werden für diese Funktionalität verwendet:

  • Empfänger-E-Mail-Adresse ('An'): SDLG_TO
  • Kopie-Empfänger-E-Mail-Adresse ('CC'): SDLG_CC
  • Blindkopie-Empfänger-E-Mail-Adresse ('BCC'): SDLG_BCC
  • Betreff: SDLG_SUBJ
  • Datei mit dem Mailtext: SDLG_TEXTF
  • Attachment-Dateiname: SDLG_ATNAME
  • Attachment-MIME-Typ: SDLG_ATTYP

 

Voraussetzung für die Verwendung von 'USDLG=Y' ist, dass die für die Kopie des Utility-Logfiles und Befehl SENDMAIL nötigen Einstellungen erfolgt sind:

  • Systemparameter für Befehl SENDMAIL:
    • Servername oder IPv4-Adresse vom SMTP-Mail-Server: MAIL_HOST
    • Portnummer vom SMTP-Mail-Server: MAIL_PORT
    • Sender-E-Mail-Adresse ('Von'): MAIL_FROM
    • Codepage für den E-Mail-Text: MAIL_TCCP
  • Eintrag in Steuertabelle $TAB4PTC75 (Datenbank TABCTL) für die Mail-Parameterdatei (UTLMSPC). Details dazu finden Sie in BOIDOC-206.
  • Eintrag in Steuertabelle $TAB4PTC75 (Datenbank TABCTL) für das Erstellen der Kopie des Utility-Logfiles (BOIULOG). Details dazu finden Sie in BOIDOC-206.

 

Siehe auch:

BOIDOC-206_Utility

Gültig ab Version 4.2.1

Was ist der Unterschied zwischen TABN03.SAVE und TABN03.DBOSAVE?

Format des Reo-Files

Mit SAVE werden die Datenbankobjekte (Tabellen, Statuseinträge) geladen, und dann unkomprimiert in den Reo-File geschrieben.

Mit DBOSAVE werden die komprimierten Datenbankobjekte direkt in den Reo-File geschrieben. Daher gibt es für DBOSAVE mit TABN01-DBOADD bzw. TABN01-DBOLOAD eigene Ladefunktionen für Reo-Files, die mit DBOSAVE erzeugt wurden.

Reo-Files, die beide Formate enthalten, sind nicht verarbeitbar.

Selektion

SAVE sichert ausgehend von den (selektierten) Tabellenversionen, und nimmt die zugehörigen AI-Tabellen, Texttabellen und Statuseinträge mit.
 

DBOSAVE behandelt alle "Datenbankobjekte" gleich, und berücksichtigt nur die Selektionen mit DBOSELECT und DBOOMIT.
Daraus ergeben sich folgende Unterschiede:

  • Es werden auch Datenbankobjekte wie z.B. Protokolleinträge gesichert, die von SAVE nicht erfasst werden.
  • Es werden AI-Tabellen, Texttabellen und Statuseinträge auch gesichert, wenn es keine Tabellen mehr dazu gibt.
  • Es werden AI-Tabellen, Texttabellen und Statuseinträge nicht automatisch mit den Tabellen mitgesichert, sondern nur wenn durch DBOSELECT ausgewählt.

Siehe auch:

BOIDOC-206_Utility

Gültig ab Version 4.2.2

Was soll ich tun, wenn bei Ausführung von Utility-Funktionen Meldungen ohne Fehlertext erscheinen?

Wenn Ausführung von Utility-Funktionen der Text der Meldungen ERRnnnn, INFnnnn und SECnnnn nicht ausgegeben wird, könnte es sein, dass die Datenbank-Allocates für die APPLNG-Verkettung fehlen.

Kontrollieren Sie Ihre Einstellungen und ergänzen Sie diese gegebenenfalls.

Wie kann ich mit Utility TABN05 Tabellendaten kopieren und verschieben?

TABEX4 bietet Funktionen zum Kopieren und Verschieben von Tabellendaten zwischen TABEX-Tabellen, Tabellen aus relationalen Datenbanken, sequentiellen Dateien, VSAM-Dateien und 'flat files'.

Diese Kopier- und Verschiebefunktionen können entweder in Batch ausgeführt werden oder als Menüpunkte im Tabellenmanager. Durch Konvertierungsfunktionen können die Daten in jedem Format bereitgestellt werden.

TABEX4 bietet sowohl die Möglichkeit, Tabellen in der gleichen Datenbank zu speichern, als auch Daten zwischen verteilten Datenbanken im Netzwerk (lokale Datenbanken, Datenbanken auf verschiedenen Computern oder Remote-Datenbanken) zu überschreiben.

 

Die TABEX4 Kopier- und Verschiebeoperationen werden mit dem Utility TABN05 durchgeführt:

  • Mit INPUT wird die Datenquelle definiert. Diese kann eine sequentielle Datei, eine TABEX Tabelle oder eine Tabelle einer relationalen Datenbank sein.

  • Mit OUTPUT wird das Datenziel definiert. Auch dies kann eine sequentielle Datei, eine TABEX Tabelle oder eine Tabelle aus einer relationalen Datenbank sein. Somit sind sämtliche Kombinationen von Datenquellen und Datenzielen für das Kopieren möglich.

  • Mit DATTRAN und FLDTRAN kann definiert werden, welche Felder in welcher Reihenfolge in die Zieltabelle übernommen werden sollen.

  • Es ist auch möglich, die Zeilen, die transferiert werden sollen, mit den Befehlen INCLUDE und EXCLUDE einzuschränken.

  • Mit TRANSFER wird der Datentransfer durchgeführt.

  • Es besteht auch die Möglichkeit, mit den Befehlen EXPORT und IMPORT Daten aus Tabellen in eine sequentielle CSV-Datei zu exportieren bzw. von einer sequentiellen CSV-Datei in eine Tabelle zu importieren. Hierbei gibt es wieder die Möglichkeit, die alten Daten dieser Tabelle zu überschreiben oder zu den bestehenden Daten hinzuzufügen.

Beispiele

Beispiel 1: Transfer einer sequentiellen Datei in eine Einversions-TABEX Tabelle

IN,,F,,''TEST.INPUT.FILE1'',SHR

- Output file = single version TABEX table

OUT,,T,,,,,TESTTAB1,00000000

- Execute transfer

TRANSFER

Beispiel 2: Transfer einer TABEX Tabelle in eine DB2 Tabelle

- Input file = TABEX table

IN,,T,,,,,TESTTAB2

- Create DB2 connection

DB2OPEN,TABEX3,DSNA

- Output file = DB2 table

OUT,,D,,BOI.DB2TEST1

- Execute transfer

TRANSFER

Beispiel 3: Daten aus TABEX-Datenbank TABVSAM lesen und eine DB2 Datenbank schreiben

- TABEX-Datenbank aktivieren

db=tabvsam

- Connect zu relationaler Datenbank

sqlopen,dsn=db2win

- Erzeugen temporären View zur Verwendung als Input-Datei

tempview,tmpv

select * from pl1test where index(Name,'Meyer ') > 0

- spezifizieren INput- und Output-Dateien

INPUT,,T,,,,,tmpv,*TVW

OUTPUT,ADD,D,,boi.sqltest

- Transfer durchführen

TRANSFER

Beispiel 4: Daten aus DB2 Datenbank lesen und in die sequentielle Datei TABOUT schreiben

- TABEX-Datenbank aktivieren

db=tabvsam

- Ausgabefile zuordnen (Windows)

setpar,1

NOALIAS DIO VAR 300 CRLF NOLEN A2E UNB

free,tabout

alloc,tabout,T:\.txt,%PAR01

- Connect zu relationaler Datenbank

sqlopen,dsn=db2win

- spezifizieren Input- und Output-Dateien

INPUT,,D,45,boi.sqltest,,,pl1test,99999999

output,,V,300

- Alle Zeilen mit 010040 <= Personalnummer <= 010070, bei denen

- das Gehalt nicht kleiner als 5000 ist

INCLUDE,personalnummer,GL,010040,010070

exclude,gehalt,<,5000

- Festlegen der Ausgabe:

- Feld Personalnummer an Ausgabeposition 1

dattran,personalnummer,,,,1

- Konstante '->' an Ausgabeposition 7

dattran,->,2,*C,,7,2,CH

- Feld Gehalt nach Umwandlung in Character an Ausgabeposition 9

dattran,gehalt,,,,9,10,CH

- Konstante '->' an Ausgabeposition 19

dattran,->,2,*C,,19,2,CH

- Feld Name an Ausgabeposition 21

dattran,name,,,,21

- TRANSFER durchführen

transfer

Wie verschicke ich E-Mails aus Utility-Abläufen?

Zum Versenden von E-Mails aus Utility-Abläufen kann die Utility-Funktion SENDMAIL verwendet werden.

 

Folgende Parameter müssen gesetzt werden:

  • Empfänger-E-Mail-Adresse ('An'): SM_TO
  • Kopie-Empfänger-E-Mail-Adresse ('CC'): SM_CC
  • Blindkopie-Empfänger-E-Mail-Adresse ('BCC'): SM_BCC
  • Betreff: SM_SUBJ
  • Datei mit dem Mailtext: SM_TEXTF
  • Attachment-Dateiname inkl. Pfad: SM_ATFN
  • Attachment-Dateiname ohne Pfad: SM_ATNAM
  • Attachment-MIME-Typ: SM_ATTYP

 

Folgende Systemparameter müssen für den Befehl SENDMAIL gesetzt werden:

  • Servername oder IPv4-Adresse vom SMTP-Mail-Server: MAIL_HOST
  • Portnummer vom SMTP-Mail-Server: MAIL_PORT
  • Sender-E-Mail-Adresse ('Von'): MAIL_FROM
  • Codepage für den E-Mail-Text: MAIL_TCCP

 

Beispiel:

funcpar,sm-to,'test@abc.at'

funcpar,sm-cc,'office@abc.at'

funcpar,sm-subj,'Utility-Doku im Anhang'

funcpar,sm-textf,W:/Mailtext.txt

funcpar,sm-atfn,'W:/BOIDOC_206_utility_en.pdf'

funcpar,sm-attyp,'application/pdf'

funcpar,sm-atnam,'BOIDOC_206_utility_en.pdf'

sendmail

 

Siehe auch:

BOIDOC-206_Utility

TABEX4 Protokollierender Callserver (BOITPSV)

Wie funktionieren Export und Reorganisation der Callserver-Protokolldaten?

ÜBERBLICK

BOI hat einen neuen, komfortablen Ablauf für den Export von Callserver-Protokolldaten sowie für die datumsgesteuerte Bereinigung und Reorganisation der Callserver-Protokolldatenbank erstellt.

Diesen Ablauf stellen wir Ihnen in Form von Batch-Job-Templates bereit.

Für jedes unterstützte Betriebssystem gibt es ein Template. Dieses Template muss noch mit den aktuellen Speicherorten der Dateien ergänzt werden, da diese Speicherpfade installationsabhängig sind.

 

Die Batch-Jobs müssen für jede Callserver-Protokolldatenbank durchgeführt werden.

Bei Vorhandensein mehrerer Callserver-Protokolldatenbanken müssen die Batch-Jobs für jede dieser Datenbanken angepasst und durchgeführt werden.

Dabei ist darauf zu achten, dass für unterschiedliche Protokolldatenbanken auch unterschiedliche Namen bzw. Speicherorte der Dateien verwendet werden.

ABLAUF FÜR DEN EXPORT UND DIE REORGANISATION DER CALLSERVER-PROTOKOLLDATEN

Job CPEXPORT: Exportieren der Callserver-Protokolldaten

Dieser Job umfasst folgende Schritte:

  1. Exportieren aller Einträge der Callserver-Protokolldatenbank im CSV-Format
  2. Erzeugen einer REO-Datei mit allen Einträgen der Callserver-Protokolldatenbank
  3. nur im z/OS Template: FTP-Step, mit dem die Dateien transportiert werden.
    Sollten Sie den FTP-Step manuell durchführen, vergessen Sie bitte nicht, die REO-Datei binär zu transferieren!
    Unter Unix, Linux, Solaris und Windows ist der FTP-Step manuell durchzuführen, da es eine Vielfalt an Möglichkeiten gibt, die Daten vom TABEX-Server nach Windows zu transferieren (ftp, Netzverzeichnis, …). Achten Sie bitte auch hier darauf, die REO-Datei binär zu transferieren.

Die Callserver-Protokolldatenbanken müssen genügend Platz für alle in sie protokollierenden Callserver jeweils für den Zeitraum von 3 Jahren haben. Das sind konkret 500*3=1500 Records á 8185 Bytes pro Callserver.

Übermittlung der REO-Dateien an BOI

Für die Auswertung benötigt unser Support die erzeugten REO-Dateien aller Callserver in gezippter Form.

Sollte die ZIP-Datei eine Größe von 10 MB übersteigen, splitten Sie sie bitte beim Zippen in Teildateien auf.

Kontaktieren Sie uns für die weitere Vorgehensweise.

Callserver-Auswertung

Unser Support erstellt auf Basis der übermittelten Daten eine Callserver-Auswertung für das letzte Nutzungsjahr.

Diese dient für alle Kunden, die das Produkt TABEX4 Java Access flexible lizenziert haben, als Grundlage für die Berechnung des Nutzungsentgelts des folgenden Nutzungsjahres.

Job CPREORG: Reorganisieren der Callserver-Protokolldatenbank

Nachdem BOI die übermittelten Daten geprüft und die Callserver-Auswertung durchgeführt hat, ist CPREORG für jeden Callserver auszuführen.

Damit wird die Callserver-Protokolldatenbank reorganisiert. Es bleiben nur die Einträge der letzten beiden Jahre erhalten.


Vorgehensweise:

  1. Callserver vor Ausführung des Jobs beenden
  2. CPREORG ausführen
  3. Callserver erneut starten

Z/OS: DETAILLIERTE BESCHREIBUNG

Job CPEXPORT

CPEXPORT muss für jeden Callserver angepasst werden, damit Dateien nicht überschrieben werden:

  1. DSN der Callserver-Protokolldatenbank (CPTDB)
  2. DSN der Ergebnis-CSV-Datei (CPEXPF)
  3. DSN der Ergebnis-REO-Datei (TABSAV)
  4. Zugangsdaten für FTP: Host, Username und Passwort
  5. remote CSV-Quelldatei für FTP
  6. lokale CSV-Zieldatei für FTP
  7. remote REO-Quelldatei für FTP
  8. lokale REO-Zieldatei für FTP


Nach Ausführung dieses Batch-Jobs existieren lokal folgende Dateien:

  1. CSV-Datei mit exportierten Callserver-Protokolldaten
  2. REO-Datei der Callserver-Protokolldatenbank

Senden Sie nun die REO-Dateien in gezippter Form an unseren Support.

Job CPREORG

Nachdem BOI die übermittelten Callserver-Protokolldaten geprüft und ausgewertet hat, muss CPREORG für jeden Callserver angepasst und ausgeführt werden. Damit werden sämtliche Callserver-Protokolldatenbanken bereinigt und reorganisiert.


In diesem Job müssen angepasst werden:

  1. DSN der Callserver-Protokolldatenbank (CPTDB)
  2. DSN der REO-Datei (CPREORG)


Vor Ausführung dieses Jobs muss der Callserver beendet werden. Im Anschluss an diesen Job muss der Callserver erneut gestartet werden:

  1. Callserver vor Ausführung des Jobs beenden
  2. CPREORG ausführen
  3. Callserver erneut starten

LINUX, AIX, SOLARIS: DETAILLIERTE BESCHREIBUNG

Skript cpexport

Dieses Skript muss für jeden Callserver angepasst werden, damit Dateien nicht überschrieben werden:

  1. Pfad und Dateiname der Callserver-Protokolldatenbank (BOICPDB)
  2. Pfad und Dateiname der Ergebnis-CSV-Datei (CPEXPFILE)
  3. Pfad und Dateiname des Ergebnis-REO-Datei (CPREOFILE)


Nach Ausführung dieses Skripts existieren folgende Dateien:

  1. CSV-Datei mit exportierten Callserver-Protokolldaten
  2. REO-Datei der Callserver-Protokolldatenbank

Es wird im Gegensatz zu z/OS kein automatischer FTP gestartet, der die Dateien auf den lokalen Rechner transferiert.

Die CSV-Datei kann mittels FTP im Textmodus auf den lokalen Rechner transferiert bzw. über ein Netzlaufwerk angesprochen werden.

Die REO-Datei muss im Binärmodus mittels FTP auf den lokalen Rechner transferiert bzw. über ein Netzlaufwerk angesprochen werden.

Senden Sie nun die erzeugten REO-Dateien in gezippter Form an unseren Support.

Skript cpreorg

Nachdem BOI die übermittelten Callserver-Protokolldaten geprüft und ausgewertet hat, muss CPREORG für jeden Callserver angepasst werden. Damit werden sämtliche Callserver-Protokolldatenbanken bereinigt und reorganisiert.

 

In diesem Skript müssen angepasst werden:

  • Pfad und Dateiname der Callserver-Protokolldatenbank (BOICPDB)


Vor Ausführung dieses Skripts muss der Callserver beendet werden, im Anschluss an dieses Skript muss der Callserver erneut gestartet werden:

  1. Callserver vor Ausführung des Jobs beenden
  2. Skript cpreorg ausführen
  3. Callserver erneut starten

WINDOWS: DETAILLIERTE BESCHREIBUNG

Skript cpexport.bat

Dieses Skript muss für jeden Callserver angepasst werden, damit Dateien nicht überschrieben werden:

  1. Pfad und Dateiname der Callserver-Protokolldatenbank (BOICPDB)
  2. Pfad und Dateiname der Ergebnis-CSV-Datei (CPEXPFILE)
  3. Pfad und Dateiname der Ergebnis-REO-Datei (CPREOFILE)

 

Nach Ausführung dieses Skripts existieren folgende Dateien:

  1. CSV-Datei mit exportierten Callserver-Protokolldaten
  2. REO-Datei der Callserver-Protokolldatenbank

Es wird im Gegensatz zu z/OS kein automatischer FTP gestartet, der die Dateien auf den lokalen Rechner transferiert.

Die CSV-Datei kann mit FTP im Textmodus auf den lokalen Rechner transferiert bzw. über ein Netzlaufwerk angesprochen werden.

Die REO-Datei muss im Binärmodus mit FTP auf den lokalen Rechner transferiert bzw.über ein Netzlaufwerk angesprochen werden.

Senden Sie nun die erzeugten REO-Dateien in gezippter Form an unseren Support.

Skript cpreorg.bat

Nachdem BOI die übermittelten Callserver-Protokolldaten geprüft und ausgewertet hat, muss CPREORG.BAT für jeden Callserver angepasst werden. Damit werden sämtliche Callserver-Protokolldateien bereinigt und reorganisiert.

 

In diesem Skriptmüssen angepasst werden:

  • Pfad und Dateiname der Callserver-Protokolldatenbank (BOICPDB)

 

Vor Ausführung dieses Skripts muss der Callserver beendet werden, im Anschluss an dieses Skript muss der Callserver erneut gestartet werden:

  1. Callserver vor Ausführung des Jobs beenden
  2. Skript cpreorg.bat ausführen
  3. Callserver erneut starten

Wie erstelle ich die Tabelle der Callserver-Protokolleinträge?

Funktionsbeschreibung

Das SSL-Modul $TABX4XCPR wird einerseits vom Callserver zum Schreiben der Protokolleinträge aufgerufen. Es kann aber auch zum Erstellen einer Tabelle der Protokolleinträge verwendet werden.

Dabei wird aus den Statuseinträgen in Datenbank TABCPR eine Speichertabelle erstellt. Diese wird unter dem Namen $_CSVPRT_$ in Datenbank TABTMP gespeichert.

Vorbereitungen und Programmaufruf

Das Erstellen der Tabelle aus den Callserver-Protokolleinträgen kann entweder im Batch oder Online (TSO bzw. Client/Server-Terminal) aufgerufen werden. Je nach Art des Aufrufs wird eine entsprechende JCL bzw. Aufrufprozedur benötigt.

Beschreibung der Aufrufumgebung

  • Eine JCL-Datei oder Aufruf-Prozedur ähnlich wie bei den TABEX-Utilities
  • Sysparm-Angabe für den Aufruf: M=$TABX4XCPR-CRTTAB
  • Erforderliche Datenbank-Allokationen

INTMOD-Verkettung

TABCTL-Verkettung

OPSMSG-Verkettung

TABCPR

TABTMP

Ergebnis nach der Programmdurchführung

Nach erfolgreicher Durchführung befindet sich eine Tabelle $_CSVPRT_$ in der Datenbank TABTMP.

Die möglichen Fälle bei Programmende sind:

FallExit-CodeErgebnistabelle in TABTMPAnmerkungen

Tabelle mit Zeilen erstellt

0ja

Hinweismeldung

Leertabelle erstellt

4ja

Hinweismeldung

Fehler

8nein

Fehlermeldung mit Returncode und Diagnose-Info (ev. BOI kontaktieren)

 

Struktur der erzeugten Tabelle

Auszug aus dem Entwicklungsstand von Handbuch BOIDOC_224:


Technische Status-Felder

FeldnameTypLängeInhalt

STA_TABLE

CH10

Statusname = Hostname des Callservers, die ersten 10 Character in Großbuchstaben

STA_VERSION

CH8

Statusversion = Portnummer (000nnnnn gespeichert im Format YYYYMMDD)

STA_LOAD_DB

CH8

Datenbankname ( = „TABCPR“)

STA_USER

CH8

User-ID des Status-Writers ( = „BOITPSV“)

STA_DATE

CH8

Datum des Statuseintrags (Format YYYYMMDD)

STA_TIME

CH8

Zeit des Statuseintrags (Format HH:MM.SS)

 

Callserver-Identifikationsfelder

FeldnameTypLängeInhalt

CPR_HNAME

CH36

Hostname des Callservers (max. 36 Characters), gemischte Schreibweise

CPR_PORT

BF2

Portnummer des Callservers

CPR_TSTMP

CH26

Timestamp der Status-Erzeugung (Format YYYY-MM-DD-HH.MM.SS.FFFFFF)

 

Usage-Counters

FeldnameTypLängeInhalt

CPR_NLNUMACC

BF8

Native/SSL/Andere: Anzahl der lokalen Calls

CPR_NLNUMBYT

BF8

Native/SSL/Andere: Anzahl der lokalen API-Parameterstruktur-Bytes

CPR_NLCONMAX

BF4

Native/SSL/Andere: Maximale Anzahl der lokalen Verbindungen

CPR_NLCONCUR

BF4

Native/SSL/Andere: Aktuelle Anzahl der lokalen Verbindungen

CPR_NRNUMACC

BF8

Native/SSL/Andere: Anzahl der Remote-Calls

CPR_NRNUMBYT

BF8

Native/SSL/Andere: Anzahl der Remote-API-Parameterstruktur-Bytes

CPR_NRCONMAX

BF4

Native/SSL/Andere: Maximale Anzahl der Remote-Verbindungen

CPR_NRCONCUR

BF4

Native/SSL/Andere: Aktuelle Anzahl der Remote-Verbindungen

CPR_JLNUMACC

BF8

Java: Anzahl der lokalen Calls

CPR_JLNUMBYT

BF8

Java: Anzahl der lokalen API-Parameterstruktur-Bytes

CPR_JLCONMAX

BF4

Java: Maximale Anzahl der lokalen Verbindungen

CPR_JLCONCUR

BF4

Java Local current number of connections

CPR_JRNUMACC

BF8

Java: Anzahl der Remote-Calls

CPR_JRNUMBYT

BF8

Java: Anzahl der Remote-API-Parameterstruktur-Bytes

CPR_JRCONMAX

BF4

Java: Maximale Anzahl der Remote-Verbindungen

CPR_JRCONCUR

BF4

Java: Aktuelle Anzahl der Remote-Verbindungen

 

Overlay-Felder für lange Counters

Zusätzliche Overlay-Felder werden in der Tabellenstruktur über die Felder ...NUMACC und ...NUMBYT definiert.

Die Overlay-Felder repräsentieren die hohen und niedrigen Anteile dieser Felder in jeweils 4 Byte Länge.

Die hohen und niedrigen Anteile von ...NUMACC werden über die Overlay-Felder ...NUMACCH und ...NUMACCL definiert.

Die hohen und niedrigen Anteile von ...NUMBYT werden über die Overlay-Felder ...NUMBYTH und ...NUMBYTL definiert.

Zusätzliche Felder

Feldname

Typ Länge

Inhalt

CPR_FREE

CH96

(frei, für zukünftige Verwendung)

 

Einschalten der Protokollierung

Die Protokollierung kann eingeschaltet werden - sie kann jedoch nicht ausgeschaltet werden, wenn sie in der Lizenzdatei eingeschaltet ist.

 

Die Schalter sind in BOIDOC_224 im Aufrufparameter des Callservers dokumentiert:

Die Flags "2C" im Aufrufparameter schalten Verbindungs-Log und Zugriffsprotokoll ein.

 

Beispiele:

Windows / Linux / Unix: in boiparam.txt

TPSVPARM <1998 - 2C>

z/OS: in der JCL

// PARM=('TRAP(ON),ENVAR("TZ=CET-1CEST") / 1998 - 2C')

 

Siehe auch:

BOIDOC-224_Cs_admin