Troubleshooting

Wenn es zu Fehlern kommt, und die Verbindung nicht mehr hergestellt werden kann, beginnt der Ärger und meist ratloses Suchen nach dem Fehler. Dabei kann der Fehler an einer Fehlkonfiguration des eigenen Rechners, an der Transportstrecke (Modem und Telekom), oder auf dem Netzversorgungsrechner liegen. Es ist also nicht gerade einfach, den Fehler zu lokalisieren. Dieses Kapitel stellt die Schritte dar, die genügen, den Fehler immerhin zuzuordnen.

Nach dem ersten erfolgreichen Pollen sollte man zuerst ein Backup auf Diskette machen. Wichtig sind dabei vor allem die Dateien PERMISSN , PASSWD, SYSTEMS, UUPC.RC, [USER].RC.

Ansonsten gilt für UUPC mehr als für viele andere Programme: 'never change a running system'. Wer es trotzdem versucht, sollte erstmal ein Backup vor der Änderung machen und, sofern möglich, nur einen Parameter zur Zeit ändern.

Sollte es zu Fehlern kommen, empfiehlt sich folgende Vorgehensweise:

  1. Ist der Fehler reproduzierbar?
  2. Wo tritt der Fehler auf (vor dem Connect, beim Connect, nach dem Logout)?

    Um das herauszufinden, sollte man die Programme getrennt laufen lassen.
    Vom Prompt aufrufen:

  3. UUCICO.EXE und UUXQT.EXE können mit dem Parameter -x1 bis -x20 mit steigendem Debuglevel aufgerufen werden. Je höher der Wert gesetzt wird, desto redseliger wird das Programm. Debuglevel -x5 reicht in der Regel. Die Ergebnisse werden im Logfile, zu finden im Spoolverzeichnis, protokolliert. Bei Anfragen bei einem Experten ist es sinnvoll, solche Log-Mitschnitte zur Fehleranalyse mitzuschicken.
  4. Kommt nach einer erfolgreichen physikalischen Verbindung keine Verbindung zustande, liegt es meist an einem fehlerhaften Chat Script. Die Fehlermeldung ist dann 'SCRIPT FAILED'. Hat man sicher nichts am Loginscript (SYSTEMS) geändert, versucht man 5..
  5. Nimmt der Server an? Das kann man testen, indem man bei dem Server mit einem gewöhnlichen Terminalprogramm versucht, sich auf seinem Netzversorgungsrechner einzuloggen. Als LOGIN gibt man den Pointnamen, für PASSWORD dann das Passwort, das in SYSTEMS steht, an. Meldet sich der Versorgungsrechner dann 'shere=[servername]', ist von seiner Seite wahrscheinlich alles in Ordnung. Der Netzserver erwartet jetzt UUPC und nicht ein Terminalprogramm. Die Verbindung muß mit CRTL-C abgebrochen werden. Meldet sich der Versorgungsrechner nicht mit 'shere=[servername]' (auch hier kann 'SCRIPT FAILED' als Fehlermeldung ausgegeben werden), sollte man sich mit dem Postmaster des Versorgungsrechners in Verbindung setzen.
  6. Sollte nach dem CONNECT ein Fehler auf dem Server auftreten, wird als Fehler 'unexpected third message' ausgegeben. Auch hier empfiehlt es sich, Kontakt zum Postmaster des feed aufzunehmen.
Fragen kann man in den Newsgroups 'comp.os.os2.apps' und der deutschsprachigen Gruppe 'de.comp.os.os2' stellen. Für UUPC/EXTENDED gibt es eine Maillist, in die man sich eintragen lassen kann:
Mail an 'listserv@kew.com' mit dem Inhalt 'subscribe uupc-info'.

Inhalt | Einleitung | Der Alltag mit UUPC | Installation | Konfiguration | Spezielle Konfigurationen | Programme und Hilfsprogramme | Bezugsquellen

Heimatseite | OS/2-Eingang

Copyright 1995

kapeka@toppoint.de