Next Previous Contents

20. FAQ - Oftgestellte Fragen

F: Ist ein Umstieg von FBB/DieBox/MSYS auf BayCom möglich?

A: Für FBB und MSYS gibt es keine Utilities zum Konvertieren der Datenbestände. Hier ist es am Besten die Daten über ein Kabel von der ``alten'' Box auf die ``neue'' Box zu forwarden, falls das die ``alte'' Software zuläßt. Für DieBox gibt es sowohl eine Software zum Konvertieren der Mails als auch eine Möglichkeit zu Übernahme der Benutzerdaten:

F: Bei der DOS-Version wird nach einigen Minuten der Monitor dunkel - ist etwas defekt?

A: Nein, das ist der Bildschirmschoner, er kann mit dem Befehl crtsave 0 abgeschaltet werden.

F: Bei der Mailbox DB0XYZ läuft schon eine neue Version, woher kann ich diese Version bekommen?

A: Neue Versionen werden in das Board BAYBOX mit dem Verteiler BAYCOM eingespielt. Sollte die neue Version noch nicht dort zu finden sein, so handelt es sich um eine Beta-Version, also um eine Testversion, welche bei einigen wenigen Boxen gestestet wird, bevor sie verteilt wird. Event. lohnt sich auch ein Blick nach http://www.baycom.org/baybox

F: Wenn ein Run-Utility Bulletins löscht, so werden Fernerase-Mails erzeugt. Kann ich etwas dagegen tun?

A: Ja, mit einem Trick: Die Mails nicht löschen, sondern deren Lifetime auf #0 setzen. So werden die Bulletins genauso wie bei ERASE unsichtbar und beim nächsten Purge gelöscht.

F: Warum wird nach dem Hochstarten einer Box mehr freier Speicher beim Befehl VERSION dargestellt als wenn die Box eine Weile läuft (DOS)?

A: Die Speicherverwaltung der BayCom-Mailbox nutzt die malloc() und free() Aufrufe der C-Laufzeitbibliothek. Diese verwaltet den Speicher jeweils zu Blockgrössen, wie sie angefordert wurde. D.h. wenn zuerst ein sehr großer Block angefordert wird und dann ein sehr kleiner, und dann der große Block wieder freigegeben wird, entsteht eine Lücke. Der angezeigte freie Speicher ist aber stets nur der größte, zusammenhängende Block, und nicht die Summe aller ``Schnipsel''. Bleibt eine Lücke frei, so kann diese bei der nächsten Anforderung wieder genutzt werden, weil die Verwaltung stets nach dem ersten freien Block sucht, in den der angeforderte Block hineinpasst. Dabei entsteht natürlich ein Verschnitt, weil viele der angeforderten Blöcke eine unterschiedliche Größe haben. So erklärt sich, warum der angezeigte freie Speicher mit der Zeit immer weniger wird: Der Speicher wird immer mehr fragmentiert. Wird ein Block allerdings wieder freigegeben und sind in der Nachbarschaft ebenfalls freie Blöcke, so werden diese wieder zusammengefügt und es entsteht wieder durchgehender, freier Speicher. Der Vorgang der Fragmentierung setzt sich deshalb nicht fort, sondern pegelt sich auf einen durchschnittlichen Wert ein, der dann auf Dauer im Schnitt erhalten bleibt. Manche Blöcke bleiben allerdings sehr lange belegt (z.B. Sprachen, CONVNAME.BCM, FWD.BCM und solche Listen), weshalb auch der freie Speicher lange unverändert zu sein scheint. Üblich ist, daß gegenüber dem maximal möglich verfügbaren Speicher nach dem Hochstarten etwa 30-50 kB abgehen. Dies ist vor allem beim Start von externen DOS-Programmen lästig, da für diese nur durchgehend freier Speicher nutzbar ist.

F: Untersucht man die Datei BCM.EXE, kommen Befehlswörter und Meldungen zutage, die keine oder eine unbekannte Wirkung haben. Was hat es damit auf sich und warum sind diese nicht dokumentiert?

A: Es gibt in den Quellen zur Box viele Baustellen, an denen irgendeine Funktion angedacht war aber nie realisiert wurde, oder die Teile werden auch zu anderen Zwecken verwendet und erfüllen ihre Funktionalität in der Box nur teilweise. In jedem Fall sollten nur die Funktionen als vorhanden gewertet werden, die auch dokumentiert sind. Da beim Erstellen der Boxsoftware eine relativ penible Versionsverwaltung betrieben wird und alle Erweiterungen automatisch in die Änderungslisten einfliessen, gibt es kaum undokumentierte Funktionen, die nicht bewusst undokumentiert geblieben sind.

F: Im Syslog tauchen immer wieder völlig unverständliche Meldungen auf. Wie ist zu unterscheiden, welche Meldungen wirklich wichtig sind und was ignoriert werden kann, ggf. welche Gegenmaßnahmen notwendig werden.

A: Das ist ein sehr wunder Punkt. Zum einen ist klar, daß eine Dokumentation eigentlich dringend nötig wäre, zum anderen gibt es aber so furchtbar viele Meldungen (ca. 400 verschiedne), die potentiell kommen können, daß es ein gewaltiger Aufwand wäre sie alle zu dokumentieren. Prinzipiell kann gesagt werden, daß die Kategorie ``#L'' meist völlig harmlos ist, ``#S'' ist je nach Laune des Entwicklers entweder schlimm oder nicht, hingegen ``#F'' und ``#A'' sind stets höchst unangenehm und führen grundsätzlich dazu, daß das gewünschte Ergebnis nicht erzielbar ist. Eine Liste oft vorkommender Meldungen wird baldmöglichst nachgereicht.

F: Eingegebe Nachrichten werden sehr schnell an andere Boxen weitergegeben. Dies nimmt die Möglichkeit, nochmals über den Inhalt einer abgeschickten Nachricht nachzudenken und diese ggf. noch vor Weitergabe zu löschen.

A: Die unverzügliche Weitergabe von Nachrichten zu den Nachbarboxen war war ein wichtiges Kriterium bei der Entwicklung der BayCom-Mailbox. Eine Nachricht sollte stets so schnell wie möglich am Ziel ankommen, sofern dies die Linkstrecken ermöglichen. Es ist deshalb nicht vorgesehen und im momentanen Design auch gar nicht ohne weiteres machbar, Nachrichten verzögert loszusenden. Eine Lösung für Kurzentschlossene ist, vor Abschluß der Nachricht deren Inhalt nochmals zu prüfen und diese ggf. durch CTRL-X zu verwerfen und somit gar nicht erst abzuschicken.

F: Unter ALTER REJECT wäre es wünschenswert, mehr Begriffe anzugeben als in die momentan verfügbare 80-Zeichen-Zeile passen.

A: Dieser vielfach geäusserte Wunsch ist angekommen, ist jedoch nur mit sehr viel Ungemach zu verwirklichen. In der derzeitigen User-Struktur sind dafür nur 80 Zeichen vorgesehen und ein Umorganisieren dieser Struktur würde einen enormen Aufwand für alle Boxbetreiber beim Update bedeuten. Es wäre zum einen sehr viel freier Plattenplatz (ca. 100 MB) erforderlich, zum anderen wäre ein Zurückrüsten auf alte Versionen nicht mehr möglich. Ausserdem würde das reorganisieren der Daten vor dem Update ca. 1 Stunde die Box lahmlegen. Bei der Vielzahl der laufenden Boxen lohnt es sich durchaus, für einen solchen Schritt mehrere Änderungen auf einmal zusammenzufassen und erst dann eine solche Umorganisation durchzuführen.

F: Es war einmal eine 32 Bit-DOS-Version der BayCom-Mailbox angedacht und wurde auch angekündigt. Was ist daraus geworden?

A: Es gibt eine 32 Bit-DPMI-Version von BCM.EXE. Diese hat sehr viel Mühe bei der Portierung bereitet, da viele unter DOS mögliche Zugriffe im protected mode ganz anders sind, erst recht wenn diese von einem 32 Bit-Programm aus erfolgen. Auf den ersten Blick sieht dann alles auch ganz gut aus, man kann frei Speicher adressieren, es existiert eine virtuelle Speicherverwaltung, die sehr großzügige Speicherugriffe ermöglicht. Außerdem entfällt die modulweise Segmentierung, was den Code angenehm übersichtlich macht. Es hat sich jedoch gezeigt, daß auch ganz krasse Nachteile entstehen, die das Projekt letztlich dann nach dessen Fertigstellung zu Fall gebracht haben:

Obige Argumente machen klar, warum das Projekt nach näheren Tests zu den Akten gelegt wurde. Schade um die Arbeit und die dadurch entstandenen Kosten. Speziell bei letzterem ist ein besonderer Dank an DL6FBS zu richten, der hier den wesentlichen Teil übernommen hat.

In der Zwischenzeit gibt es eine Version der BayCom-Mailbox für Windows NT.

F: In der PS-Liste stehen oft nicht nur eingegebene Kommandos, sondern auch Symbole, die offenbar vom Programm generiert werden. Was bedeuten diese?

A: Beim Forwarding werden hier normalerweise die übertragenen Mails bzw. die ausgetauschen Kommandos dargestellt. Wird gerade keine Mail gesendet oder empfangen, so ist im Kommandoteil der PS-Liste der Zustand der Forward-Routine zu entnehmen. Das bedeutet im einzelnen:

fwd_loop

Die Forward-Hauptschleife wurde aufgerufen

fwd_send

Die Forward-Schleife verzweigt demnächst zu einem SEND-Befehl

fwd_delay

Es wurden Nachrichten gesendet und es wird abgewartet, ob noch eine Mail für den Partner eintrifft bevor die Verbindung beendet wird

fwd_rec

Die Forward-Maschine erwartet ein Kommando vom Partner

fwd_pro

Es wurde ein Prompt gesendet

fwd_connect

Ein Connect-Befehl wurde abgesetzt, Verbindung wird erwartet

fwd_connected

Die AX.25-Verbindung ist gelungen

wait_for_sid

Ein Forward-Partner wurde connected, und es wird nun die SID des Partners erwartet

wait_pr1

Es wird der erste Prompt nach dem Login erwartet

wait_pr2

Es wird der zweite Prompt nach dem Senden der SID erwartet

rx_wait_sid

Ein Forward-Connect wurde entgegengenommen und die eigene SID gesendet; es wird nun die SID des Partners erwartet

F: Was bedeutet ``NO - BID'' beim Forward?

A: Das ist kein Fehler (also kein BID-Mangel o.ä.), sondern zeigt an, daß die angebotene Bulletin bereits lokal vorhanden ist und deshalb vom Partner nicht geschickt werden soll.


Next Previous Contents