... die Meldung „Lokale Datei inkonsistent“ ausgegeben wird.
Das kann bedeuten, dass
eine Binärdatei versehentlich als Textdatei übertragen wurde (Option -b verwenden!)
eine Textdatei zu lange Sätze enthält (Option -r verwenden!)
... die Meldung „Fernes System nicht verfügbar“ ausgegeben wird.
Das kann bedeuten, dass
die in der Partnerliste, dem TNS oder dem Hosts-Eintrag angegebene Partneradresse nicht stimmt. Bei BS2000-Kopplungen sollte überprüft werden, ob ein BCMAP-Eintrag für $FJAM mit der Portnummer 1100 im BS2000-Partner gemacht wurde (dieser wird ab openFT V9.0 für BS2000-Systeme automatisch erstellt).
im Partnersystem der asynchrone openFT-Server nicht gestartet ist.
eine Firewall im Partnersystem keine Verbindung zulässt.
Bitte beachten Sie, dass ftping nur für den internen Einsatz vorgesehen ist und keine garantierte Schnittstelle darstellt.
... das eigene System von Partnersystemen nicht erreichbar ist.
Es sollten folgende Fehlerquellen überprüft werden:
wurde der asynchrone openFT-Server gestartet?
entspricht die lokale Adresse den Standardeinstellungen
(ftmodo -openft=@s) oder wurde sie verändert?Wenn Sie an einem Windows-System den TNS verwenden:
wurde für die lokale Adresse ein RFC1006-Eintrag mit TSEL $FJAM gemacht?
wurde der lokalen Anwendung $FJAM die Portnummer 1100 zugeordnet? Die Portnummer 102 sollte grundsätzlich nicht verwendet werden, da es zu Kollisionen mit anderen Anwendungspaketen kommen kann.
wurde im Partnersystem die Portnummer 1100 adressiert ? Im BS2000 wird automatisch von openFT ein BCMAP erstellt. Damit dies erfolgreich ist, dürfen keine alten BCMAP-Einträge vorhanden sein.
ist die Firewall für die Anwendung openFT freigeschaltet?
... die Meldung „Lokales System im fernen System unbekannt“ ausgegeben wird.
Das bedeutet, dass Ihr Partnersystem Ihr lokales System nicht als Partner akzeptiert. Dazu sollten Sie auf dem Partnersystem prüfen:
Sind dynamische Partner ausgeschlossen und es existiert kein oder kein passender Eintrag in der Partnerliste für Ihr lokales System?
Lösungsmöglichkeiten:
Im Partnersystem Ihr lokales System in die Partnerliste eintragen oder
im fernen System den Partnerlisteneintrag überprüfen, z.B. ob die gesendete Instanzidentifikation mit der eingetragenen Instanzidentifikation übereinstimmt, oder
dynamische Partner zulassen
Schlägt die Partneradressüberprüfung für Ihr lokales System fehl?
Auf dem lokalen System sollten Sie die Einstellungen der Betriebsparameter Identifikation und Prozessorname überprüfen.
... die Meldung „Fernes System xy unbekannt“ ausgegeben wird.
Das kann bedeuten, dass
Sie für das Partnersystem den Eintrag in der Partnerliste, die TNS-Einträge oder die Einträge in der Hosts-Datei ändern müssen,
ein TNS-Eintrag verwendet wird, obwohl die TNS-Nutzung deaktiviert ist,
dynamische Partner deaktiviert sind und der Partner nicht in der Partnerliste eingetragen ist.
... das BS2000 nicht erreicht werden kann
Wenn Ihr lokales System im BS2000 unbekannt ist, geben Sie im BS2000 das Kommando ADD-FT-PARTNER ein.
Wenn Sie die Meldung "Fernes System nicht verfügbar" erhalten, prüfen Sie ob eine der folgenden Ursachen vorliegt:
Betriebsmittelengpass im fernen System
Fernes FT-System nicht gestartet
BCIN fehlt
Keine Netzverbindung (z.B. bei TCP/IP-Kopplung Überprüfung mit dem Kommando ping)
Nameserver-Eintrag fehlt oder ist fehlerhaft
... der Name des Partners in den Logging-Sätzen fehlt
Tragen Sie den Partner in die Partnerliste, in den DNS, in die hosts-Datei (an Unix-Systemen /etc/hosts) oder in den TNS ein.
... die Logging-Funktion sich nicht aufrufen lässt, also die Logging-Datei nicht mehr lesbar bzw. inkonsistent ist
Gründe hierfür können sein:
Systemabsturz während Logging-Sätze geschrieben werden.
Volles Dateisystem beim Schreiben auf die Logging-Datei.
An Unix-Systemen: kill auf den openFT-Prozess während Logging-Sätze geschrieben werden.
Die einzige Möglichkeit besteht darin, openFT zu beenden (ftstop) und die betroffene Logging-Datei zu löschen.
Sie können den vollen Pfadnamen der betroffenen Logging-Datei kann mit dem Kommando ftshwl -llf -plf=0 ermitteln, vorausgesetzt, die Logging-Datei wurde nach Auftreten des Problems noch nicht gewechselt.
An Windows-Systemen können Sie zum Löschen der Logging-Datei z.B. den Windows-Explorer verwenden.
Dabei gehen alle Logging-Sätze der betroffenen Datei verloren.
Das explizite Anlegen einer leeren Logging-Datei ist nicht sinnvoll, da diese wegen fehlender Headerinformationen ebenfalls inkonsistent ist.
Um Platzproblemen zuvor zu kommen, sollten Sie
regelmäßig die Logging-Datei wechseln (ftmodo -lf=c),
alte Offline-Logging-Dateien auf einem anderen Rechner/Speichermedium sichern
und anschließend die alten Offline-Logging-Dateien auf dem openFT-Rechner löschen.
Alternative: Aktivieren Sie das automatische Löschen von Logging-Sätzen (ftmodo, Optionen -ld, -lda, -ldd und -ldt).
... der Zugriff auf die Berechtigungssatz- und Berechtigungsprofildatei Fehler bringt oder wenn diese Datei defekt ist
Gründe hierfür können sein:
Manueller Zugriff auf die Dateien sysfsa.dat und sysfsa.idx. Diese Dateien befinden sich im Verzeichnis config der jeweiligen openFT-Instanz.
Unix-System:
Bei der Standardinstanz lautet der Pfadname dieser Dateien:
/var/openFT/std/config/sysfsa.dat
und
/var/openFT/std/config/sysfsa.idx
Systemabsturz bei geöffneten sysfsa.*
An Unix-Systemen: kill auf den openFT-Prozess bei geöffneten sysfsa.*
An Unix-Systemen: volles Dateisystem bei ISAM-Zugriff
An Unix-Systemen hinterlässt ISAM bei Fall 2, 3 und 4 i.d.R. eine unbrauchbare Indexdatei.
Lösungsmöglichkeiten:
Versuch mit Export/Import:
Exportieren Sie mit ftexpe die Daten in eine Sicherungsdatei.
Beenden Sie dann den openFT-Server mit ftstop, löschen Sie sysfsa.dat und sysfsa.idx und starten Sie openFT wieder mit ftstart. Importieren Sie die Daten mit ftimpe aus der Sicherungsdatei.Versuchen Sie, die ISAM-Indexdatei per dcheck wieder herzustellen.
Beispiel mit der Standardinstanz auf Unix-Systemen:
/opt/openFT/bin/ftbin/dcheck -b /var/openFT/std/config/sysfsaBeispiel mit der Standardinstanz auf Windows 10-Systemen):
dcheck -b "C:\ProgramData\Fujitsu TechnologySolutions\openFT\var\std\config\sysfsa"Eventuell muss die Indexdatei zuvor explizit gelöscht werden:
Bei leerer Datendatei sysfsa.dat gehen keine Daten verloren, somit können beide ISAM-Dateien bei gestopptem openFT gelöscht und vor ftstart per ftshwa initialisiert werden.
Enthält die Datendatei bereits Änderungen der Berechtigungssätze und/oder -profile, dann geben Sie folgende Kommandos ein:
Unix-System:
cd /var/openFT/std/config ftstop mv sysfsa.dat sav.sysfsa.dat && rm sysfsa.idx ftshwa >/dev/null rm sysfsa.dat && mv sav.sysfsa.dat sysfsa.dat /opt/openFT/bin/ftbin/dcheck -b sysfsa ftstart
Windows-System:
cd C:\ProgramData\Fujitsu Technology Solutions\var\std\config ftstop move sysfsa.dat sav.sysfsa.dat del sysfsa.idx ftshwa del sysfsa.dat move sav.sysfsa.dat sysfsa.dat dcheck -b sysfsa ftstart
Erläuterung:
Eine defekte sysfsa.idx muss neu erzeugt werden. Hierzu wird die zu erhaltende sysfsa.dat zuerst gesichert. Per ftshwa wird eine neue sysfsa.dat erzeugt, sofort wieder gelöscht und durch die gesicherte sysfsa.dat ersetzt, wodurch ein wieder verwendbares Paar von Dateien existiert.
Wenn auch dieser Versuch nicht zum Erfolg führt, müssen Sie die Berechtigungssatz- und Berechtigungsprofildatei löschen und mit neuen Einträgen einen konsistenten Stand erzeugen.
... ich bei einem ncopy-Auftrag keine freie Transportverbindung bekomme
An Windows-Systemen kann dies bei Kopplung zu Nicht-TCP/IP-Netzen vorkommen (z.B. X.25): Überprüfen Sie die Konfigurationseinstellungen für das jeweilige Transportsystem.
Prüfen Sie die Partneradresse im Partnereintrag oder in der Partnerliste.
Wenn Sie mit TNS arbeiten: prüfen Sie Ihre TNS-Einträge und prüfen Sie, ob die TNS-Nutzung und der Betrieb mit CMX aktiviert sind: Bei ftshwo muss bei USE TNS und USE CMX jeweils der Wert YES angezeigt werden. Andernfalls aktivieren Sie die TNS-Nutzung und den Betrieb mit CMX mit ftmodo -tns=y -cmx-y.
Prüfen Sie die Adresseinstellungen der Betriebsparameter.
... die openFT-Meldung „Ferne Zugangsberechtigung ungültig“ erscheint
Aus Datenschutzgründen unterscheidet diese Meldung auf der Initiatorseite nicht zwischen den verschiedenen möglichen Gründen für die Ablehnung. Diese Informationen sind nur über das openFT-Logging des Responder-Systems verfügbar.
... Aufträge im Zustand „WAIT“ stehen bleiben?
prüfen Sie, ob der asynchrone openFT-Server im lokalen System gestartet ist
prüfen Sie, ob der openFT bzw. der asynchrone openFT-Server im fernen System gestartet ist
Mit ftshwr -l können Sie weitere Ursachen ermitteln.
... in Unix-Systemen das Löschen eines Auftrages im openFT Explorer auffällig lange dauert (ca. 1 Minute)
Das kann bedeuten,
dass für den Auftrag, der gelöscht werden soll, eine Mail bei Beendigung des Auftrages angefordert wurde
und dass es wegen eines Konfigurationsproblems der Mailfunktion des Unix-Systems ca. 1 Minute dauert, um eine Mail abzusenden.
Lösung:
Auf eine Mail bei Beendigung des Auftrages verzichten, d.h. beim ft-Kommando die Option -m=n angeben (oder -m weglassen da Standardwert ab V10.0). Aufträge, die aus dem openFT Explorer gestartet werden, fordern nie eine Beendigungsmail an.
... in Linux-Systemen im openFT Explorer die linke Maustaste nicht wie gewünscht funktioniert
Dies kann daran liegen, dass die Funktion der NumLock-Taste mit Xfree und KDE (auf größeren SuSE-Linux-Systemen) per Generierung anders eingestellt wurde.
Dies führt zu Problemen, wenn die NumLock-Taste als Alt-Feststelltaste fungiert: aus Klick wird Alt-Klick, aus Doppelklick wird Alt-Doppelklick.
Das Problem kann der Systemverwalter durch Umschalten der NumLock-Taste beheben, ggf. ist im BIOS die NumLock-Funktionalität einstellbar. Mit dem Kommando xmodmap können die Tastenbelegungen überprüft und geändert werden.
... auf einem Windows-Terminalserver oder Windows-Server beim Start eines openFT Kommandos durch einen Benutzer die Meldung "Can't create termination event (error x). Command aborted." ausgegeben wird.
Das bedeutet, dass das entsprechende openFT Kommando wegen fehlender Rechte des Aufrufers bestimmte interne Objekte nicht einrichten kann und deshalb das Kommando nicht ausgeführt werden kann. Dieses Problem kann auf Windows-Terminalservern oder Windows-Servern auftreten, wenn der Gruppe der Benutzer das Recht zum Erstellen globaler Objekte fehlt. Um das Problem zu beheben, muss der Systemverwalter in der Rechteverwaltung des Betriebssystems der Gruppe Benutzer das Recht zum Erstellen globaler Objekte gewähren.
... sich in Windows-Systemen der openFT-Dienst nur beim Reboot des Systems starten lässt, nicht aber manuell, und der Benutzer die benötigten Verwalter-Rechte hat?
Im vorliegenden Fall erhalten Sie von Windows eine Fehlermeldung über eine fehlgeschlagene Initialisierung mit der Nummer 0xC0000022. Dies wird dadurch ausgelöst, dass in der Systemumgebungsvariablen PATH vor dem openFT-Installationspfad ein Pfad mit einem Netzlaufwerk bzw. ein UNC-Name oder ein Pfad mit Leerzeichen eingetragen ist. Falls der Dienst automatisch beim Booten des Systems gestartet wird, dann sind diese Einträge noch nicht aktiv und der Dienst startet normal. Später sind sie dann aktiviert und für SYSTEM mangels fehlender Rechte nicht zugreifbar.
Lösung:
Pfad bereinigen.
... es unter Windows zu Initialisierungsfehlern in user32.dll oder kernel32.dll kommt, wenn eine Folgeverarbeitung gestartet wird?
Ursache:
Die System-Umgebungsvariable PATH enthält nicht zugreifbare UNC-
Pfade/Netzlaufwerke.
Lösung:
Pfad bereinigen und nur lokale zugreifbare Pfade verwenden.
Performance-Hinweis
Wenn Sie im Betrieb mit CMX den TNS verwenden (ftmodo -tns=y), dann sollten Sie bei den TNS-Einträgen das Protokoll RFC1006 einstellen, da das RFC1006-Protokoll deutlich performanter ist als die Kommunikation über LANINET. Im BS2000 sollte ohne BCMAP Einträge gearbeitet werden. Werden trotzdem BCMAP Einträge benötigt, so gilt: Ist der PTSEL-I-Eintrag vorhanden, so wird RFC1006 verwendet.
Beim Betrieb ohne CMX wird immer das RFC1006-Protokoll verwendet.