FTAM Sytemfehler 11

Hallo liebe Gemeinde,

ich soll von einer Kollegin eine Problem in einer Netzwerkumgebung mit SFirm32 mittels FTAM Kommunikation übernehmen. Ich kann derzeit (noch) nicht wirklich viele Informationen liefern (besonders nicht zu der verwendeten ISDN Hardware). Auf jeden Fall wird jedoch das FTAM Modul der Firma Omikron benutzt (32 bit, Capi 2.0 Basis). Der Fehler tritt wohl schon bei der Initialisierung auf.

Herstellerseitig gibt es den Tipp, bei Fehler 11 den Bankparamter-String zu überprüfen, ansonsten Trace Dateien ur Überprüfung zu erzeugen.

Ich möchte nur vorab schon mal Anfragen, ob es von eurer Seite aus spezielle Erfahrungen mit dem Systemfehler 11 gibt (Wann, welche Umgebung o.ä.). Später kannich vielleicht auch selber mehr Informationen liefern und hoffentlich auch eine Lösung präsentieren...

Gruß
Captain FRAG

Kann leider nicht mit Sicherheit sagen ob das mit besagtem Fehler 11 zusammenhängt - jedoch tritt häufiger (gerade bei den MultiCash, DreCash, HypoCash oder GENOcash Versionen 3.xx) das Problem auf, das die Capi nicht ordentlich angesteuert werden kann.

Von Omikron ist die derzeit aktuelle BETA-Version des FTAM-Moduls 3.01.003, die DZ Bank hat für Ihre Variante GENOcash aber erst die Version 3.00.005 freigegeben, vielleicht mal mit einer anderen Version versuchen?

Naja hat das Programm wirklich eine Terminal-Server-Freigabe? S-firm hat sie nicht. Obwohl ein reines Terminal-Server-Netzwerk sieht anders aus in meinen Augen als mit CLients, die eigene Laufwerke haben

Aber ein Capi-Fehler!?!?!?Vielleicht auch die Ini-Datein für das Ftam-Modul verrissen! Wie gesagt wichtig wäre zu wissen was am Bankrechner angekommen ist!


Gruß

Michael

So, das Problem hat sich heute zum Glück geklärt. Problem war, das der Systembetreuer aufgrund von Platzmangel bei dem Update das Datenverzeichnis verschoben und dann geupdatet hat. Da die Installation nebenbei auch auf ein neues FTAM-Modul umgestellt hat und der Terminal-Server auch noch mit den Konfigs gewürfelt hat, fand das neue FTAM Modul dann die von S-Firm erstellten Auftragsdateien nicht. Aber es kam eben der Befehl zum Versand und der Fehler11 sagt nicht viel mehr als "Auftrag nicht ausführbar". Ist dann ja auch logisch.

Ich habe dann manuell ein paar Konfigs umgeschrieben (dem Hilfetool sei Dank, waren die Änderungen einfach zu finden), noch ein Update gemacht und auf das alte Coconet Modul zurückgestellt. Danach ging wieder alles. Allerdings brauchte ich den Betreuer echt als Hilfe, wo der T-Server die Konfigdateien für die einzelnen Benutzer überall spechern kann, grenzt schon an Wahnsinn. Und vor allem die Frage, wann greift überhaut welche? Schon echt interessant. War auf jeden Fall ne Lehrstunde für den good old NT4 Terminalserver.

Ach ja, Mr. Nett, zu den lokalen Laufwerken:
Die lokalen Laufwerke der Terminals waren über Netzwerkfeigaben über den T-Server wieder auf die Terminals gemappt. Sah echt interessant aus:
z.B.
Laufwerk C auf dem Terminal war dann das Systemlaufwerk des Servers
Laufwerk C$ ist die lokale Platte im Terminal selbst, über den Server als Netzlaufwerk bereitgestellt

Im Prinzip hast du mit den verrissenen Konfigs aber schon ins schwarze getroffen.



<!--EDIT|Captain FRAG|9.09.2003-->