Der Benutzer kommt mit den meisten Programmdateien aus dem UUPC-Paket nicht direkt in Berührung. Sie werden von anderen Programmen wie ELM und TRN aufgerufen, um Mail und News zu verarbeiten. Einige Programme werden zudem nur in Systemen benötigt, die Verbindungen zu mehreren Rechner unterhalten oder im passiven Modus arbeiten, das heißt: Anrufe entgegennehmen.
Wer nur bei einem Versorgungsrechner, der Toppoint z.B., pollt, kommt mit einigen wenigen Programmen aus. Die teilweise sehr umfangreichen Parameter für die jeweiligen Programme und Beschreibungen aller Programme, kann man in COMMANDS.PRN nachlesen.
Man lernt am meisten über die Programme, wenn man mit ihnen experimentiert. Das ist völlig ungefährlich. Bei einem Aufruf ohne Parameter wird meistens lediglich die Hilfe für das Programm ausgegeben. In jedem Fall läßt sich ein laufendes Programm mit CTRL-C abbrechen. Kein Programm verändert die Konfigurationsdateien.
Um einen Einblick zu geben, und um die vielfältigen Möglichkeiten von UUPC wenigstens anzudeuten, werden im Folgenden die Programme und ihre Funktionen vorgestellt.
uucico
Natürlich muß die Vorstellung mit dem zentralen Programm beginnen:
UUCICO.EXE. UUCICO.EXE führt den eigentlichen
Datenaustausch mit anderen
Systemen aus. UUCICO.EXE wird meist aus Batchfiles oder Rexxscripts
aufgerufen, kann aber auch vom Prompt direkt ausgeführt werden.
Die notwendigen Informationen über Modems, Ports, Pfade usw. werden aus den Dateien ausgelesen, deren Namen auf 'RC' endet. Die Einstellungen können aber alle auf der Kommandozeile durch Verändern der Startparameter überschrieben werden.
-------------------------------------------------------------------- * uucico -s all pollt bei allen in SYSTEMS angegeben Rechnern. * uucico -s System pollt nur bei dem angegebenen System, wenn die Zeiten, die in SYSTEMS eingestellt sind, eingehalten werden. * uucico -xdebuglevel erhöht schrittweise die Meldungen in UUCICO.LOG. Debuglevel ist eine Zahl zwischen 1 und 20 (mehr dazu im Kapitel Troubleshootig). Ohne Angabe, im normalen Betrieb, ist das Level auf 1 eingestellt. * uucico -l logname kann eine andere LOG-Datei als UUCICO.LOG festgelegen * uucico -m inmodem kann eine von der in SYSTEMS angegebenen Modemsteuerdatei abweichende Datei eingestellen * uucico -n ignoriert alle Zeitangaben in SYSTEMS und erlaubt es sofort zu pollen. * uucico -r0 lädt UUCICO.EXE, um im Hintergrund auf einen Anruf zu warten. Im Unterschied zum UNIX-Original ist die Standardeinstellung -r1, mit der UUCICO.EXE ein angegebenes System anruft. -----------------------------------------------------------------------Ausgewählte Startoptionen von UUCICO.EXE
Nach dem Pollen liegen im Spoolverzeichnis eine Menge neuer Dateien. Sie können unterteilt werden in Daten, die in '\spool\system\d' liegen und Steuerdateien mit Ausführungsbefehlen in '\spool\system\x'. Diese Anweisungen werden von UUXQT.EXE ausgeführt. Normalerweise steht da nicht viel mehr drin, als daß in einer Datendatei Mails sind und UUXQT RMAIL.EXE zum Ausliefern aufzurufen hat, oder News, die UUXQT mit dem RNEWS.EXE verarbeitet. UUXQT.EXE sollte also nach jedem erfolgreichen Pollen aufgerufen werden und wird deswegen häufig in einem Batchfile oder REXX-Script nach UUCICO.EXE angefügt.
Mit
uuxqt -x debuglevelkönnen die Programmmeldungen für die Fehlersuche differenziert eingestellt werden. Standard für debuglevel ist -x1.
uustat, uutraf und uusub
Mehr statistische Funktion hat UUSTAT.EXE. Es gibt Statusangaben
für Benutzer und Rechner aus. Darüberhinaus können noch nicht abgeschickte
Jobs (auf dieser Ebene werden Mail und News als Auftrag gesehen)
gelöscht werden.
------------------------------------------------------------------------ uustat -a zeigt wartende Jobs uustat -k jobid löscht den Job mit der Nummer jobid uustat -m zeigt kurz das Ergebnis des letzten Polls uustat -Psystem erstellt einen Dummyjob, sodaß der in [system] genannte Rechner auch dann angerufen wird, wenn keine Mails oder Newspostings in der Warteschleife sind. ----------------------------------------------------------------------Die drei wichtigen Funktionen von UUSTAT.EXE
Zwei weitere Programme die statitisches Material liefern, sind
UUSUB.EXE und UUTRAF.EXE. UUSUB.EXE gibt Statistiken über die
Verbindungen zu anderen Systemen aus. Der Parameter -c löscht
die bisher gesammelten Werte. Um UUTRAF.EXE zu nutzen, muß in der
UUPC.RC die Option 'syslog' eingetragen werden. Damit wird jeder
Datenaustausch und die Dauer der Verbindung in der Datei SYSLOG im
Spool-Verzeichnis protokolliert. Nach dem Aufruf von UUTRAF
werden gut sortiert die Angaben auf dem Bildschirm ausgegeben. Die
Datei SYSLOG kann nur von Hand gelöscht werden.
uuclean
Die meisten Aktionen von UUPC/Extended werden in LOG-Dateien protokolliert. Nach einiger Zeit nehmen die LOG-Dateien wachsenden Plattenplatz in Anspruch. Zudem veralten die Informationen. Die Übertragungsgeschwindigkeit von vor drei Monaten ist wohl kaum mehr wichtig. UUCLEAN.CMD ist ein Rexxscript, das die LOG-Dateien im Spool-Verzeichnis und Datenreste im Temp-Verzeichnis löscht. Wenigstens einmal im Monat sollte UUCLEAN.CMD aufgerufen werden, um Ordnung zu schaffen.
Syntax:
uuclean [spooldir [tempdir]]
Eine wenig beachtete Anwendung ist inzwischen das 'Fernkopieren', womit einst alles begann. Der Name uucp rührt ja von 'Unix-To-Unix-Copy' her. Mail und News sind lediglich spezielle Anwendungen des Fernkopierens. Das zum Fernkopieren nötige Programm UUCP.EXE ist auch in UUPC/Extended enthalten - und es ist fazinierend, wenn man gelegentlich (viel zu selten) damit arbeitet.
UUCP.EXE stellt Text- oder Binärdateien in eine Warteschleife für andere Systeme, die dann bei der Verbindung übertragen werden. Man kann damit recht einfach einzelne Files zwischen Systemen kopieren. So ist es möglich, Dateien aus den PD-Verzeichnissen der Toppoint zu holen. Die gegenüber dem Z-Modem-Protokoll, das mit ZOC zum Dateitransfer benutzt wird, langsamere Übertragungsrate wird durch die Schnelligkeit beim Einloggen udn Verzeichniswechsel wettgemacht.
Syntax:
uupc system!quelldatei zieldatei
Für die Toppoint gälte dann der folgende Aufruf von uupc:
uupc tpki!home\pd\os2\driver\ljos2.zip e:\uupc\publiv\ljos2.zip
legt die Datei ljos2.zip beim nächsten Pollen der tpki aus dem Verzeichnis '\home\os2\driver' in das Verzeichnis 'uupc\public' des eigenen Rechners. Umgekehrt gehts natürlich auch:
uupc e:\uupc\public\ljos2.zip tpki!home\pd\os2\driver\ljos2.zip
kopiert die Datei vom lokalen Rechner auf dem Rechner tpki in das
angegebene Verzeichnis. Das geht allerdings nur, wenn das lokale
System dort auch Schreibrechte hat. Einschränkend ist aber, daß das
vorliegende UUCP nur direkt und nicht über mehrere Stationen hinweg
kopieren kann.
uupoll
Nachdem der Einstieg geschafft ist, und das System stabil läuft, überlegt man sich bald, das Pollen zu automatisieren. Meist läuft es ganz unbeaufsichtigt wenigstens einmal am Tag und dann natürlich nachts, wenn es billiger ist. UUPOLL.EXE ermöglicht automatisches Pollen zu bestimmbaren Zeiten. Es ruft erst UUCICO.EXE, dann UUXQT.EXE auf. Dabei können alle Parameter, die bei UUCICO.EXE einstellbar sind, auch hier gewählt werden.
Mit dem Parameter -f hhmm wird der Zeitpunkt des ersten Pollens in Stunden (hh) und Minuten (mm) festgelegt, mit -i hhmm die Intervalle bis zum nächsten Pollen.
Bei uupoll -f 0200 -i 0800 wird z.B. das erste Mal um 2.00 Uhr morgens gepollt und dann alle acht Stunden bis zum Abbruch von UUPOLL.EXE mit CRTL-C.
Im Beispiel wird jeweils um 2.00 Uhr, 10.00 Uhr und 18.00 Uhr gepollt. Die gleichen Zeiten werden rein rechnerisch auch mit dem Aufruf
uupoll -f 1000 -i 0800eingestellt. Allerdings kann es sein, daß das Programm dann ins Wanken gerät und Fehler produziert. Deshalb sollte der Startzeitpunkt der früheste Zeitpunkt am Tag sein, also 2.00 Uhr.
Wird -i hhmm nicht angegeben, startet UUPOLL.EXE alle vier Stunden einen Anruf.
Soll UUPOLL.EXE nicht durchgehend aktiv sein, kann mit -e hhmm eine Tageszeit festgelegt werden, zu der UUPOLL.EXE automatisch beendet wird.
Die vielen hier nicht erwähnten Parameter, die an UUPOLL.EXE übergeben werden können, sind in COMMANDS.PRN nachzulesen.
Leider kann UUPOLL.EXE weder feststellen, ob es zu einem Connect
gekommen ist oder besetzt war, noch kann es Fehler auswerten, wenn
z.B. nach dem Connect kein Login möglich war. Wenn besetzt war, wird
nicht erneut versucht zu pollen, sondern erst zum nächsten
eingestellten Zeitpunkt wird wieder angerufen. So bleiben Mails unter
Umständen Stunden oder Tage zu lange in der Warteschlange. Bei
Fehlern zahlt man zwar die Telefongebühren für den Aufbau der
Verbindung, aber es können keine Daten ausgetauscht werden, und man
muß UUSTAT.EXE bemühen, um zu kontrollieren, ob der letzte Versuch
auch wirklich erfolgreich war. Deswegen haben sich viele Benutzer von
UUPC/Extended eigene REXX-Scripte geschrieben, die auf
unterschiedliche Weise die Probleme umgehen.
uuname
Um zu sehen, welche Systeme der lokale Rechner kennt, kann UUNAME.EXE gestartet werden. Es gibt, ohne Parameter aufgerufen, die Namen aller dem System bekannten Server aus. UUNAME.EXE wertet nur die Datei SYSTEMS aus. Das heißt, daß ein Server zwar bekannt sein kann, aber ohne einen Eintrag in PERMISSN können keine Daten zwischen dem lokalen Rechner und dem Versorgungsrechner ausgetauscht werden. Der Parameter -d gibt den Domainnamen des lokalen PC's, der Parameter -l den Namen des lokalen PC's zurück.
rnews, inews und rmail
Die drei folgenden Programme werden für gewöhnlich nie vom Benutzer
direkt aufgerufen, sondern entweder von UUXQT.EXE oder dem Mailer und
Newsreader. Aufgrund des Baukastensystems können aber um beide
Programme herum auch eigene Anwendungen gebastelt werden, die einen
Transportmechanismus benötigen. So ist es durchaus naheliegend, mit
REXX einen einfachen Mailserver zu basteln, der mit RMAIL.EXE Dateien
an den Absender einer Mail, der die Dateien anfordert, zu schicken.
RNEWS.EXE wird von UUXQT aufgerufen, wenn nach dem Pollen News angekommen sind. Die News kommen in einer Datei an. Eine zweite Datei hat die Anweisung, auf die erste Datei das Programm RNEWS.EXE anzuwenden. Genau dieses wird dann auch von UUXQT.EXE gestartet.
Das Gegenstück ist seit der Version 1.12i INEWS.EXE. Beim Posten eigener News wird INEWS.EXE vom Newsreader aufgerufen, um umgekehrt wieder die beiden Dateien zu erzeugen: Eine mit dem Text des Postings und eine Anweisungsdatei an das RNEWS auf dem empfangenden System, was es mit der Textdatei zu tun hat.
RMAIL.EXE unterscheidet sich nicht besonders von RNEWS.EXE und INEWS.EXE, nur daß es Mails verarbeitet. Der ELM macht nichts anderes, als aus dem Mailheader die Adresse und Mail an RMAIL.EXE zu übergeben.
uuport
Unter OS/2 ist es möglich, den COM-Port für andere Programme, die
diesen Port benutzen wollen, freizugeben. Dies geschieht mit dem
mitgelieferten Programm UUPORT.EXE (
uuport -s port). Mit einem zweiten Aufruf von UUPORT (
uuport -r port) wird der passive Modus, also das Warten von UUCICO.EXE auf Anrufer, wieder aktiviert. UUPORT kommuniziert mit UUCICO.EXE über Named Pipes, ein Verfahren, das relativ langsam ist. Der COM-Port wird auch freigegeben, wenn in einer zweiten Session UUCICO.EXE aufgerufen wird, um bei Servern zu pollen. Das passive UUCICO.EXE erhält den Port automatisch wieder zugewiesen.
Inhalt | Einleitung | Der Alltag mit UUPC | Installation | Konfiguration | Spezielle Konfigurationen | Troubleshooting | Bezugsquellen
Copyright 1995
kapeka@toppoint.de