Hallo!

Ich habe das Problem, dass ab und zu eine (von 10) FTAM-DFUe-Übertragungen mit einem Fehler endet; meist "Keine Netzwerkverbindung zum Partner".
Leider wird dann kein neuer Versuch vom Automaten unternommen. Wie kann man dort eine Abhilfe schaffen?

Gruss, Holger Petersen

Hallo Holger,

leider nicht, da Sfirm32 bis jetzt zumindest keine selbständige Wiederholung der gescheiterten Aufträge anstösst, wie z. B. aus Multicash bekannt ist. Dies muss bisher manuell über Standardaufträge / Fremddateien rechts auf die Zahlung gehen / rechte Maustaste / sofort ausführen. Es wird der gescheiterte Auftrag erneut übertragen.

Hallo,

man muß das problem an der Wurzel bekämpfen!

Welches BS hast Du?
Netzwerkinstallation??
Geht die Verbindung über einen DFÜ-Server????



Cu

Michael

Tja; den 'Trick' mit der rechten Maustaste kenne ich. Nur: Die Abrufe erfolgen gegen 5 Uhr morgens, und wenn ich (etwas :-) später zum Dienst komme, sollte ich eigentlich nicht mit sowas belästigt werden...
Schlimm genug, dass SFirm eventuell vorhandene DTI-Dateien gnadenlos überschreibt. Ein "Retry" wäre doch eigentlich 'normal'...

"Das Übel an der Wurzel packen" würde ich gerne; aber es scheint keine LINUX-Version von FTAM zu geben?

Ich nutze von SFIRM _nur_ den Datei-Abruf; die Daten selbst werden mit einem Perl-Script per FTP zu einem IBM-Host übertragen. Auch das lässt sich ja mit dem AT-Befehl von Windows automatisieren.
Leider läuft Multicasch nicht mehr unter XP.

Hallo Holger,

wenn es nur ums Abholen geht, warum stellst Du dann nicht einen 2ten Abholauftrag in die DFÜ-Aufträge der 5 oder 10 Min. später die DFÜ macht?
Wenn der erste Versuch klappt läuft der 2te ins leere, aber wenn der erste nicht klappt, dann ist der zweite ggf. erfolgreich.

Gruß
Karsten

"Warum keinen zweiten Auftrag"

a) Kann ich 101% sicher sein, dass die Bank keine zweite Datei bereitstellt, die die erste wie bekannt gnadenlos überschreibt?

b) Ich habe es manchmal, dass -obwohl der erste von 10 Anrufen um 5:20 laufen soll- die Abholungen noch um 8:10 aktiv sind. 'Irgendeine' Verzögerung hat dafür gesorgt.

Im Normalfall wird bei FTAM nur einmal am Tag eine Datei bereitgestellt. Muß mit den einzelnen Instituten geklärt werden. Anders sieht es aus wenn historisch abgeholt wird. Aber wie ich es sehe wird nur die Bereitstellung der Institute abgeholt.
Aber nun nochmal die Frage nach der Systemumgebung: Welches BS und wie wird die DFÜ gemacht? Zentral? oder lokal?
Wenn eine von 10 DFÜ nicht geht sieht es mir nach einem Treiberproblem oder Netzproblem aus, dass bei dieser negativen DFÜ der Treiber aus irgenteinem Grund nicht (rechtzeitig) reagiert.
Oder die (eventuell vorhandene) TK-Anlage gibt die Leitung nicht rechtzeitig frei.

Gruß
Karsten

Kann es vielleicht mit der Abrufuhrzeit um 5 Uhr zusammenhängen, das dort das RZ noch nicht erreichbar ist?

Ich kenne kein RZ was nicht um 5 Uhr die Daten schon bereitgestellt hat. Ausnahmen bestätigen natürlich die Regel, aber im Prinzip werden die Daten in der Nacht bereitgestellt und sind lange vor 5 Uhr bereit.

Gruß
Karsten

Das kannst du so pasuchal nicht sagen.
Es kommt schon drauf an wie der Kunde die Daten bereitsgestellt haben möchte und ob die Art der Bereitstellung nicht auf ein Vorereignis (Auszugsschnitt z.B. bei Auzugsorientierter Bereitstellung) warten muss.

Bei uns ist der Auzugsschnitt mal auf 14:00 geändert worden, dann stehen die auzugsorientierten ELKO-Auszüge auch eben erst kurz danach bereit.

Grundsätzlich nimmt der Host aber zu jeder Tages- und Nachzeit Aufträge entgegen und gibt sie auch sofort ins Backend zur Verarbeitung weiter.

Hallo!

a) Betriebssystem Windows-XP mit (lokaler) Fritz-ISDn-Karte. Zu der Zeit wird kein weiteres Programm auf dem Rechner gestartet.
Da alles lokal abläuft kann ich ein Netzwerk-Problem m.E. ausschliessen.
Zwischen den einzelnen Abrufen vergeht auch brav die eingestellte Wartezeit.

Also auf 5 Uhr würde ich nicht wetten...

Mit 4:30 waren wir oft zu früh; mit 5:00 für die erste (von 10) Verbindungen im 5-Miuten-Takt fahren wir im Moment sehr gut - bis auf eben die ca. 2-3 Male pro Woche wo dann nix kommt.

Gruss, Holger

Wie gesagt, kenne ich kein RZ welches "so spät" die Daten bereitstellt. Aber es lohnt sich die Institute zu fragen. Die wissen eigentlich immer die Zeiten wann die Systeme welche Läufe haben und wann die Bereitstellungen sind.
@Holger: Ist es immer ein bestimmtes Institut welches nicht klappt oder ist es unterschiedlich?
Wenn es immer das gleiche Institut ist würde ich meinen Vorschlag wieder ins Spiel bringen, einfach 5-10 Min. nach der letzten Abholung einen zweiten Abholauftrag einstellen.
Gruß
Karsten

Nein; immer ein anderes; manchmal (selten) auch zwei.
Ich vermute dass einfach die Einwahl-Leitungen zu der Zeit nicht ausreichen? Wenn ich jedenfalls 'kurz nach 8 Uhr' per Hand den oder die Reste einsammle, dann geht es immer sofort.

Gruß, Holger

Hallo,

vielleicht kannst Du einfach den Waitparameter etwas höher setzen. D. h., dass Sfirm32 zwischen den Übertragungen etwas länger wartet.

Dies kannst Du versuchen zu ändern unter Sfirm32 / CoConet / FT 000X-Verzeichnis in der Capi.ini. Diese solltest Du auf allen FT-Verzeichnissen anpassen.

Naja, standardmässig steht dieser Eintrag bereits auf 30.

; Key : WAIT_TIMER
; Funktion: Legt die maximale Dauer in Sekunden fest, die auf Capi-
; Nachrichten gewartet wird. Ausgenommen hiervon sind
; DATA_B3_IND-Nachrichten.
;
; erlaubt : > 0
; Default : 5
WAIT_TIMER = 30

Bin mir aber nicht sicher, ob dieser noch höher gestellt werden kann. Wenn ich mich richtig erinnere, ist der maximale Wert bereits 30. Ein Versuch ist es aber wert.

Also, dass die Wählleitungen an sich nicht ausreichen, kann ich mir nicht vorstellen, da standardmässig nur nach der nächst freien Leitung von Sfirm32 gesucht wird und ist diese da, dann wird die Übertragung gestartet.

Ich könnte mir vorstellen, dass einfach die Zeit zwischen den Wählversuchen nicht ausreicht. Also Sfirm32 baut die ISDN-Verbindung auf, bekommt beim 1. Versuch eine Verbindung zur Bank X, baut den B-Kanal wieder ab und versucht die nächste Verbindung aufzubauchen. Und genau hier blockt die Leitung, weil der B-Kanal einfach noch nicht frei ist.

Deshalb klappt die Verbindung gemäss Deinen Angaben ab und zu und ab und zu nicht.

Holger, was mich zu Deinem Beitrag interessieren würde:

Es scheint ja auch so zu sein, dass bei Deinem Kunden, das Abholen der Auszüge über den SfAutomaten (tägliche Abholung) gesteuert wird. Hat der Kunde hierbei nur den SfAutomaten geöffnet? Oder lässt er Sfirm32 offen?

Bei einem Kunden mit einem ähnlich gelagerten Fall ist uns aufgefallen:

Die ISDN-Karte ist hier im Server. Sfirm32 2.0i ist installiert. Die Auszugsabholung für 3 Banken soll ca. 07.00 Uhr durch den Automaten abgearbeitet werden. Soweit so gut. Die Abarbeitung erfolgt auch. Nur hat der Kunde natürlich auf dem Server Sfirm32 nicht geöffnet, sondern der Automat läuft nur. An sich ist der Kunde auch um 07:00 noch nicht anwesend, so dass Sfirm32 auf seinem Client auch noch nicht geöffnet ist.

Die Auszüge werden abgeholt, aber dummerweise nicht eingelesen. Der STA bzw. die Sicherungsdatei steht dann im Archiv unter Eingang. Hier kann er natürlich eingelesen werden.

Ich erinnere mich aber an vorangegangene Versionen. Da erhielt der 1. der sich im Sfirm32 anmeldet eine Meldung, dass Auszüge zum Einlesen vorhanden sind.

Wie steuert ihr dies bei Euch? Ist Sfirm32 komplett geöffnet, funktioniert es natürlich. Der Kunde möchte aber aus Sicherheitsgründen, Sfirm32 auf dem Server nicht ständig offen lassen, ist ja auch verständlich.

den wait_timer kann man bis 40 stellen. alles dadrüber ist sinnlos. allerdings setzt das voraus das eine ältere sf32-version eingesetzt wird. Ab der 2.0h ist, glaube ich, nur noch das Omicron-FTAM-Modul unterstützt. Der Hinweis bezieht sich auf das Coconet-Modul. Im Omikron-Modul ist mir ein ähnlicher schalte nicht bekannt.

Gruß
Karsten

Solche Werte habe ich bei mir gar nicht gefunden. Selbst eine Suche (per Explorer) nach
"*capi*" hat nix ergeben. Eventuell habe ich gar keine CAPI installiert? Die Installation wurde von meinem Vorgänger gemacht.

Der "Kunde" bin ich übrigens selbst...

Ich habe nun eine Reihe weiterer FTAM-Aufträge erzeugt, die jeweils im Stundentakt von 4:00 bis 6:00 anlaufen. Damit nix überschrieben wird, ist jeweils ein anderer Dateiname angegeben. In der (Perl-) Weiterverarbeitung wird nun mit (dem Äquivalent von) "*.dti" gearbeitet.
Nun klappt es meist; wenn aber einer der Übertragungsversuche nicht erfolgreich war, verbleibt die Zeile im Status "gescheitert" und wird leider nicht am nächsten Tag noch einmal versucht...

Gruss, Holger

Leider gibt es eine automatische Wiederholung des Auftrages nicht mehr. Die Wiederholung (war in der 1.6 Version vorhanden) ist wohl deshalb unter den Tisch gefallen weil Kunden, die ein falsches DFUE Kennwort eingegeben hatten, durch die Wiederholungen gesperrt wurden.

Was Du aber machen koenntest waere folgendes:
Die DFUE-Auftraege fuer den Automaten werden im Sfirm Datenverzeichnis in der sfdfu.mdb gespeichert.
Nimm eine leere DFUE-Datenbank oder leere Deine vorhandene durch das loeschen aller DFUE-Auftraege (Extra->Reorg).
Lege den FTAM Auftrag zum abholen der Auszuege fuer die erste BPD-Datei/Bank an.
Kopiere die sfdfu.mdb beiseite.
Loesche den DFUE Auftrag und lege den naechsten Auftrag an und verfahre analog.
Am Schluss hast Du fuer jede Bank/BPD-Datei eine eigene sfdfu.mdb.
Nun laesst Du Dein Programm / Perlscript jeden morgen die vorhandene sfdfu.mdb sichern und durch die mit dem jeweiligen Kontoauszugsabholauftrag ersetzen. Das ersetzen laesst Du solange wiederholen bis das Auswerten des Automatenprotokolls erfolg oder keine Daten vorhanden meldet oder eine von Dir festgelegte maximale Anzahl der Wiederholungen erreicht ist.
Wenn alle sfdfu.mdb mit STA Auftraegen abgearbeitet sind die urspruengliche mdb wieder rein kopieren.

Der Automat pollt mit dem in seinen Optionen eingestelltem Intervall (n Minuten) die sfdfu.mdb und arbeitet die dort enthaltenen Auftraege ab. Falls der Zugriff auf die Datenbank fehlschlaegt gibt es eine Fehlermeldung und der Automat versucht es nach dem Ablauf des Intervalles nochmal.

Das ist zwar ein bischen Bastelarbeit , aber wenn Du eh mit Perl eine automatische Weiterverarbeitung steuerst sollte das kein Problem darstellen. Ich hoffe das die Idee dahinter und die funktionsweise des Automaten im Zusammenspiel mit der sfdfu.mdb ruebergekommen ist.

MfG

Jan