Das
SysOp-FAQ 0.7
Version 0.7
6. November 1997
von
Christian Goßlar
Telefon 030 - 827 011 44
Binger Str. 80
D-14197 Berlin
MausNet: Christian Goßlar @ B
Dieses ist ein Versuch eines Sysop-FAQs.
Alle Angaben sind aber natürlich ohne Gewähr.
Für Anregungen, Kritik, Zuarbeit bin ich immer zu haben. Also schickt mir Infos zu Fragen die fehlen oder auch komplette Erklärungen.
Bedanken möchte ich mich bei Frithard Meyer-Zu-Uptrup für James, ohne den die Maus nur halb so viel Spaß macht, den anderen SysOps, die mir bei vielen dummen Fragen immer gerne geholfen haben und natürlich bei den Maus-Programmierer Gereon Steffens, Jörg Stattaus und Kai Henningsen für ihre tolle Arbeit. Und auch bei Dirk 'UDO' Hagedorn für das tolle UDO, den das SysOp-FAQ ist
Im Moment sind die folgenden Ausgabeformate verfügbar:
ASCII-Version
Manual-Page-Version
Rich-Version
LaTeX-Version
OS/2-Info-Version
WinHelp-Version
ST-Guide-Version (ATARI)
Pure-C Hilfe (ATARI)
HTML-Versionen
als ein 850kB File
pro Hauptkapitel ein File
für jedes Kapitel ein File (ca. 750 Files)
UDO-Quelltext-Version
Falls noch weitere Ausgabeformat gewünscht werden, die UDO
erzeugen kann aber nicht in der Liste steht, dann bitte bei mir melden.
Wenn jemand mit dem UDO-Quelltext selber ein Ausgabeformat erzeugt und
irgendwo ablegt, so sollte man das irgendwo kennzeichnen (z.B. durch
Änderung der Versionsnummer im Quelltext). Erzeugt wurden diese
Versionen mit UDO6 PL.6.
Diese FAQ ist nur für SysOps des MausNet gedacht. Eine Weitergabe an nicht SysOps ist nicht erlaubt (ich habe keine Lust mir zu überlegen, ob hier irgendwelche relevanten Sachen drin stehen).
Alle Variablen beziehen sich auf die aktuelle Maus-Version. Ob es bei älteren auch immer so ist, weiß ich nicht. Zur Not hilft sicher ein Blick in das Maus-News Kapitel.
Die jeweils aktuelle Version des FAQ liegt auf jedem Fall immer in der Maus B3 (030-82701143) im Gruppen-PT Sysop.Prog.
Alle Rechtschreibfehler © cg.
Fragen und hoffentlich auch die Antworten zu Problemen, die die Maus alleine betreffen.
Hier die Abkürzungen, die im Mcall.Log auftreten können.
ACHTUNG: Die Abkürzungen, die James in seinem Bericht liefert, müssen nicht mit denen hier übereinstimmen. Deshalb immer bei Fragen oder Problemen im Mcall.log nachgucken.
Bad-Tausch | Fehler beim MausTausch-Login (falscher Username oder Passwort) |
BRK | manueller Sysop-Rauswurf |
CHAT | User versuchte zu CHATTEN |
Chat + | Chat vom Sysop beantwortet |
!Chat | User versucht außerhalb der Sprechstunde zu chatten |
cl1 | Carrier Lost 1, tritt jetzt eigentlich nur noch auf. |
cl2 | Carrier Lost 2 (soll es auch geben). Laut einer uralt-Mail von Kai wird dieser gemeldet, wenn der Carrier flattert (1 Sekunde da, 1 Sekunde weg, ...). Stammt noch aus den guten alten Kopplerzeiten. |
DIR | Direktport-login |
del | User hat sich selbst gelöscht. Es wird auch eine Mail an den Sysop erzeugt. |
Extern x | Externes Programm x wurde aufgerufen |
Kommerz | Der Punkt Kommerzielles wurde aufgerufen |
le | Legaler Exit (Maus regulär verlassen) |
listwarn | GastDownload = FALSE und Fileliste gibt ne entsprechende Warnung |
Modem Müll | Ausgabe [Modem-Müll: xyz] bei nicht erkanntem ConnectStringX |
nuop | Upload gesperrt (Gast) |
nu$up | Upload gesperrt (User) |
nodown | Download gesperrt (Gast) |
NoGup | Kein Upload in GPT erlaubt |
noÖdown | kein öffentlicher Download erlaubt |
NoÖup | Kein Upload in ÖPT erlaubt |
NoPup | Upload war nicht erlaubt für diesen Anrufer zu dieser Zeit |
noPdown | Kein Gastupload im persönlichen PT erlaubt |
noTausch | Tausch nicht erlaubt |
no$ | Kein $ für die auszuführende Aktion. Kommt/kam (?) z.B. auch bei entsprechendem Beitragslevel, wenn jemand einen Relogin machen will. |
P- | Zugriff auf Programmteil verweigert |
ProtX- | Protokoll x gesperrt |
TauschOK | Maus nach MausTausch-Login verlassen (sagt nichts darüber aus, ob der Tausch geklappt hat) |
TO | Onlinezeitüberschreitung < 5 min, beim Menüwechsel rausgeworfen |
to | Inaktivitäts-Timeout (2 Minuten nix gemacht) Siehe CharWaitTimeOut |
tos | Timeout Schummelei. Der User wollte sich am Timeout vorbeischummeln, indem er einen Relogin unter seinem eigenen Namen (oder als Gast?) macht |
upSperr | 10 Min vor event keine Uploads mehr |
upwarn | 60 min vor nächstem Event wird der User darauf beim Upload hingewiesen |
Wakeup(1,80) | Modem 1 meldet sich nicht mehr und die Maus versucht es durch diverse Maßnahmen wieder zur mitarbeit zu überreden. |
Wurf | harte Onlinezeitüberschreitung (>5 min), unmittelbar rausgeworfen, egal ob der User in einem Menü, beim Onlinelesen oder sonstwo ist. Zeit über MaxExceed einstellbar |
1.J/N-TO | Inaktivitäts-Timeout beim ersten Ja/Nein |
- | Multitausch durch mehrfachen hintereinander folgenden Tausch zu sehen, ohne neuen Anruf (wird nicht extra markiert). |
Das wird mit GeizhalsNach in Tagen festgelegt. Außerdem kann noch extra festgelegt werden, ob der User tauschen darf (GeizhalsTauschOK), wie groß das Outfile werden darf und auch, das man erst nach X Tagen Geizhals wird.
Das ändern ist ganz einfach. Wenn jemand die Frage "Sind Sie eingetragener Benutzer" mit Nein beantwortet, wird die Datei GASTINFO.INF angezeigt, falls sie existiert. Die Datei muß in InfoPath liegen. Wenn die Datei nicht da ist, werden die Defaulttexte angezeigt.
Dazu einfach eine Datei NEULOGIN.INF in den InfoPath legen. Wenn jemand danach die Frage "Wollen Sie sich jetzt eintragen" mit Ja beantwortet, wird die Datei NEULOGIN.INF angezeigt, falls sie existiert.
Mit dem Programm XENOPHOB von Michael Keukert @ AC2 kann man für bestimmte User das Paßwort automatisch verändern lassen. Das Programm setzt für die angegebenen User ein zufällig gewähltes neues Passwort. Sinnvoll für Gate-User, Daemonen usw. die z.B. Sysop-Status haben.
Mit dem Programm MPWD von von Michael Keukert @ AC2 kann man die User-Paßwörter auf zu kurze oder zu einfache Angaben testen. MistPWD meckert User mit einem individuellen, konfigurierbaren Text an, wenn ihr Passwort nicht gewissen Sicherheits-Mindestanforderungen genügt.
Die Daemon-Einträge kann man aber auch anders sicher machen. Dazu einfach mit einem HEX-Editor in der MUSER.DAT in das Daemon-Paßwort Sonderzeichen einbauen. Die kann man nicht eintippen und somit kann sich auch niemand darunter einloggen.
Von: Sebastian Hempel @ WUN (Di, 05.03.96 23:42)
Servus,
Ein User berichtet mir von folgendem Phänomen.
Ihr Anruf hat 00:43 Minuten gedauert. ^^^^^ Gebühren für diesen Anruf: (Freizeittarif, Anrufdauer: 46 Sekunden) ^^^^^^^^^^^ City R50 R200 Fern 0.12 0.24 0.36 0.36 DM
Woher kommt die Abweichung von 3 Sekunden, die in diesem Fall eine ganze Einheit ausmachen?
Man liest sich
Sepp
Von: Gereon Steffens @ K2 (Sa, 09.03.96 14:13)
RId: 199603052342.a36402@wun.maus.de
MId: 199603091413.a34305@k2.maus.de
>Ihr Anruf hat 00:43 Minuten gedauert.
So lange hat's bis hierhin gedauert...
>(Freizeittarif, Anrufdauer: 46 Sekunden)
Und so lange wird's dauern, bis die MAUS wirklich auflegt. Die
Differenz ergibt sich daraus, daß die MAUS nach der Ausgabe der Daten
ans Modem noch einige Zeit (sprich: DisconnectWait Sekunden) warten muss,
um sicherzugehen, daß die auch zum User übertragen werden.
Gereon
Ja, genauso wie beim Faxempfang kann man auch ein sich auch Anwahlscript bauen, das z.B. als Namen 'super_wichtiger_geheimer_Event' sendet und dann den entsprechenden event auslöst. Siehe auch AutoLogX und AutoEventX
Von: Kai Henningsen @ MS (Fr, 07.01.94 19:10)
Hi Bernhard,
BR> Gips eine Möglichkeit, von der Konsole aus eine
Filebeschreibung
BR> statt einzutippen hochzuladen?
Da werden jetzt bestimmt wieder viele Antworten kommen, aber weil ich
das seinerzeit eingebaut habe, antworte ich trotzdem :-)
Also: seit langer Zeit kann man *überall*, wo die MAUS eine Zeileneingabe erwartet, also insbesondere auch bei den Programmbeschreibungen, der MAUS ein Textfile unterschieben, was dann - solange es reicht - für alle weiteren derartigen Eingaben benutzt wird (NICHT für Menüs!). Das funktioniert, indem man statt dem Text ..p eingibt. Da das Feature ziemlich tief unten in der MAUS liegt, sind die Möglichkeiten stark eingeschränkt; aber von der Tastatur aus kann man wie üblich ein File angeben.
MfG Kai
********************************************************
Nachtrag. Bei meinen Versuchen hat es nicht geklappt. Vielleicht bin ich ja auch nur zu blöd? cg
Muß man als Console-Sysop immer ALT-222 und den Namen eintippen? Geht das nicht einfacher?
Ja. Dazu gibt es die Variablen ConsoleKey.FX Was in diesen Variablen konfiguriert wird, lässt sich bei einem Tastaturanruf in der MAUS per Alt-F5 bis Alt-F8 wieder abrufen. Control-Zeichen können als ^X dargestellt werden. Ein ^ wird durch ^^ erzeugt. Sehr praktisch ist, das #222 ALT-222 emuliert. Einige Beispiele:
ConsoleKey.F5 | 'JFrithard Meyer-Zu-Uptrup^MGeheim^M'; Login |
ConsoleKey.F6 | 'pad-7^M^Ml'; Progliste der letzten 7 Tage |
ConsoleKey.F7 | #222'JChristian Goßlar'; Anstatt ALT-222 usw nur ALT-F8 Der
Eintrag im m7com.cfg sieht dann so aus:
|
ConsoleKey.F8 | #222'JChristian GoßlarJPW'; |
Das gleiche nochmal, nur wird das PW danach geschickt. ACHTUNG , damit kann jeder, der an die Konsole kommt, sich unter dem Namen einloggen. |
Sysop-Menü, Löschen, # und dann den neuen Messagepointer setzen.
Wenn sie ein User neu einträgt, stellt die Maus den Messagepointer nicht auf 1 sondern auf 0. Denn das ist auch Sinnvoll, denn es sollte folgendes gelten:
wenn der Messagepointer auf 1 steht, bekommt man alle Mails, die in den Gruppen, die der User angeschaltet hat, noch in der Maus liegen. Also sehr viele!
wenn der Messagepointer auf 0 steht, dann bekommt man die Mails, die seit gestern eingetroffen sind (Gestern bedeutet, alle Mails die in der E-Zeile das Datum von gestern tragen). Also nicht so viele Mails. Das hat den Vorteil, das man als Neuuser nicht mit einem riesen Berg an Mails zugeschütet wird.
ACHTUNG Der User bekommt natürlich nur Mails für die Gruppen, die er auch angeschaltet hat. Und wenn der User nix anschaltet, sind das halt nur die Gruppen, die in der jeweiligen Maus auf Default oder Pflicht stehen.
MultiTausch ist eine abgewandelte Form des MausTausch-Logins. Der Unterschied ist, daß nach dem Tausch nicht aufgelegt wird, sondern der User online in der Box bleibt und der tausch für den zweiten User ausgeführt werden kann. Statt mit "MausTausch<name>..." loggt man sich dafür einfach mit "MultiTausch<name>..." ein.
Hier mal ein paar Tips zur Maus.Bat. Mit Sicherheit funktionieren die nur unter Plain-DOS. Bei OS/2 funktioniert auf jeden Fall der Tip mit dem exit nicht.
Als ersten errorlevel unbedingt den höchsten Wert eintragen, der nicht mehr benutzt wird. Meisten ist das 80. Ein höherer Wert geht IHMO auch nicht, da dann langsam die Fehlercodes von DOS beginnen.
ein 'exit' in der ersten Zeile verhindert, das man die Maus ausversehen aus der DOS-Shell der Maus nochmal starten kann. Natürlich darf kein exit Programm existieren
Man kann auch das ganze mit einer Kontrolldatei verfeinern:
Von Harald Krusekamp
Ich lege mit der maus.bat eine Kontrolldatei an, die beim Verlassen des
batches gelöscht wird (und sicherheitshalber auch in der autoexec.bat
;-) maus.bat überprüft, ob die Kontrolldatei da ist und falls ja,
wird m7com.exe nicht gestartet. Also etwa am Anfang der maus.bat (bitte vor
:again ;-):
if exist c:\maus\maus.akt echo Maus zweimal starten? Nö ;-) if exist c:\maus\maus.akt quit echo >c:\maus\maus.akt
:LeaveBatch if exist c:\maus\maus.akt del c:\maus\maus.akt ECHO %_DOW %_DATE %_TIME Ende von MAUS.BAT >> %MAUSLog ECHO MAUS.BAT beendet.Seit Jahren erprobt und für gut befunden. Nicht vergessen, daß die Datei maus.akt beim Bootvorgang gelöscht werden muß.
Und dann noch ein alternativen Tip, der aber nur unter 4DOS funktionert.
rem Verhindern, daß man die Maus aus einer Shell startet IFF "%_SHELL" != "0" THEN SET START="" inkey /w5 Achtung. In Subshell Level %_SHELL %%start EXIT ENDIFF
Die rechte Zahl stellt den aktuelle freien Speicher an. Die linke ist der minimal freie Speicher zur Laufzeit der Maus.
Von: Gereon Steffens @ K2 (Sa, 01.02.97 21:51)
MId: 199702012151.a32539@k2.maus.de
Genau ist es folgendes:
< |> |T |C |M 1| 1678064 1850240 WFC |11:41:10 | | | | | | | | Uhrzeit | | | | | | | +- Name der aktuellen Funktion. (*1) | | | | | | | | | | | | | | | | | | | | +- Maximal freies RAM auf dem Heap | | | | | +- Momentan freies RAM auf dem Heap | | | | +- wechselt zwischen Modemport 1 und 2 | | | +- Zählt alle Checks auf interne Timeouts (*2) | | +- Gesetzt wenn es ein internes Timeout gibt | +- Zählt ausgehende Zeichen +- Zählt eingehende Zeichen (*1) und "WFC?" steht für Wait For Call (*2) was ständig passiert, hieran kann man sehen, ob noch Timer-Interrupts kommen.
Gereon
Wenn im m7com.cfg die Variable CheckBetweenCalls auf TRUE steht, ruft die Maus zwischen den Anrufen immer den CALLCHK.BAT Batch auf. Normalerweise nur nach jedem Anruf. Wenn die beiden Variablen ModemCheckInterval und CallCheckAtInterval auf TRUE stehen, dann wird auch alle x Sekunden der Batch aufgerufen. Dort kann man z.B. auch einen Errorlevel stetzen, der die Maus dann veranlaßt, den entsprechenden Event zu starten. Hier mal ein Beispiel aus dem Berliner CALLCHK.BAT zum automatischen User-Tausch (reines DOS)
set RC=0 rem Hat Christian ein Infile abgelegt? if exist %lanpath%cg\tausch\B\outfile.zip goto next1 if not exist %lanpath%cg\tausch\B\infile.zip goto next1 set RC=76 goto event :next1 rem hier können weitere Abfragen kommen .. :event echo %RC% >%mauspath%callchk.rc
Zuerst wird getestet, ob noch ein altes Outfile in dem Pfad liegt. Wenn ja, darf natürlich kein Tausch ausgelöst werden, da sonst das alte Outfile überschrieben wird. Der Test sollte auch hier erfolgen. Wenn man das erst im Maus.bat testet, dann führt die Maus nur noch Events aus, wenn mal ein in- und Outfile rumliegt. Wenn Kein Outfile da ist, muß natürlich getestet werden, ob überhaupt ein INFILE vorhanden ist. Wenn ja, wird der entsprechende Event-Wert in CALLCHK.RC gespeichert und der CALLCHK.BAT beendet. Die Maus kontrolliert den Inhalt der CALLCHK.RC Datei und wenn dort ein Wert größer Null drin steht, beendet sich die Maus mit den entsprechenden Errorlevel und der Event mit der gleichen Nummer wird aus dem MAUS.BAT gestartet. In der MAUS.BAT sieht das dann so aus:
... if errorlevel 76 goto cgtausch .. rem --------------------------- Event 76 --------------------------------- rem autotausch für Christian :cgtausch rem eine Zeile m7com /t Christian Goßlar %lanpath%cg\tausch\B\infile.zip %lanpath%cg\tausch\B\outfile.zip rem das löschen ist ganz WICHTIG!!! del %lanpath%cg\tausch\B\infile.zip goto Again ...
Zwischen zwei Anrufen kann man per Alt-F4 die sofortige Ausführung von CALLCHK erzwingen.
Von : Kai Henningsen @ MS (Fr, 25.06.93 22:57)
HK> worauf testet der Dupecheck der Maus genau?
CRC über das Stichwort. CRC über den Text. MsgId der kommentierten Msg. Empfänger bzw. Gruppe. Länge.
MfG Kai
Wieviele Mails zurück nachgeguckt wird, kann mit den Variablen AllgDupMax, DupMaxDefaultGate, DupMaxDefaultUser und PersDupMax festgelegt werden.
Folgende Tastencodes kennt die Maus (Zahlen nur vom Nummerblock verwenden!)
Alt-222 | Von der Tastatur einloggen |
Alt-234 | Maus regulär beenden |
ALT-246 | beim Warten auf einen Anruf startet einen %COMSPEC%. Zurück zur MAUS mit "exit<cr>". |
Alt-753 | User fragen ob er chatten will |
Alt-999 | User rauswerfen und die Maus verlassen (aber erst wenn der User das Menü wechselt) |
ALT-238 | Runtime-Error 199 der Maus erzeugen. |
Alt-F1 | Mitlesen/tippen abschalten (Spannermodus aus). |
Alt-F2 | Mitlesen/tippen anschalten. Ist aber beim nächsten Anruf wieder abgeschaltet. Gilt also nur für den aktuelle Anruf. |
Alt-F3 | Mitlesen/tippen ständig angeschaltet, bis die Maus beendet wird. Siehe auch ImmerSpannen |
Alt-F5-F8 | Siehe ConsoleKey.FX und Konsolenlogin |
ALT-F4 | Sofortige Ausführung des CALLCHK-Batch. Siehe CallCheck |
Während des Tastaturanrufes |
|
Alt-R | Record On |
Maus-Ausgaben (Mitteilungen usw.) auf File mitloggen Die MAUS fragt dann den Filenamen ab. An eine existierende Datei werden die Ausgaben angehängt. Paging wird abgeschaltet. | |
Alt-C | Close |
Das Ausgabefile schließen. NICHT vergessen!!! |
Ja, klar. Hier mal ein paar Mails dazu. Vorab aber noch ein ganz wichtiger Hinweis von Stefan Heidrich. Man muß unbedingt darauf achten, das der RAR-Packer beim start 585KB freien Speicher hat. Sonst läuft der nicht.
Alexander Güth @ AN schrieb am 25.06.95
für alle die es interessiert, hier die Configs für den Packer RAR sowie dem neuen LHA 2.55. Dank hier bei Gereon für den obskuren Aufruf von LHA :-) - da muß man erstmal drauf kommen :-) ! Der Fehler/Grund hierfür liegt natürlich beim neuen LHA 2.13/2.55 !
M7com.cfg
Packer5.Select := 'R' ;
Packer5.Name := '(R)AR' ;
Packer5.Ext := '.RAR' ;
Packer5.IDoffset := 0 ;
Packer5.IDstring := 'Rar!'#26#7 ;
; Packer5.PackRate := ; [ 6.0000000000E-01]
Packer8.Select := 'H' ;
Packer8.Name := 'L(H)A' ;
Packer8.Ext := '.LZH' ;
Packer8.IDoffset := 2 ;
Packer8.IDstring := '-lh5-' ;
; Packer8.PackRate := ; [ 6.0000000000E-01]
Packer.bat
rem ----------------------------------- .LZH/LHA rem LHARC: :lp Echo. | %PackerPath%lha m -o %4 %5 Goto Done rem LHA: :hp Echo. | %PackerPath%lha m %4 %5 Goto Done :lx :hx echo IN*.* | %PackerPath%lha e /a- -m %4 Goto Done :ll :hl echo *.* | %PackerPath%lha l %4 >%5 Goto Done rem ----------------------------------- .RAR :rp %PackerPath%rar m -m3 %4 %5 Goto Done :rx %PackerPath%rar e -y -x@%PackerPath%forbid.lst %4 Goto Done :rl %PackerPath%rar l %4 >%5 Goto Done
ARCCHECK.BAT
(!nl) rem ----------------------------- LHA/LHARC: (!nl) :l (!nl) :h (!nl) %PackerPath%lha t %2 (!nl) If ErrorLevel 1 Goto Error (!nl) Goto Done :r %PackerPath%rar t %2 If ErrorLevel 1 Goto Error Goto Done
Von: Karl-Heinz Wachtendorf @ OL (Fr, 01.12.95 12:32)
Tja, da hab ich wohl nicht gründlich genug getestet, denn beim Tauschen mit RAR kommt: DOSExit: 0 DOSExitCode: 6 und der Tausch mißlingt. Arccheck und Archiv listen klappt, aber auspacken nicht. RAR kann laut Doku beim *Auspacken* den Parameter -x@FORBID.LST nicht und daher kommt der ExitCode 6. Wenn man den Parameter -x wegläßt, dann klappt wirklich alles. Achja, -std sollte man auch noch einfügen :-)
Kalle
Von: Alexander Güth @ AN (Sa, 02.12.95 12:39)
KHW>Parameter -x@FORBID.LST nicht und daher kommt der ExitCode 6.
KHW>Wenn man den Parameter -x wegläßt, dann klappt
wirklich alles.
dem kann ich nicht zustimmen bei mir schaut das in der packer.bat so aus und es funktioniert mit der v 1.55 prächtig ohne Probleme. Auch das Tauschen mit einem Infile.RAR (gerade getestet).
rem ------- .RAR
:rp
%PackerPath%rar m -std -m3 %4 %5
Goto Done
:rx
%PackerPath%rar e -std -y -x@%PackerPath%forbid.lst %4
Goto Done
:rl
%PackerPath%rar l -std %4 >%5
Goto Done
Du solltest vielleicht mal den ganzen Pfad angeben. Desweiteren wenn ich in der Error.lst nachgucken finde ich unter ExitCode 6 folgendes:
6 ø Ungültiges Datei-Handle ø (Invalid file handle)
Eventl. liegt es auch daran, das einfach nicht genügend freier Speicher da ist ? Fährst du die RealMode Maus ? Wenn ja, sollte oben mind. 200 KB freier Heap da sein. Sonst krachst auch bei mir regelmäßig. Gruß, Alex
Von: Karl-Heinz Wachtendorf @ OL (So, 03.12.95 11:01)
AG>Du solltest vielleicht mal den ganzen Pfad angeben.
Hatte ich auch schon, nützte aber nix.
AG>Desweiteren wenn ich in der Error.lst nachgucken finde ich unter
AG>ExitCode 6 folgendes:
Muß man da nicht in der Doku zum RAR nach den Exitcodes gucken?
Dort steht nämlich dies:
(last operation status and reason for exit).
6 OPEN ERROR Open file error
Was auch erklären würde, wieso es ohne -x Parameter geht.
AG>Eventl. liegt es auch daran, das einfach nicht genügend
freier
AG>Speicher da ist? Fährst du die RealMode Maus?
Ja, und ich habe oben einen Wert zwischen 170-190 kB stehen. Kalle
Von: Georg Bauer @ MS3 (Mi, 17.07.96 09:07)
Hi!
...
Auszug aus dem Handbuch:
Minimum DOS version to run RAR: 3.0
Minimum memory requirements to perform commands and corresponding operations (in Kbytes) are:-
Command | Command | Full | Full | |
line | line | screen | screen | |
mode | mode | mode | mode | |
Not solid | Update | Not solid | Update | |
or adding | solid | or adding | solid | |
to solid | archive | to solid | archive | |
EMS enabled | 337 | 409 | 409 | 481 |
EMS disabled | 401 | 473 | 473 | 545 |
EMS enabled | 217 |
EMS disabled | 281 |
EMS enabled | 409 |
EMS disabled | 473 |
Daraus geht eindeutig hervor, daß RAR in der Kommandozeilenausführung deutlich weniger Speicher braucht, als im Dialog. Und die Maus wird den Dialog ja wohl nicht allzuoft nutzen, oder? :-)
Habs grad mal ausprobiert: 400K frei, und ich konnte Files packen (mit M). Und das macht ja die Maus auch nur. Auspacken ist noch unkritischer.
bye, Georg
Und hier noch die bereits in TAUSCHBAU erschienene Doku zum Format des ITK:
ITK-Zeilen:
# | ID des Kommandos |
N | Name des Kommandos |
A | Aufzählung der Werte eines Aufzählungstyps |
B | Beschreibung der Werte eines Aufzählungstyps |
C | Konstante Teile der Syntax |
D | Defaultwert für ein Feld |
F | Datentyp eines Feldes |
H | Ausführliche Beschreibung des Kommandos |
K | Kurze Beschreibung eines Parameters |
L | Ausführliche Beschreibung eines Parameters |
T | Art des Kommandos |
V | Version des Kommandos |
G | Gruppe zu der dieses Kommando gehört |
Bedeutung:
# | ist eine ganze Zahl, die dieses Kommando eindeutig identifiziert. |
N | ist eine nicht zu lange Bezeichnung für das Kommando; sie könnte z.B. als Auswahl in einem Menü verwendet werden. |
C | beschreibt konstante Teile der Syntax. |
H | ist eine ausführlichere Beschreibung des Kommandos; das Frontend könnte sie als Online-Hilfe im Menü für das entsprechende Kommando zur Verfügung stellen. |
V | enthält eine ganze Zahl, die als Versionsnummer dieses Kommandos dient. Ändert sich die Syntax oder die Bedeutung, so ist diese Nummer zu erhöhen. |
T | gibt die Art des Kommandos an:
|
Fc | gibt den Datentyp eines Parameters an (s. unten) |
Ks | gibt eine kurze Bezeichnung eines Parameters; das Frontend kann sie benutzen, um im Dialog das entsprechende Feld zu beschriften. |
Ls | gibt eine ausführlichere Beschreibung des Parameters. Das Frontend könnte diese als Onlinehilfe zu dem einzelnen Feld anbieten. |
Ds | gibt einen Defaultwert für den Parameter vor; die Syntax ist die, die auch im Infile für diesen Parameter zu verwenden ist. |
As[:s...] | Gibt die Infile-Syntax für einen Wert eines
Aufzählungstyps an. Jeder Wert kann mehrere Zustände
annehmen. Die Syntax verschiedener Zustände wird dabei durch
Doppelpunkte getrennt. Beispiel:
|
Bs | bezeichnet einen Wert eines Aufzählungstyps. Die Unterteilung von Aufzählungstypen erfolgt zweidimensional ("Werte des Aufzählungstyps" X "Zustände eines Wertes"), da dies der Praxis am nächsten kommt. Beschreibungen werden nur für *Werte* angegeben, während die verschiedenen Zustände eines Wertes nur durch unterschiedliche Markierungen an der jeweiligen einzigen Beschreibung dargestellt werden. Übrigens existiert die Option "Set Of" nur entlang der ersten Dimension. Diese Aspekte sind beim Entwurf von Kommandobeschreibungen zu berücksichtigen. Es ist von Fall zu Fall zu entscheiden, ob es intuitiver ist, die Werte entlang der ersten, der zweiten oder beider Dimensionen anzuordnen. Beispielsweise ist es sinnvoll, eine Auswahl im Sinne von "Ein/Aus" (z.B. "Anfordern/Nicht Anfordern") entlang der zweiten Dimension anzu- ordnen: es genügt vollkommen, wenn der Anwender ein Feld "Anfordern" erhält, das er aktivieren kann oder nicht. Hingegen ist es bei einer Auswahl zwischen zwei nicht direkt entgegen- gesetzten Möglichkeiten ("Neue anfordern/Alle anfordern") sinnvoll, dies entlang der ersten Dimension zu tun, um zwei verschiedene Dialog- felder mit jeweils eigenen Beschreibungen zu erzeugen. |
Gx | Gibt die (G)ruppe an, zu der dieses Kommando gehört. Im Moment sind für x folgende Werte definiert:
|
Die generelle Struktur eines ITK-Eintrags ist somit wie folgt:
#<Kommando-Nummer> |
|
N<Kommando-Name> |
|
H<Kommando-Beschreibung> |
|
T<Kommando-Art> |
|
V<Kommando-Version> |
|
Auf diesen mehr oder weniger konstanten Block folgen dann ein oder mehrere syntaxbeschreibende Blöcke. Ein syntaxbeschreibender Block wird eingeleitet durch eine C- oder eine F-Zeile. Wird er durch eine C-Zeile eingeleitet, so produziert er einen konstanten String und besteht nur aus dieser C-Zeile. Ein Block, der durch eine F-Zeile eingeleitet wird, beschreibt einen vom User einzugebenden Parameter.
F<Datentyp> |
|
D<Defaultwert> |
|
K<kurze Beschreibung> |
|
L<lange Beschreibung> |
|
<ggf. noch A- und B-Zeilen, immer paarweise, immer A-Zeile zuerst> |
Die Produkte aller C/F-Blöcke, in der gegebenen Reihenfolge konkateniert, ergeben das Infile-Kommando.
H und L dürfen jeweils mehrfach auftreten. Ein Blank zu Beginn einer Zeile weist das Frontend an, diese Zeile weder neu umzubrechen noch sie zwecks neuen Umbruchs an die vorhergehende Zeile anzuhängen.
Darstellung im Infile | ||
A | Aufzählungstyp | wie in A-Zeilen angegeben |
M | Set of Aufzählung; | |
es gilt alles wie für A, | ||
nur daß das Frontend erlauben | ||
muß, mehrere Werte gleichzeitig | ||
zu aktivieren. | ||
D | Datum | JJJJMMTTHHMM[SS] |
d | Datum | TT[.MM[.JJJJ]] |
Sn | String der Länge n | wie eingegeben |
Pn | Paßwort der Länge n | wie eingegeben |
(wird ggf. nicht angezeigt) | ||
pn | neues Paßwort der Länge n | wie eingegeben |
(Frontend kann ggf. zweimal | ||
fragen) | ||
U | Username | wie eingegeben |
I | ganze Zahl, 2 Byte | dezimal, Ascii, mit |
Vorzeichen, auch wenn positiv | ||
Im,n | ganze Zahl aus dem Intervall | dezimal, Ascii, mit |
[m;n]. | Vorzeichen, auch wenn positiv | |
G | Gruppenname | im Klartext |
g | Name einer Gruppe, in der | im Klartext |
User Chef ist |
Ein 'o' hinter dem Datentyp bedeutet, daß in das Feld keine Daten eingegeben werden müssen. Im Infile ist dann ein Leerstring einzutragen.
MVIDEO.DAT ist der gerettete Bildschirm der Maus. Wenn die Datei fehlt, muss die Maus langwierig den ganzen MCALL.LOG bis zum Ende durchscrollen. Wenn man aber Externe Programme hat, die etwas ins MCALL.LOG schreiben, braucht man eine Zeile
del mvideo.dat
um den geretteten Bildschirm wegzuwerfen.
Als Sysop einloggen, Sysop-Menü, Löschen, andere Mitteilungen und dann die IDs der zu löschenden Mails eingeben. Man kann sich dabei auch noch die Mails vorher angucken.
Eine andere Möglichkeit ist das löschen per Maustauschkommando. Der Aufbau im Infile sieht so aus:
A123456@XY
BX
Am besten ModemXXX weiterbenutzen, Modem1.x vergessen und nur mit Modem2.* alles das anders definieren, bei dem sich die Modems unterscheiden. Damit kann man auch ganz einfach zwischen 1 Port und 2 Port Maus wechseln. In beide Richtungen.
Allgemein:
Die Modem-Antworten sind auch pro Modem konfigurierbar. Die bisherigen Variablen Response_XX gibt's immer noch und dienen als Default für die neuen Variablen ModemY.Response_XX.
Wg.: Achtung, RAR Packer...
Von: Andreas Mandel @ OG (Mo, 12.08.96 21:45)
Moin,
heute hat es ein User geschafft die Maus wegzuhängen.
Wenn der RAR Packer ein Passwort verschlüsseltes Archiv zum *testen* bekommt frägt er nach dem Passwort, leider kann der User das nicht eingeben und der Prompt steht bis zum Reset auf dem Screen.
Für das Listen des Inhalts benötigt er kein Passwort, allerdings zum Auspacken beim Maustausch :-(.
Abhilfe bringt mittels "-pxxx" beim Aufruf ein beliebiges Passwort mit anzugeben, dann frägt der RAR nicht nach. Er meldet dann u.U. lediglich das das Passwort falsch ist. Unverschlüsselte Archive werden wie gewohnt ausgepackt. Also im arccheck.bat und packer.bat ändern!
Andreas.
In der Maus ist der Event 70 vorbelegt, und zwar für die Anrufübernahme des MausNet, der an einer bestimmten vordefinierten Sequenz erkannt wird. Dann wird autoEvent1 und AutoLog1 von der Maus ausgeführt. Deshalb sollte man diesen Event nicht aus dem Maus.Bat bzw. dem m7com.cfg löschen, verändern.
Wg.: Keine Sicherheitslücke mit RAR mehr!
Von: Thomas Voss @ SU (Di, 13.08.96 15:35)
Hallo zusammen!
Viele von Euch bieten ja mittlerweile auch RAR zum MausTausch an.
RAR hat leider zwei schwerwiegende Nachteile:
1. "Exclude-Lists"
(Listen mit Mustern von Dateinamen, die auf keinen Fall ausgepackt werden dürfen):
In der Version 1.xx kennt RAR keine "Exclude-Lists", ab der Version 2.00 gibt es zwar einen Schalter -x, der aber mehr als schlampig programmiert ist: Es genügt bereits, die Dateien mit Pfadangabe ins Archiv zu packen, und schon passen sie nicht mehr auf die Angaben in der Exclude-List (z.B. würde TEST\VIRUS.EXE ausgepackt, auch wenn in der Exclude-List *.EXE vorkäme).
2. Versionsflag:
Im Gegensatz zu den anderen Packern gibt's bei RAR kein eindeutiges Flag an fester Stelle im Archivheader, an dem man die verwendete Version erkennen kann. Die Maus kann mit der einfachen Methode "PackerXIDString" die zu verwendende RAR-Version (1.xx oder 2.xx) nicht erkennen, man kann immer nur eine RAR-Version auf der Maus installieren.
Jede Mausbox, die RAR bisher installiert hat, ist Hackversuchen durch Archive mit "gefährlichen" Dateinamen im Inhalt (beliebt sind z.B. die Gerätetreiber CLOCK$, EMMXXXX0 etc.) schutzlos ausgeliefert!
Ich habe nun ein Zusatztool "RARCHECK" geschrieben, was sich sehr leicht in die Maus einbinden läßt und die Sicherheitslücke mit RAR nun endlich behebt:
die enthaltenen Dateien mit Hilfe einer frei definierbaren Exclude-List vollständig überprüfen und verbotene Dateinamen erkennen,
überprüfen, ob Dateien enthalten sind, die den Namen von auf dem Rechner installierten Gerätetreibern besitzen,
die enthaltenen Dateinamen nach frei definierbaren unerlaubten Zeichen durchsuchen,
das Archiv direkt so patchen, daß von den drei vorigen Tests gefundene "verbotene Dateien" mit RAR bzw. UNRAR nicht mehr ausgepackt werden können!
RARCHECK kann außerdem die Versionsnummer von RAR bestimmen, die zum Auspacken eines RAR-Archivs benötigt wird. Dadurch wird es möglich, auch verschiedene Versionen von RAR zum MausTausch anzubieten (wir haben hier in SU mittlerweile RAR 1.5x und RAR 2.00 installiert).
Wer interessiert ist, kann sich RARCHECK bei uns im GPT SYSOP.PROG saugen (Archiv RARCHECK.RAR, 26kB). Das Paket enthält auch eine ausführliche Doku mit Beispielen zur Installation.
Bitte per MU einloggen und von seiner Heimatmaus eine PM an Sysop@SU schicken!
Viele Grüße, Thomas
Was kann man gegen das blokieren der Maus durch fehlerhafte z-Modem downloads, die mehrere Stunden dauern, tun?
Ja, und zwar ein Z-Modem installieren, das auch eine Zeitüberwachung durchführen kann. Wie das installiert werden muß? Hier mal der Mecedes unter den Batchen von Gereon.
Von: Gereon Steffens @ K2 (Mo, 21.07.97 16:26) >Hab ich doch. Welchen Schalter braucht man denn da? RTFM. -z und -t sind die wichtigen Optionen, die Werte muß man anhand EXTERN.CFG berechnen. Hier ist der Ausschnitt aus meinem PROTBAT: (%PP ist der Pfad zu den Protokollen) :dozmodem set H=%@fileopen[%6extern.cfg,read] if "%H" == "-1" goto SkipOpts :loop set LINE="%@fileread[%H]" if %LINE == "**EOF**" goto OptsDone if %@word[" '",0,"%LINE"] == ""RestZeit set MINS=%@word[" '",2,"%LINE"] if %@word[" '",0,"%LINE"] == ""BaudToUser set CPS=%@word[" '",2,"%LINE"] goto loop :OptsDone set CPS=%@eval[%CPS \ 15] set MINS=%@eval[%MINS + 3] set OPT=-ti30 -z%CPS -t%MINS set H=%@fileclose[%H] :SkipOpts set ZED= if %3 == 8 set ZED=-88 if %2 == s %PP\zm -f -c%1 %ZED -nochat -nologo %OPT sz %7 if %2 == r %PP\zm -f -c%1 %ZED -nochat -nologo %OPT rz . if errorlevel 1 goto error goto ok Gereon
#80 | Modem antwortet nicht |
#81 | Modem nimmt keine Daten an, Output-Buffer wird nicht leer - wahrscheinlich Handshake blockiert |
#82 | ModemCheck funktioniert nicht. Das Modem auf den ModemCheck-String - auch beim 5. Versuch - nicht mit OK geantwortet hat. ("Hallo, Modem, lebst Du noch?") |
#83 | X00 will sich nicht initialisieren lassen |
#84 | Timer läßt sich nicht einhängen, nicht benutzt |
#85 | Timer läßt sich nicht aushängen, nicht benutzt |
#86 | X00-Kommunikations-RangeCheck z.B.B falsche Baudrate oder nicht implementierter FOSSIL-Aufruf) |
#87 | kein Fossil da |
#88 | Absturz, bevor der normale Fehlerhandler installiert ist |
#90 | M7DEC ist tütt |
#92 | MsgIdx-Buffer übergelaufen |
#199 | Manueller Runerror per Alt-238 |
#220-224 | Ärger im Programmteil |
Die Maus richtet zum importieren von Mails einen MsgIndx-Buffer ein. Wenn jetzt aber einmal ein großer Schub von Mails kommt (10000 und mehr), ist der Buffer voll und das einsortieren von Mails dauert ewig (ca. 2-3 pro Minute!)
Was kann man dagegen tun?
Das hängt davon ab, wie groß die MsgBase ist.
MsgBase unter 60000 Msgs: In M7COM.CFG die Variable "MsgIndexMax" *nicht* besetzen, bei einer MAUS ohne große Gateways dafür "MsgIdxReserve" auf Werte zwischen 2000 und 5000 setzen.
MsgBase bei 60000 oder mehr Msgs: Über die Putzparameter (Aufbewahrungszeit!) eine kleinere MsgBase erzwingen, dann a) befolgen.
Und auch noch interessant.
Von: Gereon Steffens @ K2 (Do, 07.07.94 17:20)
>was denn nun? Gereon schreibt von MSGIndexMax und
>Du von MsgIdxReserve...
Beides. MsgIndexMax setzt eine absolute Grenze, MsgIdxReserve eine
dynamische (eben aktuelle MsgBase + Reserve). Damit ist MsgIndexMax fast
überflüssig und sollte immer auf dem Default (0) belassen werden.
Tunen kann man dann mit MsgIdxReserve, indem man das so hoch setzt,
daß ein Schub Mail im Netz oder Tausch bequem in diese Reserve
passen.
>hab's mal hoch auf 60.000 genommen. Habe derzeit ca. 45.000 Mails + >10.000 und eine kleine Reserve.
Ich würde MsgIndexMax wie gesagt nicht nehmen, dafür lieber MsgIdxReserve hochsetzen.
Gereon
Folgendes Problem: Versucht jemand über Modem ein File "upzuloaden", bricht die Übertragung in die MAUS bei exakt 2048 Byte zusammen und wird nur noch sporadisch mit ca. 72 cps fortgesetzt. Downloads klappen gut; im Betrieb mit einem Terminalprogramm empfängt das Modem mit passender Geschwindigkeit.
Die Lösung:
Der HDD-Blockmode verursachte die Fehlfunktion des Modems.
Von: Frank Baschin @ SL (Mi, 03.11.93 21:38)
Moin Sevo,
SS>Das mit der Satzmitte liegt am Zyxel - das überträgt
nach dem
SS>Auflegen nicht mehr seinen Pufferinhalt.
dagegen kam aus MS doch neulich die passende Config für das
M7COM.CFG.
UseDtrC := TRUE; [FALSE]
UseDtrH := FALSE; [TRUE]
Klappt bei mir wunnebar.
gruß frank
Ja. Erstmal muß das Modem problemlos auch Faxe empfangen können (neben den normalen Connects). Das alte ZyXel 14irgendwas kann das, wenn das nicht mittels S38.4=1 abgeschaltet ist.
Kommt nun ein FAX an, sendet das ZyXel den String 'ZyXEL' an die Maus. Normalerweise würde nix passieren. Wenn allerdings die Variablen AutoLogX und AutoEventX gesetzt sind, kann automatisch ein Event ausgelöst werden, der dann das Fax empfängt und abspeichert.
Mehrere Modems/ISDN-Karten an der Maus zu betreiben ist kein Problem. Hier mal in Stichworten die hoffentlich vollständige Beschreibung.
In ModemPorts die aktuelle Anzahl der Modems eintragen
per ModemX.X00Port und ModemX.ComPort die Port festlegen. Hier mal ein Beispiel aus der Maus Berlin, an der drei Modems hängen:
Modem1.X00Port := 0; [0] x00-Port, an dem das Modem1 hängt Modem1.ComPort := 1; [1] Com-Port, an dem das Modem1 hängt Modem2.X00Port := 2; [1] Modem2.ComPort := 3; [2] Modem3.X00Port := 1; [2] Modem3.ComPort := 2; [3]
Modem1 ist ein USR am physikalischen COM-Port 1
Modem2 ist eine Teleskarte am virtuelle COM-Port 3
Modem1 ist ein USR am physikalischen COM-Port 2
die verschiedenen Init-String erschlägt man am besten so. Alle relevanten Modem-Variablen z.B. per ModemInit definieren und nur wenn es nötig ist, z.B. per Modem2.Init einen anderen String einstellen. So spart man sich Tipparbeit, da die ModemInit-Werte als Defaultwerte für die ModemX.Init Variablen benutzt werden.
Das war es eigentlich.
Hier in der Maus B läuft ein ZyXel 1496e mit folgender Konfiguration:
Factory Settings 6.13EP... Änderungen, die ins Setting gebracht werden sollen: P statt T ; Pulswahl statt Tonwahl einstellen L3 statt L4 ; Lautstärke auf 3/7 M statt M1 ; Lautsprecher aus X7 statt X5 ; Meldungen ala CONNECT 19200/ARQ/V42b *Q statt *Q2 ; nur Usermodem entscheidet über Fallback/-Forward ---> S42.1= 1 ; Durchsatz mitteln -> gestrichen da 16550 on board ---> S38.5= 1 ; MNP5 disablen -> gestrichen wegen Kompatibilität ---> S2 = 128 ; Escape-Charakter disablen -> gestrichen, nächste Z. S42.3= 1 ; Keine Escape im Answer-Modus (also Boxbetrieb) S10 = 20 ; Carrier-Verlustzeit 2 Sekunden S13.1= 1 ; erweiterte ATI2-Meldungen S20 = 1 ; 57600 Bd DTE S50 = 30 ; nach 5 Minuten (30*10s) Inaktivität auflegen S42.6= 1 ; keine 'RINGING'-Meldung mehr S38.4= 1 ; keine Fax-Antwort S48.1= 1 ; statt FAX - V.21 mit 300 BPS erlauben auslogpufferS43.5= 1 ; etwas erhöhte Eingangsempfindlichkeit das wird nach Eingabe ins Modem mit 6.13EP dann zu: B0 E1 L3 M0 N5 Q0 V1 X7 &B1 &C1 &D2 &G0 &H3 &J0 &K4 &L0 &M0 &N0 &P0 &R1 &S0 &X0 &Y1 *B0 *C0 *D0 *E0 *F0 *G0 *I0 *L0 *M0 *P9 *Q0 *S0 S00=000 S01=000 S02=043 S03=013 S04=010 S05=008 S06=003 S07=060 S08=002 S09=006 S10=020 S11=070 S12=000 S13=002 S14=002 S15=130 S16=000 S17=018 S18=000 S19=000 S20=001 S21=176 S22=000 S23=123 S24=106 S25=000 S26=000 S27=028 S28=068 S29=000 S30=000 S31=017 S32=019 S33=255 S34=030 S35=032 S36=000 S37=000 S38=016 S39=000 S40=000 S41=000 S42=072 S43=040 S44=000 S45=100 S46=028 S47=064 S48=002 S49=006 S50=030 S51=000 S52=000 S53=000 S54=000 S55=000 S56=000 S57=000 S58=000 S59=000 Das ganze ins Setting 4 abspeichern und dann noch ins M7Com.cfg ModemInit1 := 'Z4 S10=18 S35.5=0'; ModemCheck := 'Z4 S10=18 S35.5=0'; max. 20 Stellen ModemReset := 'Z4 S10=18 S35.5=0'; gleich Z0
Von: Udo Erdelhoff @ DO2 (So, 20.07.97 22:21)
Hi,
JL>Mich würde interessieren, wie sich das Modem an der MAUS
verhält, ob
JL>es was besonderes dabei zu beachten gibt.
eigentlich relativ problemlos, wenn man ein paar Dinge beachtet:
- Das Modem und das Netzteil werden warm, wenn man nicht dafür
sorgt, daß sie jede Menge Luft kriegen, kann es Ärger geben.
- Es gibt Probleme mit älteren Firmware-Versionen, die im
ISDN-Data-Multiauto-Modus (was ein Wort), irgendwelche Nullbytes vor die
Connect-Meldung packen. Die Maus reagiert darauf sehr ungehalten und
schmeißt den Connect sofort wieder weg. Die Kombination 2.04a und
Maus 7.95j läuft aber einwandfrei.
- Bis einschließlich Firmware-Version 2.02 führte ein ATH1
dazu, daß ankommende Anrufe mit "User Busy" abgelehnt wurden.
Otto Normaluser hörte dann das Besetztzeichen. Mit 2.03 wurde auf das
auf "Call rejected" geändert, was zwar eigentlich richtig ist,
aber bei Otto Normaluser zur Ansage "Dieser Anschluß ist
vorübergehend nicht erreichbar" führt. Seit 2.04a kann man
das Verhalten des Zyxels konfigurieren. Lies: Wenn man das Zyxel 2864ID an
der Maus betreibt, braucht man die Firmware-Version 2.04a oder neuer und
muß S79 auf 128 setzen. Praktischerweise ist das nur im Readme zur
2.04a und in der Onlinehilfe dokumentiert.
Meine Settings (Huhu, FAQ-Maintainer, wink, ich bin ein Zaunpfahl):
Current settings ..... ISDN Outgoing Service : X.75 E0 L0 M0 N0 Q0 V1 X7 Z0 CB0 CC0 CD1 CP0 &B1 &C1 &D2 &E0 &G0 &H3 &J0 &K4 &K00 &L1 &M0 &N0 &O0 &R1 &S0 &X0 &Y1 *C0 *D0 *E0 *G0 *GC0 *Q2 S00 = 0 S01 = 0 S02 = 43 S03 = 13 S04 = 10 S05 = 8 S06 = 3 S07 = 60 S08 = 2 S09 = 6 S10 = 7 S11 = 70 S12 = 0 S13 = 0 S14 = 2 S15 = 2 S16 = 0 S17 = 30 S18 = 0 S19 = 0 S20 = 1 S21 =176 S22 = 0 S23 =120 S24 = 0 S25 = 0 S26 = 0 S27 =156 S28 = 68 S29 = 0 S30 = 0 S31 = 17 S32 = 19 S33 = 0 S34 = 30 S35 = 32 S36 = 0 S37 = 0 S38 = 0 S39 = 32 S40 = 0 S41 = 16 S42 = 0 S43 = 8 S44 = 0 S45 =100 S46 = 28 S47 = 64 S48 = 0 S49 = 6 S50 = 0 S51 = 0 S52 = 0 S53 = 0 S54 = 0 S55 = 0 S56 = 50 S57 = 16 S58 = 0 S59 = 0 S60 = 2 S61 = 0 S62 = 0 S63 = 0 S64 = 0 S65 = 0 S66 = 0 S67 = 0 S68 = 0 S69 = 0 S70 = 0 S71 = 64 S72 = 0 S73 = 8 S74 = 0 S75 = 0 S76 = 0 S77 = 0 S78 = 0 S79 =128 S80 = 0 S81 = 62 S82 = 62 S83 = 0 S84 = 36 S85 = 1 S86 = 0 S87 = 0 S88 = 0 S89 = 0 S90 = 0 S91 = 0 S92 = 0 S93 = 0 S94 = 0 S95 = 0 S96 = 0 S97 = 0 S98 = 0 S99 = 0 S100= 0 S101= 62 S102= 62 S103= 0 S104= 0 S105= 0 S106= 7 S107= 0 S108= 0 S109= 0 S110= 0 S111= 0 S112= 8 S113= 0 S114= 8 S115= 0 S116= 0 S117= 0 S118= 0 S119= 16 S120= 0 S121= 0 S122= 0 S123= 0 S124= 0 S125= 0 S126= 48 S127= 32 Modem1.Init1 := 'Z' Modem1.Exit := '' Modem1.Auflegen := 'H0' Modem1.Abheben := 'H1' Modem1.Annehmen := 'A' Modem1.Check := 'Z' Modem1.Reset := 'Z' Modem1.CheckS2 := 'S2?'; Modem1.SetS2 := 'S2=0'; Modem1.CmdMode := #0#0#0; Modem1.DataMode := 'O'; Modem1.Status := ''; Modem1.DialPre := 'DI'; Modem1.DialPost := ''; Modem1.Response_Ignore5 := 'FM*';
Alle Einstellungen stehen im Profile 0 (->Handbuch). Was die Einstellungen für die Rufnummer angeht:
Rufnummern-Einstellung: Ich gehe mal davon aus, daß Du analoge und digitale Anrufer auf einer Rufnummer versorgen willst. In dem Fall einmal(!) aus einem Terminalprogramm AT&ZI4=Rufnummer und AT&ZI6=Rufnummer setzen. Dabei läßt man die Vorwahl natürlich weg. Wenn Du auch beim Rausrufen Rufnummern übermitteln willst, kannst Du die mit AT&ZOI (ISDN), AT&ZOM (Modem/Fax) und AT&ZOB (a/b-Wandler) setzen. Außerdem solltest Du (in der Theorie auch einmalig, in der Praxis gibt es da Probleme) mit ATCN<0> und ATCI<00> die Präfixe für nationale und internationale Anrufe setzen. Ist nicht unbedingt notwendig, sieht nur im Log schöner aus.
Apropos Log: Mit den obigen Settings meldet sich das Zyxel wie folgt:
RING
FM: 02319252119 TO: 9252186
RING
Mit dem o.g. Response_Ignore und LogIgnored := TRUE werden die Rufnummern der Anrufer dann mitgeloggt. Ist ganz praktisch, um dieNetzstörer mit ISDN rauszukriegen.
JL>Ich möchte auch meine ISTEC 1008 rausschmeißen, denn
die macht auch
JL>manchmal Streß.
Das Probleme kenne ich... Allerdings habe ich nie versucht, ein weiteres Modem an den a/b-Wandler anzuschlißen. Probier es einfach mal aus und schildere uns dann die Ergebnisse :)
/s/Udo
Vorab eins. Zumindest bei der v34+ BTZ Firmware gibt es Probleme mit der Übertragung, wenn vorher ein User mit einem Rockwel-Chipsatz Modem anruft. Danach treten verstärkt Blers und Retrainsauf, d.h. die Übertragung stockt usw. Deshalb sollte man unbedingt zwischen den Anrufen ein ATZ ans Modem schicken. Und zwar mit ModemCheck und CallChkBat Seitdem das hier in der B3 so eingestellt ist, treten diese Probleme nicht mehr auf. Allerdings müssen dann alle Modemeinstellungen direkt im Modemsetting abgespeichert werden, da alle ModemInit Werte durch das ATZ überschrieben werden.
Das USR Courier läuft hier an der B3 mit der v34 BTZ Firmware. Folgende Setting werden verwendet:
USRobotics Courier HST Dual Standard V.34+ Fax Settings... B0 C1 E1 F1 M1 Q0 V1 X7 BAUD=115200 PARITY=N WORDLEN=8 DIAL=HUNT OFF HOOK TIMER &A3 &B1 &C1 &D2 &H1 &I0 &K3 &L0 &M4 &N0 &P0 &R2 &S0 &T5 &X0 &Y1 %N6 S00=000 S01=000 S02=043 S03=013 S04=010 S05=008 S06=003 S07=060 S08=002 S09=006 S10=020 S11=085 S12=025 S13=000 S14=000 S15=000 S16=000 S17=000 S18=000 S19=000 S20=000 S21=010 S22=017 S23=019 S24=150 S25=005 S26=001 S27=000 S28=008 S29=020 S30=000 S31=000 S32=009 S33=000 S34=000 S35=000 S36=000 S37=000 S38=000 S39=010 S40=007 S41=000 S42=126 S43=200 S44=015 S45=000 S46=000 S47=000 S48=000 S49=000 S50=000 S51=000 S52=000 S53=000 S54=064 S55=000 S56=000 S57=001 LAST DIALED #: Configuration Profile... Product type Germany External MSK Options HST,V32bis,Terbo,V.FC,V34+ Fax Options Class 1/Class 2.0 Clock Freq 20.16Mhz Eprom 256k Ram 32k Supervisor date 03/25/96 DSP date 07/05/95 Supervisor rev 049-6.2.2 DSP rev 1.2.2
Im m7com.cfg steht dieses hier:
ModemInit1 := 'Z S40=7 S57=1'; ModemInit2 := ''; ModemAuflegen := 'M3 H'; ['M1 H'] ist das gleiche wie H0 ModemAbheben := 'M3 H1'; ['M0 H1'] ModemAnnehmen := 'A'; ModemCheck := 'Z'; gleich B0 ModemReset := 'Z'; gleich Z0 ModemCheckS2 := 'S2'; da stand ats2? ModemSetS2 := 'S2=43' ModemCmdMode := '#43#43#43' ;ModemCmdMode := #0#0#0; ModemDataMode := 'O'; ModemEchoOff := 'E'; gleich E0 ModemStatus := 'I6 I11'; Verbindungsstatus ins Log-File ModemBreakOn := 'Y1'; ModemBreakOff := 'Y0'; ModemNoAutoCall := 'S0=0'; WaitWithATA := 3; WaitforDCDafterConnect := 55; RingAllowedSec := 5; MaxConnectWait := 55; Modem1.DeAktivVorProt := true; Modem1.ReInitNachProt := true; ConnectOhneARQ := true;
Und hier mal eine Bastelanleitung, damit ein ATZ oder der ModemCheck String immer nach einem Anruf ans Modem geschickt wird.
Folgende Variablen sollten gesetzt werden:
CheckBetweenCalls := TRUE;
Aktiviert den CallCheck. Die Maus führt zwischen zwei Anrufen den
'callchk.bat' aus.
ModemCheckInterval := 30; [120]
Setzt die Intervalzeit in Sekunden, in der die Maus das Modem checkt
und der 'callchk.bat' aufgerufen wird.
CallCheckAtInterval := TRUE;
Aktiviert nicht nur den Check nach jedem Anruf sondern auch den alle x
Sekunden.
ModemCheck := 'Z'
Das wird bei jedem ModemCheckInterval an die Maus geschickt
Achtung. Die Modemsettings müssen deshalb so eingestellt werden, das ein 'ATZ' als Initstring ausreicht. Also auch ModemCmdMode usw. müssen im Init abgespeichert sein.
Wenn man noch 'ModemLog' aktiviert, wird TRUE wird in LogPath\MODEM.LOG ein Protokoll der Kommunikation zwischen MAUS und Modem angelegt. Da kann man da auch nachgucken, was ans Modem geschickt wird usw. Aber nicht zu lange an lassen, sonst quilt die Platte über
Und hier die Hinweise von Gabriel Schmidt im Zusammenhang mit Faxempfang
ati4 USRobotics Courier HST Dual Standard V.34+ Fax Settings... B0 C1 E1 F1 M1 Q0 V1 X7 BAUD=115200 PARITY=N WORDLEN=8 DIAL=HUNT ON HOOK TIMER &A3 &B1 &C1 &D2 &H1 &I0 &K1 &L0 &M4 &N0 &P0 &R2 &S0 &T5 &X0 &Y1 %N6 S00=000 S01=000 S02=043 S03=013 S04=010 S05=008 S06=003 S07=090 S08=002 S09=006 S10=007 S11=085 S12=050 S13=001 S14=000 S15=000 S16=000 S17=000 S18=000 S19=000 S20=000 S21=010 S22=017 S23=019 S24=150 S25=005 S26=001 S27=001 S28=008 S29=020 S30=000 S31=000 S32=009 S33=000 S34=000 S35=000 S36=000 S37=000 S38=000 S39=010 S40=007 S41=000 S42=126 S43=200 S44=015 S45=000 S46=000 S47=000 S48=000 S49=000 S50=000 S51=000 S52=000 S53=000 S54=064 S55=000 S56=016 S57=001 LAST DIALED #: OK
*Wichtig:* ATS13=1 bedeutet "Reset an fallender DTR-Flanke" (patcht einen Bug im USR Courier)
Und dann die Modem-Befehle für die Maus-Konfig.:
; Defaults für beide Ports: ; ModemCheck := 'B0'; OK-Antwort wird gecheckt ModemReset := 'Z'; ModemEchoOff := 'E'; ModemCheckS2 := 'S2?'; ModemSetS2 := 'S2=0'; Cmd-Mode-Character umdefinieren (statt '+') ModemCmdMode := #0#0#0; Character hier und bei SetS2 muß gleich sein ModemDataMode := 'O'; ; ; Port 1: US Robotics Courier V.everything ; Modem1.Init1 := '+FCLASS=2.0'; Modem1.Init2 := '+FAA=1+FLI="+49 631 17901"'; Modem1.Annehmen := 'A'; Modem1.Auflegen := 'M0H+FCLASS=2.0+FAA=1+FLI="+49 631 17901"'; Modem1.Abheben := 'M0H1'; Modem1.Status := 'I6I11'; Response_NO_DIALTONE := 'NO DIALTONE'; Response_Ignore1 := 'RINGING'; Response_Ignore2 := '+FDM'; ConnectString31 := '+FCO'; ConnectBaud31 := 14400; ConnectEvent31 := 71; ; Event 71 ist FAX-Empfang Event71Hinweis := 'FaxEmpfang';
Dann braucht man nur noch im MAUS.BAT seinen Faxreceiver aufrufen:
:FAXEmpfang REM CLASS 2.0 cdd d:\bgfax\ bgfax /FCO:5 d:\bgfax\infax\ 1 Z cdd c:\maus\ james /L- /I infax.txt goto Again
So, das müßte es gewesen sein. Hoffe ich... :-)
Dazu nur diese Mail von Markus Fritze.
Von: Markus Fritze @ HH2 (Mi, 07.08.96 12:09) MId: 199608071209.a2762@hh2.maus.de RId: 199608052213.a15243@un.maus.de ER> Könntet ihr mir mal eure KONFIGS zukommen lassen? AT&F1 ATS40=7 AT&W S40 schaltet die BZT Zulassung ab, die nervt nur. Ansonsten haben wir nix besonderes mit dem Teil angestellt :-)
Zweiter Tip.
ATS39=11
setzt den Sendepegel des Sportsters auf den maximal mögliche Wert. Schadet auf jeden Fall nix.
Von: Daniel Stämmler @ UL (Fr, 18.07.97 13:55)
Hi!
modemInit1 := '&F1 S2=0 S10=95 S11=90 S25=100 S38=3 S32.4=0' ; [''] modemInit2 := 'L0 M0 X4 &K3 &A3 &D2 S32=6 &N0 &U0'; [''] modemAuflegen := 'H M1'; ['M1 H'] modemAbheben := 'M0 H1'; ['M0 H1']
Es ist zwar einiges unnützes dabei, funktioniert in UL jedoch seit Monaten wunderbar. Seit dieser Konfiguration sind Carrier Losts u.ä. Vergangenheit.
Ach ja: S40=6&W schaltet die Wahlsprerre aus.
"Bis die Tage"
Daniel
oOo 1 Jahr MAUS Ulm oOo
Von: Andreas Romeyke @ L2 (Fr, 14.02.97 21:02)
MId: 199702142102.a4672@l2.maus.de
Hallo,
GS> betreibt jemand von euch an seiner Box ein ELSA MicroLink 33.6
TQV? Wie
GS> sehen denn die Erfahrungen mit diesem Modem aus? Welche Firmware
ist den
GS> aktuell?
Maus L2 (Quark II-System)
Das Modem ist zuverlässig und baut stabile Verbindungen. Probleme gibt es mit Creatix und einigen Dr. Neuhaus (statt 19200 v42bis nur 14.400 bei Neuhaus, Creatix bleibt sehr kurz in Verbindung), liegt aber IMHO an den Modems...
Ansonsten wir verwenden Firmware 1.19. Ein Problem könnte noch sein, das es die Firmware nicht zuläßt, das man länger als 255 s ein ATH1 wirksam halten kann.
Besonders zu schätzen sind die Register zum Auslesen von Fehler- und Verbindungscodes (besonders gut nutzbar bei der Quark II), die es einem als Sysop ermöglichen Fehler in der Konfiguration von Usern zu erkennen.
Der Support von Elsa ist hervorragend, im übrigen ist das Sysopdeal- Programm verlängert worden...
Man kann einfach ein "CONNECT*" als ersten ConnectStringX in der MAUS konfigurieren. Da bei der Erkennung nach dem "spätesten" Treffer gesucht wird, schlägt der nur dann zu, wenn alle anderen nicht gepasst haben. Es muß aber wirklich der erste Connect-String, also CONNECT1 sein. Damit kann aber nicht verhindert werden, das Müll-Connects, also Connets bei denen das Modem nur Müll zurückschickt, die Ausgabe des Modems als Modem-Müll im MCall.Log landet. Das kann man nur dann verhindern, wenn LogIgnored auf FALSE steht (denke ich mal)
Hier mal Gereons ConnectString Einstellunge für die Maus K2, mit der ZyXel v34 und ISDN-Connect funktionieren. Außerdem noch die alten HST-Connects. Sehr viel mehr braucht man eigentlich nicht. Alles ohne Garantie
ConnectString1 := 'CONNECT 64000*'; ConnectBaud1 := 64000; ; ConnectString2 := 'CONNECT 300*'; ConnectBaud2 := 300; ConnectString3 := 'CONNECT 1200*'; ConnectBaud3 := 1200; ConnectString4 := 'CONNECT 2400*'; ConnectBaud4 := 2400; ConnectString5 := 'CONNECT 4800*'; ConnectBaud5 := 4800; ConnectString6 := 'CONNECT 7200*'; ConnectBaud6 := 7200; ConnectString7 := 'CONNECT 9600*'; ConnectBaud7 := 9600; ConnectString10:='CONNECT 12000*'; ConnectBaud10 := 12000; ; ConnectString11:= 'CONNECT 14400/*'; ConnectBaud11 := 16560; ConnectString13:= 'CONNECT 14400'; ConnectBaud13 := 14400; ; ConnectString14:= 'CONNECT FAST'; ConnectBaud14 := 21000; ConnectString15:= 'CONNECT FAST/*'; ConnectBaud15 := 24150; ; ConnectString16:= 'CONNECT 19200*'; ConnectBaud16 := 22080; ConnectString17:= 'CONNECT 16800*'; ConnectBaud17 := 19320; ConnectString18:= 'CONNECT 31200*'; ConnectBaud18 := 35880; ConnectString19:= 'CONNECT 33600*'; ConnectBaud19 := 38640; ConnectString20:= 'CONNECT 28800*'; ConnectBaud20 := 33120; ConnectString21:= 'CONNECT 26400*'; ConnectBaud21 := 30360; ConnectString22:= 'CONNECT 24000*'; ConnectBaud22 := 27600; ConnectString23:= 'CONNECT 21600*'; ConnectBaud23 := 24840;
Bei ISDN-Karten gibt es das Problem, das, wenn die Maus durch einen Modemanruf belegt ist, die Karte bei einem ISDN-Anruf einfach nicht antwortet, der ISDN-Anrufer also ein "34BA: No User responding" bekommt und kein Busy-Signal. Um diese in der Maus zu erzeugen, gibt es das Programm Rejectit von M. Schmidke und die beiden Variablen ISDNCallReject ISDNCallRejectEAZs in der Maus. Wenn das Programm mit geladen wird und die Variablen die richtigen Werte haben, bekommt ein ISDN-Anrufer ein saubers Busy-Signal, wenn ein Modem-Anrufer in der Maus ist.
Wie bekommt man die Nummer des Anrufers ins MCall.log?
Folgendes sollte mindestens eingestellt bzw. aktiviert sein:
CfgVar LogIgnored (boolean, default False). Bei True werden die Response- Ignore-Strings protokolliert, ebenso nach einem RING alles, was nicht als CONNECT erkannt wurde.
Wenn Response_RING auf '*' endet und das Modem nach dem RING noch mehr Daten schickt, dann werden diese im MCALL protokolliert, wenn LogIgnored=true ist.
Um also die Tel-Nummer im Logfile stehen zu haben, muß man
Response_Ignore5 := 'FM=*'
LogIgnored := TRUE
aktivieren (neben der richtigen Einstellung bei der ISDN-Hardware)?
Alles ohne Gewähr.
So, und jetzt der Tip mit Gewähr. Hier läuft eine Teles-Karte und die Übertragung ins Logfile geht so:
Modem2.Response_Ignore4 := 'ID=*' ; ['ID=*']
oder den Defaultwert drin lassen:-). Außerdem muß mit s10.0=1 dem cFos noch gesagt werden, das die Caller-ID auch mit übertragen wird. Sonst ist nix an den Defaultwerten geändert.
cg
Ich möchte eine lokale Info-Gruppe aufmachen und sie soll, mit Ausnahme für die Sysops, ReadOnly sein. Wie kann ich das einstellen?
Öffentlich, kein WriteAccess, kein KeineMitglieder, alle Sysops als Mitglieder eintragen (kann man aber auch bleiben lassen, mit Status S geht's sowieso).
Man kann relativ einfach eine Gruppen-Pt sowohl auf CD als auch auf
Festplatte einrichten. Das ist besonders dann sinnvoll, wenn man z.B. die
AC2-CD von deren öffentlichen PT hat. So hat man eine sehr gute
Grundlage für seinen eigenen öffentlichen PT.
Nun aber zur Anleitung, wie ich es in der B3 gemacht haben. Und dort
läuft es zumindest bisher problemlos.
Backup der aller PAR,PTH und DAT Dateien anlegen!
Die CD erstmal ganz normal ein die Maus in einen Gruppen-PT einbinden (siehe Gruppenprogrammteil auf CD) oder irgendwie anders funktionierde PAR, DAT und PTH Dateien des CD-Programmteils erzeugen.
Einen Dummy Gruppen-PT anlegen, z.B. Dummy und dort auch mindestens ein File ablegen, den sonst erzeugt die Maus keine PAR/DAT Dateien und ich weiß nicht, was sonst noch nicht initialisiert wird.
Im Sysop-Nude unter Gruppen-Verwaltung die Nummer der Gruppe feststellen, z.B. 42
Maus runterfahren
Die gerade erzeugten PAR/DAT Files des eben erzeugten PT löschen bzw. die ALLGM.PAR/DAT Dateien entsprechend umbenennen. Also das hier:
ALLGEM.PAR -> GUPP0042.PAR
ALLGEM.DAT -> GUPP0042.DAT
Die PAR/DAT und PTH Dateien des CD-Gruppen-Programmteils in ALLGM.PAR/DAT/PTH umbenennen.
Maus hochfahren
Im öffentlichen-PT sollten jetzt die Programme von der CD zu finden sein.
Die Programme aus dem alten öffentlichen PT liegen ja im Programmteil Dummy. Um die jetzt in den öffentlichn zu bekommen, muß man jetzt die nur noch verschieben. Hört sich zwar nach viel Arbeit an, geht aber recht schnell. Außerdem werden dann die Dupes auch gleich aussortiert.
Keine Panik, wenn man Files von der CD-löschen will. Wenn man das per Programmteil James macht, wird automatisch erkannt, das die Files auf CD liegen und es wird nur im PAR/DAT File ein entsprechender Eintrag vorgenommen. In der Maus sollte das auch gehen, nur kommt dann auch immer eine Fehlermeldung 'Kann das File nicht löschen', die man extra wegdrücken muß.
Nun sollte alles prima funktionieren
ACHTUNG Wenn man mit irgendeinem Programm in der die Filelisten in der Gruppe Programme postet, sollte man unbedingt kontrollieren, was James da postet und eventuell auch löschen. Denn sonst postet James einen riesen Berg an Mails.
Man kann keinen Gruppen-PT anlegen ohne gleichzeitig eine entsprechende Gruppe zu haben.
Dazu gibt es die Variablen:
Die .*. Variablen legen den geringsten Userlevel für die Programmteile fest. Allen anderen Programmteildefinitionen können nur den gleichen oder ein höheren Userlevel haben. Wenn es also Gäste erlaubt sein soll im persönlichen PT etwas uploaden, muß folgendes eingestellt werden:
ProgTeil.*.Upload := 'G'
ProgTeil.P.Upload := 'G'
ACHTUNG Auch wenn mit diesen Flags ein Gästeupload in den Gruppen-PT erlaubt ist, kann man noch mit den Gruppenflags den Zugang regeln. Wenn es also Gäste in einem Gruppen-PT erlaubt sein soll etwas downzuloaden, muß auch das 'Sogar-Gäste' Flag gesetzt sein. Andersrum gilt es auch. Wenn User komplett der Zugang zu ein Programmteil verwehrt werden soll, muß das mit den Gruppenflags passieren. Nochmal hoffentlich etwas klarer: Der Zugang zu den Gruppen-PT wird über die Gruppenflags geregelt und nicht mit den oben genannten Variablen.
Wenn andererseits Gästen der Upload in Gruppen-PT nicht erlaubt sein soll, müssen die Gruppenflags so aussehen: Öffentlich, Sogargäste und Paywrite.
ACHTUNG
Mindestens bis Maus 7.95i ist es bei der Einstellung
ProgTeil.*.Upload := 'G' ProgTeil.P.Upload := 'G'Gästen möglich sich alle Programme im persönlichen PT auflisten zu lassen. Und alle heißt auch alle!
Ja das geht. Sysops können in allen Gruppen mitlesen ohne einzeln als Mitglied eingetragen zu sein.
Es gibt auch noch den Effekt, daß User, die in einer Gruppe mitlesen, die irgendwann den Status geheim bekommt, nicht ausgetragen werden, also noch mitlesen können, obwohl sie keine Mitgliedschaft besitzen.
Wenn während des Uploades ein Carrier Lost auftritt, bleibt ein File im UploadDir liegen. Das kann einmal ein komplettes Archive sein (wenn der Carrier Lost erst bei der Eingabe der Beschreibung erfolgte) oder auch nur ein Schrottfile sein. Das hat zur Folge, das der User, bei richtiger Einstellung des Z-Modems der Maus (dem Protokoll wird nicht erlaubt, Files zu überschreiben), das File nicht nochmal unter den gleichen Namen uploaden kann.
Abhilfe:
PutzUploadDirs auf TRUE und der Mausputz löscht die Uploadverzeichnisse, so das zumindest am nächsten Tag wieder alles klappen sollte.
Die Maus erlaubt eigenltich alle Kombinationen von Gruppenflags. Es werden nur folgende Plausibilitätsprüfungen durchgeführt:
Wenn W, K, S, D oder P gesetzt sind, muß auch O gesetzt sein.
Wenn G gesetzt ist, darf O nicht gesetzt sein.
Wenn G, R oder Y gesetzt sind, darf W nicht gesetzt sein.
Wenn $ oder R gesetzt sind, darf Y nicht gesetzt sein.
Wenn Y gesetzt ist, darf W nicht gesetzt sein.
Wenn ein normaler User Programmteilwart ist, ist folgendes zu beachten
ohne weiter Einstellungen kann man mit dem Status Programmteilwart nur im öffentlichen Programmteil etwas löschen. In Gruppen-Programmteilen klappt das nicht.
um in Gruppenprogrammteilen etwas löschen zu können, muß der User Gruppenchef sein.
Von: Marcus Schmidke @ BM (Fr, 14.05.93 01:08)
Hi.
Falls Stefan noch das eben auf dem Maustreff ausgearbeitete Mausgruppenflagkreuzworträtsel posten sollte, hier gleich meine Lösung dazu. Es war dank des Makrointerpreters ein Leichtes, die 32 Testgruppeneinzurichten, und dann brauchte ich eigentlich nur noch ITGs zu vergleichen und ein wenig zu testen, um die Lösungen zu finden.
Also, betrachtet wurden die Flags O, W, S, K und R - in der Hoffnung, daß P und G eindeutig sind (wer weiß, wer weiß...)
Hier das Ergebnis:
O=0: | User muß Mitglied sein, um zu lesen. |
O=1: | User darf lesen.O=0 macht nur Sinn bei K=0.
|
W=0: | User muß Chef fragen, um zu schreiben. |
W=1: | User darf schreiben. Das W-Flag hat bei R=1 keine Bedeutung. Die
MAUS weist darauf hin, daß W=1 bei O=0 wenig sinnvollste: es
kann jeder User schreiben, aber nur Mitglieder können lesen.
|
S=0: | Gäste dürfen die Gruppe nicht lesen.S=1: Gäste dürfen die Gruppe lesen. |
S=1 | macht bei O=0 keinen Sinn, da Gäste nicht Mitglieder werden
können. Die MAUS weist darauf hin. Gäste dürfen
grundsätzlich nicht schreiben, außer in die
GruppeOEFFENTLICH.
|
K=0: | Es ist dem Chef möglich, in der Gruppenverwaltung Mitglieder ein-und auszutragen. |
K=1: | Es ist nicht möglich, Mitglieder ein- oder auszutragen.K=1
macht bei O=0 wenig Sinn, da dann zwar Mitgliedschaft verlangt wird,
niemand aber Mitglieder eintragen kann.
|
R=0: | Die Gruppe ist nicht Readonly. |
R=1: | Es darf nur der Chef in die Gruppe schreiben, unabhängig
vonsonstigen Einstellungen.
Nicht getestet, aber auf dem Maustreff übereinstimmend vermutet:
|
P=0: | Alle Flags wirken wie angegeben. |
P=1: | Jede Form des Zugriffs ist *zusätzlich* noch an einen $
gebunden.
|
G=0: | Die Gruppe erscheint in der Gruppenliste. |
G=1: | Die Gruppe erscheint nur bei Mitgliedern in der Gruppenliste.
|
Y=0: | Alle Flags wirken wie angegeben. |
Y=1: | Jeder Zahler zählt automatisch wie ein Mitglied |
Als Beispiel noch meine Antwort auf die auf dem Treff häufigst gestellte Frage: Was ist der Unterschied zwischen OW und OWK?
Antwort: Von den Zugriffsrechten sind beide Gruppen identisch. Nur darf der Chef der ersten Gruppe noch nutzloserweise in der Mitgliederliste rumfummeln, während der der zweiten das nicht darf.
Komisch, jetzt, wo ich es probiert habe, ist eigentlich alles völlig klar, aber auf dem Treff war wirklich niemand sicher. Der Knackpunkt ist wohl:
K hat *keinerlei* Auswirkung auf die Zugriffsrechte für die Gruppe.
R ist stärker als W.
Gäste dürfen grundsätzlich nicht schreiben.
Tschö, Marcus.
Wenn ein User mal alle in der Maus verfügbaren Gruppen bestellt hat, kann man ihm helfen, indem man im Sysop-Menü bei den Benutzerdaten mit *-sämtliche Gruppen für ihn deaktiviert. Per Tausch geht das bisher (7.95i) noch nicht.
Das wird über die Variable GrpRenExpire festgelegt.
Nachdem das CD-ROM erfolgreich in die Maus eingebaut ist und sich auch unter dem normalen Betriebssystem ansprechen läßt, kommt der nett Teil der Arbeit.
Vorsicht Falle! Es muß unbedingt ProgTeilDatPath benutzt werden. Sonst müßte man die Steuerdateien für den Programmteil mit auf die CD packen. Nur trägt die Maus dort auch die Uploads ein... Also ersteinmal das Kapitel durchlesen.
Zuerst muß man die Beschreibungsdateien für die CD erzeugen, die man in die Maus einbinden will. Hilfreich ist dabei z.B. das Programm Maus CD CONTROLER, das CDs komplett nach Beschreibungsdateien durchsuchen kann und dann die entsprechenden Steuerdateien erzeugt.
Nun in der Maus den Gruppen-PT anlegen und unter Sysop-Funktionen, Gruppenverwaltung, Numerische Liste die Nummer der Gruppe feststellen.
Die Steuerdateien in GRUPxxxx.DAT und GRUPxxxx.PAR umbenenen und in das entsprechende Verzeichnis kopieren. Dabei können die beiden leeren alten Dateien überschrieben werden.
Wenn Alle Dateien auf der CD in einem Verzeichnis liegen, mußt man nur noch im m7com <Gruppenname>.GruppPath auf den richtigen Path setzen und fertig
Wenn die Dateien in verschiedenen Verzeichnissen auf der CD liegen, mußt du noch ein GRUPxxxx.PTH File erzeugen. Dort steht für jedes File drin, in welchen Verzeichnis es liegt. Erzeugen kannst du dieses PTH File z.B. mit CDPTH. Die erzeugte Datei muß dann natürlich auch GRUPxxxx.PTH heißen und gehört in das gleiche Verzeichnis wie die PAR/DAT Dateien. Die Variable Gruppenname.CD spielt bei der ganze Sache keine Rolle.
Sinnvoll ist es auch, wenn der Gruppen-PT readonly ist. Dann gibt es keine Probleme, wenn mal jemand etwas uploaden will.
Von: Frithard Meyer-Zu-Uptrup @ S4 (Fr, 05.01.96 23:01) Hi,
wie sperre ich den Programmteil völlig, z.B. um per MC über dasNetz zu importieren? Bei LoginProgX:='S' hat sich eben ein Programmteilwart eingeloggt und munter gesaugt ... Progteil.an:=FALSE: führt zu einem 216er der MAUS.
Von: Frithard Meyer-Zu-Uptrup @ S4 (Fr, 05.01.96 23:10)
man kopiert ein MPROG.DAT in ein neues Verzeichnis und setzt ProgteilDatPath darauf. Na ja ...
fritz
Nachtrag
MAUS 7.95i Programmteil V 35
KonfigVariable ProgTeil.an geht jetzt, mit FALSE läßt sich also der ganze Programmteil lahmlegen um z.B. mit dem MC zu importieren. Damit man den Programmteil über Netzwerk / von Programmen aus sperren kann wird ferner in MausPath die Datei 'PROGTEIL.AUS' abgefragt - existiert sie, ist der Programmteil ebenfalls gesperrt. Beim Userhinweis bei gesperrtem Programmteil wird zwischen temporär gesperrtem Programmteil: ('Der Programmteil ist momentan gesperrt - Sorry' und kaputtem Programmteil ('Der Programmteil ist zur Zeit aus technischen Gründen nicht zugänglich - Sorry') unterschieden.
Normalerweise legt die Maus die Steuerdaten (Beschreibung, Uploaden usw) zu den einzelnen Gruppenprogrammteilen in den gleichen Pfad wie die Programme ab. Wenn man allerdings ProgTeilDatPath gesetzt hat, liegen alle Steuerdateien in einem Pfad. Umstellen kann man mit convpt.arj von Fritz.
Erlebnisbericht von Björn Oste DO
Die sehr kurze (!) Anleitung gelesen, SETPTDAT.EXE gestartet, ProgTeilDatpathnach Aufforderung eingegeben und fertig wars! Hat sogar den ProgTeilDatpath in die m7com.cfg reingeschrieben. Ausschnitt aus der Anleitung: "Das Anlegen des Verzeichnisses, setzen der Variable in M7COM.CFG und kopieren der Files erledigt SETPTDAT. Im Mausverzeichnis wird dabei der Batch DEL_OLD.BAT erzeugt, mit dem man wenn alles o.k. ist später die alten Steuerdateien löschen kann."
Folgende Event-Zeiten sind für die Maus wichtig:
EventXXVonZeit
EventXXBisZeit
EventXXWurfZeit
Die EventXXVonZeit gibt an, wann der Event gestartet werden soll. Die
EventXXWurfZeit gibt an, wann normalerweise ein User aus der Box gekickt
wird. Und die EventXXBisZeit gibt an, bis wann der Event doch noch
ausgeführt werden soll. Beispiel: Der MausPutz läuft als eigener
Event normalerweise um 10. Ein User ruft um 9:50 an, tauscht und blockiert
die Box durch eine schlechter werdende Leitung 30 Minuten lang. Um 10:20
ist die Box wieder frei. Nun ist es sinnvoll, den Event doch noch
auszuführen. Deshalb BisZeit 12 Uhr oder so. Andereseits macht es
keinen Sinn, für das MausNetz /1 z.B. eine BisZeit von 8 Uhr
anzugeben. Das hat ja für jedes Level eigene von-Bis Zeiten und macht
auserhalb dieser Zeiten nix.
Diese Variablen:
EventXXHinweis
EventXXDauer
sind für die Anzeige in den Loginzeit für die gedacht und nur Hinweise. EventXXDauer bestimmt also nicht die Dauer des Events sondern soll den User nur einen Hinweis geben, das der Event ungefähr so lange dauert und man deshalb in den nächsten xx Minuten nicht mehr anrufen muß.
Von : Jörg Stattaus @ AC (Fr, 27.03.92 10:01)
MS> Ich denke, es gibt einen Befehl, der lädt automatisch ein
MS> weiteres Text-Cfg-File dazu??
Marco, das ist wirklich das Beste für die
Config-File-Änderer! Warum bin ich da nicht selber drauf gekommen?
ConfigFile := 'BLABLUBB.CFG';
weitere Files mit Komma getrennt im ` dahinter
irgendwo im m7com.cfg liest am Ende das BLABLUBB.CFG ein. Variablen,
die noch einmal definiert werden, überschreiben die erste Definition.
Nested includ essind nicht möglich.
Ihr müßt dann per Event also nur dieses zweite z.B. LOGIN.CFG auswechseln.
Gruß Jörg
Wenn ExternMenue := 'TRUE' steht, wird für externe Prgs. ein eigenes Menü aufgebaut, das mit 'x' vom Hauptmenü aus erreicht werden kann. Extern1.Acc bestimmmt den Zugriffslevel für den 1. Menüpunkt usw. Im einzelnen gilt folgendes:
0: | alle, auch Gäste |
1: | ab User |
2: | ab Zahler |
3: | ab Sysop |
Mit ExternMenue das Menü überhaupt ersteinmal aktivieren und gegebenenfalls über Extern1.Acc einen Benutzerlevel festlegen. Mit Extern1.Name wird der Name festgelegt, unter dem der Eintrag im externen Menü der Maus erscheint. In Klammern wird der Buchstabe angegeben, unter dem das Programm in Extern.bat ausgewählt wird. Extern.bat muß im Batchpath liegen und dort wird dann das entsprechende Programm aufgerufen. Am besten mal ein Beispiel dazu:
In der m7com steht folgendes:
;--------------------Externe Programme- ExternMenue := TRUE; [TRUE] Extern1.Name := '(M)aus B Service'; [''] Extern1.Acc := 2; [1] ; Extern1.Event := ; [0]
Das extern.bat sieht so aus:
if "%1"=="M" goto service goto trente :service c: cd \maus service.exe goto trente :trente
Mit 'M' kann man also aus Zahler das externe Programm Service aufrufen.
Siehe auch das Kapitel über Benutzer-Levels
Die Maus startet die Events nur einmal am Tag automatisch. Sie merkt sich auch, wenn ein Event mal per Hand vorzeitig aufgerufen wird und startet diesen dann nicht nocheinmal. Wenn man also tagsüber den Abendnetz Event zum testen aufruft, läuft der Abends nicht mehr automatisch an.
Wenn man per CallCheck Events starten läßt (z.B. mit ItsMyTime alle zwei Stunden), spielt das aber keine Rolle, da dann die Events nicht von der Maus über die Eventzeiten gestartet werden sondern über den Errorlevel.
Spezielle Fragen zum Mausbetrieb unter OS/2
Da der ARJ unter OS/2 nicht mit der I/O-Redirection zurechtkommt, muß die entsprechende Variable PackerX.ShowOutput auf FALSE gesetzt werden.
Hier mal die Einstellungen aus WHV.
Wir könnten ja mal so eine Beispielkonfiguration erstellen. Mit Hinweisen, wo optimiert werden kann, die Fußangeln liegen und was man besser sein lassen sollte.
Hier mal meine Einstellungen:
DPMI-MAUS mit 16MB Speicher und einem 486er unter Warp Connect mit SIO V1.53, CFOS 205 und CAPI 302.
CONFIG.SYS Ein paar Einträge: IFS=C:\OS2\HPFS.IFS /CACHE:2048 /CRECL:4 /AUTOCHECK:CD Diskcache wird nur für FAT benötigt nimmt also nur unnötig Speicher weg. Hier läuft alles auf HPFS und sehr stabil. :-) REM DISKCACHE=D,LW ----------------------------------------------------------------- REM Autoexec.bat nur für die MAUS PROMPT $p$g PATH=C:\OS2;C:\OS2\MDOS;C:\;C:\UTIL;C:\MAUS; C:\MAUS\NET;C:\4DOS;C:\MAUS\MCDC LOADHIGH APPEND C:\OS2;C:\OS2\SYSTEM SET COMSPEC=C:\4DOS55\4DOS.COM SET MAUSPATH=C:\MAUS\ SET DSZLOG=C:\MAUS\DSZ.LOG SET TMP=C:\ C:\CAPI\CAPIINT.COM C:\CFOS\CFOS -C2 -JC i MAUS ------------------------------------------------------------------ Ein Batchfile für den AUTOSTART beim booten damit SIO initialisiert wird: SIOINIT.CMD ----------------------- C: cd \SIO su 2 LOCK 115200 ----------------------- Meine Einstellungen für die MAUS.BAT: i=DOS-MAUS - Einstellungen p=DOS_AUTOEXEC v=C:\AUTOMaus.BAT p=DOS_BACKGROUND_EXECUTION v=1 ON p=DOS_DEVICE v=C:\SIO\VX00.SYS p=DOS_FILES v=40 p=DOS_HIGH v=1 ON p=DOS_SHELL v=C:\4DOS55\4DOS.COM C:\4DOS55 p=DOS_UMB v=1 ON p=DPMI_DOS_API v=ENABLED p=DPMI_MEMORY_LIMIT v=2 p=EMS_FRAME_LOCATION v=NONE p=HW_ROM_TO_RAM v=1 ON *Von wegen dem Timing* p=HW_TIMER v=1 ON p=IDLE_SECONDS v=5 p=IDLE_SENSITIVITY v=100 *Wichtig für die ISDN Karte* p=MEM_EXCLUDE_REGIONS v=D0000-D8FFF p=MEM_INCLUDE_REGIONS v= Reicht meiner Meinung nach völlig. Sonst blockiert die MAUS den Rechner und das Netzwerk. p=SESSION_PRIORITY v=2 Vom SIO habe ich die Voreinstellungen belassen. p=SIO_Allow_Access_COM1 v=1 ON p=SIO_Allow_Access_COM2 v=1 ON p=SIO_Allow_Access_COM3 v=1 ON p=SIO_Allow_Access_COM4 v=1 ON p=SIO_Idle_Sensitivity v=100 p=SIO_Mode_DTR v=No Change at OPEN or CLOSE p=SIO_Mode_FIFO_Load_Count v=16 p=SIO_Mode_IDSR v=Ignore DSR During Receive p=SIO_Mode_OCTS v=HandShake Signal, as in RTS/CTS p=SIO_Mode_ODSR v=Ignore DSR During Transmit p=SIO_Mode_RTS v=HandShake Signal, as in RTS/CTS p=SIO_Mode_XON/XOFF v=No XON/XOFF flow control by SIO p=SIO_Screen_Sync_Kludge v=0 OFF p=SIO_Share_Access_With_OS/2 v=1 ON p=SIO_Virtualize_16550A v=1 ON p=SIO_Virtualize_COM_Ports v=1 ON p=VIDEO_8514A_XGA_IOTRAP v=0 OFF p=VIDEO_FASTPASTE v=0 OFF p=VIDEO_MODE_RESTRICTION v=NONE p=VIDEO_ONDEMAND_MEMORY v=1 ON p=VIDEO_RETRACE_EMULATION v=0 OFF p=VIDEO_ROM_EMULATION v=1 ON p=VIDEO_SWITCH_NOTIFICATION v=0 OFF p=VIDEO_WINDOW_REFRESH v=1 p=XMS_HANDLES v=32 p=XMS_MEMORY_LIMIT v=2048 p=XMS_MINIMUM_HMA v=0
Wenn man unter OS2 einen ISDN-Port benutzt, muß man unbedingt ModemRedirect für diesen Port auf FALSE setzten. Folgende Effekte treten auf:
Von: Thomas Morgenthaler @ WHV (Fr, 10.05.96 10:18)
CG>Was für Fehler treten ohne auf?
Nur einer. Es gehen keine Daten verloren, noch stürzt das System ab. Nur der User wundert sich warum sein Up-/Download nicht klappt. Ob die Verbindung sofort gecancelt wird oder der User abbrechen muß weiß ich nicht.
Der Task wird von OS/2 angehalten. Du kannst den Task ohne Probleme von der Oberfläche kicken und die MAUS neu starten. Bei dem nächsten ISDN Tauscher, wenn die MAUS wieder auf einen nicht existierenden COM - Port zugreifen möchte. Das selbe Spiel. Für OS/2 ist die MAUS dann ein wildgewordenes Progi, das nur Mist bauen möchte und um die Systemsicherheit nicht zu gefärden wird ihr der Saft abgedreht.
Fehlermeldung: Ein Programm versuchte auf einen nicht existierenden COM Port zuzugreifen. Die Verarbeitung wurde angehalten, so in der Richtung.
Von: Thomas Morgenthaler @ WHV (Mi, 07.02.96 20:30)
Moin
Wenn PDZM bei einem ISDN Tausch aufgerufen wird. Möchte das Protokoll immer eine Ausgabe auf einem COM Port machen. Deshalb kloppt OS/2 der MAUS tüchtig einen auf die Schnauze. D.h. die MAUS steht. Wie verhindere ich das? Gruß T.M.
Von: Gereon Steffens @ K2 (Mo, 12.02.96 20:46)
>Wie verhindere ich das?
Erst mit RTFM und dann mit Modem.RedirectOK := FALSE. Gereon
ACHTUNG Wenn zwei Mäuse unter OS/2 auf einem Rechner laufen unbedingt bei einer Maus die automatische Umstellung abschalten. Denn sonst stellt die Maus um zwei Stunden die Zeit um.
Siehe auch Sommerzeit/Winterzeit?? und SommerzeitUpdate
Der Mausputz ist das Programm, das die Mails in der Messagebase als gelöscht markiert und auch löscht, User den 'gelöscht' Status verpaßt (die User aber nicht löscht!), den persönlichen Programmteil aufräumt und in den anderen Programmteilen auch aufräumt (was macht der da?). Außerdem legt es ein neues MCALL.LOG an und sichert die alten.
Bei jedem normalen Aufruf (also ohne Parameter) werden nur die Mails als gelöscht markiert, aber nicht aus der Messagebase entfernt. Genauso werden die User nicht als gelöscht markiert (Status gelöscht im Benutzerdateneditor)
Die als gelöscht markierten Mails werden normalerweise in der Nacht von Montag zu Dienstag aus der Messagebase entfernt. Das kann aber auch vorher passieren, wenn entweder ForceAllwaysProgPutz True ist, oder die Werte von KrunchMax bzw. KrunchProzent überschritten werden. Das alles schreibt der Mausputz aber in das neue MCALL.LOG, das er anlegt.
Die User werden entweder bei dem krunchen der Messagebase als gelöscht markiert (also in der Nacht von Montag zu Dienstag) oder beim Parameteraufruf /B. Für die Variableneinstellungen siehe das Kapitel über das User löschen
Wenn man die als gelöscht markierten User wirklich aus der Datei MUSER.DAT löschen will, muß man das Programm KRUNUSER benutzten. Dieses entfernt wirklich die entsprechenden Datensätze.
Die Mausputzvariablen kann man entweder im m7com.cfg mit angeben oder man legt ein MAUSPUTZ.CFG an, in die man dann alle wichtigen Variablen kopiert. Das ist aber nicht zu empfehlen, dann man bei jeder Pfad-Änderung immer zwei Files pflegen muß.
MausPutz-Parameter:
/V | geschwätzig |
/P | PMs krunchen |
/A | AMs krunchen |
/B | User löschen |
/L | NICHT löschen |
/F | Krunch forcieren |
/M | Programmteil nicht putzen |
/? | Hilfe |
MSGID kontrolliert die Message-Ids oder kann auch IDs in die Messagebase setzte (z.B. nach einen Messagebasecrash). Einmal ohne Parameter aufrufen, und man sieht die Aufrufbeispiele.
MsgId 1.10 - Überprüfung der MsgIds
AC | zeigt summarisch Ids aus AC |
LIST AC | listet alle Ids aus AC auf |
ALL | zeigt summarisch Ids aller Mäuse |
SET 12345 | trägt eine Msg mit dieser Id ein |
/P .. | alle obigen Kommandos für PMs |
Nachdem der Mausputz eine Gruppe geputzt hat, prüft er, wie alt
die älteste Nachricht in der Gruppe ist. Wenn diese Nachricht von
heute ist, bekommt der WoSysop folgende Meldung:
Von : MausPutz @ B (So, 31.12.95 05:38)
An : Sysop @ B
05:10 >>> Check für zu knappe Putzgrenzen:
05:10 Zu knapp: Große.Gruppe
In dem Fall haben Deine User ein echtes Problem, wenn sie Nachrichten
von gestern kommentieren wollen, weil diese Nachrichten nicht mehr in der
Messagebase sind. Weiterhin ist es denkbar, daß Nachrichten, die kurz
vorher mit dem Netz angekommen sind, auch schon gelöscht wurden.
Abhilfe: An den entsprechenden Variablen in der M7COM.CFG drehen, damit der
Mausputz in der Große.Gruppe genügend Nachrichten vorhält.
Aktiviert wird der Check über die Variable AufbewahrungsCheck
das Programm KRUNUSER entfernt die vom MausPutz als gelöscht markierten User aus der Datei MUSER.DAT. Vor jeden KRUNUSER Aufruf werden von den zu verändernden Dateien BackUps angelegt.
ACHTUNG!!! Nach erfolgreichen Lauf des KRUNUSER am besten die Datei 'Recover.BAT' im Backupverzeichnis umbenennen. Sonst kommt man irgendwann später ausversehen mal auf die Datei, der Batch startet und kopiert die alten User und Messagebasedaten zurück. Danach kann man die Messagebase (sowohl PM als auch ÖM) wegschmeisen und hat den Userstand vom letzten KRUNUSER lauf.
Die Defaultwerte für das löschen in den Gruppen werden durch die folgenden Variablen vorgegeben. Wenn eins von den Kriterien zutrifft, wird in der Gruppe gelöscht:
Für einzelne Gruppen gibt man die Werte dann so an:
MsgOut_SYSOPS := 'T 30 Z 300 K 1000'; ['']
Für die PMs sind die Variablen folgende:
MsgOutOldPM | nach soviel Tagen werden Mails, die den Status gelesen, beantwortet oder im Maustausch haben gelöscht. |
MsgOutActivePM | das gleiche für nicht gelesene oder zurückgestellte Mails |
BEinmalKA := 5;
BEinmalKZ := 5;
BEinmalLZ := 60;
BNeuLZ := 180;
BAltKA := 26;
BAltKZ := 32767;
BAltLZ := 182;
"B" wie Benutzer.
"Einmal" sollen Benutzer sein, die "nur einmal anrufen" - tatsächlich ist die Bedingung etwas komplizierter (<KA Anrufe in <KZ Tagen). "Neu" ist ein Benutzer danach.
Dann wird er möglicherweise Zahler und ist vor dem Löschen sicher. Und schließlich "Alt".
"KA" - Anzahl der (A)nrufe, die die Grenze für diese (K)lasse darstellen.
"KZ" - (Z)eit (in Tagen, erster bis letzter Anruf), die die Grenze für diese(K)lasse darstellt.
"LZ" - (Z)eit (in Tagen, nach dem letzten Anruf), nach der ge(L)öscht wird.
Sonderfälle: ex-Zahler sind immer Altbenutzer. SysOps werden nur gemahnt, nicht gelöscht.
Nachfrage:
Altuser wären ja in obigem Beispiel User, die innerhalb der letzten 32767 Tagen max. 25x angerufen hätten - was sind sie danach?
oder andersherum gefragt:
Ich will, dass Ex-zahler frühestens nach einem Jahr geloescht werden, wie mache ich das?
BaltLZ:=365?
BEinmalKA := ; [3]
BEinmalKZ := ; [3]
BEinmalLZ := ; [30]
innerhalb von 2 tagen hoechstens 2 anrufe -> kill nach 30 tagen?
; BNeuLZ := ; [90]
mehr als 3 Anrufe -> kill nach 90 Tagen?
ciao, udo
Und dann noch das passende Stückchen Source-Code
Von : Gereon Steffens @ K2 (Do, 04.05.95 18:25) RId : <199505040135.a25057@wi.maus.de> >Gereon, kannst Du der Vollständigkeit halber noch die Statements mit >den anderen vier Konfig-Variablen (BEinmalKA, -KZ, -LZ und BNeuLZ) >posten? Klar. Hier der komplette Ausschnitt: if not BP^.paid then begin Write(Scr, BP^.Nummer: 7, #8#8#8#8#8#8#8); KeinAnruf := today - BP^.LastCallD; TageOnline := BP^.LastCallD - BP^.LogInDate + 1; if (BP^.PayDate > 0) { hatte mal gezahlt } or (BP^.CallCount >= BAltKA) or (TageOnline >= BAltKZ) then ex := KeinAnruf > BAltLZ else if (BP^.CallCount < BEinmalKA) or (TageOnline < BEinmalKZ) then ex := KeinAnruf > BEinmalLZ else ex := KeinAnruf > BNeuLZ; if ex then begin { Lösch den User } end; end; Gereon
Der XLate-Fehler besagt, daß eine Kommentarverkettung von Mail B auf Mail A beim Msg-Krunchen nicht umgemapped werden konnte, da die Mail A nicht in der Tabelle vorkommt.
Gruß Jörg
Von : Jörg Stattaus @ AC (Do, 22.10.92 16:08)
FM> 09:19 <XLate: 12446 fehlt in 2888[+]>
FM> 09:23 <XLate: 12510 fehlt in 4308[+]>
Bei Msg neu #2888 fehlt die Msg alt #12466, die eigentlich ein
Kommentar [+] auf 2888 sein sollte. Und das mit dem [+] ist komisch! Ab und
zu gibt's mal den Fall, daß eine [-]-Verkettung fehlt - keine Ahnung,
warum. Aber in dieser Richtung ist das recht selten. Hat eure MsgBase
irgendwas abbekommen?
Gruß Jörg
Von : Kai Henningsen @ MS (Di, 05.01.93 21:20) Hi Marcus,
MS> <XLate: 229 fehlt in 1270[-]>
MS>
MS> Sagt die mir irgendwas?
Interner Konsistenz-Check. This should not happen, passiert aber aus
bisher ungeklärten Gründen immer wieder :-( Wenn man viele davon
bekommt, sollte man aber prüfen, ob die Msgbase noch in Ordnung ist.
Was die Meldung aussagt: Eine Mitteilung, die nach dem Krunchen (oder war's
vorher? egal) die Nummer 1270 hat, hatte einen Verweis auf Nummer 229, und
zwar war's die "-"-Verkettung. 229 war aber bereits gelöscht,
daher hätte die Verkettung ebenfalls gelöscht sein sollen. MfG
Kai
>03:13 <XLate: 17068 fehlt in 41[*]
[*] steht für "letzter Kommentar auf diese Msg".
Hier geht es rund um das MausNet, Aufrufparameter, Zeiten usw.
ohne Parameter | Nächtliches MausNet |
/1 | Der erste Teil des nächtlichen MausNet. Danach kann man, wenn genug Zeit bis zum Anruf von oben ist, z.B. den Mausputz, das Backup etc laufen lassen. |
/2 | Zweite Teil des MausNet. Warten auf den Anruf von oben und ruft danach die Boxen unter einem an. |
/c | Verbindungsübernahme von der MAUS, wenn das MausNet der anrufenden Box auf der eigenen MAUS landet, z.B. bei einem manuellen Netz mit mausnet /m. Ist defaultmäßig in der Maus auf Event70 definiert. Sollte also auch so in MAUS.BAT drin stehen. |
/e | Erwarte einen Anruf |
/e:HB | Erwarte Anruf aus HB (packt nur für HB) |
/m | Mache Anruf nach oben |
/p:2 | Es wird nur auf den angegebenen Port gehört |
AC | Mache Anruf bei MAUS AC |
Export? | Erlaubt die Eingabe, ab welcher Msg-ID die lokalen! Allg-/Pers-Msgs exportiert werden sollen. Sinn z.B.: mnac-hb-.* kaputtgegangen; jetzt noch einmal ab gestern exportieren. Bitte VORSICHT! Es wird auf eine Tastatureingabe gewartet. Also nicht per Batch aufrufen. |
K2,MS | Mache Anruf bei K2 und MS (Anruffolge nach Maus-Nr) |
Zusatzparameter (immer als 2./3. Parameter nach /e oder K2):
.. /x | Nicht exportieren MausNet |
.. /t:21:00 | TimeOut um 21:00 (Default jetzt +30 Min.) Beispiel: MausNet HB /t:20:13 MausNet AC3 /x /t:20:20 MausNet K2,MS /x /t:20:38 |
Bei MausNet /1 oder /2 werden keine weiteren Parameter ausgewertet.
ACHTUNG Der ProgFix kommt nicht oder nur schlecht mit langen Gruppennamen zurecht. Es können diverse Fehler auftreten (von garkeiner Aktion bis zum kompletten löschen der Maus!!! Besser ist es JAZZ von Fritz zu benutzen.
ProgFix-Parameter:
P | persönlichen Programmteil selektieren Default: aus |
O | öffentlichen Programmteil selektieren Default: aus |
G | alle Gruppenprogrammteile selektieren Default: aus |
? | ausführliche Hilfe |
U | UserdatenCheck |
C | Sicherheitscheck und Statusmeldungen am Anfang Default: aus |
X | CD-Gruppenprogrammteil selektieren (wenn vorhanden) Default: an |
R | Renumber (Gelöschte Files aus Liste löschen) Default: aus |
S | Resort (Beschreibungen bearbeiten) Default: an |
F | Filetest (Filedaten überprüfen/anpassen) Default: an |
K | Filekill (überflüssige Files entsorgen) Default: an |
A | Archivcheck (überprüft alle veränderten und neuen) Default: aus |
Z | Zuordnung der Uploader neu |
D | DupeCheck ö <-> ö, ö <-> Gruppen |
+ | Einschalten oder |
- | Ausschalten ohne (+/-) = Toggeln Also z.B.: /QTOSFK ist das gleiche wie /Q+T+O+S-F-K- |
Das CNF enthält die Daten, die das MausNet über eine Box wissen muß. Das Format ist an das Infofile ITB angelehnt.
Beschreibung der Zeilen:
; | Ein Kommentar ; CNF der AC4 |
* | Dem Stern folgt das Boxkürzel. Diese Zeile muß die erste Zeile im .CNF sein, die kein Kommentar ist! *AC4 Diese Zeile tritt genau ein mal auf. |
# | Die Netznummer der Box (dezimal). Eine Fremdbox bekommt ein - vorangestellt (der Nummer, nicht etwa dem Doppelkreuz). Beispiel, MAUS: #112 Beispiel, Fremdbox: #-22 Diese Zeile tritt genau ein mal auf. |
N | Der Name der Box, maximal 30 Zeichen lang. Beispiel: NQUARK Duisburg 3 NQUARK Köln 6 Diese Zeile tritt genau ein mal auf. |
T |
|
t | Telefonnummer der Box im internationalen Format. Fehlt diese Zeile, so soll die Box während des Netzes nicht angerufen werden (Fremdboxen werden sowieso nicht angerufen). Ist das t klein geschrieben, ist die Telefonnummer geheim und nicht zur Weitegabe an die User bestimmt. T+49-30-1181 Diese Zeile kann mehrfach auftreten (Multiportbox). |
- | Das Kürzel der Serverbox. Entfällt, wenn die Box keine Serverbox hat. Diese Zeile tritt maximal einmal auf. -AC4 |
D |
|
Z | Primäre und zusätzliche Domains der Box. D tritt genau null oder einmal auf, Z kann mehrfach auftreten. Die primäre Domain ist die Domain, unter der Nachrichten aus der Box exportiert werden, sekundäre Domains sind alternative Adressen. Für die Domains gibt es zwei Schreibweisen, einmal die mit Punkt am Anfang (dann muß das Boxkürzel noch vor die Domain gesetzt werden, um einen gültigen Domainpart zu erzeugen), und alternativ kann man auch einen vollständigen Domainpart angeben (das sollte man aber nur tun, wenn sich der gültige Domainpart nicht aus .irgendwas und Boxkürzel zusammensetzen läßt). Beispiel: Dmausdu3.gun.de Z.maus.de Z.maus.sub.org |
G | Hier werden netzweit bekannte Gateways eingetragen. Diese Zeile kann vielfach auftreten. Das Format ist:
kiste_oder_domain gibt an, was über das Gateway zu erreichen ist. Das Format ist wie bei den Domains, siehe oben. Gatenummer ist die Nummer des Gatewayusers in der MAUS (negativ, zwischen -9 und -999 oder ähnlich). Fremdboxen können eintragen, was sie wollen, vorausgesetzt, die Nummer bleibt in dem Zahlenbereich (was passiert, wenn nicht?). (IMO ist diese Information zweckfrei). erlaubt_fuer ist eine mit Kommas getrennt Liste von Boxen und Domains, für die die Benutzung dieses Gates erlaubt ist. Ein * bedeutet, daß die Benutzung des Gates für alle erlaubt ist, ein - bedeutet, die Benutzung des Gates ist generell verboten. Im folgenden Beispiel sind drei Gates angegeben, die Benutzung des ersten ist für alle erlaubt, die des zweiten für Niemanden, und die des dritten für alle Boxen, die Mitglied der Domain .maus.de sind oder DU3 heißen: ; Gates. Format: Name,Nummer,Transport ; Name: .* ist dasselbe wie alle Top-Level-Domains ; Transport: "*"=alle, "-"=keiner, ; oder "MS,.maus.de" = MS und alle .maus.de-Mäuse G.gun.de,-11,* G.rhein.de,-11,- G.de,-12,.maus.de,DU3 |
% | Informationen im PMK2-Format, siehe PMK-Token-Format. Mehrere bis viele Zeilen. Technisch zu behandeln wie s. |
s | Informationen nur für Sysops. Mehrere Zeilen möglich. |
U | Informationen für User (der Text, der z.B. im INL steht). Mehrere Zeilen möglich. |
Ein Beispiel-CNF:
; Boxkürzel - dies muß die erste Angabe sein: *DU3 ; Netznummer (Fremdbox mit "-" davor): #-110 ; Boxname [max. 30]: NQUARK Duisburg 3 ; Telefonnummer (Muster: +49-251-77262; fehlt=nicht anrufen): T+49-203-735844 ; Kürzel der Serverbox (fehlt für Baumwurzel): -DU ; Primäre (D) und sekundäre (Z) Domains: Dmausdu3.gun.de Z.maus.de Z.maus.sub.org ; Gates. Format: Name,Nummer,Transport ; Name: .* ist dasselbe wie alle Top-Level-Domains ; Transport: "*"=alle, "-"=keiner, ; oder "MS,.maus.de" = MS und alle .maus.de-Mäuse G.gun.de,-4711,.maus.de ; SysOp-Infos: %B1 Uwe Ohse %a1 Straße Nr, PLZ Stadt, Land (Germany) %t1 Telefonnummer des Betreibers %E1 uwe@tirka.gun.de, uwe_ohse@du3.maus.de %S2 weiterer Sysop %S3 und noch ein Sysop %m1 ZyXEL-16K8 V.32bis V.32 V.22bis V.22 V.21 %f1 V42.bis %u1N Usenet %u1B Uwe Ohse %u1E uwe@tirka.gun.de %u1M uwe@tirka.gun.de %u1R das ist ein wirklich lokales Gate :-) %N QUARK Duisburg 3 %HW i486/66, 20 MB, 1-2GB %OS Linux %L 51 26 N / 06 45 E city %$ 40 DM sblahblah und wichtige sonstige Informationen. ; User-Infos: U Benutzerinformation, Zeile 1 U Benutzerinformation, Zeile 2
User werden nicht automatisch benachrichtigt, wenn PM-Massen gefiltert und nicht weitergeleitet werden?
Der Hinweis vom MausNet an den Sysop wegen der gefilterten PM-Massen bekommt generell nur der WoSysop der entsprechenden MausBox. Kein anderer wird automatisch informiert. Wenn allerdings später auf dem Transportweg nochmal PM-Massen gefiltert werden, weil sie beim ersten mal durch den MausNet-Check kamen, dann bekommt natürlich auch der entsprechende Sysop eine Mail.
Außerdem gehen gefilterte PM-Massen weiter an den Wochensysop, bekommen aber schon den Gelesen-Status, landen also nicht im Tausch. Der WoSys muß die also nicht saugen.
Im Moment gelten allen PM-Mengen über 64 KB pro User und Tag als PM-Masse. Eingestellt wird dieser Wert im MAUSNET.REQ mit der Variable PMMassenFilter. Mit der Variable PMMassenHinweis kann man auch einstellen, ab wann der Sysop einen Hinweis auf große PM-Mengen bekommen soll.
Dazu mal den Text von Jörg:
Wie bekomme ich ISDN im MausNet ans Laufen?
===========================================
Hinweise zu MausNet V.2.00, 17.08.94, js@ac
1. Installation der Kartentreiber mit CAPI und cFos
ELink-Besitzer können diesen Abschnitt überlesen.
cFos ist ein Interface zwischen Fossil-Treiber und CAPI. Für MAUS und MausNet sieht dann ISDN wie ein Modem aus. Ich gehe im folgenden von einem Modem auf COM1 aus und einem ISDN, daß wir als COM2 einbinden. Ob eine zweite serielle Schnittstelle installiert ist, interessiert nicht.
Installation im AUTOEXEC.BAT nach den kartenspezifischen Treibern mit:
lh \util\cfos i -c1 -jc
i = Installation, -c1 heißt als Fossil-Port 1 (das ist der 2. Fossilport = COM2, da Fossil die Ports von 0 an zählt), -jc macht aus der Scrollock-LED eine ISDN-CARRIER-LED. Man kann mit dem cFos auch eine existierende serielle Schnittstelle "überschreiben". Wichtig ist nur, daß erst der X00 und dann der cFos eingebunden wird.
Sinnvoll kann auch der Zusatzparameter -dd sein, der den cFos ein File CTRACE in seinem Verzeichnis anlegen läßt. Dieses File enthält den gesamten CAPI-Msg-Austausch. Aber Achtung: das File wird locker etliche 100 KB groß und ist nur nach eingehendem Studium von CAPIDOC verständlich. Wenn man also massive Probleme beim Verbindungsaufbau hat, sollte man hier reinschauen.
2. MausNet.CFG:
Dem MausNet muß gesagt werden, daß es 2 Ports unterstützen soll, wo diese liegen, wie das zweite Modem bedient wird, und welche Mäuse über welchen Port angesprochen werden sollen.
Erstmal die Modem-Konfigurationen:
; ; Modem-Parameter ; ModemPorts := 2; ; Modem1.X00Port := 0; Worldblazer Modem1.ComPort := 1 ; Modem2.X00Port := 1; ISDN Modem2.ComPort := 2
Damit sind dem MausNet 2 Modems bekannt, die auch initialisiert werden. Wenn ModemPorts nicht gesetzt ist (Default), dann gelten die alten Config-Vars ModemPort und ComPort weiter. Jetzt geht's an die modemspezifischen Kommandos. Default ist jeweils ModemBla, umkonfiguriert werden kann pro Modem Modem1.Bla und Modem2.Bla.
Modem1.Init1 := 'E0'; Modem2.Init1 := '&D1 S11=2 X1'; Statuszeile an und in Zeile 2 ; Modem1.Auflegen := 'M0 H'; Modem2.Auflegen := 'H0 &L*'; höre wieder auf alle EAZ Modem2.DialPre := 'D' Modem2.Annehmen := '&L A';nicht mehr auf die Leitung hören u. annehmen Modem2.Abheben := '&L' Modem2.Status := 'I2'; protokolliert einen Verbindungsreport ins Log Modem2.Exit := '&L'
Ohne Änderung der Inits (X1) liefert cFos einfach ein 'CONNECT' zurück. Das sollte also auch bei den Connect-Strings gesetzt sein. Und nicht 'CONNECT *' - da kommt kein Blank.
Was soll die &L-Mimik? cFos scheint ein Problem zu haben, wenn ein Anruf auf dem ISDN-Port reinkommt, aber nicht direkt beantwortet wird, da ein Modemanruf anliegt. Hinterher klappt es dann auch nicht mehr. Als Abhilfe scheint sich zu bewähren, nur dann auf ISDN-Anrufe zu hören, wenn sie wirklich angenommen werden können. Sonst wird mit &L dem CAPI gesagt, auf keine EAZ zu horchen. Auf der anderen Seite kommt dann ein NO ANSWER/CAUSE=34ba.
So, und jetzt muß noch gesagt werden, welche MAUS auf welchem Port läuft und welche Nummer sie hat:
Modem.AC := 2
Modem2.Nummer.AC := '9019020'
Default ist also jeweils Modem.XY := 1. Wenn nun eine MAUS ISDN-mäßig erreicht werden soll, dann setzt man diese Config-Var und die ISDN-Telefonnummer! Default für die Nummer ist die Angabe aus dem .EXP. Ein altes, box-spezifisches ModemDialPreAC muß in Modem1.DialPre.AC (mit 2 Punkten!) umgetauft werden. Nur so kann das MausNet, je nach Aufrufparameter entweder mit dem Modem auf Port 1 oder ISDN auf Port 2 anrufen. Kontrolliert das am besten in den ersten Dial-Angaben, die das MausNet in das Log schreibt und im MAUSNET.REQ. Diese Angaben sind sehr fehleranfällig!
Besser als mit X1 kann man mit X7 fahren. Es gibt dann ausführliche Resultcodes vom cFos, die das MausNet auch im Logfile mitprotokolliert. Dazu sollte ein Connect-String CONNECT 64000* definiert werden.
Mit X7 enthalten die NO ANSWER, NO CARRIER und BUSY Responses noch den Zusatz /CAUSE=xxxx, was alles brav im Logfile vermerkt wird. Die genaue Erklärung des Wertes xxxx liefert CFOS.DOC.
DSZ ist nicht Fossil-fähig. Deshalb brauchen wir bei der Lösung mit ISDN-CAPI und cFos ein Protokoll, daß über den Fossil läuft. Ein vernünftiges ZModem gibt es noch nicht, weswegen wir zu HS/Link gewechselt sind. HS/Link hat auch den Riesenvorteil, daß es bidirektionale Übertragung erlaubt. Dieses HS/Link sollte für jeden MausNet-ISDN-Partner im MAUSNET.CFG eingestellt werden. Dies geht über die Variable
Protokoll.AC3 := 'H' im MAUSNET.CFG @ AC und
Protokoll.AC := 'H' im MAUSNET.CFG @ AC3
Default ist hier 'Z' wie ZModem. Man kann in Zukunft auch andere Protokolle definieren. Wichtig ist, daß sie auf beiden Seiten gleich eingestellt sein müssen. Der Buchstabe wird als 5. Parameter dem ZMODEM.BAT übergeben.
3. ZMODEM.BAT:
rem %1 = Port rem %2 = sz/rz/bi rem %3 = Filename rem %4 = Output in Datei (DSZ.OUT im Nachtnet, con im man. Netz) rem %5 = Protokoll-Art (Z, H) rem %6 = Baudrate set DSZLOG=DSZ.LOG if %5==H goto HSLink rem Aus Kompatibilität zu 1.99-ISDN-Versionen noch rem diese Abfrage: if %1==2 goto HSLINK :ZMODEM dsz port %1 handshake cts %2 -m -rr %3 goto Ende :HSLINK set hsl=fhslink rem Wenn auf Modemport, dann besser HSLINK.EXE benutzen rem Im Normalfall sollte das Modem auf rem COM1 sein (bitte ggf. ändern) if %1==1 set hsl=hslink if "%2"=="bi" %hsl% -! -P%1 -E%6 -HX -S2048 %3 if "%2"=="sz" %hsl% -! -P%1 -E%6 -HX -S2048 %3 if "%2"=="rz" %hsl% -! -P%1 -E%6 -HX -S2048 :Ende if errorlevel 1 quit :Ok echo Ok > ZModem.ok
Was bedeutet es, wenn der MNConfig jeden Tag sowas meldet:
Box 101 ÖRK MAUS Örks neu im Netz
(statt Box 101 BÄH MAUS Leipzig/Taucha-1)
Man hat einfach vergessen, das EXP-File einer Maus, die aus dem MausNet ausgeschieden ist, zu löschen. Irgendwann wurde die Maus-Nummer neu vergeben und nun hast man zwei EXP auf der Platte, die beide für eine Maus Nummer 101 gelten sollen. Und so meldet dir der MNCONFIG jeden Tag die andere Maus als neu. Also einfach des EXP-File der ausgeschiedenen Maus BÄH löschen und gut is.
Ja. ZIP.BAT und ZIPX.BAT müssen die heißen, und im Net-Directory liegen. Die Parameter sind bei ZIP: %1=-a, %2=Archiv-Name, %3=Filename, bei ZIPX: %1=-o, %2=Archivname.
Beispiele:
Einfachversion
ZIP.BAT: -------- if "%2"=="F:\MAUS\NET\MNAC-AC3.ZIP" goto PKZIP c:\util\zip %1 %2 %3 goto Ende :PKZIP c:\util\pkzip %1 %2 %3 :Ende
Mit Fehlerabfragen
Einfach einen \NET\ZIP.BAT anlegen. Der wird dann genommen, da MAUSNET nur 'ZIP' exect und \NET\ ja das aktuelle Verzeichnis ist.
Minimalversion
pkzip %1 %2 %3
- Version wenn es mal Probleme beim Packen gibt (mit Test und Log)- @echo off rem 4dos! echo -------- ZIPZAP Logfile %_DATE um %_TIME -------- >>ziperr.txt echo ZIP-File: %2 >>ziperr.txt pk193 %1 %2 %3 zipx -t %2 if errorlevel 1 goto fehler echo Alles klar! >>ziperr.txt goto Ende :fehler rem Packen war nix! Dann halt mit altem ZIP versuchen ... echo Fehler beim ersten Einpacken! >>ziperr.txt dir %2 >>ziperr.txt erase %2 zipalt %1 %2 %3 zipx -t %2 if errorlevel 1 goto garnix echo Zweiter Versuch erfolgreich! >>ziperr.txt goto Ende :garnix erase %2 echo Auch das zweite Einpacken war nix! >>ziperr.txt :Ende
Wenn man für verschiedene Mäuse verschieden packen will
@echo off rem 4DOS! if "%@NAME[%2]"=="MNS3-BB-" goto ZIPNEU if "%@NAME[%2]"=="MNS3-S2-" goto ZIPALT if "%@NAME[%2]"=="MNS3-S--" goto ZIPNEU if "%@NAME[%2]"=="MNS3-BL-" goto ZIPALT :ZIPNEU pk204 %1 %2 %3 goto Ende :ZIPALT zipalt %1 %2 %3 :Ende
Problem. Man will im Nachtnetz, das eine bestimmte Box immer zuerst angerufen wird. Wie geht das?
Dazu gibt es die Variable CallOrder im MausNet.cfg. Dort kann man die optionale Anrufreihenfolge eingetragen.
Beim MausNet tritt folgender Fehler auf:
DOS-Fehler #4 bei 0004:3266 - Zu viele offene Files - I/O Error 4 [4 1
Laut Jörg sollte man schon wenn man 2 Mäuse um sich rum hat Files = 30 in CONFIG.SYS und MaxFiles := 30 in MAUSNET.CFG setzen.
Von: Frithard Meyer-Zu-Uptrup @ S3 (Di, 10.08.93 23:21)
Hi zusammen,
so, seit ein paar Stunden versuche ich hinter die Geheimnisse von NETSTAT zukommen, die Doku die ich habe führt lediglich neue Features auf. Und jeder den ich angerufen habe weiß auch nichts darüber. Ich möchte das aber gerne verstehen, darf ich das?! ;-)
Also: Die erste Ausgabe (In) verstehe ich noch, bei der Zweiten wird es für mich dann schon schwieriger:
Out Ergebnis Gebühren- Box Ok NotOk MAUS Einheiten Recs cps ---------------------------------------------- BB 65 2 0 73 215672 1979 BL 39 1 0 335 164028 1898 S 65 6 0 77 195720 1857 S2 65 1 0 72 220975 1970 WÜ 60 3 0 102 19608 1796 ---------------------------------------------- 59 3 0 659 816003 1927
Was geben denn die drei Spalten 'Ergebnis' an?
Ferner: In Würzburg steht unter IN 156 Einheiten, hier aber unter OUT nur 102,wie kann so eine große Differenz entstehen?
Jau, dann das dritte Ding, bis Recs OUT ist das auch noch klar, aber was istR/E? Und dann alle weiteren Spalten sind mir dann auch nicht so ganz klar, nur daßda irgendwas über den Anteil errechnet wird und dann der jeweiligen MAUS 'gutgeschrieben' wird, also z.B. der BB 2 Einheiten.
Telefonkosten: Box Einheiten Recs Anteil IN Erstattung IN OUT ges. IN OUT gesamt R/E % Einh Einheiten DM ---------------------------------------------------------------------- BB 29+ 73= 102 4583+ 215672= 220255 2159 2.1% 2 73- 2 16.33 BL 35+ 335= 370 941+ 164028= 164969 445 0.6% 2 335- 2 76.59 S 28+ 77= 105 7412+ 195720= 203132 1934 3.6% 4 77- 4 16.79 S2 30+ 72= 102 6049+ 220975= 227024 2225 2.7% 3 72- 3 15.87 WÜ 477+ 102= 579 232780+ 19608= 252388 435 92.2% 534 102- 534 -99.36 ---------------------------------------------------------------------- 599+ 659=1258 251765+ 816003= 1067768 1439 545 659- 545 26.22
So, und wenn ich das dann kapiert habe, dann kann man noch von MSGSTAT die Routingkosten mit reinrechnen, aber das kommt dann in der nächsten Frage- stunde, wenn es wieder heißt: Route mal mit Modemqual!
Salve fritz
PS: Falls ich's kapiere schreib ich dann mal eine Doku und für James hab ich da auch was vor ...
Von: Gereon Steffens @ K2 (Mi, 11.08.93 18:40)
>Was geben denn die drei Spalten 'Ergebnis' an?
OK=Anzahl Anrufe OK, NotOK=Anzahl Anrufe nicht OK, MAUS=Anzahl Anrufe, bei denen statt einem MAUSNET eine MAUS lief.
>In Würzburg steht unter IN 156 Einheiten, hier aber unter OUT
nur 102,
>wie kann so eine große Differenz entstehen?
Manuelle Netze verursachen nur in einer Richtung Kosten.
>aber was ist R/E?
Records pro Einheit.
>dann der jeweiligen MAUS 'gutgeschrieben' wird, also z.B. der BB 2 Einheiten
Genau, und zwar prozentual, abhängig von dem Mail-Aufkommen, das von dieser MAUS geliefert wurde.
>dann kann man noch von MSGSTAT die Routingkosten mit reinrechnen,
Richtig, und zwar Routinanteil-% vom Einheiten-Eigenanteil, also in Deinem Fall von den 545 Einheiten. Das dann durch Anzahl der Boxen unter Dir teilen. Gereon
Von: Jörg Stattaus @ AC (Do, 12.08.93 12:09)
>In Würzburg steht unter IN 156 Einheiten, hier aber unter OUT
nur 102,
>wie kann so eine große Differenz entstehen?
GS>Manuelle Netze verursachen nur in einer Richtung Kosten.
Nein, nein, auch manuelle Netze sollten sauber in den Logfiles beider Partner eingetragen werden. Ich hätte gerne die genaue Aufstellung auch der Gegenseite, wieviele Verbindungen stattgefunden haben, Fritz.
Und wenn die Verbindungszahl gleich ist, muß es mit den Einheiten pro Gespräch zusammenhängen. Da ist einmal die Frage, ob ihr die gleichen Zone und Sekunden/Einheit im netstat.cfg stehen habt. Wenn ja, müßten man die MN-*.LOG vergleichen und die Differenzen pro Tag ermitteln. S3 sagt am 01.07.93 im MN-OUT.LOG 230, WÜ im MN-IN.LOG 245 usw. Eine Differenz von 10 Sekunden ist normal, da der Angerufene vom Abheben und der Anrufer vom Carrier aus zählt. Gruß Jörg
Von: Marcus Schmidke @ BM (Do, 03.04.97 14:36) MId: 199704031436.a47961@bm.maus.de
Hi.
Die Abrechnung ist schon etwas komplizierter.
Netstat geht nur nach der einfachen Regel vor: jeder bezahlt das, was er bekommen hat. Wenn BM jede Nacht 1 MB von K2 bekommt, bezahlt BM an K2 den vollen Preis dafür. Genauer passiert folgendes:
Es wird aufgerechnet, wieviele Daten von BM nach K2 geflossen sind, und wieviele von K2 nach BM geflossen sind. Weiterhin wird berechnet, wieviele Einheiten dafür insgesamt verbraucht wurden, egal, wer die auf seiner Telefonrechnung hat.
Daraus wird berechnet, welchen Anteil dieser Einheiten BM zahlen muß und welchen Anteil von K2, und das wird miteinander verrechnet. Am Ende kommt heraus, daß BM an K2 zahlen muß, weil im allgemeinen deutlich mehr Daten von K2 nach BM fließen als umgekehrt. Von dem Betrag, den BM an K2 zahlen muß, wird jetzt noch der Betrag abgezogen, den BM schon aus eigener Tasche bezahlt hat (es werden also sämtliche Verbindungen, die von BM nach K2 liefen, abgezogen). Daraus kommt ein Betrag, der tatsächlich von BM nach K2 überwiesen wird.
Beispiel (hier aus der Sicht von K2):
Telefonkosten: Box Einheiten KB Anteil In Erstattung In Out ges. In Out gesamt KB/E % Einheiten DM --------------------------------------------------------------------------- BM 32+ 65= 97 7459+ 54381= 61840 638 12.1% 65- 12 6.36
Es gingen im März 7459 KB von BM nach K2 und 54381 KB von K2 nach BM. Dafür wurden in Anrufen von BM nach K2 32 Einheiten, in Anrufen von K2 nach BM 65 Einheiten verbraucht.
Insgesamt wurden 61840 KB übertragen und 97 Einheiten verbraucht, was einen Schnitt von 638 KB pro Einheit ausmacht. 12,1 % der Daten gingen von BM nach K2, also hat K2 auch 12,1 % der 97 Einheiten zu zahlen. Das sind 12 Einheiten. 65 Einheiten hat K2 aber schon mit seiner Telefonrechnung bezahlt, also bekommt K2 von BM eine Erstattung über 53 Einheiten, also 6,36 DM.
In einem zweiten Berechnungsschritt wird ermittelt, wieviele Daten *insgesamt* in BM eingegangen sind, egal, ob aus K2, D, SU oder B. Aufgrund obiger Verrechnung hat BM alle diese Daten ja bezahlt; die Kosten für diese Daten werden als "Eigenanteil" bezeichnet.
Msgstat berechnet, wieviel von den Daten, die insgesamt in BM eingegangen sind, auch wirklich in BM verblieben sind. Viele PMs, aber auch einige Gruppen, hat BM ja nur gesaugt, um sie weiterreichen zu können. Msgstat berechnet nun diesen "Routinganteil": wieviel Prozent der Daten, die BM insgesamt gesaugt hat, konnte BM denn überhaupt gar nicht brauchen?
In BM beläuft sich das konkret auf ca. 20% aller gesaugten Daten. Für die eingegangenen Daten bezahlt BM ca. 12 DM, d.h. 2,40 DM hat BM ausgegeben, ohne selber Verwendung dafür zu haben.
Bis hierhin ist die Abrechnung noch *absolut* korrekt.
Für den recht geringen Betrag von 2,40 DM pro Monat wird jetzt aber kein großes Aufhebens gemacht. Er wird einfach zu gleichen Teilen auf alle unter BM liegenden Boxen aufgeteilt, ohne dabei zu berücksichtigen, welche der Boxen denn nun den größten Anteil an den 2,40 DM hatte.
Das bedeutet letztendlich: jeder innere Knoten des Netzbaums zahlt genau so, als wenn er Blatt wäre, für alle Gruppen, die er bekommt. Wenn also ein innerer Knoten im Ferntarif Daten herankarrt und diese im Nahtarif auf viele Boxen verteilt, sind diese Boxen fein raus, der Server selber aber zahlt den vollen Betrag.
Dieses Ungleichgewicht wird - jedenfalls von der klassischen Kombination NetStat/MsgStat - nicht herausgerechnet. Eine fairere Lösung wäre vermutlich, auch die lokal eingetragenen öffentlichen Mitteilungen zu bewerten und jeweils die Kosten dynamisch auf die Boxen aufzuteilen, die die Mitteilungen erhalten.
Mit den herkömmlichen langfristigen Logfiles ist eine solche Aufteilung jedoch nicht möglich; ich könnte mir aber sehr gut vorstellen, daß James, der sowieso täglich die Netzlogfiles auswerten kann, hier exaktere Möglichkeiten bietet. Hm, nein, da stehen die Größen der Mitteilungen nicht drin. Das geht also auch nicht exakt. Tja, ich weiß es nicht, ob es eine exakte Abrechnungsmöglichkeit gibt.
Tschö, Marcus.
Wenn nach dem entpacken des Netzpaketes immer komische Zeichen in den Mails vorkommen, dann sollte man mal die Smiley-Optionen des PKZIP probieren:
-3+-)(~
In etwas abgewandelter Form benutzt das Michael Keukert in seinem ZIP.BAT
ZIP.BAT
@echo off echo %1 %2 %3 %4 %5 %6 > zip.ech :PKZIP mem > memory.lst M:\util\pkzip -~)!+3 -- %1 %2 %3 %4 %5 %6 M:\util\pkunzip -t %2 if errorlevel 1 goto ZIP quit :ZIP M:\util\zip %1 %2 %3 %4 %5 %6 quit
Die Bedeutung der Optionen:
-3 | Disable 32-bit instruction usage on 80386 or higher CPU's |
-^ | Echo the command line |
-+ | Disable Expanded Memory (EMS) usage |
- | Disable UMB/HMA Memory (XMS) usage |
-~ | Disable Network usage |
-) | Disable 32 bit DPMI usage |
-( | Use "Slow" MemCopy |
MNConfig /X
Darf nur einmal am Tag, und zwar nach dem Nachtnetz aufgerufen werden.
MNConfig ohne Parameter
Sollte nach jeder Änderung am *.CNF der eigenen Maus aufgerufen werden. Auch wenn man das Remote macht (dazu einen Event vorsehen). Anschließend sollte auch im MAUSNET.LOG nachgeschaut werden, ob alles korrekt ablief. Nicht immer werden Fehler in Mails an den Sysop gemeldet.
Wenn WriteSuccessMsg gesetzt ist, dann bekommt der Sysop auch immer eine Mail, wenn der MNConfig mit /X aufgerufen wird.
Was bedeutet folgende Meldung bei MausNet 2.54:
03:01:32>MSG-ALLG.PAR wird mit MSG-ALLG.NET verglichen.
03:01:45>A14351@BM regelmäßiger Versand -> Dupe ->
GetHeap
(0a41:1b05): 544, frei: 6328 6328(bis einschließlich "->
Dupe"
MS>GetHeap (0a41:1b05): 544, frei: 6328 6328
Eine einfache Ausgabe, daß 544 Bytes auf dem Heap angefordert wurden und dann liegen Mem- und MaxAvail bei 6328. Ist also etwas knapp in deiner Kiste.
04:07 P123456@xy -> WO nicht angekommen(?) seit 113 Stunden.
04:07 P123457@xy -> WO nicht angekommen(?) seit 88 Stunden.
Das Mausnet überwacht die Statusmeldungen der PMs. Mit den beiden Variablen PMVerlustMin und PMVerlustMax kann man einstellen, ab wann und wie lange die Meldung kommen soll.
Die Meldung bedeutet aber nicht, das die Mails nicht angekommen sind. Es kann auch die Statusmeldung verloren gegangen sein (ist fast immer der Fall). Diese Warnung bekommt immer nur der WoSysop (mit der MausNet- Meldung). Mithilfe von James kann man auch so eine Mail generieren lassen:
169h: P65428@B Von: Christian Goßlar @ B 1 PM wird von MAUSNET als nicht angekommen gemeldet.
die man in eine lokale öffentliche Gruppe posten kann. Damit sind die User dann informiert und können entsprechend reagieren.
Wie kommt so eine Meldung in der Maus A zustande (James-Posting)
107h: P30700@TBB Von: XXXX XXXX @ B an: XXXX XXXX @ HB2
107h: P30701@TBB Von: XXXX XXXX @ KR an: XXXX XXXX @ HB2
Diese Meldung wird durch das weiterleiten von PMs erzeugt. Dabei bleibt der Originalabsender erhalten
Von: Boris Meltzow @ AC2 (Do, 18.01.96 20:15)
Hi !
Seit Tagen bekomme ich ich folgenden Meldung vom Netz mit der Maus AC: ==================================================================== 14:03 MausNet Version 2.51/dpmi/debug mit Parameter "/C" gestartet 14:03 Daten <- MAUS AC : 00:11 min, 2.0 KB, 816 cps. 14:03 Daten -> MAUS AC : 0.3 KB, 816 cps. 14:03 Daten <> MAUS AC : 2.3 KB, 917 cps. 14:03 PM an KOPERNIKUS@IUS.gun.de-ac2: zurückgeroutet. 14:03 PM an RENEGADE@newswire.gun.de-ac2: zurückgeroutet. 14:03 PM an Geist@nature.gun.de-ac2: zurückgeroutet. =====================================================================
Offensichtlich werden diese drei Mails hin und her geroutet. Wie kann das?
.....Und Tschüß
Von: Gereon Steffens @ K2 (Sa, 20.01.96 14:40)
>Offensichtlich werden diese drei Mails hin und her geroutet. Wie
>kann das?
Bekannter Bug, korrekt.
Abhilfen gibt's zwei: entweder die Netz-.PAR-Files patchen, oder aber einfacheinen Gate für .gun.de einrichten, der für die MAUS, aus der diese Mails stammen,erlaubt ist (vermutlich MAUS K, ich hatte hier dieselben Empfänger).
Gereon
Von: Jörg Stattaus @ W2 (So, 21.01.96 09:50)
CG>Und was ist dagegen zu tun? Irgendwie die Mails entsorgen, nur
CG>wie? Wo muß was gepatch werden?
Das PAR-File besteht aus 48-Byte-Records. Das erste Byte ist ein 'P' für PM. Daspatcht du auf 'X' und das nächste MausNet, daß diese Msg importieren soll, tritt sie in die Tonne.
Gruß Jörg
Von: Gereon Steffens @ K2 (So, 21.01.96 19:57)
>Das erste Byte ist ein 'P' für PM. Das patcht du auf 'X'
Man sollte noch dabeisagen, daß in den drei Byte danach die ID der Msg binärsteht, zuerst ein (Intel!) Word mit der numerischen ID, dann ein Byte mit derNummer der Absender-Box.
Gereon
Von: Frithard Meyer-Zu-Uptrup @ S4 (Mo, 22.01.96 11:54)
Ihr könnt auch einfacher ein Netz von hand fahren. Danach liegt dann auf dereinen Seite wieder ein PAR/DAT für die andere MAUS da - das sind die zurück gerouteten Teile. Nochmal mit mausnet.log vergleichen und dann die beiden Teile löschen. Geht auch evtl nach dem Nachtnetz, dann aber auf jeden Fall immausnet.log nachsehen, ob nicht Mails von einer anderen MAUS kamen, die auch in diesem DAT/PAR sind.
fritz
Nachtrag von mir. Am einfachsten ist es, z.B. dirket nach dem Abendnetz nochmal ein MAUSNET /export aufzurufen. Dann sollte nur diese zurückgeroutet Mail im Netzpaket stehen. Und dann mit dem Hexeditor einfach die Mail wegpatchen.
Von Jörg Stattaus
Vorhaben: Maus OLD soll Maus NEU werden.
Bei einer Maus wird im alten CNF der Name geändert. Im OLD.CNF trägt man also *NEU ein. Der mnconfig /x nach dem nächsten Nachtnetz führt dann überall Zeitgleich die Umbenennung durch. Theoretisch sollte das auch bei Quarks so gehen, aber das habe ich nicht getestet.
Das ist nur für Doppelmäuse interessant, die per Netz miteinander verbunden sind und normalerweise immer ein lokales Netz zu bestimmten Zeiten fahren. Alle anderen sollen unbedingt die Finger davon lassen. Wenn so eine Doppelmaus auch einmal am Tag ein MausNet /1 auslösen will, aber nicht auf die Mausnetzzeiten warten will, ändert man einfach in dieser Maus die entsprechenden Zeiten. Hier mal der Netzplan, wie er im Moment vom Maunetz vorgegeben wird: In jeder Zeile steht pro Ebene AnfangSenden, EndeVonUnten, EndeNachOben, EndeVonOben und EndeNachUnten.
1 03:37 04:18 2 03:15 03:28 03:36 04:20 04:33 3 03:13 03:19 03:27 04:35 04:46 4 03:09 03:15 03:18 04:48 04:58 5 03:05 03:14 05:00
Eine Ebene-3-MAUS hat also Defaultmäßig diese Zeiten:
AnfangSenden := '03:13' EndeVonUnten := '03:19' EndeNachOben := '03:27' EndeVonOben := '04:35' EndeNachUnten := '04:46'
Die geänderten Werte sind in das MausNet.cfg einzutragen.
Das bedeute, daß das MausNet der Box Nachrichten für eine Gruppen mitgeschickt hat, die in der lokalen Box nicht vorhanden ist. Das kann eigentlich nur drei Ursachen haben, es ist aber meistens immer nur Punkt 1
Lokal wurde eine Gruppe entnetzt und auch gleich gelöscht. Nur woher soll das MausNet das wissen. Das MausNet schickt also bis zum nächsten normalen MNConfig-Lauf immernoch Mails für diese Gruppe mit. Siehe auch den Punkt zum MNConfig
Dein MAUSGRP.DAT ist defekt und deshalb wird dem MausNet mitgeteilt, das lokal die Gruppe xy existiert, obwohl sie nicht vorhanden ist.
Das MAUSGRP.DAT in deiner Serverbox ist defekt und denkt, das du die Gruppe xy hast, obwohl sie nicht vorhanden ist
Von: Jörg Stattaus @ AC (Mi, 02.06.93 12:44)
So sollte man vorgehen, wenn man die Vernetzung ändern will.
Natürlich alles mit den Beteiligten absprechen.
am Vortag das CNF ändern und mnconfig starten, aber _OHNE_ /x.
das Nachtnetz mit der alten Box abwarten, danach läuft ja netzweit mnconfig/x und die Vernetzung wird geändert.
MAUSNET.CFG (UseZip, UseZModem, ggf. ModemDialPre) anpassen
Ggf. MAUS.BAT wegen Abendnetz modifzieren
Auch eine Vertauschung der Reihenfolge von 2 Boxen geht auf diese Weise.
Aber: wenn das Nachtnetz nicht läuft, muß man von Hand nachbessern, sprich die EXPs entsprechend ändern und mnconfig /x aufrufen. Aber NUR dann.
Gruß Jörg
Einfach das EXP-File der eigenen Maus verändern oder auf das aktuelle Datum setzen (per touch). Dann schickt das MausNet das automatisch rum. D.h. wenn man bei einem Crash alle EXP-Files verliert, würde es sehr lange dauern, bis wieder alle bei einem vorhanden sind. Deshalb sollte man die EXPs bei der täglichen Datensicherung brav mit sichern. Wenn ein neues EXP verteilt wird, reicht das MausNet immer das original aus dem Netzpaket weiter und nicht etwa die Kopie von der lokalen Platte.
Änderungen nur vornehmen, wenn man weiß was man tut. Fehler können unter Umständen bedeuten, das die Maus im Netz nicht mehr bekannt ist
Vorher nachgucken, was die entsprechenden Parameter bedeuten.
Überlegen, was man in die u Zeilen einträgt. Die sind nach dem nächsten Nachtnetz für alle zu lesen!
Die Änderungen unbedingt mit einem DOS-Editor machen. Besonders bei Mäusen mit Umlauten im Kürzel ist das sehr wichtig
Nach jeder Änderung unbedingt den MNConfig ohne Parameter aufrufen und sich das Ergebnis im MausNet.LOG angucken.
Erstmal wollen wir hoffen, das dieser Fall nur sehr selten eintritt. Höchstens für temporäre Mäuse ist das ganze interessant.
Was sollte man also tun, wenn die Maus wieder aus dem Netz verschwinden soll?
Das ganze in Sysop.Info schreiben
unbedingt das CNF-File der entsprechenden Maus so ändern, das jeder sofort sehen kann, daß das EXP-File gelöscht werden kann. Am besten noch mit Datum, ab wann das geschehen soll. Wieso das ganze? Weil die Maus im Moment noch nicht alte EXP-Files löscht. Wenn jetzt die Mausnummer neu vergeben wird, bekommt man Probleme, wenn das alte EXP noch auf der Platte rumgammelt. Jeden Tag meldet der MNCONFIG mir eine neue Maus?
Hier sind die Fragen, die sich um den Mausrechner allgemein und um Hilfsprogramme rund um die Maus drehen, zusammengestellt.
Aus dem File in der S3:
2 Sonstige DIRECT.ZIP 7415
Datenfernübertragung, Textfile
Direkt-Login Anleitung.
Von Frithard Meyer-Zu-Uptrup @ S3
MAUS-Direct-Login ab Version 7.85e
------
18.5.1991 by Frank Baschin
22.5.1991 corrected by Marco Schlünß
13.7.1992 updated by Frank Baschin
Nachdem mich viele von Euch auf die genaue Installation der Direct-Login- Funktion in der Maus angesprochen haben, habe ich mich jetzt mal hingesetzt und das grundlegenste aufgeschrieben.
Für die 'alten Hasen' liegen die wichtigsten Änderungen als Files diesem Packet bei.
1.0 was ist Direct-Login?
2.0 die Hardware
3.0 die Software-
3.1. auf Maus-Seite
3.2. auf der anderen Seite
4.0 die Bedienung
5.0 der MausTausch
1.0 was ist Direct-Login?
Der Direct-Login ist die einfachste Methode um mittels einem zweiten verbundenen Rechner in die MAUS zu gelangen.
Dazu wird über ein Null-Modem Kabel eine Verbindung aufgebaut, die die gleichen Funktionen bietet wie ein Anruf per Modem nur eben viel billiger und schneller. Die Übertragungsgeschwindigkeit beträgt maximal 19200 Bps! Als Verbindungs-Programm kann jedes gängige Terminal Programm, wie zum Beispiel TELIX (tm), QMODEM (tm) oder TELEMATE (tm) benutzt werden. Auch der Up- und Download von Programmen in und aus der MAUS kann so ohne lästiges Diskettenwechseln erfolgen.
Als zusätzliches Feature kann der momentane Log-Schirm der MAUS per Tastendruck übertragen werden. Dadurch ist es also möglich die MAUS in einem anderen Raum stehen zu haben und trotzdem alle Aktivitäten per Remote zu beobachten.
2.0 die Hardware
Um zwei Rechner verbinden zu können, müssen erstmal die Hardwarevoraus- setzungen geschaffen werden. Dazu müssen beide Rechner eine freie, serielle Schnittstelle zur Verfügung stellen.
Diese beiden Schnittstellen müssen nun durch ein passendes Kabel verbunden werden. In der Regel reicht ein Standard-NULL-Modem-Kabel. Es ist nur darauf zu achten, daß beim Kabel die DCD (Data-Carrier-detect) Pins auf beiden Seiten richtig verschaltet sind. Ebenfalls muß eine RTS-CTS-Kopplung vorhanden sein. Sonst gibt es Probleme beim Verbindungsaufbau. Für alle Bastler ist hier eine komplette Anleitung:
Die Belegung für zwei mal 25 pol. auf dem PC :
25 polig 25 polig
1 (GND) -------------------- 1 (GND)
7 (SG) --------------------- 7 (SG)
2 (TX) --------------------- 3 (RX)
3 (RX) --------------------- 2 (TX)
4 (RTS) -------------------- 5 (CTS)
5 (CTS) -------------------- 4 (RTS)
/-- 8 (DCD) --------//---------- 8 (DCD)-\ <== nicht verbinden!
\--20 (DTR) -------------------- 6 (DSR) |
6 (DSR) ------------------- 20 (DTR)-/
Und das ganze auch nochmal für 25 auf 9pol. :
25 polig 9polig
7 (SG) ----------------- 5 (SG)
2 (TX) ----------------- 2 (RX)
3 (RX) ----------------- 3 (TX)
4 (RTS) ----------------- 8 (CTS)
5 (CTS) ----------------- 7 (RTS)
/-- 8 (DCD) --------//------- 1 (DCD)-\ <== nicht verbinden!
\--20 (DTR) ----------------- 6 (DSR) |
6 (DSR) ----------------- 4 (DTR)-/
Und nochmal 9pol auf 9pol.:
/--1 (DCD) ---------//------- 1 (DCD)--\
| 2 (RX) ------------------ 3 (TX) |
| 3 (TX) ------------------ 2 (RX) |
\--4 (DTR) ------------------ 6 (DSR) |
5 (SG) ------------------ 5 (SG) |
6 (DSR) ------------------ 4 (DTR)--/
7 (RTS) ------------------ 8 (CTS)
8 (CTS) ------------------ 7 (RTS)
Wenn im Kabel die DCD-Pins schon verbunden sind, im Standard-Kabel nicht immer der Fall, reicht es auch aus, wenn man auf MAUS-Seite die Pins 8-20-6 verbindet. Also DCD-DTR-DSR.
Sind die Pins NICHT verbunden, so ist wie in der obigen Schaltung zu verfahren. Also einfach auf beiden Seiten DCD mit DTR verbinden. Das Kabel vom ST zum PC sieht so aus:
ST PC
2 -------- 3
3 -------- 2
4 -------- 5 -\
5 -------- 4 -/
6 -------- 20 ---\
7 -------- 7 |
8 -------- 8 ----/
20 -------- 6
Also auf PC-Seite RTS mit CTS und DTR mit DCD verbunden.
3.0 die Software auf der MAUS-Seite
Wenn die Hardwarevoraussetzungen geschaffen wurden, kann man sich an die Software machen. Als erstes ist der MAUS-Rechner zu bearbeiten. In der CONFIG.SYS müssen die Anzahl der Ports für den X00.SYS um einen erweitert werden. Dieser Port dient später der MAUS dazu, ihre Daten an den zweiten Rechner zu senden.
Am einfachsten folgendes probieren:
DEVICE = X00.SYS e 0=COM1 1=COM2
Wobei COM1 und COM2 den tatsächlichen Namen der Schnittstellen entsprechen müssen. Für den X00 bedeutet das z.B. in unserem Fall 0=COM1 und 1=COM2. Das ist wichtig, damit man später der MAUS diese Nummern mitteilen kann. (Siehe nächstes Kapitel.)
Weitere Infos zum X00.SYS sind in dessen Docu zu finden. Als
nächstes muß die Datei M7COM.CFG der MAUS um einige Zeilen
erweitert werden. Hier die Variablen im einzelnen:
; Diese Config-Vars sind in das M7COM.CFG einzubinden. ; Die default-Werte stehen in [] darunter. ; DirectLogin:= TRUE ; TRUE für Login via anderen seriellen Port ; [FALSE] ; DirectBaud := 19200 ; auf dieser Baudrate wird der Port fest betrieben DirectRing := '222'; dieser String wird als "Anrufwunsch" gewertet. ; ['222'] jeder andere liefert den Log-Bildschirm DirectLog := ' '; dient zur Übertragung des MAUS-Log-Screen DirectPort := 1 ; X00-Port, an dem evtl. das Nullmodemkabel hängt ModemPort := 0 ; X00-Port, an dem das Modem hängt ; ; ^--> diese Angaben sind die gleichen wie von X00.SYS !!!
Für den Anfang sollte man es einfach mal mit diesen Werten probieren. Wichtig ist nur, daß bei DirectPort und ModemPort die gleichen Werte eingesetzt werden, die schon in der CONFIG.SYS definiert wurden!
Damit sind die Arbeiten auf dem MAUS-Rechner beendet, und die MAUS kann wieder gestartet werden.
3.2. die Software auf der anderen Seite
Auf der Remote-Seite sind keine besonderen Installationen zu tätigen. Hier sollte es jetzt mit jedem Terminal Programm möglich sein, eine Verbindung zur MAUS herzustellen.
Dazu muß das Terminal-Prg nur auf den richtigen Port und die richtige Geschwindigkeit eingestellt werden. In unserem Fall ist der Port durch die Hardware vorgegeben, und die Geschwindigkeit muß dieselbe sein, die im M7COM.CFG als DirectBaud eingestellt wurde. Ein X00.SYS braucht NICHT geladen zu werden!
4.0 die Bedienung
Ich beschreibe jetzt einmal die Bedienung am Beispiel von TELIX (tm). Für ein anderes Programm ist analog zu verfahren.
Vor dem Start ist darauf zu achten, daß keine Modeminitialisierung oder ähnliches an den Port gesendet werden. Ansonsten kann es bei der MAUS 7.85e zu seltsamen Abstürzen kommen. Die Folgeversionen sollten diesen Bug nicht mehr aufweisen.
Da TELIX nicht sehr groß ist, empfehle ich für den Direct-Login eine extra-Kopie zu benutzen, in der alle Modemparameter auf Null gesetzt sind. Dann einfach TELIX starten.
Um mit der MAUS in Verbindung zu treten sind zwei Variable aus dem M7COM.CFG wichtig.
1. DirectRing := '222' 2. DirectLog := ' '
Gibt man nun die Ziffern 222 ein, so sollte sich die MAUS mit
Ok, Direct Ring erkannt
melden. Ist dies nicht der Fall, so hat man etwas falsch gemacht. Am besten die Kabel und die Einstellungen der Sofware kontrollieren.
Check-Liste:
1. ist der X00.SYS richtig eingestellt?
2. stimmen die Einstellungen im M7COM.CFG?
3. ist das Kabel richtig verdrahtet? (RTS-CTS...etc)
4. stimmt der Port im Terminal-Prg?
5. stimmt die Geschwindigkeit?
Nach dem dem erfolgreichen Connect sollte auf der MAUS-Seite anstelle der Geschwindigkeit ein DIR im MCALL.LOG stehen. Das bedeutet, daß die MAUS per DIRect-Login verbunden ist.
Der weitere Verlauf des Logins erfolgt genauso, wie man es vom Modem her gewohnt ist. (Nur ein bischen schneller) Als nächsten Test drückt man nun die Space-Taste. Es sollte jetzt auf dem TELIX-Schirm eine exakte Kopie des MAUS-Schirms erscheinen. Die Taste, bei welcher diese Übertragung stattfindet, kann man im M7COM.CFG mit der Variablen DirectLog := 'x' einstellen. ' ' bedeutet SPACE!
Als letzten Test sollte man versuchen ein File per Protokol in die MAUS zu übertragen. Am besten auf beiden Seiten ein EXTERNES Protokol benutzen. Wenn nun auf einer oder beiden Seiten die Übertragung nicht klappt und sich z.B. DSZ oder MpT mit "Carrier-Lost" melden, so ist mit Sicherheit ein Kabelfehler vorhanden.
In diesem Fall muß die korrekte Verdrahtung der DCD Pins überprüft werden! Hat auch dies geklappt, so ist man mit der Installtion fertig.
5.0 der MausTausch
Als SysOp sollte man bemüht sein, die MAUS nicht unötig lange mit dem lesen der Mails zu blockieren. Daher bietet es sich an auch per Direct-Login den Maustausch zu benutzen. Dies ist ohne Probleme möglich. Für TELIX habe ich ein kleines Script Programm geschrieben, daß den MausTausch vollautomatisch durchführt. Also vom Einloggen in die Maus über das Holen der Mails bis zum Ausloggen aus der MAUS.
Der Script liegt diesem Packet als MT.SLT bei. Zur Benutzung müssen nur noch im Script der Name und das Passwort des SysOps eingetragen werden. Und danach das File mit
CS MT.SLT
compilieren. CS ist der Script-Compiler von TELIX. Um den MausTausch nun durchzuführen gibt man einfach
TELIX sMT
ein. Mit TELIX s{Script-Name} wird ein Script automatisch gestartet. Das Script-File sollte ausreichend dokumentiert sein um es ohne Probleme benutzen zu können. Es ist jedoch nur ein Grundgerüst. Für Erweiterungen wäre ich sehr dankbar.
Den registrierten Benutzern des MauTau's ab Version 2.4 (8.Release) steht sogar noch die Möglichkeit zur Verfügung als EXTERNES DFÜ-Programm einen BATCH zu definieren, der TELIX mit der Option sMT startet. So ist es am komfortabelsten. (Näheres in der MauTau-Docu (Welche? Anmerk. des MauTau-Autors))
Und hier das MT.SLT-Script dazu:
//////////////////////////// Direct-Login /////////////////////////////// /Dies ist ein Beispielscript, um in die MAUS per Directlogin einzuloggen/ / Es ist darauf zu achten, daß die Eintrage absolut mit denen der / / MB übereinstimmen. / / Dieser Script führt vollautomatisch den MausTausch durch! / str user_name[] = "Frank Baschin" ; // hier den eigenen Namen eintragen str passwort[] ="xxxxxx" ; // Passwort des SysOps / Dies ist nur ein Beispiel mit einer sehr geringen Fehlerbehandlung. / ////////////////////////////////////////////////////////////////////////// main() { cputs ("222"); // der Wert aus dem M7COM.CFG für "DirectRing" if (waitfor ("Sind Sie eingetragener Benutzer",600)) // Abfrage 1 Minute warten { cputs ("J"); } if (waitfor ("Ihr Name")) // Namensabfrage { cputs (user_name); // obigen Namen senden cputs ("^M"); } if (waitfor ("Ihr Password : ")) // Passwortabfrage { cputs (passwort); // Passwort senden cputs ("^M"); } cputs("^M"); // evtl. 24 Zeilenlimit der MAUS überspringen. if (waitfor ("Eingabe: ")) // alles klar. Eingeloggt. { cputs ("T"); // MausTausch anwählen. cputs ("^M"); } if (waitfor ("Protokoll")) // INFILE senden. { cputs("z"); // XModem. delay(10); // um Timing Problem zu vermeiden. (1Sek) send('Z', "INFILE.LZH"); // Infile per "X"-Modem senden. } // ZModem unter Telix hat ein Autodownload, dehalb können die // nächsten Zeilen entfallen. // // if (waitfor ("Protokoll",1800)) // OUTFILE empfangen. // { // delay(10); // um Timing Probleme zu vermeiden. (1Sek) // receive('X', "OUTFILE.LZH"); // Outfile per "X"-Modem empfangen. // } cputs("^M"); if (waitfor ("Eingabe:",1800)) // alles fertig. Max.3 Minuten warten! { cputs("S"); } if (waitfor ("Wollen Sie wirklich aufhören")) // letzte Abfrage { cputs("J"); // und bestätigen. } ExitTelix(); // und Schluß, ab zum DOS... }
Ähmmm ja. Keine Ahnung. Frag mal Timm Ganske @ OF:-)
Ich weiß zwar nicht was der freundliche Tankwart meint, ich empfehle aber mlzwo von Marcus Schmidke. Was kann man damit alles anstellen?
Eine ganz normale Mailingliste laufen lassen
Eine Mailingliste in eine lokale Gruppe umleiten lassen. D.h. in der Maus in der mlzwo läuft kann man ganz normal in einer Gruppe lesen und die Mitglieder außerhalb der Maus bekommen alle Gruppenmails per PM zugeschickt und umgekehrt landen alle PMs an den Mailinglisten Daemon in der Gruppe.
Die Mailingliste kann sowohl öffentlich als auch geschlossen geführt werden. Der unterschied besteht in dem eintragen der Mitglieder. Bei einer öffentlichen Mailingliste kann jeder User sich selber ein und austragen. Bei einer geschlossenen kann das nur der Mailinglisten Chef
Und hier mal ein Beispielaufruf für die Mailingliste.
Aufruf im Maus.Bat call c:\maus\maillist.bat Maillist Mail Daemon rem Mailinglisten-Batch mit MlZwo rem rem Maillist = Name der Mailing-Liste für mlzwo rem Mail = Vorname des Mailinglisten-Dämons rem Daemon = Nachname des Mailinglisten-Dämons c: cd \maus copy c:\maus\mlzwo\infile.org c:\maus\mlzwo\infile.txt m7com /t mail daemon c:\maus\mlzwo\infile.txt c:\maus\mlzwo\outfile.txt del c:\maus\mlzwo\infile.txt cd \maus\mlzwo c:\maus\mlzwo\mlzwo Maillist -o outfile.txt infile.txt del c:\maus\mlzwo\outfile.txt cd \maus m7com /t mail daemon c:\maus\mlzwo\infile.txt c:\maus\mlzwo\outfile.txt del c:\maus\mlzwo\infile.txt cd \maus\mlzwo c:\maus\mlzwo\mlzwo Maillist %1 -o outfile.txt dummy.txt cd \maus
Das ganze in einen Batch packen und vor und nach dem Nacht- Abendnetz aufrufen.
Gruppe: SYSOP.TECH
ID: A26619@K2
Wg.: Datumswechsel
Von: Gereon Steffens @ K2 (Do, 26.06.97 22:57)
MId: 199706262257.a26619@k2.maus.de
>Was passiert eigentlich mit der MAUS beim Wechsel von 1990 auf
2000?
Du meinst von 1999 auf 2000? Das wird die jetzige Version nicht
verkraften.
Gereon
Von: Frithard Meyer-Zu-Uptrup @ S3 (Di, 24.08.93 11:22)
> hätte ich mal folgende Frage: Wenn ich auf dem Arbeitsrechner
ein
> Backup der Message-Base halten will, welche Dateien muß ich
da alle
> runterziehen? Alle MSG*.* oder sonst noch was?
Na ja, die Messagebase ist im Datengau-Fall schnell wieder komplett neugefüllt, es gibt da noch ein paar andere die auch kein Fehler sind:
MAUSSAVE.BAT
Rem Hält immer 2 Sicherungen auf der Platte Hyperdk S T:3 JAMES /V Datensicherung erase g:\maususer.arx rename g:\maususer.arj g:\maususer.arx arj a g:\maususer.arj d:\maus\maususer.dat arj a g:\maususer.arj d:\maus\mauslast.ung arj a g:\maususer.arj d:\maus\mausvar.dat arj a g:\maususer.arj d:\maus\m7com.cfg arj a g:\maususer.arj d:\maus\mgruppen.dat arj a g:\maususer.arj d:\maus\*.bat arj a g:\maususer.arj d:\maus\net\mn-*.cnf rem ProgTeilDatPath: arj a g:\maususer.arj e:\maus\progdat\*.* arj a g:\maususer.arj c:\autoexec.bat arj a g:\maususer.arj c:\config.sys erase d:\maus\msgpers.p$$ erase d:\maus\msgpers.d$$ erase d:\maus\msgallg.p$$ erase d:\maus\msgallg.d$$ erase g:\msgpers.arx rename g:\msgpers.arj g:\msgpers.arx erase g:\msgallg.arx rename g:\msgallg.arj g:\msgallg.arx arj a g:\msgpers.arj d:\maus\msgpers.* arj a g:\msgallg.arj d:\maus\msgallg.* JAMES /W Hyperdk W
Das "Jargon File" (aka "The New Hacker's Dictionary"):
Murphy's Law: prov. The correct, *original* Murphy's Law reads: "If there are two or more ways to do something, and one of those ways can result in a catastrophe, then someone will do it." This is a principle of defensive design, cited here because it is usually given in mutant forms less descriptive of the challenges of design for lusers. For example, you don't make a two-pin plug symmetrical and then label it `THIS WAY UP'; if it matters which way it is plugged in, then you make the design asymmetrical (see also the anecdote under magic smoke).
Edward A. Murphy, Jr. was one of the engineers on the rocket-sled experiments that were done by the U.S. Air Force in 1949 to test human acceleration tolerances (USAF project MX981). One experiment involved a set of 16 accelerometers mounted to different parts of the subject's body. There were two ways each sensor could be glued to its mount, and somebody methodically installed all 16 the wrong way around. Murphy then made the original form of his pronouncement, which the test subject (Major John Paul Stapp) quoted at a news conference a few days later.
Within months `Murphy's Law' had spread to various technical cultures connected to aerospace engineering. Before too many years had gone by variants had passed into the popular imagination, changing as they went. Most of these are variants on "Anything that can go wrong, will"; this is sometimes referred to as Finagle's Law. The memetic drift apparent in these mutants clearly demonstrates Murphy's Law acting on itself!
Nr. | Fehlermeldung |
DOS Dosfunktionen | |
1 | Ungültiger DOS-Funktionscode |
(Invalid function number) | |
2 | Datei nicht gefunden |
(File not found) | |
3 | Pfad nicht gefunden |
(Path not found) | |
4 | Zu viele Dateien geöffnet |
(Too many open files) | |
5 | Zugriff auf Datei verweigert |
(File access denied) | |
6 | Ungültiges Datei-Handle |
(Invalid file handle) | |
12 | Ungültiger Zugriffscode |
(Invalid file access code) | |
15 | Ungültiges Laufwerk |
(Invalid drive number) | |
16 | Aktuelles Verzeichnis kann nicht gelöscht werden |
(Cannot remove current directory) | |
17 | Umbenennen über Laufwerke hinweg nicht erlaubt |
(Cannot rename across drives) | |
18 | Keine weiteren Dateien |
(No more files) | |
Maus: extern (events) | |
50 | event 50 |
70 | event 70 (mausnet hat in der maus angerufen) |
79 | event 79 |
Maus: intern | |
80 | Modem antwortet nicht |
81 | Modem nimmt keine Daten an |
82 | ModemCheck funktioniert nicht ("Hallo, Modem, lebst Du noch?") |
83 | X00 will sich nicht initialisieren lassen |
84 | Timer läßt sich nicht einhängen |
85 | Timer läßt sich nicht aushängen |
86 | X00-Kommunikations-RangeCheck |
87 | kein Fossil da |
88 | Absturz, bevor der normale Fehlerhandler installiert ist |
(Fehler beim INIT) | |
89 | Fehler beim EXEC (execute external programm) |
90 | M7DEC ist tütt |
91 | ITG-Error beim lesen von NET-GRP.DAT |
turbopascal: Dosfunktionen | |
100 | Lesefehler von Diskette/Platte |
(Disk read error) | |
101 | Schreibfehler auf Diskette/Platte |
(Disk write error) | |
102 | Dateivariable ist keiner Datei zugeordnet |
(File not assigned) | |
103 | Datei nicht geöffnet |
(File not open) | |
104 | Datei nicht für Eingabe geöffnet |
(File not open for input) | |
105 | Datei nicht für Ausgabe geöffnet |
(File not open for output) | |
106 | Ungültiges numerisches Format |
(Invalid numeric format) | |
150 | Diskette ist schreibgeschützt |
(Disk is write-protected) | |
151 | Peripheriegerät nicht bekannt/nicht angeschlossen |
(Bad drive request struct length) | |
152 | Laufwerk nicht bereit |
(Drive not ready) | |
154 | CRC-Fehler in Daten |
(CRC error in data) | |
156 | Seek-Fehler auf Diskette/Platte |
(Disk seek error) | |
157 | Unbekanntes Sektorformat |
(Unknown media type) | |
158 | Sektor nicht gefunden |
(Sector Not Found) | |
159 | Drucker hat kein Papier |
(Printer out of paper) | |
160 | Fehler beim Schreiben auf Peripheriegerät |
(Device write fault) | |
161 | Fehler beim Lesen von einem Peripheriegerät |
(Device read fault) | |
162 | Hardware-Fehler |
(Hardware failure) | |
manueller Fehler | |
199 | Manueller Runerror via <alt>238 |
Turbo-Pascal: Interne Runtime-Fehler | |
200 | Division durch Null |
(Division by zero) | |
201 | Bereichsüberschreitung |
(Range check error) | |
202 | Stack-Überlauf |
(Stack overflow error) | |
203 | Heap-Überlauf |
(Heap overflow error) | |
204 | Ungültige Zeiger-Operation |
(Invalid pointer operation) | |
205 | Überlauf bei Gleitkomma-Operation |
(Floating point overflow) | |
206 | Unterlauf bei Gleitkomma-Operation |
(Floating point underflow) | |
207 | Fehler bei Gleitkomma-Operation |
(Invalid floating point operation) | |
208 | Overlay-Manager nicht installiert |
(Overlay manager not installed) | |
209 | Lesefehler bei Overlay-Datei |
(Overlay file read error) | |
210 | Objekt nicht initialisiert |
(Object not initialized) | |
211 | Aufruf einer abstrakten Methode |
(Call to abstract method) | |
212 | Fehler bei Stream-Registrierung |
(Stream registration error) | |
213 | Collection-Index außerhalb des gültigen Bereichs |
(Collection index out of range) | |
214 | Collection-Überlauf |
(Collection overflow error) | |
215 | Arithmetik-Überlauf |
(Arithmetic overflow error) | |
216 | Schutzfehler |
(General Protection fault) | |
MAUS: Programmteil - Errors | |
220 | programmteil-fehler |
221 | dito |
222 | dito |
223 | dito |
224 | dito |
Die Sommer/Winterzeit Umstellung macht die Maus automatisch. als Sysop sollte man nur darauf achten, das kein Event zwischen 2 und 3 Uhr läuft (zumindest in der Nacht). Denn das gibt Probleme. Ach ja. Der WoSysop bekommt einen Tag vorher eine Ankündigung zur Umstellung.
am letzten Sonntag im März nach 02:00 um 1 Stunde vor, am letzten Sonntag im Oktober nach 03:00 um 1 Stunde zurück (Stand Okt '97)
WoSy erhält einen Tag vorher einen Hinweis
durch einen Eintrag in MAUSVAR.DAT wird eine zweite Aktion am gleichen Tag verhindert
abschaltbar mit SommerzeitUpdate := FALSE (Default: TRUE)
ACHTUNG Wenn zwei Mäuse auf einem Rechner laufen unbedingt bei einer Maus die automatische Umstellung abschalten. Denn sonst stellt die Maus um zwei Stunden die Zeit um. Siehe auch den extra Abschnitt für Mäuse unter OS/2
Außerdem sollte man darauf achten, das die Maus auch in der Zeit nach 3 Uhr auch mal kurz aktiv ist. Wenn z.B. das MausNet schon um 2 Uhr irgendwas losläuft, wird die Uhrzeit erst beim nächsten hochfahren der Maus, also bei nächsten Start von m7com, umgestellt.
Mit folgendem kleinen Batch kann der Inhalt des Extern.CFG ins Enviroment übernommen werden.
Achtung, ist eine Zeile!!!!
for %line in (@%mauspath%extern.cfg) set%@word[0,%line]= %[quote]%@substr[%line,%@eval[%@len[%@word[0,%line]]+5], %@eval[%@len[%line]-%@len[%@word[0,%line]]-7]]%quote
Achtung: Das war eine Zeile. Empfehlenswert ist SETLOCAL, da sonst das Environment ggf. platzt.
Im Extern.CFG stehen die immer die Userdaten des gerade aktuellen oder wenn der schon beendet des, des letzten Users. Beispiel:
UserName := 'Heinz Horst'; Vorname := 'Heinz'; Nachname := 'Horst'; Benutzernummer := '123'; UserStatus := 'Z'; SysOpName := 'SysOp'; ANSI := 'TRUE'; Umlaute := 'äöüÄÖÜß'; Zeilenzahl := '0'; Alter := '88'; Geschlecht := 'M'; PLZ := 'D-12345'; Ort := 'Bärlin'; RestZeit := '16'; AnrufZahl := '99'; Zahler := 'TRUE'; BaudToUser := '17280'; BaudToModem := '38400'; FossilPort := '0'; ComPort := '1'; Spannen := 'FALSE';
Man kann also per CallChk-Batch bestimmte aktionen auslösen, wenn ein bestimmter User drin war oder für alle User Sachen in spezielle Verzeichnisse speichern (z.B. das letzte Outfile).
Wenn eine Quark unter einem hängt müssen nicht nur die Umlaute bei dein Quarkuser richtig eingestellt sein, sondern die Umlauteeinstellung der in der Servermaus für die Quark muß auch stimmen. Irgendwas um ISO-xxxx sollte ein vernüftiges Ergebnis liefern. Wenn da was falsches drinsteht, haben alle Mails der Quarkuser falsche Umlaute.
Dazu frag mal besser deinen lokalen Sysop-Chef. Nur soviel. Wenn man sich als MU irgendwo einlogt und sachen holt, sollte man eigentlich immer eine Bestätigungsmail von seiner Heimatmaus an den jeweiligen Sysop schreiben. Eine Mail Online zu schreiben ist nicht nötig und IHMO auch nicht so sinnvoll, da das jeder kann. Von der Heimatmaus nur der jeweilige User.
Auf jeden Fall sollte man in keiner Gruppen, also auch nicht in den Sysopgruppen, den Namen des aktuellen MU posten. Denn sonst kann man sich die ganze Sache auch sparen. Ach ja. Jeder der den aktuellen Namen öffentlich postet ist ein potentieller freiwilliger zum festlegen des neuen MUs samt neuen Paßwort und natürlich auch zum schreiben der Mails an alle Sysops per PM.
Wenn man einen MU einrichtet sollte man folgendes beachten
MU eintragen mit Geschlecht Programm, damit der Name nicht in irgendwelchen Userlisten etc. erscheint
Sinnvoll ist auch ein Promistatus, damit der nicht vom Mausputz gelöscht wird.
Den MU als Mitglied in der Gruppe SYSOP.PROG eintragen, damit man an die Programme kommt. Auf keinen Fall sollte der MU Sysopstatus haben!
NewU2M ist ein Programm, welches sich zu allen Mails, die eine externe ID haben, die Zuordnung zwischen Maus-ID und externer ID merkt und bei Mails, die eine externe Referenz haben, jedoch keine Maus-Referenz, diese ins Outfile schreibt. Damit hat man auch bei Mails, die über ein Usenetgate ins Mausnetz kommen, eine ordentliche Verkettung.
Klette trägt dann noch die so gefundenen IDs in die Messagebase der Maus ein, so das die Mails ganz normale MausNet-Verkettungen haben. Und wenn man schon NewU2M installiert, sollte man unbedingt auch Klette installieren, da damit die Verkettungen für alle User erstellt werden und das ganze auch noch Offline abläuft.
Da Mails mit externen IDs nur an den Gates erzeugt werden können, ist es besonders sinnvoll, wenn jedes Gate Use2Maus und Klette installiert. Solange das aber nicht der Fall ist (und das ist es bisher nicht), kann jede Maus Klette/Use2maus installieren und sich über zufriedenen User freuen.
Wie wird das nun installiert?
Ganz einfach. Erst mal das aktuelle Klette-Paket aus der Maus OF oder B3 holen, einen entsprechenden User installieren und das beiliegenden Batch in das eigenen MAUS.BAT einbauen (am besten über 'call' aufrufe') und fertig. Bei den Call-Aufrufen mußt du nur darauf achten, das Klette immer nach einen MausNet und vor eventuellen Speedtausch-Aufrufen läuft.
Um das CNF-File der Maus automatisch Auswerten zu können, hat man sich unter den auf das PMK-Token Format geeinigt. Hier die Beschreibung:
Das sog. PMK-Token Format, V2.0, 28.6.94
für die automatische Auswertung der EXPortfile- Information. Angaben, die ohne Rückfrage weitergegeben werden dürfen, fangen mit GROSSBUCHSTABEN an, Daten, die der Sysop nicht weitergeben will, mit kleinbuchstaben. (Im folgenden stehen immer nur die Großbuchstaben)
Verpflichtende Angaben: (Anmerkung von Christian Goßlar Verpflichtend ist sicher nur Betreiber und Sysop Name. Der Rest wird freiwillig sein)
%B | Name des Betreibers (Name wie in der Maus ohne Boxkürzel) |
%A | Postadresse des Mailboxstandortes oder des Betreibers. Also der
Ort, wo wichtige (gelbe) Post auch wirklich ankommt! (Ist
NICHT notwendigerweise die Mausring-Adresse! [Siehe %P])
Format: Strasse Hausnummer, PLZ Ort, Land
|
%T | Telefonnummer des Betreibers, internationales Format |
%E | alternative(!) Mailadresse(n), ggf. durch Kommata getrennt (natürlich nicht verpflichtend) |
| |
Doppemmaus |
|
%D | Damit wird bei einer Doppelmaus die Hauptmaus gekennzeichnet. Bei der H/H0 steht also in dem CNF der Maus H0 ein %D H |
| |
Sysops und Cosysops: |
|
%Sn | Name des Sysops/Cosysops (ohne @ und Boxkürzel). n = fortlaufende Nummer |
%An | Postadresse des entsprechenden Sysops. |
%Tn | Telefonnummer des entsprechenden Sysops |
%En | alternative(!) Mailadresse(n), ggf. durch Kommata getrennt |
Wichtig:
| |
| |
Gast-Sysops und Vertreter mit anderer Sysop-Heimatbox: |
|
%GSn | Name des Gast-Sysops, ACHTUNG: Inklusive @ und Boxkürzel der Heimatmaus! |
%GAn | Postadresse des entsprechenden Sysops |
%GTn | Telefonnummer des entsprechenden Sysops |
%GEn | alternative(!) Mailadresse(n), ggf. durch Kommata getrennt |
Wichtig:
| |
Kommunikation: |
|
%Mn | Modulationsart, n=Modemport (beginnend bei 1)
|
%Fn | - Fehlersicherung/Kompression, n=Modemport (beginnend bei 1) Es
wird nur der maximal mögliche Wert einer Klasse genommen.
Gültige Werte sind:
|
%In | Rufnummer des Ports, falls abweichend von der Mausnummer. War zuerst für ISDN gedacht, daher das I als Kürzel. Internationales Format, wie in der Maus. |
Mausring: |
|
%P | Postadresse, an die der Mausring geschickt werden soll, wenn
diese abweichend von %A (=Mailboxstandort oder Betreiberadresse).
Format: Empfängername, Strasse Hausnummer, PLZ Ort, Land
|
Gateways: |
|
%UnN | Netzname des anderen Netzes (z.B. FidoNet, Seven, Z-Netz) |
%UnB | Name des Gateway-Partners |
%UnE | E-Mail Adresse des Gateway-Partners in dessen Netz(!) |
%UnM | E-Mail Adresse des Gateway-Partners von der Maus aus. (Gleichzeitig ist das ein Adressierungsbeispiel) |
%UnR | Weitere Informationen (können mehrere Zeilen sein) Die Gateways werden von 1 an durchnumeriert. |
Sonstiges: |
|
%N | Name der Mailbox, z.B. "MAUS AC2", "QUARK L" |
%O | Organisation/Firma, falls die Maus von einem Verein oder einer Firma betrieben wird. |
%HW | Verwendete Maschine und Hardware. |
%OS | Betriebssystem, unter dem die Box fährt. Beide freies Format, eine Zeile sollte aber ausreichen! |
%L | Geographische Lage des Systems. Format:
|
%$ | Höhe des Mausbeitrages |
%R | Beliebige Kommentare für menschliche Leser |
So sähen die Angaben für die AC2 aus (man beachte die
Groß/Kleinschreibung):
%N Maus AC2
%L 50 46 N / 06 06 E city
%hw 386/40, 8MB, 100MB
%os MS-DOS 5.0, NW3.12
%B Michael Keukert
%a Elsaßstraße 58, 52068 Aachen, Deutschland
%t 0241-513297
%S1 Stefan Rupp
%a1 Turpinstraße 140, 520xx Aachen, Deutschland
%t1 0241-536002
%r Modem 1 = Telebit Worldblazer
%m1 V32B, TPEP
%f1 V42B
%r Modem 2 = Teles.S0 16 Bit ISDN-Steckkarte
%m2 ISDNC
%i2 +49-241-9019019
%U1N InterEUnet
%u1B Guido Bunsen, RWTH-Aachen
%u1E guido@pool.informatik.rwth-aachen.de
%u1M guido@pool.informatik.rwth-aachen.de
%U2N GerNet
%U2B Michael Wilde, Heise Verlag
%U2E Michael Wilde, 21:100/49
%U2M Michael Wilde @ GERNET 21:100/49
%U2R Die AC2 ist Node im Gernet. Adresse 21:100/9
%u3N FidoNet
%u3B Erik Schmidt
%u3E Erik Schmidt, 2:2452/102
%u3M Erik Schmidt @ FTN 2:2452/102
%u3R Der Gateway ist nur lokal bekannt.
%u3R Die AC2 ist Node im FidoNet. Adresse 2:2452/130
%$ 40.-/Jahr
Und wenn jemand den genauen Standort der Maus braucht, bitteschön:
aachen, deutschland | 50.46T | 6.06Fmez |
augsburg, deutschland | 48.22T | 10.53Fmez |
bergisch-gladbach, deutschland | 50.59T | 7.08Fmez |
berlin, deutschland | 52.33T | 13.22Fmez |
bielefeld, deutschland | 52.02T | 8.32Fmez |
bochum, deutschland | 51.29T | 7.13Fmez |
bonn, deutschland | 50.44T | 7.06Fmez |
bottrop, deutschland | 51.31T | 6.55Fmez |
braunschweig, deutschland | 52.16T | 10.32Fmez |
bremen, deutschland | 53.05T | 8.48Fmez |
bremerhaven, deutschland | 53.33T | 8.35Fmez |
chemnitz, deutschland | 50.50T | 12.55Fmez |
cottbus, deutschland | 51.46T | 14.20Fmez |
darmstadt, deutschland | 49.52T | 8.39Fmez |
dessau, deutschland | 51.50T | 12.15Fmez |
dortmund, deutschland | 51.32T | 7.27Fmez |
dresden, deutschland | 51.03T | 13.45Fmez |
duisburg, deutschland | 51.26T | 6.45Fmez |
düsseldorf, deutschland | 51.13T | 6.47Fmez |
erfurt, deutschland | 50.58T | 11.02Fmez |
erlangen, deutschland | 49.36T | 11.01Fmez |
essen, deutschland | 52.43T | 7.56Fmez |
frankfurt, deutschland | 50.07T | 8.41Fmez |
freiburg, deutschland | 48.00T | 7.51Fmez |
freising, deutschland | 48.24T | 11.44Fmez |
gelsenkirchen, deutschland | 51.31T | 7.06Fmez |
gera, deutschland | 50.52T | 12.05Fmez |
göttingen, deutschland | 51.32T | 9.56Fmez |
hagen, deutschland | 51.21T | 7.28Fmez |
halle, deutschland | 51.28T | 11.58Fmez |
hamburg, deutschland | 53.33T | 10.00Fmez |
hamm, deutschland | 51.41T | 7.48Fmez |
hannover, deutschland | 52.22T | 9.43Fmez |
heidelberg, deutschland | 49.25T | 8.42Fmez |
heilbronn, deutschland | 49.08T | 9.13Fmez |
herne, deutschland | 51.33T | 7.13Fmez |
jena, deutschland | 50.56T | 11.35Fmez |
kaiserslautern, deutschland | 49.27T | 7.45Fmez |
karlsruhe, deutschland | 49.01T | 8.24Fmez |
kassel, deutschland | 51.19T | 9.30Fmez |
kiel, deutschland | 54.20T | 10.08Fmez |
koblenz, deutschland | 50.21T | 7.36Fmez |
köln, deutschland | 50.56T | 6.57Fmez |
krefeld, deutschland | 51.20T | 6.34Fmez |
leipzig, deutschland | 51.20T | 12.25Fmez |
leverkusen, deutschland | 51.01T | 6.59Fmez |
lübeck, deutschland | 53.52T | 10.42Fmez |
ludwigshafen, deutschland | 49.29T | 8.27Fmez |
magdeburg, deutschland | 52.08T | 11.37Fmez |
mainz, deutschland | 50.00T | 8.15Fmez |
mannheim, deutschland | 49.29T | 8.28Fmez |
moers, deutschland | 51.27T | 6.39Fmez |
mönchengladbach, deutschland | 51.12T | 6.26Fmez |
mülheim, deutschland | 51.26T | 6.53Fmez |
münchen, deutschland | 48.09T | 11.35Fmez |
münster, deutschland | 51.58T | 7.38Fmez |
neuss, deutschland | 51.12T | 6.42Fmez |
nürnberg, deutschland | 49.27T | 11.05Fmez |
oberhausen, deutschland | 51.28T | 6.51Fmez |
offenbach, deutschland | 50.06T | 8.46Fmez |
oldenburg, deutschland | 53.10T | 8.12Fmez |
osnabrück, deutschland | 52.16T | 8.03Fmez |
paderborn, deutschland | 51.43T | 8.46Fmez |
pforzheim, deutschland | 48.53T | 8.42Fmez |
potsdam, deutschland | 52.24T | 13.04Fmez |
recklinghausen, deutschland | 51.37T | 7.12Fmez |
regensburg, deutschland | 49.01T | 12.06Fmez |
remscheid, deutschland | 51.11T | 7.12Fmez |
rostock, deutschland | 54.05T | 12.08Fmez |
saarbrücken, deutschland | 49.14T | 7.00Fmez |
salzgitter, deutschland | 52.05T | 10.20Fmez |
schwerin, deutschland | 53.38T | 11.23Fmez |
siegen, deutschland | 50.52T | 8.02Fmez |
solingen, deutschland | 51.11T | 7.05Fmez |
stuttgart, deutschland | 48.46T | 9.11Fmez |
ulm, deutschland | 48.25T | 10.00Fmez |
wiesbaden, deutschland | 50.05T | 8.15Fmez |
witten, deutschland | 51.26T | 7.20Fmez |
wolfsburg, deutschland | 52.26T | 10.48Fmez |
wuppertal, deutschland | 51.16T | 7.11Fmez |
würzburg, deutschland | 49.48T | 9.56Fmez |
zwickau, deutschland | 50.44T | 12.30Fmez |
amstetten, österreich | 48.07T | 14.52Fmez |
baden, österreich | 48.01T | 16.14Fmez |
braunau, österreich | 48.16T | 13.02Fmez |
bregenz, österreich | 47.30T | 9.46Fmez |
bruck/mur, österreich | 47.25T | 15.17Fmez |
dornbirn, österreich | 47.25T | 9.44Fmez |
eisenstadt, österreich | 47.51T | 16.31Fmez |
feldkirch, österreich | 47.14T | 9.36Fmez |
graz, österreich | 47.05T | 15.22Fmez |
hallein, österreich | 47.41T | 13.06Fmez |
innsbruck, österreich | 47.16T | 11.24Fmez |
kapfenberg, österreich | 47.26T | 15.18Fmez |
klagenfurt, österreich | 46.38T | 14.20Fmez |
klosterneuburg, österreich | 48.18T | 16.19Fmez |
krems, österreich | 48.25T | 15.36Fmez |
leoben, österreich | 47.23T | 15.06Fmez |
linz, österreich | 48.19T | 14.18Fmez |
mödling, österreich | 48.05T | 16.28Fmez |
salzburg, österreich | 47.48T | 13.03Fmez |
sankt pölten, österreich | 48.13T | 15.37Fmez |
steyr, österreich | 48.04T | 14.25Fmez |
ternitz, österreich | 47.43T | 16.02Fmez |
traun, österreich | 48.13T | 14.14Fmez |
villach, österreich | 46.37T | 13.51Fmez |
wels, österreich | 48.10T | 14.02Fmez |
wien, österreich | 48.12T | 16.22Fmez |
wiener neustadt, österreich | 47.48T | 16.15Fmez |
wolfsberg, österreich | 46.50T | 14.50Fmez |
Kurz und knapp. NIX
Nur dadurch, das man nie etwas in eine vernetze Gruppe schreibt, könnte man es verhindern. Es reicht aber aus, einmal eine Mail in eine MausNet-Gruppe zu schreiben, die exportiert wird. Und schon kann man Werbung bekommen.
Siehe auch die Artikel über das IN-und Kommerz bzw das FAQ dazu
Sinnvoll ist auch dieser Hinweis
Von: Uwe Rößner @ MGN (Mi, 12.02.97 18:14)
MId: 199702121814.a21224@mgn.maus.de
Hallo,
AM> Dann ist der Müll aber schon da. Ich hoffe, daß man
demnächst
AM> gegen Werbung per Mail genauso rechtlich vorgehen kann, wie
AM>gegen Werbung per FAX.
Das kannst Du, laut US-Gesetz, jetzt schon. ;-) Folgenden Text an den
Absender und an den postmaster und Ruhe ist. Er stand vor kurzem in der
c't. Ist allerdings erst dann sinnvoll, wenn man mehrere Mails vom selben
Account über einen gewissen Zeitraum bekommt, da diese meistens
gefaked sind, aber wem sag ich das... ;-)
By US Code Title 47, Sec. 227(a)(2)(B), a computer/modem/printer meets
the definition of a telephone fax machine. By Sec. 227(b)(1)(C), it is
unlawful to send any unsolicited advertisement to such equipment. By
Sec.227(b)(3)(C), a violation of the aforementioned section is punishable
by action to recover actual monetary loss, or $500, whichever is greater,
for each violation.
I will report any further violations from your site, which I get
knowledge of to abuse@postoffice.us.
Gruß, Uwe.
Ersteinmal ist Werbung im MausNet unerwünscht.
Außerdem ist noch folgendes zu beachten. Bei reinen MausNet-Gruppen ist es nur Sache des MausNet, es ist arg stören und der User kann entsprechend zugeflammt werden. Wenn das ganze aber in irgendeiner mit dem InterNet vernetzen Gruppen stattfindet, sollte unbedingt der Abschnitt IN und Kommerz beachtete werden und das auch dem User deutlich gemacht werden.
Wenn die Werbemail aus dem Internet kommt, kann man eigentlich außer rumjammern, den Autor anschreiben, den Postmaster des entsprechenden Systems anschreiben, nix machen.
Wenn man so eine Mail aus der Maus K2 bekommt
Hi SysOp,
aus Deiner Box sind heute in K2 MessageId-Dupes angekommen. Bitte ueberpruef ("msgid xy") & korrigier ("msgid set ####") das doch mal.
sollte man genau das tun, was dort beschrieben steht.
erstmal das Programm MSGID besorgen
MSGID mit dem Parameter xy starten xy steht für das Kürzel der eigenen Maus
Es wird folgende Ausgabe erzeugt:
A-MsgIds der MAUS XY Chronologisch tauchen auf: 25 Msg(s): 7 .. 1185 06.09.96 .. 23.10.96 142 Msg(s): 77 .. 247 23.11.96 .. 02.12.96 106 Msg(s): 99 .. 204 02.12.96 .. 07.12.96 Numerisch sortiert (1000er Schritte): 0 .. 1999
Das bedeutet, das nicht alle Mails eine aufsteigende ID haben, sondern das neuere Mails eine kleinere ID haben. Und das erzeugt Probleme.
Nun mit MSGID eine neuen höhere ID in der Maus erzeugen, z.B. so:
MSGID set xxxx
XXXX sollte so gewählt werden, das es ca. 1000 über der
hösten bisherigen ID liegt.
Danach bitte unbedingt mit
MSGID LLIST xy
kontrolieren, ob alles geklappt hat.
Siehe auch Was tun nach einem Crash?
Frage: Was kann man machen, wenn James meldet, das nur noch sehr wenig freie MsgIDs in der Maus vorhanden sind?
Ich, Christian Goßlar, bin da so vorgegangen:
Online in die Mauseinloggen, Mitteilungen anrufen, Stichwort listen, alle aufrufen. Dann bekommt man als Liste die ältesten Mails in der Maus angezeigt.
Zu den angezeigenten Gruppen die Mausputz-Parameter MsgOutDefaultKB, MsgOutDefaultAnzahl und MsgOutDefaultTage kontrollieren
vielleicht nochmal mit dem Programm msgid.exe die Verteilung der Message-IDs kontrollieren.
Die Mausputz-Parameter entsprechend ändern
Um jetzt eine Erfolg feststellen zu können, muß der Mausputz aufgerufen werden. Aber wenn man den nicht zum 'krunchen' auffordert, wird man nach dem MausPutz keine Änderung der Message-ID Verteilung feststellen. Also Mausputz /A (siehe auch Aufrufparameter des MausPutz) aufrufen.
Das war es
beten:-)
Wenn nur die Messages-Base Probleme bereitet, erst einmal FIXRNUM starten und gucken was gemeldet wird. Und lieber die öffentliche Messagesbase wegschmeissen, als daß durch Fehler Dupes und Schrottmails erzeugt werden (z.B. Mails aus geheimen Gruppen in Maus.Info:-). Bei der Messagesbase der PMs ist das gleiche. Nur ist es dabei noch wichtiger, das die i.O. ist. Denn falsches Zustellen ist dort noch problematischer. Deshalb die noch viel eher löschen.
Zum installieren einer neuen Messagebase benötigst du eine leere Messagesbase, die aus den Dateien:
MSG-ALLG.DAT und PAR
MSG-PERS.DAT und PAR
besteht. Eine leere Messagebase liegt entweder auf der Maus original Diskette oder auch in Sysop-Programmteil diverser Mäuse (z.B. AC2).
Nach dem Neuinstallieren aber unbedingt mit MSGID die IDs der öffentlichen und der PMs deiner Maus hochsetzen. Und zwar auf Werte, die über denen der letzte Mails deiner Maus liegen. Dazu entweder zuhause im Frontend nachgucken oder mit MSGID in der Servermaus die letzten IDs der eigenen Maus feststellen. Am besten noch 1000-2000 draufaddieren.
Das sollte mach auch auf jeden Fall machen, wenn man mal ein Messagebasebackup in die Maus einspielt. Auch wenn es nur ein paar Stunden alt ist. Man erzeugt Sprünge in der Message-ID Reihenfolge und das gibt nur Probleme.
Also nach neuinstallation der Messagebase immer MSGID aufrufen und die Messagesid neu setzten. Das gilt auch für den Fall, das man die BackUp-Messagesbase installiert (sofern vorhanden) und wenn nach dem Backup ein MausNet lief.
Gesetzt wird die Message-ID z.B: so:
msgid set 3000
Außerdem muß man auch für alle User den Messagepointer auf einen richtigen Wert setzen. Wenn man eine neue Messagesbase installiert hat, ist das der Wert eins, sonst ein eintsprechen höherer (je nachdem von wann das Backup ist). Das setzten des Messagespointers für alle User geht von Sysop-Menü unter '(L)öschen/(#) setzen'. Wenn man das nicht macht, wundern sich die User beim nächsten Tausch, das sie keine Mails bekommen.
Danach bitte unbedingt
msgid list xx
testen, ob alles auch geklappt hat.
Siehe auch das Kapitel zum MSGID Programm.
Und zum nachholen des Netzes dort nachlesen.
Manchmal kann ja ein Netzpaket verloren gehen. Was tun? Erstmal in der Serverbox nachfragen, ob dort nicht noch ein Backup des Netzpaketes liegt. Wenn nicht in der Netzzentrale nachfragen. Dort laufen eigentlich Batche, die jedes Netzpaket einen Tag aufheben. Auch wenn es dann ein etwas größeres Netzpaket ist. Das macht nix. Einfach entsprechend umbenennen und dann Mausnet /import aufrufen. Das MausNet schmeist schon alle Mail und PMs weg, die nicht für die eigene Maus bestimmt sind. So geht also nix verloren.
Im Moment gilt folgendes:
maximale Userzahl | 16382 (Achtung, kostet viel Speicher!) |
max. Gruppenanzahl | 512 (lokal und Netzweit) |
Programme | ab 6550 Programme im öffentlich PT oder entsprechend vielen in einem Gruppen-PT gibt es Probleme (Sortierung klappt nicht mehr. Wenn auch irgendwie alphabetisch mitsortiert wird, liegt die Grenze schon bei 2448) |
Gruppen-Programmteile | Es sind nur maximal *30* gleichzeitig möglich |
maximale Messagezahl | 65536 in der Messagebase (aber wer braucht schon so viel auf einmal?) |
Modemports | Keine Ahnung. Drei gehen bei der Maus auf jeden Fall. Beim MausNet gehen im Moment IHMO nur zwei Ports |
Gruppennamen | Die Gruppennamen dürfen maximal 40 Zeichen lang sein |
Dollardatum | Das Datum darf nicht über das Jahr 2000 gehen. Das gibt Probleme. |
Nachrichtenlänge | Jede Nachricht kann maximal 16KB lang sein. Das ist so fest in
der Maussoft verdrahtet und wird sich erst mit der Maus 9(?)
ändern. Es gibt also keine Konfigvariable um das zu
ändern. Gerechnet wird nur der Mail-Body ohne eventuelle
Doppelpunkte, die im Infile dovor stehen.
|
Programmteil-Taggen | Bei mehr als 50 selektierten/angezeigten Programmen stürzt die Maus ab. |
Was tun, wenn man mal Mails mit Datum in der Zukunft in der Messagebase hat und wie stellt man das fest?
Feststellen durch MSGID Aufruf z.B.
Die Folge von solchen Fehlern ist die, das solnage keine Mails mehr aus der Maus exportiert werden, bis das Zukunftsdatum erreicht ist.
Abhilfe:
ALLE Mails mit dem Zukunftsdatum löschen (Sysopmenu). Auch die persönlichen! Dann Mausputz aufrufen, aber so, das die MBase gekrunscht (Parameter /f) wird (das ist wichtig). Nun die beiden *.NET Files im Mausverzeichnis löschen und einmal MAUSNET EXPORT aufrufen. Dann MAUS starten und Testmails eingeben. Maus beenden und MAUSNET Export nochmal aufrufen. Nun sollten die Testmails exportiert werden. Wenn ja, die Testmails in der Maus löschen und mit Hilfe von MAUSNET EXPORT? die nicht exportieren Mails rausschicken. (hier ist die ID letzte ID anzugeben, die in einem MAUSNET-Logfile noch auftaucht. Das war's
Dazu am besten das FAQ aus dem GerNet
Gruppe: GerNet
Wg.: GerNet: FAQ zu Echo GERNET
Von: Lutz Labs @ GerNet 21:100/49 (So, 13.04.97 07:34)
Box: c't-Mailbox, Hannover
FAQ des GerNet (Stand 17.12.95)
Q: | Ist das Echo GERNET ein Echo, in dem Kontakt zu den Redakteuren der c't besteht? | ||||||||||||||||||||||||
A: | Nein. Die Redakteure haben mit dem Echo nichts zu tun. Die Redakteure der c't schauen in die Echos ct.ger, ct.support, ct.projekte und ct.pruefstand rein, die ELRAD-Redakteure in das Echo elrad.ger. Dieses Echo dient der Diskussion ueber das GerNet. Jegliche Anfragen zu Themen, die in der c't besprochen wurden, sind offtopic. Das Echo GERNET ist kein c't-Supportecho! | ||||||||||||||||||||||||
Q: | Darf ich als Point denn im Echo GERNET auch schreiben? | ||||||||||||||||||||||||
A: | Ganz ausdruecklich ja. Auch Points haben schliesslich das Recht, an der Gestaltung eines Netzes teilzunehmen. Es gibt kein Echo speziell fuer Sysops. | ||||||||||||||||||||||||
Q: | Gibt es auch Support-Echos fuer die iX oder die Gateway? | ||||||||||||||||||||||||
A: | Ein iX-Echo wird es in absehbarer Zeit nicht geben. Die Redakteure der iX sind personell nicht in der Lage, ein solches Echo auch zu betreuen. Bei der Gateway dauert der Entscheidungsprozess noch an. | ||||||||||||||||||||||||
Q: | In welche Netze wird das GerNet gegatet? | ||||||||||||||||||||||||
A: | Diverse. Siehe naechste Mail. FTN-kompatible Netze gehoeren auch dazu. Das wird geduldet, ist aber nicht unbedingt erwuenscht. | ||||||||||||||||||||||||
Q: | Darf ich auch mit einer Fido-Aka hier schreiben? | ||||||||||||||||||||||||
A: | Ungerne. Aber wenn Du damit leben kannst, dass Dich ein Reply per NetMail nie erreicht, na dann... Wenn Du ueber ein "offizielles" Gate wie z.B. 21:104/0.999 schreibst, dann ist die Erreichbarkeit gesichert. Dort wird die Adresse umgesetzt, bei den meisten anderen, die die Echos einfach unter Fido-Aka weiterleiten, nicht. | ||||||||||||||||||||||||
Q: | Wie komme ich in die c't-Mailboxliste? | ||||||||||||||||||||||||
A: | NetMail an Kalle Probst, Redaktion c't, 21:100/49. Oder telefonisch waehrend der Hotline (13:00 .. 14:00) unter 0511-53 52 517. Oder Mail an kp@ct.heise.de. Zur Not an mich, ich leite die Mails dann weiter. | ||||||||||||||||||||||||
Q: | In welchen Echo im GerNet kann ich Verkaufsangebote posten? | ||||||||||||||||||||||||
A: | In keinem. Das Echo RAM-Boerse wurde geschlossen. | ||||||||||||||||||||||||
Q: | Wer ist der GerNet-Koordinator und wie erreiche ich ihn? | ||||||||||||||||||||||||
A: | Lutz Labs (ll@ct.heise.de oder 21:100/49@GerNet) | ||||||||||||||||||||||||
Q: | Gibt es Rules fuer die Echos? | ||||||||||||||||||||||||
A: | Per Filerequest oder in der Mailbox gibt es ein File namens GERNET.ZIP (Magic: GERNET), in dem die Echorules und diverses anderes beschrieben sind. | ||||||||||||||||||||||||
Q: | Wie bekomme ich eine GerNet-Aka? | ||||||||||||||||||||||||
A: | Freq GERNET. Da ist auch eine aktuelle Nodeliste drin. Wende Dich an den naechsten Hub und beantrage sie bei ihm. | ||||||||||||||||||||||||
Q: | Wer ist der Moderator des Echos GERNET? | ||||||||||||||||||||||||
A: | Offiziell niemand. Im Bedarfsfall NetMail an mich. | ||||||||||||||||||||||||
Q: | In welchen Echos soll ich meine Fragen crossposten? | ||||||||||||||||||||||||
A: | In gar keinen. Es sollte ausreichen, die Frage in einem Echo zu stellen, sonst zieht sich die Diskussion ueber mehrere Echos und ist damit voellig unuebersichtlich. | ||||||||||||||||||||||||
Q: | Wo bekomme ich alte Hefte her? | ||||||||||||||||||||||||
A: | Siehe Seite 12, rechts unten in jeder c't. Bis zu 2 Jahre alte Hefte sind meistens noch lieferbar, ansonsten koennen Kopien der Artikel bestellt werden. | ||||||||||||||||||||||||
Q: | Wo bekomme ich die Platinen oder die Software zu den Projekten? | ||||||||||||||||||||||||
A: | Bei eMedia. Anzeige in jeder c't, Seite siehe Inserentenverzeichnis. | ||||||||||||||||||||||||
Q: | Gernet.PC.HARD oder .AMIGA - Was sind das eigentlich fuer Echos? | ||||||||||||||||||||||||
A: | Diese Echos sollen der Entlastung der CT.GER dienen. Hier wird eben nicht systemuebergreifend diskutiert. Die Redaktion schaut in diese Echos nicht rein, dort kann man also keine Antworten von uns erwarten. | ||||||||||||||||||||||||
Q: | Wann gibt es bei der ELRAD-Mailbox endlich mal die Moeglichkeit des Filerequests? | ||||||||||||||||||||||||
A: | Bald... | ||||||||||||||||||||||||
Q: | Wie kommen meine Points in die Pointliste? | ||||||||||||||||||||||||
A: | Der Pointlistkeeper im GerNet ist Hinrich Donner, 21:493/0. Bitte keine Updatefiles hierher schicken, hier bleiben sie unbearbeitet liegen. Fuer die Fakenetnummer bitte beim Hinrich melden. | ||||||||||||||||||||||||
Q: | Meine Telefonnummer hat sich geaendert - wem soll ich das sagen? | ||||||||||||||||||||||||
A: | Weisst Du noch, bei wem Du damals die Nodenummer beantragt hast? Dann schreib den man auch mal wieder an. Falls Du auch in der c't-Mailboxliste drin bist, dann auch eine Mail an Kalle Probst (21:100/49), am besten vor dem 25. des Monats - sonst wird die Aenderung erst im uebernaechsten Heft vermerkt. | ||||||||||||||||||||||||
Q: | Wie ist denn das Magic fuer die aktuelle Nodeliste? | ||||||||||||||||||||||||
A: | NODELIST. Bei der Gelegenheit die anderen Magics:
|
ACHTUNG
Von: Timm Ganske @ OF (So, 30.06.96 23:33)
MId: 199606302333.a6767@of.maus.de
Kommentar zu A57189@OF in der Gruppe CT.Support
Falls jemand gefragt wird:
Lutz Labs @ GerNet 21:100/49 am 17.06.96 in CT.Support (ID MSGID_21=3A100=2F49.0_1c567f02@fidonet.org):
>wir haben etwas umgestellt. Die Domain ist jetzt heise.de, sonst
>bleibt alles beim alten. ix.de ist aber noch ein paar Wochen
gültig.
Am meisten bringt es, viel RAM für einen Festplattencache zu installieren. Wenn man dann noch mutig ist und den Cache als Schreibcache installiert, dann geht die Maus wirklich ab. Aber auch ein reiner Lese-Cache bringt viel. Wenn möglich den Cache auch so einstellen, das immer einige Sektoren mehr gelesen werden als gerade angefordert werden.
Außerdem sollte immer mal wieder die Platte mit Defrag aufgeräumt werden. Dann bringt das Vorauslesen von Sektoren auch noch mehr, als wenn z.B. die Messagesbase total verteilt auf der Platte rumliegt.
Als Rechner reicht für einen normale Maus, auf der nur die Maus laufen soll, locker ein 486 mit 8MB RAM erstmal aus. Und bevor Geld in einen schnellen Rechner gesteckt wird, sollte man IHMO RAM kaufen.
Dazu jetzt mal mei erster Erfahrungsbericht. Wir haben hier vor zwei Wochen sowas eingerichtet. Zuerst die Voraussetzungen:
einen UUCP-Acount
eine Programm zu abholen und senden der Mails. Wir benutzen im Moment FXUUCICO. Es soll aber auch mit dem UUCICO von Waffel gehen.
Eine Software zur Umsetzung der UseNet-Mails auf Mausformat und umgekehrt (wir benutzene Erwinsgate)
und viel Zeit
Als erstes Zuerst mußt mal einen Gate-User in der Maus installieren. Das geht ja recht einfach und ist im nächsten Kapitel beschrieben. Dann den FXUUCIO installieren und vielleicht einen Probeanruf um etwas Daten zum spielen zu haben. Und als letztes muß Erwinsgate eingerichtet werden. Das ist aber mit dem Hilfe-Text von Georg kein Problem. Hauptsächlich müssen Ordner eingerichtet und eingetragen werden und das GATE.BAT, das als Beispiel beiligt, an deine eigene Konfiguration angepaßt werden. Ach ja. Du muß man noch in der Maus die Gruppen lokal einrichten einrichten, die man aus dem Internet importieren will.
Achtung
Im MausNet darf eine Gruppe nur an einem Gate importiert werden. Man kann zwar auch MausNet-Gruppe, die eigentlich bei einem anderen Gate importiert werden, lokal importieren, nur gibt es oft Probleme, einige spezielle Schalter müssen gesetzt werden usw. Für den Anfang ist es deshalb sicherer, wenn man die Gruppen, die importieren werden sollen lokal einen anderen Namen als im MausNet haben. Ist zwar etwas unschön aber sicher. Z.B. einfach durch einen kleinen Vorsatz wie IN. Wenn man sich dann später besser mit dem Gate auskennt, kann man das ja problemlos ändern.
So. Und nun geht es ans testen. Also die Batche von Erwinsgate aufrufen, sich das erzeugte Infile angucken und in die Maus eintauschen und dort testen. Und die Log-Files gut angucken.
Ach ja. Wenn man seinen Usern eine Freude bereiten will, dann installiert man am besten auch noch Klette und Use2Maus. Damit werden die UseNet Mails mit Maus-IDs versehen und diese direkt in die Mausdatenbank eingetragen, so daß alle User problemlos eine Verkettungen haben.
Erst mal einen User mit negativer Benutzernummer einrichten. Vorname 'GATE' und Nachname so wie er im mn-xx.cnf steht. Die Maus legt dann ein MU-xxxx.DAT File an, das die Userdaten dazu enthält. Dort muß noch der Nachname mit einem führenden Punkt '.' versehen werden. Dann noch das Gate in die CNF Datei eintragen, fertig.
Spätestens seit der Maus 7.95h geht es aber noch einfacher. Einfach in dem CNF-File der eigenen Maus das Gate eintragen und MnConfig aufrufen. Die Maus legt dann selber einen entsprechenden Gate-User an.
Beispiel: Lokales Gate in der Maus B3, das Gate ist als Benutzer 'GATE .B' unter der Nummer -42 in der B3 eingerichtet. Die B3.CNF sieht folgendermaßen aus:
; Gates. Format: Name,Nummer,Transport
; Name: .* ist dasselbe wie alle Top-Level-Domains
; Transport: "*"=alle, "-"=keiner,
; oder "MS,.maus.de" = MS und alle .maus.de-Mäuse
G.b,-42,B3
In MAUS.BAT muß dann nur noch ein entsprechender Aufruf eingebaut werden, fertig. Hier auch mal das Beispiel dazu:
m7com /t gate .b infile.txt outfile.txt
Und man sollte darauf achten, das der GATE-User in die Read-Only oder anderen Gruppen mit Zugangsbeschränkung, auch eingetragen ist. Sonst kann der dort keine keine Mails reinschreiben. Das gleiche gilt natürlich für ein Gate, das Mails exportieren soll. Achtung Nach der dem einrichten des Gate-Users sollte einmal der MnConfig aufgerufen werden. Einmal um die richtige Konfiguration zu testen und zweitens kann man sonst auch nicht den User in Gruppen eintragen. Den gibt es nämlich dann für die Maus garnicht.
Um lokale Gruppen mit einer anderen Maus zu vernetzen gibt es z.B. das Programm MLZWO (Maus-2-Maus Gate) von Marcus Schmidtke @ BM
Ganz einfach. Erstmal eine neue Netznummer von Jörg besorgen. Dann ein entsprechendes CNF-File in denNetIOPath legen und den MNConfig aufrufen. Hier mal ein Beispiel-CNF
; Boxkürzel - dies muß die erste Angabe sein:
*B9
; Netznummer (Fremdbox mit "-" davor):
; Boxname [max. 30]:
NQUARK Berlin 9
; Telefonnummer (Muster: +49-251-77262; fehlt=nicht anrufen):
T+49-30-999999999
; Kürzel der Serverbox (fehlt für Baumwurzel):
-B
; Portdefinition
P#1
PT+49-30-999999999
PKA
; Primäre (D) und sekundäre (Z) Domains:
D.maus.de
Z.maus.sub.org <<- die gibt es nicht mehr
; Gates. Format: Name,Nummer,Transport
; Name: .* ist dasselbe wie alle Top-Level-Domains
; Transport: "*"=alle, "-"=keiner,
; oder "MS,.maus.de" = MS und alle .maus.de-Mäuse
; entfällt (nur für Gateways)
; SysOp-Infos:
s Weitergabe der folgenden Informationen an Nicht-Mausnet-Sysops
s ist nicht gestattet. Ausnahme: Zeilen die mit '%' und einem
s Großbuchstaben beginnen.
und dann das übliche
Wenn alles richtig geklappt hat, dann wird die Fremdbox erkannt, es wird ein MU-0XXX.DAT File in im MausPath angelegt (xxx entspricht der Netznummer, also hier MU-0999.DAT). Auf jeden Fall aber auch ins MausNet.Log schauen, ob alles in richtig ablief. Dann die Maus starten, ins Sysop-menü gehen und über Benutzerdaten die Fremdboxdaten angucken. Achtung. Die Fremdbox hat eine negative Benutzernummer, hier also wieder -999. Auf jeden Fall muß das Paßwort verändert werden.
Nun kann die Fremdbox anrufen. Der Benutzerstatus der Fremndbox ist überings egal. Auch mit dem normalen Userstatus bekommt die Fremndbox alle Gruppen, die Sysop-Infofiles usw.
Noch eine besonderheit. Wenn die Fremdbox neue Gruppen per tausch bestellt, werden die scheinabr nicht sofort bestellt und der Fremdbox im tausch mitgeschickt, sondern die Box bekommt die Gruppe erst nach einem MNConfig-Lauf. Dann steht auch soetwas im MausNet.Log
>Konfiguriere Fremdbox QUARK Berlin 9
>bekommt Gruppe SYSOPS (Netz #1)
>bekommt Gruppe BIGFOOD (Netz #3)
>bekommt Gruppe NETGAMES (Netz #4)
Hier die komplette Belegung eines Null-Modem Kabels, das passend für die MAUS zu benutzen ist. Wichtig ist die Belegung des Pins 8 (DCD). Wenn die Verbindung schon im Kabel gemacht ist braucht man bloß noch auf MAUS-Seite die Pins 8-20-6 zu verbinden.
Hier die komplette Belegung für zwei mal 25 pol. :
25 polig 25 polig 1 (GND) -------------------- 1 (GND) 7 (SG) --------------------- 7 (SG) 2 (TX) --------------------- 3 (RX) 3 (RX) --------------------- 2 (TX) 4 (RTS) -------------------- 5 (CTS) 5 (CTS) -------------------- 4 (RTS) +-- 8 (DCD) -------/ /---------- 8 (DCD)-+ <== nicht verbinden! +--20 (DTR) -------------------- 6 (DSR) | 6 (DSR) --------------------20 (DTR)-+
Hier das ganze auch nochmal für 25 auf 9pol. :
25 polig 9polig 7 (SG) ----------------- 5 (SG) 2 (TX) ----------------- 2 (RX) 3 (RX) ----------------- 3 (TX) 4 (RTS) ----------------- 8 (CTS) 5 (CTS) ----------------- 7 (RTS) +-- 8 (DCD) -------/ /------- 1 (DCD)-+ <== nicht verbinden! +--20 (DTR) ----------------- 6 (DSR) | 6 (DSR) ----------------- 4 (DTR)-+
Und nochmal 9pol auf 9pol.:
+--1 (DCD) --------/ /------- 1 (DCD)--+ | 2 (RX) ------------------ 3 (TX) | | 3 (TX) ------------------ 2 (RX) | +--4 (DTR) ------------------ 6 (DSR) | 5 (SG) ------------------ 5 (SG) | 6 (DSR) ------------------ 4 (DTR)--+ 7 (RTS) ------------------ 8 (CTS) 8 (CTS) ------------------ 7 (RTS)
hier mal noch eine weiterführende Erklärung:
3. Rechner-Rechner (Nullmodem)
Für Datenübertragungen von Rechner zu Rechner müssen die Datenleitungen (RxD und TxD) natürlich gekreuzt werden. Das einfachste Verbindungskabel benötigt nur drei Leitungen: RxD, TxD und GND. Für LapLink z.B. genügt das. Braucht man einen Hardware-Handshake, so müssen ausserdem mindestens RTS und CTS verbunden werden, ebenfalls gekreuzt.
Benutzt man Software, die eigentlich für eine Modemverbindung gedacht ist oder die den Einschaltzustand des "Gegeners" überprüft, muss man noch weitere Signale verbinden. Da das DTE nur zwei Ausgänge hat (DTR und RTS), ein DCE aber 4 (CTS, DSR, RING und DCD) kann es nötig sein, "Falschverbindungen" einzubauen, um so z.B. das eigene DTR als fremdes DCD "vorzuspielen" oder auch das eigene DTR dem "Gegner" als DCD _und_ DSR. DTR an DSR wäre eigentlich richtig, aber wenn die Soft ein Carrier- signal braucht und (oft) DSR ignoriert...
(RTS kommt für solche Spielchen normalerweise nicht in Frage, weil es für den Handshake ständig gebraucht wird.)
Zu Testzwecken kann man auch noch einen Schalter einbauen, der den DCD-Eingang gezielt belegt, um "Carrier da" oder "Carrier weg" zu simulieren. Hier muss man gelegentlich probieren.
Es folgt die idiotensichere Variante, je nach Bedarf kann man Leitungen (oben sind die wichtigen) weglassen:
Rechner 1 Rechner 2 9pol 25pol 25pol 9pol 5 7 ---GND---------------------GND------- 7 5 2 3 ---RxD--------. ,----------RxD------- 3 2 X 3 2 ---TxD--------' `----------TxD------- 2 3 7 4 ---RTS--------. ,----------RTS------- 4 7 X 8 5 ---CTS--------' `----------CTS------- 5 8 4 20 ---DTR--------. ,----------DTR------- 20 4 X 6 6 ---DSR--o-----' `-------o--DSR------- 6 6 | | 1 8 ---DCD--' `--DCD------- 8 1
From: Alexander Güth @ AN Newsgroups: SYSOP.TECH Subject: Directport Mac od. PC Message-ID: <199611170018.a12592@an.maus.de>
Hi,
Für alle die es interessiert hier mal die PIN-Belegung eines Directportkabels (Nullmodem) zwischen MAC und Maus. Der vollständiger halber auch noch die Kabelbelegung PC - Maus.
Rechner-Rechner (Nullmodem) Mac - PC
Mac SCC/GeoPort PC RS-232 9pol (männlich) 25pol 9pol (weiblich) 1 --- HSKo / DTR --------------- CTS ---- 5 8 2 --- HSKi / CTS --------------- RTS ---- 4 7 3 --- TxD- -------------------- RxD ---- 3 2 4 --- GND -------o------------ GND ---- 7 5 | 5 --- RxD- -------|------------ TxD ---- 2 3 | 6 --- TxD+ | ,-- DCD ---- 8 1 | | 7 --- GPi / DCD ---|---------o-- DSR ---- 6 6 | | 8 --- RxD+ -------' `-- DTR ---- 20 4 9 +5 V (350mA max. nur bei GeoPort)
Dieses Kabel funktioniert nach eigenen Test zuverlässig mit dem DirectPort der Maus.
Rechner-Rechner (Nullmodem) PC - PC
Fuer Datenuebertragungen von Rechner zu Rechner muessen die Datenleitungen (RxD und TxD) natuerlich gekreuzt werden. Das einfachste Verbindungskabel benoetigt nur drei Leitungen: RxD, TxD und GND. Fuer LapLink z.B. genuegt das. Braucht man einen Hardware-Handshake, so muessen ausserdem mindestens RTS und CTS verbunden werden, ebenfalls gekreuzt. Benutzt man Software, die eigentlich fuer eine Modemverbindung gedacht ist oder die den Einschaltzustand des "Gegeners" ueberprueft, muss man noch weitere Signale verbinden. Da das DTE nur zwei Ausgaenge hat (DTR und RTS), ein DCE aber 4 (CTS, DSR, RING und DCD) kann es noetig sein, "Falschverbindungen" einzubauen, um so z.B. das eigene DTR als fremdes DCD "vorzuspielen" oder auch das eigene DTR dem "Gegner" als DCD _und_ DSR. DTR an DSR waere eigentlich richtig, aber wenn die Soft ein Carrier- signal braucht und (oft) DSR ignoriert... (RTS kommt fuer solche Spielchen normalerweise nicht in Frage, weil es fuer den Handshake staendig gebraucht wird.) Zu Testzwecken kann man auch noch einen Schalter einbauen, der den DCD-Eingang gezielt belegt, um "Carrier da" oder "Carrier weg" zu simulieren. Hier muss man gelegentlich probieren. Es folgt die idiotensichere Variante, je nach Bedarf kann man Leitungen (oben sind die wichtigen) weglassen:
Rechner 1 Rechner 2 9pol 25pol 25pol 9pol 5 7 ---GND---------------------GND------- 7 5 2 3 ---RxD--------. ,----------RxD------- 3 2 X 3 2 ---TxD--------' `----------TxD------- 2 3 7 4 ---RTS--------. ,----------RTS------- 4 7 X 8 5 ---CTS--------' `----------CTS------- 5 8 4 20 ---DTR--------. ,----------DTR------- 20 4 X 6 6 ---DSR--o-----' `-------o--DSR------- 6 6 | | 1 8 ---DCD--' `--DCD------- 8 1
Ach ja, hier noch die PIN-Belegung für ein Modem-Kabel für den MAC.
Rechner-Modem
Mac SCC/GeoPort Modem RS-232 9pol (männlich) 25pol 1 --- HSKo / DTR ------------o-- DTR ---- 20 | 2 --- HSKi / CTS ------------|-- CTS ---- 5 | 3 --- TxD- -----------------|-- TxD ---- 2 | 4 --- GND -------o---------|-- GND ---- 7 | | 5 --- RxD- -------|---------|-- RxD ---- 3 | | 6 --- TxD+ | | | | 7 --- GPi / DCD ---|---------|-- DCD ---- 8 | | 8 --- RxD+ -------' `-- RTS ---- 4 9 +5 V (350mA max. nur bei GeoPort)
Von: Michael Keukert @ AC2 (Mo, 29.01.96 12:02)
Sorry, aber wie oft wurde hier schon von verschiedenen Leuten lauthals geäussert, daß erweiterte MPROG.DAT eigentlich nur Probleme machen können! ........
Abhilfe: Altes MPROG.DAT rüberkopieren (1710 Bytes), PROGFIX drüberlaufen lassen (nur der tut's in diesem Falle - vorher Gruppen mit langen Namen in kürzere umbenennen). Progfix schreibt alle Files ins Log, deren Parameter nicht stimmen, setzt die Parameter aber gleichzeitig auch auf Null. Dann am bequemsten diese Liste ausdrucken und mit dem MC die Parameter *für jedes einzelne File* richtig setzen (Geht über F5).
Viel Spaß!
Die aktuelle Demomaus liegt immer in AC oder K2
TIC-File-Generatoren-Liste Stand: 5 May 1996 ++
(21.09.1997)
Michael Kugelmann @ S5 Version 0.1a
BITTE WEITER ERGÄNZEN UND KORRIGIEREN, WER ETWAS WEISS.
Verbesserungsvprschlägeund Korrekturen bitte per PM an
den Autor. Ich danke all denjenigen, welche bisher bei
der Erstellung und Korrektur der Liste beteiligt waren.
Allgemeine Infos:
F: | Was ist bitte ein TIC-File-Generator und wofür braucht man das? |
A: | James kann für den User den Upload in die Programmteile
übernehmen. Dazu lädt er das Uploadfile zusammen mit einer
Datei, die alle zum Upload notwendigen Informationen enthält (das
TIC-File) und dem INFILE beim Tausch hoch. Dazu werden entweder die
ganzen Dateien in ein Archiv gepackt oder im Multiupload mit Z-Modem
hochgeladen. James erledigt nach dem Tausch den Rest. Vorteil: man
muß den Upload nicht mehr Online oder über ein
Upload-Batch/Script machen, was Ganze beschleunigt und vereinfacht.
|
F: | Kann ich TIC-Files auch von der Maus erhalten? |
A: | Ja, dazu muß man (wenn installiert) beim Herunterladen von
Dateien als Übertragungsprotokoll "<protokoll> mit
TIC" anwählen, oder wenn Saugtausch benutzt wird, muß
die Zeile "#JAMESTIC" _vor_ den angeforderten Programmen in
der Anforderungs-PM stehen.
|
F: | Wer kann Den Upload mit Tic-Files beim Tausch nutzen? |
A: | Zuerst einmal gilt: alle User einer Maus, auf der Schnulli und
James installiert und auch entpr. konfiguriert sind.
Aber: Nicht in allen Mäusen ist das allen Usern erlaubt!
Gäste z.B. können das in keiner Box.
User dürfen es idR, wenn sie auch Online im Programmteil der Maus
Uploaden dürfen. Ein TIC-Upload in einen GPT (oder ÖPT) ist
nicht möglich, wenn der User nicht auch Online in der Maus
Zugriff darauf hat!
Im Zeifelsfalle sollte man seinen Sysop mal fragen oder einfach
ausprobieren. Mehr als das die Dateien einfach wieder gelöscht
werden (weil ja niemand da ist, der sie Importiert) kann nicht
passieren.
|
F: | Welche Informationen kann ein User der MPROG.DAT entnehmen? |
A: | In der MPROG.DAT steht drin, in welche Kathegorien die Datei auf einer Maus beim hochgeladen eingetragen werden kann. Also Programmtyp, Quelltext, Copyright... Sprich genau das Menü, das die Maus beim online-Upload anbietet. |
System | 2 | 3 | 4 | 5 |
Name | Vers. | Autor | MP | |
Archivname | Zu finden | |||
[optionale Bemerkung] | ||||
Amiga | ||||
AmiTIC | 1.4 | Oliver Schuler @ SIG | FW | |
ÖPT@SIG | ||||
Atari | ||||
DirToTIC | Frank Roeske @ LU2 | Beta | J | |
DTT*.LZH | ||||
Version auf Anfrage | ||||
benötigt Filelist (SW) | ||||
MakeNews | 1.14 | Manfred Ssykor @ AC3 | FW | |
MKN_vvv.LZH | ÖPT@AC3 | |||
MAKEUPL | 3.40 | Volker Keck @ SIG | FW | N |
ÖPT@SIG | anpaßbar | |||
Weiterentwicklung evtl. | ||||
von Volker Janzen @ UL | ||||
MausHelp | 0.32 | Manfred Ssykor @ AC3 | SW | |
MAUS?vvv.LZH | Ö&S@AC3 | |||
Saug-Utility | 6.0 | Frank Rüger @ OS2 | FW | |
SAUGUT60.TOS | ÖPT@OS | |||
Final Version! | ||||
(Kein Update/Support meehr) | ||||
TIC-Kreator | 1.18 | Ulf Dunkel | SWE | J |
TICK_vvv.??? | GPT MAUSTAUSCH @ EL + DAL | |||
DOS | ||||
PAUL | 1.12 | ?Michael Streichsbier @ M2? | SW | J |
PAULXvvv.ARJ | ÖPT@WHV | |||
TICMAKER | 0.5ß | Andreas Mayer @ ZW | FW | (N) |
???????????? | ||||
benutzt Text-basierte | ||||
Beschreibungsdatei | ||||
anstatt MPROG.DAT | ||||
Mac | ||||
Mausefalle | 1.4 | ?????????? | SW | |
??????? | ||||
Im Maustauschpr. eingebaut | ||||
OS/2 | ||||
Lst2Tic | 1.08 | Karsten Iwen @ HL | SW | |
LST2Tvvv.ZIP | GPT MAUSTAUSCH @HL + ÖPT@S3 | |||
Windows | ||||
TIC-File-Gen | 1.02 | Markus Schober @ ZW | FW | J |
TICFGENv.ZIP | ÖPT@ZW | |||
TVMTIC | 1.0c | Hans-Peter Bock @ TBB | FW | J |
TVMTIC.ZIP | ÖPT@TBB | |||
Upload | 0.1d | Georg Bauer @ MS3 | FW | J |
#UPL*.EXE | ÖPT@MS3 | |||
XPHatch | 2.02 | Carsten Schmitz @ HH2 | SW | |
ÖPT@TBB | ||||
?für Fido? | ||||
Windows | ||||
TIC-Creator | 1.01ß | Andreas Suffner @ S4 | SW | |
tic.zip | GPT MouseEye@S3 | |||
trotz Shareware kostenlos | ||||
UTic | 1.10 | Ulrich Tönnies @ OS2 | SW | N |
ÖPT@OS2 | ||||
Unix | ||||
nix | ||||
Sonstige | oder | Nicht | ||
Betriebssytemgebunden | ||||
Lst2Tic | ???? | ?????? | ||
LST2TIC.AWK | ?in AWK? | |||
Karl-Heinz Wachtendorf @ OL | ||||
hatte dazu was geschrieben | ||||
(oder das Archiv gepostet), | ||||
könnte er sich bitte bei | ||||
mir melden? Danke. | ||||
(Zitat von damals: | ||||
#!rungawk.mup) |
MAUS | [4] |
James | (Die "eierlegende Wollmilchsau" für die Maus ;-) |
Mausring Commander | Michael Keukert @ AC2 GPT Sysop.Prog |
TicTac | (Standalone-Programm zur Tic-Generierung, |
bei Maus ohne James) |
Anmerkungen und Erklärungen:
MP: Benutzt MPROG.DAT der Maus
ein vvv z.B. bei beim Archivnamen leitet sich von der Version ab
FW = Freeware, SW = Shareware, SWE = Shareware (eingeschränkt)
zu [4]: Tools nur für Mäuse erhältlich und dort einsetzbar, z.B. um "Download mit TIC" anzubieten, normalerweise DOS-Programme
Hier habe ich mal völlig unverbindlich die Sachen über das Verhalten im MausNet zusammengesucht, die mir wichtig erscheinen.
Von: Jürgen Conradi @ HB (Mo, 15.07.96 04:57)
Fast alle Mäuse sind Teilnehmer der Domain 'maus.de'. Die Domain 'maus.de' ist Mitglied im IN e. V. und somit unterliegt die Nutzung von 'maus.de' den Verträgen, die der IN e. V. mit den verschiedenen Providern (EUNet, DFN, XLink, BelWue) abgeschlossen hat. Ein ganz wesentlicher Punkt ist folgender:
KEINE KOMMERZIELLE NUTZUNG der maus.de-Konnektivität. Die Netznutzung ist ausschließlich für private Zwecke zulässig. U. a. ist damit folgendes untersagt:
Verwendung der maus.de-Adresse auf Visitenkarten, Briefköpfen, Schriftstücken usw, die nicht ausschließlich privaten Zwecken dienen.
Werbung mit Angabe der maus.de-Adresse
Postings mit Werbung für eine Firma
Support über die maus.de-Adresse (gilt natürlich auch für Shareware)
Hinweis auf Firmen in Footern
jegliche Nennung einer .maus.de-Adresse im Zusammenhang mit kommerziellen Aktivitäten aller Art
und ähnliches.
Die Nichtbeachtung dieser Regel kann schwerwiegende Folgen haben. Bei Bekanntwerden von Verstößen ist mindestens mit dem Ausschluß der betreffenden Maus aus maus.de zu rechnen. Im Rahmen des Möglichen ist aber auch die Auflösung der kompletten Domain maus.de oder sogar des kompletten IN e. V., wenn die Provider wegen Mißachtung der vertraglichen Regelungen die Versorgung einstellen. Ich bitte also, im Interesse aller IN-Domains dieses Verbot strengstens zu beachten.
Vorstand Maus.De e.V:
jc@hb.maus.de - gs@k2.maus.de - ms@bm.maus.de
Von: Jürgen Conradi @ HB (Do, 25.04.96 19:53)
Eine Bitte an die SysOps - Bitte ausdrucken und aufheben
Q: | Worum geht es bei der NON-KOMMERZ Frage dem Individual Network e.V.? |
A: | Die Verträge den IN e.V. mit seinen IP-Zulieferen (Providern) legen den IN e.V. auf eine ausschliessliche Nutzung durch Privatpersonen fest. Diese Nutzung hat nichtkommerziell zu erfolgen. |
Q: | An wen wendet man sich in derartigen Fragen? Welche Befugnisse existieren? |
A: | Es existiert ein Arbeitskreis (IN-AK-NON-Kommerz@individual.net). Die Aufgabe des AK besteht darin festzulegen, was auf Leitungen, die vom IN e.V. bezahlt werden, als kommerziell anzusehen ist. Im AK existiert eine sehr sehr strenge Forumlierung, was Kommerz ist. Diese Formulierung ist keinesfalls ausschliesslich konsensfähig, sie zeigt nur, daß alles, was nach dieser Reglung NICHT kommerziell ist, faktisch von der grössten Mitgliederversammlung noch Unterstützung bekäme. Die exakte Kommerzdefinition liegt nach wie vor bei den Providern, die aber sich dieser Aufgabe nicht stellen. Entscheidungen kann nur der Beirat/Vorstand oder das Präsidium den IN e.V. treffen. In letzter Instanz ist die Mitgliederversammlung entscheidend. |
Q: | Was ist 'Kommerzielle Netznutzung'? |
A: | Es gibt 2 Varianten, eine 'übliche' und eine 'scharfe': Die Regionaldomains des individual Network e.V. bietet einen vollen und uneingeschränkten Zugang zum Internet - für Privatpersonen. Die Frage ist nur: Was heisst das denn überhaupt, 'Zugang für Privatpersonen' oder anders: Das Verbot kommerzieller Nutzung. Zuerst einmal die Gründe für diese Einschränkung. Jede Regionaldomain kauft ihre Konnektivität, d.h. das Recht, Daten ins Internet zu schicken und zu empfangen, von anderen Anbietern ein, die u.a. kommerzielle Interessen vertreten. Der Individual Network e.V. tritt gegenüber diesen Anbietern als Gemeinschaftseinkäufer auf, der es seinen Mitglieder ermöglicht, die gemeinsam eingekauften Kontingente gemeinsam zu nutzen. Gegenüber diesen Anbietern hat sich der Individual Network e.V. verpflichtet, nur Privatpersonen zu nichtkommerzieller Nutzung anzuschliessen. Diese Verpflichtung gilt deshalb selbstverständlich auch für die Regionaldomains. Deshalb ist zuerst einmal natürlich der Anschluss von Firmen tabu. Ausgenommen sind auch Institutionen, Vereine oder sonstige juristischen Personen - es dürfen nur Privatleute angeschlossen werden. Daran ändert auch die Gemeinnützigkeit eines Vereins nicht. Einzige Ausnahme ist die Mitversorgung von Vereinen mit gleicher Zielsetzung. Es gibt mehrere Gründe für diese Regelung: Eine Regionaldomain darf den in gleichen Bereich tätigen Providern keine Konkurrenz machen. Deshalb dürfen die Dienste, die einkauft wurden, nur an Mitglieder der Regionaldomain weitergegeben werden. Daraus folgt auch, daß keine potentiellen Kunden dieser Provider angeschlossen werden - deshalb der Ausschluss von Institutionen und Firmen. Es geht also darum, den Leuten einen Internetzugang zu ermöglichen, die die kommerzielle Provider nicht direkt als Kunden im Auge haben, Privatleute eben. Probleme können auftreten, wenn jemand gleichzeitig auch noch in einer Firma arbeitet, oder selber eine kleine Firma hat. Erst dann können wirklich Konflikte entstehen. Dies gilt aber wohl für die Mehrzahl der Teilnehmer... Für den einzelnen angeschlossenen Nutzer gibt es deshalb mehrere Dinge zu beachten: Kommerziell ist jede Nutzung die direkt der Beschaffung des Lebensunterhalts dient, d.h. insbesondere das Verschicken von Werbung für die eigene 'kleine' Firma, das Nutzen von eMail zum Abschliessen von Verträgen oder Gewinnen von Kunden und Geschäftspartnern. Das Veröffentlichen der eMail-Adresse als Ansprechstelle für Geschäftskunden das Veröffentlichen von Firmennamen oder Adressen in den News (auch in der Organization-Zeile im Artikel-Header oder in der Signature!) Keine kommerzielle Nutzung ist aber die Nutzung der News und des Internets zum Erfahrungsautausch und zur Weiterbildung. Dass Firma und Privatleben nicht immer leicht zu trennen sind, ist selbstverständlich. Trotzdem ist es wichtig, immer daran zu denken, daß diese Trennung überhaupt erst die Grundlage für die Existenz des IN e.V. bildet, d.h. ohne das Verbot kommerzieller Nutzung wäre eine Nutzung des Internets durch Vereinsmitglieder von Regionaldomains in der Regel unmöglich, da unbezahlbar. Jede noch so kleine Firma ist prinzipiell ein kommerzieller Nutzer: Auch ein Shareware-Autor, der nur wenig Geld verdient, aber er verdient eben doch Geld damit. Entscheidend ist damit auch nicht unbedingt die Gewinnerzielungsabsicht oder die Höhe des Umsatzes, sondern einzig und allein der Zweck der Internetnutzung: Eben um sich privat zu 'Vergnügen', soziale Kontakte zu knüpfen oder sich nette Bilder anzuschauen. Auf der anderen Seite steht, damit möglicherweise Geld zu verdienen oder einen sonstigen direkten Vorteil für die eigene oder eine andere Firma zu erhalten. Die 'Scharfe', die jedem, der sich daran hält, praktisch sicher gehen lässt, nichtkommerziell zu arbeiten. Ein Nichteinhaltung dieser 'scharfen' Reglung heisst nicht, daß kommerzielle Nutzung vorliegt. Handlungen, die im "Netz" als gewerblich angesehen werden:
|
Q: | Ist es zulässig, bei einem kommerzielle Provider die Webseiten zu haben und die eMail für Bestellungen per IN e.V. zu beziehen. |
A: | Definitiv nicht, wenn es sich um etwas "Kommerzielles" handelt. |
Q: | Kann ich an meinem Arbeitsplatz eMail per IN e.V. lesen, bearbeiten und pollen (z.B. über die Technik der Firma), vorausgesetzt, der Chef hat dem zugestimmt? |
A: | Solange eine entsprechende Vereinbarung unterschrieben ist, die die Abtrennung der Bereiche 'Arbeit' und 'Privatleben' zum Inhalt hat. Eine Kontrolle wird vermutlich niemand ausüben, die Leute müssen wissen, was sie tun. Es ist somit praktikabel mail-forwarding an Sites zu machen, die damit Kosten sparen könnten. Das betreffende IN-Mitglied sollte schriftlich zusichern, daß es Missbrauch ausschliesst. |
Q: | Besteht ein Unterschied zwischen einem wissenschaftlichen Arbeitsplatz und einem industiellen? |
A: | Nein, warum denn ? Arbeitsplatz ist Arbeitsplatz. Arbeitsplatz ist immer kommerziell und somit nicht privat. |
Q: | Kann sich ein Mailbox-Verein anschliessen? |
A: | Zumindest Einverständnis vom IN-Vorstand einholen, es bsteht das Problem mit der Definition, was eine Site ist. Evtl. gibt es Sonderkonditionen. Wenn jeder Point als Site gezählt wird, ist es jedoch kein Problem. |
Q: | Kann sich ein gemeinnütziger Verein anschliessen? |
A: | Vereinsanschlüsse an sich sind problematisch -> Vorstand. Wenn eine Einzelperson als solche diese Vereinsarbeit für einen solchen Verein macht, dann liegt es im Ermessen der Domain. Der Anschluss sollte aber nicht zu einem Vereinsanschlüss mit Strohmann werden. |
Q: | Kann sind eine Bibliothek anschliessen, an in der nur Studenten und private Personen lesen? |
A: | Organisationsanschlüsse sind generell problematisch -> Vorstand. Macht es eine Einzelperson als Person, so ist das unbedenklich. |
Q: | Kann sich eine juristische Person (Verein, Gewerkschaft, Partei, Arbeitsgruppe, Schachverein...) als solche anschliessen? |
A: | Nein, die Zugänge des Individual Network e.V. sind nur für Privatpersonen gedacht. Einer Privatperson kann und sollte es aber nicht verwehrt sein, im Rahmen seines privaten Interesses auch über die betroffene juristische Person zu berichten, ... Eine Ausnahme davon bilden die Vereine, die gleiche oder ähnliche Zielsetzungungen haben, wie die Regionaldomains des Individual Network e.V. |
Q: | Kann ein Nutzer einen Anschluss für eigene weiterbildende Arbeiten (Diplomarbeit, ...) benutzen? |
A: | Ja. |
Q: | Jemand will auf unserem WWW-Server Seiten zu seiner Lieblingsband ablegen -> gar kein Problem... Wie sieht es nun aus, wenn dort Artikel und Bilder erscheinen, die unter Copyright stehen und daher einer Erlaubnis bedürfen ? |
A: | Es liegt weder mittelbar noch unmittelbar ein Erwerbszweck vor, deswegen ist prinzipell nichts einzuwenden. So die Plattenfirma darauf hingewiesen ist, daß diese Veröffentlichung eine rein private und keine der Firma ist, geht das schon. Das muss auch so explizit dran stehen, daß sich Fragen erübrigen. |
Q: | Einige Domains sind -im Gegensatz zur Satzung des IN e.V.- nicht als Verein organisiert. Geht das überhaupt? |
A: | Der Passus mit den Vereinen als Mitgliedern kam damals von Terra - obwohl wir ja meines Wissens auch damals schon Domains hatten die offiziell als GbR organisiert waren. Vielleicht sollte man mal bei ihm nachfragen, wie er sich das vorgestellt hatte (er hat damals irgendwie argumentiert, aber ich habe es wieder vergessen). Die Geschichte mit den GbRs wurde vom DE-NIC forciert: Von quasi einem Tag auf den anderen konnte man dort als nicht eingetragener Verein keine Domains mehr anmelden. Das führte dazu, daß oftmals eine GbR als Domainbeantragender in die Formulare eingetragen wurde. Etwas problematisch wird es natürlich, wenn diese GbR auch etwas anderes macht als nur die IN-Domain zu betreuen. Erst recht, wenn plötzlich Rechnungen von der GbR gestellt werden, ohne daß der Bezug zur IN-Domain klargestellt wird. (von Vera Heinau) |
Q: | Wenn man für eine (Computer)zeitschrift einen Artikel schreibt und unter diesem Artikel steht dann: Willi Wusel Student der Informatik und arbeitet für div. Firmen EMail: willi.wusel@in-domain.de |
A: | Die Angabe einer Adresse unter einem Zeitschrftenartikel dient dem Zweck, daß der Autor zu diesem Artikel kontaktiert werden kann. Für den Artikel, für die Erstellung, wird er/sie bezahlt. Durch die Benutzung der Adresse nach der Erstellung erzielt der Autor keine Einnahmen mehr. Eine derartige Adresse sollte aber in jedem Fall als private Adresse gekennzeichent sein, beispielsweise so: Willi Wusel |
Q: | Kann ich meine eMail Adresse auf eine Visitenkarte drucken lassen? Auf eine von der Firma? |
A: | Wenn explizit dransteht, daß es die private eMail ist, selbstverständlich. Schliesslich kann man auf einer Visitenkarte auch seine private Telefonnumer angeben. Es sollte aber ausgeschlossen sein, daß dies zur kommerziellen Benutzung der eMail Adresse kommt, weil es beispielsweise keine Firmen-eMail gibt. |
Q: | Wir haben folgendes Problem: Eine Firma möchte zu den von ihnen vertriebenen Rechnern Internet-Software zugeben, bei uns einen Schnupperaccount (10 Stunden oder so) "einkaufen" und den Leuten die Möglichkeit geben, sich nachher über uns normal anzuschliessen. |
A: | Hier wird eine IN-Dienstleistung an ein Unternehmen verkauft, daß diese Dienstleistung zu Werbungszwecken bzw. als allgemeine Attraktivitätssteigerung seiner Produkte einsetzt. Soweit allgemein. Im speziellen ist einer der wichtigsten Gründe für das Kommerzverbot, daß das IN nur Privatkunden beliefert, die sich sowieso nicht an kommerzielle Provider anschliessen würden (nicht zu den Tarifen, bei denen es sich für die Provider lohnt). Das sichert uns die Unterstützung der Provider. Im hier vorliegenden Fall handelt es sich aber um eine Firma, deren Schnupperaccountverteilung evtl. doch interessant für die Provider wäre. Ich denke, für das IN und für die lokale Domain hat eine solche Zusammenarbeit nur Vorteile. Wenn es die lokale Domain also schafft, sowohl von dem Provider, über den Sie versorgt wird, als auch alle in Betracht kommenden regionalen Pops ein Einverständnis zu bekommen, dann sieht die Lage gut aus. Die Pops sind die, die evtl. selbst Interesse an einem solchen Deal hätten und aus den Pops bekommt man vielleicht eher ein klarers Statement als vom jeweiligen Provider. Dann müsste man noch sicherstellen, daß die Firma, die die IN-Dienste weiterverkauft, in der Werbung klarstellt, daß es sich hier um eine private Vereinigung handelt, die keine Verbindung zur Firma hat. Also der übliche riesige Aufwand um kleine Sachen, aber sonst kann viel Ärger von anderer Seite kommen. |
Q: | Wir haben ein Sonderangebot für Hardware (etc.) von einem Sponsor, sollen im Gegenzug, seinen Namen/Link... auf unsere Hauptseite setzen. Ist das gestattet? Wie sieht es mit sponsoring aus ? Bzw mit der Erwähnung der Sponsoren ? |
A: | Solange für die eingeforderte Dienstleistungen ohne Benutzung von Leitsungen des IN e.V., also den Internetanschluss auskommt, ist alles unprolematisch. Die regionale Vereinszeitung kann also Anzeigen ohne Ende enthalten. Der regional abfragbare Web-Server natürlich ebenfalls. Es gilt immer Der Grundsatz: Wir lassen die Provider (und darum geht es im Endeffekt bei "gewerblich/kommerziell") nur an den Stellen reinreden, wo auch die von ihnen eingekaufte Leistung berührt sind. Es ist eine Nutzung von IN e.V. Leistungen (Anschluss + Traffic) zu Werbezwecken, ich kenne kaum klarere kommerzielle Nutzung. WWW Anschluss & Traffic ist aber vom IN e.V. bezahlt. Punkt. Deswegen ist Sponsoring (als Werbung per WWW) von MEINEM Standpunkt aus abzulehen. Man sollte nie vergessen, daß die eingeforderte Aktion den Sponsor normalerweise Geld kosten wurde, das er an eine Firma im Internet abzuführen hätte. Bei den Kosten, um die es dabei gewöhlich geht, ist ein Preisnachlass von 300DM bei Technik eigentlich lächerlich. Eine Überschneidung mit den Arbeitsgebieten von Presentation oder Content Providern ist unproblematisch, da diesbzgl. keine Verträge vorliegen. Es ist nur Vereinsrecht zu beachten. Für einen gemeinnützigen Verein ist die Unterscheidung zwischen "Sponsor" und "Spender" wichtig. Mit einem "Sponsor" geht man einen Vertrag ein, der einen verpflichtet, den Sponsor bei allen möglichen und unmöglichen Gelegenheiten zu erwähnen. Art und Umfang der Erwähnung (Werbung) wird dabei genau festgelegt und davon abhängig werden die Gegenleistungen des Sponsors (Geld, Hardware, Software) gemacht. Ein Spender stellt einem Verein eine Geldsumme bzw. Hard- und Software zur Verfügung. Das einzige was ihm rechtlich zusteht ist eine Spendenquittung. Gegenleistungen kann ein Spender nicht einklagen. Es gehört aber zum guten Ton und ist rechtlich vollkommen o.k. sich für eine Spende zu bedanken. Der Dank für so eine Spende ist in jedem Fall auch keine Werbung im Sinne von Öffentlichkeitsarbeit gegen Geld. Natürlich hat so ein "Danke" einen Werbeeffekt. Der springende Punkt ist, das der Verein über Art und Umfang entscheidet und nicht der Spender. Konkret auf's WWW bezogen existiert folgender KompromissVORSCHLAG:
|
Q: | Was sind die auf ein Jahr beschränkten Testaccounts für Firmen? |
A: | Der IN e.V. hat das Recht, Firmen zur kommerziellen Nutzung auf die Dauer von bis zu einem Jahr anzuschliessen. Dies Bedarf der Anzeige bei IN-Vorstand@Individual.Net. Gleichzeitig muss sich um eine Umschaltung der Firma an den nächsten kommerziellen Provider gekümmert werden. Diese Reglung ist allerdings nicht besonders klug, solange nicht der Aktionsradius für "reguläre" IN-Domains abgesteckt ist. Sehr bald gibt es nämlich Fragen der Art "da wird ein Semikommerzieller für längere Zeit angeschlossen, und wir dürfen nicht mal Sponsoring-Infos auf unsere WWW-Seiten packen?" Vorstand Maus.De e.V:
|
Allgemein gilt, das man zwar die Gruppe Sysop.Info lesen sollte, es aber natürlich keine Pflicht gibt, daß ein Sysop diese Gruppe liest. Allerdings gilt hier genauso wie für User bei der Gruppe Maus.Info:
Wer Sysop.Info nicht liest ist selber schuld!
Wenn da also was wichtiges drinsteht und man es nicht mitbekommt...pp
Ferner sollte man in Sysop.Info bitte nix kommentieren. Das sieht immer doof aus, besonders wenn es Kommentare wie 'Ja genau' etc sind. Gummipunkte gibt es dafür fast immer. Damit das nicht zufällig passiert, kann man folgendes machen:
Gruppe Sysop.Info auf Geheim (das ist sie ja sowieso) und auf Readonly setzen.
Gruppenchef wird ein Daemon-User oder nur ein Sysop. Dann kann es nur einem passieren.
Wenn wirklich jemand anderes als der Gruppenchef dort was wichtiges posten muß, kann er sich ja eintragen oder den Gruppenstatus ändern. Er ist ja Sysop und sollte das schaffen.
Dann muß man sich zwar erst als Mitglied eintragen, um etwas zu schreiben, aber so oft kommt das normalerweise auch nicht vor.
Eine andere und viel einfachere Möglichkeit ist es, wenn man den Followup in der Maus direkt setzt. Wenn das Frontend das unterstützt (alle neuere sollten es eigentlich) können so auch keine unabsichtlichen Kommentare mehr dort abgelassen werden. Allerdings muß man dann, wenn man etwas absichtlich dort kommentieren will, je nach Fronmtend ein paar Verrenkungen machen.
Auf dem Sysoptreffen in Bremen wurde unter anderm das beschlossen:
Über die Mitleser in den technischen SysOp-Gruppen von Fremdmäusen (kommerzieller Einsatz der MAUS-Software) wird abgestimmt. Es wird darauf hingewiesen, daß nur im ISB eingetragene Personen lesenden Zugriff auf SysOp-Gruppen haben dürfen.
Genau ist es im entsprechenden Kapitel nachzulesen.
Ein Teil der Sysops meint folgendes:
Neue Mäuse, Betreiber (also Betreiberwechsel) werden mitsamt der Vorstellung in Sysop.Info angekündigt. Diskussionen darüber sollen dann in Sysop.Neu erfolgen. Dazu ist den neuen Betreibern die Gruppe freizuschalten (aber nur Sysop.Neu).
Bei CoSysops gibt es unterschiedliche Meinungen. Ein Teil meint, neue CoSysops werden in Sysop-Info angekündigt. Die Vorstellungsmail soll dann in Sysop.Neu gepostet werden. Der andere Teil meint, das die kurze Infomail in Sysop.info bei CoSysops zuviel ist. Ich finde das erstere netter und so voll wird S-Info dadurch auch nicht (cg).
Von: Harald Krusekamp @ MS (Do, 04.04.96 22:55)
MId: 199604042255.a54581@ms.maus.de
Moin Thomas!
TL> Unter das BDSG fallen nur Behörden und öffentliche
Stellen sowie die
TL> Privatwirtschaft. Das MausNetz hat - wie z.B. auch Vereine -
kein
TL> wirtschaftliches Ziel.
Das ist schon fast wieder ein FAQ wert: Was Du schreibst, stimmt schlicht nicht. Im dritten Abschnitt des BDSG ist von "geschäftsmäßiger", nicht von "geschäftlicher" Datenverarbeitung die Rede.
Geschäftsmäßig ist ein selbständiges und auf eine gewisse Häufigkeit abgestelltes Tätigwerden. Auf Entgeltlichkeit kommt es nicht an (das wäre "gewerbsmäßig").
Zöller-Stephan ZPO 17. Aufl. Par. 157 Rdnr. 4 u. H. a. BGH NJW 1986, 1051; OLG Hamburg MDR 1951, 693; RGZ 61, 51) (aus einer Mitteilung von Ralf Maseratis @ UN zitiert) Ich habe hier ein Schreiben der Bezirksregierung Arnsberg liegen, als der für Münster zuständigen Datenschutzbehörde (die BR Münster ist nicht Datenschutzbehörde), in dem folgendes steht: Durchführung des Bundesdatenschutzgesetzes - BDSG - hier: Meldepflicht nach Par. 32 BDSG Hiermit bestätige ich, daß die MAUS MS, Münster bei mir im Register nach Par. 32 Bundesdatenschutzgesetz gemeldet ist. Ich weise darauf hin, daß Änderungen zu den mir mitgeteilten Angaben innerhalb eines Monats anzuzeigen sind. Mit freundlichen Grüßen Im Auftrag Ahlers
Der dritte Abschnitt des BDSG findet mithin unmittelbar Anwendung auf Mailboxen. Dies hat übrigens nichts mit der - für die meisten Mailboxen nicht mehr notwendigen - Anmeldung beim BAPT nach dem FAG zu tun.
Personenbezogene Daten sind Einzelangaben über persönliche oder sachliche Verhältnisse einer bestimmten oder bestimmbaren Person (siehe Info 1 des Bundesbeauftragten für Datenschutz, Seite 14). Ein Blick in Par. 28 (den ich wegen der Länge hier nicht abtippen werde ;-)) zeigt, daß Hans personenbezogene Daten veröffentlicht hat, was unter bestimmten Voraussetzungen des Par. 28 noch erlaubt sein könnte. Allerdings ist keine der Voraussetzungen erfüllt: Weder liegt eine Zweckbestimmung vor, die eine Veröffentlichung rechtfertigen könnte, noch kann man angesichts deutlichen Widerspruchs vieler Sysops (schon durch die explizite Anwendung der Kleinschreibung innerhalb des Tokenformats im ISB) von mangelndem schutzwürdigem Interesse ausgehen, zumal die meisten Daten im ISB gerade nicht für die Veröffentlichung bestimmt sind, worauf diejenigen, deren Daten dort drinstehen, vertrauen durften (aber leider nicht konnten). Da Hans als Sysop berechtigter Empfänger der im ISB gespeicherten Daten ist, durfte er sie gem. Par. 28 IV BDSG nur für den Zweck nutzen, zu dessen Erfüllung sie an ihn übermittelt werden. Die Daten wurden aber gerade nicht zur Veröffentlichung an ihn übermittelt, dennoch hat er sie veröffentlicht.
Geht man davon aus, daß Hans nicht bewußt jemanden schädigen wollte (das würde das Strafmaß erhöhen), muß man von einer Geldstrafe gem. Par. 43 I bzw. II BDSG als Strafmaß - Ersttäter, minder schwerer Fall usw. - ausgehen. Möglicherweise würde ihn seine mangelnde Einsicht ein paar Hunderter extra kosten - Richter lieben so etwas ;-)
TL> personenbezogenen Daten - findet aber hier keine Anwendung)
Bitte nie nicht wiederholen, einverstanden?
TL> p.s.: Hoffe Du fasst es nicht zu sehr als Belehrung auf - just
Info
TL> :-)
Eben ;-)
MfG Harald
Regel: Schreibe keine Msgs wenn du schlecht geschlafen hast.
Regel: Schreibe keine Msgs wenn du sehr müde bist.
Regel: Schreibe am besten überhaupt nix...:-)
Regel: Schreibe keine Msgs wenn Du schlechte Laune hast.
Regel: Regst Du Dich über irgendetwas auf (insbesondere über Kollegen), tritt Regel Nr. 4 in Kraft.
Vorab. Jeder kann die Betreffkürzel in Programme handhaben, wie er meint, das es sinnvoll ist. Es wird und kann keiner zu irgendwelchen Regelungen gezwungen werden.
Wenn man will, kann man sich aber auch an diese Betreffkürzel halten:
Der Absender der Mails ist egal
für den öffentlichen-PT sollte für jedes Betriebssystem eine eigene Mail generiert werden.
Der Betreff sollte folgendermaßen aussehen: Mauskürzel: Betriebssystem Beispiel: B3: ST TOS B3: Windows
Gruppenprogrammteile
B3: GPT Maustausch
Die Mails müssen nicht nach Betriebssystem aufgesplittet werden, da
ersten dort nicht so viele unterschiedliche kommen und es zweitens auch ein
riesen JMS-benötigt (Fehleranfällig)
für die Loginzeiten und sonstige Hinweise: B3: Info, Loginzeiten
die gelöschten Programme sollten in den Mails der einzelnen Betriebssysteme mitdrin stehen. Also keine eigene Mail
Für James hier mal ein Beispiel Steuertext, der so in der Maus B3 bisher problemlos funktioniert. Angepaßt werden muß eigentlich nur noch folgendes:
#IFKRIT (WT=Fr) #ABSENDER Programmteil Maus /D=-7 <--- natürlich in allen Aufrufen ändern B3: GPT Gpt-Name <--- hier noch die anderen Gruppen-Pt eintragen, die in deiner Maus vorhanden sind. Und natürlich die Loginzeiten, Infos. Eigetragen haben ich dort mal die Steuertexte zur Erzeugung der Gesamtinfos des Programmteils.
;--------------------- Neue Uploads in PROGRAMME --------------------- ; Steuertext für James ; Es wird am Wochentag WT in PROGRAMME gepostet. ; R- Keine Files die über den Ring kamen anzeigen ; Y+ wenn es nix gab, auch nix melden ; S=B sortiert nach Betriebssystem ; D=7 die neuen Uploads der letzten 7 Tage ; X+ die gelöschten Programme anzeigen ; Absender legt den Namen fest, wenn der fehlt, ist es der Daemon-Name ; 03.10.96 cg first try ; 10.10.96 cg Betreffkürzel an die Maus angepaßt #IFKRIT (WT=Fr) #ABSENDER Programmteil Maus ;--------------------------------DOS --------------------------------- #GPROGRAMME /N B3: DOS #NEWFILES /S=B /B=1 /G- /R- /Y+ /X+ /D=-7 ;-------------------------------- OS/2 ------------------------------- #GPROGRAMME /N B3: OS/2 #NEWFILES /S=B /B=2 /G- /R- /Y+ /X+ /D=-7 ;------------------------------- Win --------------------------------- #GPROGRAMME /N B3: Windows #NEWFILES /S=B /B=3 /G- /R- /Y+ /X+ /D=-7 ;------------------------------- TOS --------------------------------- #GPROGRAMME /N B3: ST TOS #NEWFILES /S=B /B=4 /G- /R- /Y+ /X+ /D=-7 ;------------------------------- Amiga ------------------------------- #GPROGRAMME /N B3: Amiga #NEWFILES /S=B /B=5 /G- /R- /Y+ /X+ /D=-7 ;------------------------------- Mac --------------------------------- #GPROGRAMME /N B3: Macintos #NEWFILES /S=B /B=6 /G- /R- /Y+ /X+ /D=-7 ;------------------------------- Unix -------------------------------- #GPROGRAMME /N B3: Unix #NEWFILES /S=B /B=7 /G- /R- /Y+ /X+ /D=-7 ;------------------------------- Sonstige ---------------------------- #GPROGRAMME /N B3: Sonstige #NEWFILES /S=B /B=0 /G- /R- /Y+ /X+ /D=-7 ;--------------------------- Gruppen-PT------------------------------- ;---------------------------Maustausch-------------------------------- #GPROGRAMME /N B3: GPT Maustausch #NEWFILES /S=B /O- /G& /R- /Y+ /X+ /D=-7 /N=Maustausch ;----------------------------GPT-Name--------------------------------- #GPROGRAMME /N B3: GPT Gpt-Name #NEWFILES /S=B /O- /G& /R- /Y+ /X+ /D=-7 /N=GPT-Name ;-------------------------- Loginzeiten ------------------------------ #GPROGRAMME /N B3: Info, Loginzeiten _Öffentlicher Programmteil_ #Newfiles /#=1 /R+ /I /G- #Newfiles /O+ /G- /#=1 /S=B /R+ /I _Gruppenprogrammteile_ #Newfiles /O- /G+ /#=1 /R+ /I Hier können jetzt die Infos reinkommen #ENDABSENDER (das war's was für #ABSENDER verschickt wird) #ENDIF (#ifkrit)
ZUSATZ: Ab Maus 7.95i untersützt die Maus mit der Variable DownloadSperre das sperren von Downloads für bestimmte Usergruppen. Ab James 1.5c unterstützt James das auch (siehe History-Text zu James). Die Steuertexte müssen dann um die entsprechenden Parameter (z.B. /U=V) erweitert werden.
Die meisten Beschreibungen habe ich aus dem Sysop-Programmteil der Maus S3/S4. Viele Programme liegen aber auch sicher in den Aachener Mäusen, K2 usw. Und die Liste ist bei weitem noch nicht vollständig. Und auch nicht auf dem aktuellen Stand, sorry!
Hoffentlich aktueller ist das folgende. Der Tool Server @ ZW. Eine einfache Hilfe erhält man, wenn man an den Server eine Mail mit dem Betreff 'Hilfe' und im Body '-'.
Archivename: | ANAMSG14.ZIP |
Archivlänge: | 24981 |
Beschreibung: | ANAMSG Version 1.4 - analysiert die Lesegewohnheiten eurer User |
Autor: | Jörg Stattaus |
Archivename: | BINKCST2.ZIP |
Archivlänge: | 19253 |
Beschreibung: | BINKCOST analysiert die Logfiles eines Fido-Gateways mit BinkleyTerm. Voll kompatibel zu NetStat ab 1.9. Partnerrechner individuell konfigurierbar. Einzelabrechnung pro Partnersystem als Summe ausgebbar. Neue Telekom-Tarife von '96 werden berücksichtigt. |
Autor: | Michael Keukert @ AC2 |
Archivename: | BDOS_259.LZH |
Archivlänge: | 339701 |
Beschreibung: | Binkley Term V 2.59 für DOS
|
Archivename: | CDPTH03.ARJ |
Archivlänge: | 32137 |
Beschreibung: | CDPTH V 0.3: Hat man Programmteile anderer Mäuse auf CD, kann man sich hiermit ein passendes PTH-File erzeugen. Das geht auch mit dem ÖPT! Beliebige GPTs, max. 20 CD-ROM, Einspielen von Files in den Progteil, die nur auf CD sind (Abgleich). V 0.3: Es wird immer auf der letzten CD auf der etwas gefunden wurde mit der Suche begonnen (für Wechsler) |
Archivename: | CDPTH |
Beschreibung: | Erstellt ein allgprog.pth. Dazu werden auf einer oder mehreren CDs Archive,die man im ÖPT hat gesucht und bei Vorhandensein das File auf der CD genommen. Hat man die zu den CDs passenden Steuerdateien, kann man zusätzlich alles, was auf CD aber noch nicht im eigenen ÖPT ist, einspielen lassen. |
Archivename: | CHEFWT77.ZIP |
Archivlänge: | 31380 |
Beschreibung: | ChefWart 0.77ß - ChefWart kann Gruppen- und Leserlisten ausgeben. Dabei läßt sich nach vielfältigen Kriterien auswählen, welche Gruppen ausgegeben werden sollen. Bsp.: Alle Gruppen, die nicht readonly sind und deren GC inaktiv aber kein Sysop ist (mit Leserliste): chefwart /i /w /v- |
Archivename: | #U2M10A.EXE |
Archivlänge: | 222388 |
Beschreibung: | Erwinsgate 1.0a: neu gegenueber der 1.0 ist die Behandlung von Sekundaeradressen beim Import und die Erzeugung von Approved-Zeilen fuer moderierte Mausgroups. Ausserdem noch kleinere Bugfixes (References-Parser) Erwinsgate 1.0 - besondere Features dieser Version: ausgehende News werden gebatched und komprimiert Mäuse ohne D-Zeile werden nicht exportiert Übrigens ist die 1.0 in der Version rein zufällig, hat nix mit Nicht-Beta-Status zu tun, also bitte keine übersteigerten Hoffnungen ;-) |
Autor: | Georg Bauer @ MS3 |
Archivename: | DRIVEDA.ZIP |
Archivlänge: | 6905 |
Beschreibung: | Driveda überprüft ob auf ein Laufwerk zugegriffen werden kann und gibt dann einen Errorlevel zurück. Allerdings wird mitgezählt wie oft es nicht ge- klappt hat und nach einer bestimmten Anzahl Versuche wird abgebrochen. Damit kann man z.B. bei Mitsumi CD-Roms sicherstellen, daß das Laufwerk richtig initialisiert ist. |
Archivename: | DSERV07.ZIP |
Archivlänge: | 20454 |
Beschreibung: | DokuServe V 0.7ß - Dokumentenserver für das MausNet. Kann auf Mailanfragen hin Texte zuschicken. Frei konfigurierbar, incl. Mengenlimits. Neu in dieser Version: verbesserte Fehlerbehandlung (keine Fehlalarme mehr), ignorieren von Tearlines (Jahaaaaa!) |
Autor: | Michael Keukert @ AC2 |
Archivename: | FIXPPAR.ARJ |
Archivlänge: | 10979 |
Beschreibung: | Bei kaputten Programmteil-Steuerdateien (zugriff[x]) kann es passieren, daß der KrunUser sich bei der Bearbeitung der Programmteile bei einer Programmnummer mit RTE201 (RangeCheck) verabschiedet. Mit diesem Programm kann man das verbunden mit ein wenig umkopieren/ umbenennen beheben. Kein Log kein nix, reines Sparta! |
Archivename: | FXRNM215.ZIP |
Archivlänge: | 17951 |
Beschreibung: | FixRnum - Messagebasereparierer V 2.15 |
Archivename: | FORMEL.ZIP |
Archivlänge: | 21044 |
Beschreibung: | Der Formelinterpreter von Andreas Mayer @ ZW für den Sysop-Teil der MAUS |
Autor: | Andreas Mayer @ ZW |
Archivename: | FWDPM20.ARJ |
Archivlänge: | 37512 |
Beschreibung: | FWD_PM Version 2.0 Programm zum weiterleiten von PMs |
Archivename: | GATE2GRP.EXE |
Archivlänge: | 17222 |
Beschreibung: | Ein Utility für Günters Gate. Das Programm scannt das GATE.CFG und trägt den Gateway-User sowohl als Mitglied in alle Gruppen ein, als auch in die Gruppen-Bestellung. So kann man sicher sein, daß der Gate auch wirklich Lese- und Schreibzugriff auf alle Gruppen im GATE.CFG hat, und die Gruppen auch im Auto-Tausch bekommt. Lange Namen klappen! (9/94) |
Autor: | Michael Keukert @ AC2 |
Archivename: | GSTAT13.ZIP |
Archivlänge: | 25746 |
Beschreibung: | GATESTAT analysiert die Logfiles von Waffle- oder FX-UUCICO (Günters- Gate). Voll kompatibel zu NetStat ab 1.9. Partnerrechner individuell konfigurierbar. Einzelabrechnung auch pro Partnersystem als Summe. Neue Telekom-Tarife von '96 werden berücksichtigt. Analyse komplett, monatsweise oder über beliebigen Zeitraum. Bugfix für Mondscheintarif! |
Autor: | Michael Keukert @ AC2 |
Archivename: | G125.ZIP |
Archivlänge: | 93551 |
Beschreibung: | Gateway von G.Stück V1.25, auch genannt Günters Gate |
Autor: | Günter Stück @ HB |
Archivename: | GATEWAY.ZIP |
Archivlänge: | 31081 |
Beschreibung: | Beschreibung zum Gateway von Günter Stück Als TEX und DVI. |
Archivename: | GENDBDIF.ZIP |
Archivlänge: | 24517 |
Beschreibung: | Datenbankmodul zum Maus-Archie Server. Dieses Programm, im MAUS(!)- Verzeichnis gestartet, rödelt den Programmteil durch und erzeugt dabei ein MA-[mein Mauskürzel].DAT. Dieses File bitte packen und in meinen persönlichen Programmteil uploaden. Kurze Zeit später ist Deine Maus auch über den Maus-Archie abfragbar. |
Autor: | Michael Keukert @ AC2 |
Archivename: | GLASNOST.ARJ |
Archivlänge: | 11871 |
Beschreibung: | Dieses Programm setzt bei allen Maus-Gruppen, die OWK sind (Öffentlich, WriteAccess und KeineMitglieder) zusätzlich noch das 'SogarGaeste' Flag, damit auch Gaeste die entsprechende Gruppe lesen(!) können. Läuft nur mit Maus-Versionen 7.x ts |
Autor: | Michael Keukert @ AC2 |
Archivename: | GODLIKE.EXE |
Archivlänge: | 11391 |
Beschreibung: | Setzt von der Kommandozeile aus für beliebige User den Sysop-Status. |
Autor: | Michael Keukert @ AC2 |
Archivename: | GRPST12.ZIP |
Archivlänge: | 18434 |
Beschreibung: | GroupStat V 1.2 Erstellt Statistik über das Messagevolumen von Gruppen |
Archivename: | HISTAT.EXE |
Archivlänge: | 29693 |
Beschreibung: | Hi(res)Stat(istik) gibt die "Klötzchengrafik"-Statistik über die Maus online/offline-Zeiten im Grafikmodus (und damit feiner auflösend) auf dem Bildschirm aus. Ist natürlich nur was für Tastatursysops, geht dafür aber auch während die Maus läuft. VGA erforderlich. |
Autor: | Michael Keukert @ AC2 |
Beschreibung: | Sehr gutes Tool, das automatisch, Hilftexte, Userbegrüßungen, Netzauswertungen, Saugtausch und und und........ Fast die Ei-legende-Woll-Milch-Sau |
Autor: | Frithard Meyer-zu-Uptrup @ S3 |
Archivename: | Jane |
Beschreibung: | Jane ist die Onlineversion von James. Man kann sich online immer einen aktuellen Bericht geben lassen. Es ist auch möglich, an Kommandos Parameter online zu übergeben, z. B. um online den NetStat eines bestimmten Monats abzufragen, man bekommt dann einen Prompt zur Eingabe des Monats. Das Menü und die einzelnen Funktionen sind frei zusammenstellbar. |
Autor: | Frithard Meyer-zu-Uptrup @ S3 |
Archivename: | Jerry |
Beschreibung: | Jerry sieht nach, ob für bestimmte Benutzer neue PMs da sind. Man kann das z. B. dazu verwenden, um im CALLCHK.BAT nach PMs für James zu sehen und dann James per Callcheck-Event sofort zu starten. |
Autor: | Frithard Meyer-zu-Uptrup @ S3 |
Archivename: | Jimmy |
Beschreibung: | Ist die Batchversion von James und beherrscht die Zeitfunktionen, Start-/Stoppzeiten oder z. B. die letzte Mausverbindung. Es werden unterschiedliche Errorlevel zurückgegeben, man kann diese dann im Batch auswerten. Ich nehme das z. B., um zweimal die Woche die Platten zu optimieren. Jimmy enthält auch eine Funktion, um in einer Datei per Zeitkriterium definierte Events auszulösen. Dadurch sind auch Events, die nur an bestimmten Tagen oder mehrmals täglich laufen, möglich etc. |
Autor: | Frithard Meyer-zu-Uptrup @ S3 |
Archivename: | KILLLOKL.ARJ |
Archivlänge: | 11683 |
Beschreibung: | Dieses Programm scannt das MGRUPPEN.DAT File nach lokalen Gruppen, und bietet bei jeder gefundenen die Möglichkeit, diese zu löschen. |
Autor: | Michael Keukert @ AC2 |
Archivename: | KILLMSG.ZIP |
Archivlänge: | 17084 |
Beschreibung: | Löscht öffentliche oder persönliche Nachrichten aus der Maus-Messagebase. Es kann grundsätzlicher ein ganzer Nachrichtenbereich (von...bis) angegeben werden. Ideal um den Dumpfmumpf unseres 'Hackers' zu löschen. |
Autor: | Michael Keukert @ AC2 |
Archivename: | Klette 0.16 |
Beschreibung: | Dieses Tool sollte möglichst auf jeder Maus installiert sein, mindestens aber an den wichtigsten Gatemäusen, damit die User die Verkettungen im mausinternen Format mitbekommen (geht auch übers Netz mit). Siehe auch: Was ist Klette und Use2Maus? |
Autor: |
|
Archivename: | KrunUser |
Beschreibung: | Programm um die als gelöscht markierten User auch wirklich aus den Mausdaten zu löschen. |
Archivename: | M2M.ZIP |
Archivlänge: | 20216 |
Beschreibung: | Maus-to-Maus-GateWay Stand 21.11.94 |
Archivename: | MAKEPKT.LZH |
Archivlänge: | 3454 |
Beschreibung: | Programm zur Erstellung eines Fido FTS001 kompatiblen Mailpackets. Sämtliche Parameter werden per Kommandozeile übergeben. |
Autor: | Michael Keukert @ AC2 |
Archivename: | MKTIC05.ARJ |
Archivlänge: | 53803 |
Beschreibung: | MakeTic V 0.5 Man kann damit Download incl. James-TicFiles in der
MAUS anbieten. Dazu definiert man unter Protokollen z.B. "ZModem
mit (T)IC" und bindet MakeTic in Protbat.bat ein.
|
Autor: | Frithard Meyer-zu-Uptrup @ S3 |
Archivename: | MCDC_RTM.ZIP |
Archivlänge: | 60328 |
Beschreibung: | Das Laufzeitsystem für den MAUS CD CONTROLLER. Braucht ihr nur einmal zu saugen bzw. gar nicht, wenn Borland Pascal 7.0 vorhanden ist oder das Laufzeitsystem einer früheren MCDC-Version. |
Autor: | Uwe Schlenther @ S3 |
Archivename: | MausChat |
Beschreibung: | Ist ein Chatter speziell für die MAUS. Er macht IO über den Fossiltreiber und funktioniert daher auch mit ISDN. Ferner holt er sich die Benutzerdaten von der MAUS und stellt somit die Umlaute auf Benutzerseite richtig dar und das Ganze in der vom Benutzer gewählten Zeilenzahl. Dann gibt's noch Gimmicks wie Musikfiles, Chat-Logfile, Userinfo oder Chatten über den Directport. |
Autor: |
|
Archivename: | MAUSDOOR.ARJ |
Archivlänge: | 26747 |
Beschreibung: | Zusatzprogramm und Manager für externe Programme an der Maus. Sollte EIGENTLICH bei jeder Maus, die Jörg ausliefert, dabeisein. |
Autor: | Michael Keukert @ AC2 |
Archivename: | MAUSDOWN.EXE |
Archivlänge: | 7141 |
Beschreibung: | MausDown verzögert in Batchfiles bis zu einer Minute. Die abgelaufene Zeit wird grafisch durch einen Balken angezeigt. Zusätzlich kann man aber vor der Zeit abbrechen. Abbruch oder normales Ende werden durch verschiedene Errorlevel zurückgegeben, so das Verzweigungen im Batchfile möglich sind. Dieser Version benötigt KEINEN Ansi-Treiber mehr! |
Autor: | Michael Keukert @ AC2 |
Archivename: | MFILE22.ZIP |
Archivlänge: | 33279 |
Beschreibung: | MausFile, universeller Filelistengenerator für Mäuse, Version 2.2 Erweiterte Kommandozeilenaufrufe, beliebige Gruppen, u.v.m. |
Autor: | Michael Keukert @ AC2 |
Archivename: | MFS108.ZIP |
Archivlänge: | 119244 |
Beschreibung: | MausFileSucher 1.08. Der MAUS-Archie. |
Archivename: | MC239.ZIP |
Archivlänge: | 298902 |
Beschreibung: | MausRingComander v2.39 Nun mit Unterstützung des SQ-Rings. Suche nach Dups, Laden des ÖPTs, Wahl des Einfügemoduses (Copy, Move). Von Alexander Güth @ AN |
Archivename: | MCALL.EXE |
Archivlänge: | 4688 |
Beschreibung: | MCALL.EXE anonymisiert das Logfile des Vortages (oder das über die Kommandozeile übergebene) und speichert es in der Datei MCALL.MTF, von wo es in eine Gruppe gepostet werden kann. |
Autor: | Michael Keukert @ AC2 |
Archivename: | MCC057.ZIP |
Archivlänge: | 261609 |
Beschreibung: | MCC Version 0.57 - jetzt lauffähig ab Maus Version 7.95e und schon mit ein paar Änderungen gegenüber der 0.55-Version. Viel Spaß! |
Autor: | Michael Keukert @ AC2 |
Archivename: | MCDC20E.ZIP |
Archivlänge: | 89539 |
Beschreibung: | MAUS CD CONTROLLER 2.0e. Das Utility zum Konvertieren von Dateibeschreibungen auf CD-ROM ins Programmteilformat der MAUS. |
Archivename: | MCLOCK.ZIP |
Archivlänge: | 19130 |
Beschreibung: | Dieses kleine Programm ist ein optisch ansprechenderer Ersatz für WAIT4UHR von Jörg Stattaus. Mit MCLOCK kann man innerhalb eines Batchfiles auf eine bestimmte Uhrzeit warten. Braucht man z.B. beim Abendnetz. Viel Spaß! |
Autor: | Michael Keukert @ AC2 |
Archivename: | MegaHang |
Beschreibung: | Ist ein kleines Programm, das bei häufigen Abstürzen der MAUS (wenn z. B. das Modem total hängt) der Bootvorgang nach x Neuboots verzögert wird und nach y Neuboots durch noch längere Pausen unterbrochen wird. Dies verhindert ein endloses Neubooten des Rechner bei hängendem Modem. |
Archivename: | MEVENT.ARJ |
Archivlänge: | 11876 |
Beschreibung: | Zeigt die Maus-Events im grafischen Überblick an. Kurz und gut! |
Autor: | Michael Keukert @ AC2 |
Archivename: | MFORMEL.ARJ |
Beschreibung: | Das Formelprogramm für Maus-Sysops. Beliebige Formeln können eingebunden werden. Sämtliche Winkelfunktionen, algebraische Logik mit Hierarchie (Punkt vor Strich), zusätzlich noch Quersumme und Wochentag in die Berechnung einbauen. |
Autor: | Michael Keukert @ AC2 |
Archivename: | MLZWO.ZIP |
Archivlänge: | 22063 |
Beschreibung: | MLZWO - Neue Version 5/94 Verwaltet Mailinglisten |
Autor: | Marcus Schmidke @ BM |
Archivename: | MPROGVW.ZIP |
Archivlänge: | 14596 |
Beschreibung: | MPROG.EXE speichert den Inhalt des MPROG.DAT in eine lesbare ASCII-Datei namens MPROG.TXT |
Autor: | Michael Keukert @ AC2 |
Archivename: | MPWD14.ZIP |
Archivlänge: | 34520 |
Beschreibung: | Neue /TERBO-Version von MistPassword - dem Passwortsicherheitsscanner. MistPWD meckert User mit einem individuellen, konfigurierbaren Text an, wenn ihr Passwort nicht gewissen Sicherheits-Mindestanforderungen genügt. Neu: eine (zusätzliche) DPMI-Version mit erheblichem Geschwindigkeits- gewinn. |
Autor: | Michael Keukert @ AC2 |
Archivename: | MSGID111.ZIP |
Archivlänge: | 23335 |
Beschreibung: | Analysiert die vergebenen MSG-Ids (Allg & Pers) und man kann die ID damit auch setzen. |
Archivename: | MT2BIN.ZIP |
Archivlänge: | 13262 |
Beschreibung: | MT2BIN dekodiert aus Gateway-Infiles eventuell enthaltene UUcodierte Binaries automatisch. Neue, erheblich verbesserte Version. In drei Durchläufen wird das INFILE abgearbeitet und sinnvoll sortiert. So wird eine weitaus größere Dekodierungsrate (bisher ca. 20, jetzt ca. 90%) erreicht. Source ist dabei, damit mir keiner Schweinereien nachsagt. |
Autor: | Michael Keukert @ AC2 |
Archivename: |
|
Beschreibung: | Trägt $-User in Gruppen ein, die über die Kommandozeile übergeben werden. |
Archivename: | MUVIEW.EXE |
Archivlänge: | 16123 |
Beschreibung: | Der Remote-Userdaten-Editor (R.U.D.E.). Kann derzeit zwar nur anzeigen (und (noch) nicht editieren), dafür kann man diese Version 0.2 auch über die Kommandozeile aufrufen. Also entweder mit der Usernummer oder über den vollen Namen oder - wie bisher - interaktiv. MUView /? zeigt eine kurze Hilfe. Von MC 2.21ß/DPMI @ AC2 |
Archivename: | MVIEW.EXE |
Archivlänge: | 34500 |
Beschreibung: | Neue Version von MVIEW. Das Programm dient zum schnellen Browsen durch die Messagebase, um z.B. Hackermails aufzuspüren. Netzwerkfähig! Neu in dieser Version: Netzwerk-Update, wenn zwischendurch neue Messages reingekommen sind. Suche nach Netz-MsgID. Nur MSGs eines Users. |
Autor: | Michael Keukert @ AC2 |
Archivename: | MVPACK.ARJ |
Archivlänge: | 33225 |
Beschreibung: | Das MV-Pack stellt zwei Programme zum MAUSVAR.DAT File im Mausverzeichnis zur Verfügung. MVV.EXE zeigt den Inhalt der Datei übersichtlich (und redirectable) an, MVPATCH erlaubt, im Falle eines Unfalls oder eines versehentlichen Löschens die Anruferzahl der Maus in dieses File zu patchen. |
Autor: | Michael Keukert @ AC2 |
Archivename: | NetJames |
Beschreibung: | NetJames ist quasi eine 'Shell' für das MausNet. Er kann beliebige Archive über das Netz versenden, er regelt MAUS-MAUS Gates oder hat Funktionen, um das Netztiming z. B. im Abendnetz zu verbessern. Man kann aber beispielsweise auch beliebige Archive per NetJames über das MausNet an benachbarte Mäuse weitergeben, ohne 'Ausreißer' beim Netztiming zu riskieren. |
Autor: | Frithard Meyer-zu-Uptrup @ S3 |
Archivename: | NETMC04.ZIP |
Archivlänge: | 42298 |
Beschreibung: | Keukert & Stattaus Productions proudly presents: NetMC 0.04 Einfaches Programm zum Fileaustausch zwischen zwei Mäusen über das MausNet. Nur ein Programm wird benötigt. Alternative für die Mäuse, die James nicht installieren wollen. |
Autor: | Michael Keukert @ AC2 |
Archivename: | NSTAT19.ZIP |
Archivlänge: | 59468 |
Beschreibung: | Netstat V 1.9. Kann bereits das Tarifsystem ab 1.1.96 Realmode und DPMI |
Archivename: | NU2MMAUS.ZIP |
Archivlänge: | 316733 |
Beschreibung: | NewUse2Maus 1.20.1 mit allem, was benötigt wird, um es auf einer Maus zu installieren. CheckU2M.ARJ und Service.ARJ sind im Archiv enthalten, die beiden sorgen dafür, daß es abschaltbar ist (CheckU2M.ARJ) und daß der User es selbst abschalten kann (Service.ARJ). NewUse2Maus stellt Verkettungen in '-'-Zeilen anhand von 'R'-Zeilen her. |
Autor: | Timm Ganske |
Archivename: |
|
Archivlänge: |
|
Beschreibung: | Programm zum erzeugen einer Busy-Meldung bei ISDN-Karten, wenn die Maus über das analog Modem belegt ist. |
Autor: | M. Schmidke (ms@bm.maus.de) |
Archivename: | REQUEST.ZIP |
Archivlänge: | 304830 |
Beschreibung: | Wie man der Maus den FidoNet Filerequest beibringt. |
Autor: | Michael Keukert @ AC2 |
Archivename: | SCHEDULE.ZIP |
Archivlänge: | 16089 |
Beschreibung: | Schedule ist ein Hilfsprogramm zur automatisierten monatlichen Auswertung /und/ Archivierung der Maus, MausNet und Gatewaydaten. Mit Hilfe von Schedule können umfangreiche Batche (beiliegend) gesteuert werden, die hier seit über 2 Jahren tadellose jeden Monat die Abrechnung erstellen, posten und archivieren. |
Autor: | Michael Keukert @ AC2 |
Archivename: | SCHNUL49.ARJ |
Beschreibung: | Schnulli 4.9 - SaugTausch für die MAUS *** Diese Version wird für MAUS 7.95i benötigt *** Bitte lesen!.doc und die History in schnulli.doc beachten! DOS und OS/2-Version dabei. |
Autor: | Frithard Meyer-zu-Uptrup @ S3 |
Archivename: | Service |
Beschreibung: | Service kommt unter 'Externe Programme' in die MAUS. Auch hier ist wie bei Jane das Menü frei erstellbar. Man kann mit Service den Schnulli PPT-Autoversand, NewUse2MAUS, Urlaubstausch und Geburtstagsliste konfigurieren, nach PM-IDs suchen lassen und es können Infotexte eingebunden werden. |
Autor: | Frithard Meyer-zu-Uptrup @ S3 |
Archivename: | CONVPT.ARJ |
Archivlänge: | 35771 |
Beschreibung: | Enthält das Programm SETPTDAT.EXE V 0.2 und die passende Doku. Man kann damit streßfrei, risikolos und simpel den Programmteil konvertieren, d.h. auf gesetzten ProgteilDatPath umsteigen. jc@hb-Edition. V 0.2: Mir Parameter -R wird das Ganze umgehkehrt gemacht. |
Archivename: | Speed11.ARJ |
Archivlänge: | 107814 |
Beschreibung: | Speed-Tausch - V 1.1. Beschleunigt den MausTausch ein wenig. *** Diese Version wird benötigt für MAUS 7.95h *** *** Nicht mit älteren MAUS-Versionen einsetzen *** Dabei: Speedoff Real&DPMI, Speedon, Doku etc. |
Autor: | Frithard Meyer-zu-Uptrup @ S3 |
Archivename: | TEAM10.ARJ |
Archivlänge: | 45209 |
Beschreibung: | TeamShell V 1.0 TeamShell ist eine Shell um SysopTeam (von Stefan Uhlmann) herum. Es kann jeder beliebige Sysop Wochensysop sein und nicht nur der Dämon. Neu: /NEUUSER /SUCHEUSER funktioniert wie /NEU und /SUCHE, Mails von MAUS, MausNet etc. werden aber ignoriert. |
Autor: | Frithard Meyer-zu-Uptrup @ S3 |
Archivename: | TICTAC11.ARJ |
Archivlänge: | 64242 |
Beschreibung: | TicTac V 1.1 Importiert FIDO-Fileechos, JAMES-Fileexporte (Filenetz, Saugtausch) und MAUS-Ringe (allerdings nur komplett!)in den Programmteil. Konfigurationsanleitung ist in der Doku zu James enthalten! Stand: wie James 1.1 |
Archivename: | TOPLIN11.ZIP |
Archivlänge: | 12137 |
Beschreibung: | TopLines v1.1, zeigt jetzt auch Anrufzahl und Zahlerstatus an. |
Archivename: | VONXY.ARJ |
Archivlänge: | 12287 |
Beschreibung: | Erstellt Logfile über den Usenet-Traffic. Statt XY das eigene Mauskürzel einsetzen, also z.B. VONK2.EXE oder VONHRO.EXE |
Autor: | Michael Keukert @ AC2 |
Archivename: | XENOPHOB.EXE |
Archivlänge: | 15235 |
Beschreibung: | XenoPhob setzt für einen beliebigen User ein neues, zufällig ermitteltes Passwort in die Userdaten ein. Aufruf über die Kommandozeile mit der Usernummer (auch negative für Gateways) oder den Usernamen. Benutzung auf eigene Gefahr! Von MC 2.21ß/DPMI @ AC2 |
Die gesammelten News-Texte aller Mausversionen sollten eigentlich immer in der K2, Gruppen-PT Sysop.Prog liegen. Deshalb hier nur die der letzten Versionen.
Um die aktuelle Version der Maus-Soft, des MNConfig und des MausNet zu erfahren, genügt ein Blick in den ISB-Eintrag der Maus K2:
MAUS | 7.95i |
MausNet | 2.54 |
MNconfig | 2.0 |
NetStat | 1.9 |
KrunUser | 2.95 |
Fwd-PM | 2.1 |
MsgID | 1.11 |
OUT_IN | 1.0 |
TopLines | 1.1 |
Aktuelle Versionen von Hilfsprogrammen zur Maus (Monatliches Posting in der Gruppe Tools.Beta)
Programm | aktuelle | aktuelle | aktuelle |
Release | Beta | Entwicklerversion | |
BinkCost2 (incl. Source) | 2.0 | ||
CDFNet (incl. Source) | 1.0 | ||
Gate2Grp | 1.0 | 1.1 | |
Gatestat | 1.2 | ||
Glasnost (incl. Source) | 1.0 | ||
Histat | 0.2 | ||
KillLokl (incl. Source) | 1.0 | ||
KillMsg (incl. Source) | 1.0 | ||
MC Mausring Commander | 2.41 | ||
MCC Maus Control Center | 0.59 | ||
MCall | 1.0 | ||
MClock | 0.1 | ||
MFormel | 1.01 | ||
MProg (incl. Source) | 1.0 | ||
MT2Bin (incl. Source) | 1.2d | 1.2j | |
MUView | 0.1 | ||
MUser | 1.0 | ||
MView | 0.05 | ||
MakePkt (incl. Source) | 0.01 | ||
Maus2RA (incl. Source) | 1.4 | ||
MausDoor | 1.1 | ||
MausDown | 1.0 | ||
MausFile | 2.7 | ||
MistPassword | 1.4 | ||
NetMC (Fileversand per Netz) | 0.4 | ||
Schedule (Autom. Abrechnung) | 1.0 | ||
VonXY (incl. Source) | 1.0 | ||
Xenophob (Zufallspassworte) | 1.0 | 1.1 |
Programm | aktueller |
Release | |
DokuServe | 0.7 |
MEvent | 1.0 (klappt nicht mit Multiplex-Events) |
Folgendes ist bei der aktuelle Maussoft zu beachten
Die Maus ab Version 7.95h setzt keine Baudraten mehr selber. Das muß man vorher selber in Config.sys bzw Autoexec.bat erledigen. Hier das Beispiel für Port 1
CONFIG.SYS DEVICE=C:\UTIL\X00.SYS E 0=COM1 T=2048 R=2048 FIFO=15 AUTOEXEC.BAT XU set:0:57600:8N1 lock:0:57600:8N1
Probleme mit MENDE.DAT
Von: Timm Ganske @ OF (Mi, 25.12.96 17:43)
MId: 199612251743.a15779@of.maus.de
Hier noch eine kleine Warnung an alle, weil ich damit lange
gekämpft hatte: Laßt im Callchk das MENDE.DAT nicht neu
schreiben, das gibt eine Sharing violation, wenn dieser Fall eintritt. Erst
mit der nächsten Version der Maus wird das dann (hoffentlich) wieder
gehen.
Betroffen ist insbesondere die Beispielanwendung von FORTRAND aus meinem SYSOP.PROG. Wer keine User mit so dämlichen Scripts hat, die immer genau während des Abspanns auflegen, kann das Risiko natürlich weiterhin eingehen, man muß halt damit rechnen, daß es auch mal schiefgeht ...
Mausabsturz beim Programmetaggen
Bei mehr als 50 selektierten Programmen im Programmtaggen-Menü
stürzt die Maus einfach ab. Z.B. so:
!!! --------------------- MAUS abgestürzt ! --------------------- !!! ** Grober Schnitzer - MAUS 7.95j/dpmi/gs/beta ** ** ganz außen ** ** Hauptmenü ** PrgTeil-Ö ProgLöschen -O ProgTagg -O Benutzereingaben: J;P;LJ;L Turbo-Fehler #201 bei 0014:01d5 - Range check: 101 <> 1..100 Traceback: 0010:34cf 0010:39bd 0010:3f4b 0010:86fa 000e:1bf8 0002:119f 001d:001b 0001:0101 Programm beendet!
Fehler in der Maus 7.95g (ist die alt!)
Von: Gereon Steffens @ K2 (So, 07.01.96 19:27)
Folx,
leider ist in der neuen MAUS 7.95g ein peinlicher Bug, der auch ziemlich drastische Auswirkungen haben kann (wie z.B. CLP erfahren musste): Wenn man online eine Gruppe im SysOp-Teil löscht, dann kann das dazu führen, daß der MAUS mehr oder weniger zufällig Netzgruppen entzogen werden. Also bitte Finger weg von dieser Funktion!
Das entsprechende Äquivalent im Tausch (GL-Kommando) hat diesen Bug nicht. Wo ich gerade dabeibin, nochmal der Hinweis auf die Problematik mit falsch eingestellten Baudraten. Bitte lest und beachtet A26284@K2 in SYSOP.TECH! Ich bin derzeit noch mit einigen anderen Änderungen beschäftigt, eine neue Version gibt's sobald wie möglich.
Sorry for any inconvenience.
Gereon
Fehler in der Maus 7.95j
Der Aufruf der 'UserRlisten', 'Zahler' erzeugt einen Mausabsturz.
Das MausNet verträgt im Moment nur zwei Modems!!!
Wenn man also die Maus mit drei Modems betreibt, muß man im
MausNet auf ein Modem verzichten. In der Maus müssen unbedingt die
Modems 1 und 2 diejenigen sein, die auch im MausNet aktiv sein sollen. Eine
andere Einstellung bringt nur Probleme.
Nochmal der Hinweis: die MAUS macht keine SetBaudrate-Aufrufe mehr, wenn FixedBaudrate=TRUE ist. Das bedeutet, daß vor dem Start der MAUS sicher- gestellt sein muß, daß die Baudrate der seriellen Schnittstellen und auch die Übertragungsparameter korrekt gelockt *und* eingestellt sind. Wenn man X00.SYS verwendet, kann man das mit XU.EXE einstellen, etwa so: XU set:0:57600:8N1 lock:0:57600:8n1 für jeden Port. Für andere FOSSIL-Treiber bitte in deren Doku nachsehen.
Gateways dürfen Msgs bis zu 12 Std. aus der Zukunft eintauschen
Bugfix: Gruppen-Löschen im SysOp-Teil tut's wieder
Bugfix: Anrufcounter bei aufeinanderfolgenden Anrufen desselben Users wird jetzt korrekt hochgezählt.
Wenn MPROG.DAT nicht vorhanden ist, gibt's jetzt eine entsprechende Meldung.
MausTausch: bricht maschinenlesbare Infofiles nicht mehr um. Im ITI gibt's dazu ein neues Flag "W", mit dem angezeigt wird, ob ein File umbrechbar ist (W+) oder nicht (W-).
MausTausch: unterstützt TD- und TZ-Kommando wie in der Quark.
Beim Start per "m7com /t ..." wird keine "MAUS XX - Start..."-Zeile mehr ins MCALL.LOG geschrieben.
ConnectBaudXX ist jetzt Longint, d.h. man kann Bitraten von mehr als 64K angeben.
DirectBaud ist jetzt ebenfalls longint.
Neue Cfg-Var CharWaitTimeOut (word, default 110). Damit kann man den Time- Out in Sekunden angeben, nach dem die MAUS den User mit "to" rauswirft. Kleinster möglicher Wert ist 10, und beim Ablauf wird auch wie bisher erst noch 3mal gepiept und weitere 10 Sekunden gewartet.
Neue Cfg-Var LowMemoryLimit (longint, default 0). Bei Werten > 0 wird zwischen Anrufen überpüft, ob noch soviel Memory frei ist wie angegeben. Wenn das nicht der Fall ist, wird der Event aus LowMemoryEvent (word, default 203) ausgelöst. Damit kann man sich gegen die Speicherlecks schützen, die entstehen können, wenn ein User mitten in einer Routine auflegt, die Speicher alloziert hat und nicht mehr freigeben kann. Wenn man den Event umdefiniert, kann man auch einen automatischen Wechsel von RealMode- zur DPMI-Version implementieren.
Bugfix bei der Behandlung von M-Zeilen im Tausch, sollten jetzt überall funktionieren.
Gateways dürfen jetzt beliebige Adressen in V-Zeilen schicken.
Die Routine zur ITG-Erstellung ist komplett neu und braucht nicht mehr so riesige Speichermengen wie früher.
Die Logfilestatistik kommt mit 5stelligen Anrufzahlen zurecht.
Einige Overlays verschoben, dadurch >20K mehr Speicher in der RealMode- Version.
BugFix: in der DPMI-Version schlug die Maximalgrößenerkennung fürs Outfile oft viel zu spät zu.
Neue CfgVar ModemX.RingCount (word, default 0). Damit kann eingestellt werden, beim wievielten Klingeln die MAUS abheben soll. War doch nicht so schwer einzubauen...
Wenn Response_RING auf '*' endet und das Modem nach dem RING noch mehr Daten schickt, dann werden diese im MCALL protokolliert, wenn LogIgnored=TRUE ist.
In den Userdaten wird jetzt festgehalten, wann der Record zum letzten Mal geändert durch NUDE oder Tauschkommandos geändert wurde. Die Tauschkommandos zum Gruppen-Be- und Abstellen zählen dabei nicht mit.
MNconfig:
Infofiles SYSOPGRP.INF, SBOXLIST.INF und SBOXLISG.INF auf 8 stellige MAUS- Namen angepasst, ebenso den Netzplan.
klemmt Quarks die lokalen Gruppen der Server-MAUS nicht mehr ab.
auführlichere Log-Meldungen zur Gate- und Fremdbox-Konfiguration.
PK-Zeile: akzeptiert jetzt auch den Typ "H" für US Robotics HST-Modi Die Connect-Typen sind übrigens additiv gemeint, V und H schließen also A nicht mit ein!
Aus dem Newstext:
Sorry daß das mit dieser Version so lange gedauert hat, aber ich hab' im Moment einen ca. 60-Stunden-Job, und außerdem in den letzten Wochen auch noch einige wichtige Sachen privat zu tun.
Gereon
In Zusammenarbeit mit dem neuen MNconfig werden die Daten aus den D- und Z- Zeilen der .EXPs ausgewertet und entsprechend geroutet, s.u. Der Abschnitt dazu ist *WICHTIG*, bitte aufmerksam lesen!
Kosmetische Änderung im Programmteil-Menü
Von anonymen Gruppen können nur noch SysOps und GC die Leser- und Mitglieder- listen abrufen.
Neue CfgVar: ConnectMitPort (boolean, default False). Bei True wird die Portnummer an den Connectstring angehängt, damit man im MCALL.LOG sofort sehen kann, auf welchem Modem ein Anruf 'reinkam.
Wenn eine Mitteilung mit M-Zeile kommt, entfernt die MAUS keine Leerzeilen mehr, außerdem wird bei solchen Mitteilungen die Umlautwandlung sowohl beim Import als auch beim Export abgeschaltet.
ITG ist wieder schneller.
Bugfix: "Vernetzung ändern" im SysOp-Teil geht nur für Gruppen, die für die Box erlaubt sind.
Bugfix bei E-Zeilen aus der Zukunft.
Der Async-Tausch tut's nur, wenn man das MausTausch-Login benutzt, und das prüft die MAUS jetzt auch ab.
Bugfix: Loginzeit-Berechnung beim Neueintrag im Relogin gefixt. Zum Neueintragen bekommt man jetzt soviel Zeit wie ein normaler User zu dieser Zeit, mindestens aber NeuLoginZeit Minuten (neue Cfg-Var, default 5).
Sicherheitscheck: bei jedem Start der MAUS wird überprüft, ob es evtl. Dubletten bei den Gruppennamen gibt. Falls ja, wird eine entsprechende Warnung ins MCALL.LOG geschrieben.
Bugfix: Spannermodus wird nach einem externen Chatter wieder korrekt ein- geschaltet.
Zugriffsmodes für (hoffentlich alle) Files geändert. Die MAUS öffnet üblicherweise ihre Files mit Modus 162 (Read/Write, Lesen für andere Erlaubt), andere Programme, die solche Files lesen wollen müssen dann Modus 64 (Read-Only mit Sharing) benutzen.
Zeitfreigabe unter OS/2 an einigen weiteren Stellen eingebaut.
Gruppenübergreifende Kommentare im Tausch sind erlaubt.
Zu jedem ConnectStringX kann per ConnectEventX (word, default 0) ein Event konfiguriert werden. 0 bedeutet, daß kein Event ausgelöst wird.
Bei der Bearbeitung von UQx- und GQx-Kommandos gibt die MAUS jetzt 'was aus.
ITK um G-Zeile erweitert, wie in TAUSCHBAU besprochen. Jedes Kommando ist einer (G)ruppe zugeordnet, im Moment sind das folgende:
U | für Userdaten |
A | für administrative Userdaten |
G | für Gruppendaten |
T | für Tausch-Optionen |
F | für FE-Features und Technik. |
Neue Cfg-Var DownloadSperre (char, default 'D'). Damit kann angegeben werden, ob Uploads zunächst für weitere Downloads gesperrt werden sollen. Bei einer Sperre muss erst der SysOp oder PT-Wart den Download solcher Files freischalten (das geht über Begleitinformationen ändern). Die möglichen Werte für diese Variable sind D - Sperre deaktiviert, N - Uploads von Neulingen werden gesperrt, $ - Uploads von Nichtzahlern werden gesperrt.
Bugfix beim Tauschkommando UF: zu lange FWD-Adressen werden jetzt als Fehler abgelehnt.
D- und Z-Zeilen (für Domainangaben) werden aus den .EXPs gelesen
und alles, was nicht .maus.de oder .maus.sub.org ist, wird in einem neuen
File \maus\net\MN-ALIAS.DAT gespeichert. Dieses File liest die MAUS beim
Start und routet Mails entsprechend.
Für die Zeilen gibt es zwei Formate: wenn der Eintrag mit einem
"." beginnt, dann heisst das, das die MAUS unter ihrem normalen
Kürzel als Rechner unter dieser Domain bekannt ist. Wenn der Eintrag
nicht mit "." beginnt, wird er als Rechnername interpretiert. Z.B.
wären im UN.EXP also "D.maus.ruhr.de" und
"Dun.maus.ruhr.de" äquivalent, wichtig wird der Unterschied
z.B. bei F und DU3.
Die Auswertung am Beispiel eines (hypothetischen) .EXP-Ausschnitts
für K2:
D.maus.de
Z.maus.sub.org
Z.maus.rhein.de
Zmausk2.cologne.de
Mail an foo@k2.maus.de, foo@k2.maus.sub.org, foo@k2.maus.rhein.de und
foo@mausk2.cologne.de würde damit übers MausNet an die K2
geschickt,
bzw. von K2 lokal zugestellt.
Für Tool-Programmierer: Das MN-ALIAS.DAT ist - in Pascal-Notation
- ein
file of record
box: 0..255;
domain: string[50];
end;
Auf eine spezielle Reihenfolge der Records darf man sich nicht
verlassen.
Wenn eine Netzgruppe umbenannt wird, aber schon eine lokale Gruppe mit demselben Namen existiert, gibt's jetzt eine entsprechende Warnung.
Von : Frithard Meyer-Zu-Uptrup @ S4 (Do, 11.07.96 15:12)
Ferner zum Programmteil:
Änderungen am Programmteil
MAUS 7.95i Programmteil V 35
KonfigVariable ProgTeil.an geht jetzt, mit FALSE läßt sich also der ganze Programmteil lahmlegen um z.B. mit dem MC zu importieren. Damit man den Programmteil über Netzwerk / von Programmen aus sperren kann wird ferner in MausPath die Datei 'PROGTEIL.AUS' abgefragt - existiert sie, ist der Programmteil ebenfalls gesperrt. Beim Userhinweis bei gesperrtem Programmteil wird zwischen temporär gesperrtem Programmteil: ('Der Programmteil ist momentan gesperrt - Sorry' und kaputtem Programmteil ('Der Programmteil ist zur Zeit aus technischen Gründen nicht zugänglich - Sorry') unterschieden.
Bei deaktiviertem oder falsch konfiguriertem Programmteil stürzt die MAUS nicht mehr ab wenn sich ein User<>GAST einloggt.
Downloadsperre (siehe Gereons Newsfile), dazu noch: Info für Programmierer rund um den Programmteil: in IBMParameter ist der Status von gesperrten Files 'G'. Wer also in seinem Programm den Status nur auf 'X' abfragt, hat nichts weiter zu beachten. Programme die z.B. Filelisten erzeugen, sollten aber den Sperrstatus anzeigen.
OS/2-Version: Sortierung geht bei jeder Sortierung bis max. 15000 Programme
fritz
Schon seit 7.95i: der Default für die Cfg-Var BangLogout ist jetzt True.
SysOp-Userlisten haben Überschriften
Bugfix: bei M-Zeilen im Infile wird jetzt wirklich keine Umlautwandlung mehr gemacht.
Bugfix: RT 216 beim Dupecheck gefixt.
Bugfix: die MAUS erkennt ihre eigenen Aliasnamen (und die anderer Mäuse) aus den D/Z-Zeilen im .EXP jetzt korrekt als Empfängeradressen bei Mail.
Neues SysOp-Tausch-Kommando UO zum Setzen des Promi-Status
Fremdboxen dürfen nur diejenigen Gruppen bestellen, die ihnen auch erlaubt sind.
Die MAUS akzeptiert im Infile drei neue Headerzeilen: F, T und S für FollowUp-To, Reply-To und Sender. Wie bei der M-Zeile werden diese Dinger einfach nur durchgereicht.
Noch 'ne neue Headerzeile, nur für Gateways erlaubt: X. Damit können Flags zu dieser Mitteilung angegeben werden, derzeit wird nur eins unterstützt: R+ bzw. R-. R+ gibt an, daß diese Msg reexportiert werden darf (default), R- verbietet einen Reexport. Diese Flags werden nur in Gateway-Outfiles geschrieben. ACHTUNG bei MAUS-to-MAUS-Gates: die funktionieren nur noch dann, wenn entweder beide oder keine der Mäuse die X-Zeile kennen. Beim Update also mit den Nach- barn besprechen, oder die X-Zeilen rausfiltern (z.B. mit grep -v "^X")
Mit den Config-Variablen LocalInfoX.Desc und LocalInfoX.File (mit X in A..U) kann man lokale Infofiles festlegen. Online werden die im (I)nfomenü unter L(O)kales angeboten, per Tausch als Infofiles ILOKx. LocalInfoX.Desc ist die Beschreibung eines solchen Infofiles, eins der Zeichen in diesem String muss fuer die Menuauswahl in () angegeben werden. Dabei muß es sich um einen Buchstaben oder eine Ziffer handeln. LocalInfoX.File ist der Name der zugehörigen Infodatei, die im InfoPath liegen muß. Wenn Beschreibung oder File leer sind, oder das File nicht existiert, oder der Auswahlbuchstabe fehlt oder nicht eindeutig ist, wird so ein Config- Eintrag ignoriert.
Das Infofile ITG hat keine E-Zeilen mehr (damit ändert es sich nicht so oft), dafür gibt's ein neues Infofile ITE, das hat das Änderungsdatum.
Es gibt einen Cache für die CRCs derjenigen Infofiles, die 'richtige' Files sind. Der Cache wird in MausPath\M7INFO.CRC gespeichert, bei jedem Start prüft die MAUS, ob sich das Modifikationsdatum der Files gegenüber dem gespeicherten geändert hat, und berechnet die CRC neu, falls ja. Wenn M7INFO.CRC fehlt, wird der Cache komplett neu aufgebaut. Wer diesen Cache nicht haben will (weil er z.B. im CallCheck oder sonstwo Infofiles ändert), kann ihn per InfoFileCRCcache:=false abschalten.
Experimentelles Flag: MausPMRealName (boolean, default false). Wenn diese Variable auf true steht, generiert der Tausch-Exporter für MausNet-PMs eine N-Zeile (indem er einfach von der V-Zeile alles ab dem @ abschneidet).
Per Default werden Mails an die Usenet-Namen von Mäusen nicht mehr durchs MausNet geroutet. Man kann dieses Feature per UseMausAlias := true aber wieder einschalten.
Beim Einlesen von M7COM.CFG werden Events, deren Zeiten über Mitternacht hinweg gehen, angemeckert.
.maus.sub.org wird nicht mehr unterstützt
Bei Boxnummern-Kollisionen wird das ältere der beiden .EXPs in .EX umbenannt.
Bugfix: Gate-Erlaubniseinträge für ganze Domains werden jetzt korrekt erkannt.
Fremdboxen dürfen nur diejenigen Gruppen bestellen, die ihnen auch erlaubt sind.
Alle Werte sind in m7com.cfg einzutragen. Die aktuellen Werte, stehen immer in der m7com.req. Diese Datei legt die Maus an, wenn ConfigRequestFile gesetzt ist.
Default: | 'Tschüß' |
Bedeutung: | Damit werden die Benutzer verabschiedet. Also 'Tschüß, Herr Heinz' Einzutragen in m7com.cfg |
Default: | '500' |
Bedeutung: | Soviele Mails durchsucht der Dupecheck in der Maus bei öffentlichen Mails. Defaultwert ist DupMaxDefaultUser bzw DupMaxDefaultGate Einzutragen in m7com.cfg |
Default: | 'MausPath\MAUSPROG\' |
Bedeutung: | In dem Verzeichnis werden die Ordner für die verschiedenen Betriebssysteme angelegt Einzutragen in m7com.cfg |
Default: | 'GruppenProgPath\AMIGA\' |
Bedeutung: | Pfad für Programme des AMIGA-Betriebssystems Einzutragen in m7com.cfg |
Default: | 'MausPath\AsyncTau\' |
Bedeutung: | Pfad für den AsyncTausch Einzutragen in m7com.cfg |
Default: | '' |
Bedeutung: | Wenn der String des AutoLogX empfangen wird, der AutoEventX ausgeführt. Es kann jeder definierte Event (von 50-79) ausgelöst werden. Einzutragen in m7com.cfg |
Default: | '' |
Bedeutung: | Von Edgar Rosenboom Auf einen String hin, kann man hiermit einen Event auslösen. Dieser String kann, soweit ich mich richtig erinnere, bis "Sind sie eingetragener Benutzer" gesendet werden. Ich habe z.B. so den Faxempfang beim ZyXEL eingestellt. Das ZyXEL
sendet den String ZyXEL. Also folgendes eingetragen:
|
Siehe Auch die Frage dazu.
Default: | TRUE |
Bedeutung: | Bei TRUE gibt es in jedem Menü einen neuen Punkt "!", mit dem man sich nach einer (immer gleichen) Ja/Nein-Abfrage ausloggen kann. Dabei werden nur noch die Telefongebühren (falls eingeschaltet) und die Verbindungszeit ausgegeben. Einzutragen in m7com.cfg |
Default: | |
Bedeutung: | Hier werden die Batche gestartet Die MAUS startet ihre Batches (PACKER, PROTBAT, EXTERN, ARCCHECK, CALLCHK, TAU_IN, TAU_OUT) aus diesem Verzeichnis. Einzutragen in m7com.cfg |
Default: | 'MausPath\Batch\' |
Bedeutung: | Pfad in dem die Uploads, Packerergebnisse usw landen. Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Was passiert hier? Hmmmmm..:-) Einzutragen in m7com.cfg |
Default: | '0' | ||||||||||||||||||||||
Bedeutung: | Beitragslevel sagt, wie die MAUS die Beiträge "einfordern" soll.
Einzutragen in m7com.cfg |
Default: | 'MausNetPath\Conf\' |
Bedeutung: | Dort liegen alle EXP-Files der anderen Mäuse und auch das eigene CNF-File der Maus. Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Bei TRUE wird CALLCHK nicht nur nach jedem Anruf, sondern auch beim Modem-Check ausgeführt Siehe auch CheckBetweenCalls und das Kapitel dazu. Einzutragen in m7com.cfg |
Default: | '110' |
Bedeutung: | Damit kann man den Time-Out in Sekunden angeben, nach dem die MAUS den User mit "to" rauswirft. Kleinster möglicher Wert ist 10, und beim Ablauf wird auch wie bisher erst noch 3mal gepiept und weitere 10 Sekunden gewartet. Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Im E(X)tern-Menü wird der Menüpunkt für den Chatter nur noch während der SysOp-Sprechstunde (und wenn UserDarfChatten TRUE ist) angezeigt. Einzutragen in m7com.cfg |
Default: | '0' |
Bedeutung: | Extern.X.Menue-Nummer für den Chat. Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Bei TRUE wird ohne Nachfrage der CHAT gestartet. Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Bei TRUE wird die Zeit, die bei einem Chat verbraten wird, auf die Onlinezeit angerechnet, allerdings max. soviel, daß ein Event nicht gefährdet wird. Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Bei TRUE wird immer zwischen zwei Anrufen der Batch `callchk' ausgeführt. Dieser Batch kann über seinen Returncode einen Event auslösen, indem er entweder mit "exit X" beendet wird (4DOS), oder die Nummer des auszulösenden Events in die Datei "callchk.rc" im MAUS-Directory schreibt (BRNDAMAG.COM). Ein Returncode von 0 zeigt an, daß *kein* Event ausgeführt werden soll. Ein Beispiel: echo off rem %1 %2 %3 enthalten das Datum (D M Y) rem %4 %5 %6 enthalten die Uhrzeit (H M S) rem %7 enthält den Wochentag (Mo Di Mi ...) rem %8 enthält ein "C" oder "I" als Kennzeichen, ob der rem Batch nach einem Anruf (C), beim ModemCheckInterval rem (I) oder manuell (M) aufgerufen wurde. echo %1 %2 %3 %4 %5 %6 %7 %8 >callchk.log if exist %mauspath%callchk.rc del %mauspath%callchk.rc set RC=0 rem ein blödes Beispiel: rem Ab 23 Uhr wird zwischen zwei Anrufen Event 77 ausgelöst. if %4 gt 22 set RC=77 goto done rem ein besseres Beispiel (4DOS required): rem wenn über's Netz M7COM.CFG edtiert wird, startet die rem MAUS neu. rem Event 79 ist dafür im MAUS.BAT als "goto Again" rem definiert. set C_D=%@date[%@filedate[m7com.cfg]] set C_T=%@time[%@filetime[m7com.cfg]] set R_D=%@date[%@filedate[m7com.req]] set R_T=%@time[%@filetime[m7com.req]] if %C_D lt %R_D goto next if %C_D gt %R_D goto doit if %C_T gt %R_T goto doit goto next :doit set RC=79 goto done :next rem weitere Abfragen hier :done echo %RC >%mauspath%callchk.rc Der Returncode muß dabei in [0,50..79] liegen, alles andere wird ignoriert. Solche Events werden im MCALL.LOG protokolliert, falls definiert auch mit EventXXHinweis. Zwischen zwei Anrufen kann man per Alt-F4 die sofortige Ausführung von CALLCHK erzwingen. Siehe auch Was hat es mit dem CALLCHK.BAT auf sich? Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Wenn das TRUE ist, kann man die MAUS mit Ctrl-Break killen. Keine gute Idee. Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | HeapCheck für FreeList per ConfigVar CheckFreeList einschaltbar. Uralt und nicht mehr relevant. Von: Frank Berger @ AC (Mi, 07.02.96 08:46) Hallo Ulrich, ER> - HeapCheck für FreeList per ConfigVar CheckFreeList ER> einschaltbar FALSE US>Ich kann vor allem mit den letzten Satz nicht anfangen. US>Die einzigen Wörter die ich verstehe lauten: für; per; US>einschaltbar. Das sind 3/7 des Satzes. Also gut. Fangen wir mal systematisch an. Die Silben "List" und "Check"=Überprüfen dürften Dir geläufig sein, also haben wir schon mal zwei halbe und ein Drittel Wort auf der "Haben"-Seite ;-). Gratuliere! Jetzt hast Du über die Hälfte des Satzes, nämlich dreizehn Einundzwanzigstel, verstanden. Jetzt mal "im Ernst" weiter: "Heap" ist ein allgemein üblicher Ausdruck unter Programmierern, der einen Teil des Arbeitsspeichers umschreibt. Im allgemeinen werden umfangreichere Datenstrukturen (zum Beispiel Listen) auf dem Heap abgelegt. Dabei ist im Gegensatz zum "normalen" Speicher eine besondere Vorsicht bzw. Sorgfalt seitens des Programmierers vonnöten, da er selbst für das Reservieren und wieder Freigeben dieses Speichers verantwortlich ist. "HeapCheck" hat also was mit der Überprüfung dieses Speichers zu tun. In Zusammenhang mit "Heap" bedeutet "Free" das Freigeben von Daten auf dem Heap, d. h., diese Daten können danach überschrieben werden. Es geht also darum, daß der Speicherbereich irgendeiner Liste, die wohl auf dem Heap angelegt war, wieder freigegeben wird, um anderen Aufgaben zur Verfügung zu stehen. Wenn man solche "Free"-Aufrufe vergißt, passiert es leicht, daß irgendwann kein Speicher mehr zur Verfügung steht und das Programm abstürzt. "ConfigVar": Wenn Du "Var" noch nie gehört haben solltest, müßtest Du vielleicht doch mal den (Sysop-)Job oder die Gruppe wechseln. "ConfigVar" bezeichnet eine Maus-Programmvariable, die über ein Config-File (M7COM.CFG oder MAUSNET.CFG) einstellbar ist. Programmtechnisch gesehen sind solche "var"s eigentlich vom Benutzer zur Laufzeit definierte Konstanten. In diesem Fall vom Typ BOOLEAN, d. h. diese ConfigVar kann nur TRUE oder FALSE annehmen, also "ja" oder "nein". "CheckFreeList" - kannst Du Dir jetzt selbst
zusammenbasteln. "Überprüfe das Freigeben der Liste"
(oder eben nicht) - darum geht's. Was für eine Liste gemeint ist,
geht aus obiger Zeile nicht hervor - da nützen auch viele Jahre
Sysop-Dasein nichts!
_______ _/_ ( / rank Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Bei TRUE wird vor jeder Zeichenausgabe auf den horizontalen Strahlrücklauf gewartet. Damit wird das Flimmern auf CGAs verhindert, aber auch die Ausgabe langsamer. Einzutragen in m7com.cfg |
Default: | FALSE Einzutragen in m7com.cfg |
Default: | FALSE Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Bei TRUE wird vor jedem Start eines externen Programms (Packer, Protokoll, CallChk etc.) der Cache geflushed. Dazu wird die DOS-Funktion "Commit File" (Int 21h, Funktion 68h) benutzt, auf die mindestens SmartDrive reagiert. Einzutragen in m7com.cfg |
Default: | '2' Einzutragen in m7com.cfg |
Default: | Enviroment-Variable SHELL aus der CONFIG.SYS Einzutragen in m7com.cfg |
Default: | m7com.cfg im MausPath |
Bedeutung: | In ConfigFiles können per "ConfigInclude := 'filename'" jetzt weitere cfg-Files eingelesen werden. ConfigInclude darf mehrfach in einem Cfg-File vorkommen, und wird auch in den eingelesenen Files ausgewertet. Die Verschachtelungstiefe ist egal, nur die Gesamtanzahl aller Includes ist limitiert (derzeit auf 30). Im .REQ werden alle Includes angegeben. NB: Bei mehrfach definierten Variablen zählt die zuletzt gelesene Definition! Rekursionen sind auch möglich. Nested includ essind nicht möglich. Einzutragen in m7com.cfg |
Default: | TRUE |
Bedeutung: | Wenn TRUE, wird ein File m7com.req angelegt, in der alle
Variablen und die aktuellen Werte angelegt. Nach Möglichkeit
landen dort auch die Fehlermeldungen. Außerdem wartet die Maus 3
Sekunden, bevor es weiter geht. Damit hat man etwas Zeit, die
Fehlermeldung zu lesen.
Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Beim anlegen eines *.REQ Files (siehe ConfigRequestFile werden auch allen Variablen eingetragen, die M7COM.EXE oder alle anderen Maus-Utilitys, die auf m7com.cfg zugreifen, nicht anfordert. Damit kann man also feststellen welche Variablen überflüssig sind. Aber ACHTUNG nicht nur die Maus sondern mindestens auch der Mausputz greifen auf das cfg-File zu. Einzutragen in m7com.cfg |
Default: | unterschiedlich |
Bedeutung: | Baudrate zu den String. Nach dem Wert wird die Zeit für Downloads, tausch usw. berechnet. Bei Connects mit Fehlercompression sollte die Werte Connect-Baudraten ca. 10% mehr angeben. Wenn man es genau machen will:
Einzutragen in m7com.cfg |
Default: | 0 |
Bedeutung: | Zu jedem ConnectStringX kann per ConnectEventX ein Event konfiguriert werden. 0 bedeutet, daß kein Event ausgelöst wird. Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Bei TRUE wird die Portnummer an den ConnectString angehängt, damit man im MCALL.LOG sofort sehen kann, auf welchem Modem ein Anruf 'reinkam. Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Bei TRUE wird die (eh redundante) Angabe "ARQ" aus Connect-Meldungen entfernt, um mehr Platz für den Usernamen zu lassen. Einzutragen in m7com.cfg |
Default: | 'CONNECT' |
Bedeutung: | String, den das Modem beim Connect meldet
Einzutragen in m7com.cfg |
Default: | '' | ||||||||||
Bedeutung: | ConsoleKey.F[5678] Was in diesen Variablen konfiguriert wird, lässt sich bei einem Tastaturanruf in der MAUS per Alt-F5 bis Alt-F8 wieder abrufen. Control-Zeichen können als ^X dargestellt werden. Ein ^ wird durch ^^ erzeugt. Sehr praktisch ist, das #222 ALT-222 emuliert. Einige Beispiele:
Siehe auch das Kapitel zum Konsolenlogin Einzutragen in m7com.cfg |
Default: | TRUE |
Bedeutung: | Bei FALSE wird vor dem AT kein CR gesendet Einzutragen in m7com.cfg |
Default: | 'SysOp' |
Bedeutung: | Wird als Defaultwert für den Eintrag von SysOpName im EXTERN.CFG benutzt. Einzutragen in m7com.cfg |
Default: | '300' |
Bedeutung: | So viele Millisekunden wartet die MAUS zwischen "Protokoll startet" und dem eigentlichen Start. Wenn man nicht einen guten Grund hat, sollte dort nix anderes als der Default oder sogar '1' stehen. Bei kleinen werten kann es aber vorkommen, das die User bei Beginn jeder Übertragung CRC-Fehler bekommen, weil das Protokoll zu schnell startet. Zumindest haben wir das in der B festgestellt. Einzutragen in m7com.cfg |
Default: | '19200' |
Bedeutung: | Auf dieser Baudrate wird der Direktport fest betrieben. Siehe auch Direktlogin-Anleitung. Besser die Werte über X00 in der CONFIG.SYS festlegen. Siehe auch MaxBaud Einzutragen in m7com.cfg |
Default: | '753' |
Bedeutung: | Anchatten eines Users jetzt auch über den DirectPort möglich. Wenn der String aus DirectChat empfangen wird, wird der User wie sonst auch gefragt, ob er den Chat annehmen will. Das Ergebnis wird am DirectPort ausgegeben. Einzutragen in m7com.cfg |
Default: | TRUE |
Bedeutung: | Bei FALSE beachtet die MAUS jetzt auch am DirectPort das DCD-Signal und "legt auf" wenn das nicht vorhanden ist. Einzutragen in m7com.cfg |
Default: | '' |
Bedeutung: | Wenn dieses Zeichen von Direktport von der Maus empfangen wird, sendet die Maus eine Kopie des Mausbildschirms über den Direktport. Damit läßt sich der Mausbildschirm remote überwachen. Siehe auch Direktlogin-Anleitung Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Siehe Direktlogin-Anleitung. Wenn DirectLogin FALSE ist, fehlen auch alle anderen DirectLogin-Variablen im m7com.req. Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Bei TRUE wird beim Kommandozeilentausch das Infile nicht mehr erst nach BatchWorkPath kopiert und ausgepackt, sondern direkt geöffnet und gelesen. Das tut's also nur mit Textfiles und nur beim Tausch mit m7com /t! Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | DirectPortModemSimulator (Boolean, default FALSE). Bei TRUE versucht die MAUS auf dem DirectPort ein Modem zu simulieren:
MAUS PC/ST Kürzel Beschreibung 2 ---\/--- 2 TxD Transmit Data 3 ---/\--- 3 RxD Receive Data 4 ---\/--- 4 RTS Ready to Send 5 ---/\--- 5 CTS Clear to Send 7 -------- 7 GND Signal Ground /- 6 ---\ 6 --\ DSR Data Set Ready \- 8 /-\--- 8 | CD Carrier Detect 20 -/ \- 20 --/ DTR Data Terminal Ready (Ein kleiner Nachteil dabei ist, daß sich die MAUS dabei dann nicht mehr merkt, daß ein DirectRing da war. Siehe auch Direktlogin-Anleitung Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Bei TRUE wird auch für den DirectPort RTS/CTS-Handshake eingeschaltet. Dies ist ein Versuchsballon: bisher war das immer ausgeschaltet, aber evtl. erklärt das die Aussetzer am DirectPort, die u.a. in SU gehäuft auftraten. Einzutragen in m7com.cfg |
Default: | weiß ich nicht, hab keinen Direktport hier |
Bedeutung: | Normale und CallCheck-Events werden jetzt auch auf dem DirectPort protokolliert, die Variable auf TRUE steht. Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Bei TRUE wird immer dann, wenn die MAUS testet, ob das Modem noch da ist, der DirectPort neu initialisiert. Das ist zwar brutal, aber die Probleme bei der MAUS SU sind damit gelöst. Einzutragen in m7com.cfg |
Default: | '222' |
Bedeutung: | Zeichenfolge zum einloggen über den Direktport Siehe auch Direktlogin-Anleitung Einzutragen in m7com.cfg |
Default: | weiß ich nicht, hab keinen Direktport hier |
Bedeutung: | Bei TRUE wird beim Einloggen eines Users dessen Namen (bzw. "Gast") auf den DirectPort ausgegeben, beim Anrufende werden der Ende-Status (le, cl1 etc.) und die Anrufdauer ausgegeben. Einzutragen in m7com.cfg |
Default: | 'howl8' |
Bedeutung: | Wenn über den DirectPort der String aus DirectTime empfangen wird, sendet die MAUS die aktuelle Uhrzeit. Einzutragen in m7com.cfg |
Default: | '3' |
Bedeutung: | Gibt an, wie lange (in Sekunden) die MAUS beim Auflegen warten
soll, bevor sie DTR runterzieht. Wirkt nur, wenn UseDtrH=TRUE ist.
Siehe auch die Frage zur Gebührenanzeige der Maus und zum ausloggverhalten der Maus.
Einzutragen in m7com.cfg |
Default: | 'D' |
Bedeutung: | Damit kann angegeben werden, ob Uploads zunächst für weitere Downloads gesperrt werden sollen. Bei einer Sperre muss erst der SysOp oder PT-Wart den Download solcher Files freischalten (das geht über Begleitinformationen ändern). Die möglichen Werte für diese Variable sind
James unterstützt diese Feature im Moment nur in der Betaversion. Einzutragen in m7com.cfg |
Default: | GruppenProgPath\DOS\' |
Bedeutung: | Pfad für Programme des DOS-Betriebssystems Einzutragen in m7com.cfg |
Default: | '' Einzutragen in m7com.cfg |
Default: | '300' |
Bedeutung: | Bestimmt wie lange DTR runtergezogen wird. Angabe in ms. Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Soll das File 'Core.Dmp' (im MausPath) erzeugt werden? Keine Ahnung, was das ist. Einzutragen in m7com.cfg |
Default: | '2000' |
Bedeutung: | Soviele Mails durchsucht die Maus nach Dupes beim Gatetausch. Einzutragen in m7com.cfg |
Default: | '500' |
Bedeutung: | Soviele Mails durchsucht die Maus beim Dupecheck Einzutragen in m7com.cfg |
Default: | '' |
Bedeutung: | Quoting Editor für den Tastatur-Sysop: Im Dialog (Q) wie Quote übernimmt die kommentierte Msg gequotet in ein File QUOTE.TMP und ruft den konfigurierten Editor auf. Wenn das File im Editor geändert und gesichert wird, wird die Msg als Kommentar eingetragen, wenn nicht, wird sie gelöscht. Beispiel 'Q' [z.B. für Q.EXE] Einzutragen in m7com.cfg |
Default: | TRUE |
Bedeutung: | Löscht einen User 42 Sekunden nach seinem ersten Anruf, wenn er das falsche Geburtsdatum eingegeben hat. Einzutragen in m7com.cfg :-) (c) by Jödel |
Default: | TRUE |
Bedeutung: | Bei FALSE werden die Zeiten für den Event XX nicht beachtet, d.h. also der Event abgeschaltet. Nützlich, wenn man einfach einen Event mal eben disablen will. Einzutragen in m7com.cfg |
Default: | '' |
Bedeutung: | EventXXBisZeit - spätestmögliche Zeit für Event XX Siehe EventXXVonZeit Einzutragen in m7com.cfg |
Default: | '0' |
Bedeutung: | Damit kann zu Events jetzt eine geschätzte Dauer angegeben werden, die in der Tabelle der Events auch mit ausgegeben wird. Einzutragen in m7com.cfg |
Default: | '' |
Bedeutung: | Text-Beschreibung der Events, Einzutragen in m7com.cfg |
Default: | '0' |
Bedeutung: | Für Events sind jetzt je bis zu 8 Zeiten erlaubt. Dazu muss EventXXMultiplex auf die Zahl der vereinbarten Zeiten gesetzt werden. Statt in den sonst benutzen Variablen werden dann EventXX[von|bis|wurf]Zeit.Y verwendet, wobei das Y von 1 bis EventXXMultiplex hochgezählt wird. Einzutragen in m7com.cfg |
Default: | '' |
Bedeutung: | EventXXVonZeit - frühestmögliche Zeit für Event XX |
EventXXBisZeit - spätestmögliche Zeit für Event XX | |
EventXXWurfZeit - um diese Zeit wird ein Benutzer gewaltsam hinausgeworfen, um den Event noch zu ermöglichen. Kann entfallen, dann kann der Event nicht mehr garantiert werden. Das hilft natürlich nur, wenn zu diesem Zeitpunkt die Maus läuft und die Uhr stimmt! Es muß stets gelten: VonZeit <= WurfZeit <= BisZeit Einzutragen in m7com.cfg |
Default: | '' |
Bedeutung: | Zeit, zu der ein User gewaltsam hinausgeworfen wird. Siehe EventXXVonZeit Einzutragen in m7com.cfg |
Default: | TRUE |
Bedeutung: | Aktiviert den ExternMenü-Eintrag in Hauptmenü. Sinnvollerweise definiert man dann auch externe Programme Einzutragen in m7com.cfg |
Default: | '1' | ||||||||
Bedeutung: | Bestimmt ab welchen Userlevel ExternX.Name erscheint.
Ein SysOp der keinen Dollar hat, bekommt bei der Einstellung 2 den Menüpunkt nicht angezeigt. Für die Maus hat ein SysOp nicht automatisch einen Dollar! Siehe auch SysOpPayWarn Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | TRUE zeigt an, daß für dieses externe Programm der DoorWay-Modus benutzt wird, die MAUS gibt dann vor dem Start noch einen entsprechende Meldung aus. Einzutragen in m7com.cfg |
Default: | '0' |
Bedeutung: | Im E(X)tern-Menü kann eine neue Sorte von Programmen definiert werden: wenn zu einem Menüpunkt X die Cfg-Variable ExternMenuX.Event mit einem Wert verschieden von 0 definiert wird, wird zur Ausführung des Programms die MAUS beendet. Im MAUS.BAT kann das wie bei einem Event erkannt werden, als Return-code wird nämlich der Wert von ExternMenuX.Event zurückgeliefert. Eine Rückkehr zur MAUS ist im gleichen Anruf nicht möglich, darauf wird der User hingewiesen und es kommt auch noch eine Sicherheitsabfrage. Mögliche Einsatzbereiche dafür sind Programme, die extrem viel Memory benötigen, oder aber die Möglichkeit, echte Events auszulösen, ohne dafür die SysOp-Formel kennnen zu müssen (Status 'S' reicht, um Zugang zu Punkten mit ExternMenuX.Acc:=3 zu bekommen). Die Nummern für die Events müssen im Bereich [50..79] liegen. Einzutragen in m7com.cfg |
Default: | '' |
Bedeutung: | Das ist der Name, der im Externen-Menü erscheint. In
Klammern wird der Buchstabe zum anwählen des Externen Programmes
angegeben. Beispiel:
und das EXTERN.BAT sieht dann so aus (normales DOS): if "%1"=="M" goto service
Einzutragen in m7com.cfg |
Default: | TRUE |
Bedeutung: | Kommunikation Rechner-Modem immer mit MaxBaud Einzutragen in m7com.cfg |
Default: | 'A:\' |
Bedeutung: | Einstellung für alle Up/Downloads direkt von der Tastatur. Kann man natürlich während des einspielens ändern. Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Bei TRUE wird das MCALL.LOG nach jeder Zeile geflushed. damit da bei Crashes auch was zu lesen steht. Das hab ich damals bei der Sache mit Marcus' Keksstrahlen eingebaut :-) Einzutragen in m7com.cfg |
Default: | '' |
Bedeutung: | Name des Programms, mit dem die Zugangsberechtigung zum SysOp-Teil getestet wird. Ein Beispiel mit der alten Formel liegt als SYSFORM.PAS/.EXE bei. Wenn FormelProgramm leer (' ') ist, wird weiterhin die alte eingebaute Formel verwendet. Man kann auch anstatt eines externen Programmes einen 4DOS-Batch ausführen lassen. Hier ein Beispiel von Timm Ganske: [m7com.cfg] FormelProgramm := 'SFORMEL.BTM'; [' '] [Ausschnitt m7com.cfg Ende] [sformel.btm] if %@eval[ %1 \ 100 + %1 %%100 ] == %2 quit 0 quit 1 [sformel.btm ende!] Diese Beispielformel sollte dafür sorgen, daß man bei der Zahl abcde folgendes rechnen muß: abc+de. Ich habe sie jetzt nicht getestet, aber 4DOS bietet alle Möglichkeiten, beliebige Formeln aufzustellen. Einfach mal die Hilfe zu %@EVAL anschauen. Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Bei TRUE wird der Punkt (K) im Hauptmenü nicht mehr angezeigt. Einzutragen in m7com.cfg |
Default: | '40' |
Bedeutung: | Nach wievielen Anrufen gilt ein Anrufer als Geizhals. Einzutragen in m7com.cfg |
Default: | '0' |
Bedeutung: | Werte >0 legen fest, daß jemand erst nach der angegebenen Anzahl von Tagen zum Geizhals werden kann, egal wie GeizhalsNach gesetzt ist. Einzutragen in m7com.cfg |
Default: | '0' |
Bedeutung: | Ein Wert >0 gibt an, wie groß (in Kilobytes gemessen) das OUTFILE.TXT eines Geizhalses sein darf Einzutragen in m7com.cfg |
Default: | TRUE |
Bedeutung: | Bei FALSE wird der MausTausch für Geizhälse gesperrt. Gilt nicht für Sysops Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Bei TRUE Anruf über S0=1/DTR^ annehmen anstatt über ATA Einzutragen in m7com.cfg |
Default: | TRUE |
Bedeutung: | Bei FALSE ist die Mitgliederliste einer Gruppe nur noch für die Mitglieder der Gruppe, den Chef und die SysOps abrufbar. Einzutragen in m7com.cfg |
Default: | MausPath\GRUPROG\' |
Bedeutung: | Pfad für die Gruppenprogrammteile Einzutragen in m7com.cfg |
Default: | TRUE |
Bedeutung: | Hiermit kann der Cache der Infofile (File MausPath\M7INFO.CRC), des es ab Maus 7.95j gibt, abgeschaltet werden. Ist aber nur nötig, wenn man z.B. im CallCheck.Bat irgendwelche Infofiles ändert. Einzutragen in m7com.cfg |
Default: | |
Bedeutung: | Hier liegen die Infotexte der Maus. Also eigentlich alles was mit *.Inf im Mausverzeichnis rumliegt. Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Bei TRUE wird schon beim Start der MAUS der Spannermodus aktiviert. Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Siehe ISDNCallRejectEAZs Einzutragen in m7com.cfg |
Default: | '' |
Bedeutung: | Die MAUS (und das MausNet ab v2.53) kann jetzt aktive Rufablehnung im ISDN. Dazu muss die Variable ISDNCallReject auf "TRUE" gesetzt werden, außerdem muß man in "ISDNCallRejectEAZs" angeben, auf welche(n) EAZ(s) Anrufe abgelehnt werden sollen. Dabei wird einfach eine Aufzählung der EAZs als String, ohne irgendwelche Trennzeichen erwartet. Damit das funktioniert, ist die Installation des Programms Rejectit von Marcus Schmidke @ BM erforderlich, das liegt u.a. im GPT SYSOP.PROG @ K2. Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Bei TRUE werden die Up-und Downloads nicht mit mit Recs (128 Byte) sondern mit KB protokolliert. Einzutragen in m7com.cfg |
Default: | '' |
Bedeutung: | Mit den Config-Variablen LocalInfoX.Desc und LocalInfoX.File (mit
X in A..U) kann man lokale Infofiles festlegen. Online werden die im
(I)nfomenü unter L(O)kales angeboten, per Tausch als Infofiles
ILOKx.
Einzutragen in m7com.cfg |
Default: | '' |
Bedeutung: | Lokales Infofile. Siehe LocalInfoX.Desc Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Wenn LogChat auf TRUE gesetzt ist und der eingebaute Chatter benutzt wird, wird beim Chatten ein Protokoll in der Datei CHAT.LOG (im MAUS-Directory) geführt. Diese Datei wird beim Beginn jedes Chats neu angelegt. Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Bei TRUE werden im der Logfile-Statistik im MausMeter die ISDN-Anrufer (CONNECT 64000) einzeln ausgewiesen, dafür die 300er, 1200er und 2400er zu einer Spalte "<=2400" zusammengefasst. Einzutragen in m7com.cfg |
Default: | '3' |
Bedeutung: | Das sagt aus, wieviel von den Programmteil-Aktivitäten im MCALL.LOG landen. Also sowas wie Beschreibung ändern, löschen etc. Je höher der Level, desto mehr landet im MCALL.LOG. 15 ist dabei das Maximum. Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Bei TRUE werden die Response-Ignore-Strings protokolliert, ebenso nach einem RING alles, was nicht als CONNECT erkannt wurde. Wenn Response_RING auf '*' endet und das Modem nach dem RING noch mehr Daten schickt, dann werden diese im MCALL protokolliert, wenn LogIgnored=TRUE ist. Einzutragen in m7com.cfg |
Default: | '' X von A bis Z möglich |
Bedeutung: | Hinweis zur Loginzeit Einzutragen in m7com.cfg |
Default: | 'G' X von A bis Z möglich |
Bedeutung: | Ab welchen User-Level ist der Programmteil zu der LogInZeit erlaubt. Einzutragen in m7com.cfg |
Default: | '' X von A bis Z möglich |
Bedeutung: | Man kann pro Stunde und getrennt für Gäste, User,
Beitragszahler und "Geizhälse" die Online-Zeiten
einstellen. Die Parameter für Beitragszahler und Geizhälse
sind optional.
Ein Beispiel: LogInZeitA := '00: 00, 20, 30, 10' LogInZeitB := '02: 60, 60' Erste Zeile: Zwischen 00:00 und 01:59 haben User 20 Minuten und Beitrags- Zahler 30 Minuten Online-Zeit. Gäste sind gesperrt und Geizhälse haben nur 10 Minuten. Nach 2 Uhr haben alle Anrufer 60 Minuten. Programmteilsperre für bestimmte Loginzeiten über LogInProg Mögliche Eingaben G-ast, N-euling,U-ser,Z-ahler,S-ysop LogIn-Zeiten (wie sie bei einer neuen MAUS benutzt werden sollten) User 1/2 von Zahler und Geizhälse 10 Minuten weniger als User in SL ab User Geizhals Gast Zahler LogInZeitA := '00: 5, 8, 16, 05' LogInProgA := ; ('') LogInHinweisA := ; ('') Einzutragen in m7com.cfg |
Default: | |
Bedeutung: | Pfad für das MCALL.LOG und die der letzten 14 Tagen. Bei ModemLog TRUE wird dort auch das MODEM.LOG abgelegt. der PM-Forwarder FwdPM legt dort auch seine Log-Files ab. Einzutragen in m7com.cfg |
Default: | '0' |
Bedeutung: | Bei Werten > 0 wird zwischen Anrufen überpüft, ob noch soviel Memory frei ist wie angegeben. Wenn das nicht der Fall ist, wird der Event aus LowMemoryEvent (word, default 203) ausgelöst. Damit kann man sich gegen die Speicherlecks schützen, die entstehen können, wenn ein User mitten in einer Routine auflegt, die Speicher alloziert hat und nicht mehr freigeben kann. Wenn man den Event umdefiniert, kann man auch einen automatischen Wechsel von RealMode- zur DPMI-Version implementieren. Einzutragen in m7com.cfg |
Default: | GruppenProgPath\MACINTOS\' |
Bedeutung: | Pfad für Programme des MACINTOS-Betriebssystems Einzutragen in m7com.cfg |
Default: | '' |
Bedeutung: | Mit dem Text werden die User beim einloggen begrüßt. Einzutragen in m7com.cfg |
Default: | 'G' |
Bedeutung: | Ab dieser Userklasse ist der Mausmeter-Zugang erlaubt Einzutragen in m7com.cfg |
Default: | MausPath\net |
Bedeutung: | Pfad für MNconfig, MausNet Einzutragen in m7com.cfg |
Default: | '\MAUS\' |
Bedeutung: | Hier wird der Pfad für die Maus festgelegt. Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Experimentelles Flag ab Maus 7.95j
Einzutragen in m7com.cfg |
Default: | '19200' |
Bedeutung: | Die Maximale bps-Rate. Damit sagt die MAUS (per EXTERN.CFG) wie schnell die Leitung zum Modem ist. Ab der Maus 7.95g muß die Schnittstellengeschwindigkeit mit X00 und XU in der CONFIG.SYS und AUTOEXEC.BAT Sollte man besser über den *X00* einstellen, dann kann hier ruhig der Defaultwert stehen. ACHTUNG. Ab der Maus 7.95g verändert die Maus keine Schnittstellenwerte. deshalb die Schnittstellengeschwindigkeit mit X00 einstellen und mit XU unveränderlich einstellen. Beispiel: CONFIG.SYS DEVICE=C:\UTIL\X00.SYS E 0=COM1 B,0,115200 T=2048 R=2048 FIFO=15 AUTOEXEC.BAT xu set:0:115200:8N1 lock:0:115200:8N1 Einzutragen in m7com.cfg |
Default: | '60' |
Bedeutung: | Wie lange (in s) soll auf eine CONNECT Meldung gewartet werden Einzutragen in m7com.cfg |
Default: | '5' |
Bedeutung: | Gibt die Zeit in Minuten an, ab der eine harte Onlinzeitüberschreitung gegeben ist. Einzutragen in m7com.cfg |
Default: | '0' |
Bedeutung: | Insgesamt sind nur maximal soviele Relogins möglich, wie hier angegeben ist. Der Wert 0 bedeutet, daß es kein Limit gibt. Die frühere Beschränkung, daß sich jemand nicht unter seinem Namen noch einmal und ein Gast auch nicht wieder als Gast einloggen konnte sind hiermit weggefallen. Einzutragen in m7com.cfg |
Default: | TRUE |
Bedeutung: | Schaltet die '-' in den Menüs an. Einzutragen in m7com.cfg |
Default: | '120' |
Bedeutung: | Das ist die Rücksicherung, der Cache wird nie so groß, daß nicht mindestens dieser Wert an KB freigehalten wird. Siehe ParCacheSize Einzutragen in m7com.cfg |
Default: | |
Bedeutung: | Pfad für die öffentliche Messagebase. Einzutragen in m7com.cfg |
Default: | |
Bedeutung: | Pfad für die persönliche Messagebase. Siehe auch MittAllgPath Einzutragen in m7com.cfg |
Default: | 'M0 H1' |
Bedeutung: | Das wird bei einem RING auf einem Port an alle anderen Port auf denen kein RING kam geschickt, damit Anrufer dort ein Besetzzeichen hören. Maximale Länge 20 Zeichen Auch beim verlassen der Maus mit ALT-234 oder anderen legalen verlassen, wird das an alle Ports geschickt, damit die User ein Besetzzeichen hören. Einzutragen in m7com.cfg |
Default: | 'A' |
Bedeutung: | Das schickt die Maus ans Modem, wenn ein Anruf angenommen werden soll und eine Verbindung aufgebaut werden soll. Maximale Länge 20 Zeichen Einzutragen in m7com.cfg |
Default: | 'M1 H' |
Bedeutung: | String, den die Maus beim Auflegen ans Modem schickt. Maximale Länge 20 Zeichen Einzutragen in m7com.cfg |
Default: | 'B' |
Bedeutung: | Das wird, wenn ModemCheckInterval gesetzt ist, an das Modem geschickt. Maximale Länge 20 Zeichen Man sollte unbedingt testen, ob der Defaultwert, also 'atb' auch funktioniert. Wenn nicht entsprechend ändern, z.B. in 'B0' Einzutragen in m7com.cfg |
Default: | 'S2?' Einzutragen in m7com.cfg |
Default: | '120' |
Bedeutung: | Damit wird das Zeitintervall in Sekunden festgelegt, in dem die MAUS zwischen zwei Anrufen checkt, ob das Modem noch ansprechbar ist. Außerdem wird bei diesem Check der DirectPort neu initialisiert, falls DirectPortWakeup = TRUE ist. Siehe auch CheckBetweenCalls Maximale Länge 20 Zeichen Einzutragen in m7com.cfg |
Default: | '#0#0#0' |
Bedeutung: | Wie soll das Modem in den Commandmodus gehen. Achtung +++ ist ein gefährlicher String, denn den könnte man in einer Nachricht, die man ONLINE schreibt senden. Maximale Länge 20 Zeichen Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Sollte auf TRUE stehen, wenn ein Modem da ist:-) Bei FALSE werden keinerlei Befehle an ein nicht vorhandenes Modem geschickt. Sinnvoll für Test-Mäuse. Einzutragen in m7com.cfg |
Default: | 'O' |
Bedeutung: | Mit diesem Kommando geht das Modem wieder in den Datamode. Einzutragen in m7com.cfg |
Default: | '' |
Bedeutung: | Das bekommt das Modem, beim beenden der Maus geschickt. Darf maximal 80 Zeichen lang sein. Einzutragen in m7com.cfg |
Default: | '' |
Bedeutung: | Init-String für das Modem. Darf maximal 80 Zeichen lang. Wird beim start der Maus an das Modem geschickt. Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Bei TRUE wird in LogPath\MODEM.LOG ein Protokoll der Kommunikation zwischen MAUS und Modem angelegt. Einzutragen in m7com.cfg |
Default: | 'S0=0' |
Bedeutung: | Das Kommando damit das Modem nicht beim x. Klingeln abhebt, sondern auf das RING wartet. Maximale Länge 20 Zeichen Einzutragen in m7com.cfg |
Default: | '0' |
Bedeutung: | Port an dem das Modem hängt Einzutragen in m7com.cfg |
Default: | '1' |
Bedeutung: | Legt die Anzahl der Modemport fest. Zum umstellen siehe auch das entsprechende Kapitel Die Modem-Antworten sind jetzt auch pro Modem konfigurierbar. Die bisherigen Variablen Response_XX gibt's immer noch und dienen als Default für die neuen Variablen ModemY.Response_XX. Alle Modem-Variablen gibt es demnach bei zwei-Port-Mäusen mit Modem1.xxx und Modem2.xxx. Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Experimentell! Dies ist ein Versuch, wie die MAUS diese lästigen Runtime-Errors 80 und 81 von selber in den Griff kriegen könnte. Bei TRUE wird ähnlich wie bei DirectPortWakeup versucht, bei Problemen den X00-Port neu zu initialisieren. Solche WakeUp-Versuche werden im MCALL.LOG als WakeUp(x) protokolliert, wobei x angibt, welcher Modem-Error sonst passiert wäre (80 oder 81). Einzutragen in m7com.cfg |
Default: | 'Z' |
Bedeutung: | Wird beim Start der Maus ans Modem geschickt. Maximale Länge 20 Zeichen Einzutragen in m7com.cfg |
Default: | '' |
Bedeutung: | Befehl um eventuell Statusmeldungen nach dem auflegen ins
ModemLogFile zu schreiben. Interessant für die Fehlersuche.
Maximale Länge 20 Zeichen Einzutragen in m7com.cfg |
Default: | 'S2=0' |
Bedeutung: | Wert des Escape-Zeichen für das MausModem festlegen. Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | sicher irgendwas für Debug-Zwecke Einzutragen in m7com.cfg |
Default: | TRUE |
Bedeutung: | TRUE deaktiviert den Fossilport vor dem Protokoll Einzutragen in m7com.cfg |
Default: | TRUE |
Bedeutung: | Bei FALSE versucht die MAUS nicht mehr, die Ausgabe externer Programme auf den betreffenden Modemport umzulenken. Das ist fÜr den Betrieb mit cFOS unter OS/2 leider nötig und hat zur Folge, daß z.B. keine Packerausgaben beim Tausch mehr sichtbar sind und insbesondere, daß es keine DOS-Shell im SysOp-Teil mehr gibt. Einzutragen in m7com.cfg |
Default: | TRUE |
Bedeutung: | TRUE reaktiviert den Fossilport nach dem Protokoll wieder Einzutragen in m7com.cfg |
Default: | '0' |
Bedeutung: | Damit kann eingestellt werden, beim wievielten Klingeln die MAUS abheben soll. Einzutragen in m7com.cfg |
Default: | 0 |
Bedeutung: | Damit wird der X00-Port festgelegt, an dem das Modem X hängt. X ist dann die Modemnummer unter der das Modem z.B. per ModemX.Init angesprochen werden kann. Siehe auch Mehrere Modems an der Maus Einzutragen in m7com.cfg |
Default: | 1 |
Bedeutung: | Der Com-Port, an dem das Modem X hängt. Siehe ModemX.X00Port und Mehrere Modems an der Maus Einzutragen in m7com.cfg |
Default: | '0' |
Bedeutung: | Siehe MsgIdxReserveAllg Einzutragen in m7com.cfg |
Default: | '0' |
Bedeutung: | Siehe MsgIdxReserveAllg Einzutragen in m7com.cfg |
Default: | '0' |
Bedeutung: | Siehe MsgIdxReserveAllg Einzutragen in m7com.cfg |
Default: | '5000' |
Bedeutung: | MsgIndexMax setzt eine absolute Grenze, MsgIdxReserveAllg oder MsgIdxReservePers eine dynamische (eben aktuelle MsgBase + Reserve). Damit ist MsgIndexMax fast überflüssig und sollte immer auf dem Default (0) belassen werden. Tunen kann man dann mit MsgIdxReserve, indem man das so hoch setzt, daß ein Schub Mail im Netz oder Tausch bequem in diese Reserve passen. Siehe auch das entsprechenden Kapitel Einzutragen in m7com.cfg |
Default: | '1000' |
Bedeutung: | Siehe MsgIdxReserveAllg Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Damit kann der MausTausch den Nichtzahlern gesperrt werden Einzutragen in m7com.cfg |
Default: | '0' |
Bedeutung: | Soviel Tage lang gilt ein User als Neuling. Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Bei TRUE wird Neulingen (also Usern, die vor weniger als NeulingFrist Tage zum ersten Mal angerufen haben) das Schreiben von Gruppen-Mitteilungen verboten. Zahler sind keine Neulinge. Einzutragen in m7com.cfg |
Default: | 5 Minuten |
Bedeutung: | Zeit die ein User beim Relogin mindestens bekommt. Normalerweise ist es die Zeit die ein normaler User zu dieser Zeit bekommt. Hiermit kann die Zeit auch anders verändert werden. Einzutragen in m7com.cfg |
Default: | 'MausNetPath\IO\' |
Bedeutung: | Path für die empfangenen/zu sendenden Netzpakete. Einzutragen in m7com.cfg |
Default: | |
Bedeutung: | Wenn man auf der Msg-Partition nicht genügend Platz zum Krunchen hat, kann man hier in diesen Path die neuen, gekrunchten Dateien angelegt. Nach dem erfolgreichen krunchen werden die beiden Dateien dann nach MittAllgPath umkopiert und gelöscht. Einzutragen in m7com.cfg |
Default: | TRUE |
Bedeutung: | Bei FALSE kann sich kein User neu eintragen. Interessant für Doppelmäuse, bei denen eine eine Maus nur für Zahler ist. Einzutragen in m7com.cfg |
Default: | |
Bedeutung: | Wenn man auf der Msg-Partition nicht genügend Platz zum Krunchen der pers. Messagesbase ist, kann man hier in diesen Path die neuen, gekrunchten Dateien angelegt. Nach dem erfolgreichen krunchen werden die beiden Dateien dann nach MittAllgPath umkopiert und gelöscht. Einzutragen in m7com.cfg |
Default: | GruppenProgPath\OS_2\' |
Bedeutung: | Pfad für Programme des Betriebssystems Einzutragen in m7com.cfg |
Default: | '256' |
Bedeutung: | Soviele Par-Einträge werden maximal auf einmal gelesen. 511 ist der oberste Wert (64K) - ein Eintrag ist 128 Bytes groß. Der Programmteil behandelt das ziemlich selbständig, wenn der Speicher knapp wird, reserviert er automatisch weniger. Dazu gibt's folgendes: MinRamKBFrei Einzutragen in m7com.cfg |
Default: | 'CDEFGHIJKLMNOPQRSTUVWXYZ' |
Bedeutung: | Welche Partitions gibt es. Einzutragen in m7com.cfg |
Default: | 'MausPath\PERS\' |
Bedeutung: | Pfad für den persönlichen Programmteil Einzutragen in m7com.cfg |
Default: | unterschiedlich, X von 1 bis 20 möglich |
Bedeutung: | Extension des Packers Siehe auch PackerX.Select Einzutragen in m7com.cfg |
Default: | unterschiedlich, X von 1 bis 20 möglich |
Bedeutung: | Ab dem wievielten Zeichen soll nach dem PackerX.IDstring gesucht werden Siehe auch PackerX.Select Einzutragen in m7com.cfg |
Default: | unterschiedlich, X von 1 bis 20 möglich |
Bedeutung: | An welchem ID-String wird das entsprechende Archive erkannt. Siehe auch PackerX.Select Einzutragen in m7com.cfg |
Default: | unterschiedlich, X von 1 bis 20 möglich |
Bedeutung: | Der vollständige Packer-Name in der Auswahl. Siehe auch PackerX.Select Einzutragen in m7com.cfg |
Default: | unterschiedlich, X von 1 bis 20 möglich |
Bedeutung: | Packerrate Siehe auch PackerX.Select Einzutragen in m7com.cfg |
Default: | unterschiedlich, X von 1 bis 20 möglich!item [Bedeutung:] Buchstabe, mit dem der Benutzer den Packer auswählen kann. Muß damit auch im Packer.bat angesprungen werden. Allgemein gilt. Die Deafultwerte lassen sich wunderbar verwenden. Im einzelnen sind folgenden x-Werte vorbelegt:
Hier die Vorbelegung für den Packer 1
| ||||||||||||||||||
Packer1.Select := ; ['Z'] | |||||||||||||||||||
Packer1.Name := ; ['(Z)IP v1.1'] | |||||||||||||||||||
Packer1.Ext := ; ['.ZIP'] | |||||||||||||||||||
Packer1.IDoffset := ; [0] | |||||||||||||||||||
Packer1.IDstring := ; ['PK'#3#4#10] | |||||||||||||||||||
Packer1.PackRate := ; [ 6.0000000000E-01] | |||||||||||||||||||
Packer1.ShowOutput := ; [TRUE] Einzutragen in m7com.cfg |
Default: | unterschiedlich, X von 1 bis 20 möglich |
Bedeutung: | Hiermit läßt sich für jeden Packer einzeln einstellen, ob die Ausgaben zum User geleitet werden. Für ARJ unter OS/2 muss FALSE gesetzt werden. Siehe auch PackerX.Select Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Da gibt's dann eine erweiterte Ausgabe, was der Programmteil an Dateien so öffnet, ... (Nicht zu empfehlen :-) Einzutragen in m7com.cfg |
Default: | '500' |
Bedeutung: | Soviele Mails durchsucht der Dupecheck in der Maus bei persönlichen Mails. Defaultwert ist DupMaxDefaultUser bzw DupMaxDefaultGate Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Hier wurde auf ziemlich verworrene (:-) ) Weise der letzte Download beim Download pro Monat berücksichtigt. Es ist inzwischen dahingehend überarbeitet, daß pro Monat ohne Download der DPM-Wert um etwa 4% reduziert wird, nach 2 Jahren ohne DL ist der DPM-Wert also 0, unäbhängig von der Downloadzahl. Bei TRUE wird der DPM auch noch anhand des letzten Saugdatums berechnet. Je länger das entsprechende File nicht gesaugt wurde, desto mehr wird von dem rechnerischen DPM abgezogen. Wimni ist damit jedes File nach 24 Monaten Nichtsaugens beim DPM auf 0. Einzutragen in m7com.cfg |
Default: | '' |
Bedeutung: | Pfad für die Programmteilbeschreibungen Einzutragen in m7com.cfg |
Default: | TRUE |
Bedeutung: | Sollte bis Maus 7.95h nicht verändert werden. Macht nix brauchbares. [Ab MAUS 7.95i Programmteil V 35] KonfigVariable ProgTeil.an geht jetzt, mit FALSE läßt sich also der ganze Programmteil lahmlegen um z.B. mit dem MC zu importieren. Damit man den Programmteil über Netzwerk / von Programmen aus sperren kann wird ferner in MausPath die Datei 'PROGTEIL.AUS' abgefragt - existiert sie, ist der Programmteil ebenfalls gesperrt. Beim Userhinweis bei gesperrtem Programmteil wird zwischen temporär gesperrtem Programmteil: ('Der Programmteil ist momentan gesperrt - Sorry' und kaputtem Programmteil ('Der Programmteil ist zur Zeit aus technischen Gründen nicht zugänglich - Sorry') unterschieden. Einzutragen in m7com.cfg |
Default: | 'N' |
Bedeutung: | Bestimmt den Userlevel, ab dem in den öffentlichen Programmteil etwas abgelegt werden darf. Siehe auch Gästeupload im Programmteil? Einzutragen in m7com.cfg |
Default: | 'G' |
Bedeutung: | Ab diesen Userlevel dürfen Programm aus den öffentlichen Programmteile gesaugt werden. Siehe auch Gästeupload im Programmteil? Einzutragen in m7com.cfg |
Default: | 'N' |
Bedeutung: | Ab diesen Userlevel dürfen Programm in den persönlichen Programmteile abgelegt werden. Siehe auch Gästeupload im Programmteil? Einzutragen in m7com.cfg |
Default: | 'N' |
Bedeutung: | Bestimmt den Userlevel, ab dem aus persönlichen Programmteil gesaugt werden darf. Siehe auch Gästeupload im Programmteil? Einzutragen in m7com.cfg |
Default: | 'G' |
Bedeutung: | Bestimmt den Userlevel, ab dem überhaupt etwas aus den Programmteilen gesaugt werden kann. Siehe auch Gästeupload im Programmteil? Einzutragen in m7com.cfg |
Default: | 'N' |
Bedeutung: | Bestimmt den Userlevel, ab dem überhaupt etwas in den Programmteilen abgelegt werden kann. Siehe auch Gästeupload im Programmteil? Einzutragen in m7com.cfg |
Default: | '130' |
Bedeutung: | Siehe auch ProgTyp.Packer Diese beiden Variablen steuern, welche Programmtypen bei Protokoll.X.restricted noch downloadbar sind. Die Defaults stimmen für das 1710-MPROG.DAT. Wer noch eins der alten MPROG.DATs benutzt (Filegröße 1770 oder 2070), muß 20 (DFÜ) und 6 (Packer) eintragen. Einzutragen in m7com.cfg |
Default: | '120' |
Bedeutung: | Siehe auch ProgTyp.DFUE Diese beiden Variablen steuern, welche Programmtypen bei Protokoll.X.restricted noch downloadbar sind. Die Defaults stimmen für das 1710-MPROG.DAT. Wer noch eins der alten MPROG.DATs benutzt (Filegröße 1770 oder 2070), muß 20 (DFÜ) und 6 (Packer) eintragen. Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Bei TRUE darf ein Promi auch außerhalb der Sprechstunde chatten (wie ein SysOp). Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Wenn PromptsMitESC auf TRUE gesetzt wird, werden alle sog. "Selects" (Packer, Protokoll, Umlaute etc.) um den String "<ESC=Abbruch>" erweitert. Einzutragen in m7com.cfg |
Default: | unterschiedlich, X von 1 bis 10 möglich |
Bedeutung: | Man darf mit dem Protokoll X Downloaden. Siehe auch Protokoll.X.Name Einzutragen in m7com.cfg |
Default: | unterschiedlich, X von 1 bis 10 möglich |
Bedeutung: | Da nicht alle Protokolle (besser gesagt fast keine, insbesondere nicht DSZ, GSZ und MPt) ein Fossil benutzen können, das aber gerade für ISDN/cFOS natürlich lebensnotwendig ist, muß man jetzt die Protkolle für das zweite Modem explizit freischalten. Die geschieht einfach durch Setzen der Cfg-Var Protokoll.X.ModemOk auf einen String(!), der die Liste der fuer dieses Protokoll erlaubten Modems enthält. Per Default sind für alle Protokolle die Modems 0 (Direct/Tastatur) und 1 erlaubt, um ein Protokoll auf allen drei Modems zu erlauben, muss also Protokoll.X.ModemOk := '012' angegeben werden. Siehe auch Protokoll.X.Name Einzutragen in m7com.cfg |
Default: | unterschiedlich, X von 1 bis 10 möglich |
Bedeutung: | Multidownload mit dem Protokoll X erlaubt/funktioniert. Siehe auch Protokoll.X.Name Einzutragen in m7com.cfg |
Default: | unterschiedlich, X von 1 bis 10 möglich | ||||||||||||||
Bedeutung: | Wie heißt das Protokoll. Daraus werden die Selekts zusammengebastelt, außerdem steht das auch in den Benutzerdaten. Im einzelne sind wieder per default vorbelegt
Auch hier gilt. Die Default-Werte sind recht brauchbar. Wenn ein Protokoll nicht benutzt werden soll, einfach mit Protokoll.6.Name := '' abmelden. Jedes Protokoll kann natürlich auch anders definiert werden. Also 1 ist HS-Link, 2 Z-Modem usw. Wenn man sich Arbeit machen will, wieso nicht. Einzutragen in m7com.cfg |
Default: | unterschiedlich, X von 1 bis 10 möglich |
Bedeutung: | Wenn die mit NamenMitModem nacheinander definiert sind, wird es zusammengefasst. Sinnvoll für X, Y, Z-Modem. Sieht dann so aus: X, Y, Z-Modem Siehe auch Protokoll.X.Name Einzutragen in m7com.cfg |
Default: | unterschiedlich, X von 1 bis 10 möglich |
Bedeutung: | Das ist ein Gimmik: Danach geht, egal wie vorgegeben, kein Upload mehr, und der Download ist auf Rubrik Datenfernübertragung (inklusive aller Unterpunkte) beschränkt, entsprechendes wird auch ausgegeben. Man kann allerdings noch im persönlichen Programmteil downloden, und auf den Tausch hat es auch keinen Einfluß. Siehe auch Protokoll.X.Name Einzutragen in m7com.cfg |
Default: | unterschiedlich, X von 1 bis 10 möglich |
Bedeutung: | Tausch mit dem Protokoll X erlaubt. Siehe auch Protokoll.X.Name Einzutragen in m7com.cfg |
Default: | unterschiedlich, X von 1 bis 10 möglich |
Bedeutung: | Man darf mit dem Protokoll X Uploaden. Siehe auch Protokoll.X.Name Einzutragen in m7com.cfg |
Default: | unterschiedlich, X von 1 bis 10 möglich |
Bedeutung: | Das ist der Faktor, mit dem die Maximaldownloadzeit multipliziert wird. Hier nicht zu viel eintragen, da der Überzug anders geregelt ist. Die Default-Werte funktionieren. Siehe auch Protokoll.X.Name Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Bei TRUE bekommt ein Programmteilwart die gleiche Loginzeit wie ein SysOp. Siehe auch SysopLoginZeit Einzutragen in m7com.cfg |
Default: | 'BUSY*' |
Bedeutung: | Diesen String soll das Modem bei einem besetzt zurückmelden. Einzutragen in m7com.cfg |
Default: | 'ERROR*' |
Bedeutung: | Diesen String soll das Modem bei einem Fehler (z.B. falsches AT-Kommando zurückliefern. Einzutragen in m7com.cfg |
Default: | unterschiedlich, X von 1 bis 9 möglich | ||||||||||
Bedeutung: | Diesen String vom Modem kann die Maus ignorieren. Vorbelget sind folgende Werte:
Besonderheit bei 4:
Einzutragen in m7com.cfg |
Default: | 'NO ANSWER*' |
Bedeutung: | Diesen String soll das Modem zurückmelden, wenn kein Connect zustande kam. Einzutragen in m7com.cfg |
Default: | 'NO CARRIER*' |
Bedeutung: | Modem-Meldung fürs Auflegen Einzutragen in m7com.cfg |
Default: | 'NO DIALTONE*' |
Bedeutung: | Diesen String soll das Modem zurückmelden, wenn kein Freizeichen da ist. Einzutragen in m7com.cfg |
Default: | 'OK' |
Bedeutung: | Diesen String soll das Modem zurückmelden, wenn ein Kommando korrekt verstanden wurde. Einzutragen in m7com.cfg |
Default: | 'RING' |
Bedeutung: | Modem-Meldung wenn es bimmelt. Einzutragen in m7com.cfg |
Default: | '5' |
Bedeutung: | Config-Var für "TrailBlazer" wie lange (in ms) darf nach dem Anrufabnehmen (ATA/DTR) noch ein RING kommen Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Bei TRUE nimmt die Maus auf des erste RING hin ab, egal was da noch folgt (war früher für das Elsa-Modem notwendig). Nie bei anderen Modems auf TRUE setzen. Das bewirkt ein nicht abheben im MausNet und somit keine Verbindung im MausNet. Also am besten diese Variable überhaupt nicht ins MausNet.cfg oder m7com.cfg eintragen Einzutragen in m7com.cfg |
Default: | TRUE |
Bedeutung: | Damit läßt sich die automatische Sommerzeit-Umstellung abschalten Einzutragen in m7com.cfg |
Default: | GruppenProgPath\SONSTIGE\' |
Bedeutung: | Pfad für Programme die unter SONSTIGE einsortiert werden. Einzutragen in m7com.cfg |
Default: | TRUE |
Bedeutung: | Bei TRUE wird beim einloggen ein Spruch des Tages angezeigt. Einzutragen in m7com.cfg |
Default: | TRUE |
Bedeutung: | Bei FALSE wird in der Statuszeile nur noch die Uhr angezeigt. Das sollte unter OS/2 etwas CPU-Zeit sparen. Einzutragen in m7com.cfg |
Default: | GruppenProgPath\ST_TOS\' |
Bedeutung: | Pfad für Programme des ST-TOS-Betriebssystems Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Bei TRUE wird zum Zugang zum SysOp-Teil *IMMER* die Formel abgefragt, auch bei einem Tastaturanruf. Einzutragen in m7com.cfg |
Default: | '60' |
Bedeutung: | Loginzeit für Sysops. Die Loginzeit für Programmteilwarte wird über PTWhatSysOpZeit festgelegt. Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Bei TRUE wird von der MAUS beim Versand einer Zahlungserinnerung auch Nachricht darüber an den SysOp geschickt. Einzutragen in m7com.cfg |
Default: | '00:00-23:59' |
Bedeutung: | Außerhalb der definierten Zeit piepst die MAUS nicht bei Anrufen und erlaubt den Usern keinen Chat. Einzutragen in m7com.cfg |
Default: | TRUE |
Bedeutung: | Durch UhrAnzeigen := FALSE; wird jetzt wirklich nur die Uhrzeit-Anzeige in der Statuszeile abgeschaltet. Einzutragen in m7com.cfg |
Default: | GruppenProgPath\UNIX\' |
Bedeutung: | Pfad für Programme des UNIX-Betriebssystems Einzutragen in m7com.cfg |
Default: | '0' |
Bedeutung: | Wenn auf der entsprechenden Partition (x) nur noch soviel KB frei sind, wird jeglicher Upload verweigert. Beim Öffentlichen Programmteil bezieht sich das aufs erste angegebene Betriebssystem (deshalb erst die Frage nach dem Betriebssystem, dann der Download Inzwischen hat das auch Auswirkungen auf den Mausputz. (Siehe dort :-) Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Bei TRUE geht das Modem bei DTR auf LOW in den Commandmodus Einzutragen in m7com.cfg |
Default: | TRUE |
Bedeutung: | Wenn TRUE, wird das MsgIdxFile benutzt Einzutragen in m7com.cfg |
Default: | TRUE |
Bedeutung: | Wenn TRUE, wird das MsgIdxFileAllg benutzt Einzutragen in m7com.cfg |
Default: | TRUE |
Bedeutung: | Wenn TRUE, wird das MsgIdxFilePers benutzt Einzutragen in m7com.cfg |
Default: | TRUE |
Bedeutung: | Wenn TRUE, wird das UsrIdxFile benutzt; Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Bei TRUE darf ein User den CHAT anwählen Einzutragen in m7com.cfg |
Default: | TRUE |
Bedeutung: | Bei FALSE werden in der Benutzerliste, den Gruppenlisten und in der HighScore-Liste die entsprechenden Daten nicht mehr ausgegeben Einzutragen in m7com.cfg |
Default: | TRUE |
Bedeutung: | Bei FALSE werden in der Benutzerliste, den Gruppenlisten und in der HighScore-Liste die entsprechenden Daten nicht mehr ausgegeben Einzutragen in m7com.cfg |
Default: | TRUE |
Bedeutung: | Bei FALSE werden in der Benutzerliste, den Gruppenlisten und in der HighScore-Liste die entsprechenden Daten nicht mehr ausgegeben Einzutragen in m7com.cfg |
Default: | TRUE |
Bedeutung: | Bei FALSE werden in der Benutzerliste, den Gruppenlisten und in der HighScore-Liste die entsprechenden Daten nicht mehr ausgegeben Einzutragen in m7com.cfg |
Default: | 'G' |
Bedeutung: | Ab welchen Userlevel ist der Zugang zur Userliste möglich. Einzutragen in m7com.cfg |
Default: | |
Bedeutung: | Beim beenden der Maus wird ein User-Index in der Datei
Einzutragen in m7com.cfg |
Default: | TRUE |
Bedeutung: | Auflegen der Verbindung mit DTR = low. Bei FALSE geschieht es mit "+++" und dann mit ModemAuflegen Einzutragen in m7com.cfg |
Default: | TRUE |
Bedeutung: | Per Default werden Mails an die Usenet-Namen von Mäusen nicht mehr durchs MausNet geroutet. Man kann dieses Feature per UseMausAlias := true aber wieder einschalten. Ab Maus 7.95j Einzutragen in m7com.cfg |
Default: | FALSE Einzutragen in m7com.cfg |
Default: | TRUE |
Bedeutung: | Mit FALSE kann das "Gähnen" zwischen 1 und 4 Uhr morgens abgeschaltet werden. :-) Einzutragen in m7com.cfg |
Default: | '5' |
Bedeutung: | Wie lange (in *50ms) wird nach der CONNECT Meldung auf DCD^ gewartet bis die ersten Zeichen gesendet werden. Einzutragen in m7com.cfg |
Default: | '0' |
Bedeutung: | Wie lange (in ms) soll nach dem RING noch mit dem ATA gewartet werden Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | WatchDog, der bei CarrierLost in externen Programmen einen Reset auslöst Einzutragen in m7com.cfg |
Default: | GruppenProgPath\WINDOWS\' |
Bedeutung: | Pfad für Programme des WINDOWS-Betriebssystems Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Bei TRUE, schreibt der MNconfig nach jedem Lauf mit /X eine entsprechnde Mail an den WoSy. Siehe auch die Frage zum MNCONFIG Pfad für Programme des WINDOWS-Betriebssystems Einzutragen in m7com.cfg |
Default: | '200' |
Bedeutung: | Hiermit kann man die Wartezeit (in Timerticks, also 18tel Sekunden) zwischen dem Aussenden zweier XONs einstellen. Wenn XonPause auf 0 steht, werden keine XONs mehr geschickt (was ja auch bei RTS/CTS-Handshake kaum noch sinnvoll ist) Einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Bei TRUE soll die Gruppe vom FileCheck des Progputz verschont werden. Laut Achim wird sie aber noch nicht entsprechend genutzt (Stand 12.3.96) Dann einzutragen in m7com.cfg |
Default: | FALSE |
Bedeutung: | Bei TRUE wird bei einem Upload in den betreffenden
Gruppenprogrammteil eine (lokal)e Mitteilung in der Gruppe erzeugt,
analog zu den Mitteilungen im persönlichen PT. Wenn die
Mitteilung netzweit zu lesen sein soll, muß <Gruppenname>.GrpMsgLocal vom von Hand
verändert werden.
Einzutragen in m7com.cfg |
Default: | TRUE |
Bedeutung: | Wenn beim Upload in einen GPT eine Msg generiert werden soll siehe <Gruppenname>.GrpMsg), ist diese normalerweise lokal, hiermit kann man die Distribution auf "MausNet" umschalten. Sinnvoll für Gruppen wie SYSOP.PROG oder MT.CAT.DEV. Einzutragen in m7com.cfg |
Default: | '<Gruppenname>.GruppenProgPath' |
Bedeutung: | Pfad für den Gruppen-PT der Gruppe xyz. Damit kann man für jeden Gruppen-PT einen eigenen Pfad angeben Einzutragen in m7com.cfg |
Am einfachsten ist es, die Mausputz-Variablen auch in die m7com.cfg einzutragen. Viele Sachen sind dort sowieso schon definiert (Gruppen-Pfade usw).
Default: | '3000' |
Bedeutung: | Ab welchen Plattenplatz soll der Mausputz das krunchen auslösen unabhängig von den anderen Putzparametern. Einzutragen in m7com.cfg oder Mausputz.cfg |
Default: | TRUE |
Bedeutung: | Hiermit wird eine Überprüfung auf evtl. zu knappe Putzgrenzen eingeschaltet: wenn nach dem Putz die älteste in einer Gruppe verbleibende Mitteilung von "heute" ist, gibt's eine entsprechende Meldung im Log. Einzutragen in m7com.cfg oder Mausputz.cfg |
Default: | '26' |
Bedeutung: | Legt fest, ab wann User gelöscht werden. Siehe Wann werden Mails in Gruppen gelöscht? Einzutragen in m7com.cfg oder Mausputz.cfg |
Default: | '32767' |
Bedeutung: | Legt fest, ab wann User gelöscht werden. Siehe Wann werden Mails in Gruppen gelöscht? Einzutragen in m7com.cfg oder Mausputz.cfg |
Default: | '182' |
Bedeutung: | Legt fest, ab wann User gelöscht werden. Siehe Wann werden Mails in Gruppen gelöscht? Einzutragen in m7com.cfg oder Mausputz.cfg |
Default: | '3' |
Bedeutung: | Legt fest, ab wann User gelöscht werden. Siehe Wann werden Mails in Gruppen gelöscht? Einzutragen in m7com.cfg oder Mausputz.cfg |
Default: | '3' |
Bedeutung: | Legt fest, ab wann User gelöscht werden. Siehe Wann werden Mails in Gruppen gelöscht? Einzutragen in m7com.cfg oder Mausputz.cfg |
Default: | '30' |
Bedeutung: | Legt fest, ab wann User gelöscht werden. Siehe Wann werden Mails in Gruppen gelöscht? Einzutragen in m7com.cfg oder Mausputz.cfg |
Default: | '90' |
Bedeutung: | Legt fest, ab wann User gelöscht werden. Siehe Wann werden Mails in Gruppen gelöscht? Einzutragen in m7com.cfg oder Mausputz.cfg |
Default: | '' |
Bedeutung: | ??? Einzutragen in m7com.cfg oder Mausputz.cfg |
Default: | FALSE |
Bedeutung: | Bei TRUE wird damit wohl immer der forcierte Mausputz (also das physikalische löschen der Mails) aktiviert Einzutragen in m7com.cfg oder Mausputz.cfg |
Default: | '60000' |
Bedeutung: | Siehe KrunchProzent Einzutragen in m7com.cfg oder Mausputz.cfg |
Default: | '3.0000000000E+01' |
Bedeutung: | Legt fest, ab welchen Prozentanteil von gelöschten Mails die Messagebase gekruncht, d.h. die als gelöscht markierten Mails wirklich aus der Messagebase gelöscht werden. Entweder, wenn KrunchMax erreicht ist oder KrunchProzent an gelöschten Mails vorliegt. Einzutragen in m7com.cfg oder Mausputz.cfg |
Default: | '60' |
Bedeutung: | Nach dieser Anzahl von Tagen wird eine Gruppenumbenennung aus dem MGRUPPEN.REN gelöscht. Und über diese Datei werden den Usern beim tausch die Gruppenumbenennungen mitgeteilt. Also nicht auf zu knappe Werte stellen. Am besten auf den Defaultwert lassen. Einzutragen in m7com.cfg oder Mausputz.cfg |
Default: | '100' |
Bedeutung: | Nach soviel Tagen werden Mails, die den Status nicht gelesen oder zurückgestellt haben, gelöscht. Einzutragen in m7com.cfg oder Mausputz.cfg |
Default: | '400' |
Bedeutung: | Die Default-Anzahl an Mails, bevor der MausPutz zuschlägt. Siehe auch MsgOutDefaultTage und MsgOutDefaultKB Einzutragen in m7com.cfg oder Mausputz.cfg |
Default: | '200' |
Bedeutung: | Defaultgröße der Gruppen in KB bevor der MausPutz zuschlägt. Siehe auch MsgOutDefaultTage und MsgOutDefaultKB Einzutragen in m7com.cfg oder Mausputz.cfg |
Default: | '180' |
Bedeutung: | Wieviele Tage werden Gruppen-Mails aufbewahrt. Außerdem kann noch für jede Gruppe ein separater Wert angegeben werden. Das sieht dann so aus: MsgOut_SYSOPS := 'T 30 Z 300'; [' '] Allgemein gilt aber, wenn ein Wert der drei zutrifft, werden in der Gruppe Mails gelöscht. Einzutragen in m7com.cfg oder Mausputz.cfg |
Default: | Die Einstellungen in MsgOutDefaultAnzahl MsgOutDefaultKB und MsgOutDefaultTage. |
Bedeutung: | Damit läßt sich für jede Gruppe spezielle Putzparameter einstellen. So z.B. für Kubu damit dort die Mails nicht nur einen Tag aufbewahrt werden, für Maus.Info oder Sysop.Info, damit man an nach ein paar Tagen nochmal was nachgucken kann usw. Einzutragen in m7com.cfg oder Mausputz.cfg |
Default: | '30' |
Bedeutung: | Nach soviel Tagen werden Mails, die den Status gelesen, beantwortet oder im Maustausch haben gelöscht Einzutragen in m7com.cfg oder Mausputz.cfg |
Default: | '' |
Bedeutung: | NumFiles sind Dateien, in denen sich LinkIt (Fido-Gateway) merkt, bis wohin bereits exportiert wurde (Highwatermark). Diese müssen beim Mausputz geändert werden, deshalb kommen sie ins CFG, in einem String, durch Komma getrennt. Einzutragen in m7com.cfg oder Mausputz.cfg |
Default: | '60' |
Bedeutung: | So lange werden persönliche Programme aufgehoben, bis sie gelöscht werden, egal ob sie abgeholt wurden oder nicht. Einzutragen in m7com.cfg oder Mausputz.cfg |
Default: | '20' |
Bedeutung: | Nach der Zeit in Tagen werden persönliche Programme, die abgeholt wurden, gelöscht. Einzutragen in m7com.cfg oder Mausputz.cfg |
Default: | FALSE |
Bedeutung: | Der Mausputz löscht alle noch den den verschiedenen Uploaddirs liegenden Files. Damit können Fehlerhafte Uploads keine Dateileichen erzeugen. Einzutragen in m7com.cfg oder Mausputz.cfg |
Default: | FALSE |
Bedeutung: | Für den MausPutz: wenn diese Variable TRUE ist, werden nicht nur echte SysOps nie gelöscht, sondern auch die Mitglieder der Gruppe SYSOPS vor diesem Schicksal verschont. Einzutragen in m7com.cfg oder Mausputz.cfg |
Default: | '65535' |
Bedeutung: | Damit kann unabhängig von allen anderen Angaben die absolute Maximalgröße der AM-MsgBase eingestellt werden. Falls mehr als TotalMsgMax Mitteilungen vorhanden sind, werden soviel alte Msgs gelöscht, daß die Gesamtanzahl auf TotalMsgMax sinkt. |
Hier werden die Einstellungen für das MausNetz eingestellt. Die entsprechende Datei ist die Mausnet.cfg im Net-Verzeichnis. Sowohl die Zeiten, Modemeinstellungen, Anrufreihenfolgen, PM-Massen Kontrollen usw. Viele Sachen werden aus dem m7com.cfg geholt (welche Jörg?) und sind auch dort erklärt.
Default: | '' |
Bedeutung: | Der Text, der beim User abwimmeln ausgegeben wird. z.B. AbwimmelFile := 'ABWIMMEL.TXT'. Default wie bisher. Davor wird immer der MausName und der folgende Text ausgegeben: 4* <CR/LF> Einzutragen in mausnet.cfg |
Default: | TRUE |
Bedeutung: | Das MausNet soll nach dem Ende der Übertragung Abheben, damit die User kein Freizeichen hören, sondern ein Besetztton. Das funktioniert nur mit Modems ohne BTZ-Aufkleber. Also Bäh:-) Einzutragen in mausnet.cfg |
Default: | Hängt von der Ebene im Mausnetz ab. |
Bedeutung: | Bestimmt, ab wann das MausNet, wenn es ohne oder mit dem Parameter /1 aufgerufen wird, anfängt die Box über sich anzurufen. Siehe auch die Fragen zum MausNet. Einzutragen in mausnet.cfg |
Default: | '15' |
Bedeutung: | Anwahlpause die das Mausnetz zwischen zwei Versuchen einlegt. Einzutragen in mausnet.cfg |
Default: | '' |
Bedeutung: | (optionale Config-Var) legt die Anrufreihenfolge fest. Z.B.: CallOrder := 'M,HB,BN2'. Nicht erwähnte Boxen werden hinten angefügt. Damit kann man erreichen, das z.B. eine Box unter einem, die noch viele andere Boxen hat, immer zuerst angerufen wird. Einzutragen in mausnet.cfg |
Default: | 'NetIOPath\DSZ.LOG' |
Bedeutung: | Legt den Pfad für das Log-File fest. Überprüfung der Übertragung in DSZ.LOG: MausNet sucht die letzten 1-2 Zeilen des DSZLogFile durch (ConfigVar mit Default MausNetPath + DSZ.LOG) und überprüft, ob Filename und Filegröße stimmen und ob als Result nicht "E" (Error) oder "L" (Carrier Lost) vermerkt wurde. Wenn DSZ.LOG gefunden wurde, gilt diese Auswertung mehr als die Existenz oder Nichtexistenz des File ZMODEM.OK. Wichtig ist dies für die getrennte Auswertung bei bidirektionaler Übertragung (ein Errorlevel sagt nicht, welche von beiden Richtungen geklappt hat) und außerdem zur Vermeidung merkwürdiger HS/Link-Errorlevel-Probleme. Sinnvoll ist, ein SET DSZLOG=DSZ.LOG im ZMODEM.BAT zu haben. Einzutragen in mausnet.cfg |
Default: | '' |
Bedeutung: | Diese Variable sorgt dafür, daß die angegebenen Mäuse im normalen Netz nicht angerufen werden (gepackt wird auch nicht). Die entsprechenden File (*.par, *.dat und *.sta) werden aber natürlich angelegt. Einzutragen in mausnet.cfg |
Default: | TRUE |
Bedeutung: | Beim Msg-Verteilen gibt das MausNet auf dem Schirm nur CR ( kein LF) aus, um das Scrollen zu vermeiden. Spart ca. 20-25% Zeit beim Verteilen (40 Sekunden im Nachtnetz in AC). Unbedingt sinnvoll und sollte gesetzt werden. Einzutragen in mausnet.cfg |
Default: | '' |
Bedeutung: | Auf diese Boxen unter einem wird beim Nachtnetz nicht gewartet bis sie angerufen haben. Einzutragen in mausnet.cfg |
Default: | TRUE |
Bedeutung: | MultiPort-Unterstützung für 2 Modems an 2 Ports an 1 oder 2 Leitungen. Wenn ModemPorts := 1 [Default], bleibt alles beim Alten. Bei ModemPorts := 2 unterscheidet das MausNet über die Config-Var
Modem1 ist das Default-Modem, das auch bei der Verbindungsübernahme verwendet wird. Modem2 wird zum Rauswählen für die Mäuse benutzt, für die es definiert ist. Im DualLine-Betrieb nimmt das MausNet auf beiden Ports Verbindungen an. Sonst wird nur mit Modem1 angenommen, es sei denn, es wird nur auf einen oder mehrere Anrufe von Modem2-Mäusen gewartet. Einzutragen in mausnet.cfg |
##!subnode DumpCore
Default: | Hängt von der Ebene im Mausnetz ab. |
Bedeutung: | Bestimmt, ab wann das MausNet, wenn es ohne oder mit dem Parameter /1 aufgerufen wird, aufhört nach oben anzurufen. Siehe auch Fragen zum MausNet. Einzutragen in mausnet.cfg |
Default: | Hängt von der Ebene im Mausnetz ab. |
Bedeutung: | Bestimmt, wie lange das MausNet probiert, wenn es ohne oder mit dem Parameter /2 aufgerufen wird, die Boxen unter sich zu erreichen. Siehe auch Fragen zum MausNet. Einzutragen in mausnet.cfg |
Default: | Hängt von der Ebene im Mausnetz ab. |
Bedeutung: | Bestimmt, wie lange das MausNet, wenn es ohne oder mit dem Parameter /2 aufgerufen wird, auf einen Anruf von oben wartet. Siehe auch Fragen zum MausNet. Einzutragen in mausnet.cfg |
Default: | Hängt von der Ebene im Mausnetz ab. |
Bedeutung: | Bestimmt, wie lange das MausNet auf einen Anruf der Mäuse von unten wartet, wenn es ohne oder mit dem Parameter /1 aufgerufen wird. Siehe auch Fragen zum MausNet. Einzutragen in mausnet.cfg |
Default: | '65535' |
Bedeutung: | ?? Einzutragen in mausnet.cfg |
Default: | '1' |
Bedeutung: | Um soviel Prozent geht ein Busy im MausNet in die Fehlerrate ein. Die Maus probiert nur solangen, bis die Fehlerrate von 100% erreicht ist. Einzutragen in mausnet.cfg |
Default: | '5' |
Bedeutung: | Um soviel Prozent geht ein NoAnswer im MausNet in die Fehlerrate ein. Die Maus probiert nur solangen, bis die Fehlerrate von 100% erreicht ist. Einzutragen in mausnet.cfg |
Default: | '30' |
Bedeutung: | Um soviel Prozent geht ein NoCarrier im MausNet in die Fehlerrate ein. Die Maus probiert nur solangen, bis die Fehlerrate von 100% erreicht ist. Einzutragen in mausnet.cfg |
Default: | '10' |
Bedeutung: | Um soviel Prozent geht ein NoDialtone im MausNet in die Fehlerrate ein. Die Maus probiert nur solangen, bis die Fehlerrate von 100% erreicht ist. Einzutragen in mausnet.cfg |
Default: | '50' |
Bedeutung: | Um soviel Prozent geht ein Fehler in der Verbindung im MausNet in die Fehlerrate ein. Die Maus probiert nur solangen, bis die Fehlerrate von 100% erreicht ist. Einzutragen in mausnet.cfg |
Default: | FALSE |
Bedeutung: | Abgleich der Uhr nach der Funkuhr-Zeit. Beispiel. M setzt FunkUhr := TRUE und nach jedem Anruf werden die anderen Uhren Ebene für Ebene nachgestellt. Bei Abweichungen > 5 Minuten kein Abgleich. Dieses sollte nur eine Maus im Netz gesetzt haben Einzutragen in mausnet.cfg |
Default: | '60' |
Bedeutung: | Funkuhr-Zeit wird auch über 2 Aufrufe hinweg gespeichert. In MAUSVAR.DAT steht Datum und Zeit des letzten Uhrabgleichs. Innerhalb der nächsten 60 Minuten (Config-Var FunkuhrZeitFuerMin) glaubt das MausNet, Funkuhr-Zeit zu haben. Sinnvoll beim Uhrabgleich im MausNet /1 und dann für die Weiterverteilung im MausNet /2 an die anderen Boxen. Einzutragen in mausnet.cfg |
Default: | '3' |
Bedeutung: | Verbindungsübernahme: Initsequenz von MausNet an MAUS nicht mehr 5* alle 500 ms, sondern schneller. Dadurch Verbindungsübernahme auch bei schnellen Rechner wie in AC3 sicherer! Beide Werte konfigurierbar: Einzutragen in mausnet.cfg |
Default: | '250' |
Bedeutung: | Verbindungsübernahme: Initsequenz von MausNet an MAUS nicht mehr 5* alle 500 ms, sondern schneller. Dadurch Verbindungsübernahme auch bei schnellen Rechner wie in AC3 sicherer! Beide Werte konfigurierbar: Siehe auch InitToMAUSCount Einzutragen in mausnet.cfg |
Default: | '3000 |
Bedeutung: | ??? Das gleiche wie InitToMAUSDelay ? Einzutragen in mausnet.cfg |
Default: | '5000' |
Bedeutung: | ???? Auch beim lokalen PM-Export Ausgabe der Msglänge, wenn größer LangePersMsg Einzutragen in mausnet.cfg |
Default: | '0' |
Bedeutung: | Ab DOS 3.30 kann man auch mehr Files (z.B. 30) öffnen. Dazu muß |
1. in CONFIG.SYS Files = 30 | |
2. in MAUSNET.CFG MaxFiles := 30 gesetzt werden. Einzutragen in mausnet.cfg |
Default: | '0' |
Bedeutung: | Anrufende Maus unterbricht Verbindungen mit nicht-maximaler Baudrate. Pro Box noch zusätzlich konfigurierbar, z.B.: MinBaudMS2 := 1200 Einzutragen in mausnet.cfg |
Default: | '' |
Bedeutung: | Das ist die Nummer der Box XY. Default die Nummer aus dem EXP. Man kann auch andere Nummer definieren. Einzutragen in mausnet.cfg |
Default: | '' |
Bedeutung: | Eigentlich abgeschaft. Steht aber noch drin. Einzutragen in mausnet.cfg |
Default: | 'DP' |
Bedeutung: | Default ModemDial Kommando, um die Boxen anzurufen. Kann man mit den Variablen ModemDailPreXY noch pro Maus einzel festgelegt werden. Einzutragen in mausnet.cfg |
Default: | '45' |
Bedeutung: | Bestimmt wie lange die Daten zu den Msg-Traffic des Nachtnetzes in der MN-MSG.DAT gehalten werden. Siehe auch TimStatTage Einzutragen in mausnet.cfg |
Default: | '0' |
Bedeutung: | ??? Keine Ahnung Einzutragen in mausnet.cfg |
Default: | '' |
Bedeutung: | ??? Keine Ahnung Einzutragen in mausnet.cfg |
Default: | '64' |
Bedeutung: | Ab welcher Länge werden PMs an einen User gefiltert. Ist MausNetzweit einheitlich auf 64Kb einzustellen. 0 bedeutet kein Filter. Siehe auch PMMassenHinweis Siehe auch Gefilterte PM-Massen Einzutragen in mausnet.cfg |
Default: | '0' |
Bedeutung: | Ab welchen PM-Massen bekommt der Sysop eine Warnmeldung. Kann kleiner als PMMassenFilter sein. Siehe auch Gefilterte PM-Massen Einzutragen in mausnet.cfg |
Default: | '120' |
Bedeutung: | Das Mausnetz überwacht den Status der PMs. Wenn eine Mail keinen angekommen Status bekommt, gibt es eine entsprechende Warnung. Und zwar so lange, bis der Maximalwert erreicht ist oder der Status entlich angekommen ist. Siehe auch PMVerlustMin und Was bedeutet die 'nicht angekommen' Meldung? Siehe auch PMVerlustMin und Was bedeutet die 'nicht angekommen' Meldung? Einzutragen in mausnet.cfg |
Default: | '72' |
Bedeutung: | Das Mausnetz überwacht den Status der PMs. Wenn eine Mail keinen angekommen Status bekommt, gibt es eine entsprechende Warnung. Und zwar ab der Zeit, die hier als minimalwert angegeben ist. Siehe auch PMVerlustMax und Was bedeutet die 'nicht angekommen' Meldung? Einzutragen in mausnet.cfg |
Default: | '30' |
Bedeutung: | Übertragung der erwarteten Packzeit bei Verbindungsübernahme durch das MausNet. Der Defaultwert ist sehr niedrig. Für ein 386/40 mit Writecache kann man 100 setzen. Wenn keine Probleme auftreten, kann der Defaultwert aber auch stehen bleiben. Messung wird im Logfile ausgegeben. Einzutragen in mausnet.cfg |
Default: | '' |
Bedeutung: | Hier kann und sollte unbedingt pro MausNet-Verbindung ein Paßwort eingetragen werden. So kann verhindert werden, das irgend jemand unter der Kennung einer anderen Box anruft und Mails unter dieses Fake-Kennung verbreitet. Das Passwort muß natürlich auf beiden Seiten gleich gesetzt sein. Pro Maus einzel konfigurierbar Einzutragen in mausnet.cfg |
Default: | 'Z' |
Bedeutung: | Protokoll wählbar: pro Box gibt's ein Protokoll.XY, daß z.B. für HS/Link auf 'H' gesetzt werden kann. Wenn beide Boxen dies für den anderen gesetzt haben, wird damit gearbeitet, sonst läuft's wie gehabt mit ZModem. Das Protokoll wird als Parameter 5 an ZMODEM.BAT übergeben. UseZModem ist dafür abgeschafft. Einzutragen in mausnet.cfg |
Default: | 'H' |
Bedeutung: | Bidirektionale Übertragung (z.B. mit HS/Link): wenn das vereinbarte Protokoll bidirektional arbeitet (muß in Protokoll.Bidirect [Default: 'H' aufgelistet sein), wird statt "rz" oder "sz" "bi" an ZMODEM.BAT übergeben. Einzutragen in mausnet.cfg |
Default: | '90' |
Bedeutung: | Bestimmt wie lange die Timing-Daten des Nachtnetzes in der MN-MSG.DAT gehalten werden. Siehe auch MsgStatTage Einzutragen in mausnet.cfg |
Default: | '300' |
Bedeutung: | Wenn die Uhren um mehr als dieser Wert voneinander abweichen, gibt es keinen Uhrabgleich. Einzutragen in mausnet.cfg |
Default: | '60' |
Bedeutung: | Solange wartet die Maus bei einem manuellen MausNet, wenn eine andere Maus angerufen wird, bis diese mit dem packen fertig ist (da ja online gepackt wird) Einzutragen in mausnet.cfg |
Hier nochmal ein Teil der Fragen anders aufgelistet. Vielleicht findet man so einige Sachen eher. Ich hatte ja schon Probleme Fragen wieder zu finden.
Modemfragen
Packerfragen
Alles um Userprobleme
Programmteil
Für Konsolensysops
Alles zum löschen von Mails/Programmen etc.
MausNet
Allgemeine Tips zur Maus
CallCheck Batch
Gatefragen/InterNetfragen
Und hier der ganze Rest
ID:A25613@K2 und ab TOP 5: ID:A25614@K2 Von: Dirk Steins @ K2 (Mi, 25.09.91 11:09)
Das Mosbacher Protokoll:
Anwesend in Mosbach waren die Sysops von 23 Mäusen. Warum wir uns dort versammelt haben, muß ich hoffentlich nicht nochmal wiederholen. Fangen wir mal an.
Als erstes wurde Gereon Steffens als Diskussionsleiter bestimmt, da er der erste eingetragene Benutzer in MS war. Dann wurde noch ein Protokollführer gesucht und jemand, der die Wortmeldungen in die richtige Reihenfolge bringt. Protokollführer wurde Markus Wagenmann und meine Wenigkeit übernahm die Aufgabe der Wortmeldungskoordination.
Folgende Punkte wurden dort auf die Tagesordnung gesetzt und auch behandelt:
Tagesordnung
Abstimmungsverfahren
IN-Beteiligung
Ignorer in Kunterbunt
Vergrößerung des Mausnetzes (Grenzen/Perspektiven)
Topologie des Mausnetzes
Farben in der Maus (ANSI-Sequenzen)
Technische Probleme (Mehrbenutzer-Maustausch, Tausch in mehreren Mäusen)
GEnie-Gate
Zerberus Gruppen Suche/Biete
Mindestanforderungen für neue Mäuse
Maus-Logo
Pool für Hardware
Pseudos Ja/Nein
Als erstes haben wir festgelegt, wer von den Anwesenden überhaupt abstimmen darf, denn auch darüber existierten verschiedene Meinungen, ob Co-Sysops mit abstimmen dürfen oder nicht. Nach einer Diskussion über dieses Thema wurde dann zur Abstimmung geschritten. Damit wir da nicht direkt in Probleme liefen, durften bei dieser Abstimmung nur die anwesenden Mausbetreiber abstimmen. Mit einfacher Mehrheit wurde entschieden, daß alle anwesenden abstimmen dürfen, sowohl Sysops als auch Co-Sysops. Nachdem dieser erste Punkt nun geklärt war, konnten wir zu dem ersten Punkt auf der Tagesordnung übergehen.
Es wurde folgendes beschlossen:
Wir haben ab jetzt folgende Abstimmungsmodi:
Betreiberabstimmung: Bei dieser dürfen nur die Betreiber von Mäusen abstimmen, Co-Sysops also nicht. Dies ist insbesondere für die Fälle gedacht, in denen es um Geld geht, daß die Sysops zahlen müssen.
Sysopabstimmung: Alle Sysops dürfen abstimmen. Dies ist für solche Fälle gedacht, in denen es nicht unbedingt um Geld geht, aber wo es um wichtige Sachen geht, die die User nicht unbedingt etwas angehen.
Userabstimmung: Jeder Spender/Beitragszahler darf abstimmen.
Wir haben außerdem beschlossen, daß es sinnvoll ist, bei einigen Abstimmungen nur eine 2/3-Mehrheit zum Beschluß zuzulassen. Dies wird je nach Fall vom Abstimmungsleiter festgelegt. Ebenso wird gegebenenfalls eine Mindestbeteiligung festgelegt.
Wir wählen einen Mausabstimmungsleiter (+ Stellvertreter), der
die ganzen Abstimmungen in der Maus koordiniert. Dazu wird eine neue Gruppe
ABSTIMMUNG für die Userabstimmungen eingerichtet, in der vom
Abstimmungsleiter der Aufruf zur Diskussion über das Thema und der
Aufruf zur Abstimmung gepostet wird. ABSTIMMUNG hat Read-Only und Paid-Only
zu sein (und Default, später auch Plicht), die Diskussionen sollen in
Maus bzw. Sysops stattfinden (ggf. in besonderen Fällen in anderen
Gruppen).
Für Sysop- und Betreiberabstimmungen werden diese Sachen (CFD,
CFV) in Sysop-Info gepostet. Der Abstimmungsleiter hat folgende Pflichten:
Aufruf zur Diskussion
Protokollierung der Diskussion
Festlegung des Wahlmodus/Mindestbeteiligung (nur Sysop-/Betreiberabstimmung)
Aufruf zur Abstimmung mit Angabe der wichtigen Argumente Pro/Contra aus der Diskussion
Auswertung der Abstimmung und Bekanntgabe des Ergebnisses
Archivierung des Ergebnisses
Nach dem Aufruf zur Diskussion (CFD) kann zwei Wochen über das Thema diskutiert werden. Diese Diskussionszeit kann bei Bedarf noch zweimal um jeweils eine Woche verlängert werden. Nach Ablauf dieser Zeit ruft der Abstimmunsgleiter durch eine entsprechende Message in ABSTIMMUNG bzw. SYSOP-INFO zur Abstimmung auf. Die Stimmen sind dann innerhalb einer Woche an den Abstimmungsleiter zu senden. Dieser postet dann nach der Auswertung das Ergebnis in SYSOP-INFO und ABSTIMMUNG (sofern erforderlich).
Der Abstimmungsleiter kann jederzeit abgewählt werden. Dazu ist der Vorschlag eines neuen Abstimmungsleiters erforderlich, eine Angabe von Gründen für die Abwahl und eine entsprechende Abstimmung, die dann vom Stellvertretenden Abstimmungsleiter durchgeführt wird.
Sollte bei einer Sysop- oder Betreiberabstimmung die festgelegte Mindestbeteiligung nicht erreicht werden, so wird diese Abstimmung zu einer Pflichtabstimmung, an der alle Betreiber teilnehmen müssen.
Die Programmierer der Maus können nicht durch eine Abstimmung zu schwerwiegenden programmtechnischen Änderungen in der Maus gezwungen werden, in diesem Falle haben sie das Recht, das zu verweigern.
Wenn es bei Abstimmungen um Belange geht, die nur Mäuse etwas angehen, so sind auch nur echte Mäuse stimmberechtigt, Quarks und Ferwis nicht. Bei anderen Abstimmungen sind diese gleichberechtigt.
Als Abstimmungsleiter wurden gewählt:
Abstimmungsleiter: Erwin Timmerbeil @ BN Stellvertreter: Frank Tegtmeyer @ HRO
Die Fragen, die diskutiert wurden, waren folgende:
Wollen wir eine Pflichtbeteiligung aller Mäuse am IN?
Wie sieht es in der Zukunft mit den Kosten aus?
Nach der Diskussion wurde folgendes beschlossen:
Nach außen hin nehmen alle Mäuse am IN teil!
Innerhalb des Mausnetzes regeln wir die Teilnahme selbst. Durch die neue Gatewaysoftware können dann einzelne Mäuse, die nicht am IN teilnehmen wollen/können, intern abgeklemmt werden, so daß sie nicht den Gateway zum Usenet nutzen können. Empfangen von internationaler Mail wird aber dadurch für alle Mäuse möglich sein!
Wir empfehlen jeder Maus, am IN teilzunehmen. Dies gilt insbesondere auch für neue Mäuse, die neu in das Netz kommen.
Die durch die Gesamtteilnahme entstehenden Kosten werden intern auf die real teilnehmenden Mäuse umgelegt. Einige Mäuse (B, BN, WÜ) erklärten sich bereit, auch höhere Beiträge zu zahlen um den Pool auszugleichen.
Die zukünftigen Kosten: Da noch nicht feststeht, wieviele Rechner/Domains nächstes Jahr am IN teilnehmen werden, stehen die genauen Kosten noch nicht fest. Nach Auskunft von Jürgen Conradi sieht es im Moment so aus, daß wohl pro Maus Kosten von ca. 15,- bis 20,- DM pro Monat entstehen werden. Dies kann noch niedriger werden.
Das IN bzw. Jürgen Conradi @ HB als unser Vertreter bezüglich IN soll regelmäßig Rechenschaft über die Einnahmen und Ausgaben ablegen.
Anmerkung: Da es bei dieser Frage um effektiv auftretende Kosten für die Mausbetreiber ging, wurde die Abstimmung als reine Betreiberabstimmung durchgeführt.
Die Herkunft dieser Messages ist ja inzwischen von Erwin Timmerbeil geklärt worden. Noch nicht bekanntgegeben wurde hier im Netz, wer alles an dieser Aktion beteiligt war. Dies waren: Erwin Timmerbeil @ BN, Heinz Decker @ BN, Jürgen Lanzki @ BN, Florian Helm @ SU, Stefan Radermacher @ K2 und Dirk Steins @ K2 (also ich).
Der Ignorer-Gang wurde ein mündlicher Verweis erteilt, und sie mußte das Versprechen abgegeben, solch eine Aktion nicht zu wiederholen.
Es wurde die Frage gestellt, wie weit das Mausnetz noch ohne technische Probleme wachsen kann.
Jörg und Kai konnten dazu keine genaue Auskunft der Art "Wir können xx Mäuse und yy Gruppen ohne Probleme verkraften" geben, waren aber beide der Meinung, daß im Moment noch einiges an Luft im Timing vorhanden sei und daß man daran wahrscheinlich auch noch einiges rausholen könnte.
Im Prinzip ging es bei dieser Frage um das gleiche wie bei Punkt 4 und wurde deshalb damit schon erledigt.
Es ging um die Frage, die Frank Baschin neulich in Sysops gestellt hatte, warum die Maus auf Schwarz und Weiß umschaltet. Frage wurde durch Kai Henningsen und Jörg Stattaus beantwortet.
Es wurde beschlossen, diese Fragen (Mehrbenutzer-Maustausch etc.) in den entsprechenden Gruppen zu behandeln, da dies in einer Diskussion sowieso nicht möglich ist.
Es gab ja schon einige Diskussionen um den GEnie-Gateway, die hier nochmal besprochen wurden. Es wurde beschlossen, den Gate vorerst nicht weiter auszubreiten und auch bei bestehenden, vernetzten Gruppen zu überprüfen, ob überhaupt Interesse an diesen Gruppen vorhanden ist und ob diese gelesen werden. Wenn dieses nicht der Fall ist, soll zur Kosteneinsparung die entsprechenden Gruppen wieder abgeschaltet werden.
Da niemand aus München da war, konnte das Thema nicht weiter behandelt werden. (Oder war da doch noch was anderes, ich habe nichts weiteres in den Unterlagen stehen?)
Es wurde überlegt, was für Mindestanforderungen für neue Mäuse gelten und ob wir dort etwas vorschreiben sollen. Nach kurzer Diskussion (war ja schon spät) wurde beschlossen, nur die Empfehlungen für neue Mäuse zu erweitern. Folgende Mindestanforderungen sollte eine neue Maus in Zukunft erfüllen:
IN-Teilnahme
24h Online-Zeit
AT als Rechner
V.32 als Modem
Außerdem wurde beschlossen, keine Überbevölkerung eines Raumes mit Mäusen zuzulassen, solange keine vernünftige Auslastung der vorhandenen Mäuse gewährleistet ist, also z.B. keine Maus K5 oder AC4 oder so.
Da ja demnächst die Maus OTR auf der Hobby-Elektronik in Stuttgart präsentiert wird, wurde von den Ausstellern der Vorschlag gemacht, doch ein einheitliches Maus-Logo für solche Sachen zu haben. Ein genauer Beschluß darüber wurde aber meines Wissens nach nicht getroffen. (Steht auch nichts im Protokoll)
Es kam die Frage auf, ob ein allgemeiner Pool für Hardwareanschaffungen geschaffen werden soll, damit etwas Geld vorhanden ist, falls eine Maus in eine Notsituation kommt (Platte abgeranzt oder ähnliches und kein Geld da). Dieser Vorschlag wurde abgelehnt.
Da in der letzten Zeit ja auch immer wieder Pseudo-Accounts von Sysops eingerichtet wurden, kam die Frage auf, ob so etwas toleriert werden soll oder nicht. Die Diskussion darüber brachte folgendes Ergebnis:
Grundsätzlich sollten keine Pseudo-Accounts eingerichtet werden. Für Damönen, also Programme, die direkt Daten aus der Maus erhalten oder in diese schreiben, sind solche Accounts erlaubt. Diese müssen dann aber deutlich als solche erkennbar sein. Bis Dämonen "echt" von der MAUS unterstützt werden (d.h. Ein-Wort-Namen, die nicht in der Userliste auftauchen), sind solche Accounts für Dämonen so umzubenennen, daß der Nachname "Programm" oder "Dämon" ist.
Andere Pseudo-Accounts sind "genehmigungspflichtig", sollten vor der Einrichtung vorgestellt und zur Diskussion gestellt werden.
Es wurde gefragt, wie wir uns in Bezug auf Dieter Soltau verhalten
sollen, der ja alle Messages aus der Maus in das Fido-Netz 241 bounced (auf
Grund von seiner Meinung nach falschen Message-IDs). Es gab die
Möglichkeit, daß wir LinkIt so abändern, daß PMs in
das 241er-Netz wieder möglich sind, oder daß wir hart bleiben
und darauf hoffen, daß Dieter Soltau entweder irgendwann einsieht,
daß es Unsinn ist, was er macht, oder daß er abgesägt wird
(was aber noch eine ganze Weile dauern kann). Hiermit möchte ich
übrigens kurz Jan Egner für seine guten Informationen zu diesem
Thema danken.
In einer der Diskussion folgenden Abstimmung wurde dann beschlossen,
daß wir LinkIt nicht ändern. Es geht also auch demnächst
keine PM in das 241er-Netz. Damit das MausNetz einheitlich auftritt, wurde
außerdem beschlossen, daß die anderen Gates in das Fido-Netz so
schnell wie möglich auf das neue LinkIt umgestellt werden.
Außerdem sollte in der nächsten Zeit auf Grund des knappen
Ergebisses noch eine Abstimmung zu diesem Sachverhalt stattfinden.
------------------------------------------------- Ende des Protokolls. Tippfehler (c) Dirk Steins. -------------------------------------------------
Datei: FL_LANG.TXT erstellt am: 11.02.93 verändert am: 15.03.93 Autor: Michael Keukert, Stefan Rupp, Jörg Stattaus Kurz-Info: Protokoll des MausNet SysOp-Treffens Beschreibung: Überarbeitetes Protokoll des MausNet-Sysop-Treffens vom 9.10 bis 11.10.1992 in Flensburg-Glücksburg, endgültige Fassung vom 11.03.93. Gruppe: MAUS.DOKU Subject: Protokoll Sysop-Treffen ID: A31822@AC, A31823@AC, A31824@AC Von: Jörg Stattaus @ AC (Fr, 12.03.93 23:59)
Überarbeitetes Protokoll des MausNet-Sysop-Treffens vom 9.10 bis 11.10.1992 in Flensburg-Glücksburg, endgültige Fassung vom 03.03.93.
Tagesordungspunkte:
1.0. Gateways (und deren Zukunft) 1.1. Gateway Zerberus 1.2. Gateway UseNet 1.3. Gateway HB (Probleme, Kosten, UUE's) 1.4. Gateway Genie 1.5. lokale Gateways 2.0. IN 2.1. Kosten,Kostensenkung 2.2. Kosten u. Schutz bei Anschlägen von Hackern 2.3. Alternativen zum IN 3.0. MAUS 3.1. MAUS 9 wann, was kann sie? 3.2. Multiport MAUS 3.3. Online Editor 3.4. Netzstruktur und Topologien 3.5. neue Regelung für Netzgruppeneinrichtung 3.6. neue Regelung für neue Sysops (Aufnahmekriterien) 3.7. $ per MauTau setzen können (Erleichterung der Wartung) 3.8. MausTauschformat und Erweiterung 3.9. Verbreitung der MAUS im Osten 3.10. Wahl des Stellvertreters des AL 4.0 SYSOPS 4.1. welche Pflichtgruppen für Sysops? 4.2. soll eine Gruppe SYSOP-LALL/LITE eingerichtet werden? 4.3. Pflichtgruppen jeder Maus 4.4. nächstes Treffen wo und wer? 4.5. kommerzielle Werbung in der Maus
Am Anfang wurde der Abstimmungsmodus geklärt: alle Anwesenden dürfen abstimmen, ist das Ergebnis unklar, erfolgt eine Betreiberabstimmung, bei der nur die MausNet-Box-Betreiber abstimmen dürfen (ach, was?).
Obwohl Klaus Atzpodien in Flensburg über das Thema referiert hat, gibt der folgende Abschnitt wegen mangelhafter Aufzeichnungen den aktuellen Stand der Dinge nach Kenntnis von Michael Keukert wieder:
Das Z-Netz hat per Koordinationsbeschluß seinen Gateway zum MausNet ausgetragen. *EIGENTLICH* sollten alle Z-Netz-Systeme daraufhin die Systeme ZERMAUS.ZER und ZERM-SL.ZER aus ihrer Konfiguration austragen (das geht bei denen nicht automagisch). Nun sieht es aber so aus, daß bei einem Großteil der Z-Netz-Systeme die Maus-Bretter recht beliebt sind. Auch möchte man auf den persönlichen Mailtransfer mit den Maus- Usern nicht verzichten. Deshalb sind viele Sysops der Aufforderung der Koordination NICHT nachgekommen, und führen zumindest ZERMAUS.ZER noch. Gestern Abend (16.2.93) habe ich noch persönlich in der BIONIC.ZER, einem der größten Systeme im Z-Netz angerufen, und dort noch den ZERMAUS Eintrag gefunden.
Ob, und wie das Z-Netz seine geplante Aufteilung in das Z-Brett-Netz und das Z-PM-Netz durchführt, und wie die Kosten und Pflichten von teilnahme- willigen Systemen aussieht, ist derzeit noch nicht bekannt.
Das Meinungsbild der Maus-Sysops scheint aber allenthalben in die Richtung zu gehen, daß man auch sehr gut ohne den Brettaustausch mit dem Z-Netz leben kann, da eh mehr Maus-Bretter ins Z-Netz gehen als umgekehrt. Auf den PM-Austausch möchten die meisten aber nicht verzichten.
Beschlüsse: keine
Mick Schmidt @ HB berichtet über die aktuelle Lage:
Problem der letzten Zeit, das auch zu den Unstimmigkeiten in SYSOPS geführt hatte, war in erster Linie, daß die User im MausNet nach wie vor viel zu schlecht informiert sind und viele Sysops sich auch überhaupt nicht darum kümmern, teilweise nicht mal oder nur sehr schleppend auf Anfragen aus HB reagieren. Konkret: Übermäßige (insbesondere finanzielle) Belastung des Gateway in HB, verursacht durch Mailmassen, teils von Usern aus dem Usenet, aber hauptsächlich von Mailinglisten und Mailservern.
Seit geraumer Zeit müssen diese Mailmassen in Bremen ausgefiltert werden, um das MausNet-Timing nicht zu gefährden. Die Abholung der aufgelaufenen Mail-Massen und die Bezahlung der entstandenen Kosten durch die User funktioniert aber äußerst schlecht.
Lösung:
Die enstandenen Kosten werden direkt vom IN-Konto der jeweiligen Heimatmäuse der User abgebucht, der Sysop muß sich dann mit seinem User auseinandersetzen, um das Geld wieder reinzubekommen. Zur Not kann ja der $ gekürzt werden. Zusammen mit der Abbuchungsmeldung an den Sysop geht eine Benachrichtigung an den User raus, daß er sich die Sachen, die für ihn angekommen sind, innerhalb der nächsten 14 Tage in HB abholen kann, danach werden sie gelöscht.
Die Lösung findet allgemeine Zustimmung.
[Anm. zum letzgenannten Verfahren: dieses ist inzwischen, zum Zeitpunkt der neuen, besseren Ausformulierung des Protokolls schon wieder geändert. Die aktuelle Regelung wird regelmäßig in MAUS.INFO geposted und kann natürlich vom lokalen Sysop oder von <info maus-de @ HB> erfragt werden.]
Nächstes Problem: Bisher werden nur übergroße UUEncodete Mails abgefangen. Es kommen aber auch verstärkt große ASCII Mails, z.B. Inhaltsverzeichnisse von Mailservern, etc.
Überlegung: Soll ein Filter bezüglich der Datenart eingesetzt werden? Wie sollte dieser dann aussehen? Ein Vorschlag: User bekommt die ersten Mailzeilen, dann kann er entscheiden, ob interessant. Und dann kann er es abholen.
>Abstimmung zwei Befürworter, Rest dagegen.
Dann wurde diskutiert, was als nicht erlaubte PM-Massen gilt: nur Files, die per UU, AtoB oder sonstwie übertragen werden, oder auch beliebige PMs. Eine Argumentation ging in die Richtung, daß Mails mit Briefcharakter etwas "schützenswertes" seien, da wir ein Netz zur Kommunikation seien. Gegenstimmen meinten, daß uns der Inhalt von PMs nichts angeht, und egal wäre, ob nun persönliche Briefe, Sourcen oder GIFs ausgetauscht werden. Zählen würde die Länge und man solle ein Limit für die maximal erlaubte Größe festsetzen.
>Abstimmung: deutliche Mehrheit für Inhalt egal, PM-Massen ab x KB.
Wie soll die Grenze für PM-Massen aussehen?
64KB, 48KB, 32KB?
>Abstimmung unentschieden zwischen 64K und 48K.
>Betreiberabstimmung ergab dann 11 Stimmen für 64K, Rest
für 48K. [48K]
48 KB sollten für jede "normale" Mail ausreichen, dies sollte jedoch beobachtet werden, damit ggf. die Grenze nach oben oder nach unten angepasst werden kann. Grundsätzlich gilt: Filetransfers per Mail sind im MausNet unerwünscht! In Ausnahmefällen ist eine Mailgröße von bis zu 48 KB zulässig, jedoch nicht regelmäßig. Ab 48 KB werden Mails im gesamten MausNet ausgefiltert und um eine Ausnutzung dieser relativ hohen Grenze besser erkennen zu können, werden schon bei einer niedrigeren Grenze Warnmeldungen von der Maus an den Sysop erzeugt.
Diese neuen Regelungen sollen den Usern möglichst bald bekannt gemacht werden und auch weitere Informationen zum Thema Gateways "Was geht und was nicht" sollen insbesondere auch von den lokalen Sysops weitergegeben werden. Speziell auch an neue User, am besten auch als Erinnerung z.B. durch regelmäßige Rundschreiben oder Nachrichten in ÖFFENTLICH.
Frage: Soll eine Gruppe FTP eingerichtet werden, in der Anfragen gepostet werden können, welche Files wo und von wem zu besorgen sind?
>Abstimmung: Gruppe FTP kein allgemeiner Konsens. So etwas kann lokal geregelt werden.
Marco Hahn @ SL brachte das Thema Maus-GEnie Gateway wieder auf die Tagesordnung. Er meinte, es bestünde von Seiten des GEnie, als auch von Seiten der GEnie-User nach wie vor starkes Interesse an einer Vernetzung. Er habe die Sache soweit abgeklärt, das auch die eine oder andere GEnie-Gruppe (Roundtable) ins MausNet gereicht werden könne.
Trotzdem bleibt nach wie vor die Frage der Kosten. Jeder Roundtable hat einen eigenen Sysop, der anteilig am Nachrichtenaufkommen entlohnt wird. Er erhält also für jede im Roundtable geschriebene Mail Geld - auch für die über einen Gateway eingespeisten.
Das Stimmungsbild der Maus-Sysops nach kurzer Diskussion:
Es stößt auf Mißfallen, daß an Maus-Mails verdient werden würde. Bei einer eventuellen Vernetzung sollten sämtliche Kosten/Einnahmen offengelegt werden. Auf jeden Fall dürfen der Maus keine Kosten entstehen, ein eventueller Gateway muß entweder selbst anrufen oder eben die Telefonkosten übernehmen. Einige Stimmen forderten sogar, sämtliche Gewinne, die durch einen eventuellen Maus-Gate eingespielt würden, müßten wieder an die Maus zurückfließen und z.B. in den IN-Topf eingebracht werden.
Ein Beschluß wurde nicht gefaßt.
Über den Begriff "lokale Gateways" wurde diskutiert. Nach Michael Keukert ist ein lokaler Gateway nur dann lokal, wenn er z.B. eine lokale Area einer Fido-Box mit einer lokalen Gruppe einer Maus austauscht. Die jetzigen sogenannten "lokalen Gateways", die netzweite Fido-Areas bei sich importieren, sind nicht lokal, da dort von Mausern geschriebene Mails ins ganze FidoNet gehen.
Jörg Stattaus erklärte die Probleme von "lokalen" Fido-Gateways, die Gruppen oder Areas austauschen würden, die bereits in AC über den Gateway gehen. Zur Zeit ist dies nicht möglich, da aus technischen Gründen Dupes nicht als solche erkannt werden können. Eine MAUS-Mail, die in AC über den Gateway geht, würde in einer anderen MAUS wieder importiert werden. Umgekehrt würden auch Fido-Mails doppelt importiert werden. Neben diesen technischen Problemen ist es auch erwünscht, daß alle Vernetzungen mit AC abgesprochen sind, da man dort politisch für den Gateway verantwortlich sei und eventuelle Probleme auf AC zurückfallen. Netzgruppen sollen weiterhin in AC über den Gateway gehen.
Ähnliches gilt für "lokale" UseNet-Gateways. Hier bedarf es einer Abklärung mit Jürgen Conradi bezüglich des IN-Vertrages, denn HB ist für das MausNet Domain-Verwalter und verantwortlich für Mails unter der Adresse .maus.de oder .maus.sub.org. Derzeit dürfen nur in Bremen Gruppen in der MAUS.* Hierarchie im Usenet eingerichtet werden.
Die IN-Teilnahme des MausNetzes ist nicht mehr volumenabhängig, sondern die vom MausNet ans IN zu zahlenden Kosten sind nur abhängig von der Anzahl der (am IN teilnehmenden) Mäuse im Netz (IN = Individual Network). Um die Kosten untereinander jedoch möglichst gerecht aufzuteilen, stuft sich jede Maus selbst bezüglich ihrer InterEUNet-Teilnahme als klein, mittel oder groß ein. So entstehen Kosten von 10, 15 bzw. 20 DM,-/Monat zuzüglich der pauschalen DM 5,- Servergebühren als Beteiligung an den Bremer Telefongebühren.
Es wurde darum gebeten, diese Selbst-Einteilung möglichst gewissenhaft zu machen, da theoretisch stets genausoviel kleine wie große Mäuse existieren müssen, um die Kosten plus/minus Null abzudecken.
Die Teilnahme am IN (eigentlich IN e.V.) macht uns gleichzeitig zu Mitgliedern im DFN (Deutsches Forschungs-Netz), im WiN e.V. (Wissenschafts-Netz) und im EUnet.
Da die Gebühren für 1993 im Voraus zu zahlen sind, zahlt das MausNet zur Zeit neben den Gebühren für 1992 die für 1993 schon mal mit, damit Anfang des nächsten Jahres das Kapital vorhanden ist. Das IN hat eine 9600 bps WiN-Leitung gemietet, die DM 18.000,- / Jahr kostet. Das Mausnet zahlt zur Zeit 600,- bis 670,- DM / Monat für die Teilnahme am InterNet. Weil ab 93 nur noch der Beitrag für jeweils ein Jahr fällig wird (93 also für 94), sollten die Kosten also demnächst etwas sinken.
Da das IN nur für Privatanwender zur Verfügung steht, dürfen kommerzielle Mäuse (z.B. Atari) nicht am IN teilnehmen. Es steht diesen (wie auch den anderen Mäusen, die aus anderen Gründen (noch) nicht am IN teilnehmen) die Domain maus.sub.org offen. Solche Mäuse zahlen nur die pauschale Servergebühr von DM 5,- / Monat an die Maus HB.
Problematisch ist die Behandlung von Anschlägen gegen das MausNet durch Mailbomben. Es gibt augenblicklich leider keine Möglichkeit, solche Mailbomben bereits an der uniol (Uni Oldenburg, von dort pollt die Maus HB) abzufangen. Größere Mailmassen lassen die Maus HB also unter Umständen lange Zeit pollen. Dadurch kann nicht nur das Netztiming gekippt werden, sondern es entstehen auch große Telefonkosten. Diese müssen irgendwie getragen werden, auch wenn die Mails nicht von einem Maus-Benutzer angefordert worden sind, also auch niemand dafür verantwortlich gemacht und finanziell belastet werden kann. Solche Kosten müssen vom IN-Konto getragen werden und sich auf überschüssigen Beiträgen ergeben.
Die Telefonverbindung HB <-> uniol ist keine Ortsverbindung, weshalb solche Mailbomben sehr teuer werden können. Eine Abhilfe wäre eine Verbindung im Ortstarif. Einige Mäuse betreiben bereits jetzt schon eigene Internet- Gateways. Dadurch wird der Risikofaktor aber nur wenig verringert, da der Großteil der Mails nach wie vor über HB läuft.
Damit das Problem auch tatsächlich bekannt ist (und nicht etwa scherzweise von einigen Benutzern heraufbeschworen wird), soll ruhig öffentlich auf diese Problematik hingewiesen werden - gegebenenfalls empfangene Mailbomben bekanntgegeben werden -, ohne daß detailiert auf die technische Realisierung solcher Anschlagsmöglichkeiten hingewiesen werden soll.
Thorsten Kitz stellte im Auftrag des Sysop der Maus MK ein alternatives Konzept zur Versorgung des MausNet mit Usenet-News vor. Die Maus MK bezieht seit einiger Zeit ihre News über einen Anbieter aus Großbritannien. Dies sei, auch unter Zunahme der Telefonrechnung, immer noch billiger als jetzt über das IN. Den übrigen Sysops erschien das etwas seltsam. Konkrete Zahlen und Kostenaufschlüsselungen konnte Thorsten leider nicht vorlegen.
Ein weiteres Problem tat sich in der anschließenden Diskussion auf: Wenn die Mails über UK laufen, so mag das zwar für das MausNet günstiger sein, für den Absender aus einem anderen Netz könnte es so aber teurer werden. Und ob jemand Verständnis dafür hat, daß eine Mail von einem Rechner zu einem anderen Rechner im gleichen Land, möglicherweise sogar in der gleichen Stadt, auf einmal über Großbritannien geroutet wird, und ihm so eventuell sogar Mehrkosten verursacht, wurde angezweifelt. Der Vertreter der Maus MK war anderer Meinung und meinte, MK werde auch weiterhin seinen Bedarf in Großbritannien decken.
Jörg Stattaus versuchte, die wesentlichen neuen Features, die zur MAUS 9 gehören werden, aufzuzählen. Konkrete Aussagen zur Realisierung lassen sich nicht machen, da dies vor allem eine Frage des Zeitplans von Kai und Jörg ist. Ziemlich sicher ist nur, daß die MAUS 9 im Laufe des Jahres 93 kommen wird. Die Features:
Neuer Header in den Mails: im Header werden die jetzigen und neue, zusätzliche Felder in einer "tokenized" Form mit einem Kennerbyte, gefolgt von einem Pascal-String (maximal 255 Zeichen) stehen. Dieses Format ist leicht und schnell auszuwerten und erweiterungsfähig.
Längere MsgIds: statt den jetzigen internen 3-Byte langen MsgIds (1 Byte Box-Nummer, 1 Word Msg-Nummer) werden auch intern die String-Ids verwendet, die jetzt nur als MId-Zeile durchgereicht werden. Dadurch lassen sich UseNet- und andere MsgIds direkt übernehmen und so wird ein vernünftiger Dupe-Check und Kommentar-Link ermöglicht.
Längere Gruppennamen: bis 80 Zeichen. Gruppennamen anderer Netze sollten möglichst unverändert übernommen werden. Netzweit gelten dann einheitliche Gruppennamen.
Erhöhung der Gruppenanzahl auf 2048: Platz für neue Netzgruppen, mehr Importe und regionale Gruppen
Crossposting: eine Mail in mehreren Gruppen: dieselbe Message einmal in der Messagebase, aber durch Angabe einer Gruppenliste mehreren Gruppen zugehörig. Unklarheit besteht noch über einige Details (in welche Gruppe geht ein Kommentar).
FollowUp und FollowUpTo: gruppenübergreifende Kommentar-Verkettung wird in der MAUS unterstützt. Eine Angabe FollowUpTo (deutscher Name wird noch gesucht) soll Kommentare defaultmäßig in eine andere Gruppe lenken.
MausTausch nach altem und neuem Standard: wenn das FrontEnd dies anfordert, kann ein Level-2-MT durchgeführt werden, der durch entsprechende Erweiterungen erst die neuen Features komplett unterstützt. Aus Kompatibilitätsgründen soll weiterhin das alte Format unterstützt werden.
Message-Index größer: statt 21.800 sollen 65.536 Msgs unterstützt werden. - _ein_ Feld für den kompletten Benutzernamen: bis zu 64 Zeichen statt Trennung in Vor- und Nachname. Dadurch können "von", "van" und mehrere Vornamen richtig eingetragen werden. Schwierigkeiten wird die Abkürzungs- routine (EK oder EvK für Erwin van Kann) machen, aber Kai zeigte Zuversicht, dieses Problem lösen zu können.
Geburtsdatum mit doppelter Abfrage (nach Datum oder nach Alter): wer will, kann das Geburtsdatum eintragen, damit er nicht jährlich Änderungen vornehmen muß. Wer dies nicht will, kann alternativ das Alter oder wie gehabt nichts angeben.
Wünsche von Sysops, die in der MAUS 9 eingebaut werden sollen:
bei (K)ommunikation mit Sysop eigenen Chatter einbinden
Bei Aufruf des Users kommt der Chat direkt (geht laut Kai nicht?)
Pieper beim User-Login/-out abstellbar
Alt + F2 (Spannermodus) auf Dauerbetrieb einstellbar
Eine Multiport-MAUS, die mehreren Usern gleichzeitig Zugang bietet, ist eine viel gewünschte Sache. OS/2 stellt eine Betriebssystem-Grundlage dar, die dies ermöglichen würde. Aber zur Realisierung wird ein Turbo-Pascal für OS/2 gebraucht, auf das noch gewartet werden muß. Als Vorbereitung werden aber Multiuser-fähige Datenroutinen schon in die MAUS 9 mit eingebunden. Vor Fertigstellung der MAUS 9 ist an eine "MUM" (Multiuser-MAUS) nicht zu denken.
Soll nach Jörg Stattaus nicht verbessert werden, da das Online lesen und schreiben nicht gefördert werden soll. Stattdessen soll der MausTausch benutzt werden. Allgemeine Zustimmung.
Immer wieder kommen Fragen von Usern und Sysops, welche MAUS-Gruppen wo mit welchen Fremdnetzen vernetzt sind. Die immer komplexer werdende Netzlandschaft erschwert die Übersicht erheblich, so daß sogar viele Sysops nicht mehr genau über alle Details Bescheid wissen (können). Der Vorschlag wurde gemacht, alle Vernetzungen zentral zu verwalten, so daß zumindest eine Institution die Informationen sammelt und verfügbar hält.
Der zu wählende "Netzgruppenkoordinator" sollte als weitere Aufgabe die Vergabe neuer Netzgruppennummern haben. Bisher wurde diese Aufgabe zentral von Jörg Stattaus in Aachen übernommen. Mit dem entsprechenden Utility könnten aber von einer anderen Maus aus neue Netzgruppen eingerichtet werden - der Vorgang ist also nicht technisch an die Maus AC gebunden.
In einer spektakulären Kampfabstimmung setzte sich Edgar Rosenboom @ UN ganz knapp gegen seinen einzigen Gegankandidaten Rene Deutscher @ HH2 als NeGruKo "Netz-Eddie" durch: Edgar bekam alle Stimmen.
Die bereits existierende Regelung zur Einführung neuer Netzgruppen wurde bezüglich ihrer Praxistauglichkeit im "größer gewordenen MausNet" diskutiert. Die bisher geltende Regelung, unabhängig von der Natur der neuen Gruppe (MausNet-intern oder Import, Volumen der Importgruppe) einheitlich 10 Interessenten als Bedingung festzulegen, wurde vielfach als unbefriedigend empfunden (sowohl von User- als auch von Sysop-Seite). Andere Alternativen wurden diskutiert; u.a. Abhängigkeit der nötigen Pro-Stimmen von der Anzahl der Mäuse im Netz.
Beschlossen wurde schließlich, daß für die Einrichtung einer reinen MausNet-internen Gruppe weiterhin 10 Stimmen ausreichen sollen, während für den Import einer Fremdnetz-Gruppe 20 Interessenten gefunden werden müssen; jeweils unter Bedingung, daß kein "erheblicher Widerspruch" vorliegt.
Nach langer und heftiger Diskussion, ob neue Sysops vorher ein halbes Jahr User gewesen sein müssen (Frank Tegtmeyer @ HRO), oder ob im Einzelfall und nach dem subjektiven Eindruck entschieden werden soll (Wolfgang "Bin gleich fertig" Walter @ KA), wurde folgender Beschluß gefaßt:
Beschluß:
Personaldebatte unter Ausschluß des Aspiranten in SYSOPS
Personaldebatte MIT dem Aspiranten in SYSOPS.NEU
Keine Pflicht-User-gewesen-sein-Zeiten für neue Sysops
Gerade im Hinblick auf die Ausdehnung des MausNet im Osten, sollten die Kriterien dort nicht ganz so eng ausgelegt werden. So sollte Firmenunterstützung kein Hinderungsgrund sein, wenn sichergestellt wird, daß keine netzweite Werbung erfolgt.
Am Rande dieser Diskussion war ein interessantes Experiment in angewandter Unlogik zu sehen. Es sollte abgestimmt werden, OB, und wenn ja, welche Sysop-Gruppen Sysop-Aspiranten bekommen dürften.
Abstimmung:
Es dürfen prinzipiell Sysop-Gruppen freigeschaltet werden.
Sysopabstimmung: keine klaren Mehrheiten
Betreiberabstimmung: Mehrheit für das Freischalten
Abstimmung:
Welche Gruppen dürfen freigeschaltet werden?
Sysopabstimmung: Für keine Gruppe fand sich eine Mehrheit.
Dieses unlogische Ergebnis (es dürfen Sysop-Gruppen freigeschaltet werden, aber es darf keine spezielle Gruppe freigeschaltet werden) läßt sich nur auf einen Fehler bei der Abstimmung zurückführen.
$ setzen mit MauTau: da Marco nicht anwesend war, und das Programm MauTau sowieso nicht weiterentwickelt wird (laut Frank Baschin), und da Marco keine Zeit mehr hat, erübrigte sich die Diskussion. Kai meinte sowieso, daß diese Option nicht geplant sei.
Grundsätzlich sind die Frontend-Programmierer für das reibungslose Zusammenspiel von MAUS und Frontend verantwortlich. Als grundlegendes Maus-Feature wird hierbei die Kommentarverkettung angesehen.
Für Erweiterungen des MausTausch-Formates ist Kai Henningsen @ MS zuständig. Was wohl in absehbarer Zeit kommen wird, ist der Up- und Download von Files per MausTausch.
Ein Interessent aus Leipzig hat sich bei Frank Tegtmeyer @ HRO wegen einer MAUS erkundigt. Diese würde von einer Firma betrieben werden, und der Interessent würde in der MAUS werben wollen. Das gab Anlaß zur Diskussion über kommerzielle Werbung im MausNet. Es wurde beschlossen, daß Werbung in Netzgruppen nicht gestattet wird. In lokalen Gruppen kann beliebig geworben werden. Außerdem darf eine Firmen-MAUS zusätzlich im MTITEL.DAT einen Hinweis auf die Betreiberfirma führen (siehe Beispiel MAUS GG [Anmerkung: jetzt MTK] von Atari).
Zur Wahl eines stellvertretenden Abstimmungsleiters stellten sich die 4 Kandidaten Florian Helm @ BN, Sam Jost @ FL2, Mick Schmidt @ HB und Stefan Rupp @ AC2. Gewählt wurde Sam Jost @ FL2.
Beschluß: Mindestens ein Sysop jeder Maus *MUß* SYSOP-INFO lesen. Daraus folgt, daß SYSOP-INFO auch eine Pflichtgruppe für die Maus ist. Zudem sollte mindestens ein Sysop auch SYSOPS lesen (kein Beschluß).
Ja: 21 Nein: 24
Beschluß: Jede Maus *MUSS* die Gruppen MAUS*.* führen! Ausnahme: Gruppe MAUSBAU nur für Mäuse, in denen Maus-Entwickler sitzen. Und MAUSRING nur für die am Ring teilnehmenden Systeme.
Zur Zeit sind also als Pflichtprogramm zu führen:
MAUS MAUS.INFO MAUS.GRP MAUS.DOKU
Dringend empfohlen für am IN teilnehmende Mäuse:
DE.NEWUSE DE.ORG.IN
Für das nächste Sysoptreffen haben sich sowohl die Sysops aus UN als auch die Stuttgarter angeboten. Rosi Rosenboom hat dann ihr Angebot zurück- gezogen, da zur Vorbereitung nicht genügend Möglichkeiten bestünden. Die Stuttgarter sind aber gerne bereit und haben als Termin den Herbst '93 vor Semesteranfang ins Auge gefaßt. Es gab allseits Lobbekundungen.
Kritisiert wurde die kommerzielle Werbung in der BIETE-Gruppe. Diese Gruppe ist aber ein Z-Netz-Import und somit muß sich das Z-Netz darum kümmern. Kommerzielle Werbung ist dort auch nicht erlaubt, bzw. kostet DM 50,- in einer Kommerzkasse bei Kerstin@ttb.zer.
Im MausNet gilt, daß keine Werbung im Netz erwünscht ist. Dies gilt sowohl für Netzgruppen, als auch für das lokale MAUS-Erscheinungsbild. Ganzseitige Werbe-Titelseiten schaden dem MAUS-Image. Erlaubt ist eine Zeile im Header oder Footer und ein Infofile unter (I)nfo (K)ommerzielles.
Insgesamt 60 Teilnehmer:
@AC Stattaus, Jörg @KA Walter,Wolfgang Stürmer, Matthias @AC2 Keukert, Michael Rupp, Stefan @KI Krüger, Nils-Henner Meyer, Heiko @AC3 Leutloff, Christian Wickinghoff, Claus @M4 Hohendorf, Christian @BB Frey, Ulrich @ME Eschenbach,Georg Henne, Jörg @MK Kitz, Thorsten @BI Keinhorst, Stefan @MS Henningsen, Kai @BL Faigle, Franz @PB Ohse, Uwe Baumgart, Frank @BN Lanzki, Jürgen Helm, Florian @HG Lenz, Ralf @DU Abele, Klaus @HH Labeit, Harald Schroers, Georg Przetak, Michael @F Stille, Sevo @HH2 Deutscher, Rene Woltmann, Detlef Fritze, Markus @FL Barth, Jens-Peter @HH3 Landgrebe, Gunnar Dawartz, Jörn Heier, Thomas Albrecht, Oliver Horst, Ingo @HRO Tegtmeyer, Frank Standtke, Maik Tegtmeyer, Petra Bieschewski, Stefan @HB Schmidt, Mick Brinkmann, Olav @KA Walter,Wolfgang Voelker, Wolfgang Stürmer, Matthias @HG Lenz, Ralf @KI Krüger, Nils-Henner Meyer, Heiko @HH Labeit, Harald Przetak, Michael @M4 Hohendorf, Christian @HH2 Deutscher, Rene @ME Eschenbach,Georg Fritze, Markus @MK Kitz, Thorsten @HH3 Landgrebe, Gunnar Heier, Thomas @MS Henningsen, Kai @HRO Tegtmeyer, Frank @PB Ohse, Uwe Tegtmeyer, Petra Baumgart, Frank Bieschewski, Stefan
Ende:
Wenn sich innerhalb einer Woche kein begründeter Widerspruch regt, gilt dieses Protokoll.
- Was ist der langen Rede kurzer Sinn? (F. Schiller)
Protokoll des MausNet-Sysop-Treffens vom 9.10 bis 11.10.1992 in Flensburg-Glücksburg.
Kurzfassung mit wichtigen Beschlüssen für MAUS.INFO (vollständiges Protokoll in MAUS-DOKU):
Tagesordungspunkte: 1.0. Gateways (und deren Zukunft) 1.1. Gateway Zerberus 1.2. Gateway UseNet 1.3. Gateway HB (Probleme, Kosten, UUE's) 1.4. Gateway Genie 1.5. lokale Gateways 2.0. IN 2.1. Kosten,Kostensenkung 2.2. Kosten u. Schutz bei Anschlägen von Hackern 2.3. Alternativen zum IN 3.0. MAUS 3.1. MAUS 9 wann, was kann sie? 3.2. Multiport MAUS 3.3. Online Editor 3.4. Netzstruktur und Topologien 3.5. neue Regelung für Netzgruppeneinrichtung 3.6. neue Regelung für neue Sysops (Aufnahmekriterien) 3.7. $ per MauTau setzen können (Erleichterung der Wartung) 3.8. MausTauschformat und Erweiterung 3.9. Verbreitung der MAUS im Osten 3.10. Wahl des Stellvertreters des AL 4.0 SYSOPS 4.1. welche Pflichtgruppen für Sysops? 4.2. soll eine Gruppe SYSOP-LALL/LITE eingerichtet werden? 4.3. Pflichtgruppen jeder Maus 4.4. nächstes Treffen wo und wer? 4.5. kommerzielle Werbung in der Maus
1.2 & 1.3 Gateway UseNet in HB
Die enstandenen Kosten für PM-Massen werden direkt vom IN-Konto der jeweiligen Heimatmäuse der User abgebucht, der Sysop muß sich dann mit seinem User auseinandersetzen, um das Geld wieder reinzubekommen. Zur Not kann ja der $ gekürzt werden. Zusammen mit der Abbuchungsmeldung an den Sysop geht eine Benachrichtigung an den User raus, daß er sich die Sachen, die für ihn angekommen sind, innerhalb der nächsten 14 Tage in HB abholen kann, danach werden sie gelöscht.
[Anm. zum letzgenannten Verfahren: dieses ist inzwischen, zum Zeitpunkt der neuen, besseren Ausformulierung des Protokolls schon wieder geändert. Die aktuelle Regelung wird regelmäßig in MAUS.INFO geposted und kann natürlich vom lokalen Sysop oder von <info maus-de @ HB> erfragt werden.] Dann wurde diskutiert, was als nicht erlaubte PM-Massen gilt: nur Files, die per UU, AtoB oder sonstwie übertragen werden, oder auch beliebige PMs.
>Abstimmung: deutliche Mehrheit für Inhalt egal, PM-Massen ab x KB. Wie soll die Grenze für PM-Massen aussehen? 64KB, 48KB, 32KB?
>Abstimmung unentschieden zwischen 64K und 48K.
>Betreiberabstimmung ergab dann 11 Stimmen für 64K, Rest für 48K. [48K]
3.4 Netzstruktur und Netztopologien
Der zu wählende "Netzgruppenkoordinator" soll als Aufgabe die Vergabe neuer Netzgruppennummern haben. Zusätzlich soll er Informationen über den Vernetzungsstatus von Netzgruppen an den Gateways (reiner Import, gleichberechtigte Vernetzung) sammeln. Edgar Rosenboom @ UN wurde ohne Gegenstimme gewählt.
3.5 neue Regelung für Netzgruppeneinrichtung
Beschlossen wurde, daß für die Einrichtung einer reinen MausNet-internen Gruppe weiterhin 10 Stimmen ausreichen sollen, während für den Import einer Fremdnetz-Gruppe 20 Interessenten gefunden werden müssen; jeweils unter Bedingung, daß kein "erheblicher Widerspruch" vorliegt.
3.10 Wahl eines stellvertretenden Abstimmungsleiters
Als stellvertretender Abstimmungsleiter wurde Sam Jost @ FL2 gewählt.
4.3. Pflichtgruppen jeder Maus:
Beschluß: Jede Maus *MUSS* die Gruppen MAUS*.* führen:
MAUS MAUS.INFO MAUS.GRP MAUS.DOKU
Dringend empfohlen für am IN teilnehmende Mäuse:
DE NEWUSE DE ORG IN
4.5. kommerzielle Werbung in der Maus:
Im MausNet gilt, daß keine Werbung im Netz erwünscht ist. Dies gilt sowohl für Netzgruppen, als auch für das lokale MAUS-Erscheinungsbild. Ganzseitige Werbe-Titelseiten schaden dem MAUS-Image. Erlaubt ist eine Zeile im Header oder Footer und ein Infofile unter (I)nfo (K)ommerzielles.
Protokoll des MausNet-Sysoptreffens vom 07.10. - 10.10.1993 in Stuttgart.
Tagesordnungspunkte: Zu Beginn schlug Jörg Henne (der die Diskussion leitete) vor, Abstimmungen am Sonntag en Block durchzuführen. Dieser Vorschlag wurde mehrheitlich abgelehnt. Alle Abstimmungen erfolgten im Anschluß an die Diskussion.
Gereon Steffens gibt einen groben Überblick über den bisherigen Stand der Planungen zur Maus 9. Mit dieser sollen 65535 Gruppen und 65535 Mäuse realisiert werden. Die "Maus-To-Maus-Gates" fallen weg. Stattdessen sollen regionale Gruppen über ein Crashnetz direkt zwischen den beteiligten Mäusen ausgetauscht werden können. Die Baumstruktur (das heutige Nachtnetz) bleibt erhalten. Hardwarevoraussetzungen werden steigen, da Maus 9 DPMI-fähig werden soll. Es darf keine Rolle mehr spielen, ob für die Userdatei 1 KB oder 18-20 KB pro User benötigt werden. Mit Maus 9 wird ein MausTausch Level 1 (O-Ton Gereon: "Was auch immer das sein mag") eingeführt. Die Umstellung von Maus 7 auf Maus 9 wird eine Stichtagumstellung, ähnlich der Postleidzahlenumstellung (O-Ton Gereon: "Nicht fünf ist Trümpf, sondern drei ist Brei oder so"). Für die Umstellung werden zur Konvertierung der User- und Message-Dateien Hilfsprogramme geschrieben. Das sind bisher alles nur Ideen.
Zur Maus 7 kündigte Gereon einige Änderungen an. Es wird in Zukunft möglich sein, das MausMeter per MausTausch abzurufen. Diese Version wird frühestens in 2 Wochen freigegeben, da dieses Feature noch nicht von den Frontends unterstützt wird. Diese Infofiles benötigen keine CRC-Berechnung, da sie bei jedem Abruf verschieden sein werden. Für Remote-SysOps ist es dann auch möglich, das MCALL.LOG per MausTausch abzurufen. Gereon kündigte auch an, daß er für vernünftige Anregungen jederzeit offen ist, solange es sich nicht um irgendwelche obskuren Vorschläge handelt (O-Ton Gereon: "Nicht wahr, Wolfgang?").
Die Mausprogrammierer haben sich bereits Gedanken gemacht, was nach Maus 9 kommen soll. Der Hintergrund ist der, daß für Maus 9 nicht irgendwelche Datenstrukturen festgelegt werden, die in 2 Jahren wieder umgeworfen werden müssen. Diese "Maus 10" soll eine Multi-Port-Maus werden, wodurch ein Multitasking-Betriebsystem (z. B. OS/2) vorausgesetzt wird. Hier wurde auch daran gedacht, DR-DOS 7.0 als Betriebsystem zu verwenden (O-Ton Gereon: "Bitte nicht schlagen"), wobei eine Art Client-Server-Struktur Verwendung finden könnte.
Jörg Stattaus äußerte sich skeptisch, was die Fertigstellung der Maus 9 angeht. Bisher wurde davon ausgegangen, daß die Maus 9 im Jahre 1993 fertiggestellt wird (siehe auch Flensburger Protokoll 3.1), was aus Zeitmangel der Programmierer nicht möglich war. Jörg stellte die Frage, ob jemand in "C" eine neue Maus programmieren möchte, da eine Portierung nicht sinnvoll ist. Die aktuelle Maus soll dabei als Pflichtenheft angesehen werden. Diese Maus soll eine Alternative zur Maus 9 sein, was nicht heißen soll, daß Maus 9 begraben wird.
Fritz Elfert gab darauf bekannt, daß eine Mailingliste existiert, in der bereits Grundüberlegungen zu einer Unix-Maus (UMaus) angestellt wurden. Evtl. kann Ende 1993 in die Programmierung eingestiegen werden. Mitte des Jahres wurden die ersten Planungen dazu begonnen, die sich mit den Vorstellungen von Gereon zur Maus 10 decken. Diese Maus soll auf jeden Fall netzwerkfähig werden. Allerdings befindet sich diese Maus noch im Planungsstadium. Jörg, Kai und Gereon gaben bekannt, daß sie diese Maus unterstützen werden. Sie werden alle Informationen (insbesondere zu den Datenstrukturen) zur Maus herausgeben. Nach Jörg's Aussagen können beide Seiten davon profitieren.
Frank Baumgart gab abschließend noch einen kurzen Überblick über den derzeitigen Stand der Quark-Soft, die inzwischen komplett von BASIC nach C portiert wurde. Die Quark-II wird "in der nächsten Woche" wieder in die Beta-Phase gehen. Es gibt nach Franks Worten bereits Überlegungen zu einer Quark-III, die ebenfalls in C programmiert werden soll und so portabel wie möglich gehalten werden soll, damit sie auf alle Plattformen (TOS, Linux) leicht portiert werden kann. Diese Quark-Version wird auch multiport-fähig sein.
Jörg Henne gab einen kurzen Überblick zum Thema ISDN, das durch die ansteigenden Datenmengen interessanter wird. Auf Nachfrage, wer sich bisher damit beschäftigt hat, meldete sich Klaus Abele, der auf die dabei auftretenden Probleme hinwies. Mit dem MausNet ist bisher kein Mischbetrieb (analog/ISDN) möglich, da von der Software derzeit nur eine Schnittstelle unterstützt wird. Eine einfache Lösung wäre ein Kombigerät, welches automatisch zwischen Modem- und ISDN-Anruf unterscheiden kann. Von Fritz Elfert kam daraufhin der Vorschlag ins MausNet einzubauen, daß in der MAUSNET.CFG für jede Maus der Port (Modem/ISDN) einzeln konfiguriert werden kann. Kai warf daraufhin ein, daß er noch keinerlei ISDN-Erfahrung habe, aber die Anregung notiert ist. Von Klaus kam noch der Vorschlag, daß eine Multitasking-Maus das Netz als eigenen Task abwickeln sollte, damit die Box für diese Zeit nicht heruntergefahren werden muß. Klaus erläuterte abschließend noch kurz die Kosten, die bei einer ISDN-Anbindung entstehen würden (Grundgebühr, Hardware- und Anschlußkosten).
Zunächst wurde nochmal kurz auf Maus 9 eingegangen. Jörg Stattaus erklärte, daß Gruppennamen maximal 255 Byte lang werden können. Aufgrund der langen Gruppennamen sind Gruppenhierarchien möglich. Was es an softwaremäßiger Unterstützung dafür geben wird, ist unklar. Die Gruppenselektion wird wahrscheinlich so aussehen, daß die Gruppen durch "taggen" (wie derzeit im Programmteil) ausgewählt werden. Von Kai kam der Hinweis, daß der hierarchische Gruppenaufbau eine administrative Angelegenheit sei und nicht Sache der Programmierer. Auf Anfragen zur Messagegröße bzw. Anzahl der Nachrichten erklärte Jörg, daß eine Messagegröße von 64 KByte geplant sei. Diese Größe wird aber konfigurierbar sein. Die Anzahl der Nachrichten wird eine 32-Bit-Zahl sein, also theoretisch ca. 2-4 Giga Nachrichten. Kai wies dann noch darauf hin, daß die Nachrichten ruhig theoretisch länger als 64 KByte werden können, nur der Header dürfe nicht länger als 64 KByte werden. Für jede Header-Zeile sind maximal 255 Bytes vorgesehen. (O-Ton Kai:) "Das technische Limit muß nicht notwendigerweise das administrative Limit sein"
Zur Problematik "einheitliche Gruppennamen im MausNet" wies Erwin Sienknecht darauf hin, daß Frontends keine Änderung des Gruppennamens erkennen, was bei der Namensänderung bestehender Gruppen zu Problemen führen würde. Da dies ein technisches Problem zwischen der Maus und den Frontends ist, wurden u. a. Steuermessages zur Gruppenumbenennung vorgeschlagen. Da dieses Thema bisher noch nicht zu einem Konsens in TAUSCHBAU geführt hat, wird es eine technische Lösung wohl so schnell nicht geben. Es stellte sich nun die Frage, ob eine "politische" Lösung gefunden werden sollte, oder ob die Gruppennamen wie bisher bleiben sollten. Frauke Cremer wies auf die Problematik der Quarks hin, die ihre Nachrichten bekanntlich per MausTausch bekommen. Frauke sagte, daß es ärgerlich sei, wenn eine neue Netzgruppe eingerichtet wird und in der Servermaus einen anderen Namen als den Netznamen bekommt. Der Quark-SysOp kann ja nur den Netznamen wissen, so daß die Quark bei abweichenden Gruppennamen die Fehlermeldung bekommt, daß es die bestellte Gruppe nicht gibt. Die folgende Abstimmung ergab eine deutliche Mehrheit zur Vereinheitlichung der Gruppennamen. Als Termin wurde der 1. November 1993 festgelegt. Michael Keukert brachte daraufhin den Einwand, daß manche Netzgruppennamen nicht korrekt seien (Beispiel: Die MausNet-Gruppe heißt CT, die Zeitschrift aber C'T). Es wurde per Akklamation beschlossen, daß Michael Keukert erstmal eine Vorschlagsliste erarbeitet. Anschliessend sollen die Namen in den betreffenden Gruppen mit einfacher Mehrheit abgestimmt werden. Gereon machte abschliessend noch den Vorschlag, in die Maus-Software etwas einzubauen, was diese Umstellung für die Frontends einfacher machen wird. Dieses Feature steht nach seinen Aussagen ganz oben auf der "Maus-to-do-Liste".
Jörg Henne stellt die Frage, ob wir ein einheitliches Logo wollen, wie es z. B. das Z-Netz hat. Von Kai kommt daraufhin der Vorschlag, ein Logo auf ASCII-Basis zu erstellen, da die einzige Ecke, wo ein Logo häufiger und wiedererkennbar auftauchen würde, das Netz wäre. Wolfgang Walter gibt zu bedenken, daß es derzeit verschiedene Logos gibt (Eissing, Lichti, PMaus) und daß Mäuse, die sich für ein abweichendes Logo entschieden haben um ihre Identität gebracht würden. Frauke vertrat den gleichen Standpunkt, da das Thema überflüssig sei. Wir sind keine Firma, sondern ein privates Hobby-Netz. Es gibt jetzt Maus-Pads, T-Shirts, und demnächst vielleicht auch noch Kugelschreiber. Die folgende Abstimmung ergab eine deutliche Mehrheit gegen ein einheitliches Logo.
Jörg Henne schnitt das Thema um die Rainbow BBS (Fido) an, deren SyOp von der Firma Rainbow verklagt wurde, da diese Firma den Namen "Rainbow" hat schützen lassen. Lutz Gruenenwald gab daraufhin einen kurzen Bericht zum Ablauf und Ausgang des Prozeßes. Im Fido gab es kürzlich Aufregung, weil ein User den Begriff "Fido" schützen ließ. Niemand weiß, was er damit bezwecken will. Um nun zu verhindern, daß mit "MausNet" etwas derartiges geschieht und den Mäusen die Benutzung dieses Begriffes untersagt wird, wurde der Vorschlag gemacht, daß sich die SysOps den Begriff MausNet schützen lassen. Es wurde auch vorgeschlagen die Begriffe "Maus" und "MausTausch" zu schützen, aber das wurde als aussichtslos aufgegeben. Jörg Stattaus brachte den Einwand, daß "Maus" ein normales Wort der deutschen Sprache ist und daher nicht geschützt werden kann. Dieses wurde von Frauke nochmal bestätigt. Stefan Rupp und Lutz Gruenenwald gaben nun einen Überblick über die Vorgehensweise und die Kosten, die dabei entstehen würden. Der Antrag kostet DM 300,- und weitere DM 60,- pro Sparte. Bei Ablehnung werden DM 150,- erstattet. Das sind alles einmalige Zahlungen. Nach einer längeren Diskussion, ob "Maus" und/oder "MausNet" geschützt werden sollen, und ob der die Eintragung als Warenzeichen sinnvoll sei, machte Georg Bauer den Vorschlag den Versuch mit "MausNet" zu starten. Wenn wir MausNet nicht schützen können, kann es niemand. Und wenn es doch jemand schafft, haben wir es schriftlich, daß es gar nicht geht, bzw. wir es schon früher versucht haben und damit die älteren Rechte. Jörg Henne rief nun zur Abstimmung auf, den Begriff "Maus", "MausNet" oder keines von beiden schützen zu lassen. Die Abstimmung ergab eine knappe Mehrheit für "MausNet". Es wurden Stimmen laut, es trotzdem auch mit "Maus" zu versuchen, worauf die Abstimmung wiederholt wurde. Nun wurde abgestimmt, ob wir "Maus", "MausNet" oder beide Begriffe schützen lassen sollen. Die Abstimmung ergab eine eindeutige Mehrheit, es nur mit "MausNet" zu versuchen. Jede(r) Anwesende zahlte dafür DM 3,- um die Eintragung zu finanzieren. Im Falle einer Ablehnung sollen die erstatteten DM 150,- dem Netz zugute kommen (z. B. "Fonds für notleidende Mäuse", IN-Konto, oe. ae.)
Die Problematik der Gruppe SYSOPS war ja allen Anwesenden bekannt und braucht daher an dieser Stelle nicht wiederholt zu werden.
Von Florian Helm kam der Vorschlag, eine SysOp-Gruppe einzurichten, in der allerdings nur Betreiber schreiben dürfen. Gereon wies darauf hin, dass die Gruppe von ca. 5 Personen vollgemüllt wurde, wodurch eine Mengenbeschränkung sinnvoller sei als eine Betreibergruppe. Michael Keukert wandte ein, daß Mengen-Beschränkungen technisch derzeit nicht möglich, und von daher schwer durchzusetzen sind. Jörg Stattaus schlug vor, da befristete Schreibsperren gebraucht werden, evtl. mal über eine moderierte Gruppe SYSOPS nachzudenken. Michael zeigte dazu die derzeit üblichen Arten der Moderation (Fido: Moderator meckert User an, die Gruppen zumüllen und können diesen Schreibzugriff entziehen. UseNet: Mails werden als PM an den Moderator geschickt, der die Nachrichten dann in die Gruppe postet) auf. Georg Bauer brachte zu Florians Vorschlag, eine Betreibergruppe einzurichten, den Einwand, daß Betreiber als Moderatoren ihrer Co-SysOps unbrauchbar sind, da die letzten Diskussionen in SYSOPS gezeigt haben daß die Fronten zwischen den Mäusen und nicht zwischen den SysOps bestanden. Eine Betreibergruppe würde nichts ändern, da zwar weniger Namen zu lesen sind, aber immer noch die gleichen Argumente wiederholt werden.
Das bereits vor Wochen in SYSOPS angeregte Abstimmungsleiter-Team (AL-Team), könnte die Rolle eines Diskussionsleiter-Teams (DL-Team) übernehmen, schlug Jörg vor. Sevo bekräftigte dies, da Einzelpersonen als Abstimmungsleiter - wie die Erfahrung der letzten Jahre gezeigt hat - zu schnell demontiert werden. Frauke schlug vor, daß das DL-Team aus drei und nicht aus fünf Personen bestehen sollte, da unter 3 Leuten eher eine Einigung möglich sei als unter 5 Leuten. Michael regte an, für Diskussionen des DL-Teams eine eigene Gruppe einzurichten, die zwar von allen SysOps gelesen, aber nur vom DL-Team beschrieben werden kann.
Da schnell mal ein Mitglied des DL-Teams ausfallen kann (Klausur, Urlaub), regte Frauke an, drei Stellvertreter zu wählen (für jedes Mitglied einen). Kai schlug vor, daß die Mitglieder des DL-Teams aus verschiedenen Mäusen kommen sollten, da (wie schon von Georg festgestellt) die Fronten zwischen verschiedenen Boxen, aber nicht innerhalb einer Maus existierten. Jörg Henne griff nochmal den Vorschlag von Jörg Stattaus auf, das DL-Team solle in Personalunion mit dem AL-Team stehen.
Im Laufe der Diskussion wurde sich darauf geeinigt, daß dem DL-Team die Kompetenz eingeräumt werden soll, "totgelaufene" Diskussionen in SYSOPS für beendet zu erklären und evtl. SysOps, die sich daran nicht halten, für eine bestimmte Zeit aus der Gruppe SYSOPS auszuschliessen. Jörg Stattaus stellte heraus, daß die Schreibsperre durch die Leserschaft der Gruppe SYSOPS zu legitimieren ist. Sevo machte darauf aufmerksam, daß der Abstimmungszeitraum kürzer gemacht werden sollten. Auf ein Abstimmungsergebnis zu einer Schreibsperre kann man nicht ein paar Wochen warten. Da das AL-Team mit der Gruppe SYSOPS und dem Lesen der Gruppen MAUS.INFO und MAUS überlastet wäre, schlug Michael Keukert vor, daß das AL-Team Abstimmungen über Gruppeneinrichtungen und Gruppenex- und Importe an User delegieren können sollte.
Die folgende Abstimmung, ob wir "eine Gruppe von Leuten, die auf die Gruppe SYSOPS irgendwie einwirken können" haben wollen, ergab eine deutliche Mehrheit - bei einer Gegenstimme - zugunsten eines DL-Teams.
Die Abstimmung über die Zusammensetzung des DL-Teams ergab 16 Stimmen für den Vorschlag, daß die Mitglieder des DL-Teams aus verschiedenen Orten kommen sollen und 54 Stimmen für den Vorschlag, daß die Mitglieder aus 3 verschiedenen Mäusen kommen müssen.
Bei den folgenden Abstimmungen ging es nun um die Kompetenzen des DL-Teams. Der Vorschlag "Das DL-Team hat die Kompetenz, ein Thema abzuwürgen" wurde mit einer Gegenstimme und fünf Enthaltungen angenommen. Der Vorschlag "Das DL-Team kann gegenüber einem Schreiber in der Gruppe SYSOPS eine Verwarnung aussprechen" wurde mit fünf Gegenstimmen und 4 Enthaltungen angenommen.
Diese Verwarnung kann ausgesprochen werden, wenn ein SysOp sich nicht an die Bestimmung hält, daß ein Thema beendet ist, oder wenn er rumflamed.
Ebenfalls eine deutliche Mehrheit fand der Vorschlag, daß der SysOp, über den der CFV läuft, während des CFV Schreibverbot hat. Mit deutlicher Mehrheit abgelehnt wurde der Vorschlag, daß während ein CFV gegen einen SysOp läuft (wenn dieser zu einem Thema geflamed hat), das Thema für alle in der Gruppe SYSOPS tabu ist. Dafür fand sich eine deutliche Mehrheit dafür, daß über den CFV nicht diskutiert werden darf, während dieser läuft.
Eine weitere Abstimmung über die Kompetenzen des DL-Teams ergab bei drei Gegenstimmen und sechs Enthaltungen, daß das DL-Team die Befugnis hat, gegen einen SysOp ein Schreibverbot zu verhängen. Dieses muß durch einen CFV durch die SysOps legitimiert werden. Das Schreibverbot gilt defaultmäßig für 14 Tage und das Ergebnis des CFV muß drei Tage nach posten des CFV veröffentlicht werden. Sonderregelungen für den Wiederholungsfall müssen seperat bestimmt werden. Die anschliessende Abstimmung über die Verlängerung der Abstimmung von drei auf fünf Tage wurde bei vier Pro-Stimmen und 14 Enthaltungen abgelehnt.
Der Vorschlag, den Abstimmungsleiter durch das "3+3 AL-Team" zu ersetzten, wurde bei fünf Gegenstimmen und sechs Enthaltungen angenommen. Bei fünf Gegenstimmen und 12 Enthaltungen wurde Personalunion zwischen dem DL-Team und dem AL-Team beschlossen.
Die Amtszeit des AL-Teams wurde bei drei Gegenstimmen und 24 Enthaltungen auf ein halbes Jahr festgesetzt. Falls Proteste gegen das AL-Team aufkommen sollten, so finden die Regeln zur Abwahl des Abstimmungsleiters aus dem Mosbacher Protokoll für jedes einzelne AL-Team-Mitglied Anwendung. Dieses wurde ohne Gegenstimmen, bei 10 Enthaltungen beschlossen. Der alte Abstimmungsleiter (bzw. AL-Team) führt die Wahl zum neuen AL-Team durch. Die Wiederwahl ist möglich.
Ohne Gegenstimmen, bei drei Enthaltungen wurde auch das Wahlverfahren beschlossen: Jeder SysOp hat 3 Stimmen, die er auf 3 verschiedene Kandidaten verteilen kann. Die Ergebnisliste wird in der Reihenfolge der Anzahl der erhaltenen Stimmen von oben nach unten ausgewertet unter der Voraussetzung, daß aus einer Maus nicht mehr als 1 Mitglied pro Maus im AL-Team ist (außer als Stellvertreter eines anderen). An dieser Stelle verweisen wir noch auf die Thematik "Doppelmäuse", die zu einem späteren Zeitpunkt behandelt wurde (Anm. d. Protokollführer).
Mit einer deutlichen Mehrheit wurde beschlossen, daß das AL-Team von den SysOps gewählt wird. Acht Stimmen entfielen auf den Punkt "Wahl des AL-Teams durch die User" und sieben Enthaltungen wurden registriert.
Bezüglich einer eigenen Diskussionsgruppe SYSOP.AL für das AL-Team (alle SysOps dürfen lesen, schreiben darf nur das AL-Team) stimmten 10 SysOps gegen diesen Vorschlag, 16 enthielten sich der Stimme und die Mehrheit stimmte dafür.
Nach einer ca. einstündigen Diskussion einigten sich die Anwesenden mit deutlicher Mehrheit (bei einer Gegenstimme und sieben Enthaltungen) darauf, Sanktionen festzulegen und diese genauer zu definieren.
Nach anschliessender Diskussion wurde dieses Ergebnis wieder verworfen und auf Antrag von Michael Keukert (mit deutlicher Mehrheit) festgehalten, daß der Ausschluß einer Maus zwar das letzte und schwerwiegendste Mittel ist, welches im Sanktionsfall eingesetzt werden kann, aber daß dieses Mittel existiert.
Sevo Stille gab einen Überblick über die derzeitige Situation im deutschen Fidonetz. Nach der Spaltung in GCC-Fido und Fido-Classic Mitte 1993 hat sich die Spaltung verhärtet. Dadurch herscht ein ziemliches Adresschaos, welches aufhören muß. Sevo berichtetet, daß es im zurückliegenden Jahr ein paarmal Probleme mit Moderatoren von Fido-Gruppen (Beispiel STARTREK) gegeben hat. Er wies darauf hin, daß wenn ein SysOp von einem Moderator angeschrieben wird, unbedingt der Gateway-SysOp informiert werden muß. Wichtig ist, daß dafür gesorgt wird, daß der User vorerst nichts mehr in der betreffenden Gruppe schreibt. Anschliessend kann die Sache mit dem Moderator geklärt werden. Darauf zu warten, daß der Moderator die Gruppe für das Gateway sperrt ist sicher der falsche Weg. Da die Gruppen immer nur über ein Gateway rausgehen, ist an der Message-ID der Gateway zu erkennen. Beim GCC-Gateway (F) ist Sevo Stille der Ansprechpartner und beim Classic-Gateway (AC) ist es Jörg Stattaus.
Um das Adresschaos mit Fido-Adressen innerhalb des MausNet zu vermindern, sollen die Gateways umbenannt werden (Fido-F/Fido-AC), damit die Adresse eindeutiger ist.
Klaus Atzpodien konnte über den Z-Netz-Gateway nichts neues berichten. Der Gateway läuft seit jahr und Tag stabil und macht keine Probleme. Vor Maus 9 wird sich an diesem Gateway auch nichts ändern. Auf Nachfrage, warum die Gruppen BIETE und SUCHE nicht mehr mit dem Z-Netz vernetzt sind, erklärte Klaus daß diese im Z-Netz aufgeteilt wurden und der Import eingestellt wurde, da nicht alle Gruppen dieser Hierarchie mit einer Gruppe vernetzt werden können.
Michael Keukert berichtete über den neuen Gernet-Gateway. Die Gate-Soft muß noch installiert werden. PMs ins und aus dem GerNet werden über diesen Gateway laufen, ebenso wie die Gruppe C'T und evtl. noch andere gewünschte Gruppen. Derzeit ist alles noch eine Frage der Installtion. Was schon an PMs am Gateway ankommt wird aufgehoben und nicht weggeworfen.
Über dieses Thema folgt an anderer Stelle ein eigenes Kapitel.
Anlaß zu diesem Thema war der umstrittene Export der Gruppe MAC ins UseNet. Gegen eine Box, die sich nicht an Abstimmungsergebnisse hält, sollen Sanktionen verhängt werden können. Der Abstimmungsaufruf zu Gruppenexporten soll in Zukunft eindeutiger formuliert werden.
Peter Böhnke regte an, anstelle der Stimmensammlung sofort eine Abstimmung durchzuführen, weil immer jemand gegen ist. Damit würde auch die Bewertung von "deutlichem Widerspruch" wegfallen. Vorgeschlagen wurde auch, den Ablauf der Gruppeneinrichtungen für Exporte zu übernehmen. Fritz Elfert schlug vor, einen Prozentwert der Teilnehmer anzusetzen. Wenn mehr als 10 % der Teilnehmer bei einer Umfrage unter den Lesern der Gruppe gegen einen Export sind, findet der Export nicht statt.
Weiterhin wurde angeregt, daß der Aufruftext standardisiert werden sollte. Peter Böhnke forderte, daß der Aufruf nur in der Gruppe und nicht in MAUS.INFO oder anderswo gepostet wird. Ebenso sollte der Aufruf, so Michael Keukert, positiv formuliert werden. Er sollte zum Beispiel nicht so aussehen: "Ist jemand dagegen, daß nicht exportiert wird?".
Der Vorschlag, den Ablauf zur Gruppeneinrichtung zu übernehmen wurde nochmals in die Diskussion eingebracht. Das Thema wurde damals ausreichend diskutiert, warum sollte es nochmals ausgearbeitet werden, zumal es gut funktioniert.
Folgender Ablauf zu Gruppenexporten wurde dann bei 8 Gegenstimmen und 6 Enthaltungen festgelegt: Der User (der den Export wünscht) wendet sich an das AL-Team, welches ihm eine Bestätigung und den formulierten Abstimmungsaufruf schickt. Hiermit autorisiert das AL-Team den User zum posten des Abstimmungsaufrufes und zur Stimmensammlung. Der Aufruf wird nur in der betreffenden Gruppe gepostet und enthält nur die Punkte "Dafür" und "Dagegen". Die einfache Mehrheit reicht für den Export.
Mit 4 Enthaltungen und keiner Gegenstimme wurde noch beschlossen, daß das Ergebnis von Exportabstimmungen grundsätzlich nach MAUS.INFO gepostet wird.
Stefan Radermacher konnte zur Funktion des Gateway nicht viel sagen, da dieses von zweien seiner Co-SysOps gewartet wird, die beide nicht anwesend waren, ebenso wie der Domainverantwortliche von .maus.de (Jürgen Conradi).
Stefan berichtete, daß der Gateway derzeit auf seinem Notebook läuft, aber er hofft, daß es in Kürze unter OS/2 auf der Maus K laufen wird.
Zum Thema Servergebühr berichtete Stefan, daß im Monat 50,- DM an Kosten anfallen, die er sich nicht leisten kann. Daher möchte er diese gerne auf alle Mäuse umlegen, die Mail über den Kölner Gateway laufen lassen. Die TeX-Mailingliste (TEX-D-L) wird als News betrachtet.
Frauke Cremer bat noch einmal darum offenzulegen, an wen was bezahlt werden muß. Stefan erläuterte, daß der IN-Beitrag, der zur Teilnahme am IN und damit zum Bezug und Versand von Mail und News ins Usenet berechtigt, an den Domainverantwortlichen gezahlt wird. Die Servergebühr ist an die Maus Köln zu zahlen, da dies die Telefonkosten sind, die der Maus Köln für den UseNet-Gateway entstehen. Eine volumenabhängige Abrechnung will Stefan nicht erstellen, da der Aufwand zu hoch sei. Mäuse mit eigenem UseNet-Gateway brauchen keine Servergebühr bezahlen.
Zur Mailbeschränkung besteht derzeit folgende Regelung: Die maximale Mailgröße von einem User an den gleichen User ist pro Tag auf 48 KB festgelegt. Bei Überschreitung dieser Größe wird ab 100 KB eine Strafgebühr in Höhe von 10,- DM pro angefangenem MB erhoben. Die Kosten sind eine reine Abschreckung und nicht die tatsächlichen Kosten, die hierbei entstehen.
Jörg Stattaus schlug vor, daß die Strafgebühren dem Gateway zugute kommen sollen und somit die Servergebühr vermindert werden kann.
Ohne Gegenstimme bei 11 Enthaltungen wurde beschlossen, daß die Grenze für Mailmassen weiterhin bei 48 KB liegt. Alles, was darüber hinausgeht, wird nicht weitergeleitet, sondern gelöscht. Absender und Empfänger erhalten eine freundliche Aufforderung, das in Zukunft doch besser zu unterlassen. Ab 100 KB werden pro angefangenem MB wird eine Strafgebühr in Höhe von DM 10,- erhoben.
Eine Betreiberabstimmung zu Servergebühr ergab ein einstimmiges Votum für DM 8,- pro Jahr und Maus die Mail über den Kölner Gateway laufen läßt.
Jörg Henne brachte das Thema MX-Records für .maus.de zur Sprache. Die beantragten MX-Records für die Mäuse DU/DU2, DO/DO2/MK/UN und MS3 wurden lt. Udo Erdelhoff von Frank Simon (alias Terra, Vorsitzender des IN) abgelehnt. Bisher haben alle Mäuse, die hinter HB hängen einen eigenen MX-Record, was technisch auch notwendig ist. Ausserdem haben die Aachener Mäuse einen MX-Record. Mehr als diese werden .maus.de nicht zugesprochen.
Es wurde einiges an Informationen weitergegeben, was die Finanzlage und die weitere Zukunft des IN angeht. Diese sind inzwischen durch das IN-Treffen überholt. Zum Thema Finanzen wurde der Wunsch formuliert, daß alle Mäuse weniger als durchschnittlich DM 15 zahlen. Beschlossen werden konnte nichts, da kein Vertreter der Domain-Verwaltung anwesend war.
Klaus Abele warf den Domainverantwortlichen vor, daß in SYSOP.IN ein Informationsdefizit bestehe. Es sollten mehr Informationen von den DVs an die SysOps weitergegeben werden. Peter Böhnke verteidigte die DVs. Wenn Jürgen oder Günter auf irgendwas angesprochen werden, erzählen sie immer was. Wenn sie nicht gefragt werden, können sie natürlich auch nichts sagen. Bisher ist auf Anfrage immer was von den beiden gekommen. Abschliessend sagte Peter noch, daß wir uns um eine kostengünstigere Lösung kümmern sollten, worauf Michael Keukert noch zu bedenken gab, daß die billigste Lösung nicht immer die günstigste ist.
An dieser Stelle wurde die Diskussion dann beendet.
Hier stellte Jörg Henne zu Beginn erst einmal die Frage, was Co-SysOps überhaupt sind.
Irgendwo sollte festgehalten werden, wer bei SysOp-Abtimmungen stimmberechtigt ist. Peter Böhnke machte den Vorschlag, daß Co-SysOps im ISB stehen sollten, damit das AL-Team eine Liste der bei SysOp-Abstimmungen stimmberechtigten Personen an der Hand hat. Vorschlag einer Definition: Co-Sysop ist, wer im ISB steht. Betreiber werden extra ausgewiesen. Kai warf ein, daß es "völlig Banane" ist, wer die Stimme für die Maus abgibt.
Die folgende Abstimmung ergab dann bei einer Enthaltung und sechs Gegenstimmen, daß SysOps und Co-SysOps mit ihrem Namen im ISB stehen müssen. Die Adresse ist keine Pflicht.
Nach kurzer Diskussion, bezüglich der Stimmberechtigung der SysOps wurde das Ergebnis der Abstimmung verworfen und die Abstimmung neu formuliert: "SysOps, die abstimmungsberechtigt sind, müssen im ISB stehen." Dieser Antrag wurde bei 15 Enthaltungen und vier Gegenstimmen angenommen.
Jörg Henne schlug vor, das ISB im PMK-Token-Format zu vereinheitlichen. Sam Jost befürwortete das, da die Abstimmungsleiter dann das ISB maschinell auswerten könnten. Wer seine SysOps dann nicht im PMK-Token-Format ins ISB einträgt, ist halt nicht abstimmungsberechtigt. Michael Keukert wies darauf hin, daß das ISB bei Maus 9 automatisch vorgegeben wird, um Fehler zu vermeiden. Daher sollte das derzeit noch nicht zur Pflicht gemacht werden.
Sevo teilte zum Thema ISB noch mit, daß die Maus F ihre Rufnummer jetzt im internationalen Format im ISB eingetragen hat. Damit Probleme mit den österreichischen und Schweizer Mäusen nicht auftreten, sollten das bei allen Mäusen so gemacht werden.
Jörg Henne stellte die Frage, wie der Begriff "Doppelmaus" zu definieren sei und ob diese auch den doppelten IN-Beitrag zu zahlen hätte. Klaus Abele stellte heraus, daß das Ziel der Doppelmaus nicht ist, die Zahl an Usern und Zahlern zu verdoppeln, sondern den Usern mehr Zeit und bessere Möglichkeiten in die Box reinzukommen zu geben. Er möchte nicht hören "Ihr seid nur ein System, müßt aber für zwei Systeme zahlen". Klaus möchte ebenfalls den Begriff "Doppelmaus" festgelegt haben. Ist es eine große Maus oder wie zwei Mäuse in einer Stadt zu sehen. Das nächste Problem der Doppelmaus ist die Servergebühr für den IN-Gateway. Gereon machte den Vorschlag eine Doppelmaus als zwei Mäuse zu zählen, da sie die Möglichkeit hat die doppelte Anzahl an Usern zu versorgen. Klaus machte den Vorschlag die zweite Maus als kleine Maus gegenüber dem IN einzustufen, da sie am Anfang eine kleine Maus sei. Wenn sie größer wird, kann sie dann höhergestuft werden. Wolfgang Walter stellte heraus, daß Karlsruhe freiwillig den Beitrag für zwei Mäuse zahlt, da es quasi eine Maus mit zwei Ports ist. Fritz Elfert brachte ein kleines Gedankenspiel: "Wenn eine Maus acht Ports hat, versorgt sie dann auch achtmal soviele User und muß den achtfachen Beitrag zahlen?". Das Maß sollte nicht die Anzahl der Ports sein, sondern die Zahl der Zahler, da nur diese die IN-Leistungen nutzen können. Kai Henningsen stellte heraus, daß das im Prinzip von den gesamt eingenommenen Geldern der Zahler abhängt. Bisher wird nicht herumgegangen und gezählt, sondern die Systeme schätzen sich selbst ein, wie das in den meisten Bereichen auch ganz gut funktioniert. Gereon brachte zum Beispiel der Acht-Port-Maus das Argument, daß diese die Ports die gleiche Adresse haben, eine Doppelmaus aber zwei Adressen. Klaus Abele wandte ein, daß im IN Doppelmäuse nur als ein System abgerechnet werden. Claus Wickinghoff faßte das Problem nochmal zusammen, daß eine Doppelmaus die Rechte einer Maus, aber die Pflichten für zwei Mäuse haben.
Es folgte eine Abstimmung, ob ein System mit dem gleichen Betreiber, räumlich beieinander stehend, bei gleichem Angebot der beiden Systeme (Ausnahme z.B. UN(2), die auf dem zweiten Port nur Spiele usw. anbieten) als ein System oder mehrere Systeme zu betrachten sei. Dreizehn Stimmen fanden sich für den Punkt "mehrere Systeme", sieben Stimmen waren Enthaltungen und der Rest stimmte für den Punkt "ein System".
Nun fand eine Betreiberabstimmung über die Verteilung der IN-Gebühr statt. Jörg Stattaus schlug vor, daß die Mäuse sich selbst einschätzen (22 Stimmen).
Der Vorschlag von Gereon Steffens, daß jede Maus das gleiche zahlt erhielt 18 Stimmen. Sieben Betreiber einthielten sich der Stimme.
Kai Henningsen regte an, diese Abstimmung in die Gruppe SYSOPS zu verlegen, da das Ergebnis recht knapp war. Dieser Vorschlag fand allgemeine Zustimmung.
Jörg Henne stellte fest, daß es in letzter Zeit Ansätze zur Reglementierung (Rules, Vorschlag des Mausguide) bis zur Einführung von Moderatoren wie im Fido üblich, gegeben hat.
Marcel Sieling brachte den Einwand, daß das Thema lang und breit diskutiert wurde. Es gibt den MausNet-Guide, der fast fertig ist. Den lokalen SysOps sollte überlassen werden, was sie damit machen. Der MausNetGuide ist ganz gut konsensfähig, warum sollte SysOps, die sich nicht damit anfreunden können der Guide vorgeschrieben werden? Jede Maus sollte das halten wie die lokalen SysOps wollen. Michael Keukert vertrat die gleiche Meinung. Die Netiquette ist Sache der User und sollte nicht von oben herab bestimmt werden.
Die Abstimmung, ob der MausNet-Guide als freiwillige Richtschnur anzusehen ist, und es den lokalen Mäusen überlassen wird, was sie damit machen wurde ohne Gegenstimme bei drei Enthaltungen angenommen.
Auf Wunsch von Dirk Steins wird ins Protokoll aufgenommen, daß das DL-Team nur für die Gruppe SYSOPS und nicht für andere Gruppen gilt!
Peter Böhnke fragte nach, ob es eine allgemein gültige Regel gibt, wie mit Usern, die sich in Gruppen daneben benehmen (z. B. UUs in NETGAMES), verfahren wird. Dieses ist bisher nicht geregelt und wird individuell gehandhabt.
Michael Keukert berichtete über Ärger in den Gruppen NETZWESEN und GATEWAYS bezüglich des Status von PMs, insbesondere den "Gelesen"-Status.
Die lauten Vertreter der Leute außerhalb des MausNet sind der Ansicht, daß der "Gelesen"-Status ziemlich kraß gegen den Datenschutz verstößt, allerdings scheint es auf der Seite auch einige Unklarheiten über die Technik zu geben. Erwin Timmerbeil hat einen Datenschutzbeauftragten gefragt, der meinte daß es kein Problem wäre, wobei es auch im MausNet ein deutliches Mißverständnis zwischen dem "Angekommen"-Staus und dem "Gelesen"-Status gibt. Der "Gelesen"-Status wird entweder explizit vom Frontend gesetzt oder eben nicht, Crosspoint setzt ihn, wenn eine bestimmte Option gesetzt ist, auf 12 Uhr anstatt ihn gar nicht zu setzen. Dieser Streit hat schon einige heftige Äusserungen ausserhalb des MausNet hervorgerufen hat, bis zur Äusserung, daß wir in einem faschistoiden Netz leben würden. Michael fragte noch, wie weit das bekannt sei, und wie weit Diskussionsbedarf besteht.
Sevo Stille vermutete, daß diese Leute den "Gelesen"-Status nicht ganz verstanden haben und von der Meinung ausgehen, daß das in irgendeiner Form öffentlich lesbar sei und daß dabei konkrete Zeiten mitgeschickt werden. Die Frontends sollten optional anbieten, die Uhrzeit mitzuliefern, was das Datenschutzproblem umgehen würde.
Michael Keukert regte an, in die MausTausch-Doku mit aufzunehmen, daß ein User, der den Status setzt, dies richtig zu tun hat. Wer den Status nicht herausgeben will, setzt den Status nicht, damit falsche Statusmeldungen unterdrückt werden. Jörg Stattaus machte deutlich, daß dieses defaultmässig der Fall sein sollte.
Die folgende Abstimmung über den Vorschlag, daß Frontend-Programmierer dazu angehalten werden, den Status so zu behandeln, daß dieser vom Frontend richtig gesetzt wird, oder gar nicht wurde bei fünf Gegenstimmen und neun Enthaltungen angenommen.
Der Antrag, daß Statusmeldungen nur auf explizite Anforderung des Users verschickt werden, wurde bei fünf Enthaltungen und einer Pro-Stimme abgelehnt.
Jörg Henne beantragte, eine geheime Gruppe einzurichten, deren einziger Zugriffsberechtigter der "Butler James" (ein Programm, welches in einer Reihe von Mäusen eingesetzt wird) ist. Diese Gruppe könnte auch für andere Programme benutzt werden.
Nach ausführlicher Diskussion über die Vor- und Nachteile dieser Gruppe wurde diese bei einer Abstimmung mit siebzehn Pro-Stimmen und vierunddreißig Enthaltungen abgelehnt.
Rosemarie Rosenboom gab den Termin des SysOp-Treffens 1994 bekannt. Dieses findet vom 26.-28.08.94 in Oer-Erkenschwick statt. Ausrichter ist die Maus Unna.
@AC Jörg Stattaus @L Matthias Bachmann @AC2 Michael Keukert @LU Olaf Boss Stefan Rupp Frank Landrock @M Lutz Gruenewald @AC3 Claus Wickinghoff @M4 Christian Hohendor Claudia Hohendorf @BB Jörg Henne Ulrich Fey @MS Kai Henningsen @BM Marcus Schmidtke @N Udo Fleckenstein @BN Florian Helm @NF Gerhard Trimpin Jörn Haase @CB Romeo Rakow r @OG Andreas Mandel @CLP Joachim Theile Stefan Llabres @DO Michael Roder @PB Bernd Becker Stefan Hintz Frank Baumgart Peter Redecker Uwe Ohse @DO2 Erwin Sienknecht @PB2 Carsten Ellermann Alfred Schmidt Udo Erdelhoff @PE Lars-Iver Kruse Jürgen Stessun @DU Klaus Abele Steffen Engel Georg Schroers Jürgen Loos Dietmar Hannemann f @R Thomas Gallert Markus Fertsch @F Sevo Stille Timm Ganske @RO Marian Maier Petra Ilyes Detlef Woltmann @RS Thorsten Flöck Claudia Hessling (Gast) @FL Maik Standtke Sam Jost @S Gerhard Meiser Thomas Przetak Inge Meiser Andreas Frank @GOe Mario Adam Hans-Peter Deist @H Friedrich Laemmle @S2 Markus Wagenmann Dittmar Knoop Peter Ahlert Andreas Zenner Uwe Schlenther Wolfgang Völker Florian Unger @HB2 Peter Böhnke @S3 Fritz Meyer-Zu-Uptrup Ulli Handorf Uwe Poliak Thomas Wilkens Michael Wist @SB Ralf Buehr @HD Philipp Oelwein @SL Marco Hahn @HG Ralf Lenz Michael Schlüter Thomas Fey @SN Jörn Kresse @HH Harald Labeit Michael Przetak @ST Lorenz Isbeih Ralf Siepker @HL Karsten Iwen Andre Duetsch Ralf Czekalla @HN Frauke Cremer Frank Duering @ST2 Georg Bauer /MS3 Martin Koyro @K Stefan Radermacher Joachim Hoss @SU Tobias Bartelt Vanessa Rehde @K2 Gereon Steffens Edgar Fuss @TBB Hans-Peter Bock Dirk Steins @UN Rosemarie Rosenboom @KA2 Wolfgang Walter Edgar Rosenboom Matthias Stürmer Martin Loos @KI Klaus Atzpodien @WOB Jens Barth Nils-Henner Kruege @WÜ Markus Klingspor @KL Gabriel Schmidt Fritz Elfert Jochen Krapf @KR Elmar Höttges Marcel Sieling @WUN Sebastian Hempel Harro Hedemann @ZW Andreas Mayer Ulrich Pfisterer
Eine nachträgliche SysOp-Abstimmung zum Thema DL-Team ergab folgendes: Ein Misstrauensantrag muß von mindestens 3 stimmberechtigten Sysops unterstützt werden - den Antragsteller eingeschlossen. Wird er im CFV abgelehnt, so wird gegen das betroffene Mitglied des AL-Teams für einen Monat (Datum des Antrags) kein weiterer bearbeitet. Ein neuer Antrag muß sich in mindestens zwei Unterstützern von allen bisher gegen diese Person gestellten unterscheiden.
Unna, 28.12.93
Die Protokollführer (Rosemarie Rosenboom, Edgar Rosenboom, Martin Loos)
Gruppe: MAUS.INFO ID: A56872@KA2 Wg.: Das Protokoll von Wiesbaden Von: Matthias Stürmer @ KA2 (Mi, 15.06.94 00:26)
Es begab sich zu der Zeit 14.00 am 28.5.1994 (Sternzeit 233487.2) Nun ja, legen wir mal los.
Nach der außerordentlich pünktlichen Begrüßung durch Gary waren wir gewillt, Frauke Cremer @ HN als Diskussionsleiterin mit deutlicher Mehrheit zu wählen. Zur Wahl standen noch Harald Krusekamp @ MS und Steffen Engel @ PE.
Nachdem eine kurze Stellungnahme zum Einstieg gewünscht wurde, verlas Erwin Timmerbeil @ BN sein Posting in OEFFENTLICH @ BN vom 08.05.94 und entschuldigte sich am Schluß nochmals ausdrücklich für das Lesen der PMs, die er von Michael Keukert @ AC2 zu lesen bekommen hatte. (Das handelt sich hierbei um ein paar wenige aus den ersten Infiles.)
Ralf Lenz @ HG kritisierte die starren Fronten, während Jürgen Conradi @ HB empfahl, den Begriff "Manifest" zu vermeiden und lieber von PMs, Mails oder Mitteilungen reden wollte. Gereon Steffens @ K2 regte eine allgemein sorgsame und neutrale Wortwahl an, da gewisse Begriffe doch negativ vorbelegt seien.
Auf Jürgens Frage, was unter dem Begriff "Stichwortweise Lesen der Mailingliste" zu verstehen sei, antwortete Michael, daß er nur gelegentlich nachgeschaut hat, ob sich das Archivende verändert hatte. Er schätzte, daß außer Hartmuts Mail noch 2-3 von ihm gelesen worden sind, ist sich der genauen Zahl aber nicht sicher.
Mick Schmidt @ HB kritisierte in seiner nun folgenden Stellungnahme die Form von Timmis Aussage und betonte noch einmal, daß die Mailingliste (im Folgenden "ML" abgekürzt) eine direkte Reaktion auf die Wahl des Diskussionsleiterteams (DL-Team) gewesen ist. Er steht weiterhin zu den Zielen der ML, distanziert sich aber von den Methoden, die, wie er betonte, nicht angewandt worden seien.
Weiterhin berichtete er, daß einige Teilnehmer der ML wünschen, den Status der Mails der ML (PM oder nicht?) geklärt zu sehen und deshalb einer Offenlegung widersprechen. Michael Fröhlich @ HB möchte dies am Dienstag (31.5.) in einem Gespräch mit einem Mitglied des ???Ausschusses des Bundestags (Jürgen oder Mick: bitte berichtigen!)??? klären. Evtl. wird Thomas Backhaus @ HB bei diesem Gespräch dabei sein, bei dem es auch um den generellen Status von PMs geht.
Jürgen versicherte später, daß die Ergebnisse dieses Gesprächs keine rechtlichen Folgen von Seiten der HB-User/Sysops für die PM-Leser haben soll. Es geht lediglich um die Klärung für die Zukunft. Torsten Hellerhoff @ AC2 leider NICHT anwesend) wird ein eigener Standpunkt zugestanden.
Olaf Boos @ LU berichtet von seiner Auswertung der ML und bietet die daraus erstellte Statistik an. Dies wird wegen der fehlenden (am Dienstag erwarteten) rechtlichen Stellungnahme abgelehnt.
Jürgen erklärt sich unter bestimmten Umständen bereit, _seine_ Mails der ML, die er geschrieben hat, freizugeben. Ralf berichtet, daß er von Jürgen anonymisierte Mails der ML, die ihn persönlich betrafen, erhalten hat und daß dieses Thema für ihn nach der Einsicht erledigt sei.
Zum "Manifest" erklärte Jürgen, daß nur ein ML-Mitglied in HB es überhaupt erhalten habe, aber keine weitere Diskussion darüber in der ML stattfand. Im weiteren Verlauf des Tages kam die Frage auf, warum sich niemand aus der ML von diesem "Manifest" im nachhinein distanziert habe. Darüber bestand wohl die allgemeine Auffassung der ML-Teilnehmer, daß dies allein Hartmuts Sache sei und die anderen Mitglieder der ML nicht betreffe. Originalton Jürgen "Das geht mir kalt am Arsch vorbei."
Harald Labeit @ HH (im Folgenden zur Unterscheidung von Harald Krusekamp mit Nachnamen) stellt die Frage, wer überhaupt Mitglied der ML sei, oder ob wenigstens die anwesenden Mitglieder bereit seinen, sich erkennen zu geben. Frauke stellt das auf Bitten von Harald Krusekamp @ MS zurück.
Michael Keukert erklärt das ML-Archiv weitergegeben zu haben, um den Vorwurf einer Manipulation zuvorzukommen. Es sei allerdings ein Fehler gewesen, dies nicht vorher verschlüsselt zu haben.
Gereon erklärt unter allgemeiner Zustimmung, daß der erste Punkt für die MAUS-Programmierer sei, eine PM-Verschlüsselung einzuführen. Jörg Stattaus @ AC berichtet, daß er auf Michaels Rechner die PMs der ML, die bei dem ersten Treffen bei Michael vorlagen, gelesen hat.
In der Pause bespricht Harald mit den anwesenden Sysops der MAUS HB persönlich, in wie weit er seine Erkenntnisse aus der Untersuchung des ML- Archivs offenlegen darf/soll. Zur Erinnerung: Harald wurde am ??? in den Untersuchungsausschuß gewählt.
Nach der Pause stellt Harald die ihm in Auftrag gegebene Auswertung der ML dar. Er betont, daß das "Manifest" die übelste Mitteilung sei und daß Hartmut Malzahn @ MK, Michael Vondung @ MK und Torsten Hellerhoff @ AC2 die treibenden Kräfte und aktivsten Mitglieder der ML gewesen seien. Die restlichen Teilnehmer haben in der ML im Großen und Ganzen keine anderen Standpunkte vertreten als in der Öffentlichkeit.
Die anwesenden Sysops sprechen Harald ihren Dank für seine Mühe und seine neutrale Darstellung aus. Später wird er noch auf eigenen besonderen Wunsch entlastet.
Edgar Rosenboom @ UN erläutert auf Nachfrage, warum die MAUS Unna das Netz verlassen wollte, aber daß sie den Usern zuliebe am Netz geblieben seien. Er erläutert, daß das unberechtigte Lesen und Mitschneiden von PMs sein Vertrauen stark erschüttert hätte. Auf Bitten der User haben sich die Sysops der MAUS UN sich aber entschlossen, doch am Netz zu bleiben.
Auf allgemeine Bitte um eine Stellungnahme, erläutert Gereon, warum er zugestimmt habe und das er in Wiesbaden sei, um "seinen Kopf hinzuhalten". Er werde die Konsequenzen auf jeden Fall akzeptieren und bittet im besonderen darum, seinen Status als MAUS-Programmierer nicht zu berücksichtigen. Erwin und Michael schließen sich dem an, wobei Michael Keukert zusätzlich sagt, daß es schwer erklärbar sei, wie sechs Leute gemeinsam eine solche Fehlentscheidung treffen konnten. Roland Franz @ KR berichtet, ähnliches gelte auch für Harro Hedemann @ KR, der spontan seinen Sysopstatus aufgegeben hat, nachdem er mit der ML konfrontiert worden ist.
- - - Ende des ersten Teil - - - Abendessen - - -
Thomas Backhaus @HB fehlt ein Statement von Jörg , der daraufhin seine Betroffenheit darstellt, das zunächst nicht weiter reflektiert zu haben.Er fühlte sich aus Sorge um das Netz dazu berechtigt. Diesen Standpunkt hatte er auch bereits auf dem letzten User-Treff in Unna zu erklären versucht. Es war für ihn eine große Erleichterung, als vor drei Wochen die Angelegenheit ans Licht gekommen ist.
Peter Hellinger @N stellt die Frage nach dem Zweck des Mitschneidens. Michael denkt, daß die einzige Erklärungsmöglichkeit eine Verdrängung gesessen sei, die eigentliche Schmutzarbeit hätte schließlich ein Programm erledigt, das nicht eigens dafür geschrieben sondern nur geringfügig geändert wurde.
Jörg betonte seine Verwunderung, daß die Archivierung noch so lange weitergelaufen sei.
Jürgen spricht die Logfiles an, und warum Michael in einer Mail darauf verwiesen habe, daß er diese erst überprüfen müsse. Michael erläutert, daß er die Logfiles zum einen nur in ausgewerteter Form zu Gesicht bekommt (James) und zum Anderen, daß er versucht hat, Torsten auf diesem Weg noch ein wenig Zeit für eine eigene Stellungnahme zu verschaffen.
Kai Henningsen @MS fragt, welche Konsequenzen nun aus der Situation gezogen werden können und wie man in Zukunft eine solche Eskalation vermeiden könne. Die Probleme haben schließlich nicht mit der ML angefangen.
Bernd Becker @PB fragt Jürgen, warum die ML-Teilnehmer nichts konkret unternommen haben, als ihnen bewußt wurde, daß die ML mitgelesen wurde. Als Antwort kam: "Aus Spaß an der Freude ;-) ". Der Name der ML sei ein Beweis dafür, daß nicht ernsthaft etwas subversives geplant gewesen sei. Ansonsten hätte man der Liste einen unverfänglichen Namen gegeben.
Es wurden Stimmen laut, daß es vor dem Ziehen von Konsequenzen erst einmal nötig ist, die User umfassend und neutral über den Sachverhalt aufzuklären und eine eindeutige Stellungnahme zum Status von PMs zu erarbeiten. Die Vorarbeiten dazu sind bewußt Michael und Harald aufgetragen worden, das Ziel soll ein Ehrenkodex für Sysops sein.
Allen war klar, daß dieses Treffen konkrete Ergebnisse haben muß, die sich nicht in den Extremen "Friede, Freude, Eierkuchen" oder "ich will Blut sehen" äußern dürfen. Deshalb wurden von uns folgende Vorschläge zur weiteren Vorgehensweise erarbeitet:
Konkret soll zuerst der Abstimmungsmodus für die zukünftigen Sysop- Abstimmungen geklärt werden (One Maus, one Vote).
In der Zwischenzeit sollen die CFVs mit Sanktionen (für jeden Beteiligten einzeln) erarbeitet und direkt nach der Festlegung des Abstimmungsmodus zur Abstimmung gebracht werden. Diese sollen folgende Punkte zur Wahl stellen:
Netzausschluß
Sysopausschluß (Bei Betreibern bedeutet dies den Verlust der Maus)
Ausschluß von netzpolitischen Ämtern
Verweis
keine Sanktionen
Bei Personen, die schon einen Verweis erhalten haben, soll dieser im CFV mit Datum erwähnt werden. Außerdem sollen bei diesen Abstimmungen keine Mindestbeteiligungen erforderlich sein.
Die Sanktionen sollen bis auf Widerruf, mindestens aber für ein halbes Jahr (wie bei Abstimmungen allgemein üblich) gelten.
Die einzelnen CFV sollen gleich nach Festlegung des Abstimmungsmodus erfolgen. Bis dahin ist Zeit zur Diskussion.
Harald betonte noch einmal, daß diese Vorkommnisse nicht am Ergebnis sondern an den Zielen gemessen werden sollten.
Steffen Engel @PE2 schlägt die Formulierung eines minimalen Regelwerk vor, das als Grundlage für alle Sysops gelten soll. Dieses soll auch für alle bereits im Netz vorhandenen Mäuse zur Geltung gelangen, wenn ein Betreiber sich nicht damit einverstanden erklären kann, so hat er das Netz zu verlassen.
Stefan Radermacher zog seinen CFV zum befristeten Ausschluß von Mick aus den Sysop-Gruppen zurück. Thomas erklärte sich bereit, Mick (der zu diesem Zeitpunkt essen war) dazu zu bewegen, seinen Antrag gegen Olaf zurückzuziehen.
Wir, die Protokollanten, möchten hier unseren Dank all denen, die durch ihren tatkräftigen Einsatz dieses Treffen erst möglich gemacht haben, aussprechen sowie unsere Zufriedenheit über die ruhige und sachliche Atmosphäre und den erfolgreichen Ablauf dieses außerordentlichen Treffens ausdrücken!!!
- - /Ende des offiziellen Teils um 21:42 Uhr/ - -
Wir, die Protokollanten, möchten hier noch unsere Zufriedenheit mit der ruhigen und sachlichen Atmosphäre und dem erfolgreichen Ablauf dieses außerordentlichen Treffens ausdrücken und hoffen, daß dieser Ton und diese Stimmung noch eine Weile vorhalten!!!
Roman Kunz und Matthias Stürmer, 16.6.1994
Protokoll des MausNet-Sysop-Treffens 1994
vom 26.8.-28.8.1994 in Oer-Erkenschwick
Die Stimmung, die in Oer-Dings herrschte, vermag dieses Protokoll natürlich nicht einzufangen. Um die teilweise etwas zusammenhangslos verlaufenden Diskussionspunkte in eine lesbare Form zu bringen, habe ich nicht versucht, das Protokoll chronologisch niederzuschreiben. Vielmehr habe ich alle Diskussionen (hoffentlich) sinnvoll gegliedert und zeitlich zerrissene Themen zusammengeführt.
Einen Hauch der Stimmung spürt man, wenn man die Summe der
abgegebenen Stimmen der einzelnen Abstimmungen vergleicht. Der Grund war
ein ständiges Kommen und Gehen, vermutlich der Grund für die
letzte Abstimmung :-)
An dieser Stelle möchte ich noch im Namen der teilnehmenden Sysops
unseren Dank an Christian aussprechen, der als Versammlungsleiter meist die
Oberhand und den "roten Faden" behielt.
Unser weiterer Dank gilt natürlich dem gesamten Organisationsteam, an der Spitze Rosi und Edgar Roosenboom, die für uns ein nettes, gemütliches Heim gesucht und gefunden haben. Alles hat bis ins Kleinste gestimmt - sogar das große Schild mit der Maus an der letzten Abzweigung (damit man noch rechtzeitig die Vollbremsung einleiten konnte).
durch den Versammlungsleiter Christian Rütgers @ UN Das Ergebnis der Abstimmung, ob auf diesem Treffen Beschlüsse gefaßt werden können, ist unbekannt, da Sevo Stille @ F nicht erreichbar ist. Jörg Henne @ BB schlägt vor, daß alle Abwesenden als mögliche Gegenstimmen gewertet werden. Dieses Problem wurde nach Feststellung der Anzahl anwesenden Betreiber (dreiundvierzig) nicht weiter verfolgt.
Gereon Steffens @ K2 legt den Bericht der MAUS-Programmierer vor. Die Dual-Port-Version ist fertiggestellt und ausgetestet. Die Umstellung auf lange Gruppennamen ist weitgehend implementiert. Stichtag für die automatische Umstellung ist vorraussichtlich der 1.10.1994. Dabei werden die Gruppennamen von bisher 10 auf 40 Zeichen erweitert und gleichzeitig netzweit einheitliche Gruppennamen eingeführt. Weiterhin kann ein Gruppenname Groß- und Kleinbuchstaben sowie Umlaute und bestimmte Sonderzeichen enthalten. Als nächstes steht der Einbau einer PM-Verschlüsselung an, die konzeptionell fertig ist und eingebaut wird, wenn die Maus mit den langen Gruppennamen stabil läuft.
Zum Dauerthema MAUS-9 erklärte Gereon, daß vieles davon in
der aktuellen MAUS bereits realisiert ist. Als nächster
größerer Umbau steht eine neue Messagebase an, in der auch
Anforderungen für Multiport-Betrieb (beispielsweise Record-Locking)
berücksichtigt werden.
Resümee von Gereon: "An der MAUS ist noch nie soviel passiert
wie in den letzten anderthalb Jahren."
Die Realmode-Version ist zum Debuggen der MAUS-Software notwendig und wird daher möglichst lange parallel zur Protected-Mode-Version beibehalten. Datenformate und weitere Infos zur MAUS werden von den Programmierern auf Anfrage an Interessierte herausgegeben.
Die Ebene 2 im MausNet ist komplett auf ISDN umgestellt, Ebene 3 zieht
langsam nach. Zur Zeit werden im Netz Raten von 12000 cps erreicht, eine
Steigerung auf 20000 cps wird für möglich gehalten. Dadurch ist
ein minutengenaues Netztiming wieder möglich.
Weiterhin rentiert sich eine ISDN-Leitung schon bei einem
Fernzonenlink.
Jörg Henne @ BB erklärt, daß zur Entwicklung der vollständigen UMaus die Programmiererkapazitäten fehlen. Daher werden die Ideen und Konzepte zur Entwicklung einer alternativen Oberfläche für die Quark verwendet.
Frank Baumgart @ PB gibt den aktuellen Stand der Quark wieder. Die Quark PB wurde bereits komplett auf die neue Software unter Linux umgestellt und läuft stabil. Sie ist "sehr, sehr schnell, schneller als die MAUS". Die Quark hat keine Mailgrößenbeschränkung, lange Message-IDs, lange Gruppennamen und eine PM-Verschlüsselung. Als Oberfläche steht zur Zeit GeoNet zur Verfügung. Eine MAUS-konforme wird von dem UMaus-Team erstellt.
Als nächste Erweiterungen sind ein Programmteil und Multiport-Betrieb geplant.
Uwe Ohse @ ME beantwortet einige Fragen zu UUCP, anderen Nachrichtenformaten und ISDN. Prinzipiell sind diese Dinge möglich, werden aber in nächster Zukunft noch nicht implementiert.
An Hardware benötigt eine Quark unter Linux einen 386er mit 8 MB Speicher. Die Quark-Software wird als Binary ausgeliefert und kostet 200,- DM. Eine Demo-Version liegt in der Quark PB.
Marco Hahn @ SL: "Es gibt das Betriebssystem, es gibt ein paar Ideen und die Quark ist zwei Jahre voraus."
Christian Rütgers @ UN stellt kurz UMS vor, eine Mail-Datenbank von Martin Horneffer @ AC2 für den Amiga. Geplant ist ein MAUS-kompatibler Aufsatz für UMS. Evt. erscheint Anfang '95 eine Demo-Version.
Stefan Rupp @ AC2 berichtet, daß die Einspruchsfrist im Mai ausgelaufen ist und Jörg Stattaus @ AC in den nächsten Tagen vermutlich die Urkunde erhält. Damit wäre "MausNet" eingetragenes Warenzeichen.
Als nächstes soll ein weiterer Versuch mit "MAUS" gestartet werden.
Nachtrag: Die Registrierung von "MausNet" war erfolgreich. Die Urkunde befindet sich auf dem Weg von den Mühlen der Bürokratie zu Jörg.
Jörg Henne @ BB berichtet vom Zusammenbruch der "Teralon", wodurch das Mailrouting aus dem Internet ins MausNet kurzfristig nach Böblingen umgestellt werden mußte und die dadurch auftretende Probleme.
Zum Thema Kostenerstattung erklärt Stefan Radermacher @ K, daß er bisher kein Geld genommen hat und auch zukünftig keines nehmen wird.
Gereon Steffens @ K2 berichtet von seinen Bemühungen einen Gate zur Domain Rhein.de aufzubauen.
Mails über 48 kB werden am Gate herausgefiltert. Absender und
Empfänger werden mit einem konfigurierbaren Text benachrichtigt und
die Mail wird vernichtet.
Aus der Erfahrung der letzten Monate zeigt sich, daß keine
Mailmassen durch Benutzung von FTP-Servern anfallen. Meist handelt es sich
um freundliche UseNet-Teilnehmer.
In Zukunft soll daher weiterhin regelmäßig der Warnungstext
von Dirk Johannwerner @ K gepostet werden.
Jörg Henne @ BB berichtet von der Inbetriebnahme eines Nameservers für die maus.de-Domain. Jetzt können problemlos MX-Einträge für Mäuse vergeben werden.
Bei dem World-Wide-Web handelt es sich um ein Hypertext-System, von dem aus dem Internet Informationen abgerufen werden können. Für das MausNet soll demnächst auch eine solche WWW-Page mit Infos zur MAUS angeboten werden.
Fritz Lämmle @ H erläutert das neue Routing im Z-Netz. Seit dem 1.7.1994 wurde im Z-Netz das Domain-Routing eingeführt, d.h. die einzelnen Systeme haben sich an regionale Internet-Domains angeschlossen. Die zer-Adressen gibt es offiziell nicht mehr, sie werden jedoch am Gate gewandelt. Nach außen ist es also nicht mehr sichtbar, ob ein System am Z-Netz oder am InterNet teilnimmt.
Die bisher von Günther Stück @ HB geführte Liste, welche Gruppe von welchem Gate in welches Netz weitergegeben wird, muß weitergepflegt werden.
Kai Henningsen führt die vollständige Vernetzungsliste,Peter Böhnke @ HB2 übernimmt freiwillig das Amt des Gateway-Koordinators.
Harald Krusekamp @ MS verliest einen Teil seines am 24.8.94 in SYSOP-INFO geposteten Satzungsentwurfs zu einem Trägerverein für "maus.de". Er beantwortet einige Fragen zu dem Entwurf. Die Versammlung beschließt die Gründung eines solchen vom MausNet unabhängigen Vereins.
Die Gründungsversammlung findet Samstag Abend statt. Sonntag vormittag erstattet der erste Vorsitzende des Vereins Jürgen Conradi @ HB einen kurzen Bericht. Zum zweiten Vorsitzenden wurde Gereon Steffens @ K2 gewählt. Marcus Schmidtke @ BM ist Kassenwart, Herbert Framke @ SU2 ist der Stellvertreter. Durch die starke Präsenz von Rheinländern im Vorstand wird der Vereinssitz entgegen des Satzungsentwurfs nach Köln gelegt.
Der Verein benötigt zwei MAUS-Gruppen: MAUS.DE.EV für die vorstandsinternen Diskussionen sowie eine weitere [deren Name nicht gefallen ist], in der die Mailingliste des IN-Präsidiums gepostet wird.
Anfragen an die Domainverwaltung sollen regional bearbeitet werden.
Nachtrag: Das Posten der Mailingliste ist aus IN-Gründen nicht möglich, so daß diese Gruppe ersatzlos gestrichen ist.
Die Informationen im "Gator" von Michael Keukert @ AC2 und einigen Infofiles in den Mäusen sind teilweise falsch oder veraltet. Eine im InterNet kursierende aktuelle FAQ wird ab sofort von Sebastian Hempel @ WUN regelmäßig gepostet.
Die Infofiles sollten in absehbarer Zeit überarbeitet und auf einen netzweit einheitlichen Stand gebracht werden.
Peter Böhnke @ HB2 gibt einen Rückblick auf seine bisherige
Amtsperiode. Aus der Versammlung kommt die Frage, ob man von der aktuellen
one-maus-one-vote-Regelung (der Abstimmungdämon berechnet
Stimmenanteile) weg kann und die Stimme lokal in jeder MAUS findet.
Dies wird abgelehnt, da dies zu langwierig ist und so kurzfristige
Abstimmungen nicht möglich sind. Weiterer heißer
Diskussionspunkt ist die Stimmenfindung, da es dort zwei verschiedene
Verfahren gibt, die die Resultate um einige Prozentpunkte verschieden
errechnen.
Die weitere Diskussion der Verfahren wird nach SYSOPS vertagt.
Verfahren 1:
Die Gesamtstimme der MAUS wird auf die Abstimmenden verteilt. Jeder
Abstimmende verteilt seinen Anteil auf die zur Wahl stehenden Punkte.
Verfahren 2:
Auch hier wird die Gesamtstimme der MAUS auf die Abstimmenden verteilt,
allerdings kann ein Abstimmender jedem zur Wahl stehenden Punkt seinen
ganzen Stimmenanteil geben.
Auf Vorschlag von Claus Wickinghoff @ AC3 soll in Zukunft bei jeder
Abstimmungsauswertung der gewählte Punkt im Originaltext aus dem
Abstimmungsaufruf mitgepostet werden.
Peter verweist darauf, daß sich einige Sysops wegen
möglicher Anfeindungen nicht trauen Abstimmungsanträge zu
stellen. Um Unterstellungen wegen vom AL-Team gefälschter PMs zu
vermeiden, muss ein Antrag dennoch öffentlich an das AL-Team gestellt
werden.
Das AL-Team kann deutlich entlastet werden, wenn zukünftig schon vorformulierte Abstimmungsaufrufe dem Antrag beiliegen.
Sam Jost @ FL erklärt, daß ein großes Problem für die ALs die Leute sind, "die immer dagegen sind". Er erhofft sich für die Zukunft, daß bei Abstimmungen mehr Zustimmung gezeigt wird, um die Nörgler zu entkräften und die ALs zu stärken.
Einsprüche gegen Abstimmungen werden zukünftig in SYSOP.AL bzw. MAUS.AL diskutiert. Das AL-Team verfaßt eine Antwort zu jedem Einspruch.
Eine ausführliche Diskussion wird für nicht notwendig befunden.
Abstimmung:
Soll das DL-Team abgeschafft werden?
ja: 43 Sysops nein: kein Sysop Enthaltungen: 4 Sysops
Damit ist das DL-Team ab sofort abgeschafft.
Thomas Meißner @ OS2 erläutert seinen Entwurf zu einem Kontrollgremium, welches Einsprüche zu Abstimmungen bearbeitet und quasi das AL-Team überwacht.
Christian von Grone @ PE2 möchte das AL-Team mit erweiterten Kompetenzen ausstatten, so daß es Sanktionen verhängen und durchführen kann. Lediglich für Ausschlüsse von Sysops ist eine Betreiberabstimmung notwendig.
Fritz Lämmle @ H erläutert, daß das AL-Team aus 3 Personen besteht, damit es sich gegenseitig überwacht und Irrtümer erkennt. Eine weitere Kontrolle findet durch das Plenum der Sysops statt.
Harald Krusekamp @ MS wünscht, daß ein Abstimmungsentwurf gepostet wird gegen den dann formelle Einsprüche eingelegt werden können. Dieser Einspruch muß *nachvollziehbar* begründet werden. Das AL-Team entscheidet dann über den Einwand.
Sam Jost @ FL schlägt vor in die Abstimmung einen Punkt aufzunehmen, mit dem man Einspruch einlegen kann.
Abstimmung:
Ein Abstimmungsentwurf wird 5 Tage zur Diskussion gestellt. In die
Abstimmung wird ein Punkt aufgenommen 'Die Abstimmung enthält einen
formalen Fehler'. Das AL-Team bearbeitet diesen Einspruch.
ja: 40 Sysops nein: 6 Sysops Enthaltungen: 1 Sysop
Bis zur Auszählung des Abstimmungsergebnisses sind Einsprüche gegen die eigentliche Abstimmung möglich. Ist das Ergebnis der Abstimmung bekanntgegeben, sind nur noch Einsprüche gegen die Auszählung möglich. Im Zweifelsfall muß das AL-Team die Auszählung verschieben, bis die Einsprüche gegen die formale Korrektheit der Abstimmung geklärt sind.
Unter allgemeiner Zustimmung letztendlich folgender Konsens zustande: Das AL-Team ist völlig frei in seinen Handlungen und hat die Rückendeckung der Sysop-Gemeinschaft. Dem AL-Team werden kleinere Fehler zugestanden. Das Mißtrauen kann dem AL-Team nur durch die Sysop-Gemeinschaft ausgesprochen werden - nicht durch vereinzelte Dauernörgler.
Abstimmung:
Abstimmungsberechtigt ist der Betreiber bzw. Sysop, der im PMK2-Format
im ISB eingetragen ist.
ja: sehr viele nein: kein Sysop Enthaltung: 4 Sysops
Abstimmung:
Betreiberabstimmungen werden nach one-maus-one-vote durchgeführt,
bei Betreibergemeinschaften werden dabei die Stimmen der mit "%B1"
und "%B2" im ISB eingetragenen Betreiber anteilsmäßig
gewichtet.
ja: sehr viele nein: kein Sysop Enthaltung: kein Sysop
Als Alternative zu dem "Konsenspapier" von Gerhard Trimpin @ NF erläutert Claus Wickinghoff @ AC3 einen eigenen Entwurf der AC3-Sysops. Dieser Entwurf sieht statt einer Verschärfung der Regeln eine sinnvolle Lockerung des Regelwerks vor.
Nach langer Diskussion faßt Claus seinen Entwurf zusammen (weniger Reglementierung, weitgehende Selbstständigkeit der einzelnen Mäuse, erweiterte Befugnisse des AL-Teams).
Eine Meinungsumfrage ergibt 37 Stimmen für den Entwurf bei 3 Gegenstimmen. Die Entscheidung wird vertagt. Beide Parteien (Gerhard und Claus) sollen ihre Entwürfe überarbeiten und in SYSOPS zur Diskussion stellen. Falls sich weitere Personen berufen fühlen, ein Regelwerk zusammenzustellen, können sie dieses gerne ebenfalls zur Diskussion stellen. Abschließend soll die gesamte Sysopschaft über die Entwürfe in der Form "Regelwerk 1 oder Regelwerk 2 oder ein anderes Regelwerk oder kein neues Regelwerk" abstimmen. Als Stichtag für die Abstimmung wird der 1.10.1994 festgelegt.
Im Folgenden sollen einige Beiträge aus der Diskussion festgehalten werden:
Edgar Roosenboom @ UN:
"mehr Regeln um Störenfriede in die Schranken zu weisen"
Edgar Fuß @ K2:
"Sysops können keine lokale Angelegenheit sein, da sie Zugriff
auf die MAUS-Dateien haben."
Harald Krusekamp @ MS:
"Weitere Reglementierung führt langfristig nicht zum
Ziel."
Marco Hahn @ SL:
"Sanktionen verlaufen momentan im Sande"
Stefan Rupp @ AC2:
"In den letzten Jahren wurden fast nur Regelstreitigkeiten in
SYSOPS diskutiert."
Thomas Fey @ HG:
"Das AL-Team hat das Vertrauen der Sysops, damit die Machtbefugnis
selbstständig Entscheidungen zu treffen und durchzuführen. Als
Notbremse existiert immer noch das Mißtrauensvotum."
Claus Wickinghoff @ AC3:
"Das AL-Team soll die Sysops und damit das MausNet auch nach
außen repräsentieren können."
Von einigen Leuten wurden Arbeitsgruppen angeregt, die bestimmte Themen ausarbeiten und zur Abstimmungsreife bringen sollen. Nachdem diverse Vorschläge zu Vorgehensweisen gemacht wurden, einigt sich die Versammlung auf folgenden Konsens:
Arbeitsgruppen können sich selbstständig zusammenfinden oder vom AL-Team eingerichtet werden. Der Arbeitsgruppe steht eine Netzgruppe zur Verfügung (die bei Bedarf eingerichtet wird), deren Status die Gruppe selbst festlegen darf. Die Arbeitsgruppe sollte in angemessener Zeit, die vor Aufnahme der Arbeit festgelegt wird, zu einem Ergebnis kommen. Im Bedarfsfall kann diese Frist verlängert werden.
Hier wurde keine explizite Entscheidung gefaßt, als Grundverhaltensmaßnahme wurde Folgendes festgelegt:
Die Störer sollten entweder ignoriert oder per PM ermahnt werden. Diese Ermahnen durch extra dazu bestimmte Personen ist sinnlos. Hier ist jeder einzelne gefordert, die Situation zu deeskalieren.
Da ein Sysop durch Zugriff auf die MAUS-Dateien auch Zugriff auf Daten anderer Mäuse hat, ist er keine lokale Angelegenheit.
Abstimmung:
Ein Sysop der Kraft einer Abstimmung als Sysop aus dem MausNet
ausgeschlossen wurde, darf keinen Zugriff der über die
Möglichkeiten des Userstatus hinausgeht auf eine MausNet-Box haben.
ja: 40 Sysops nein: 7 Sysops Enthaltung: 7 Sysops
Konsequenzen bei Verstoß gegen diese Regel werden nach Antrag gestellt.
Eine Begrenzung der maximalen Anzahl von Sysops einer MAUS ist nicht notwendig, da Abstimmungen nach "one-maus-one-vote" durchgeführt werden.
Harald Krusekamp @ MS verliest die am 2.8.94 von ihm in SYSOP.INFO gepostete Fassung des PM-Manifests.
Abstimmung:
Soll das PM-Manifest so angenommen werden?
dafür: 53 Sysops dagegen: keiner Enthaltung: einer
Damit ist das PM-Manifest in Kraft und wird als Maus-Infofile
übernommen.
Abstimmung:
Es soll ein Rundschreiben an Sysop@xy aufgesetzt werden, daß alle
Sysops der MAUS xy das Manifest bestätigen und akzeptieren. Für
diese Bestätigung haben sie 4 Wochen Zeit. Sind Sysops abwesend (z.B.
durch Urlaub) müssen sie so bald wie möglich das Manifest
bestätigen.
dafür: viele dagegen: 1 Sysop Enthaltung: 2 Sysops
Zur Durchführung dieser Mailing-Aktion meldet sich freiwillig Ulrich Pfisterer @ ZW.
Abstimmung:
Einrichtung einer Gruppe MAUS.AL als Diskussionsforum des AL-Teams bei
userrelevanten Abstimmungen. User und Sysops haben nur Leserecht in der
Gruppe.
ja: viele Sysops nein: 1 Sysop Enthaltung: 10 Sysops
Abstimmung: MAUS und MAUS.INFO.D sollen zusammengelegt werden.
vertagt, da die User abstimmen müssen
Abstimmung:
Einrichtung einer Gruppe BETREIBER, in der nur Betreiber schreiben
dürfen.
ja: 2 Sysops nein: viele Sysops Enthaltung: 4 Sysops
Hier noch der kurze Verweis auf die beiden unter 3.6 erläuterten Gruppen das "MausNet-To-InterNet e.V."-Vereins.
Zu den unnötigen Postings in den *.INFO-Gruppen wurde kein
Beschluß gefaßt. Es wurde festgehalten, das SYSOP-INFO keine
Diskussionsgruppe ist. Ggf. muß ein Schreiber durch eine
größere Anzahl PMs auf den Mißstand aufmerksam gemacht
werden.
Anselm Kruis @ M erläutert, wie man unbeabsichtigtes Posten durch
entsprechendes Konfigurieren der Gruppen auf "read-only" vermeiden
kann. Timm Ganske @ OF bittet die Frontend-Programmierer, in nächster
Zeit das "FOLLOW-UP" zu unterstützen.
Um die bestehende ATARI.INFO-Gruppe sowie die noch einzurichtende
PC.INFO-Gruppe, in denen im MausNet ansässige Firmen ihre Produkte
vorstellen können, entbrannte eine heftige Diskussion.
Problematisch ist vor allem, daß es sich um kommerzielle Mails
handelt. Nachdem von der Gruppe OEKOM (Oecher Kommerz) berichtet wurde, die
seit langer Zeit in den Aachener Mailboxen problemlos läuft, einigen
sich die Sysops auf Folgendes:
Gabriel Schmidt @ KL und Peter Hellinger @ N sollen jeweils die von ihnen ausgearbeiteten Regeln sowie eine lange Gruppenbeschreibung innerhalb der nächsten beiden Wochen in SYSOPS vorstellen. Danach werden sich die Betreiber in einer Abstimmung für einen der beiden Entwürfe entscheiden.
Weiterhin soll eine NEWS-Gruppen-Hierarchie eingerichtet werden, in der
die gewählten Regeln regelmäßig gepostet werden. Die
Umbennenung in NEWS ist notwendig, da die bestehenden INFO-Gruppen anderen
Zwecken dienen. In diesen Gruppen werden dann die gewählten Regeln
regelmäßig gepostet.
Für die Einhaltung der Regeln in den Gruppen ist der lokale
Gruppenchef zuständig.
Abstimmung:
Einrichtung der NEWS-Gruppen (Atari.NEWS, PC.NEWS, etc.)
dafür: viele dagegen: keiner Enthaltung: 4 Sysops
Da sich die auf dem Sysoptreffen '92 in Flensburg eingeführte Möglichkeit gegen die Einrichtung einer Gruppe bewährt hat, soll dies auch in Zukunft beibehalten werden.
Abstimmung:
Soll das aktuelle Verfahren beibehalten werden?
dafür: viele dagegen: 4 Sysops Enthaltung: 3 Sysops
In den bestehenden Regeln wird ein unklarer Satz umformuliert in "Die letztendliche Entscheidung in jegliche Richtung (pro oder contra) bleibt dem Sysop-Plenum vorbehalten."
Abstimmung:
Soll die zur Gründung einer Gruppe notwendige Stimmenanzahl von 10
auf 20 erhöht werden?
dafür: 30 Sysops dagegen: 10 Sysops Enthaltung: 7 Sysops
Abstimmung:
Soll die zum Import einer Gruppe notwendige Stimmenanzahl von 20 auf 30
erhöht werden?
dafür: 30 Sysops dagegen: 10 Sysops Enthaltung: 7 Sysops
Abstimmung:
Soll die zum Import einer Gruppe notwendige Stimmenanzahl von 30 auf 40
erhöht werden? dafür: 7 Sysops dagegen: viele Enthaltung: einige
Damit sind für die Gründung einer Gruppe ab sofort 20 Stimmen, für den Import einer Gruppe ab sofort 30 Stimmen notwendig. Auch hier gilt, daß die letztendliche Entscheidung beim Sysop-Plenum liegt, so daß auch kleine Gruppierungen zu einer eigenen Gruppe gelangen (Beispiel ARCHIMEDES).
Weiterhin kann bei einer Stimmensammlung zur Gründung einer Gruppe direkt gefragt werden, ob die Gruppe exportiert werden darf.
Abstimmung:
Die Pflichtgruppen (SYSOP- und heutige MAUS-Hierarchie und M.INFO.D)
sollen so bleiben.
dafür: 42 Sysops dagegen: 5 Sysops Enthaltung: 1 Sysop
Die Empfehlung der Sysops sieht vor, daß mindestens ein Sysop pro MAUS die INFO-Gruppen liest und das MAUS.INFO auf Default gestellt wird.
Abstimmung:
Wer xy.INFO nicht liest, ist selber schuld.
xy==* 32 Sysops xy==MAUS 9 Sysops Enthaltung: 4 Sysops
-> Wer *.INFO nicht liest, ist selber schuld!
Abstimmung:
Beim nächsten Sysoptreffen soll es keinen Rechnerraum geben.
dafür: 32 Sysops dagegen: 8 Sysops Enthaltung: 11 Sysops
Als Stätte für das nächste Sysoptreffen wird aus historischen Gründen die Stadt Münster vorgeschlagen. Die Sysops der dortigen Mäuse werden gebeten, in den nächsten Wochen zu prüfen, ob ihnen dies möglich ist.
6. Abschluß ===========
Abstimmung: Beim nächsten Sysoptreffen soll es keinen Rechnerraum geben. dafür: 32 Sysops dagegen: 8 Sysops Enthaltung: 11 Sysops
Als Stätte für das nächste Sysoptreffen wird aus historischen Gründen die Stadt Münster vorgeschlagen. Die Sysops der dortigen Mäuse werden gebeten, in den nächsten Wochen zu prüfen, ob ihnen dies möglich ist.
Nachtrag: Die Münsteraner Sysops nehmen von der Ausrichtung des Sysop- Treffens Abstand. Zur Zeit stehen Heilbronn und das Rhein-Main-Gebiet zur Debatte. [gabs da eigentlich schon eine Entscheidung?]
-- Teilnehmerliste --
AC2 Stefan Rupp KA2 Matthias Stürmer AC3 Claus Wickinghoff Robert Lechler Christian Leutloff Ralf Urmersbach Achim Reinhard KI Klaus Atzpodien AN Gert Stamminger KL Gabriel Schmidt BB Jörg Henne KR Elmar Höttges Ulrich Frey Harro Hedemann BB2 Sven Dittmar Henry Rolofs Holger Dengler Roland Franz BI Michael Mies LU Stefan Hürter BL Carola Keck Jochen Friedrich Volker Keck Andreas Kögel BM Axel Katerbau Olaf Boos Marcus Schmidke M2 Anselm Kruis BN Heinz Decker ME Uwe Ohse Margot Decker MK2 Martin Loos Birgit Luckas Dirk Reinarz Christian Luckas MS Harald Krusekamp DO2 Udo Erdelhoff Christian Ruetgers Uwe Blenz MS3 Martin Koyro Alfred Schmidt Matthias Heidbrink DU Klaus Abele OF Timm Ganske Thomas Neumann OS2 Thomas Meißner Georg Schroers PB Frank Baumgart FL Maik Standtke Bernd Becker Ingo Horst PE2 Jürgen Loos Sam Jost Steffen Engel FÜ Udo Fleckenstein Christian Von-Grone GI Roman Kunz RS Thorsten Flöck GP Michael Wist S Inge Meiser H Dittmar Knoop Gerhard Meiser Friedrich Lämmle Andreas Frank HB Jürgen Conradi S2 Christian Tischler Birgit Kuhfeld S3 Frithard Meyer-Zu-Uptrup HB2 Ulli Hahndorf SB Torsten Engel Peter Böhnke SL Marco Hahn HG Tomas Fey SU2 Herbert Framke HH Harald Labeit Jürgen lanski HH2 Philipp Oelwein TBB Hans-Peter Bock HN Frauke Cremer UN Rosemarie Rosenboom Frank Dürring Edgar Rosenboom K Stefan Radermacher Karl Reinberg Andreas Hoffmann WUN Sebastian Hempel K2 Edgar Fuß ZW Marion Pfisterer Dirk Steins Ulrich Pfisterer Gereon Steffens Andreas Mayer
-- Ende des Protokolls --
-- schnapp -----------
-- Ende des Protokolls --
Protokoll des Sysoptreffens 1995 in Heilbronn
Datum: Samstag, der 30.9.1995
Das Gate zum Z-Netz in Hannover läuft zuverlässig. Das Z-Netz befindet sich in Auflösung, da immer mehr Z-Netz-Sites ins Usenet abwandern. Für Testimporte steht die Mausgruppe "ZNET.TEST" zur Verfügung. Anfragen und Wünsche für Testimporte nimmt Friedrich Lämmle @ H entgegen.
Das Z-Netz schreibt eine bestimmte Namensgebung für seine Exportgruppen vor, an die sich das MausNet halten sollte. Siehe auch Top 8.
Das Fido-Gate in Frankfurt gibt es nicht mehr. Das Gate in OF hat einen neuen Partner (HUB). Seit kurzem wird über diesen Link versucht, die ins Fido Mausgruppen dort zu verbreiten, da es über AC nicht klappt.
Das Gate zum Atari-Net ist von GI nach FÜ verlegt worden. Soll auch das englischsprachige Atarinetz NeST importiert werden?
Seit 6 Monaten verfügt das Gate bei der Maus BB über eine
Standleitung ins Internet. Mail wird daher sofort ausgeliefert.
Kann eine Mail nicht sofort ausgeliefert werden, wird noch 10 Tage lang
versucht, die Mail zuzustellen. Danach wird sie als unzustellbar
zurückgeschickt. Dies ist wichtig, weil etliche Internet-Sites keinen
korrekten MX-Record haben.
Die Gatewaylogfiles werden 14 Tage aufbewahrt.
Nachforschungen sind nur unter Angabe der Message-Id möglich!
Folgende Massenmail-Regelung ist für eingehende Mail gültig: Mail
ab 64kB bleibt im Filter hängen und der Empfänger wird mittels
einer PM informiert. Ab einer Größe von 100kB erhält der
Empfänger zusätzlich eine Zahlungsaufforderung.
Als einziges anwesendes Mitglid berichtet Jörg Henne über die Tätigkeit des AL-Teams. Nach anfänglichen Schwierigkeiten hat das Team seinen Job in den Griff bekommen.
Unter anderem mußte die Abstimmungssoftware neu geschrieben werden. Die neue Software besteht aus 2 Perl-Skripts und Timm Ganskes OMOV-Programm. Sie steht auch dem neuen Team zur Verfügung.
Im AL-Team herschte folgende Aufgabenteilung: Tomas Fey kümmerte sich um Gruppeneinrichtungen, Jörg Henne um den Rest. Jörg Henne räumt ein, das das AL-Team die Abstimmung zu den langen Gruppennamen nach monatelanger Diskussion verpennt hat. Aus dem Plenum wird vorgeschlagen, die Sache auf dem Sysoptreffen zu regeln. Siehe auch TOP 8 und 9.
Leider ist Gereon Steffens @ K2 krank und die anderen Mausprogrammierer wollten oder konnten nicht zum Sysoptreffen kommen. Daher gibt es keinen Bericht über die Maus.
Uwe Ohse @ DU3 berichtet über den Entwicklungsstand der Quark II. Die Quark II läuft zur Zeit unter Linux, Net-BSD und HP-UX. Wesentlicher Vorteil der Quark ist die höhere Geschindigkeit sowie die einfachere Einbindung ins Internet. Nachteilig ist die schlechtere Einbindung ins MausNet. Eine aktuelle Demo der Quark steht zur Verfügung und kann im Saal bewundert werden.
Über den Status der Quark I ist nichts genaues bekannt.
Die Amtszeit des bisherigen AL-Teams ist abgelaufen.
Die Sysops beschließen mit absoluter Mehrheit, sofort ein neues Team zu wählen.
Folgende Kandidaten stellen sich zur Verfügung: Udo Fleckenstein @ FÜ Timm Ganske @ OF Michael Wist @ GP Gert Stamminger @ AN (nur als Stellvertreter) Peter Böhnke @ HB2 (nur als Stellvertreter)
Die Sysops beschließen ohne Gegenstimmen, daß die Anzahl der Kandidaten ausreicht.
Gegen eine Blockabstimmung werden keine Einwände erhoben. Um der OMOV-Regelung gerecht zu werden, wird eine Betreiberabstimmung durchgeführt. Die Kandidaten werden mit 2 Gegenstimmen gewählt und nehmen die Wahl an.
F. Meyer zu Uptrup @ S4 wünscht sich die Möglichkeit, regional ein höheres Limit für Massenmails als die im PM-Manifest vorgesehenen 64kB einzustellen, da er zu vielen Mäusen Nahbereichsverbindungen hat. Ein Problem besteht darin, daß das mausnet.exe Massenmails erst nach dem 1. Hop filtert. Das führt dazu, daß die MAUS S3 momentan quasi der Mülleimer des MausNet ist. Wegen dieser Einschränkung werden z.B. öfter Sachen auf der S3 "entsorgt", welche für die S4 bestimmt waren. Letzere steht ganze 20 Zentimeter von der ersteren weg.
Eine differenzierte Einstellung des Limits für einzelne Verbindungen ist derzeit nicht möglich. In der Diskussion werden folgende Gesichtspunkte aufgezeigt:
Regionale Regelungen können die User verwirren, wenn sie nicht mehr wissen, wieviel sie wohin verschicken dürfen.
Höhere Limits ändern den Charakter des MausNet von einem messageorientierten Netz hin Richtung auf ein fileorientiertes Netz.
Höhere Limits an Gateways könnten Auswirkungen auf die Domain .maus.de haben. Friedrich Lämmle @ H hält dem entgegen, daß die Berechnungsgrundlage zumindest im HanNet 10MB/Monat sei, was von den Mäusen nicht erreicht werde.
Eventuell widersprechen höhere regionale Limits dem PM-Manifest.
Die anwesenden Betreiber beschließen bei 20 Pro-, 11 Gegenstimmen und 6 Enthaltungen, die bisherige Regelung, die regionale Limits verbietet, zu ändern. Folgende Varianten werden abgestimmt:
Falls die Mausprogrammierer keine zusätzlichen Konfigurationsmöglichkeiten einbauen, werden lokal höhere Limits erlaubt. Abgelehnt bei einer Prostimme.
Falls die Mausprogrammierer ein pro Link einstellbares Limit einbauen, werden für maximal einen Hop entfernte Empfänger höhere Limits zugelassen. Doppelmäuse zählen als 1 System. Angenommen bei 21 Pro-, 9 Gegenstimmen und 6 Enthaltungen
Falls die Mausprogrammierer ein System einbauen, das für beliebige Verbindungen die Einhaltung aller unterwegs geltenden Limits auf der Absendermaus erzwingt und es den Usern einfach ermöglicht, das jeweilige Limit zu erkennen, so wird die Verwendung dieses Systems erlaubt. Angenommen bei 19 Pro-, 5 Gegenstimmen und 12 Enthaltungen.
Weiterhin wünschen sich die anwesenden Sysops eine Steigerung der maximalen Nachrichtengröße über 16 kB hinaus.
Harald Krusekamp @ MS gibt einen ausführlichen Bericht über die Jagd auf den Megahacker, der im Sommer dieses Jahres aktiv war.
Die Sysops beschließen mit absoluter Mehrheit (Mit zwei Gegenstimmen und drei Enthaltungen), das Nachtnetz vorzuverlegen, um die neuen Telekom-Tarife ab 1996 auszunutzen. Die genauen Zeiten werden in Sysop.tech erarbeitet.
Dieser Punkt behandelt nur reine Importgruppen, keine gleichberechtigten Vernetzungen oder MausNet-eigene Gruppen. Nach einer Diskussion beschließen die Sysops folgende Regelung bei einer Gegenstimme und 3 Enthaltungen:
Importgruppen sollen die Orginalnamen des Herkunftsnetzes behalten bzw. den vom Herkunftsnetz gewünschten Namen tragen.
Bei Importen aus dem Z-Netz wird deshalb ein "ZNET." vorangestellt, so wie das vom Z-Netz gewünscht wird.
Die Sysops beschließen, daß Timm Ganske @ OF über die Namen von Gruppen aus FTN-Netzen entscheidet. Gruppen des FIDO-Netzes tragen den Vorsatz "fido.".
Die Namen der Importgruppen werden spätestens ab 1.11. durch den Netzgruppenkoordinator umgestellt. In diesem Zusammenhang beklagt der Gatewaykoordinator Peter Boehnke @ HB2, daß er über keine aktuellen Listen verfügt.
Dieser Punkt behandelt nur MausNet-eigene Gruppen, keine gleichberechtigten Vernetzungen oder Importgruppen.
Es existiert ein fertiger CFV für eine Umbenennung der MausNet-eigenen Gruppen. Die Sysops beschließen bei 10 Enthaltungen, diesen CFV den Usern unverzüglich zur Abstimmung vorzulegen.
Es steht zur Diskussion, ob MausNet-eigene Gruppen innerhalb des MausNet den Namensprefix "maus." führen sollen. Als Argument hiergegen wurde das >*Herkunftsflag genannt, durch das man auf diesen Prefix verzichten kann. Die Sysops beschließen bei 8 Gegenstimmen und 7 Enthaltungen, darüber sofort abzustimmen. Die Sysops lehnen den Prefix "maus." mit 3 Gegenstimmen und 2 Enthaltungen ab.
Ausgenommen davon sind Gruppen, die bereits jetzt ein "MAUS" im Namen haben *(MAUS, MAUS.INFO, etc.),sowie neue Gruppen, die aufgrund ihres Themas ein *'MAUS' im Namen haben.
>*Auf Anregung von Holger Dengler @ BB2 wünscht sich ein Teil der Sysops ein alternatives Netzprotokoll, dessen Spezifikation allgemein zugänglich sein soll. Holger Dengler ist Ansprechpartner für die Bildung einer Arbeitsgruppe, die sich mit diesem Thema beschäftigen wird.
Als Ziel soll eine zweite Schnittstelle alternativ zum Maustausch definiert werden, die u.a. auch Gruppen durchrouten kann.
Jörg Henne @ BB erläutert die Möglichkeit, Netzpakete mittels UUCP over TCP durch das Internet zu transportieren.
Die Sysops erheben keine Einwände gegen den Transport durch das Internet, wenn folgende Bedingungen erfüllt sind.
Die beteiligten Internet-Provider sind einverstanden.
Die Internet-Kontingente der Domain .maus.de werden nicht belastet.
Die Pakete werden unmittelbar vom Absender zum Empfänger transportiert. Ein Transport via Mail scheidet daher üblicherweise aus.
Die Pakete enthalten keinen Klartext. Sie sind möglichst mit geeigneten Methoden zu verschlüsseln.
Michael Keukert @ AC2 will die WWW-Präsenz des MausNet koordinieren. Jörg Henne @ BB kann einen WWW-Server für das Mausnet aufsetzen. Persönliche WWW-Seiten für einzelne User sind nicht vorgesehen.
Für die IN-Geschäftsstelle wird Infomaterial über das MausNet benötigt. Timm Ganske @ OF und Jürgen Conradi @ HB schreiben einen entsprechenden Text. Es gibt einen Mauskanal im IRC: #maustalk.
Es wird über die Vergabemodalitäten für regionale Netzgruppen diskutiert.
Es wird über folgende einander ausschließende Vorschläge abgestimmt:
a) | Jeder Maus steht genau eine regionale Gruppe zu, für die die
Maus verantwortlich ist. Die Verbreitung dieser Gruppe steht im
Belieben der verantwortlichen Maus.
|
b) | Solange es technisch möglich ist, werden regionale Gruppen
vom Netzgruppenkoordinator vergeben. Wenn die Gruppen knapp werden,
kann der Netzgruppenkoordinator nach Belieben regionale Gruppen
zurückverlangen.
|
c) | Jede Maus kann 3 regionale Gruppen führen. Darüber
hinausgehende Wünsche sind in Sysops vorzubringen und
durchzusetzen.
|
d) | Es werden keine weiteren regionalen Gruppen eingerichtet, da
regionale Verbindungen über Maus-2-Maus-Gates möglich sind
und netzweit lesbare Regionalgruppen wie normale Netzgruppen behandelt
werden können.
|
Enthaltungen: 3
Zwischen den Punkten a) und b) findet eine Stichabstimmung statt. Dabei erhält Punkt a) 33 Stimmen und Punkt b) 29 Stimmen. Damit wird Punkt a) angenommen.
Die Sysops heißen die bisherige Praxis, bei einem Betreiberwechsel in Sysop.info nachzufragen, ob Einwände bestehen, gut.
Bei einem Betreiberwechsel sind die datenschutzrechtlichen Probleme zu beachten, die durch die Weitergabe der Userdaten entstehen. Eventuell ist den Usern rechtzeitig Gelegenheit zu geben, ihren Usereintrag zu löschen.
Dem Team der Quark Heilbronn um Frauke Cremer gilt der besondere Dank der Sysops für die Organisation des diesjärigen Treffens.
Die Sysops beklagen die geringe Beteiligung am diesjährigen Treffen. Insbesondere wird das völlige Fernbleiben der Mausprogrammierer heftig kritisiert.
Es wird diskutiert, das nächste Treffen früher im Jahr zu stattfinden zu lassen. Die Sysops beschließen mit Mehrheit, beim bisherigen Termin zu bleiben.
Es wird diskutiert, ob die Einrichtung von Arbeitsgruppen sinnvoll ist. Ein Beschluß wird hierzu nicht gefaßt.
Die Mäuse HB und HB2 erklären sich bereit, das nächste Treffen auszurichten.
Maus Name AC2 Boris Meltzow AN Robert Lechler AN Gert Stamminger BB Jörg Henne BB Ulrich Frey BB2 Holger Dengler BB2 Sven Dittmar BL Volker Keck BL Carola Keck *GAST* (Frau von Volker Keck, kein Sysop) BM Markus Schmidke BOR Georg Feuersträter D Andreas Jülicher D Peter-F. Bajetto DO Björn Oste DO Stefan Hintz DO2 Uwe Blenz DO2 Andreas Rost DU Klaus Abele DU Thomas Neumann DU Georg Schroers DU3 Uwe Ohse FÜ Martin Schwenk FÜ Udo Fleckenstein GI Roman Kunz GI Horst Jünger GP Michael Wist H Friedrich Lämmle HAM Peter Huluk HAM Michael Scharfschwerdt HB Jürgen Conradi HB2 Peter Böhnke HH Harald Labeit HL Karsten Iwen HM Jens Lüthje HN Frauke Cremer HN Frank Dürring K2 Edgar Fuß KA Wolfgang Walter KA2 Ralf Urmersbach KI Klaus Atzpodien KN Andreas Rieck KN Martin Kürschner KN Matthias Kürschner KR Elmar Hoettges KR Henry Rolofs LB Uwe Seidler LI Horst Kollmuss LU Stefan Huerter LU Andreas Koegel LU Jochen Friedrich M2 Anselm Kruis MGN Falk Sauer MK2 Dirk Reinarz MK2 Martin Loos MS Michael Steinwachs MS Harald Krusekamp OF Timm Ganske OG Andreas Mandel OG Stefan Llabres OG Alexander Prontepcharon OS2 Thomas Meißner PB3 Frank Baumgart PB3 Dirk Hagedorn S Inge Meiser S Gerhard Meiser S3 Frithard Meyer-zu-Uptrup SB Torsten Engel SB Christian Philipp SB2 Harald Eckstein SU2 Juergen Lanzki SU2 Herbert Framke SZ Steffen Engel SZ Stefan Brix TBB Hans-Peter Bock UN Edgar Rosenboom UN Karl Reinberg WÜ Elke Freier Wü Fritz Elfert WÜ Roland Füssl ZW Andreas Mayer ZW Ulrich Pfisterer Macht zusammen 81 Teilnehmer, davon waren 80 stimmberechtigt. =============================================================
Für das Protokoll
Anselm Kruis @ M2
Michael Wist @ GP
Michael Kugelmann @ S5 (Überarbeitung)
Protokoll des MausNet© SysOp-Treffens 1996
Version 1.2 vom 18. Oktober 1996
Das SysOp-Treffen fand am 20. und 21. September 1996 im Jugendgästehaus in Bremen statt. Anwesend waren 79 SysOps aus 48 Mäusen. Unter den SysOps waren 74 männlichen und 5 weiblichen Geschlechts.
Die eigentliche Tagung fand am 21.09.1996 in der Zeit von 10:00 Uhr bis 17:30 Uhr statt. Sie wurde durch Mittagessen (12:30 Uhr) und Kaffeetrinken (16:00 Uhr) unterbrochen. Sebastian Hempel @ WUN und Thomas Meißner @ OS2 übernahmen die schwere Aufgabe der Protokollführer.
Die Tagung bestand aus zwei Teilen. Am Vormittag wurden in einzelnen Arbeitsgruppen verschiedene Themen diskutiert. Die Ergebnisse dieser Arbeitsgruppen wurden am Nachmittag im Plenum vorgetragen und evtl. Abstimmungen dazu durchgeführt. Den Vorstellungen der Arbeitsgruppen schloß sich eine Diskussion im Plenum zu allgemeinen Themen an.
Thema
Die Arbeitsgruppe beschäftigte sich mit den Umgangsformen im MausNet und denen von SysOps ("Du arrogantes Arschloch") oder anderen Usern mit Ämtern im speziellen.
Andreas Hoffmann @ K2
Ergebnisse
Im Allgemeinen werden die Umgangsformen im MausNet eingehalten. Bei öffentlichen Streitereien sollten sich andere User des öfteren per PM einmischen. Es kann jedoch Probleme geben, wenn einer der beteiligten Personen ein Amt (Betreiber, SysOp, AL-Team, etc.) inne hat und auch auf PMs nicht reagiert.
Um das Eskalieren von Streitereien in Zukunft zu vermeiden, wird von der Arbeitsgruppe die Einführung einer Schlichtungsinstanz (Schiedsgericht, Schiedsstelle) mit entsprechender Macht vorgeschlagen.
Die Arbeitsgruppe macht folgenden Vorschlag zum Profil des Schiedsteams.
In erster Linie ist das Schiedsteam für den Fall gedacht, daß ein Sysop oder Betreiber in eine Streitigkeit involviert ist.
Das Schiedsteam soll nur auf Anforderung hin aktiv werden. Hierfür müssen sich User aus mindestens 10% der Mäuse (auf 5er aufgerundet), mindestens aber aus 15 unterschiedlichen Mäusen beim Schiedsteam über einen User beschweren.
Das Schiedsteam entscheidet dann in relativ kurzer Zeit mit einfacher Mehrheit über evtl. Sanktionen. Als Sanktion ist das Abklemmen der die Streitigkeit betreffenden Gruppe(n) - SysOp-Gruppen für 7 Tage und (in letzter Konsequenz) User-Gruppen für 3 Tage - vorgesehen.
Die Kommunikation des Schiedsteams kann über eine eigene Gruppe, eine Mailingliste oder per Voice (Telefon) erfolgen.
Das Schiedsteam berichtet anschließend über die Entscheidung, inklusive einer kurzen Begründung. Diskussionsverlauf und Entscheidungsfindung müssen weder öffentlich verfolgbar ablaufen, noch nachträglich dokumentiert werden.
Eine Info-Mitteilung über das Schiedsteam wird regelmäßig in Maus.Info gepostet. In dieser Mitteilung soll darauf hingewiesen werden, daß die Anrufung des Schiedsteams das letzte Mittel ist. Vorher sollten alle anderen Möglichkeiten zur Schlichtung eines Streits (lokale Gespräche, Einschalten des SysOps, etc.) verwendet werden.
Das Schiedsteam soll 5 Mitglieder (ohne Vertreter) umfassen und eine unbeschränkte Amtszeit besitzen.
Das Schiedsteam entscheidet nur über die Form nicht jedoch über den Inhalt einer Diskussion. Es handelt sich um keine Moderation.
Abstimmungen
Soll ein Schiedsteam eingerichtet werden, das auf Anforderung hin über Sanktionen entscheidet? Als Sanktion ist hierfür das Abklemmen von Usergruppen für 3 Tage und für SysOp-Gruppen für 1 Woche vorgesehen.
Ergebnis: 38 dafür, 18 dagegen, 10 Enthaltungen (66)
Es wird ein Schiedsteam eingerichtet.
Das Schiedsteam wird erst auf Anforderung von Usern aus 5% der Mäuse, mindestens jedoch 3, hin aktiv.
Ergebnis: 54 dafür, 2 dagegen, 10 Enthaltungen (66)
Das Schiedsteam wird erst bei der Aufforderung von Usern aus 5% der Mäuse, mindestens jedoch aus 3 Mäusen, hin aktiv.
Sollen die Mitglieder des Schiedsteams auf dem SysOp-Treffen gewählt werden?
Ergebnis: 45 dafür, 9 dagegen, 12 Enthaltungen (66)
Die Mitglieder des Schiedsteams werden auf diesem SysOp-Treffen gewählt.
Es gibt 6 Vorschläge für die Mitglieder des Schiedsteams: Harald Krusekamp @ MS, Steffen Engel @ SZ2, Andreas Hoffmann @ K2, Marco Hahn @ SL, Philipp Oelwein @ HH2 und Marcus Ohlhaut @ BA. Es wird über jeden Vorschlag einzeln abgestimmt. Die 5 Vorschläge mit den meisten Stimmen werden Mitglieder des Schiedsteams.
Harald Krusekamp @ MS erhält 47 Stimmen
Steffen Engel @ SZ2 erhält 37 Stimmen
Philipp Oelwein @ HH2 erhält 31 Stimmen
Andreas Hoffmann @ K2 erhält 16 Stimmen
Marcus Ohlhaut @ BA erhält 17 Stimmen
Marco Hahn @ SL erhält 15 Stimmen
Somit besteht das Schiedsteam aus: Harald Krusekamp @ MS, Steffen Engel @ SZ2, Philipp Oelwein @ HH2, Andreas Hoffmann @ K2 und Marcus Ohlhaut @ BA.
Thema
Die Arbeitsgruppe beschäftigte sich mit dem Verhältnis zwischen Usern und SysOps.
Karl Reinberg @ UN
Ergebnisse
Das Mißtrauen einiger User gegenüber den SysOps entsteht aufgrund der mangelnden Information der User über die Aufgaben, Möglichkeiten und Tätigkeiten der SysOps. Die Einführung eines MausRates, wie er in den letzten Monaten in der Gruppe Maus diskutiert wurde, ist zur Lösung dieses Problem ungeeignet. Außerdem hat eine Umfrage unter den Usern gezeigt, daß von der Mehrheit der User ein MausRat auch nicht gewünscht wird.
Die Arbeitsgruppe schlägt die Einführung eines neuen Infofiles vor. In diesem Dokument soll über die Aufgaben, Rechte und Pflichten der einzelnen Personen mit entsprechendem Userstatus (Betreiber, SysOp, Programmteilwart, Gruppenchef, AL-Team) informiert werden. Durch dieses Infofile soll auch über die Pflichten des SysOp aufgeklärt werden. Axel Katerbau @ BM erklärt sich dazu bereit die Erstellung dieses Dokuments in Maus.Doku zu koordinieren.
Der Einführung eines derartigen Infofiles wird allgemein zugestimmt, weshalb keine Abstimmung darüber notwendig ist.
Die Usermitbestimmung in technischer Hinsicht kann nur vorschlagenden Charakter haben. Wie auch die SysOps den MAUS-Programmierern nur Vorschläge machen können. Die Mitbestimmung der User auf administrativer Ebene ist eine Angelegenheit der lokalen Autonomie.
Die Beteiligung der User an der Netzpolitik kann u.a. durch die Information der User über Diskussion in der Gruppe SysOps verbessert werden. Die Informationen beschränken sich dabei auf das Thema und nicht auf den Inhalt der Diskussion. Diese Information auf lokaler Ebene wird jeder MAUS im MausNet empfohlen.
In der anschließenden Diskussion wird die u.U. recht lange Antwortzeit von Mitteilungen an SysOp @ MAUS moniert. Es wird eine allgemeine Empfehlung ausgesprochen, daß Mitteilungen an den WoSy einer MAUS innerhalb von 3 Tagen zu beantworten sind.
Über die Mitleser in den technischen SysOp-Gruppen von Fremdmäusen (kommerzieller Einsatz der MAUS-Software) wird abgestimmt. Es wird darauf hingewiesen, daß nur im ISB eingetragene Personen lesenden Zugriff auf SysOp-Gruppen haben dürfen.
Abstimmungen
SysOps von Fremdmäusen werden als Gast-SysOp im ISB eingetragen. Als Kürzel wird hierbei das Kürzel der Fremdmaus eingetragen.
Ergebnis: 56 dafür, 1 dagegen, 13 Enthaltungen (70)
SysOps von Fremdmäusen werden in obiger Form im ISB eingetragen.
Thema
Die Arbeitsgruppe behandelte die Problematik der IN-Teilnahme und die Frage, ob alle Mäuse verpflichtend Mitglieder einer Domain sein müssen. Anselm Kruis @ M2
Ergebnisse
Mitteilungen von Mäusen, die nicht am IN teilnehmen, werden nicht exportiert werden. Desweiteren ergibt sich die Problematik, daß auf öffentliche Mitteilungen aus diesen Mäusen keine privaten Kommentare geschrieben werden können. Diesen Umstand könnte man u.U. durch eine entsprechende Absenderangabe kenntlich machen, die von den Gateways mit einem Bounce behandelt wird.
Es können nicht alle Mäuse an der Teilnahme am IN verpflichtet werden, wenn sie bereits über einen kommerziellen Provider versorgt werden. In der Arbeitsgruppe wurde auch überlegt, die Domain maus.de aus dem IN zu nehmen. Diese Überlegungen zielen jedoch auf die ferne Zukunft hin.
Es wird jeder MAUS dringend empfohlen, Mitglied einer Domain zu sein.
Thema
Die Arbeitsgruppe beschäftigte sich mich mit Regeln zum Kommerz in den MausNet-Gruppe und der Werbung in der MAUS selbst.
Patrick Jerchel @ B
Ergebnisse
Der lokale Kommerz ist aufgrund der lokalen Autonomie erlaubt. Es wird zwischen dem Kommerz von Seiten des Betreibers, dem Kommerz durch einen Sponsor und dem Kommerz durch Dritte im allgemeinen unterschieden. Der Kommerz kann in lokalen Gruppen, dem InfoFile Kommerz und durch entsprechende Hinweise in mtitel.dat und mende.dat erfolgen.
Die Arbeitsgruppe möchte auf dem SysOp-Treffen Entscheidungen über den Status von lokalen Kommerzgruppen (Pflicht und/oder Default), den Hinweis auf lokale Kommerzgruppen und dem Umfang von Kommerz in Titel und Abspann erreichen. Der lokale InfoText über Kommerz bleibt weiterhin zur freien Verfügung.
Des weiteren soll über die Verwendung der MausNet-Adresse - nicht der IN-Adresse - für kommerzielle Belange entschieden werden. In diesem Zusammenhang soll auch der Status der Chef-Adressierung und der Verwendung von Weiterleitungsdämonen geklärt werden.
Die Arbeitsgruppe diskutierte auch über den MausNet-weiten Kommerz und den erlaubten Umfang. Zur Entlastung der *.news Gruppen von kommerziellen Mitteilungen wird die Gründung einer MausNet-weiten Kommerzgruppe vorgeschlagen. Kommerzielle Mitteilungen könnten in dieser Gruppe kanalisiert werden. Die Diskussion über die Inhalte der *.news Gruppen konnte aus zeitlichen Gründen nicht erfolgen. Über den Umfang von Postings in diesen Gruppen wird daher in der Gruppe info.temp diskutiert.
Abstimmungen
Dürfen kommerzielle lokale Gruppen den Pflicht-Status haben?
Ergebnis: 0 dafür, 68 dagegen, 3 Enthaltungen (71)
Lokale kommerzielle Gruppen dürfen nicht den Status Pflicht haben.
Darf eine lokale kommerzielle Gruppe den Status Default haben, wenn der Benutzer darauf hingewiesen wird, wie er diese wieder abstellen darf?
Ergebnis: 24 dafür, 31 dagegen, 13 Enthaltungen (68)
Eine lokale kommerzielle Gruppe darf nicht den Status Default haben.
Darf in lokalen Pflichtgruppen auf die Existenz von lokalen kommerziellen Gruppen hingewiesen werden?
Ergebnis: 31 dafür, 19 dagegen, 19 Enthaltungen (69)
In lokalen Pflichtgruppen darf auf die Existenz von lokalen kommerziellen Gruppen hingewiesen werden.
Im Titel darf ein Hinweis (1 Zeile) auf kommerzielle Gruppen bzw. den kommerziellen Inhalt gegeben werden.
Ergebnis: 59 dafür, 7 dagegen, 3 Enthaltungen (69)
Im Titel der MAUS darf ein Hinweis (1 Zeile) auf die kommerzielle Gruppe gegeben werden.
Im Abspann der MAUS dürfen 5 Zeilen (incl. Sternchen) für kommerzielle Belange verwendet werden.
Ergebnis: 32 dafür, 22 dagegen, 11 Enthaltungen (65)
Der Hinweis auf kommerzielle Belange darf im Abspann durch 5 Zeilen erfolgen.
Darf die MausNet-Adresse (Realname) nach außen hin für kommerzielle Belange verwendet werden?
Ergebnis: 44 dafür, 5 dagegen, 17 Enthaltungen (66)
Die MausNet-Adresse (Vorname Nachname @ MAUS-Kürzel) - nicht die maus.de Adresse (Vorname_Nachname@MAUS-Kürzel.maus.de) - darf für kommerzielle Belange verwendet werden.
Darf die technische Adressierung (Info-Account, Chef) nach außen hin für kommerzielle Belange verwendet werden?
Ergebnis: 1 dafür, 56 dagegen, 9 Enthaltungen (66)
Die technische Adressierung darf nach außen hin nicht für kommerzielle Belange verwendet werden.
Darf bei Fragen in öffentlichen (netzweiten) Gruppen öffentlich mit kommerziellen Inhalten geantwortet werden?
Ergebnis: 0 dafür, 51 dagegen, 15 Enthaltungen
Es darf auf öffentliche Anfragen nicht öffentlich mit kommerziellen Inhalten geantwortet werden.
Soll eine neue (netzweite) Gruppe zur Kanalisierung von kommerziellen Inhalten gegründet werden?
Ergebnis: 21 dafür, 37 dagegen, 8 Enthaltungen
Es wird keine kommerzielle Gruppe im MausNet gegründet.
Thema
Die Arbeitsgruppe beschäftigte sich mit dem Problem von Hackern und "Megahackern".
Holger Wulfers @ HB
Ergebnisse
Die beste Gegenmaßnahme gegen Hacker ist die Aufklärung der SysOps über Sicherheitslöcher und deren Beseitigung. Die beste technische Maßnahme gegen evtl. Zerstörungen ist das Backup.
Für das Verhalten bei sogenannten Megahackern kann keine Empfehlung gegeben werden. Es gibt auch keine Maßnahmen durch die derartige Zwischenfälle vermieden werden können. Es wird der Hinweis gegeben, daß eine dauerhafte Kontrolle der Inhalte nicht notwendig ist. Der SysOp muß erst Handeln, wenn er von verbotenen Inhalten Kenntnis erlangt (z.B. durch Hinweise von Usern).
Thema
Die Arbeitsgruppe beschäftige sich mit den Themen
Headerei, Quoterei, Footerei
PGP-Signierung von öffentlichen Mitteilungen
Pseudos und dem Problem des Doppelaccounts
Markus Ohlhaut @ BA
Ergebnisse
Der Status von Headern, dem Quoteverhältnis und Footern wird wie bisher beibehalten. Header, übermäßige Quotes und Footer sind zu unterlassen. Die PGP-Signierung von öffentlichen Mitteilungen ist nicht erwünscht. Nur für gewisse Mitteilungen mit wichtigem bzw. dokumenthaftem Charakter ist eine Ausnahme erlaubt. Außerhalb von Info- und News-Gruppen wird die Signierung als Footer angesehen.
Zu Pseudos bzw. dem Problem des Doppelaccounts findet eine Abstimmung statt.
Abstimmungen
Pro natürliche Person, pro MAUS ist nur ein Account zum Schreiben ins Netz unter Realname erlaubt.
Ergebnis: 64 dafür, 3 dagegen, 3 Enthaltungen (70)
Pro natürlicher Person ist pro MAUS nur ein Account zum Schreiben ins Netz unter Realname erlaubt. Bestehende Doppelaccounts sind von dieser neuen Regelung betroffen!
Thema
Die Arbeitsgruppe behandelte die Umbenennung der MausNet-Gruppen. Durch die Verwendung von langen Gruppennamen sollen die MausNet-Gruppen in Hierarchien gruppiert werden. Für diese Gruppierung existieren verschiedene Vorschläge. Karsten Iwen @ HL
Ergebnisse
Durch die Abwesenheit von Andreas Mayer @ ZW, der bereits verschiedene Vorschläge gesammelt hat, konnte diese Arbeitsgruppe keine Ergebnisse liefern. Da die Vorschläge nicht vorlagen, konnte auf dem Treffen auch keine Abstimmung über die verschiedenen Vorschläge durchgeführt werden.
Ab dem 23.09. wird daher in der Gruppe Importgruppen.Rahmendiskussion eine endgültige Ausarbeitung des CfVs zum "Great Renaming" durchgeführt. Neben Karsten Iwen @ HL haben sich Friedrich Lämmle @ H, Uwe Ohse @ DU3, Peter Böhnke @ HB2 und Peter Redecker @ BOR bereit erklärt die Ausarbeitung zu übernehmen.
Themen
Die Arbeitsgruppe behandelte verschiedene Themen zu Gateways.
zukünftiger Status von Kreuzvernetzungen
Transitproblematik und Strategien zur Dupevermeidung
Mindestanforderungen an Gateways
Georg Bauer @ MS3
Ergebnisse
Außer den Gruppen Netzwesen, Gateways und Gatebau werden alle Kreuzvernetzungen in nächster Zeit aufgelöst. Bei allen anderen Gruppen wird einem der an der Kreuzvernetzung beteiligten Netze die Gruppe zugesprochen und deren Name für die Gruppe übernommen. Neue Kreuzvernetzungen werden nicht mehr eingerichtet. Bei der Gründung einer Gruppe ist deren Exportname festzulegen, an den sich alle anderen Netze halten müssen.
Die Transitproblematik - z.B. Zustellung einer Mitteilung vom Internet an das FidoNet über das MausNet - wird durch verschiedene Maßnahmen beseitigt. Die Maßnahmen tragen außerdem zur Vermeidung von Dupes bei.
Das einheitliche Splitting von Mitteilungen am Gateway und deren Kennzeichnung ist bereits geregelt, wird aber noch nicht von allen Gateways unterstützt.
Die Header-Zeilen sender, follow-up und reply-to werden in einer der nächsten MAUS-Versionen verfügbar sein. Sobald diese Zeilen implementiert sind, werden sie auch von Gateways verwendet werden.
Nicht mehr exportierbare Mitteilungen sollten von Gateways gekennzeichnet werden. Dies ist z.B. bei Crosspostings notwendig, da durch den Wegfall von Header-Zeilen ein vernünftiger Export nicht mehr möglich ist.
Beim Import von Mitteilungen aus dem MausNet ist die kurze MsgID aus der langen MsgID zu extrahieren und zu verwenden.
Die Gateways verwenden die Domain-Einträge der einzelnen EXP-Files um den einzelnen Mäusen die korrekte Domain zuzuordnen. In der MsgID selbst wird allerdings immer die Domain maus.de verwendet.
Das Weiterleiten einer Mitteilung aus dem Internet an eine MausNet Adresse und weiter an eine Internet Adresse ist erlaubt.
Durch obige Maßnahmen ist ein Transit von Mitteilungen durch das MausNet kein Problem mehr.
In der weiteren Diskussion wurden folgende Mindestanforderungen für Gateways im MausNet festgelegt. Die genauen Mindestanforderungen sollen bis 31.10.1996 inhaltlich mit den anderen Gateway-Programmierern in den entsprechenden Gruppen abgesprochen werden.
Die Splittingkonventionen müssen realisiert werden.
Sender/Reply-To/Followup-To müssen unterstützt werden, sobald sie verfügbar sind.
Mitteilungen, die beim Import so verändert werden, daß ein Export nicht sinnvoll ist, müssen geeignet gekennzeichnet werden. Entsprechend gekennzeichnete Mitteilungen dürfen an anderen Gates nicht exportiert werden. Was zu einer Kennzeichnung führt, muß in Zusammenarbeit der Programmierer ausgearbeitet werden.
Der Pathhack (news.maus.de in den Path eintragen) wird nur noch für Fremdnetzmitteilungen gesetzt. Bei Mausmitteilungen wird er weggelassen. Statt dessen werden bei Mausmitteilungen beim Reimport aus der langen Message-ID die kurze Id ermittelt und als Temp-ID verwendet.
Als Absenderadressen sind die Angaben aus der D-Zeile im EXP zu verwenden. Mäuse ohne D-Zeile werden nicht exportiert.
Transit von Mail, verursacht durch den PM-Forwarder (Usenet an Maus weitergeleitet an Usenet) muß erlaubt sein.
Die Konventionen zur M-Zeile müssen implementiert sein (rudimentäre Mime-Unterstützung)
Das Bouncen von öffentlichen Mitteilungen ist verboten. Am Rande der Diskussion wurde die Gruppe SysOp.Gate als "offizielle" Gruppe für Diskussionen zu Gateways im MausNet festgelegt.
Thema
Die Arbeitsgruppe diskutierte die derzeitige Problematik des AL-Teams, den Modus für Neuwahlen, die Länge der Amtszeit und die Möglichkeit zur Beteiligung von Usern am AL-Team.
Thomas Meißner @ OS
Ergebnisse
Die Arbeitsgruppe schlägt die Aufteilung des AL-Teams in ein SysOp- und ein User-Team vor. SysOp- und User-Team sind getrennt. Das User-Team bearbeitet die Abstimmungen auf Userseite, das SysOp-Team kümmert sich ausschließlich um SysOp-Abstimmungen und "kontrolliert" das User-Team.
In der anschließenden Diskussion werden weitere Möglichkeiten zur Entlastung des AL-Teams angesprochen. So wird vorgeschlagen, daß User automatisch einen CfO zur Einrichtung einer neuen Gruppe durchführen können, wenn sie auf die Anfrage beim AL-Team keine negative Antwort bekommen. Auch könnte die derzeitige Struktur des AL-Teams (nur SysOps) beibehalten werden, wenn das AL-Team Aufgaben delegieren könnte und somit nur noch koordinierende Aufgaben hat.
Es wird vorgeschlagen, daß das AL-Team als erste Handlung nach seiner Wahl den nächsten Wahltermin festlegt. Somit könnte die derzeitige Situation - AL-Team ist weit über seine eigentliche Amtszeit immer noch im Amt - vermieden werden. Es wird festgelegt, daß das AL-Team regulär im Netz zu wählen ist. Nur in Ausnahmefällen soll eine Wahl auf dem SysOp-Treffen stattfinden.
Von den derzeitigen Mitgliedern des AL-Teams wird angeregt, einen einzigen Abstimmungsdämon im MausNet zu installieren. Bisher habe jedes AL-Teams seinen eigenen Dämon verwendet. Der Dämon des derzeitigen AL-Teams befindet sich in FÜ und kann von außen nicht betreut und "bedient" werden. Markus Schmidke @ BM erklärt sich bereit, bis 19.10. einen funktionsfähigen Abstimmungsdämon zu programmieren. Jürgen Conradi würde ihn in der HB installieren. Der Dämon soll in Zukunft von allen AL-Teams verwendet werden.
Abstimmungen
Sollen User am AL-Team beteiligt werden?
Ergebnis: 28 dafür, 35 dagegen, 9 Enthaltungen (72)
Das AL-Team wird weiterhin nur aus SysOps bestehen.
Soll das AL-Team ermächtigt werden, Aufgaben an User zu übertragen?
Ergebnis: 71 dafür, 1 dagegen, 1 Enthaltung (73)
Das AL-Team darf Aufgaben in Zukunft an User übertragen.
Soll das AL-Team auch weiterhin aus 3 Personen bestehen?
Ergebnis: 73 dafür, 0 dagegen, 0 Enthaltungen (73)
Das AL-Team besteht aus 3 Personen.
Soll die Amtsdauer des AL-Teams 1 Jahr betragen?
Ergebnis: 68 dafür, 0 dagegen, 3 Enthaltungen (71)
Die Amtszeit des AL-Teams beträgt 1 Jahr
Soll das AL-Team jetzt sofort auf dem SysOp-Treffen gewählt werden?
Ergebnis: 12 dafür, 35 dagegen, 18 Enthaltungen (65)
Das AL-Team wird nicht auf dem SysOp-Treffen gewählt.
Soll das AL-Team in spätestens einem Monat gewählt werden?
Ergebnis: 52 dafür, 1 dagegen, 12 Enthaltungen (65)
Das AL-Team wird in spätestens einem Monat im Netz gewählt.
Jörg Stattaus @ W2 berichtet vom derzeitigen Status der Netzzentrale in Aachen (AC).
Frank Berger arbeitet in Paris und kommt nur jedes 2. Wochenende nach Aachen. Der andere SysOp der MAUS Aachen (Robert Hecht) kann ebenfalls aus Zeitgründen nicht schnell auf evtl. Probleme reagieren. Frank möchte daher aus zeitlichen Gründe die MAUS Aachen und damit die Netzzentrale abgeben.
Michael Keukert @ AC2 hat sich lokal bereits angeboten, die AC und damit die Netzzentrale als Zweitmaus zu übernehmen. Für die Übernahme der Zentrale haben sich ebenfalls "Fritz mit dem langen Namen" (Frithard Meyer-zu-Uptrup @ S3) und Friedrich Lämmle @ H bereit erklärt.
Die Entscheidung über den Standort der neuen Netzzentrale wird vertragt und in den SysOp-Gruppen besprochen.
Das einzige MausTausch-FrontEnd, das in dieser Hinsicht aus der Reihe tanzte, war CrossPoint von Peter Mandrella @ LU. Peter ist derzeit dabei, die Unstimmigkeiten zu beseitigen. Somit besteht kein Diskussions- und Handlungsbedarf in dieser Hinsicht.
Jörg Stattaus @ W2 erstattet als einziger anwesender Programmierer der MAUS-Software Bericht.
Kai Henningsen @ MS ist nicht mehr im Programmier-Team der MAUS dabei. Frithard Meyer-zu-Uptrup @ S3 ist seit diesem Jahr neu in das Team eingestiegen. Er kümmert sich um die OS/2-Umsetzung der MAUS und den Programmteil. Die Portierung der MAUS auf OS/2 ist größtenteils abgeschlossen. Es fehlen nur noch Feinheiten und die Fossil-Unterstützung. Nach der Portierung will sich Fritz um den Programmteil kümmern. Er übernimmt dafür die Sourcen von Achim Reinhardt und wird wohl als erstes den SaugTausch implementieren.
Die Sourcen der OS/2-MAUS sind übrigens mit denen der normalen MAUS unter DOS identisch. Die verschiedenen Versionen werden durch Compilerschalter realisiert. Die beiden Versionen (DOS und OS/2) werden daher immer den gleichen Stand haben.
Die MessageBase der MAUS 9 ist von Jörg fertig "designed" und basiert auf dem MausTausch-Format. Das Format kann daher in Zukunft beliebig ohne größere technische Probleme erweitert werden. Der MausTausch kann durch das neue MessageBase-Format sehr einfach implementiert werden. Es existiert bereits ein Importer/Exporter in einer Alpha-Version, der die bisherigen Netzpakete in die neue MessageBase einsortieren bzw. daraus erzeugen kann.
Gereon Steffens @ K2 kümmert sich derzeit um die laufende Wartung der MAUS-Software (Bugfixes, neue Features). Gereon ist im Gegensatz zu Jörg etwas skeptischer, was die Realisierung der MAUS 9 angeht.
Durch die neue Arbeitsstelle hat Jörg jedoch weniger Zeit für die Programmierung der Software. Er ruft deshalb interessierte und motivierte Programmierer zur Mitarbeit im Programmierer-Team auf. Georg Bauer wird sich um die Weiterentwicklung des FidoNet-Gateway kümmern.
Uwe Ohse @ DU3 berichtet über den derzeitigen Stand der Quark.
Die Quark kann bei der derzeitigen Struktur des MausNet nicht als Standardmaus eingesetzt werden. Der Austausch von Netzpaketen funktioniert derzeit nur zwischen Quarks. Eine Abhilfe ist evtl. durch die MAUS 9 möglich.
Ansonsten ist die Entwicklung soweit abgeschlossen. Auch er ruft interessierte Programmierer zur Mitarbeit an der QUARK auf. In Zukunft ist u.a. die MultiPort-Fähigkeit der QUARK-Software vorgesehen.
Das Umpacken von Shareware ist nach dem Urheberrechtsgesetzt verboten.
Durch den Paragraph 2 des Urheberrechtsgesetzes fällt auch Shareware bzw. Software im allgemeinen unter die Regelungen dieses Gesetzes. Im Paragraph 17 dieses Gesetzes wird das Verbreitungsrecht geregelt. Durch diesen Paragraph ist das Umpacken und Hinzupacken gesetzlich verboten. Der Autor von Shareware gibt die Art der Verbreitung vor. Ein Umpacken der Archive bzw. ein Hinzupacken von weiteren Dateien ist somit nicht erlaubt.
Das Umpacken von Archiven kann u.U. auch Überprüfungen auf die Authentizität unmöglich machen. Einige Packformate erlauben dieses Verfahren, damit man die Veränderung von Originalarchiven erkennen kann.
FidoNet-Gateways
Timm Ganske @ OF berichtet über den Stand der Gateways zum FidoNet. Er beschäftigt sich derzeit mit der Erstellung von Pseudo-Rules, die für exportierte MausNet-Gruppen im FidoNet gelten sollen. Auch ist er um die Zusammenstellung einer Liste aller ins FidoNet exportierten Gruppen bemüht.
Die Verbreitung der MausNet-Gruppen im FidoNet beschränkt sich auf Inseln. Tests haben ergeben, daß nur kleine Bereiche des FidoNet mit MausNet-Gruppen versorgt werden. Es wird daher der Export von Mitteilungen an allen FidoNet-Gateways aktiviert. Sobald es zu Dupes kommen sollte, sind entsprechende Maßnahmen sofort einzuleiten.
GerNet-Gateway
Michael Keukert @ AC2 kann nichts besonderes über das Gateway zum GerNet in AC2 berichtet. Er weist jedoch auf das Vorhandensein von weiteren Areas außer der ins MausNet importierte Area ct hin. Wenn Interesse am Import dieser Areas besteht, können diese sofort in AC2 importiert werden.
TK-Gesetz und Auswirkungen auf das MausNet
Die Auswirkungen des neuen TK-Gesetzes sollten von Leuten mit juristischem Hintergrundwissen untersucht werden. Interessant in diesem Zusammenhang ist u.a. die Definition von geschäftsmäßig, die schon bei der Anmeldung von privat geführten Mailboxen beim BAPT eine Rolle gespielt hat. Auch der Unterschied zwischen den Begriffen Dienst und Dienstleistungen könnte für die Auswirkungen des TK-Gesetzes auf das MausNet relevant sein.
Es wird die Einrichtung einer temporären, MausNet-weiten Gruppe zu diesem Thema vorgeschlagen. In dieser Gruppen sollen auch User beteiligt werden.
Das SysOp-Treffen 1997 findet in Bamberg statt. Für 1998 hat sich der Frankfurter Raum als Austragungsort des SysOp-Treffens angeboten.
Teilnehmerliste
MAUS Vorname Name AC2 Boris Meltzow AC2 Michael Keukert AC2 Stefan Rupp A-W Thomas Moser AN Gert Stamminger B Christian Goßlar B Patrick Jerchel BA Marcus Ohlhaut BA Martin Schwenk BA Michael Neumann BB Ulrich Frey BIR Ulrich Schilken BM Axel Katerbau BM Marcus Schmidke BOR Georg Feuersträter BOR Peter Redecker D Andreas Jülicher DO2 Udo Erdelhoff DO2 Uwe Blenz DU Georg Schroers DU Klaus Abele DU Michael Wolf DU3 Uwe Ohse EL Uwe Sonntag GP Michael Wist H Friedrich Lämmle HB Holger Wulfers HB Jürgen Conradi HB Mick Schmidt HB Rosi Brase HB2 Olaf Peters HB2 Peter Böhnke HB2 Thomas Wilkens HB2 Volkmar Jürgens HH Harald Labeit HH2 Philipp Oelwein HH3 Gunnar Landgrebe HL Karsten Iwen HM Ingolf Heilemeier HM Jens Lüthje HRO Andreas Klebow K2 Andreas Hoffmann KI Klaus Atzpodien KR Henry Rolofs LB Andreas Frank LB Uwe Seidler LU Andreas Kögel LU2 Frank Roeske LU2 Stefan Huerter M2 Anselm Kruis MK2 Dirk Reinarz MK2 Martin Loos MS Harald Krusekamp MS Michael Steinwachs MS3 Georg Bauer OF Jens Hefter OF Marc Hefter OF Timm Ganske OF2 Frederico Hernandez-Püschel OG Alexander Porntepcharoen OG Andreas Mandel OG Patrik Schindler OS2 Thomas Meißner S Gerhard Meiser S5 Inge Meiser S5 Michael Kugelmann SL Marco Hahn SZ Steffen Engel TBB Hans-Peter Bock TBB Stefan Heidrich UN Edgar Rosenboom UN Karl Reinberg UN Rosemarie Rosenboom W2 Jörg Stattaus WHV Silke Tintelott WHV Thomas Morgenthaler WUN Sebastian Hempel WÜ Elke Freier WÜ Roland Füßl
Am 21. September 1996 wurde in Bremen beim SysOp-Treffen die Wahl des schönsten Sysops durchgeführt.
Nun möchten wir den "normalen" ;-) Usern nicht vorenthalten, welche Herren dort von einer fachkundigen Jury - bestehend aus 5 weiblichen Sysops - zu den schönsten Sysops im MausNet gewählt wurden.
Vielleicht kann man ja ein bewunderndes Pfeifen in die nächste Mail einbauen, mit der man sich jetzt endlich mal zum Maustreffen anmeldet, weil die Neugierde einfach zu groß ist. ;-)
Marcus Schmidke @ BM
Jörg Stattaus @ W
Timm Ganske @ OF, Harald Krusekamp @ MS
Sebastian Hempel @ WUN
Dirk Reinarz @ MK2, Peter Böhnke @ HB2
Karsten Iwen @ HL, Patrick Jerchel @ B, Martin Schwenk @ BA
Peter Redecker @ BOR, Roland Füßl @ WÜ, Stefan Heidrich @ TBB
Hans-Peter Bock @ TBB, Ulrich Frey @ BB, Markus Ohlhaut @ BA,
Thomas Morgenthaler @ WHV, Uwe Ohse @ DU3
Uwe Seidler @ LB, Andreas Hoffmann @ K2
Steffen Engel @ SZ, Harald Labeit @ HH
Protokoll SysOp-Treffen 26.-28.09.1997 in Bamberg
Protokoll: Matthias Stürmer und Stefan Heidrich
Begrüßung durch das Orga-Team
"Wahl" der Protokollanten
Arbeitsgruppenfestlegung
hierarchische Gruppennamen
neue Verfahren zum Netzgruppen löschen
Import-Präfix
Maus Hilfsfond
Mauswerbung
Netzziele
Mails/News netzweit löschen
SPAM
Pflege der EXPs
User abmahnen
Warum machen wir SysOp-Abstimmungen
Verhalten der SysOps gegenüber dem AL-Team, Vorschläge, etc.
Maus 9
Offenlegung des MausNet-Protokolls
Maus- und MausNet-Sourcen (in Pascal) sind freigegeben und werden
über Gereon Steffens @ K2 zentral verwaltet, damit nicht mehrere
Versionen gleichzeitig im Umlauf sind. Jeder darf für seinen
persönlichen Gebrauch daran herumbasteln, solche Versionen dürfen
aber nicht verbreitet werden.
Die Sourcen zur Maus 9 sind (noch) nicht frei, da sie noch in Arbeit
sind. Die Maus 9 soll dann einen Konverter für die Datenbank von alt
auf neu bekommen, er ist aber noch nicht verfügbar.
Die MausNet-Gruppen sollen hierarchisiert werden. Dazu ist es laut Uwe
Ohse technisch nötig, entweder die Mausgruppen oder die importierten
Gruppen mit einem einheitlichen Präfix zu versehen.
Ein Importpräfix wurde von den SysOps bereits beschlossen. Laut
Aussage von Udo Erdelhoff exportiert das Usenet Gruppen nur noch, wenn im
Importnetz die Gruppennamen gleich der Usenet-Gruppennamen sind. Ein
Importpräfix ist deshalb nicht durchsetzbar, da sonst der Import
eingestellt werden müsste.
Zum Export von MausNet-Gruppen ist es sinnvoll, dass die Mausgruppen
einen Präfix bekommen: "maus.*". Deshalb ist es auch sinnvoll,
diesen Mauspräfix intern zu benutzen, so dass intern und beim Export
die gleichen Gruppennamen benutzt werden.
Da eine solche Hierarchie incl. des Maus-Präfixes aber auf
Widerstand stößt, wurde von Andreas Mayer angeregt, dass ein
Aliasnamen parallel zum technischen Gruppennamen im ITG eingeführt
wird. Laut Jörg Stattaus ist eine solche Maßnahme technisch
möglich. Den Frontend-Autoren wird nahegelegt, diese Aliasnamen
möglichst bald zu unterstützen. Zum Verfahren zur
Netzgruppenlöschung wurde angeregt, das gleiche Verfahren wir bei der
Gruppeneinrichtung zu benutzen. Dazu stellt der Netzgruppen-Koordinator im
eigenen Ermessen fest, welche Gruppen gelöscht werden könnten. Er
führt dann eine Abstimmung in der entsprechenden Gruppe durch. Bei
gleicher Anzahl von Pro-Stimmen, die bis jetzt auch zur
Gruppenneueinrichtung nötig waren, wird die Gruppe beibehalten,
ansonsten wird die entsprechende Gruppe geschlossen.
Teilnehmer der Arbeitsgruppe:
Adrian Reyer, Peter Bajetto, Jörg Stattaus, Arnd Graefe, Uwe Ohse, Wolfgang Walter, Matthias Stürmer, Falk Sauer, Michael Scharfschwerdt, Wolfgang Völker, Udo Erdelhoff, Martin Loos, Andreas Mayer, Bernd Dierolf, Michael Goldbach, Georg Feuersträter, Dirk Reinarz, Gerhard Meiser, Andreas Kogel, Stefan Heidrich
Abstimmung im Plenum:
Frage: | Wollen wir eine Änderung des Gruppennamenkonzepts in Richtung langer, technischer Gruppennamen? |
Pro: | 62 |
Contra: | 3 |
Enthaltungen: | 9 |
Ergebnis: | Damit werden die langen Gruppennamen eingeführt. |
In einigen Fällen ist eine Abmahnung von Usern durch andere User und/ oder SysOps bzw. das in Rechnung stellen von Kosten durch das Löschen und transportieren von Mails (hier: Kettenbriefen) vorgekommen. Rechtliche Möglichkeiten dies zu unterbinden gibt es keine. Es wurde vorgeschlagen, eine Absichtserklärung - ähnlich dem PM-Manifest - zu beschließen, dass Maus-SysOps solche Abmahnungen oder ähnliches unterlassen.
Teilnehmer an der Arbeitsgruppe:
Jürgen Affenzeller, Michael Goldbach, Dirk Reinarz, Thomas Niering, Bernd Dierolf, Jochen Friedrich, Torsten Hallmann, Peter Böhnke, Adrian Reyer, Uwe Ohse, Arnd Graefe, Stefan Heidrich
Abstimmung im Plenum:
Frage: | Verpflichten wir uns, Maus-Usern, die öffentlich nichtkommerziellen Mist bauen, keine Abmahnung zu schicken? |
Pro: | 50 |
Contra: | 1 |
Enthaltungen: | 15 |
Ergebnis: | Es werden keine Maus-User abgemahnt, wenn sie nichtkommerziellen Mist bauen. |
Abstimmung im Plenum:
Frage: | Verpflichten wir uns, Maus-Usern, die kommerziellen Mist schreiben, keine Abmahnung zu schicken? |
Pro: | 12 |
Contra: | 30 |
Enthaltungen: | 24 |
Ergebnis: | Maus-User, die kommerziellen Mist bauen, dürfen abgemahnt werden. |
Abstimmung im Plenum:
Frage: | Verpflichten wir uns, Nicht-Mausern, die Mist schreiben keine Abmahnungen zu schicken? |
Pro: | 5 |
Contra: | 36 |
Enthaltungen: | 24 |
Ergebnis: | Nicht-Maus-User dürfen abgemahnt werden, wenn sie Mist bauen. |
Aufhänger an der Diskussion waren die finanziellen Schwierigkeiten
des Betreibers der Maus Cottbus.
Die Diskussion in der Arbeitsgruppe teilte sich in einen Hardwarefond
und einen Finanzfond.
Hardwarefond
Der Hardwarefond soll einspringen, wenn eine Maus durch einen Defekt
plötzlich Ersatzhardware benötigt. Nun stellte sich die Frage, ob
das - wie bisher - regional regelbar sein sollte oder ob es einen
netzweiten Koordinator geben sollte, der weiß, wo Hardware zu
bekommen ist und eine Liste über verfügbare Einzelteile
führt. Christian Goßlar @ B würde sich für diesen
Posten zur Verfügung stellen.
Abstimmung im Plenum:
Frage: | Ist es gewünscht, einen Hardwarefond einzurichten? |
Pro: | 46 |
Contra: | 8 |
Enthaltungen: | 17 |
Ergebnis: | Es wird ein Hardwarefond eingerichtet.
|
Finanzfond
Jede Maus im Netz sollte freiwillig 10,- DM - einmalig - einzahlen. Es
soll ein Team mit 3 Mitgliedern gebildet werden, dass nichtöffentlich
über die Vergabe entscheidet und den Fond verwaltet. Die finanzielle
Unterstützung soll als zinsloser Kredit vergeben werden, der innerhalb
von 6 Monaten rückzahlbar ist.
Der Antrag muss schriftlich an das Vergabeteam gestellt werden;
über die Vergabe wird dann - wegen der Dringlichkeit - telefonisch
entschieden. Das Team legt einmal jährlich - beim SysOp-Treffen -
einen Rechenschaftsbericht ab. In der Diskussion stellten sich dann noch
die Fragen nach dem Mißbrauch durch das Team, da die Vergabe nicht
öffentlich stattfinden soll, und nach dem Fall, in dem das Geld nicht
zurückbezahlt werden kann.
Soll der Kreditnehmer dann öffentlich bekannt gemacht werden?
Betreiberabstimmung im Plenum:
Frage: | Ist es gewünscht, einen Finanzfond einzurichten? |
Pro: | 20 |
Contra: | 12 |
Enthaltungen: | 11 |
Ergebnis: | Aufgrund des knappen Ergebnisses und keiner qualifizierten Mehrheit besteht weiterhin Diskussionsbedarf zu diesem Thema. |
Teilnehmer an der Arbeitsgruppe:
Thomas Meißner, Christian Goßlar, Peter Bajetto, Gerhard Meiser, Martin Schwenk.
Wie bekommen wir neue User und können alte halten?
Off-Line Netz
Kommunikation soll im Vordergrund stehen
Userfreundlichkeit (Usernähe - Maustreffen)
MIME
Dem User zeigen, dass es einen Maustausch gibt
evtl. automatischer Download eines FEs
Oberfläche kundenorientierter; einfacher an Informationen kommen
SysOps sollten im Bedarfsfall auch zum User gehen und dort helfen
Erklärung der Mausoberfläche in www.maus.de
Sollte das MausNet multimedialer werden? Oder in Richtung Usenet gehen?
Handzettel verteilen -> daraus folgen steigende Anruferzahlen. Von diesen Neuusern bleiben ca. 30% als User dabei. Die 30 % beziehen sich speziell darauf, daß versucht wird, mit Modemhändlern in Kontakt zu treten und die Handzettel neu verkauften Modems beizulegen.
Werbeheft inkl. Einführung in die Maus (Volker Ronneberger@GÖ)
Disketten verschicken. Martin Ruf @ C-B hat eine solche Diskette bereits erstellt.
Möglicherweise könnte man auch FEs auf eine Maus-Werbe-CD packen.
In den Stuttgarter Mäusen wird für die Hobby-Elektronik gerade eine solche Diskette erstellt und wird ab November auch dort im Programmteil zu finden sein. Ansprechpartner: Michael Kugelmann @ S5
Ansprechpartner für FEs auf einer möglichen Maus-Werbe-CD:
Lutz Grünenwald | -> DOS |
Michael Scharfschwerdt | -> OS/2 |
Karl Reinberg | -> OS/2 |
Martin Loos | -> Amiga |
Frank Röske | -> Atari |
Jürgen Affenzeller | -> OS/2 |
Daniela Dürbeck | -> Mac |
Götz Hoffart | -> Mac/Windows/Atari |
Udo Fleckenstein | -> Linux |
Teilnehmerliste an der Arbeitsgemeinschaft:
Aleks A-Lessmann, Lutz Grünenwald, Andreas Weiss, Ralf Belscher, Horst Kollmuß, Michael Scharfschwerdt, Volker Janzen, Edgar Fuß, Philipp Oelwein, Volker Ronneberger, Götz Hoffart, Martin Ruf, Karsten Iwen, Alexander Porntepcharoen, Andreas Mandel, Silke Tintelott, Thomas Morgenthaler, Matthias Fonfara, Andreas Mayer, Hartmut Heinbach, Gabriel Schmidt, Michael Wist, Georg Feuersträter, Matthias Stürmer
Es kommt im MausNet vor, dass nicht von allen Mäusen, die das Netz verlassen, auch die EXPs gelöscht werden. Es gibt zwei Verfahren um die EXP-Löschung zu vereinfachen:
Die EXPs bekommen ein Löschflag, so dass MNConfig das EXP bei gesetztem Löschflag löscht oder umbenennt.
Die EXPs werden durch eine zentrale Stelle - z.B. durch den Netz- Gruppen-Koordinator - gelöscht, ähnlich der Gruppeneinrichtung.
Sebastian Hempel fasst alle vorhandenen Texte, die sich um EXPs drehen, zusammen und erstellt daraus eine EXP-Doku (Token-Formate), die vor Veröffentlichung Gereon Steffens zur Korrektur vorgelegt wird. Diese EXP-Doku enthält dann auch Empfehlungen für Einträge ins EXP.
SPAM (Massenmitteilungen in öffentlichen Gruppen)
Filtermöglichkeit gibt es im Grunde nur vor dem Gateway, da nur
dort die notwendigen Informationen zur Verfügung stehen. In den
Gatewayprogrammen werden keine Filter implementiert werden, wobei zumindest
Erwinsgate die Möglichkeit bietet, innerhalb des Gatelaufes weitere
Programme auszuführen, über die durch jemand anderen diese
Funktionalität implementiert werden könnte. In der Arbeitsgruppe
wurde Spam subjektiv weniger störend empfunden als die
Belästigung durch ungewollt zugesandte Werbe-PMs. Es existieren
bereits Konfigurationen für Internet-Mailverteiler (MTAs), die eine
sehr hohe Trefferquote haben und Massen-Werbemails ausfiltern (basierend
auf der IP-Adresse der Absender und abrufbaren Listen selbiger).
Die entsprechnde Konfiguration auf eisbaer (dem Rechner vor dem
Hauptgate) gestaltet sich problematisch, da die entsprechende Man-Power mit
Fachkenntnissen fehlt. Hilfe bezüglich smail ist willkommen
(Interessenten wenden sich bitte an UF @ BB).
Netzweites Löschen
Das MausNet ist für schnelle Cancels nicht geeignet, von der
Einführung eines zusätzlichen 'Crash-Nets' zu diesem Zweck wird
abgeraten (s. Einrichtung Abendnetz). Cancels müssten innerhalb der
Maus in der Messagebase und zusätzlich in den Speedtausch-Outfiles
bearbeitet werden, eine Weiterleitung zum User ist notwendig wegen der
hohen Tauschfrequenz vieler Benutzer.
Die Arbeitsgruppe hält geeignete Mechanismen zur Weiterleitung von
Steuerungsnachrichten (primär Cancels - Löschnachrichten)
für notwendig.
Diese sollen auf der langen Message-ID basieren und sind deshalb
primär für die Verarbeitung in Frontends gedacht.
Eine Einspeisung der entsprechenden Nachrichten aus dem Usenet ist
vornehmlich wegen des sehr hohen Volumens nicht praktikabel (NoCem mit ca.
40MB/Tag)
Eine Alternative wäre das manuelle Einspeisen von
Löschmitteilungen innerhalb des Mausnets. Eventuell auftretende
soziale Probleme (Fremdcanceln) dürften sich in Grenzen halten und
handhabbar sein.
Teilnehmerliste an der Arbeitsgruppe:
Philipp Oelwein, Hans-Peter Bock, Juergen Affenzeller, Michael Keukert, Martin Ruf, Gabriel Schmidt, Andreas Weiss, Hartmut Heinbach, Thomas Gallert, Harald Beckert, Dirk Schulz, Christian Goßlar, Thomas Wilkens, Stefan Rupp, Edgar Fuß, Martin Koyro, Stefan Huerter, Dirk Reinberg, Karl Jochen Friedrich, Frank Röske, Volker Ronneberger, Volker Janzen, Ralf Belscher, Michael Kugelmann, Ulrich Frey, Inge Meiser, Adrian Reyer, (zeitweise) Uwe Ohse, Udo Fleckenstein, Federico Hernandez-Püschel
Abstimmung im Plenum über folgende Absichtserklärung:
Frage: | Wir SysOps sprechen uns für eine Annahmeverweigerung von PMs (Mail) von als Massenversendern bekannten IP-Domains aus. |
Erklärung: | Hiermit soll einem möglichen Zensurvorwurf (Löschen von Mail/PM) vorbeugend entgegengewirkt werden. |
Pro: | 57 |
Contra: | 3 |
Enthaltung: | 10 |
Ergebnis: | Die SysOps sprechen sich für eine Annahmeverweigerung aus. |
AL-Team, Vereinfachung Gruppeneinrichtung
Ziel der AG war es, die Arbeit des AL-Teams, sowie das Verfahren der
Gruppeneinrichtung zu vereinfachen. Hierzu wurden folgende Lösungen
erarbeitet:
Einrichtung von Gruppen
Das Verfahren zur Neueinrichtung von Gruppen wird vereinfacht: Die AG
einigte sich auf folgende Verfahren:
Neueinrichtung von MausNet-internen Gruppen wird
unbürokratisch auf Zuruf realisiert. Für externe, zu
importierende Gruppen wird der alte Ablauf beibehalten, d.h. Testimport und
Abstimmung.
Das Verfahren im Einzelnen:
Mail an das AL-Team @ OF, in der der Gruppenwunsch genannt wird.
Das AL-Team entscheidet, ob es eine solche oder ähnliche Gruppe
schon gibt, und ob die Gruppe erwünscht (mit den Zielen und Inhalten
des MausNets vereinbar ist, es wurde hier auch der "Geist des
MausNets" angesprochen).
(Zusatz auf Wunsch von Philipp Oelwein: <<... tätigte ich
den Zwischenruf "Und wo bleibt da Esoterik?", was aus dem Plenum
mit Heiterkeit quittiert wurde und von Peter mit "Die ist
unerwünscht.">>)
Fehlt die Gruppenbeschreibung, so fragt das AL-Team diese beim Einreicher des Gruppenwunsches an.
Der nächste Schritt ist eine Nachricht in Maus.Info, in der die User des MausNets über die geplante neue Gruppe informiert werden. Mit dem Absendedatum fängt eine Einspruchsfrist von 7 Tagen an, nach der die Gruppe durch den Netzgruppenkoordinator eingerichtet wird.
Gibt es innerhalb der Einspruchsfrist einen _begründeten_ Einspruch an das AL-Team@OF, so wird der bisherige Gruppeneinrichtungsablauf ohne vorherige Diskussion (CFD) wieder durchgeführt (CFV).
Über den Einspruch und die Begründung entscheidet das AL-Team.
Normaler Ablauf der Gruppeneinrichtung:
kurzfristiger CFV in Maus.Info.
Umbenennen von Gruppen und Vernetzungsstatus ändern
Hier gilt der aktuelle Ablauf:
Ankündigung in Maus.Info
Abstimmung in der Gruppe durch AL-Team oder Beauftragten
Mail an Netzgruppenkoordinator
Gruppenbeschreibungen ändern
Diskussion in Gruppe und bei Einigkeit Mail an Netzgruppenkoordinator.
Maus.Info.Wahl wird abgeschafft.
SysOps
Ein SysOp-Ausschluß über eine Abstimmung (CFV) ist weiterhin
möglich. Folgende bisher übliche Möglichkeiten für
einen Ausschluß gibt es auch weiterhin:
Netzausschluss
Betreiberausschluss
SysOp-Ausschluss
Bei Nichtbeachtung erfolgt für die betroffene Maus eine Gruppensperre und/oder Maussperre durch das Schiedsteam.
SysOp-Gruppen
Sysop.Gate wird nach Maus.Gate umgenannt und für Maus-User beschreibbar geflaggt. Für außerhalb des MausNet ist entsprechende Gruppe als moderierte Gruppe zu behandeln.
Die restlichen SysOp-Gruppen bleiben unverändert. Die AG empfiehlt jedoch die Öffnung von SYSOP, bzw. dass mehr SysOps die Gruppe MAUS lesen und sich an den Diskussionen beteiligen sollen.
SysOp-Abstimmungen sind weiterhin verbindlich
Das AL-Team kann eigenständig entscheiden.
Teilnehmer der AG:
Peter Böhnke, Torsten Hallmann, Thomas Morgenthaler, Tim Ganske, Mathias Fonfara, Götz Hoffart, Martin Schwenk, Gert Stamminger, Klaus Büttner, Michael Wist, Marcus Ohlhaut, Matthias Kürschner, Jörg Schuhardt, Aleks Almonacid-Lessmann, Michael Steinwachs, Lutz Grünenwald, Thomas Niering
Abstimmung im Plenum:
Frage: | Wer ist dafür, die vereinfachte Gruppeneinrichtung einzuführen? |
Pro: | 61 |
Contra: | 1 |
Enthaltungen: | 8 |
Ergebnis: | Die vereinfachte Gruppeneinrichtung wird eingeführt. |
Abstimmung im Plenum:
Frage: | Wer ist dafür SYSOP.GATE in MAUS.GATE umzubenennen, Usern zu öffnen (read/write) und zu exportieren? |
Pro: | 41 |
Contra: | 10 |
Enthaltungen: | 24 |
Ergebnis: | SYSOP.GATE wird umbenannt, geöffnet und exportiert. |
Abstimmung im Plenum:
Frage: | Muss bei der Öffnung von MAUS.GATE die Gruppe auf Mitgliedschaft gesetzt werden? |
Pro: | 19 |
Contra: | 43 |
Enthaltungen: | 17 |
Ergebnis: | Maus.Gate muß innerhalb des MausNet nicht auf Mitgliedschaft gesetzt werden. |
Abstimmung im Plenum:
Frage: | Soll die Gruppe SYSOPS für User readonly geöffnet werden? |
Pro: | 38 |
Contra: | 20 |
Enthaltungen: | 15 |
Ergebnis: | Ja, die Gruppe SYSOPS soll für User readonly geöffnet werden. |
Ätsch, das kommt davon, wenn man mich Protokoll schreiben
läßt. Dann gebe ich nämlich auch noch meinen Senf dazu und
das jetzt, bevor die Teilnehmerliste kommt.
Zuerst einmal herzlichen Dank an das Orga-Team, das aus folgenden
Leuten besteht:
Doris Meininger @ BA
Margit Birkner @ BA
Anne Gerber @ BA
Björn Schmidgall @ FÜ
Martin Schwenk @ BA
Tobias Völker @ BA
Es hat mir saugut bei euch gefallen und ich komme gerne mal wieder; aber nicht erst in 90 Jahren, sondern schon früher.
BTW: | Das nächste SysOp-Treffen findet (wie ich gerade in SYSOP.INFO gelesen habe) im Frankfurter Raum statt und wird von den Mäusen AB/F/OF/OF2 ausgerichtet. |
Weiterhin möchte ich mich bei:
Brigitte Banck @ BA für die Unterstützung beim Fahrdienst am
Freitag, Gaby Kramer @ BA für die Buttons,
Joachim Herold @ FÜ (Hara Ratschi) fÜr das tolle Programm am
Samstag, Marcus Ohlhaut @ BA & M4 für die PGP-Aktion
AKKU Klaus Büttner für die Fürstenmaus
Sebastian Hempel @ WUN für die Kantholzkiste
Brauerei Hummel in Merkendorf
und bei allen, die ich hier vergessen habe auch noch ganz herzlich bedanken. Es war richtig toll bei und mit euch. DANKE!!!
BTW: Nächstes Jahr schreibt jemand anderes!!!
In diesem Sinn :)
Stefan
AB | Jörg Schuhardt |
AC2 | Stefan Rupp |
AC2 | Michael Keukert |
AN | Gert Stamminger |
B | Christian Goßlar |
BA | Anne Gerber |
BA | Doris Meininger |
BA | Margit Birkner |
BA | Martin Schwenk |
BA | Tobias Völker |
BB2 | Ulrich Frey |
BOR | Georg Feuersträter |
C-B | Martin Ruf |
D | Peter Bajetto |
DO2 | Michael Scharfschwerdt |
DO2 | Udo Erdelhoff |
DU3 | Uwe Ohse |
DU3 | Arnd Graefe |
DU3 | Adrian Reyer |
FR | Götz Hoffart |
FÜ | Björn Schmidgall |
FÜ | Thomas Niering |
FÜ | Udo Fleckenstein |
GÖ | Volker Ronneberger |
GP | Michael Wist |
GP | Ralf Belschner |
H/H2 | Wolfgang Voelker |
HB2 | Peter Böhnke |
HB2 | Thomas Wilkens |
HD | Matthias Stürmer |
HH2 | Philipp Oelwein |
HL | Karsten Iwen |
HM | Jens Lüthje |
K2 | Edgar Fuß |
KA | Wolfgang Walter |
KA2 | Matthias Fonfara |
KL | Gabriel Schmidt |
KN | Andreas Rieck |
KN | Martin Kürschner |
KN | Matthias Kürschner |
LI | Bettina Natter |
LI | Horst Kollmus |
LU | Andreas Kögel |
LU | Jochen Friedrich |
LU2 | Frank Röske |
LU2 | Stefan Hürter |
M | Aleks Almonacid-Lessmann |
M | Lutz Grünenwald |
M2 | Daniela Dürbeck |
M4 | Marcus Ohlhaut |
MGN | Falk Sauer |
MGN | Klaus Büttner |
MK2 | Dirk Reinarz |
MK2 | Martin Loos |
MK2 | Petra Bochinz |
MS | Harald Krusekamp |
MS/MS2 | Michael Steinwachs |
MS3 | Martin Koyro |
NI | Edgar Rosenboom |
NI | Rosemarie Rosenboom |
OF | Timm Ganske |
OF2 | Dirk Schulz |
OF2 | Federico Hernandez-Püschel |
OG | Alexander Porntepcharoen |
OG | Andreas Mandel |
OS2 | Torsten Hallmann |
OS4 | Thomas Meißner |
R | Thomas Gallert |
R | Frau Gallert |
S | Gerhard Meiser |
S5 | Inge Meiser |
S5 | Michael Kugelmann |
SI | Andreas Weiss |
SI | Hartmut Heinbach |
TBB | Bernd Dierolf |
TBB | Hans-Peter Bock |
TBB | Juergen Affenzeller |
TBB | Michael Goldbach |
TBB | Stefan Heidrich |
UL | Volker Janzen |
UN | Karl Reinberg |
W2 | Jörg Stattaus |
WHV | Silke Tintelott |
WHV | Thomas Morgenthaler |
WUN | Sebastian Hempel |
WUN | Yvonne Röckl |
Dieser Text wurde erzeugt mit
UDO
Release 6 Patchlevel 6
TOS
Copyright © 1995, 1996, 1997 by
Dirk Hagedorn
Postfach 8105
D-59840 Sundern
E-Mail: DHagedorn@t-online.de
UDO ist ein Programm, welches Textdateien, die im Universal Document Format erstellt wurden, in das ASCII-, ST-Guide-, LaTeX-, Rich Text-, Pure-C-Help-, Manualpage-, HTML-, WinHelp-, Texinfo-, Linuxdoc-SGML-, LyX-, Apple-QuickView- und Turbo-Vision-Help-Format umwandeln kann.
Weitere Informationen sowie die aktuellen Versionen findet man im World
Wide Web unter
http://members.aol.com/DirkHage
Copyright © by Christian Goßlar
Letzte Aktualisierung am 6. November 1997