AMMS steht f\u00fcr 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\u00fcbertragung zum Datentausch, aber auch zur allgemeinen Kommunikation nutzt. In den sp\u00e4ten 80er und 90er Jahren war dies sehr beliebt und kann als Vorl\u00e4ufer des Internet angesehen werden. Auch der Amiga Computer spielte hier nat\u00fcrlich eine gro\u00dfe Rolle \u2013 nicht nur als anrufender Teilnehmer, sondern auch als Host f\u00fcr die BBS.<\/p>\n\n\n\n
Ein in Deutschland sehr beliebtes Mailbox-System war AMMS, welches nicht, wie bei anderen Systemen \u00fcblich das Programm mehrfach in den Speicher des Host-Computers lud, sondern lediglich ein Hauptprogramm startete. Die einzelnen ben\u00f6tigten Ports (i.d.R. waren diese mit seriellen Schnittstellen und daran angeschlossenen Modems verkn\u00fcpft) konnten nach belieben gestartet und beendet werden.<\/p>\n\n\n\n
AMMS Statusdisplay<\/strong> Zeigt die Port-\u00dcbersicht von AMMS auf dem Host-Computer.<\/p>\n\n\n\n AMMS ist in seiner Struktur dem AmigaOS und modernen Computersystemen \u00e4hnlich. Es basiert auf Libraries, die nahezu alle Funktionen integrieren. Das Hauptprogramm „MB“ l\u00e4dt beim Start alle dauerhaft im Speicher stehenden Daten und bietet eine Oberfl\u00e4che, \u00fcber die alle Ports kontrolliert werden k\u00f6nnen. Die Ports fungieren als Schnittstellen zwischen dem Benutzer und dem System. Jeder Benutzer verf\u00fcgt \u00fcber einen eigenen Ordner, in dem pers\u00f6nliche Daten gespeichert werden. Neue Benutzer stellen \u00fcber einen Befehl einen Antrag zur Aufnahme in die Community und erhalten einen sofortigen Zugang zur Mailbox, allerdings mit stark eingeschr\u00e4nkten Nutzungsrechten. Erst nach einer (meist redaktionellen) \u00dcberpr\u00fcfung des Benutzers werden weitergehende Zugriffsrechte gew\u00e4hrt.<\/p>\n\n\n\n AMMS verf\u00fcgt grunds\u00e4tzlich \u00fcber eine interaktive Befehlsoberfl\u00e4che \u00e4hnlich einer Shell, es ist jedoch m\u00f6glich und \u00fcblich, ein men\u00fcorientiertes System zu erstellen. Men\u00fcs mit Hotkeys und anderen Features sind dabei problemlos integrierbar. Alle Verwaltungsaufgaben k\u00f6nnen auch remote durchgef\u00fchrt werden. Dar\u00fcber hinaus erm\u00f6glicht AMMS eine port\u00fcbergreifende Kommunikation, bei der ein Benutzer mit administrativen Zugriffsrechten einem anderen Benutzer z.B. zuschauen oder auch Eingaben f\u00fcr ihn t\u00e4tigen kann.<\/p>\n\n\n\n AMMS enth\u00e4lt neben verschiedenen Chatsystemen auch modular erweiterbare Nachrichten-Bretter (vergleichbar mit heutigen Foren), Filebretter f\u00fcr den Up- und Download von Dateien, ein Postfach f\u00fcr jeden Benutzer (f\u00fcr Privatnachrichten und E-Mails) sowie Kurznachrichtensysteme (\u00e4hnlich SMS oder Messenger). \u00d6ffentliche Nachrichten-Bretter wurden fr\u00fcher regelm\u00e4\u00dfig in einer Art Ringnetz zwischen den Mailboxen ausgetauscht, was eine Kommunikation \u00fcber die Grenzen einzelner Mailboxen hinweg erm\u00f6glichte.<\/p>\n\n\n\n Das Hauptprogramm von AMMS belegt ca. 800kByte (bei 200 Usern und 400 Protokolleintr\u00e4gen). Die Ports belegen ca. 300kByte. Eine kleine Mailbox mit einem (Modem-) Port und einer lokalen Console l\u00e4uft bereits auf einem Amiga mit 68000-Prozessor und 2MB RAM. Eine 20-Port-Box (1000 User, 2000 Protokolleintr\u00e4ge) l\u00e4uft bereits ab 8MB Fastram.<\/p>\n\n\n\n AMMS (Amiga Multiuser Mailbox System)<\/strong><\/p>\n\n\n\n ist ein Multiuser-Mailbox-System, worin AMMS steht f\u00fcr Amiga Multiuser Mailbox System. Eine Mailbox, wie Bulletin Board Systeme (BBS) im…<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-14","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/amms-bbs.de\/index.php\/wp-json\/wp\/v2\/pages\/14","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/amms-bbs.de\/index.php\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/amms-bbs.de\/index.php\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/amms-bbs.de\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/amms-bbs.de\/index.php\/wp-json\/wp\/v2\/comments?post=14"}],"version-history":[{"count":3,"href":"https:\/\/amms-bbs.de\/index.php\/wp-json\/wp\/v2\/pages\/14\/revisions"}],"predecessor-version":[{"id":108,"href":"https:\/\/amms-bbs.de\/index.php\/wp-json\/wp\/v2\/pages\/14\/revisions\/108"}],"wp:attachment":[{"href":"https:\/\/amms-bbs.de\/index.php\/wp-json\/wp\/v2\/media?parent=14"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Systemanforderungen<\/h2>\n\n\n\n
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.<\/p>\n\n\n\nGrundsaetzliche Daten ueber das AMMS :<\/h2>\n\n\n\n
\n
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.<\/li>\n\n\n\n
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.<\/li>\n\n\n\n
stehenden Daten bzw. alle residenten Befehle nach. Es ist das eigentliche
Hauptprogramm, welches alle Ports kontrolliert.<\/li>\n\n\n\n
Aktivitaeten auf den Ports an. Es bietet die Moeglichkeit, den Usern
zuzuschauen (VT100 ueber xem-Libs) und bei ihnen einzugreifen.<\/li>\n\n\n\n
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.<\/li>\n\n\n\n
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.<\/li>\n\n\n\n
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\/\u2026 bzw. MBTEXT:ENGLISH\/COM\/\u2026
moeglich. Da die Befehlstexte kein ASCII sind, muss der Konverter CVT bzw.
CVTALL die ASCII-Texte in Befehlstexte konvertieren.<\/li>\n\n\n\n
beim Start des Systems nachgeladen werden. Fuer Aenderung der Befehlstexte
siehe MBCOM:, bloss statt MBCOM: steht dann MBRES: in den Pfadnamen.<\/li>\n\n\n\n
ausgefuehrt werden koennen.<\/li>\n\n\n\n
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.<\/li>\n\n\n\n
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.<\/li>\n\n\n\n
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.<\/li>\n\n\n\n
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.<\/li>\n\n\n\n
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.<\/li>\n\n\n\n
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.<\/li>\n\n\n\n
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.<\/li>\n\n\n\n
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.<\/li>\n\n\n\n
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.<\/li>\n\n\n\n
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.<\/li>\n\n\n\n
Hinweise zum Message, PM- und File-System stehen weiter unten im Text.
Genauere Informationen stehen in den Dokumentationen @{\u201eMessage-System\u201c link amms:dok\/msg.guide\/main},
@{\u201eFile-System\u201c link amms:dok\/file.guide\/main}, @{\u201eNetzwerke\u201c link amms:dok\/Netzwerke.guide\/main} und @{\u201eFastnet-Format\u201c link amms:dok\/fastnet.guide\/main}.<\/li>\n\n\n\n
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.<\/li>\n\n\n\n
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 : \u2026 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 @(\u201eMessage-Guide\u201c link amms:dok\/msg.guide}.<\/li>\n\n\n\n
Datenfiles im Verzeichnis \u201ePMS\/\u201c im Userverzeichnis \u201embudir:\/\u201c 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
(\u2014-) 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.<\/li>\n\n\n\n
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<\/code> :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 \u201eDOWNTAB.DAT\u201c 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 @(\u201eFile-Guide\u201c link amms:dok\/file.guide}
und im Helpfile des Befehls FILES (HELP FILES).<\/li>\n\n\n\n
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.<\/li>\n\n\n\n
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).<\/li>\n\n\n\n
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.<\/li>\n\n\n\n
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.<\/li>\n\n\n\n
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.<\/li>\n\n\n\n
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 \u2013 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.<\/li>\n\n\n\n
(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 \u201eT\u201c fuer Option gesetzt oder ein \u201eF\u201c
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 ).<\/li>\n<\/ul>\n\n\n","protected":false},"excerpt":{"rendered":"