| Index | Einführung | Benutzerteil | Verwalterteil | Anhang | Suche |
TTXENDE oder sogar abortjob
auf den TTXJOB ist wirkungslos.
TTXPORT xxx ABORTED"
(blinkend, invers-video)
Interface not ready
Störung bei Telematik-Anschluß xxx
Störung seit yymmdd hh:mm
und über diesen Anschluß werden keine
Nachrichten versandt.
Der Druckjob beendet sich nichtoder
oder
Abhilfe: Die betreffende Datei löschen und neu erzeugen:
Lösung in diesem Fall: Es genügt kurzfristig, mit
Danach sollte ein Neustart der Telematik möglich sein, und
alles sollte wiederum "rund laufen".
Hintergrund: In diesem Fall hat die Telematik keinerlei
Chance sich selbst zu "erfangen", weil das MPE
den betreffenden Prozess innerhalb des
Wenn ein Defekt des DTC vorliegt und dieser noch nicht
repariert werden konnte, man aber die Telematik sauber beenden
möchte, um die HP3000 niederzufahren - auch dann
kann die oben beschriebene Vorgangsweise zielführend sein.
Bitte stellen Sie sicher, daß die
Überprüfen Sie die Leitung, indem Sie die Telematik
stoppen, ein Terminal an den entsprechenden Anschluß
hängen und einen Logon versuchen. (Achtung:
Wenn der Logon erfolgreich ist und die Telematik mit dem Gerät
trotzdem nicht arbeiten kann, ist ein Hardwaredefekt (meist
Blitzschlag) am Telexinterface oder am Faxcontroller wahrscheinlich.
In solchen Fällen kann auch das Traceflag in der
Gerätekonfiguration der Telematik als Diagnosehilfe
herangezogen werden.
Der Druckjob beendet sich erst nach zweimaliger Aufforderung
Das ist die Folge eines MPE-Problems:
Wenn das Betriebssystem nicht kontrolliert beendet wurde,
z.B.: durch einen "system failure" oder eine
"harte Stromabschaltung", kann es vorkommen,
daß zu diesem Zeitpunkt geöffnete IPC-Dateien nachher
nicht mehr richtig funktionieren: Der Anstoß des lesenden
Prozesses erfolgt dann immer um einen Record zu spät.
Der Druckjob muß zweimal gestartet werden, beim ersten
Start beendet er sich ohne Aufforderung von selber
Das Druckprogramm liest daher den Beendigungsbefehl
(CMDREC 99) vom letzten Stop erst mit dem nächsten
eingetragenen Satz, eigentlich werden auch die Kontrollausdrucke
auf dieselbe Weise verzögert.
Damit sollte das Problem gelöst sein.abortjob"
DRUCKIPC.TTXDTA.TTX löschen und
neu erzeugen:
:hello mgr.ttx,ttxdta
:listf druckipx,2
:Build tmp;rec=-80,3,f,ascii
:File x=druckipc;STD
:fcopy from=*x;to=tmp
:purge druckipc
:build druckipc;msg;rec=-80,3,v,ascii
:fcopy from=tmp;to=druckipc
:purge tmp
:ttxan
:ttxdrjan
Kommentar: Man könnte zwar in der Reorganisation oder beim
Start des TTXJOB vorbeugend eine analoge Befehlsfolge
einbauen, das wäre jedoch nur dann eine gangbare Lösung,
wenn durch die Organisation gewährleistet ist, daß
verlorengegangene Druckaufträge "verschmerzt"
werden können, oder daß die Datei
DRUCKIPC zum Zeitpunkt der Reorganisation immer
leer ist.
Die Telematik/3000 läßt sich nicht beenden.
Es sind bisher 2 mögliche Ursachen bekannt, wo dieser Fall
aufgetreten ist:
LISTF,2
der Wert EOF kleiner als der Wert LIMIT
ist (das hängt mit der variablen Blockstruktur im MPE zusammen)!
fcopy die "Bestätigungsdatei" zu
entleeren. Langfristig muß aber eine andere
zielführende Lösung gefunden werden! Wenn die
Fremdapplikation die Daten ohnedies nie liest, kann man
die Datei auch als standard-sequentielle Datei anlegen
(wenn die Telematik EOF bekommt, wird sie das
ignorieren), oder die Bestätigungsdatei kann auch als
cirkulare Datei angelegt werden.sysdiag und termdsm
einen Reset auf das betreffende ldev machen, an dem
das Telematik-"Gerät" angeschlossen ist.Intrinsic
(meist beim open, wo man kein Timeout programmieren kann)
gefangen hält. Die MPE-Befehle abortjob
und abortio haben auf diesen einen Prozess keinen
direkten Einfluß, weil der Process-Control-Block
in diesem Wartegrund vom System nicht beachtet wird. Einzig der
Reset durch Termdsm läßt den Fehler
wirksam werden und erweckt den betroffenen Prozess wiederum zum
Leben.
Der für einen bestimmten Anschluß (ldev xxx) zuständige
Kommunikationsprozeß hat sich irregulär beendet.
Auf der Systemkonsole erscheint in regelmäßigen Anständen
die Meldung "TTXPORT xxx ABORTED"
(blinkend, invers-video)
$STDLIST des
TTXJOB, welcher gerade läuft, nicht verlorengehen kann.
Beenden Sie den TTXJOB, sichern Sie seinen Spoolfile und
senden Sie dieses an
office@cogidata.com.
Starten Sie die Telematik neu. Sollte der Fehler wieder auftreten,
stornieren Sie den auf diesem Anschluß zuletzt versuchten
Sendeauftrag (eventuell mit unserer Hilfe). Sollte der Fehler trotzdem
wieder auftreten, müssen wir per Modem auf Ihre HP3000, wobei uns
der oben gemachte Jobausdruck natürlich sehr hilft.
In diesem Fall sind 2 mögliche Ursachen wahrscheinlich:
Auf der Systemkonsole erscheint in regelmäßigen
Abständen die Nachricht:
Interface not ready
Störung bei Telematik-Anschluß xxx
Störung seit yymmdd hh:mm
und über diesen Anschluß werden keine Nachrichten versandt.
ACCEPT-
Befehl auf der Systemkonsole kann nötig sein). Solange
dieser Logon nicht möglich ist, kann die Telematik auch nicht
arbeiten.
Voraussetzung für die Erzeugung eines Kontrollausdruckes
ist, daß das Journalkennzeichen in der Anschlußmaske
für die Konfiguration (zu erreichen mit "weitere Werte" der
Controller auf "J") gesetzt ist. In dieser Maske befinden sich
auch andere spezifische Konfigurationseinstellungen, welche im Handbuch
nachzulesen sind.
Wir haben eine Konfigurationsänderung gemacht, und seither
erhalten wir keine Kontrollausdrucke für die Versendung mehr.
Index
Einführung
Benutzerteil
Verwalterteil
Anhang
Suche