_________________________________________________________________________
BiPoint v3.47 Zerberus(tm)-Netcall mit Telix(tm) v3.12
_________________________________________________________________________
Aufruf:
_______
CallD("BiPoint", Tel_Nr, Ext, Pass_Name, Protokoll);
_________________________________ <:-) ___________________________________
Die 'Features' des Programm-Pakets:
-----------------------------------
* Sie koennen alternativ X-, Y-, Z- und Bi-Modem(tm) zur Daten-
Uebertragung waehrend des Netcalls verwenden.
* Steuerung ueber eine einfache Konfigurationsdatei (BiPoint.CNF) im
Telix-Upload-Directory, deren Inhalt =vor= der Anwahl Ihrer
Server-Box ausgewertet wird.
* automatische Pruefung der in der Konfigurationsdatei von Ihnen
angegebenen Datei-Namen auf Gueltigkeit und Vorhandensein.
* Die unter Telix(tm) eingestellten Werte fuer Baud und COM-Port
werden selbstaendig an BiModem(tm) weitergegeben, so dass Sie
waehrend des Netcalls unabhaengig von der BiModem-Konfiguration
sind.
* Von frueheren Netcalls eventuell uebriggebliebene Dateien
'CALLER.xxx' und 'CALLED.xxx' werden automatisch geloescht, um einen
fehlerfreien Netcall zu gewaehrleisten.
* Bevor ein PUFFER versandt wird, fragt das Programm nach, ob Sie die
Datei versenden wollen, damit Sie nicht versehentlich frueher aus
Ihrer Box empfangene PUFFER neu aufs Netz schicken.
* Haben Sie keine Daten zu versenden (PUFFER nicht vorhanden), wird
selbstaendig eine (leere) 'Dummy'-Datei angelegt.
* Die von Ihnen zu versendende 'PUFFER'-Datei wird Ihren Angaben in
der Konfigurationsdatei entsprechend selbstaendig komprimiert.
* Die Verbindung zu Ihrer Zerberus(tm)-Box wird mit Ihrem Modem
automatisch hergestellt.
* Die Login-Prozedur der Box und der Datentransfer werden automatisch
abgewickelt - mit dem Uebertragunsprotokoll Ihrer Wahl.
* Das aufrufende Telix-Script erhaelt Ergebnis-Codes von 'BiPoint'.
* Nach erfolgreich abgewickeltem Netcall wird
- der empfangene Netcall-PUFFER automatisch extrahiert,
- die eingegangene Datei 'CALLED.xxx' geloescht,
- die Protokoll-Datei (capture) geloescht,
- die eingegangenen Nachrichten nach Wunsch angezeigt.
* Sie koennen die empfangenen Daten gleich bearbeiten, ohne Telix
verlassen zu muessen.
_________________________________ <:-) ___________________________________
im Paket enthaltene Dateien:
----------------------------
* BIPOINT.NEW:
Geschichte der Erweiterungen/Veraenderungen des Programmes
* BIREGIST.FRM:
Bezugsmoeglichkeiten und 'Registrierung'
* BICHECK.SLC:
Script zum Einlesen und Pruefen der Konfigurations-Datei
* BIPOINT.CNF:
Datei mit Ihrer Konfiguration
* BIPOINT.DOC:
diese Datei <:-))
* BIPOINT.SLC:
das eigentliche Netcall-Script
* BIPREP.BAT:
BATch-Programm zum Herstellen Ihres Netcall-PUFFERs
* BIVIEW.SLC:
Script zum Ansehen und Bearbeiten der eingegangenen Nachrichten
* ZERBERUS.SLT:
Script zum Einloggen in einer Zerberus-Mailbox
* ZERBERUS.SLC:
kompiliertes Mailbox-Script
* BIMODEM.CFG:
Beispiel-Konfiguration fuer BiModem
_________________________________ <:-) ___________________________________
Hard- und Software-Voraussetzungen:
-----------------------------------
* XT (-kompatibler) Rechner;
* ein beliebiges (von Telix ansteuerbares) Modem;
* Betriebssystem MS-DOS v3.xx;
* Das Shareware-DFUe-Programm 'Telix'(tm), mindestens v3.12,
lauffaehig installiert;
* Wollen Sie die Moeglichkeit der Netcalls mit dem Bimodem-Protokoll
nutzen, so benoetigen Sie das Shareware-DFUe-Programm 'BiModem'(tm),
v1.2x, lauffaehig installiert;
* Ein Account in einer Zerberus(tm)-Mailbox als 'normaler' User UND
ein Eintrag dort als sog. 'Point'/'Terminal' (den Sie mit dem/der
Sysop absprechen muessen);
* Ein Tool zum Bereitstellen der Zerberus(tm)-kompatiblen
Netcall-Datei 'PUFFER', z.B. die "Zimmermann Message Preparation
Utility v1.30";
_________________________________ <:-) ___________________________________
Installations-Hinweise:
-----------------------
Im Betriebssystem sind fuer die korrekte Funktionsweise der 'BiPoint'-
Software keine besonderen Einstellungen vorzunehmen. Achten Sie jedoch
generell darauf, dass Ihre COMSPEC-Umgebungsvariable den korrekten Wert
(Pfad und Name Ihres Kommando-Prozessors, i.d.R. "C:\COMMAND.COM")
enthaelt. (Ueberpruefen koennen Sie dies, indem Sie am DOS-
Bereitschaftszeichen (Prompt) den DOS-Befehl 'SET' eingeben, worauf Ihnen
u.a. der aktuelle Wert der COMSPEC-Umgebungsvariablen angezeigt wird.)
In Telix muessen insbesondere das Up- und Download-Verzeichnis sowie der zu
benutzende COM-Port und die Uebertragungs-Parameter richtig installiert
sein, auch da 'BiPoint' diese Einstellungen verwendet. Auch jener Befehl,
der Ihr Modem zum Waehlen veranlasst ("Dialing prefix", i.d.R. "ATDP"), und
jener, der eine Befehlszeile abschliesst ("Dialing suffix", i.d.R.
",,,^M"), muessen in Telix eingestellt sein. Auch der zu verwendende Editor
(in Telix mit ALT-A aufzurufen) muss korrekt angegeben sein, damit Sie die
eingegangene Post auch bearbeiten koennen. Installieren Sie schliesslich
die Telix-Puffer moeglichst klein. z.B.:
- "Scroll Back buffer size ... 4 (KBytes)"
- "Capture file buffer size ... 4 (KBytes)"
- "File xfer disk buf. size (Kb) ... 4"
Da das Programm-Paket recht umfangreich ist, koennten andernfalls bei
grossen Telix-Puffern eventuell Speicherplatzprobleme auftreten ("Not
enough memory"). Aus dem gleichen Grund sollten Sie auch vermeiden,
waehrend Ihrer DFUe-Sitzungen speicher-renitente Programme geladen zu
haben. Denn zum einen benoetigen diese bekanntlich ja (u.U. wertvollen)
Speicherplatz, und zum anderen haben einige von ihnen (zumal, wenn sie
geballt auftreten) die unangenehme Eigenschaft, Interrupts und Zeichen zu
'verschlucken', was dann beinahe notwendig zu Uebertragungsfehlern fuehrt.
Uebrigens: Da nach und nach immer mehr Mailboxen mit schnellen Modems (9600
und 19200 Bits/Sek.) arbeiten, muessen Sie ggf. mehrere Kommata hinter die
Telefonnummer schreiben, damit Ihr Modem etwas laenger wartet (i.d.R. 1/2
Sek. pro Komma), bevor es auflegt bzw. das Box-Modem auf Ihre
Geschwindigkeit heruntergeschaltet hat. (In der LINK-H und der OLN haben
sich 6 - 7 Kommata bewaehrt, was einer Wartezeit von etwa 3 Sekunden
entspricht, in der das Box-Modem auf 2400 herunterschalten kann.) In Telix
sollten Sie die selbstaendige Geschwindigkeits-Erkennung abschalten:
- "Auto baud detect .... Off"
(im Menu "Modem and dialing parameter setup"),
da es andernfalls zu Koordinationsproblemen zwischen den beiden beteiligten
Modems kommen kann, die letzlich eine Verbindung nicht zustande kommen
lassen koennen. 'BiPoint' schaltet fuer die Dauer seiner Arbeit daher diese
Option selbsttaetig aus.
Die Programme 'Bixxx.SLC' kopieren Sie bitte in das Verzeichnis, in dem Sie
Ihre Telix-Scripts abgelegt haben ("Script directory"). Die Konfigurations-
Datei 'BiPoint.CNF' kopieren Sie in das Verzeichnis, von dem aus Sie Ihre
Daten versenden ("Upload directory"). Einzustellen sind diese Verzeichnisse
im Telix-Untermenu "Filenames and paths" im Menu "Configure Telix", das Sie
mit 'ALT-O' aufrufen koennen. Fuer die Einzelheiten der Telix-Installation
verweisen wir auf die zu Telix gehoerende ausfuehrliche Dokumentation.
Die Datei 'BiPrep.BAT' kopieren Sie mit Marc Zimmermanns 'MsgPrep'
(entsprechende Dokumentation lesen!) in Ihr Point-Verzeichnis (das auch in
'BiPoint.CNF' anzugebende Verzeichnis, aus dem der PUFFER kommt) und passen
es an den darinnen angegebenen Stellen an Ihre Installation (Pfade etc.)
an.
Bei BiModem achten Sie bitte darauf, KEINE BiModem-Transfer-Liste
(BIMODEM.PTH) anzulegen, da es hiermit - wie sich im praktischen Betrieb
gezeigt hat - zu Koordinierungs-Problemen mit der 'BiNet'-Software ihrer
Box kommen kann. Ausserdem installieren Sie BiModem bitte so, dass von
Ihnen KEINE Ueberpruefung nach dem Transfer stattfindet
- "Always verify when done N"
sowie
- "Verify files when done transferring N"
Allerdings muessen Sie der 'BiNet'-Boxsoftware Zugriff von aussen
gestatten:
- "Allow remote file requests Y",
da die gegenwaertige BiNet-Software Ihrer Mailbox zur korrekten Funktion das
Ergebnis der Upload-Verifizierung benoetigt. Bekommt sie dies nicht,
erhalten Sie bei Ihrem naechsten Anruf alle alten Daten nocheinmal, weil
die Box davon ausging, dass die Uebertragung nicht geklappt hat und daher
die dort fuer Sie angelegte Point-PUFFER-Datei nicht loescht. Die
Mailbox-Software loescht auch CALLER.* und CALLED.* nicht einzeln, sondern
ueberschreibt sie erst bei einem naechsten Netcall.
Weil 'BiPoint' zur Auswertung des Netcalls in der Datei 'BiPoint.LOG' die
Angaben der verschickten Dateien benoetigt, hindern Sie BiModem auch daran,
diese Dateien zu loeschen:
- "Delete source file when done (Y/N) N",
dies erledigt 'BiPoint' nach einem ordnungsgemaess abgewickelten Netcall
ohnehin.
Als Hilfestellung fuer Ihre BiModem-Installation haben wir diesem Software-
Paket eine BIMODEM.CFG beigefuegt, die Sie in Ihr BiModem-Verzeichnis
kopieren und Ihren Wuenschen entsprechend anpassen (v.a. Dateinamen und
Pfade) koennen. - Generell sollten Sie die BiModem-Dokumentation aufmerksam
lesen, bevor Sie mit diesem leistungsfaehigen Protokoll arbeiten.
Wir empfehlen Ihnen darueberhinaus, in der Anfangszeit (bis BiModem auf
Ihrem Rechner und der Box korrekt arbeitet) Ihren Vertreter
(SYSOP@IHR_POINT) zu loeschen, damit keine persoenlichen Nachrichten
verlorengehen koennen, und Ihre Post 'zu Fuss' abzuholen. Hierfuer fuegen
wir ein kurzes Script im Quellcode bei ("ZERBERUS.SLT"), das Sie Ihren
Beduerfnissen entsprechend anpassen koennen. Die korrekte Funktionsweise
von 'BiPoint' koennen Sie bei BiModem-Uebertragungen waehrend des Transfers
beobachten und anhand der uebermittelten Daten pruefen.
_
Sollten Sie bisher noch keinen Point-Account in Ihrer Heimatbox haben,
besprechen Sie alle diesbezueglichen Einzelheiten (Name, Passwort,
Komprimierungs-Programm, Protokoll, Poll-Zeiten) mit dem/der Sysop Ihrer
Box.
Falls trotz korrekter Installation aller beteiligten Programme einmal
Probleme auftreten sollten, die Sie auch mit dem/der Sysop Ihrer Box nicht
loesen koennen, schicken Sie uns mit per e-mail die Bildschirmdump-Datei
'BiPoint.IMG' (unter Telix "Screen Image ... Alt-I" erzeugbar), aus dem die
Fehler-Meldungen zu ersehen sind, oder eine (moeglichst genaue)
Problembeschreibung. Wir versprechen Ihnen, soweit es in unseren
Moeglichkeiten liegt, bei der Behebung von Problemen im Zusammenhang mit
der 'BiPoint'-Software behilflich zu sein.
_________________________________ <:-) ___________________________________
Die Arbeitsweise der Scripts:
-----------------------------
Nachdem Sie Telix gestartet haben, rufen Sie 'BiPoint' auf, indem Sie Ihr
selbstgeschriebenes Script (mit ALT-G) starten. Als Muster dafuer koennen
Sie bspw. das unten abgedruckte Script (zum Netcall mit der OLN) verwenden.
Haben Sie als Protokoll-Parameter darin keinen gueltigen Kennbuchstaben
('B', 'X', 'Y' oder 'Z') angegeben, werden Sie in einem Bildschirmfenster
aufgefordert, das gewuenschte Uebertragungsprotokoll auszuwaehlen:
____________________________________________________________
_ _____ [B]iModem [X]Modem [Y]Modem [Z]Modem ____ _
_ _
_ Welches Uebertragungs-Protokoll soll verwendet werden?_ _
____________________________________________________________
Dies ist die einzige Stelle im Programm, an der KEIN automatischer Abbruch
stattfindet, falls Sie nichts eingeben. Achten Sie daher bitte darauf, dass
Sie in Ihrem aufrufenden Script einen gueltigen Kenn-Buchstaben angeben, da
in diesem Fall das Protokoll-Menu gar nicht erst erscheint.
Zur Sicherheit unterbricht das Programm nun eine eventuell noch bestehende
Verbindung ("Hanging up"). Ausserdem werden eventuell (von frueheren
Netcalls) noch vorhandene CALLER.xxx und CALLED.xxx geloescht. Da Bi- und
Z-Modem bekanntlich einen (z.B. aufgrund eines Leitungszusammenbruchs)
unterbrochenen Dateitransfer wiederaufnehmen kann, fragt 'BiPoint', falls
Sie fuer Ihren Netcall das Bi- oder ZModem-Protokoll verwenden, jedoch
zuerst nach, ob die Download-Datei geloescht werden soll:
____________________________________________________________________
_ CALLED.ARC 22089 Bytes vom 29.11.90 um 23:48:00 loeschen (J/N)? __
____________________________________________________________________
Dann wird Ihre Konfigurations-Datei 'BiPoint.CNF' eingelesen und die
Eintraege darin ueberprueft. Sollten die dort von Ihnen angegebenen
Programme ('Packer' und BiModem) nicht vorhanden sein, oder waehrend des
Einlesens Fehler auftreten, wird das Programm (mit einem entsprechenden
Ergebnis-Code, s.u.) abgebrochen. Das gleiche gilt, wenn die Datei im
Telix-Upload-Verzeichnis nicht gefunden werden konnte, wobei Ihnen dieser
Umstand zusaetzlich ausdruecklich mitgeteilt wird:
________________________________
_ _
_ BiPoint.CNF nicht gefunden _
_ _
________________________________
Sofern es in dem angegebenen Verzeichnis eine PUFFER-Datei gibt, werden Sie
als naechstes gefragt, ob Sie diese versenden wollen, etwa in dieser Art:
__________________________________________________________________
_ PUFFER 46180 Bytes vom 29.11.90 um 23:30:16 versenden (J/N)? __
__________________________________________________________________
Reagieren Sie innerhalb von 30 Sekunden darauf nicht, wird 'NEIN'
angenommen und nichts verschickt. Auf diese Weise ist es einerseits
moeglich, die 'BiPoint'-Software auch unbeaufsichtigt laufen zu lassen,
ohne dabei versehentlich Daten aufs Netz zu schicken, die nicht dorthin
sollen. Andererseits soll so vermieden werden, dass Sie frueher aus dem
Netz geholte Daten erneut versenden (was wegen des gleichen Namens PUFFER
fuer sowohl empfangene als auch zu versendende Daten ein beinahe
'klassischer' Fehler ist).
Das in der Konfigurationsdatei angegebene Programm zum Packen der Daten
wird aufgerufen und der PUFFER versandfertig komprimiert, was Ihnen durch
einen entsprechenden Hinweis gemeldet wird:
______________________________________________________
_ _
_ Die Datei PUFFER wurde zum Versand komprimiert _
_ _
______________________________________________________
Sollten waehrend des Komprimierens Fehler aufgetreten sein, die Ihr
'Packer' meldet (z.B. falsche Aufrufparameter), so werden Sie auf den
Effekt hingewiesen:
____________________________________________
_ _
_ PUFFER konnte nicht komprimiert werden _
_ _
____________________________________________
Falls keine PUFFER-Datei vorhanden war oder Sie die vorhandene nicht
versenden wollten, erscheint stattdessen folgender Hinweis:
___________________________________________________
_ _
_ Dummy-PUFFER wurde zum Versand fertig gemacht _
_ _
___________________________________________________
Praktisch bedeutet dies folgendes: Da Ihre Box bei einem Netcall ja
erwartet, auch Daten uebermittelt zu bekommen, muessen Sie auch welche
versenden. Haben Sie nun keine, so wird eine Datei versandt, die lediglich
eine Leerzeile (CR/LF) enthaelt - und die Box ist's zufrieden.
Wenn bis hier alles ordnungsgemaess abgewickelt wurde, erscheint ein
weiterer, kurzer Hinweis, aus dem Sie das verwendete Protokoll sowie Ihren
Point-Namen ersehen koennen:
_____________________________________________________
_ _
_ Bi-Modem-Netcall [EVALUATION COPY fuer MY_POINT] _
_ _
_____________________________________________________
Jetzt wird das 'Protokoll' (capture-file) angelegt. Sollten hierbei
irgendwelche Probleme auftreten (wofuer es eigentlich nur zwei
(unwahrscheinliche) Gruende geben kann: 1. Ihre Platte ist voll bzw. kein
Platz mehr im Directory; 2. es existiert unter dem Namen eine
schreibgeschuetzte Datei), wird Ihnen dieser Umstand angezeigt:
_______________________________________
_ _
_ Fehler beim Oeffnen der Log-Datei _
_ _
_______________________________________
Erst jetzt startet Telix die Anwahl Ihrer Mailbox und stellt die Verbindung
her, was Ihnen im Erfolgsfalle durch einen entsprechenden Hinweis angezeigt
wird:
________________________________________________________
_ _
_ Verbindung hergestellt - NetCall hat begonnen ... _
_ _
________________________________________________________
Sollte sich die Box jedoch innerhalb von sechs Minuten nicht korrekt
melden, so erscheint der folgende Hinweis auf Ihrem Bildschirm:
___________________________
_ _
_ Box meldet sich nicht _
_ _
___________________________
Falls waehrend der Phase des Einloggens und der Identifikation aus
irgendwelchen Gruenden (bspw. schlechte Leitungsqualitaet) die Verbindung
unterbrochen worden sein sollte, werden Sie auch hierauf hingewiesen:
_______________________________
_ _
_ Traegersignal verloren! _
_ _
_______________________________
Bei all diesen (seltenen, aber nicht unmoeglichen) Fehlern werden alle
folgenden Schritte nicht ausgefuehrt, das Script stattdessen abgeschlossen
und die entsprechende Fehlerursache in der Datei 'BiPoint.LOG' vermerkt.
Dann identifiziert sich Ihr 'BiPoint' gegenueber der Box und tauscht die
Daten (mit dem Protokoll Ihrer Wahl) aus. Sobald die wechselseitige
Identifikation abgeschlossen ist, komprimiert die Mailbox die fuer Sie
bereitliegenden Daten. 'BiPoint' macht Sie hierauf entsprechend aufmerksam:
___________________________________
_ _
_ Box komprimiert Netcall-Datei _
_ _
___________________________________
Nach Ende des Netcalls wird die Leitung unterbrochen ("Hangup") und Sie
werden entsprechend informiert:
__________________________________________________
_ _
_ NetCall wurde beendet - Leitung unterbrochen _
_ _
__________________________________________________
Sollte unterdessen ein Fehler aufgetreten sein, werden Sie auch am Monitor
darauf hingewiesen, z.B. so:
________________________________________
_ _
_ NetCall beendet mit Fehlercode -5 _
_ _
________________________________________
Die Bedeutung der einzelnen Ergebnis-Codes ist im folgenden erklaert und
geht auch aus dem Beispiel-Script unten (zum Netcall mit der OLN) hervor: _
0 = Netcall erfolgreich abgewickelt
-1 = BiModem-Verbindung konnte nicht hergestellt werden (abhaengig von
BiModem-Installation: "Number of seconds to wait for connect")
-2 = PUFFER konnte nicht extrahiert werden (wg. falschem Parameter fuer
das Dekomprimierungs-Programm oder schlechtem Sektor(en) im Bereich
der empfangenen Datei CALLED.xxx)
-3 = CALLED.xxx nicht angekommen (duerfte eigentlich nie auftreten,
laesst auf eine defekte FAT schliessen - Virus im System?)
-4 = Login in Mailbox fehlgeschlagen (entweder hat sich die Box innerhalb
von 3 Minuten nicht korrekt gemeldet, oder die Leitungsverbindung
wurde zwischendurch unterbrochen)
-5 = Anwahl erfolglos (entweder war waehrend der in der Konfigurations-
Datei 'BiPoint.CNF' angegeben Anzahl von Anwahlversuchen staendig
besetzt, das Traegersignal (CARRIER) ist verlorengegangen oder Sie
haben das 'BiPoint'-Script beim Waehlen mit ESC abgebrochen)
-6 = Konfigurations-Datei fehlerhaft (Falsche Reihenfolge? Ungueltige
Eintraege? - Ueberpruefen Sie 'BiPoint.CNF'!)
-7 = Carrier beim Upload (mit XYZ-Modem) verloren
-8 = Uebertragung beim Upload (mit XYZ-Modem) abgebrochen
-9 = Carrier beim Download (mit XYZ-Modem) verloren
-10 = Uebertragung beim Download (mit XYZ-Modem) abgebrochen
-11 = waehrend BiModem-Transfer Carrier verloren
-12 = veraenderte BiModem-Version auf der anderen Seite (gepatcht oder
Viren-infiziert)
-13 = CTS ist ausgeschaltet (abhaengig von BiModem-Installation: "CTS/RTS
hardware flow control (Y/N)")
-14 = zu viele Fehler waehrend Uebertragung (abhaengig von BiModem-
Installation: "Max # of errors before disconnect")
-15 = unbekannter BiModem-Fehler (fuehrt nicht zum Programm-Abbruch)
-20 = Text-Anzeige-Programm nicht gefunden
-21 = (Telix-)Editor nicht gefunden (wenn Sie in Telix den mit ALT-A
aufzurufenden Editor nicht korrekt angegeben haben)
-22 = PUFFER nicht gefunden (sollte nur passieren, wenn Sie weder einen
PUFFER verschickt noch einen empfangen haben)
-23 = PUFFER bis zum Ende gelesen (sic!)
-24 = PUFFER-Bearbeitung beendet (durch entsprechende Menu-Auswahl)
Schliesslich wird die empfangene PUFFER-Datei auch gleich 'ausgepackt', was
Ihnen ebenfalls mitgeteilt wird:
___________________________________________
_ _
_ Die Datei PUFFER wurde dekomprimiert _
_ _
___________________________________________
Wurden saemtliche Schritte bis hierher fehlerlos abgewickelt, so wird das
eigene 'Logbuch' (capture-file) geloescht, die Datei 'BiPoint.LOG' auf den
neuesten Stand gebracht, die Dateien CALLER.xxx sowie CALLED.xxx geloescht.
Nach einem ZModem-Netcall finden Sie in der Datei 'BiPoint.LOG' einen
Eintrag nach folgendem Muster:
90.12.01 18:42:13 __ Z-Modem-Netcall _
90.12.01 19:09:12 Connected with : Manually entered number.
90.12.01 19:09:12 ++ At phone # : 0202473086
90.12.01 19:09:12 ++ Settings : 9600,N,8,1
90.12.01 19:09:16 Elapsed time until Connection : 00:27:01
90.12.01 19:09:31 Upload using Zmodem protocol.
90.12.01 19:09:31 ++ File : \UPLOAD\CALLER.ARC
90.12.01 19:09:35 ++ Chars per second : 639
90.12.01 19:09:40 Download using Zmodem protocol.
90.12.01 19:09:40 ++ File : \Download\called.arc
90.12.01 19:10:50 ++ Chars per second : 658
90.12.01 19:11:04 __ Netcall erfolgreich abgewickelt _
_
Nach einem Netcall mit BiModem sieht der Eintrag aehnlich aus:
90.12.03 23:35:58 __ Bi-Modem-Netcall _
90.12.03 23:39:03 Connected with : Manually entered number.
90.12.03 23:39:03 ++ At phone # : 05113505604
90.12.03 23:39:03 Elapsed time until Connection : 00:03:02
90.12.03 23:39:03 ++ Settings : 2400,N,8,1
90.12.03 23:39:47 Upload using BiModem protocol.
90.12.03 23:39:47 ++ File : CALLER.ARC
90.12.03 23:39:47 ++ Transfer : Successfull (5176 bytes)
90.12.03 23:39:47 ++ Chars per second : 272
90.12.03 23:39:47 ++ Remote-ID : OekolineMailbox SYSOP@OLN.ZER v1.23 -350 5604
90.12.03 23:44:16 Download using BiModem protocol.
90.12.03 23:44:16 ++ File : CALLED.ARC
90.12.03 23:44:16 ++ Transfer : Successfull (65217 bytes)
90.12.03 23:44:16 ++ Chars per second : 225
90.12.03 23:44:16 ++ Remote-ID : OekolineMailbox SYSOP@OLN.ZER v1.23 -350 5604
90.12.03 23:44:37 __ Netcall erfolgreich abgewickelt _
90.12.03 23:44:37 Elapsed time online 00:05:21
Beachten Sie bitte, dass die Datei 'BiPoint.LOG' dann nicht ordnungsgemaess
geschlossen werden koennte, wenn Sie das Script zwischendurch (mit ESC)
abbrechen wuerden. Daher wird diese Moeglichkeit des Programm-Abbruchs
unterbunden - lediglich in dem Fenster, mit dem Telix Ihnen anzeigt, dass
gerade gewaehlt wird, koennen Sie (mit ESC) 'BiPoint' abbrechen. In diesem
Fall erscheint in der Datei 'BiPoint.LOG' die Meldung "Anwahl erfolglos".
Noch ein Hinweis zu BiModem: Aeltere BiModem-Versionen als v1.22 koennen
die Telefon-Nummer des Gegenuebers NICHT korrekt darstellen: Auf dem
Bildschirm waehrend des Datentransfers sehen Sie eine praktisch
willkuerliche Nummer. Achten Sie zumindest darauf, bei BiModem Ihre eigene
Nummer richtig zu formatieren ("Phone number edit mask").
Nachdem Sie nun also einen neuen PUFFER empfangen haben, koennen Sie sich
die einzelnen Nachrichten gleich ansehen. Dabei erscheint ein
Bildschirm-Fenster etwa dieser Art:
_______________________________________________________________________
_ _
_ Datei :\POINT\PUFFER 13043 Byte von 34323 gelesen _
_ _
_ Empfaenger :/Z-NETZ/TELECOM/NETZWERKE _
_ Nachricht von:BRIAN_O'FISH@MULI.ZER _
_ Betreff :Hitchikers Guide to Zerberus Netcalls _
_ Datum :19.07.1990 - 09:10 _
_ Route :MIDGET!MULI!HHN!GCS!INFINET!LINK-H!OLN _
_ ID :49.222@MIDGET _
_ Typ :Text _
_ Groesse :13043 Bytes _
_ _
_______________________________________________________________________
Sie koennen nun entscheiden, wie Sie weiter verfahren wollen, indem Sie aus
dem folgenden Menu die gewuenschte Option durch die entsprechende Taste
auswaehlen:
____________________________
_ _
_ [L]esen _
_ [W]eiter Blaettern _
_ [S]peichern als Datei _
_ [A]ntwort ins Brett _
_ [P]ersoenliche Antwort _
_ [B]eenden _
_ _ _
____________________________
Wenn Sie innerhalb von 5 Minuten (300 Sekunden) keinen Menu-Punkt waehlen,
so gibt 'BiView' den Code -24 (Arbeit beendet) an das aufrufende 'BiPoint'-
Programm zurueck. Durch diese Schleife soll zwei einander widersprechenden
Anspruechen Rechnung getragen werden: Zum einen koennen Sie auf diese Weise
'in aller Ruhe' ueberlegen und auswaehlen; zum anderen aber koennen Sie
'BiPoint' auch unbeaufsichtigt im Batch-Betrieb laufen lassen. Wenn Sie am
Ende Ihres Telix-Scripts, mit dem Sie 'BiPoint' aufrufen, den "ExitTelix"-
Befehl verwenden, wird das DFUe-Programm auch gleich verlassen, und Sie
koennen irgendeines Ihrer DOS-BATch-Programme weiterarbeiten lassen.
Wollen Sie die Nachricht [L]esen, so wird das in Ihrer Konfigurations-Datei
angegebene Anzeigeprogramm gestartet (empfehlenswert: 'LIST' bzw. 'FV' von
Vernon D. Buerg). Handelt es sich um eine Text-Datei, wird der Textlister
aufgerufen, andernfalls das Programm zum Anzeigen von Binaerdateien.
Selbstverstaendlich koennen Sie auf die Nachricht auch antworten: entweder
(privat) an den Absender oder (oeffentlich) in das Brett, in dem die
Nachricht steht. Dazu wird ein neuer Nachrichtenkopf generiert und Ihr
Editor gestartet, dem die Antwortdatei uebergeben wird. Diese sieht bei
einer [P]ersoenlichen Antwort ungefaehr so aus:
------------------------------schnipp-------------------------------------
BRIAN_O'FISH@MULI.ZER
A. auf: Hitchikers Guide to Zerberus Netcalls
T
In seiner Nachricht vom 19.07.1990 schreibt BRIAN_O'FISH@MULI.ZER:
------------------------------schnapp-------------------------------------
[A]ntworten Sie oeffentlich im Brett, so sieht es etwas anders aus:
------------------------------schnipp-------------------------------------
/Z-NETZ/TELECOM/NETZWERKE
A. auf: Hitchikers Guide to Zerberus Netcalls
T
In seiner Nachricht vom 19.07.1990 schreibt BRIAN_O'FISH@MULI.ZER:
------------------------------schnapp-------------------------------------
Nachdem Sie Ihren Text geschrieben und mit Ihrem Editor gespeichert haben,
werden Sie nocheinmal gefragt, ob Sie die Antwortdatei tatsaechlich
verschicken moechten:
_______________________________________________________________________
_ 64876089.MSG 987 Bytes vom 29.08.90 um 22:59:38 verschicken (J/N)? __
_______________________________________________________________________
Auch hier gilt wieder, dass Sie innert 30 Sekunden antworten sollten, da
sonst Nein angenommen wird. Beantworten Sie die Frage (so oder so) mit
Nein, wird die Antwortdatei geloescht, so dass Sie sich Ihre Platte nicht
'zumuellen'. Der Dateiname wird uebrigens aus der jeweils aktuellen
Systemzeit und -datum generiert, so dass doppelte Dateinamen mit hoher
Wahrscheinlichkeit vermieden werden.
Beachten Sie bitte, dass Sie zum Versenden (bzw. dem Generieren eines
Versand- PUFFERs) derzeit noch auf ein seperates Programm angewiesen sind
(z.B. die "Zimmermann Message Preparation Utility"). Unser Modul
'BiPrep.SLC' befindet sich noch in der Entwicklung und kann daher derzeit
noch nicht mitgeliefert werden. Stattdessen fuegen wir diesem Paket die
Datei 'BiPrep.BAT' bei, die in Zusammenarbeit mit Marc Zimmermanns
'MsgPrep' einen Netcall-PUFFER bereitstellt.
Falls Sie die Nachricht (seperat von der PUFFER-Datei) [S]peichern wollen,
wird eine entsprechende Datei angelegt und dies am Bildschirm angezeigt:
___________________________________________________________
_ _
_ Nachricht wurde gespeichert als: \POINT\64876190.TxT _
_ _
___________________________________________________________
Fuer die Generierung des Dateinamens gilt das gleiche wie oben erwaehnt:
die Systemzeit und -datum werden verwendet.
Wenn Sie [W]eiterblaettern, wird Ihnen der naechste Nachrichtenkopf w.o.
angezeigt. Auf diese Weise koennen Sie den gesamten eingegangenen PUFFER
lesen und verarbeiten. Schliesslich werden Sie dann darauf hingewiesen,
dass die Datei vollstaendig gelesen wurde:
___________________________
_ _
_ PUFFER zuende gelesen _
_ _
___________________________
Sie koennen das Lesen jedoch auch zwischendurch [B]eenden, was Ihnen dann
ebenfalls auf dem Bildschirm quittiert wird:
____________________
_ _
_ Arbeit beendet _
_ _
____________________
Abschliessend wird die Kontrolle an das aufrufende Script (das Sie nach dem
unten abgedruckten Muster selbst erstellen koennen) zurueckgegeben. Dort
koennen Sie nach Bedarf den zurueckgegebenen Ergebnis-Code auswerten.
_________________________________ <:-) ___________________________________
Was ist ein Point:
------------------
Es ist recht zeitraubend, wie ueblich 'online' in eine Box zu gehen, um
dort die neuesten Nachrichten zu lesen: Zunaechst muss man warten, bis die
Box frei ist und man sich einloggen kann - nicht selten (zumal am fruehen
Abend) sind dazu Dutzende von Anrufen noetig. Bis man dann jene Bretter
angewaehlt hat, in welchen man nachsehen moechte, und die interessanten
Artikel rausgepickt hat, die man lesen moechte, vergeht wieder kostbare
Zeit (und entstehen Teflon-Kosten).
Ist man dagegen als sog. 'Point' an eine Zerberus-Mailbox angeschlossen,
erhaelt man alle neuen Nachrichten in den bestellten Brettern automatisch.
Dazu ruft der Point regelmaessig bei seiner Mailbox an. Die gesamte
Uebertrageung laeuft automatisch ab. Da die Daten komprimiert uebertragen
werden (z.B. "geARCt"), wird zusaetzlich die Telefonrechnung geschont.
Damit kann man zumindest Boxen im Nahbereich auch tagsueber im
8-Minuten-Takt anrufen, zumal dann die Box auch eher frei ist.
Anschliessend kann man in Ruhe ('offline') die Nachrichten lesen sowie ggf.
beantworten. Und weil dabei auch kein Gebuehrenzaehler mit-tickt, kann man
genauer lesen oder zum Beantworten auch mal in der Literatur
(Buecher/Zeitschriften) nachschlagen.
_________________________________ <:-) ___________________________________
Das 'Abonnieren' von Brettern:
------------------------------
Mailbox-Bretter, deren Inhalt Sie regelmaessig beziehen moechten, koennen
Sie bei Ihrer Box gewissermassen 'abonnieren'. Dazu gibt es zwei Wege, die
Sie mit dem/der Sysop Ihrer Box absprechen muessen.
Der eine Weg besteht darin, dass Sie dem/der Sysop mitteilen, welche
Bretter Sie beziehen moechten. Alles weitere wird dann in der Box
veranlasst.
Da dies fuer alle Beteiligten ein recht aufwendiger Weg ist, wurde von den
'Muli labs' (Brian O'Fish) ein Hilfsprogramm entwickelt, das Ihnen die
Moeglichkeit bietet, je nach Bedarf Bretter zu abonnieren oder auch wieder
abzubestellen. Das geschieht einfach dadurch, dass Sie dem Pseudo-User
"MAPS" eine Nachricht mit ihren Wuenschen schicken. BEVOR Sie dies aber
tun, senden Sie bitte zunaechst nur eine Nachricht an MAPS mit dem Betreff
HILFE *
Einen Text braucht Ihre Nachricht nicht zu enthalten - er wuerde ohnehin
ignoriert - eine Leerzeile reicht. Mit Ihrem naechsten Netcall erhalten Sie
dann von der Box ausfuehrliche Hinweise dazu, auf welche Weise mit MAPS im
Detail umzugehen ist. Erst nachdem Sie diese Hilfetexte aufmerksam gelesen
(und bei Bedarf mit dem/der Sysop besprochen) haben, sollten Sie
tatsaechlich mit MAPS arbeiten.
_________________________________ <:-) ___________________________________
Das Weiterleiten persoenlicher Nachrichten:
-------------------------------------------
Sofern Sie persoenliche Nachrichten an andere UserInnen versenden wollen,
aendert sich fuer Sie durch die Benutzung eines 'Points' zunaechst einmal
gar nichts - abgesehen davon, dass Sie erhebliche Telefongebuehren sparen
koennen, weil Sie nun ja nicht mehr 'online' arbeiten, sondern in Ruhe
zuhause. Die Adressierung (V.NACHNAME@BOX.ZER) an UserInnen anderer Boxen
bleibt die gleiche. Beachten Sie bitte nur, dass Sie bei Nachrichten an
NutzerInnen Ihrer Heimatbox lediglich den Namen der Empfaenger (ohne:
@BOX.ZER) angeben.
Damit auch jene Nachrichten, die in Ihr persoenliches Postfach gesendet
werden, an Ihren Point (via Netcall) weitergeleitet werden, muessen Sie in
Ihrer Box einen STELLVERTRETER benennen: SYSOP@MY_POINT. Nachdem Sie in
Ihrer Heimatbox diesen Befehl eingegeben haben, werden automatisch alle
persoenlichen Nachrichten in Ihre Netcall-Datei einsortiert und Ihnen beim
naechsten Anruf uebermittelt.
_________________________________ <:-) ___________________________________
Das Netcall-Script:
-------------------
Ihr eigenes Script zum Netcall in der OLN koennte bspw. so aussehen:
--------------------------------- schnipp ---------------------------------
/////////////////////////// CallOLN.SLT ////////////////////////
// //
// Telix-Salt-Script zum automatisierten Einloggen bei OekoLine //
// //
// Kontaktadresse oekoline //
// ----------------------- //
// Udo Schacht-Wiegand //
// Moorkamp 46, 3000 Hannover 1 //
// Tel: 0511-350 30 81 (privat, bis 22 Uhr) //
// OLN-Mailbox: 0511-350 56 04 (300 bis 9600 Baud, 8N1) //
// //
// In der Mailbox: SYSOP oder U.SCHACHT-WIEGAND //
// //
/////////////////// (C) 1989,90 DFG/M.Watermann ///////////////
Main()
{
Int
Erfolg;
Erfolg = CallD("BiPoint", "05113505604,,,", "OLN", "PASSWORT", "B");
// ^ ^ ^ ^ ^
// | | | | |_ Protokoll
// | | | |
// | | | |_ Point-Passwort
// | | |
// | | |__ Endung der Capture-Datei
// | |
// | |___ Telefonnummer der Mailbox
// |
// |___ Name des Telix-BiModem-Scipts
//
PrintS(); // Leerzeile
if (Erfolg == 0)
{
PrintS(" Netcall erfolgreich");
}
else
{
Tone(523, 10); Tone(659, 10);
Tone(523, 10); Tone(659, 10);
if (Erfolg == -1)
PrintS(" BiModem-Verbindung kann nicht hergestellt werden");
else if (Erfolg == -2)
PrintS(" PUFFER konnte nicht extrahiert werden");
else if (Erfolg == -3)
PrintS(" CALLED.xxx nicht angekommen");
else if (Erfolg == -4)
PrintS(" Login in Mailbox fehlgeschlagen");
else if (Erfolg == -5)
PrintS(" Anwahl erfolglos");
else if (Erfolg == -6)
PrintS(" Konfigurations-Datei fehlerhaft");
else if (Erfolg == -7)
PrintS(" Carrier beim Upload verloren");
else if (Erfolg == -8)
PrintS(" Uebertragung beim Upload abgebrochen");
else if (Erfolg == -9)
PrintS(" Carrier beim Download verloren");
else if (Erfolg == -10)
PrintS(" Uebertragung beim Download abgebrochen");
else if (Erfolg == -11)
PrintS(" BiModem hat Carrier verloren");
else if (Erfolg == -12)
PrintS(" veraenderte BiModem-Version auf der anderen Seite");
else if (Erfolg == -13)
PrintS(" CTS ausgeschaltet");
else if (Erfolg == -14)
PrintS(" zu viele Fehler waehrend BiModem-Uebertragung");
else if (Erfolg == -20)
PrintS(" Text-Anzeige-Programm nicht gefunden");
else if (Erfolg == -21)
PrintS(" (Telix-)Editor nicht gefunden");
else if (Erfolg == -22)
PrintS(" PUFFER im angegebenen Verzeichnis nicht gefunden");
else if (Erfolg == -23)
PrintS(" PUFFER bis zum Ende gelesen");
else if (Erfolg == -24)
PrintS(" PUFFER-Bearbeitung beendet");
}
PrintS(); // Leerzeile
} // end of Main()
------------------------------- schnapp -----------------------------------
Die Protokoll-Datei (capture-file) bekommt ihren Namen automatisch
zugewiesen. Er besteht aus dem aktuellen Datum in der Form JJMMTT sowie der
'BiPoint' als Parameter 'Ext' uebergebenen Endung. Auf diese Weise laesst
sich mit einem Blick ins Inhaltsverzeichnis leicht das Wann und Wo der
einzelnen fehlgeschlagenen Anrufe erkennen.
Die Protokoll-Datei eines Anrufs in der Oekoline-Box am 2. Nov. 1990 wuerde
dann bspw. heissen: '901102.OLN'. Bei einem fehlerlos abgewickelten Netcall
wird diese Protokoll-Datei allerdings am Programmende automatisch
geloescht, so dass im Normalfall keine Dateien 'uebrigbleiben'.
_________________________________ <:-) ___________________________________
Die Konfigurations-Datei:
-------------------------
Aus der Konfigurations-Datei 'BiPoint.CNF', die in Ihrem Telix-Upload-
Verzeichnis liegt, werden die folgenden Angaben eingelesen:
1. Name Ihres Points
2. die Extension des verwendten Komprimierungs-Programms (i.d.R.
"ARC");
3. Suchpfad und Name des Komprimierungs-Programm (i.d.R. "PKARC");
4. die Komprimierungs-Parameter (i.d.R. "-oc -u");
5. das Verzeichnis, AUS dem die 'PUFFER'-Datei kommt;
6. Suchpfad und Name des Dekomprimierungs-Programm (i.d.R. "PKXARC");
7. die Dekomprimierungs-Parameter (i.d.R. "-r");
8. das Verzeichnis, IN das die 'PUFFER'-Datei kommt;
9. der Suchpfad und Name des BiModem-Programmes; hier muss in jedem
Fall ein gueltiger Dateiname stehen: Wenn Sie also nicht mit BiModem
arbeiten wollen oder koennen, so tragen Sie hier z.B. den Suchpfad
und Namen Ihres Kommandoprozessors ein (i.d.R. "C:\COMMAND.COM");
10. die Zahl der gewuenschten Anwahl-Versuche bei Ihrer Server-Box;
steht hier eine 0 (Null), so wird 'endlos' angewaehlt;
11. Suchpfad und Name des Textanzeige-Programms (i.d.R. "LIST");
12. Suchpfad und Name des Binaerdatei-Anzeigeprogramms (i.d.R. "FV");
_
Alle Zeilen, die entweder leer sind oder mit einem Semikolon (';')
beginnen, werden als Kommentare angesehen und ignoriert. Sie koennen also
beliebige Bemerkungen in die Konfigurations-Datei schreiben. Fuehrende
Leerzeichen werden ebenfalls ignoriert. Lediglich die korrekte Reihenfolge
der genannten Angaben muss sichergestellt sein.
Ihre Datei 'BiPoint.CNF' koennte demnach etwa so aussehen:
------------------------------ schnipp ------------------------------------
; Konfigurations-Datei zum Telix-BiPoint-Script
; fuer Point-Netcalls in Zerberus-Boxen
; ---------------------------------------------
MY_POINT
; 1. Der Name Ihres Points
; ------------------------
ARC
; 2. die Extension des Quetschers
; -------------------------------
Q:\PkArc
; 3. Pfad und Name des Quetschers
; -------------------------------
-oc -u
; 4. Parameter zum Quetschen
; --------------------------
\Point
; 5. da kommt der PUFFER her
; --------------------------
Q:\PkXArc
; 6. Pfad und Name des Entquetschers
; ----------------------------------
-r
; 7. Parameter zum Dekomprimieren
; -------------------------------
\Point
; 8. da soll der neue PUFFER hin
; ------------------------------
\DFUe\BiModem
; 9. Pfad und Name des externen BiModem-Protokolls
; ------------------------------------------------
0
; 10. Anzahl der Waehlversuche (0 = unendlich)
; --------------------------------------------
U:\List
; 11. Textanzeige-Programm
; ------------------------
U:\FV
; 12. Binaerdatei-Anzeigeprogramm
; -------------------------------
------------------------------ schnapp ------------------------------------
_________________________________ <:-) ___________________________________
Die beiden wichtigsten Protokolle:
----------------------------------
Das ZModem Datenuebertragungs-Protokoll sorgt fuer zuverlaessige Datei- und
Befehls-Uebertragung mit vollstaendiger END-TO-END Daten-Integritaet
zwischen verschiedenen Anwendungsprogrammen. ZModem's 32-Bit-CRC schuetzt
auch vor den Fehlern sog. "error free" Modems und solchen, die selbst in
den weitest entwickelten Netzen auftreten. Es sichert alle Daten und
Ueberwachungs-Information mit einer effektiven Fehlererkennung. Seine
Datenfluss-Behandlung eliminiert Verzoegerungen, wie sie durch die
Datenblock-Behandlung von Kermit/XModem/YModem/JModem entstehen. Dabei
verzichtet es auf die klassischen Kompromisse zwischen Uebertragungs-
Effizienz und Fehler-Korrektur der XModem/YModem/JModem-Paketlaengen.
ZModem's Paketlaenge ist die gesamte Datei.
Benutzer-Freundlichkeit ist ein wichtiges ZModem-Feature. Der
AutoDownload(tm) (automatischer Datei-Download, initiiert ohne Eingriff des
Anwenders) vereinfacht, verglichen mit traditionellen Protokollen, den
Datei-Transfer betraechtlich.
BiModem(tm) ist ein neues Kommunikations-Protokoll, das es gestattet,
GLEICHZEITIG in beiden Richtungen Daten zu uebertragen. BiModem kann Daten
versenden (Upload) waehrend es zugleich empfaengt (Download). Stellen Sie
sich die zeitlichen Einsparungen vor, wenn Sie mit der Leistungs-
faehigkeit von Zmodem(tm)- und YmodemG Ihre Daten versenden koennen,
waehrend Sie zur gleichen Zeit und mit derselben Leistungsfaehigkeit andere
Daten empfangen. Zudem koennen Sie sich waehrend der Datenuebertragung auch
noch mit dem/der Sysop Ihrer Mailbox via Bildschirm unterhalten (Chat) ...
Aehnlich wie ZModem, benoetigt auch BiModem keine weiteren Eingaben, um
sowohl Up- als auch Download selbsttaetig abzuwickeln. Wenn Sie sich als
BiModem-Anwender haben registrieren lassen, koennen Sie zudem u.a. noch
waehrend der Uebertragung (!) weitere Dateien zum Up- oder Download
angeben.
_________________________________ <:-) ___________________________________
Interna:
--------
Zur Orientierung hier die Prozedur-Koepfe der einzelnen Scripts sowie
(leicht gekuerzt mit freundl. Genehmigung von BRIAN_O'FISH@MULI.ZER) als
Hintergrund-Information einige Hinweise zum eigentlichen Netcall.
'BiCheck.SLC':
Main(Str Konfig_Datei, Str Pointname,
Str UpFile, Str DownFile,
Str BiMoDirPrg, Str BiPointLog, Str CmdLine,
Str DeKompriPrg, Str DeKompParm,
Int AnwahlVersuche,
Str TextViewer, Str BinViewer)
'BiPoint.SLC':
Main(Str Tel_Nr, Str Extension, Str Pass_Name, Str Protokoll)
'BiView.SLC':
Main(Str ZielVerzeichnis, Str Version, Str Pointname,
Str TextViewer, Str BinViewer)
Der Zerberus-Netcall:
---------------------
Zuerst wird die Verbindung zwischen den beiden Systemen auf irgendeine Art
und Weise hergestellt (zum Beispiel ueber Modem).
Nach erfolgtem Connect laeuft aus Sicht des Anrufers folgendes ab:
a) Die andere Seite sendet den Mailbox-Begruessungsbildschirm. Dieser
kann durch wiederholtes Senden von Ctrl-X abgebrochen werden.
b) Die Mailbox sendet als Prompt den String "Username:". Nun sollte der
Anrufer den String "ZERBERUS", gefolgt von CR/LF, senden.
c) Wenn b) funktioniert hat und die Mailbox das "ZERBERUS" verstanden
hat, sendet sie den String "Systemname:", andernfalls vermutet sie
wahrscheinlich einen normalen Usernamen, sie sollten in dem Fall
einige CR/LF - Paare senden, damit die Verbindung sich wieder
synchronisiert, und bei b) weitermachen. Wenn "Systemname:"
empfangen wurde, sollte der Anrufer seinen System- (oder
Terminal-/Point-) Namen senden, in Grossschrift und wiederum mit
CR/LF beendet.
d) War dies nicht erfolgreich, geht's wieder zu b), ansonsten sendet
die Mailbox "Passwort:". Nun wird das vereinbarte Netzpasswort
gesendet, ebenfalls in Grossschrift und durch CR/LF beendet.
e) Wenn die Passworteingabe fehlgeschlagen ist, wird entweder wieder
bei b) weitergemacht, oder die andere Seite sendet bei zuvielen
Fehlversuchen den String "Netzzugriff verweigert" und legt auf.
Wurde das Passwort korrekt erkannt, sendet die Mailbox erst einmal
mehrere Zeilen, die den String "running ARC" enthalten. Sie ist nun
die Daten fuer Sie am vorbereiten, was einige Zeit in Anspruch
nehmen kann (Sie sollten an dieser Stelle ruhig sichergehen und mit
einem Timeout von 10 Minuten arbeiten).
f) Ist der Partner fertig mit Arcen, so sendet er ein einzelnes
NAK-Zeichen (Ascii Hex 15, Dezimal 21) und erwartet nun Ihre
Seriennummer. Diese Seriennummer besteht im Prinzip aus fuenf
Zeichen, wobei das fuenfte die Summe der ersten vier ist (modulo
256), also (in C): char s[5]; s[4] = (char)(((int) s[0] + (int) s[1]
+ (int)s[2] + (int)s[3]) & 0xFF); Was Sie als Seriennummer nehmen,
ist im Prinzip egal, Sie koennen zum Bleistift der Einfachkeit
halber fuenf mal ein Nullbyte senden. Wenn die Seriennummer korrekt
erkannt wurde, sendet die Gegenseite ein ACK (Ascii 6), wenn nicht,
wieder ein NAK. Sollte die Seriennummer mehrmals nicht erkannt
werden, legt die Gegenseite auf.
g) Ist der Seriennummerncheck erfolgreich gelaufen (ACK empfangen),
beginnt umgehend der eigentliche Netztransfer:
Beim Netztransfer wird immer in je einer Richtung ein File gesendet.
Bei Unidirektionalem Transfer (Xmodem, Zmodem) sendet zuerst der
Anrufer, dann der Angerufene.
Bei Bidirektionalem Transfer (Bimodem) werden beide Dateien
gleichzeitig versandt.
Der Anrufer sendet eine Datei namens CALLER, der Angerufene eine
Namens CALLED. Es muss damit gerechnet werden, dass moeglicherweise
der Dateiname der zu empfangenden Datei ein anderer als der
erwartete ist.
Die Datei ist ein Archiv, gepackt mit ARC (bei manchen Systemen ist
eventuell auch ZIP, ZOO oder LHARC als Archivformat moeglich). Die
oben angesprochenen Dateien CALLER und CALLED sollten als Extension
die jeweilige Arcer-Extension tragen.
Im Archiv befindet sich eine Datei namens PUFFER und sonst nix.
Diese Datei ist das eigentliche Netcallfile (Format s.u.).
Wenn ein Partner nichts zu versenden hat, sollte er entweder eine
Datei senden, die nur aus einem CR/LF-Paar besteht, oder aber ein
Archiv, das ein PUFFER-File mit CR/LF enthaelt, beide Formen sollten
erwartet werden.
h) Direkt nach dem Versand der beiden Files wird die Verbindung
getrennt.
Format des Netcallfiles (PUFFER)
--------------------------------
Die PUFFER-Datei enthaelt nacheinander ohne Luecke alle Nachrichten, die
versandt werden sollen.
Eine Nachricht besteht dabei aus Kopf und Message.
Der Kopf enthaelt 8 Zeilen, die jeweils durch CR/LF beendet werden.
Ein Kopf sieht folgendermassen aus:
----------- Start o'Kopf ------------
<Empfaenger>
<Betreff>
<Absender>
<Datum>
<Pfad>
<MsgId>
<Typ>
<Laenge>
----------- End o'Kopf --------------
Die einzelnen Felder haben folgende Bedeutung:
<Empfaenger> :
Eine Zeichenkette ohne Leerzeichen und in Grossschrift. Maximallaenge:
40 Zeichen (hmm, unsicher, vielleicht mehr) Es gibt drei moegliche
Erscheinungsformen:
<Username>
Empfaenger ist ein User, der in der Mailbox eingetragen ist, die das
Netcallfile erhalten wird. Username darf keinen Klammeraffen (@)
enthalten. Beispiel: BRIAN_O'FISH
<Brettname>
Empfaenger ist ein Brett in der Box, die das Netcallfile erhalten wird.
Damit die Nachricht ankommen kann, muss das Brett dort natuerlich
vorhanden sein. Beispiel: /T-NETZ/BESCHEUERT
<Username>@<Systemname>.ZER
Empfaenger ist der User <Username> im Netzsystem <Systemname> Beispiel:
WOLFGANG@SOLARIS.ZER
Es ist wichtig, dass fuer Nachrichten an User im Serversystem der
Systemname NICHT im Empfaengerteil auftaucht, also die erste
Erscheinungsform genommen wird !
<Betreff>
Der Nachrichtentitel. Eine beliebige Zeichenkette mit einer
Maximallaenge von 40 Zeichen (wieder geschaetzt...)
<Absender>
Der Absender der Nachricht. Eine Zeichenkette ohne Leerzeichen und in
Grossschrift. Maximallaenge sind wiederum 40 Zeichen. Der Absender
sollte immer die Form <eigener_username>@<eigener_systemname>.ZER haben.
Bei einem Terminal (Point) sollte der Pointname fuer den eigenen
Systemnamen eingesetzt werden, das Serversystem wird das Feld
entsprechend anpassen.
<Datum>
Das Erstellungsdatum der Nachricht. Eine Zeichenkette nur aus Ziffern
mit exakt 10 Zeichen Laenge ohne Leerzeichen dazwischen.
Format: jjmmtthhmm
jj = Jahr (00-99, gezaehlt seit 1900, ich weiss, 2000 ist nicht :-)
mm = Monat (01-12)
tt = Tag im Monat (01-31)
hh = Stunde (00-23)
mm = Minute (00-59)
Es ist SEHR wichtig, dass das Format dieses Feldes stimmt, insbesondere
die Laenge, da es sonst zu grossen Problemen auf dem Netz kommen kann.
<Pfad>
Der Nachrichtenpfad, den die Nachricht bereits gelaufen ist. Eine
Zeichenkette ohne Leerzeichen, Maximallaenge 80 Zeichen, wenn es mehr
werden, sollte abgeschnitten werden !
Format: <System1>!<System2>![...]!<unser_System>
Die Systemnamen sind jeweils OHNE die Endung .ZER zu schreiben. Das
eigene System wird immer am Ende angehaengt (umgekehrt wie bei UUCP!).
Usernamen sollten im Pfad nicht auftauchen! Wird eine Nachricht neu
generiert, sollte der Pfad leergelassen werden (Leerzeile, keine
Blanks!), der Server wird sich dann als erstes System eintragen.
<MsgId>
Dies ist eine eindeutige Kennung der Nachricht. Der Theorie nach sollte
sie NETZWEIT NIEMALS doppelt vorkommen. Eine Zeichenkette ohne
Leerzeichen mit maximal 20 Zeichen (sehr wichtig!). Das
"Standard"-Format ist folgendes: <xx>.<yyyyy>@<unser_System> wobei xx
eine zweistellige Zufallszahl und yyyyy ein bei jeder Nachricht
erhoehter Zaehler ist. Beispiel: 08.15@MIDGET
<Typ>
Der Nachrichtentyp, gibt die Weiterverarbeitung der Nachricht an. Ein
einzelnes Zeichen, und zwar:
T fuer Textnachrichten
B fuer Binaernachrichten
Alle anderen Zeichen fuehren bei Zerberus- und Kompatiblen Systemen zu
erheblichen Problemen, also bitte keine eigenen Formate definieren,
sonst koennen Sie ihr Netcallfile gleich loeschen (Einlesen wird an der
Stelle mit Fehler abgebrochen).
Das Format von Binaerdateien ist frei, bei Textdateien sollten Sie
darauf achten (mit Ihrer Software bei der Erstellung der Message
sicherstellen), dass Zeilen mit CR/LF beendet werden und moeglichst
IBM-Umlaute verwenden (wenn ueberhaupt).
<Laenge>
Die Laenge der Message (der eigentlichen Nachricht) in Bytes. Wichtig
bei empfangenen Netcallfiles: Vor der Zahl kann ein Leerzeichen stehen!
Nach den Vorgaben von Zerberus sollte UNBEDINGT beachtet werden, dass
persoenliche Netzmails, also Mails mit dem Empfaengerformat
<Username>@<Systemname>.ZER, nicht laenger als 4000 Zeichen werden.
Andernfalls kann ihnen dreierlei passieren:
- Die Nachricht verschwindet im Nirwana
- Die Nachricht wird weitergeroutet. In diesem Fall machen Sie sich
SEHR unbeliebt bei vielen Leuten
- Die Nachricht wird korrekt als Eilmail versand (ich weiss nicht, ob
das in irgendeiner Implementation bereits korrekt gehandhabt wird).
Am Wahrscheinlichsten ist dabei das erste Verhalten (Nirwana), aber
ziehen Sie daraus nicht den Schluss, dass sie das nicht beachten
sollten!
Bei Brettnachrichten sollte auch die Laengenbeschraenkung beachtet
werden, hier ist sie aber Sache des Serversysops, so dass wenn
ueberhaupt diese Einstellung parametrisiert werden sollte.
Beispiel eines Kopfes:
----------- Start o'Kopf ------------
/T-NETZ/BESCHEUERT
Info: Das Zerberus-Netcallformat
BRIAN_O'FISH@MIDGET.ZER
9009071123
08.15@MIDGET
T
4223
----------- End o'Kopf --------------
Nach dem Kopf kommt dann im Netcallfile direkt die Message (beginnend mit
dem ersten Byte nach dem CR/LF der <Laenge>-Zeile. Die Message ist genau
<Laenge> Bytes gross, danach folgt sofort im naechsten Byte der naechste
Kopf.
_________________________________ <:-) ___________________________________
Die 'BiPoint'-Quelltexte:
-------------------------
Von einigen NutzerInnen kam die Bitte, ihnen den Source-Code fuer eigene
Modifikationen zur Verfuegung zu stellen. Diesen Wunsch koennen wir leider
nicht nachkommen: Zum einen ist das Programm-Paket derzeit schon rund 112
KByte (ca. 3.300 Zeilen) gross, was vermutlich ziemlich viel Arbeit
bedeuten wuerde, es zu verstehen und zu veraendern. Zum zweiten arbeiten
wir noch immer daran (z.B. soll auch das Herstellen der
Zerberus-PUFFER-Datei ins Script integriert werden), und wir moechten
vermeiden, dass von dem Programm voneinander unabhaengig und
unterschiedlich modifizierte Varianten entstehen; neue Versionen werden von
uns erst freigegeben, wenn sie im 'Echtbetrieb' ausfuehrlich getestet
wurden. - Wir hoffen, Sie koennen diese Gruende verstehen, zumal sie nicht
zuletzt auch der Sicherheit im Netz dienen sollen. - Im Uebrigen koennen
Sie anhand der 'History' (in 'BiPoint.NEW') sehen, dass wir bemueht sind,
auf Anregungen moeglichst schnell zu reagieren.
_________________________________ <:-) ___________________________________
Credits:
--------
BiModem v1.24
-------------
Copyright (C) 1989 by ERIK LABS
Erik Labs, 3431 W. Thunderbird Rd., Suite 13-311, Phoenix, AZ 85023
(602)942-5403 Voice, (602) 866 9229 Data (2400)
_________________________________________________________________________
FV v1.33 - Verbose Archive Directory Lister
-------------------------------------------
(c) Copyright by Vernon D. Buerg 1989-90. ALL RIGHTS RESERVED.
_________________________________________________________________________
LIST v7.5b
---------- Copyright (C) 1983-1990 by Vernon D. Buerg
139 White Oak Circle, Petaluma, CA 94952
Data: (707) 778-8944 VOR 24-hour bulletin board
- or - (707) 778-8841 MB 24-hour bulletin board
Compuserve: 70007,1212
_________________________________________________________________________
MsgPrep v1.30
------------- Copyright (C) Marc Zimmermann, 1989-1990.
Marc Zimmermann, Hochstrasse 167, 6600 Saarbruecken 5, Tel.: 0681-791993
_________________________________________________________________________
'maps v1.13
----------- (c) 1990 brian o'fish, muli lab's
Patrick Schaaf, Alter Stadtweg 69, D-6607 Dudweiler/Saar,
Tel.: 06897 763816
_________________________________________________________________________
Telix v3.12
----------- Copyright (C) 1986 - 1989 by Exis Inc.
EXIS Inc., Post Office Box 130, West Hill, ON, Canada M1E 4R4
(416)-289-4641 voice, (416)-289-4645 FAX, (416)-439-8293 BBS
_________________________________________________________________________
Zerberus(r)
----------- Copyright (C) 1987 - 1990 by H.Schroeder & W.Mexner
_________________________________________________________________________
Einen herzlichen Dank an Udo Schacht-Wiegand (SYSOP@OLN.ZER) fuer seine
Geduld und Unterstuetzung bei der Entwicklung und dem Testen der Software.
_________________________________________________________________________
BiPoint v3.47
_____________ Copyright (C) 1989, 90 DFG/M.Watermann, D-3000 Hannover 1
Hinweise & Anregungen
sind immer willkommen. Sie koennen Ihre Mitteilungen richten an
(e-mail:)
Zerberus : M.WATERMANN@OLN.ZER
FidoNet : Matthias Watermann of 2:247/205.9751
(snail-mail:)
Die Freie Gesellschaft
Verlagsbuchhandlung M. Watermann
Richard-Wagner-Str. 27, D-3000 Hannover 1
_________________________________________________________________
BiPoint