Inhaltsübersicht

Lizenz prüfen

directsync4i wird mit sen Standard-Lizenzdateien von Toolmaker lizenziert. Zur Prüfung verwenden Sie die Befehle:

1. ADDLIBLE DIRSYNC
2. DSPLICINFO *FULL

Weitere Informationen dazu - und wie man die Anzeige interpretiert finden Sie auf der Seite zur Lizenzprüfung für Toolmaker-Produkte

Bibliotheken und Verzeichnisse für directsync4i

Fehlersuche und -behebung auf IBM i

Version feststellen

IBM i-Version

GO LICPGM, Auswahl 10, Taste F11

directsync4i Version

DSPDTAARA DIRSYNC/prdrel

WOPiXX

Befehle zur Konfiguration

Start/Stop -Befehle

Subsystem und Jobs

Logs/Protokolle/Dumps

Protokollierung ein und ausschalten

Protokoll-Dateien

Auf dem Gateway-PC endet der Job "directsync4i Gateway Service" immer kurz nach dem Start

1. Bitte prüfen Sie, ob eine gültige Lizenz vorliegt: Lizenz prüfen
   1. ist dies nicht der Fall, dann prüfen Sie, ob Ihnen bereits per E-Mail eine Lizenzdatei geschickt wurde. Lizenzdateien sind einfache .txt-Dateien, ihr Name beginnt mit "License_DIRSYNC_", gefolgt von weiteren Angaben zu Ihrem System. Wenn Sie eine solche Datei in Ihrer Mailbox finden, dann speichern Sie diese bitte im IFS der IBM im Verzeichnis /Toolmaker. Überschreiben Sie eine ggf. schon vorhandene Datei gleichen Namens
      
   2. Wenn Sie keine Lizenzdatei haben, dann fordern Sie sie bitte an bei: licenses@toolmaker.de.

Der Fehlerjob DS4IERROR

Treten in directsync bei laufender Triggerung Fehler auf, so erscheint in der web-Anwendung directsync4i bzw. im Subsystem DIRSYNC ein Fehlerjob DS4IERROR. Dieser Job gibt detaillierte Information über das vorliegende Problem, das bearbeitet werden muß.

0277 – directsync web-Fehlerjob bei laufender Triggerung

0276 – directsync Fehlerjob bei laufender Triggerung

Zuordnung der DTAQ's

Eine der häufigsten Fehlerursachen ist, dass die Zuordnung der DTAQ's anhand der auftretenden Dateiveränderungen nicht optimal konfiguriert ist. Dies lässt sich aber durch entsprechende Konfigurationsänderungen bzw. Hinzunehmen weiterer DTAQ's durch entsprechende Lizenzerweiterung beheben. Siehe hierzu separates Kapitel Lizenzierung. $QSTSRC - Kapitel umbauen

Speichergrenze für Datenwarteschlange CI2IDQxx erreicht

Diese Fehlermeldung besagt, daß die Speichergrenze für eine Datenwarteschlange erreicht ist. Dies ist der Fall, wenn zu viele Dateien mit viel Dateibewegungen einer einzigen DataQ zugewiesen sind. Hier kann Abhilfe geschaffen werden, indem weitere DataQ's hinzukonfiguriert werden und Dateien mit vielen Dateioperationen eine eigene DataQ zugewiesen werden.

Hinweis: Eine neu ausgewählte DataQ muß vorher im directsync Administrator aktiviert werden. Evtl. muß auch eine Lizenzerweiterung erfolgen. Siehe hierzu separates Kapitel Lizenzierung.$QSTSRC - Kapitel umbauen

REORG DB2

Mit folgenden SQL-Statements kann die DB2 bzw. der CI2ITRGBUFFER reorganisiert werden.

IBM DB2

Be

0292 – IBM DB2 Befehlsfenster

C:\Program Files\IBM\SQLLIB\BINDB2
CONNECT TO DIRSYNC USER "db2admin"
Eingabe Kennwort
REORG TABLE DIRSYNC.CI2ITRGBUFFER ALLOW NO ACCESS LONGLOBDATA
CONNECT RESET
QUIT
C:\Program Files\IBM\SQLLIB\BIN\EXIT

DSY9020/DSY9010 Empfangsprogramm antwortet nicht

Diese Fehlermeldung kommt, wenn länger als 40 Sekunden keine Nachricht für das SEND Programm auf dem Gateway-PC kommt. Die Kommunikation vom directsync4i Gateway PC zur IBM i ist nicht möglich bzw. wurde länger als 40 Sekunden unterbrochen.

Wird das directsync4i Subsystem über dirweb – directsync4i – System – Subsystem beenden – Subsystem starten neu gestartet, ist die Kommunikation vom Gateway PC und IBM i wieder hergestellt und das Problem behoben.

0291 – Fehler Empfangsprogramm antwortet nicht

Sollte dies nicht der Fall sein, so ist zu prüfen, ob am Gateway-PC der SEND Dienst läuft. Falls nicht, sind die Logfiles über directsync4i Administrator – Reiter Dienste – Logdatei anzeigen zu prüfen.

0290 – Prüfen Logdatei

DSY9999 DTAQ ist überfüllt

Ist eine DTAQ überfüllt, so muß eine Konfigurationsänderung vorgenommen und u.U. weitere DTAQ's lizenziert werden. Siehe hierzu separates Kapitel Lizenzierung.$QSTSRC

0275 – Fehler DTAQ ist überfüllt

CLRPFM

Problem:

Sollten Sie Dateien in directsync4i registrieren wollen, auf welche ein clear physical file member (CLRPFM) Befehl ausgeführt werden muss, werden Sie einen Fehler erhalten, denn directsync4i registriert mehrere Triggerprogramme an einer Datei und Dateien mit Triggerprogrammen können nicht mit CLRPFM bearbeitet werden.
Grundsätzlich sollte geprüft werden, ob Dateien, auf die regelmäßig ein CLRPFM ausgeführt wird, überhaupt via directsync4i gesichert werden müssen, da es sich bei solchen Dateien i.d.R. um temporäre Arbeitsdateien handelt, deren Inhalt durch bestimmte Programmabläufe jederzeit wiederhergestellt werden können.

Lösung:

Für dieses Problem stehen mehrere Lösungsansätze bereit:

1. Sie ersetzen den Befehl durch unsere Alternative CLRPFREC.

Dieser Befehl nimmt die gleichen Parameter entgegen, wie der original CLRPFM löscht jedoch alle Sätze in einer Datei via SQL Delete Anweisung.

ACHTUNG:

Enthält eine Datei sehr viele Sätze, wird für jeden gelöschten Satz ein Triggerbuffer in die angehängte DTAQ/PWRQ geschrieben und auf den Gateway PC gespeichert. Dies kann u.U. zu erhöhter Belastung führen!

1. Sie hängen die Trigger ab, bevor Sie das Programm aufrufen, welches einen CLRPFM ausführt. Damit kann der CLRPFM ausgeführt werden und der Gateway PC wird nicht unnötig belastet.

Nach erfolgtem CLRPFM können die Trigger wieder angehängt werden. Dies geschieht über unsere Befehle:

QSYSOPR Meldungen DSY9010 und DSY9020

Problem:

Auf der IBM i läuft im Subsystem „DIRSNYC" ein Job mit dem Namen „MONITOR". Dieser Job überwacht die korrekte Funktion von directsync4i. U.a. überwacht er die Verbindung zum Gateway PC. D.h. er schickt regelmäßig einen Ping an den Gateway PC und wartet auf die entsprechende Antwort. Laufen auf dem PC alle Dienste ordnungsgemäß, ist auch der Monitor Job zufrieden. Sollte jedoch ein oder mehrere Dienste nicht laufen bzw. der ganze PC nicht antworten, gibt der Monitor Job Fehlermel dungen in die Nachrichtenwarteschlange QSYSOPR aus.
Die Meldungen werden als CPF9898 gesendet.Enthält die Nachricht den Code DSY9010 bedeutet dies, dass der Gateway zwar erreicht werden kann und einige Dienste laufen, jedoch nicht alle, die laufen müssen.Hierzu wird ein Code angegeben. Im o.g. Beispiel sehen Sie:„Auf dem Gateway PC laufen bestimmte Dienste nicht: XSEP"
XSEP ist der Code, wobei dieser sich wie folgt zusammen setzt:

1. Stelle = Receive SV Dienst
2. Stelle = Send SV Dienst
3. Stelle = Externer Dienst
4. Stelle = Receive PowerQ

Sofern ein Dienst läuft bzw. nicht gebraucht wird, steht sein Buchstabe im Code.

Läuft er nicht, steht ein X an der Stelle.

Im o.g. Beispiel hat der Gateway PC gemeldet, dass der Receive SV Dienst nicht läuft.

Da dieser die DTAQ's auf der IBM i ausliest, ist es der wichtigste Dienst und es muss in dem Fall umgehend geprüft werden, warum der Dienst nicht läuft und ggf. der Dienst neu gestartet werden.

Erscheint die Meldung DSY9020 bedeutet dies, dass der Gateway PC gar nicht reagiert. Dann muss ebenfalls sofort geprüft werden warum und der PC schnellstens wieder mit der IBM i verbunden werden!

ACHTUNG:

Ohne einen einwandfrei funktionierenden Gateway PC, der kontinuierlich die Daten aus den DTAQ's und PWRQ's der IBM i liest und in der PostgreSQL Datenbank auf dem PC speichert, haben Sie nicht nur keinen erhöhten Datenschutz, sondern laufen auch Gefahr, dass die DTAQ's und/oder ggf. die PWRQ's und damit Ihre IBM i Platten überlaufen, was zur Beeinträchtigung Ihres Systembetriebs führt!

QSYSOPR Meldungen CPF950A – DTAQ voll

Problem:

Wenn diese Meldung in der Nachrichtenwarteschlange QSYSOPR erscheint, bedeutet das, das zu viele Daten zu schnell in die betroffene DTAQ geschrieben wurden und zu langsam oder gar nicht vom Gateway PC ausgelesen werden – in dem Fall tritt die Meldung mit einer der Meldungen DSY9010 oder DSY9020 auf (s.o.). Eine DTAQ kann max. 2GB an Daten aufnehmen, was ungefähr 60.000 Triggerbuffersätzen entspricht.Wenn dieses Problem auftaucht, kann es passieren, dass einige Anwender bzw. Batchjobs nicht weiterarbeiten können, da die Anwendungsprogramme versuchen Datenänderungen an einer Tabelle auszuführen, das angehängte Triggerprogramm jedoch nicht in seine zugeordnete DTAQ schreiben kann und deshalb in einer Schleife hängt.

Lösung:

Wenn es sich bei dem Problem um eines der DSY9010 oder DSY9020 handelt, schauen Sie bitte unter diesen Problemen nach der Lösung.Wenn der Gateway PC jedoch normal läuft und dennoch eine DTAQ überläuft, dann muss analysiert werden warum dies geschehen ist.
Es dies kann mehrere Ursachen haben:

1. Wenn es zu einem akuten Problem kommt und Ihre Anwender nicht arbeiten können, führen einen Clear DTAQ Befehl auf die entsprechende DTAQ aus. Dies erfolgt über den Befehl:

CLRDTAQ
der sich in der Bibliothek DIRSYNC befindet. Dort geben Sie bitte den Namen der betroffenen DTAQ's an und die Bibliothek DIRSYNCTRG. Sollte das Problem mehrere DTAQ's betreffen, gehen Sie bitte, wie unter „Not Stop" beschrieben vor!

1. Zu viele Tabellen an einer DTAQ

Wenn Sie zu viele Tabellen an eine einzige DTAQ hängen, läuft diese logischerweise schneller voll, als wenn es nicht so viele sind. Prüfen Sie in der directsync4i Weboberfläche bitte, wie viele Tabellen Sie an die DTAQ gehängt haben, die übergelaufen ist. Sie können durch einen Klick auf die Spalte DataQ die Anzeige entsprechend sortieren.

1. Eine oder mehrere Tabellen haben zu viele Bewegungen in zu kurzer Zeit

Die Anzahl der Datenbewegungen einer Tabelle können Sie in der o.g. Ansicht ebenfalls erkennen. Hierbei handelt es sich jedoch um die absolute Anzahl seit dem letzten IPL.

D.h. diese Zahl sagt überhaupt nicht aus, in welchem Zeitraum, wie viele Datensätze der Tabelle verändert wurden.

Steht hier z.B. 100.000 und das letzte IPL war vor 6 Monaten, dann könnten es einige wenige Sätze pro Tag gewesen sein oder 99.000 innerhalb weniger Sekunden.

Derzeit müssen Sie diese Zahl bei kritischen Tabellen noch selbst überwachen oder Sie verwenden eine unserer Test DTAQ's (T1 oder T2). Diese haben den Vorteil, dass man sie direkt im laufenden Betrieb deaktivieren kann. Allerdings sind diese Trigger langsamer, da sie den entsprechenden Schalter überwachen müssen.

Wir arbeiten derzeit an einem Analysetool, welches die Tabellen über einen längeren Zeitraum überwacht und so die tatsächliche Zeit ermitteln kann, in welcher wie viele Bewegungen stattgefunden haben.

Die Lösung für diesen Fall ist, die betroffene Tabelle an eine PowerQ zu hängen. Dabei handelt es sich um physische Dateien, die wesentlich mehr Triggerbuffer zwischenspeichern können, als eine DTAQ.

Welche Data- oder Power Queue soll ich verwenden

Problem:

Bei der Registrierung Ihrer Datentabellen in directsync4i müssen Sie eine Datenwarteschlange (DTAQ) oder eine Datenbanktabelle (PWRQ) auswählen, in welche directsync4i die Datenbewegungen Ihrer Tabelle zwischenspeichert. Aus dieser DTAQ oder PWRQ holt der Gateway PC dann die Datenbewegungen und speichert sie in seiner lokalen Datenbank als Sicherung ab bzw. schreibt Sie im Falle einer Backup IBM i Maschine dorthin.

Die Frage, die immer wieder als erstes gestellt wird ist: Welche DTAQ bzw. PWRQ soll ich für welche Tabelle verwenden und kann ich nicht einfach alle Tabellen einer DTAQ zuordnen?

Lösung:

Das Problem ist, dass eine DTAQ max. 2 GB an Daten aufnehmen kann. Das entspricht ca. 60.000 Datenbewegungen aus Ihren Tabellen.

Um festzustellen welche Tabelle Sie welcher DTAQ zuordnen können bzw. wie viele Tabellen Sie einer DTAQ zuordnen können und wann es sinnvoller ist eine andere zu verwenden oder gar auf eine PWRQ zu wechseln, sind folgende Punkte entscheidend:

• Wie viele Bewegungen hat die Tabelle in welcher Zeit?
• Wie schnell kann der Gateway PC die Daten aus der DTAQ bzw. PWRQ abholen und in seiner PostgreSQL Datenbank zwischenspeichern?

Diese beiden Punkte sind entscheidend und können derzeit nur durch Erfahrungswerte ermittelt werden. Die Anzahl der Bewegungen können Sie der directsync4i Weboberfläche entnehmen.

Bei „Dateien verwalten" finden Sie die Spalte „Anzahl Bewegungen Insert/Update".

Die Zahl die dort steht, ist die Anzahl der Bewegungen seit dem letzten IPL. D.h. diese Zahl sagt leider noch nichts darüber aus, in welchem Zeitraum diese Bewegungen stattgefunden haben.

Siehe hierzu auch den Punkt „QSYSOPR Meldungen CPF950A – DTAQ voll".

Tabelle hat mehr als 500 Spalten

Problem:

Aus Geschwindigkeitsgründen haben wir die Standardprogramme in directsync4i auf max. 500 Spalten pro Tabelle begrenzt. Jede weitere Spalte, kostet bei der internen Verarbeitung (vor allem bei der Rückspeicherung oder bei lokalen- und externen Datenbankspiegelungen) wertvolle Rechenzeit, die sich bei der Masse der Datensatzbewegungen schnell bemerkbar machen können.

Lösung:

Sollten Sie Tabellen haben, die mehr als 500 Spalten beinhalten, verwenden Sie für diese Tabellen bitte die DTAQ's 01 oder 02.

Die Programme, die diese DTAQ's verarbeiten, können bis zu 1.000 Spalten pro Tabelle verarbeiten. Sollten Sie Tabellen mit mehr als 1.000 Spalten mit directsync4i sichern wollen, wenden Sie sich bitte an unsere Mitarbeiter.

Not Stop - Anwendung funktioniert nicht mehr

Problem:

Das schlimmste was beim Einsatz von directsync4i passieren kann ist, dass das Problem „DTAQ voll" bei mehreren DTAQ's gleichzeitig auftritt und dadurch viele Ihrer Anwender und Batch Jobs nicht weiterarbeiten können. Dies sollte definitiv nicht passieren, kann aber im Falle einer falsch konfigurierten directsync4i Tabellenzuordnung bzw. Probleme mit dem Gateway PC, die nicht gesehen werden (weil z.B. niemand die Nachrichtenwarteschlange QSYSOPR überwacht und kein Tool vorhanden ist, welches diese Aufgabe ausführt) passieren.

Lösung:

Beachten Sie bitte, dass es bei solch einem Problem nichts bringt, wenn Sie das directsync4i Subsystem oder die darin befindlichen Batchjobs beenden. Da die DTAQ's und PWRQ's von den directsync4i Triggerprogrammen befüllt werden, bringt es nur etwas, wenn Sie die Trigger über die Weboberfläche von directsync4i deaktivieren.Da dies im laufenden Betrieb nicht möglich ist, weil die Tabellen keine Sperren enthalten dürfen, um Trigger ab- oder anzuhängen, haben wir für diesen Fall haben wir ein Notfall Programm erstellt, welches Sie mit dem Befehl:

DSCLRALL aus der Bibliothek DIRSYNC aufrufen können.

Der Befehl zeigt zunächst den folgenden Bildschirm an:

Bestätigen Sie mit Auswahl „J" und Datenfreigabe, wird ein Batchjob gestartet, der in einer Endlosschleife alle directsync4i DTAQ's und PWRQ's leert.

Durch diese Maßnahme können Ihre Anwender und Programme normal weiterarbeiten; es geht jedoch die directsync4i Datensicherung verloren.

Sobald Ihr Tagesgeschäft beendet ist, deaktivieren Sie bitte alle Trigger über die Weboberfläche von directsync4i bzw. zumindest die Trigger von den Tabellen, die sehr große Datenbewegungen aufzeigen. Erst danach können Sie den Batch Job CLEARALL aus dem Subsystem DIRSYNC beenden.

Sollte so etwas bei Ihnen passieren, wenden Sie sich bitte umgehend an uns, damit wir gemeinsam mit Ihnen analysieren können, warum es zu diesem Problem gekommen ist.

Tabelle hat Satzlänge von mehr als 16.000 Stellen

Problem:

Sie möchten Tabellen mit directsync4i sichern, die eine Satzlänge von mehr als 16.200 Stellen haben.

Da directsync4i die Sicherungen der Datenbewegungen mit Hilfe von IBM Triggern ausführt und diese Trigger auf max. 32K Satzlänge begrenzt sind und darin 2 Abbilder eines Satzes (vorher / nachher) speichern müssen, können wir auch nur max. 16.200 Stellen in der Satzlänge unterstützen.

Lösung:

Sprechen Sie uns bitte an, damit wir gemeinsam mit Ihnen eine Lösung für dieses Problem besprechen können.

Tabelle enthält einen nicht unterstützten Datentyp

Problem:

Sie möchten eine Tabelle mit directsync4i sichern, die eine Spalte mit einem nicht unterstützten Datentyp enthält.

Hier sind die Datentypen, die directsync4i nicht unterstützt:

• Binary / Varbinary
• Graphic / Vargraphic / Long Vargraphic
• CLOB
• BLOB
• DBCLOB
• Distinct
• Datalink
• XML

Lösung:

Sprechen Sie uns bitte an, damit wir gemeinsam mit Ihnen eine Lösung für dieses Problem besprechen können.

PostgreSQL Datenbank auf Gateway PC voll

Problem:

Alle Datenbewegungen der Tabellen, die Sie in directsync4i registrieren, werden auf den Gateway PC in die PostgreSQL Datenbank geschrieben. Irgendwann ist jedoch auch einmal der Plattenplatz auf dem Gateway PC ausgeschöpft, so dass Sie dafür sorgen müssen, dass die directsync4i Tabellen innerhalb der PostgreSQL Datenbank regelmäßig bereinigt werden.

Lösung:

Hierfür gibt es 2 Möglichkeiten:

1. Auf der IBM i gibt es den Befehl CLRDSYDB in der Bibliothek DIRSYNC:

Mit diesem Befehl können Sie direkt alle Datensätze in der PostgreSQL Datenbank bis zum angegebenen Datum/Uhrzeit entfernen.

Die Angabe, ob Sie nur verarbeitete Sätze löschen möchten, betrifft primär Installationen mit Dual System Betrieb. D.h. Sie haben eine Backup IBM i Maschine, auf die Ihre Datenbewegungen übertragen werden.

Bei Single System Betrieb, sollten Sie hier ein N eintragen, da ansonsten keine Sätze gelöscht werden.

2. Im directsync4i Administrator auf dem Gateway PC

Hier finden Sie unter dem Tab „Caching Server" die Einstellung 

„Löschung soll erfolgen um"

Wenn Sie hier eine Uhrzeit einstellen, wie z.B. 23 bei Stunde und 55 bei Minute, sowie eine Anzahl Tage, die Sie erhalten möchten bei „Anzahl Tage für Benutzung der Anzeige", wird der Gateway PC um diese Uhrzeit alle Datensätze, die älter sind als das aktuelle Datum minus der Anzahl Tage löschen.Diese Aufgabe übernimmt der Windows Dienst „Restart SV"

Tabelle hat keinen eindeutigen Schlüssel

Problem:
Sie möchten Tabellen mit directsync4i sichern, die über keinen eindeutigen Schlüssel verfügen.

Lösung:

Eine Tabelle, die keinen eindeutigen Schlüssel hat, kann lediglich mit einem INSERT Trigger versehen werden, da ein UPDATE oder DELETE nur mit eindeutigem Schlüssel möglich ist.

DSYENDTRG – Trigger abhängen

Problem:

Sie möchten die directsync4i Triggerprogramme per Befehl bzw. Programm abhängen, weil Sie z.B. einen Nachtjob oder Monatsabschlussprogramm laufen lassen, welches temporär viele Dateiveränderungen durchführt, die nicht gespiegelt werden brauchen. Oder Sie wollen z.B. einen CLRPFM Befehl auf die Tabelle ausführen.

Lösung:

Verwenden Sie hierfür den speziellen Befehl DSYENDTRG. Mit diesem können Sie die directsync4i Trigger per Befehl bzw. Programm abhängen.

ACHTUNG:

Damit werden nur die Triggerprogramme von directsync4i abgehängt. Wenn Sie ggf. noch weitere Triggerprogramme angehängt haben, müssen Sie diese anderweitig (z.B. RMVPFTRG) abhängen.

Geben Sie die Bibliothek, sowie die Datei an, deren Trigger Sie anhängen möchten.

Trigger sofort abhängen, dürfte selbst erklärend sein, wenngleich sofort nicht wirklich sofort bedeutet. Sofort bedeutet in diesem Fall, dass der Batch Job DSYAUTOAD versucht, die Trigger direkt abzuhängen. Sollte die Datei gesperrt sein, können die Trigger nicht abgehängt werden und der DSYAUTOAD Job versucht es in einer Minute wieder. Da dieser Job immer eine Minute pausiert, kann es also auch im Falle, dass die Datei nicht gesperrt ist, bis zu einer Minute dauern, bis die Trigger abgehängt werden.

Wenn Sie „End-Datum/Zeit überschreiben" auf 1 setzen, können Sie im Feld darunter ein Ende-Datum und eine Ende Zeit eingeben, zu welcher die Trigger geplant abgehängt werden.

Das Format für das Enddatum und –Zeit Feld lautet:

2018-12-01 23.30.00.000000

Für den 01. Dezember 2018 um 23:30 Uhr

DSYACTTRG – Trigger hinzufügen

Problem:

Sie möchten die directsync4i Triggerprogramme per Befehl oder Programm zur Sicherung mit directsync4i anhängen.Dies macht u.U. dann Sinn, wenn Sie bei besonderen Aktionen, wie z.B. Nachtverarbeitung oder Monatsabschluss die directsync4i Trigger mit dem Befehl DSYENDTRG entfernt haben.

Lösung:

Mit dem Sonderbefehl DSYACTTRG können Sie die directsync4i Trigger zur Sicherung hinzufügen.

ACHTUNG:

Die angegebene Datei muss bereits via directsync4i Weboberfläche registriert worden sein. Dieser Befehl hängt lediglich die directsync4i Trigger an!

Geben Sie die Bibliothek, sowie die Datei an, deren Trigger Sie anhängen möchten.

Im Feld „DataQueue" tragen Sie bitte den Namen der Datenwarteschlange ein, über die die Dateibewegungen gesichert werden sollen.

Das Format lautet:

ANN, wobei A für einen Buchstaben steht.

Folgende stehen zur Auswahl:

• T für die Test DTAQ
• B für Basis DTAQ
• Q für Queue
• P für PowerQ.

NN steht für eine Nummer. Bei B und T stehen nur 01 und 02 zur Verfügung.Bei P steht 01-09 zur Verfügung und bei Q steht 01-20 zur Verfügung. Welche Data- oder Power Queue Sie verwenden sollten, lesen Sie bitte unter „Welche Data oder Power Queue soll ich verwenden" nach.

Trigger sofort anhängen, dürfte selbst erklärend sein, wenngleich sofort nicht wirklich sofort bedeutet. Sofort bedeutet in diesem Fall, dass der Batch Job DSYAUTOAD versucht, die Trigger direkt anzuhängen. Sollte die Datei gesperrt sein, können die Trigger nicht angehängt werden und der DSYAUTOAD Job versucht es in einer Minute wieder. Da dieser Job immer eine Minute pausiert, kann es also auch im Falle, dass die Datei nicht gesperrt ist, bis zu einer Minute dauern, bis die Trigger angehängt werden.

Wenn Sie „Start-Datum/Zeit überschreiben" auf 1 setzen, können Sie im Feld darunter ein Start-Datum und eine Start Zeit eingeben, zu welcher die Trigger geplant angehängt werden.

Das Format für das Startdatum und –Zeit Feld lautet:

2018-12-01 23.30.00.000000

Für den 01. Dezember 2018 um 23:30 Uhr

Wofür sind die DTAQ's T1 und T2

Problem:

In der Auswahl zur Dateiregistrierung, können auch die DTAQ's T1 und T2 ausgewählt werden. Was hat es mit diesen auf sich?

Lösung:

Die DTAQ's T1 und T2 sind Sonderfälle. Bei diesen DTAQ's handelt es sich um sog. Test DTAQ's.D.h. wenn Sie bei bestimmten Tabellen nicht sicher sind, ob diese viele oder nicht so viele Datensatzbewegungen ausführen, hängen Sie diese Tabelle/n zunächst an eine der T-DTAQ's.

Diese haben den Vorteil, dass man das Triggern der Daten während des Betriebs ein- und ausschalten kann. Dazu gehen Sie in die directsync4i Weboberfläche und klicken im Menü „System" auf den Button „Test-DATAQ aus".Damit wird das Triggern in die DTAQ's ausgeschaltet!

ACHTUNG:

Die Triggerprogramme für die Test DTAQ's T1 und T2 sind durch diese Funktion um einiges langsamer, als die „normalen" Triggerprogramme, die diese Funktion nicht haben, weil sie bei jedem Trigger nach dem Schalter schauen müssen.

Fehlersuche und -behebung auf dem Gateway-PC

Version feststellen

Windows

Microsoft Office

directsync4i-Version

Start → Programme → directsync4i→ directsync4i Administrator, Registerkarte "Info"

IBM i ClientAccess bzw. Access Manager

Befehle zur Konfiguration

Start/Stop -Befehle

Logs/Protokolle/Dumps

Protokollierung ein und ausschalten

Protokoll-Dateien

Hotline-Fälle