AMMS steht für Amiga Multiuser Mailbox System. Eine Mailbox, wie Bulletin Board Systeme (BBS) im deutschsprachigen Raum genannt werden, ist ein i.d.R. privat betriebenes Rechnersystem, welches man per Datenfernübertragung zum Datentausch, aber auch zur allgemeinen Kommunikation nutzt. In den späten 80er und 90er Jahren war dies sehr beliebt und kann als Vorläufer des Internet angesehen werden. Auch der Amiga Computer spielte hier natürlich eine große Rolle – nicht nur als anrufender Teilnehmer, sondern auch als Host für die BBS.
Ein in Deutschland sehr beliebtes Mailbox-System war AMMS, welches nicht, wie bei anderen Systemen üblich das Programm mehrfach in den Speicher des Host-Computers lud, sondern lediglich ein Hauptprogramm startete. Die einzelnen benötigten Ports (i.d.R. waren diese mit seriellen Schnittstellen und daran angeschlossenen Modems verknüpft) konnten nach belieben gestartet und beendet werden.
Funktionen & Aufbau von AMMS
AMMS Statusdisplay Zeigt die Port-Übersicht von AMMS auf dem Host-Computer.
AMMS ist in seiner Struktur dem AmigaOS und modernen Computersystemen ähnlich. Es basiert auf Libraries, die nahezu alle Funktionen integrieren. Das Hauptprogramm „MB“ lädt beim Start alle dauerhaft im Speicher stehenden Daten und bietet eine Oberfläche, über die alle Ports kontrolliert werden können. Die Ports fungieren als Schnittstellen zwischen dem Benutzer und dem System. Jeder Benutzer verfügt über einen eigenen Ordner, in dem persönliche Daten gespeichert werden. Neue Benutzer stellen über einen Befehl einen Antrag zur Aufnahme in die Community und erhalten einen sofortigen Zugang zur Mailbox, allerdings mit stark eingeschränkten Nutzungsrechten. Erst nach einer (meist redaktionellen) Überprüfung des Benutzers werden weitergehende Zugriffsrechte gewährt.
AMMS verfügt grundsätzlich über eine interaktive Befehlsoberfläche ähnlich einer Shell, es ist jedoch möglich und üblich, ein menüorientiertes System zu erstellen. Menüs mit Hotkeys und anderen Features sind dabei problemlos integrierbar. Alle Verwaltungsaufgaben können auch remote durchgeführt werden. Darüber hinaus ermöglicht AMMS eine portübergreifende Kommunikation, bei der ein Benutzer mit administrativen Zugriffsrechten einem anderen Benutzer z.B. zuschauen oder auch Eingaben für ihn tätigen kann.
AMMS enthält neben verschiedenen Chatsystemen auch modular erweiterbare Nachrichten-Bretter (vergleichbar mit heutigen Foren), Filebretter für den Up- und Download von Dateien, ein Postfach für jeden Benutzer (für Privatnachrichten und E-Mails) sowie Kurznachrichtensysteme (ähnlich SMS oder Messenger). Öffentliche Nachrichten-Bretter wurden früher regelmäßig in einer Art Ringnetz zwischen den Mailboxen ausgetauscht, was eine Kommunikation über die Grenzen einzelner Mailboxen hinweg ermöglichte.
Systemanforderungen
Das Hauptprogramm von AMMS belegt ca. 800kByte (bei 200 Usern und 400 Protokolleinträgen). Die Ports belegen ca. 300kByte. Eine kleine Mailbox mit einem (Modem-) Port und einer lokalen Console läuft bereits auf einem Amiga mit 68000-Prozessor und 2MB RAM. Eine 20-Port-Box (1000 User, 2000 Protokolleinträge) läuft bereits ab 8MB Fastram.
AMMS (Amiga Multiuser Mailbox System)
ist ein Multiuser-Mailbox-System, worin
gleichzeitg mehrere User arbeiten koennen. Dabei wird nicht, wie bei anderen
Systemen ueblich, das Programm mehrfach in den Hauptspeicher eingeladen,
sondern ein Serverprogramm (MBSERVER) wird am Anfang gestartet. Die einzelnen
Ports werden ueber den Befehl PORT hochgefahren. Dabei koennen die Ports in
beliebiger Reihenfolge hoch- bzw. runtergefahren werden.
Ports koennen Consolen, serielle, Arexx-, Link- oder andere Schnittstellen
sein. Momentan existeren nur Ports fuer Batch-Ports, xemlib-Consolen
(z.B. VT102) und serielle Schnittstellen, die in fast beliebiger Anzahl
gestartet werden koennen. Die Anzahl ist momentan auf 30 Ports begrenzt,
eine Erhoehung kann bei Bedarf eingebaut werden.
Das Programm MBSTAT liefert einen Screen, der alle Ports anzeigt und womit
der Sysop Usern zuschauen kann.
Grundsaetzliche Daten ueber das AMMS :
- SPEICHERVERBRAUCH Das Serverprogramm belegt mit den residenten Befehlen und Sysop-Monitor
ca. 850 KByte (bei 200 Usern und 400 Protokolleintraegen), wobei sich
dieser Speicherbedarf mit der maximalen Useranzahl, der Protokollgroesse
und der Anzahl der residenten Befehle veraendern kann.
Die Ports belegen ca. 200 KByte, wobei Consolen ca. 50 KByte mehr belegen.
Die ausfuehrbaren Befehle (mbcom:) sollten aus Geschwindigkeitsgruenden
in einer RAM-Disk stehen und verbrauchen dann zusaetzlich ca. 420 KByte.
Eine kleine Mailbox mit einem Port und einer Consolen sollte daher nicht
auf einem Rechner mit weniger als 2.0 MByte laufen.
Der Speicheraufwand ist bei einer hoeheren Portanzahl vergleichweise
gering, weil AMMS nicht mehrfach das Hauptprogramm in den Speicher laedt.
Eine 20-Port-Box (1000 User/ 2000 Protokolleintraege) laeuft schon ab
8 MByte Fastram. - LIBRARIES Das AMMS basiert auf Libraries, die fast alle Funktionen enthalten.
Diese Libraries koordinieren alle Multiuser-Funktionen und stellen ueber
500 Funktionen zur Verfuegung. Diese Libraries haben die Endung .mblib
und stehen im Verzeichnis amms/libs. - MBSERVER Das Serverprogramm MBSERVER laedt beim Start alle staendig im Speicher
stehenden Daten bzw. alle residenten Befehle nach. Es ist das eigentliche
Hauptprogramm, welches alle Ports kontrolliert. - MBSTAT Dieses Programm dient als Oberflaeche fuer den Sysop und zeigt alle
Aktivitaeten auf den Ports an. Es bietet die Moeglichkeit, den Usern
zuzuschauen (VT100 ueber xem-Libs) und bei ihnen einzugreifen. - PORT Das Programm PORT erlaubt das Starten von beliebigen Ports. Diese Ports
sind die eigentlichen Schnittstellen zwischen User und System.
Sie koennen einzeln hoch- bzw. runtergefahren werden. Ebenso koennen ihre
Settings mit Hilfe des Befehls EDIT PORT modifiziert werden. - KILLPORT Das Programm KILLPORT erlaubt das runterfahren von gestarteten Ports.
- BEFEHLSVERARBEITUNG ALLGEMEIN Alle Befehle, die der Benutzer in der Befehlsebene oder in Batchdateien
nutzen kann, sind nicht fest im Programm implementiert, sondern werden von
Disk nachgeladen. Damit ergibt sich eine Modularisierung, die ein Erweitern
des Systems schnell und einfach ermoeglicht.
Es gibt zwei Arten von Befehlen, die ausfuehrbaren Befehle (mbcom:, mbres:)
und die Batchbefehle (mbbatch:com/).
Um die Geschwindigkeit des Systems zu erhoehen, sind einige ausfuehrbare
Befehle (mbres:) resident. Sie werden beim Starten des Systems nachgeladen
und stehen staendig im Speicher. Ausfuehrbare Befehle sind in Assembler geschrieben und benutzen ausschliess-
lich die Funktionen der AMMS-Libraries. Zusaetzlich koennen Programme, die
in einer Hochsprache geschrieben sind, aufgerufen werden. Diese koennen
allerdings nur ueber eine Interface-Routine alle Library-Funktionen des AMMS
benutzen, weil die Library-Funktionen fuer Assemblerprogramme ausgelegt sind. Batchbefehle sind ASCII-Files, worin alle Befehle des Systems aufgerufen
werden keonnen, damit stellt das AMMS einen Interpreter zur Verfuegung.
In Batchbefehlen koennen Variablen deklariert und Labels definiert werden,
Sprungbefehle und Abfragen ermoeglichen einen Ablauf von allen Algorithmen. - MBCOM: In diesem Verzeichnis stehen alle ausfuehrbaren nicht residenten Befehle,
die unter AMMS ausgefuehrt werden koennen. Sie werden beim Aufruf von
AMMS nachgeladen und ausgefuehrt.
In den Unterverzeichnissen DEUTSCH/ und ENGLISH/ stehen die Befehltextfiles,
worin alle Texte der Befehle definiert sind. Eine Aenderung dieser Texte
sind ueber die ASCII-Texte MBTEXT:DEUTSCH/COM/… bzw. MBTEXT:ENGLISH/COM/…
moeglich. Da die Befehlstexte kein ASCII sind, muss der Konverter CVT bzw.
CVTALL die ASCII-Texte in Befehlstexte konvertieren. - MBRES: In diesem Verzeichnis stehen alle ausfuehrbaren residenten Befehle, die
beim Start des Systems nachgeladen werden. Fuer Aenderung der Befehlstexte
siehe MBCOM:, bloss statt MBCOM: steht dann MBRES: in den Pfadnamen. - MBBATCH: In diesem Verzeichnis stehen alle Dos und AMMS-Skripte, die unter AMMS
ausgefuehrt werden koennen. - MBBATCH:COM/ In diesem Verzeichnis stehen alle AMMS-Befehle, die ein Skript sind.
Solche Befehle enthalten AMMS-Befehle und koennen ohne grosse Kenntnis
selber programmiert werden.
Da auch diese Befehle Texte beinhalten, existieren die Unterverzeichnisse
MBBATCH:COM/DEUTSCH/ und MBBATCH:COM/ENGLISH/, worin alle sprachspezifischen
Daten gespeichert sind. Diese Dateien haben die Endung .BAT, wenn sie
selber eine Skript-Datei sind, und eine Endung .TXT, wenn es sich um
einen ASCII-Text handelt, der so angezeigt wird. - MBBATCH:LOGIN Beim Einloggen in einem Port wird die Batchdatei MBBATCH:LOGIN, die fuer
die Einlog-Sequenz sorgt, unter dem User LOGIN gestartet. Diese Datei ist
beliebig aenderbar und muss den Befehl LOGIN enthalten, ueber den sich die
User einloggen. Endet die Datei unter dem User LOGIN, so legt der Port
automatisch auf. - MBUDIR: Alle User besitzen ein User-Directory (MBUDIR:/), worin persoenliche
Daten gespeichert werden. Unter anderem steht dort die Batchdatei LOGIN, wo
sich der User seine eigene Einlog-Sequenz definieren kann. Diese Datei wird
aus der Einlog-Batchdatei MBBATCH:LOGIN mit Hilfe des Befehl EXECUTE BATCH
gestartet. In dieser Datei steht nun der Aufruf zum Menu oder andere Befehle,
die beim Einloggen userspezifisch ausgefuehrt werden sollen. - APPLICATION Neue User stellen ueber den Befehl APPLICATION einen Antrag. Dieser Antrag
fuehrt zum sofortigen Eintrag des Users im System. Dabei erhaelt der neue
User fast alle Zugriffe und Einstellungen des Systemusers NEWUSER.
Ebenso wird das komplette User-Directory des Users NEWUSER dem neuen User
als Vorgabe kopiert. Damit steht den Sysop die Moeglichkeit frei, den neuen
Usern auch die Login-Datei vorzudefinieren (EDIT BATCH NEWUSER).
Der neue User kann sich sofort nach dem Antrag unter seinem Namen im System
einloggen. - EDIT USER Der Editor, um Daten des Users zu aendern. Die Zugriffe der Bretter und
Filebretter koennen ueber EDIT ACCESS/EDIT FACCESS und EDIT BOARD/EDIT FBOARD
genau eingestellt werden.
Wird ein User ueber den Befehl EDIT USER eingetragen, so werden keine Daten
als Voreinstellung uebernommen. Diese muss man expliziet mit Hilfe des
Befehls von einem anderen User kopieren oder per Hand einstellen.
Ebenso wird nur das User-Directory ohne Inhalt erzeugt (bis auf das Directory
pmsgs). Daher ist der Eintrag von Usern ueber den Befehl EDIT USER abzuraten. - MENU AMMS besitzt grundsaetzlich nur eine interaktive Befehlsoberflaeche. Aber
durch die Batchbefehle ist es moeglich, ein menueorientiertes System
als komfortable Applikation ueber diese Befehlsoberfaeche zu legen.
Dabei sind Menues mit Hotkeys und anderen Spielereien kein Problem.
AMMS liefert ein einfachen Menue standardmaessig mit. - VERWALTUNG Alle Verwaltungsaufgaben koennen nur ueber Ports ausfuehrt werden.
Somit kann das System sowohl vollstaendig vor Ort als auch aus der
Ferne gewartet werden, was gerade bei groesseren Boxen sehr wichtig ist,
weil ein Sysop nicht mehr in der Lage ist, alle Aufgaben zu uebernehmen.
Die Verwaltungsbefehle sind alle sehr komfortabel, wir haben deshalb auf
eine zusaetzliche Verwaltung verzichtet. - ZUGRIFFE AMMS besitzt 10000 Level (0-9999) und 16 Zugriffsbits (0123456789abcdef),
die fuer jeden Befehl und User vergeben koennen. Hat ein User den gleichen
oder einen hoeheren Level, so hat er Zugriff auf den entsprechenden Befehl.
Hat er unabhaengig vom Level ein Zugriffsbit gesetzt, den auch ein Befehl
besitzt, so hat der User ebenfalls Zugriff auf den Befehl. Dabei reicht
schon ein gesetzes Bit um Zugriff zu bekommen, auch wenn der Befehl mehrere
gesetzt hat.
Damit man nicht gleich vollen Zugriff auf die Befehl erlangt, gibt es zwei
Stufen, den Userbereich mit Userlevel und Userzugriffsbits und den Sysop-
bereich mit Sysoplevel und Sysopzugriffsbits.
Da Befehl noch max. 6 Optionen besitzen, kann auch noch fuer jede einzelne
Option ein Level und Zugriffsbits festgelegt werden.
Typischerweise haben User mit Level 2000 normalen Userzugriff, User ab Level
9000 Sysopzugriff. Das Zugriffsbit 6 ist fuer den Zugriff auf priviligierte
Befehle vorgesehen und darf keinem User vergeben werden.
Das Zugriffsbit 7 ist fuer Netzuser vorgesehen, die damit auf bestimmte
Skripte Zugriff erhalten. Diese Bit darf demnach auch keinem normalen User
vergeben werden. - GROESSTER ZUGRIFF Sysops mit dem Level 9999 haben grundsaetzlich auf alles Zugriff.
Ihnen koennen keine Befehle oder Daten vorenthalten bleiben.
Brettverwalter muessen keine Sysops sein, sie brauchen nur Zugriff auf die
Befehle, die mit der Brettverwaltung zu tun haben. Somit kann jeder User
Brettverwalter werden, ohne ein Risiko fuer das System darzustellen. - PORTUEBERGREIFENDE KOMMUNKTION AMMS bietet die portuebergreifende Kommunikation. Man kann einen anderen
User mit Hilfe des Befehls MONITOR zuschauen und Eingaben taetigen.
Diese Funktion bietet auch das Programm MBSTAT, wo der Sysop ohne
eingeloggt zu sein, einem User zuschauen kann.
Der Befehl FORCE erlaubt es, einen String als Eingabe auf einen anderen Port
zu schicken.
Der Befehl MESSAGE ermoeglicht es, eine Nachricht einen anderem Port auf
den Bildschirm zu schicken.
Damit sich User komfortabel unterhalten koennen, bietet das AMMS zwei
Chat-Systeme. Ein Fullscreenchat (FCHAT) und ein Zeilenchat (XCHAT).
Fuer den Zeilenchat existiert inzwischen auch ein Chatlink, der es
ermoeglicht, dass mehrere Mailboxen gleichzeitig den Zeilenchat benutzen
koennen und somit einen grossen Chatverbund bilden. Ebenso hat ein Sysop
ein Programm geschrieben, das die Verbindung zum IRC ermoeglicht. - MESSAGE/MAIL/FILE-SYSTEME Das Message-, PM- und Filesystem sind fest im AMMS eingebaut.
Hinweise zum Message, PM- und File-System stehen weiter unten im Text.
Genauere Informationen stehen in den Dokumentationen @{„Message-System“ link amms:dok/msg.guide/main},
@{„File-System“ link amms:dok/file.guide/main}, @{„Netzwerke“ link amms:dok/Netzwerke.guide/main} und @{„Fastnet-Format“ link amms:dok/fastnet.guide/main}. - ONLINE-NACHRICHTEN AMMS bietet neben dem PM-System auch ein ONLINE-Message-System.
Online-Messages sind kurze Texte, die sich die User gegenseitig schicken
koennen. Dabei verschickt am Anfang ein User eine Online-Message mit dem
Befehl PMSG.
Befindet sich der Zieluser im System, so wird ihm die Nachricht angezeigt,
sobald er sich in der Befehlsebene oder im Menue aufhaelt. Er antwortet
sofort ohne den Befehl PMSG extra aufzurufen.
Befindet sich der User gerade nicht im System, so wird die Nachricht im
User-Directory (MBUDIR:/PMSGS/) gespeichert und beim naechsten
Login angezeigt. - MESSAGE-SYSTEM Das Message-System kann max. 20000 Bretter mit jeweils max. 10000 Nachrichten
verwalten. Zusaetzlich wird noch fuer jeden User ein Privatfach verwaltet.
Fuer eine ordentliche Organisation der Bretter koennen max. 12000
Verzeichnisse angelegt werden. Die Namen von Brettern und Verzeichnissen
duerfen max. 30 Zeichen lang und identisch sein. Das Message-System verwaltet jedes Brett einzeln, dabei werden wegen einer
hoeheren Zugriffsgeschwindigkeit die Bretter wie folgt auf Disk abgelegt : MBMSG:// Beispiele: MBMSG:0-63/0/D0
MBMSG:64-127/127/MSGTAB Die Datenfiles enthalten jeweils max. 100 Nachrichten mit folgenden Aufbau : … Der Header ist dynamisch im Fastnet-Format aufgebaut, darf max. 32768 Bytes
lang sein und wird optional gepackt.
Die Nachricht ist in x Teile zerstueckelt, wobei ein Teil max. 32762 Bytes
lang sein darf, alle Teile stehen direkt hintereinander und werden optional
gepackt. Das Zerstueckeln ermoeglich das Verwalten von beliebig langen
Nachrichten mit einem Buffer von 32768 Bytes.
Die Nachrichten stehen sortiert hintereinander im Datenfile Das File MSGTAB ist ein Indexfile, das die wichtigesten Informationen jeder
Nachricht enthaelt. Es enthaelt auch die max. Nachrichtenanzahl und weitere
Informationen. Das File CRCTAB dient nur fuer den Netzverkehr, es ordnet jeder Nachricht
eine CRC32-SUMME zu. Die CRC32-Summe stammt von der MID und dient zur
Dupe-Erkennung. Damit der User nicht immer alle Bretter angezeigt bekommt, besitzt er eine
Brettliste, in der er die Bretter, die er lesen moechte, eintraegt.
Diese Brettliste wird vom Befehl NN, READ und RN benutzt, um die neusten
Nachrichten aus den gewuenschten Brettern anzuzeigen.
Ebenso wird diese Brettliste von den ZConnect- und Fastnet-Points benutzt. Alle User sind mit ihrem Eintrag sofort ein ZCONNECT-Point (inc. MAPS).
Das kann deshalb so realisiert werden, da fuer die User-Points kein
zusaetzlicher Speicher benoetigt wird. Die Nachrichten werden beim Pointen
online aus den Brettern exportiert und gepackt.
Optional kann man sich aber die Daten vorpacken lassen, das gerade fuer
Benutzer der Fernzone sehr interessant ist. Damit die schon gelesenen Nachrichten nicht nochmal als Neu angezeigt werden,
wird fuer jedes Brett die hoechste Nachrichtennummer der schon gelesenen
gespeichert. Dabei fuehren die Nachrichten eine fortlaufende Nummer mit sich,
die genau die zeitliche Reihenfolge der Speicherung der Nachricht darstellt. Weitere Informationen zum Message-System stehen im @(„Message-Guide“ link amms:dok/msg.guide}. - PM-SYSTEM Das PM-System entspricht einem Brett des Message-Systems, nur stehen die
Datenfiles im Verzeichnis „PMS/“ im Userverzeichnis „mbudir:/“ Der normale User sollte nur Platz fuer 50 PMs bekommen, weil sonst eine
sehr hohe Plattenkapazitaet notwendig ist, weil viele User ihre alten
Nachrichten aus Traegheit oder Unwissenheit nicht loeschen.
Die max. PM-Anzahl kann mit OPTIMIZE MAIL oder EDIT USER geaendert werden. Mit den Befehlen MAIL und SEND koennen PMs gelesen und versendet werden. Alle PMs, die an ALL geschickt werden, werden in das Brett :SYSTEM/PMALL
gespeichert. Auf dieses Brett darf kein User LESE- oder SCHREIB-Zugriff
(—-) haben, da sonst PMs an ALL nicht korrekt importiert werden koennten.
Das PM-System schaut beim Aufruf des Befehls MAIL nach, ob neue PMs an ALL
existieren. Wenn ja, dann werden die neuen PMs importiert. Die Abfrage, ob
eine PM neu oder alt ist, verlaeuft wie beim RN-Befehl ueber die hoechste
gelesene Nachrichtennummer. Sollte diese Nachrichtennummer beim Brett PMALL
fuer alle User zurueckgesetzt werden, so werden alle PMs an ALL nochmal neu
importiert.
Will ein Sysop eine PM an ALL loeschen, so muss er mit Hilfe des NN-Befehls
das Brett :SYSTEM/PMALL anwaehlen und die entsprechende PM loeschen. - FILE-SYSTEM Das File-System kann max. 20000 Bretter mit jeweils max. 2000 Files
verwalten. Es entspricht von der Verwaltung her dem Message-System, die
Verwaltungsbefehle unterscheiden sich bloss im Namen (FBoard statt Board).
Standardmaessig werden neue Bretter mit identischen AMMS-Namen in FILES:
angelegt, ein anderer logischer Pfad kann aber bei MAKE FBOARD angegeben
werden. Ein identischer AMMS-Name sieht wie folgt aus :AMMS AMIGA-DOS:FILES/AMIGA/VIREN -> FILES:FILES/AMIGA/VIREN Der Befehl FILES zeigt brettweise die Files in einem sehr komfortablen
File-Requester an. Dabei koennen die Files mit Hilfe der Cursortasten
angewaehlt und viele Funktionen auf sie angewendet werden (z.B. Archiv
anschauen, Archiv ueberpruefen, Textfile anschauen, Bild ueber die Console
anschauen, File loeschen, File downloaden usw.).
Mit ueber 50 Funktionen und mehreren selbst definierbaren Funktionen ist
der Files-Befehl ein sehr maechtiges Instrument. Alle Files koennen zum Download markiert werden, wobei die Markierungen
nicht beim Verlassen des Systems verloren gehen. Sie werden im User-Directory
unter dem Namen „DOWNTAB.DAT“ abgespeichert. Der Batchdownload ist wie der
Batchupload brettweise oder brettuebergreifend moeglich. Damit der User Filebretter selektieren kann, besitzt er wie beim Messagesystem
eine Filebrettliste. In diese Liste traegt der User alle Bretter ein, die
er angezeigt bekommen moechte.
Mit dem Befehl FN (FILES/NEW) werden nur die neuen Files der Bretter aus der
Filebrettliste angezeigt. Mit dem Befehl FILES werden alle Files der Bretter
aus der Filebrettliste angezeigt. Damit die schon angezeigten Files nicht nochmal als neue Files angezeigt
werden, wird fuer jedes Brett die hoechste Filenummer der schon angezeigten
Files gespeichert. Dabei fuehren die Files eine fortlaufende Nummer mit sich,
die genau die zeitliche Reihenfolge der Importierung der Files in das Brett
angibt. Weitere Informationen zum File-System stehen im @(„File-Guide“ link amms:dok/file.guide}
und im Helpfile des Befehls FILES (HELP FILES). - FILE-PM-SYSTEM Das File-PM-System basiert auf dem Filesystem.
Dabei wird die Moeglichkeit des Versendens privater Files in einem Brett
genutzt. Das Filebrett :SYSTEM/PRIVAT wird zum Privatfilebrett ernannt.
Wird ein Privatfile gesendet, so muss mind. ein Zieluser angegeben werden.
Nur die Sysops, der Sender und die Zieluser haben Download- und
Loesch-Zugriff auf das File. Fuer die anderen User existiert das File nicht. Alle User, die Privatfiles versenden duerfen, muessen Upload-, Download- und
Loeschzugriff (-UDE) auf das Filebrett :FILES/PRIVAT/PRIVAT haben. Der Batchbefehl FMAIL schaut nach, ob ein Privatfile vorliegt und geht
gegebenenfalls in den FILES-Befehl (entspricht vergleichbar dem MAIL).
Mit Hilfe des SMAIL-Befehls kommt man immer in das Privatfilebrett und
kann Privatfiles uploaden (entspricht vergleichbar dem SEND).
Die User koennen das Brett auch in ihre Filebrettliste aufnehmen oder direkt
anwaehlen. - DISK TOOL Sollte die Filebrettanzahl nicht reichen oder CDs eingebunden werden, so
kann auf den Befehl DISK TOOL zurueckgegriffen werden.
Er ist aehnlich dem Befehl Files aufgebaut und ist fuer die Einbindung
von CDs sehr geeignet.
Genauere Informationen stehen im Hilfstext zum Befehl DISK TOOL
(AMMS> help disk tool). - VERWALTUNG DER FILE- BZW. MESSAGEBRETTER Die Verwaltung der File- und Msgbretter ist nach dem gleichen Prinzip
aufgebaut: Die Zugriffe S=Sysop, R=Read, W=Write und D=eigene Message loeschen oder
aendern bzw. S=Sysop, D=Download, U=Upload und E=eigenes File loeschen oder
Files anschauen werden fuer jedes Brett fuer jeden einzelnen User bestimmt.
Dafuer existeren die Befehle EDIT BOARD bzw. EDIT FBOARD, womit alle Zugriffe
der User auf ein Brett gesetzt werden und EDIT ACCESS bzw. EDIT FACCESS,
womit alle Zugriffe eines Users auf alle Bretter gesetzt werden. Zusaetzlich zu der Vergabe von Rechten gibt es noch ein Brettsysop, der alle
Rechte auf sein Brett besitzt. Dieser wird beim Erzeugen des Bretts
(MAKE BOARD bzw. MAKE FBOARD) angegeben und kann durch die Befehle INFO BOARD
und INFO FBOARD angezeigt werden. Er ist der eigentliche Verwalter des Bretts
und sollte fuer den reibungslosen Betrieb verantwortlich sein.
Neben dem Brettsysop koennen noch andere User den Sysop-Zugriff bekommen.
Diese User haben fast die gleichen Moeglichkeiten wie der Brettsysop bei
der Verwaltung des Bretts. - AUTOMATISCHES EINTRAGEN NEUER USER UND DEREN ZUGRIFFE Wenn sich ein neuer User mit Hilfe des APPLICATION-Befehls eintraegt, so
werden alle Brettzugriffe und alle anderen Userdaten, die Zugriffe bestimmen,
vom Systemuser NEWUSER als Vorgabe kopiert. Somit ist der neue User mit
den Zugriffen des User NEWUSER im System eingetragen.
Ebenso bekommt er das komplette User-Directory des Users NEWUSER kopiert.
Er kann sich sofort nach dem Antrag unter seinem Usernamen einloggen.
Der Eintragsvorgang wird im Textfile MBDAT:ANTRAEGE.DAT mitprotokolliert
und kann ueber den Befehl SHOW APPLICATIONS angeschaut werden.
Ist die maximale Useranzahl im System erreicht, so kann sich kein neuer User
eintragen. - VEREINFACHTES VERWALTEN VON ZUGRIFFEN UEBER SPEZIELLE SYSTEMUSER Wie schon beim Message-System erwaehnt, kann fuer jeden User der Zugriffs-
modus in jedem Brett einzeln bestimmt werden. Diese Verwaltung laesst alle
Moeglichkeiten der Zugriffsvergabe zu, ist aber bei Levelorientieren
Zugriffsvergaben sehr arbeitsintensiv, wenn der Sysop fuer jeden User
einzeln die Zugriffe setzen muss.
Deshalb kann diese Art von Zugriffsvergabe wesenlich vereinfacht werden,
indem man Systemuser einrichtet, die die entsprechenden Zugriffe fuer einen
Level beinhalten. Soll nun ein User einen hoeheren Level und damit auch mehr
Zugriffe bekommen, so geht man in den Befehl EDIT USER und waehlt den User an.
In der obersten Zeile, wo man zwischen ENDE und SPEICHERN UND ENDE waehlen
kann, gibt es auch noch die Moeglichkeit EINSTELLUNGEN VON ANDEREM USER HOLEN.
Wenn man diesen Punkt anwaehlt und Return drueckt, muss ein Username angegeben
werden. Dieser Username muss nun der Systemuser sein, der die entsprechenden
Zugriffe fuer den User enthaelt. Nun werden alle Brettzugriffe und Zugriffe vom
Systemuser zum User kopiert, und wenn man nun die Userdaten vom User speichert,
hat der User nun den Zugriff, die der Sysop dem Level zugeordnet hat.
Ein Systemuser ist ein normaler User mit dem Schutz-Flag y (sYstemuser).
Die Flags fuer Protokoll, Status und Login sperren und Systemuser werden
beim Kopiervorgang nicht mitkopiert. - VERWALTEN DER ZUGRIFFE DER BEFEHLE Befehle sind die Schnittstelle zwischen User und Betriebsystem des AMMS.
Da man fast alles mit den Befehlen des AMMS tun kann, darf nicht jeder User
auf alle Befehle Zugriff haben. Dazu existiert eine etwas komplizierte,
aber sehr maechtige Befehlsverwaltung. Alle User besitzen einen Level von 0 – 9999 und 16 Zugriffsbits.
Der Level dient der eigentlichen Zugriffsvergabe, aber ueber die 16 Zugriffs-
bits koennen User zeitweise Rechte auf hoeher priviligierte Befehle bekommen
ohne den entsprechenden Mindestlevel zu besitzen. Befehle haben folgende Level zur Zugriffsvergabe zur Verfuegung : Userlevel = Mindestlevel, damit User Zugriff auf Befehl bekommt
Sysoplevel = Mindestlevel, damit User Sysopzugriff auf Befehl bekommt
Batchlevel = Der User bekommt innerhalb eines Batchbefehls diesen Level
zugeordnet, wenn sein eigener Level kleiner ist. Hiermit
kann einem User innerhalb eines Batchbefehls vorruebergehend
ein hoeherer Level gegeben werden, damit er definierten
Zugriff auf priviligierte Befehle bekommt.
Beispiel :
Der Befehl INFO SYSTEM benoetigt zur Anzeige des Platten-
speichers den DOS-Befehl INFO. Dieser ist aber nur ueber den
Befehl EXTERN zu erreichen, der ueber einen Handler voll-
staendigen Amiga-Dos-Zugriff bietet. Innerhalb des Batch-
befehls kann nun dem User definierten Zugriff auf solch
einen Befehl gegeben werden. Befehle haben folgende Zugriffsbitreihen zur Verfuegung : Useracc= Wenn der User mindestens ein Zugriffsbit besitzt, das in dieser
Bitreihe gesetzt ist, so hat er Zugriff auf den Befehl, auch wenn
er einen zu niedrigen Level besitzt. Sysopacc= Wenn der User mindestens ein Zugriffsbit besitzt, das in dieser
Bitreihe gesetzt ist, so hat er Sysopzugriff auf den Befehl, auch
wenn er einen zu niedrigen Level besitzt. Batchacc= Der User bekommt innerhalb eines Batchbefehls die Zugriffbits
zugeordnet. Dabei behaelt er alle seine schon vorhandenen Zugriffs-
bits und kann somit nur mehr Bits erhalten. Wie beim Batchlevel hat
es den Sinn, einem User kurzzeitig mehr Zugriffsrechte zu geben als
er eigentlich besitzt.
Beispiel:
Im Menu muessen staendig Texte von Disk geladen werden. Diese Texte
koennen aber nur durch hoeher priviligierte Befehle oder Befehls-
funktionen geladen werden, weil die Angabe eines Filenamens noetig
ist. Damit der User dennoch definierten Zugriff darauf bekommt,
wird ein Bit (in den vorgegebenen Menues Bit 6) gesetzt, das der
User normalerweise nicht besitzt. Dieses Bit ist ebenfalls bei den
entsprechenden Befehlen bzw. Befehlsfunktionen im Useracc gesetzt.
Somit hat der User innerhalb des Menues auf Befehle Zugriff, die
er normalerweise nicht benutzen kann. Durch ein geschicktes Spiel aus Level und Zugriffbits koennen sehr einfach
zusaetzliche Befehle erstellt und ein komplexes Menuesystem aufgebaut werden. - BEFEHLSAUFRUFE Es gibt grundsaetzlich zwei Arten von Befehlen. Befehle mit einem Befehlswort
(z.B. Dir und CD) und Befehle mit zwei Befehlsworten (z.B. Show Command und
Show User), wobei die Befehlsworte mit mindestens einem Space getrennt sein
muessen. Alle Befehlsnamen koennen abgekuerzt werden. Die Abkuerzungen
bestimmt derjenige, der ein Befehl mit Hilfe des Befehls EDIT COMMAND/ADD
eintraegt. Der User muss mindestens soviele Buchstaben eingeben, wie der
Befehlsname am Anfang Grossbuchstaben besitzt. Dies gilt fuer jedes Befehls-
wort. Damit nicht versehentlich Befehle eingetragen werden, die die gleiche
Abkuerzung besitzen, wird beim Eintragen die Abkuerzung auf Eindeutigkeit im
System ueberprueft. Damit ein Befehl mehrere Aufgaben uebernehmen kann, gibt es Optionen.
Diese Optionen muessen direkt hinter dem letzten Befehlswort stehen und
beginnen immer mit einem Slash (/). Die Optionen werden ohne Slash im
Befehl EDIT COMMAND eingetragen, und ihnen ist ebenfalls ein Zugriffslevel
und eine Zugriffsbitreihe zugeordnet, so dass der Zugriff auf Optionen
genau definiert werden kann.
Auch Optionen koennen nach dem gleichen Prinzip, wie bei den Befehlsworten,
abgekuerzt werden. Die maximale Optionsanzahl ist auf 6 beschraenkt.
Batchbefehle koennen auch Optionen auswerten, in den Variablen O1 bis O6 bzw.
OS fuer Sysopzugiff steht entweder ein „T“ fuer Option gesetzt oder ein „F“
fuer Option nicht gesetzt. Diese Variablen koennen in den Batchbefehlen unter
anderem mit Hilfe des IF-Befehls ausgewertet werden.
Damit ein Befehl von alleine eine Option benutzt, gibt es fuer jede Option
ein Flag, das definiert, ob die Option beim Start an oder aus ist.
Die Benutzung einer Option bewirkt ein Invertieren dieses akt. Status an/aus. Zu allen Befehlen steht ein Hilfstext zur Verfuegung, der ihre Funktion
und die Funktionen der Optionen erklaert (HELP ).