Home

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


Inhaltsverzeichnis


Anhang




1 Einleitung


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

Made with UDO


Im Moment sind die folgenden Ausgabeformate verfügbar:

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.


2 Fragen zur Maus

Fragen und hoffentlich auch die Antworten zu Problemen, die die Maus alleine betreffen.


2.1 Diverse Fragen und Tips


2.1.1 Abkürzungen im MCall-LOG

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).

2.1.2 Ab wann gelten User als Geizhals?

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.

2.1.3 Ändern des Textes, den Gäste beim einloggen angezeigt bekommen

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.

2.1.4 Ändern des Textes, den man beim neu eintragen angezeigt bekommt

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.

2.1.5 Automatisches ändern der PW für bestimmte User

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.

2.1.6 Checken der User-Paßwörter

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.

2.1.7 Die Gebührenanzeige der MAUS, stimmt die?

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

2.1.8 Kann man bei einem Anruf automatisch einen Event auslösen?

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

2.1.9 Kann man von der Konsole Filebeschreibungen uploaden?

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

2.1.10 Konsolenlogin mit zwei Tastendrücken!

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.F7 := #222'JChristian Goßlar'

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.

2.1.11 Messagezähler für alle User verändern/zurücksetzten?

Sysop-Menü, Löschen, # und dann den neuen Messagepointer setzen.

2.1.12 Messagepointer 0 bei Neuuser?

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:

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.

2.1.13 Multi-Maustausch, wie geht das?

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.

2.1.14 Tips zum Maus.bat

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.

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

2.1.15 Was bedeuten die Zahlen oben auf den Mausbildschirm?

Die rechte Zahl stellt den aktuelle freien Speicher an. Die linke ist der minimal freie Speicher zur Laufzeit der Maus.

2.1.16 Was bedeutet die Statuszeile in 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

2.1.17 Was hat es mit dem CALLCHK.BAT auf sich?

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.

2.1.18 Was überprüft die Maus beim Dupe-Check?

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.

2.1.19 Welche Tastencodes gibt es bei der Maus?

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!!!

2.1.20 Wie bindet man RAR-Packer in die Maus ein?

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:

Tabelle 1: Commands: A,F,M,U
CommandCommandFullFull
linelinescreenscreen
modemodemodemode
Not solidUpdateNot solidUpdate
or addingsolidor addingsolid
to solidarchiveto solidarchive
EMS enabled337409409481
EMS disabled401473473545

Tabelle 2: Commands: CW,E,P,T,X
EMS enabled217
EMS disabled281

Tabelle 3: Command: C
EMS enabled409
EMS disabled473

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

2.1.21 Wie ist die Definition der Maustausch-Kommandos?

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:

  • TK besagt, daß es sich um ein Kommando handelt, das der Anwender per Konfiguration festlegen können sollte und welches dann automatisch immer wieder benutzt wird.

  • TE kennzeichnet ein Kommando, das pro Tausch manuell aktiviert werden können sollte, aber nur einmal im Infile auftauchen sollte;

  • TB schließlich bedeutet, daß der User mehrere dieser Kommandos pro Tausch absetzen kann, diese aber vom Frontend nur so häufig abgesetzt werden, wie der User sie explizit eingibt.

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:
A+:
, d.h. es existieren zwei Zustände. Der erste wird durch '+' angegeben, der zweite durch einen Leerstring. Bei Werten mit zwei Zuständen sollte die Beschreibung derart gewählt werden, daß das Frontend den ersten der Zustände durch 'markiert', den zweiten durch 'nicht markiert' in einer Dialogbox symbolisieren kann. Bei Werten mit drei Zuständen sollte sie so gewählt werden, daß der erste durch 'positiv markiert', der zweite durch 'negativ markiert' und der dritte durch 'nicht markiert' symbolisiert werden kann.
Diese Angabe bezieht sich auf die Syntax und braucht also dem User nicht angezeigt zu werden.

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:

  • 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.

Die generelle Struktur eines ITK-Eintrags ist somit wie folgt:

#<Kommando-Nummer>


Diese Zeile leitet ein neues Kommando ein. Alle folgenden Zeilen bis zum Ende oder bis zur nächsten #-Zeile beziehen sich auf dieses Kommando.

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>


Diese Zeile leitet einen neuen Parameter ein. Alle folgenden Zeilen bis zum Ende des Kommandos oder bis zur nächsten C- oder F-Zeile beziehen sich auf diesen Parameter.

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.

Tabelle 4: Als Datentypen c stehen zur Verfügung:
Darstellung im Infile
AAufzählungstypwie in A-Zeilen angegeben
MSet of Aufzählung;
es gilt alles wie für A,
nur daß das Frontend erlauben
muß, mehrere Werte gleichzeitig
zu aktivieren.
DDatumJJJJMMTTHHMM[SS]
dDatumTT[.MM[.JJJJ]]
SnString der Länge nwie eingegeben
PnPaßwort der Länge nwie eingegeben
(wird ggf. nicht angezeigt)
pnneues Paßwort der Länge nwie eingegeben
(Frontend kann ggf. zweimal
fragen)
UUsernamewie eingegeben
Iganze Zahl, 2 Bytedezimal, Ascii, mit
Vorzeichen, auch wenn positiv
Im,nganze Zahl aus dem Intervalldezimal, Ascii, mit
[m;n].Vorzeichen, auch wenn positiv
GGruppennameim Klartext
gName einer Gruppe, in derim 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.

2.1.22 Was steht in der MVIDEO.DAT Datei?

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.

2.1.23 Wie löscht man Schrottmails?

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

2.1.24 Wie stelle ich am besten von 1 auf 2 Port-Maus um?

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.

2.1.25 Worauf ist bei der RAR-Packer Einbindung zu achten?


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.

2.1.26 Vordefinierte Events in der Maus

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.

2.1.27 RAR-Packer zum zweiten


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:

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

2.1.28 Zu lange downloads bzw. downloads über mehrere Stunden

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

2.2 Fehlermeldungen der Maus


2.2.1 Maus-Fehlermeldungen

#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

2.2.2 Was bedeutet MsgIdx-Buffer übergelaufen?

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.

a)

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.

b)

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

2.3 Fragen, Tips zu Modemprobleme


2.3.1 Probleme beim Upload, bzw kein Upload möglich

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.

2.3.2 Beim ausloggen überträgt das Modem nicht mehr den Pufferinhalt.

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

2.3.3 Kann man mit dem Maus-Modem automatisch FAXe empfangen

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.

2.3.4 Mehrere Modems an der Maus

Mehrere Modems/ISDN-Karten an der Maus zu betreiben ist kein Problem. Hier mal in Stichworten die hoffentlich vollständige Beschreibung.

2.3.5 Tips zur Konfiguration des ZyXel 1496

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

2.3.6 Tips zur Konfiguration des ZyXel 2864ID

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

2.3.7 Tips zur Konfiguration des USR Courier v34

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... :-)

2.3.8 Tips zur Konfiguration des USR Sportster

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.

2.3.9 Tips zur Konfiguration des USR Sportster Voice

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

2.3.10 Tips zur Konfiguration des ELSA MicroLink 33.6 TQV

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...

2.3.11 Wie verhindert man unbekannte Connect-Meldungen?

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)

2.3.12 Beispiele für Connect-Strings

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;

2.4 Fragen, Tips zu ISDN in der Maus


2.4.1 Besetzt erzeugen mit einer ISDN-Karte

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.

2.4.2 Telefonnummer des Anrufers im MCall.Log

Wie bekommt man die Nummer des Anrufers ins MCall.log?

Folgendes sollte mindestens eingestellt bzw. aktiviert sein:

  1. CfgVar LogIgnored (boolean, default False). Bei True werden die Response- Ignore-Strings protokolliert, ebenso nach einem RING alles, was nicht als CONNECT erkannt wurde.

  2. 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

2.5 Probleme die Gruppen und den Programmteil betreffen.


2.5.1 Gruppenflags für lokale Readonly Gruppen?

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).

2.5.2 Gruppenprogrammteil auf CD und Festplatte

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.

2.5.3 Gruppenprogrammteil ohne eine Gruppe einrichten?

Man kann keinen Gruppen-PT anlegen ohne gleichzeitig eine entsprechende Gruppe zu haben.

2.5.4 Gästeupload im Programmteil?

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!

2.5.5 Mitlesen in Gruppen ohne Mitgliedschaft?

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.

2.5.6 Probleme beim Fileupload / Schrott-Files?

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.

2.5.7 Unsinnige Gruppenflags möglich?

Die Maus erlaubt eigenltich alle Kombinationen von Gruppenflags. Es werden nur folgende Plausibilitätsprüfungen durchgeführt:

2.5.8 User als Programmteilwart, was beachten?

Wenn ein normaler User Programmteilwart ist, ist folgendes zu beachten

2.5.9 Was bedeuten die Gruppenflags?

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:

  1. K hat *keinerlei* Auswirkung auf die Zugriffsrechte für die Gruppe.

  2. R ist stärker als W.

  3. Gäste dürfen grundsätzlich nicht schreiben.

Tschö, Marcus.

2.5.10 Wenn ein User mal alle Gruppe bestellt hat

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.

2.5.11 Wie lange schickt die Maus Gruppennamenänderungen an die User?

Das wird über die Variable GrpRenExpire festgelegt.

2.5.12 Wie richte ich einen Gruppen-PT auf CD ein?

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.

  1. 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.

  2. Nun in der Maus den Gruppen-PT anlegen und unter Sysop-Funktionen, Gruppenverwaltung, Numerische Liste die Nummer der Gruppe feststellen.

  3. 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.

  4. 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

  5. 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.

  6. Sinnvoll ist es auch, wenn der Gruppen-PT readonly ist. Dann gibt es keine Probleme, wenn mal jemand etwas uploaden will.

2.5.13 Wie sperre ich den Programmteil komplett?

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

2.5.14 Wozu ist ProgTeilDatPath gut?

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."

2.6 Variablen-Einstellungen / Event-Probleme


2.6.1 Bedeutung der Eventzeiten

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ß.

2.6.2 Geht ein include in der m7com.cfg?

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

2.6.3 Gibt es Benutzer-Levels für die Externen Programme?

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

2.6.4 Wie bindet man externe Programm in die Maus ein?

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

2.6.5 Wie oft laufen Events am Tag?

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.

2.7 Die Maus unter OS-halbe.

Spezielle Fragen zum Mausbetrieb unter OS/2


2.7.1 Der arj-Packer 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.

2.7.2 Beispiel-Konfiguration für eine OS2-Maus

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

2.7.3 ISDN-Ports unter OS2

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.

2.7.4 PDZM-Modem und die Maus unter OS/2

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

2.7.5 Sommerzeit-Umstellung bei OS/2

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


3 Fragen zum Mausputz


3.1 Allgemeines zum Mausputz

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ß.

3.2 Aufrufparameter des MausPutz

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

3.3 MSGID-Programm

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

3.4 Was macht der Check für zu knappe Putzgrenzen?

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

3.5 Was macht der KRUNUSER?

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.

3.6 Wann werden Mails in Gruppen gelöscht?

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:

MsgOutDefaultTage

MsgOutDefaultAnzahl

MsgOutDefaultKB

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

3.7 Wann werden User vom Mausputz gelöscht?


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".

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

3.8 Xlate, was bedeutet das?

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".


4 Fragen zum MausNet

Hier geht es rund um das MausNet, Aufrufparameter, Zeiten usw.


4.1 Aufruf-Parameter des MausNet

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.

4.2 Aufrufparameter des ProgFix

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-

4.3 Bedeutung des Parameter des CNF-Files

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:
Gkiste_oder_domain,gatenummer,erlaubt_fuer.

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

4.4 Gefilterte PM-Massen

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.

4.5 ISDN im MausNet, was ist zu beachten?

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

4.6 Jeden Tag meldet der MNCONFIG mir eine neue Maus?

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.

4.7 Kann man auch einen Packer-Batch im Mausnetz aufrufen?

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

4.8 Kann man die Anrufreihenfolge im Nachtnetz verändern?

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.

4.9 MausNet-Fehler - Zu viele offene Files -

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.

4.10 Netstat, was bedeuten die Ausgaben?

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

4.11 Netstat Erklärung zum zweiten

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.

4.12 Problene mit dem Auspacken des Netzpaketes?

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

4.13 Wann und wie soll der MNCONFIG aufgerufen werden?

Wenn WriteSuccessMsg gesetzt ist, dann bekommt der Sysop auch immer eine Mail, wenn der MNConfig mit /X aufgerufen wird.

4.14 Was bedeutet die GetHeap Meldung im MausNet.log?

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.

4.15 Was bedeutet die 'nicht angekommen' Meldung?

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

4.16 Was bedeutet zurückgeroutet?

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.

4.17 Wie benennt man eine Box um?

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.

4.18 Wie kann ich das Nachtnetz zu anderen Zeiten fahren?

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.

4.19 Wie entstehen 'nicht eingetragen' Meldungen?

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

4.20 Wie verändert man die Vernetzung im Mausnetz?

Von: Jörg Stattaus @ AC (Mi, 02.06.93 12:44)

So sollte man vorgehen, wenn man die Vernetzung ändern will.

  1. Natürlich alles mit den Beteiligten absprechen.

  2. am Vortag das CNF ändern und mnconfig starten, aber _OHNE_ /x.

  3. das Nachtnetz mit der alten Box abwarten, danach läuft ja netzweit mnconfig/x und die Vernetzung wird geändert.

  4. MAUSNET.CFG (UseZip, UseZModem, ggf. ModemDialPre) anpassen

  5. 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

4.21 Wie verschickt man ein neues EXP der eigenen Maus?

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.

4.22 Worauf ist bei Änderungen des CNF-Files zu achten?

4.23 Worauf ist zu achten, wenn mal eine Box vom Netz geht?

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?


5 Allgemeine Fragen zum Mausrechner

Hier sind die Fragen, die sich um den Mausrechner allgemein und um Hilfsprogramme rund um die Maus drehen, zusammengestellt.


5.1 Direktlogin-Anleitung

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...
}

5.2 Fido-Gate. Wie richte ich sowas ein?

Ähmmm ja. Keine Ahnung. Frag mal Timm Ganske @ OF:-)

5.3 Mailingliste, was für Programme gibt es?

Ich weiß zwar nicht was der freundliche Tankwart meint, ich empfehle aber mlzwo von Marcus Schmidke. Was kann man damit alles anstellen?

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.

5.4 Ist die Maus für das Jahr 2000 vorbereitet?

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

5.5 Maus-Backup. Was sollte mindestens gesichert werden?

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

5.6 Murphy, wer ist das?

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!

5.7 Runtime-Fehlermeldungen

Tabelle 5: Runtime-Fehlermeldungen
Nr.Fehlermeldung
DOS Dosfunktionen
1Ungültiger DOS-Funktionscode
(Invalid function number)
2Datei nicht gefunden
(File not found)
3Pfad nicht gefunden
(Path not found)
4Zu viele Dateien geöffnet
(Too many open files)
5Zugriff auf Datei verweigert
(File access denied)
6Ungültiges Datei-Handle
(Invalid file handle)
12Ungültiger Zugriffscode
(Invalid file access code)
15Ungültiges Laufwerk
(Invalid drive number)
16Aktuelles Verzeichnis kann nicht gelöscht werden
(Cannot remove current directory)
17Umbenennen über Laufwerke hinweg nicht erlaubt
(Cannot rename across drives)
18Keine weiteren Dateien
(No more files)
Maus: extern (events)
50event 50
70event 70 (mausnet hat in der maus angerufen)
79event 79
Maus: intern
80Modem antwortet nicht
81Modem nimmt keine Daten an
82ModemCheck funktioniert nicht ("Hallo, Modem, lebst Du noch?")
83X00 will sich nicht initialisieren lassen
84Timer läßt sich nicht einhängen
85Timer läßt sich nicht aushängen
86X00-Kommunikations-RangeCheck
87kein Fossil da
88Absturz, bevor der normale Fehlerhandler installiert ist
(Fehler beim INIT)
89Fehler beim EXEC (execute external programm)
90M7DEC ist tütt
91ITG-Error beim lesen von NET-GRP.DAT
turbopascal: Dosfunktionen
100Lesefehler von Diskette/Platte
(Disk read error)
101Schreibfehler auf Diskette/Platte
(Disk write error)
102Dateivariable ist keiner Datei zugeordnet
(File not assigned)
103Datei nicht geöffnet
(File not open)
104Datei nicht für Eingabe geöffnet
(File not open for input)
105Datei nicht für Ausgabe geöffnet
(File not open for output)
106Ungültiges numerisches Format
(Invalid numeric format)
150Diskette ist schreibgeschützt
(Disk is write-protected)
151Peripheriegerät nicht bekannt/nicht angeschlossen
(Bad drive request struct length)
152Laufwerk nicht bereit
(Drive not ready)
154CRC-Fehler in Daten
(CRC error in data)
156Seek-Fehler auf Diskette/Platte
(Disk seek error)
157Unbekanntes Sektorformat
(Unknown media type)
158Sektor nicht gefunden
(Sector Not Found)
159Drucker hat kein Papier
(Printer out of paper)
160Fehler beim Schreiben auf Peripheriegerät
(Device write fault)
161Fehler beim Lesen von einem Peripheriegerät
(Device read fault)
162Hardware-Fehler
(Hardware failure)
manueller Fehler
199Manueller Runerror via <alt>238
Turbo-Pascal: Interne Runtime-Fehler
200Division durch Null
(Division by zero)
201Bereichsüberschreitung
(Range check error)
202Stack-Überlauf
(Stack overflow error)
203Heap-Überlauf
(Heap overflow error)
204Ungültige Zeiger-Operation
(Invalid pointer operation)
205Überlauf bei Gleitkomma-Operation
(Floating point overflow)
206Unterlauf bei Gleitkomma-Operation
(Floating point underflow)
207Fehler bei Gleitkomma-Operation
(Invalid floating point operation)
208Overlay-Manager nicht installiert
(Overlay manager not installed)
209Lesefehler bei Overlay-Datei
(Overlay file read error)
210Objekt nicht initialisiert
(Object not initialized)
211Aufruf einer abstrakten Methode
(Call to abstract method)
212Fehler bei Stream-Registrierung
(Stream registration error)
213Collection-Index außerhalb des gültigen Bereichs
(Collection index out of range)
214Collection-Überlauf
(Collection overflow error)
215Arithmetik-Überlauf
(Arithmetic overflow error)
216Schutzfehler
(General Protection fault)
MAUS: Programmteil - Errors
220programmteil-fehler
221dito
222dito
223dito
224dito

5.8 Sommerzeit/Winterzeit??

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.

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.

5.9 Tips zum extern.cfg

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).

5.10 Umlautprobleme bei Quarks

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.

5.11 Was hat es mit dem MU auf sich?

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

5.12 Was ist Klette und Use2Maus?

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.

5.13 Was ist das PMK-Token Format und wozu gibt es das?

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
Die Kommata sind wichtig!

%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:
Die Token für den Betreiber DÜRFEN KEINE Nummer haben, die Token für die übrigen Sysops MÜSSEN fortlaufende Nummern haben!

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:
Bei Gast-Sysops muß die Adresse angegeben werden, denn Stimmen von Gast-Sysops werden gewertet, als ob sie von ihrer Heimatbox abgegeben worden seien - d.h. der Betreffende muß dort als Sysop eingetragen sein, und auch die Bestätigung wird an die Heimatadresse geschickt!

Kommunikation:

%Mn

Modulationsart, n=Modemport (beginnend bei 1)
Es wird nur der maximal mögliche Wert einer Klasse
genommen. Gültige Werte sind:
CCITT-Klasse:
---
V32       CCITT V32     9600 bps Vollduplex
V32B      CCITT V32bis 14400 bps Vollduplex
V33       CCITT V33
V34       CCITT V34
(V.Fast-Class -> siehe Sonstiges)
US-Robotics Klasse:
----
HST       USR Courier HST
H14       USR Courier HST 14.4Kbps
H16       USR Courier HST 16.8Kbps
Telebit-Klasse:
---
PEP       Packet Ensemble Protocol
TPEP      Turbo-PEP
ZyXEL-Klasse:
---
ZYX       Zyxel
ZYX16     Zyxel mit 16.8Kbps
ZYX19     Zyxel mit 19.2Kbps
ISDN-Klasse:
--
ISDNA     V.110 mit 19.2Kbps
ISDNB     V.110 mit 38.4Kbps
ISDNC     X.75 mit 64Kbps
G4FAX     Gruppe 4 FAX mit 64Kbps
Sonstige:
--
VFC       V.Fast-Class
TER       V.32terbo
FAX       G3 Fax mit 9600bps
FAX4      G3 Fax mit 14.4Kbps
Nochmal: es wird nur der jeweils höchstmögliche Wert einer Klasse angegeben. Ein Telebit Worldblazer (Turbo-PEP und V.32bis) hätte also:
%M1 V32B,TPEP
ein ONBIT 240FAX (V.Fast-Class, FAX und V.32bis) hätte:
%M1 V32B, VFC, FAX
ein neueres Zyxel (aus dem Gedächtnis):
%M1 V32B, ZYX19, FAX4

%Fn

- Fehlersicherung/Kompression, n=Modemport (beginnend bei 1) Es wird nur der maximal mögliche Wert einer Klasse genommen. Gültige Werte sind:
V42 LAP-M Fehlerkorrektur mit Fallback auf MNP 1-4
V42B LAP-M Fehlerkorrektur mit Fallback auf MNP 1-5
MNPn Microcom Networking Protocol (n = 4 bis ...)
Merke: Wer V42B dazuschreibt, braucht nicht MNP zu erwähnen!

%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
Die Kommata sind wichtig!

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:
gg mm N / gg mm E [city]
gg mm = Grad Minuten
N, E = Nördlicher Länge, Östlicher Breite
city = Angaben bezogen auf den Stadtmittelpunkt
Beispiel: 50 46 N / 06 06 E city
"Witzige" Kommentare sind in dieser Spalte möglichst zu unterlassen.

%$

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:

Tabelle 6: Geographische Lage einiger Orte
aachen, deutschland50.46T6.06Fmez
augsburg, deutschland48.22T10.53Fmez
bergisch-gladbach, deutschland50.59T7.08Fmez
berlin, deutschland52.33T13.22Fmez
bielefeld, deutschland52.02T8.32Fmez
bochum, deutschland51.29T7.13Fmez
bonn, deutschland50.44T7.06Fmez
bottrop, deutschland51.31T6.55Fmez
braunschweig, deutschland52.16T10.32Fmez
bremen, deutschland53.05T8.48Fmez
bremerhaven, deutschland53.33T8.35Fmez
chemnitz, deutschland50.50T12.55Fmez
cottbus, deutschland51.46T14.20Fmez
darmstadt, deutschland49.52T8.39Fmez
dessau, deutschland51.50T12.15Fmez
dortmund, deutschland51.32T7.27Fmez
dresden, deutschland51.03T13.45Fmez
duisburg, deutschland51.26T6.45Fmez
düsseldorf, deutschland51.13T6.47Fmez
erfurt, deutschland50.58T11.02Fmez
erlangen, deutschland49.36T11.01Fmez
essen, deutschland52.43T7.56Fmez
frankfurt, deutschland50.07T8.41Fmez
freiburg, deutschland48.00T7.51Fmez
freising, deutschland48.24T11.44Fmez
gelsenkirchen, deutschland51.31T7.06Fmez
gera, deutschland50.52T12.05Fmez
göttingen, deutschland51.32T9.56Fmez
hagen, deutschland51.21T7.28Fmez
halle, deutschland51.28T11.58Fmez
hamburg, deutschland53.33T10.00Fmez
hamm, deutschland51.41T7.48Fmez
hannover, deutschland52.22T9.43Fmez
heidelberg, deutschland49.25T8.42Fmez
heilbronn, deutschland49.08T9.13Fmez
herne, deutschland51.33T7.13Fmez
jena, deutschland50.56T11.35Fmez
kaiserslautern, deutschland49.27T7.45Fmez
karlsruhe, deutschland49.01T8.24Fmez
kassel, deutschland51.19T9.30Fmez
kiel, deutschland54.20T10.08Fmez
koblenz, deutschland50.21T7.36Fmez
köln, deutschland50.56T6.57Fmez
krefeld, deutschland51.20T6.34Fmez
leipzig, deutschland51.20T12.25Fmez
leverkusen, deutschland51.01T6.59Fmez
lübeck, deutschland53.52T10.42Fmez
ludwigshafen, deutschland49.29T8.27Fmez
magdeburg, deutschland52.08T11.37Fmez
mainz, deutschland50.00T8.15Fmez
mannheim, deutschland49.29T8.28Fmez
moers, deutschland51.27T6.39Fmez
mönchengladbach, deutschland51.12T6.26Fmez
mülheim, deutschland51.26T6.53Fmez
münchen, deutschland48.09T11.35Fmez
münster, deutschland51.58T7.38Fmez
neuss, deutschland51.12T6.42Fmez
nürnberg, deutschland49.27T11.05Fmez
oberhausen, deutschland51.28T6.51Fmez
offenbach, deutschland50.06T8.46Fmez
oldenburg, deutschland53.10T8.12Fmez
osnabrück, deutschland52.16T8.03Fmez
paderborn, deutschland51.43T8.46Fmez
pforzheim, deutschland48.53T8.42Fmez
potsdam, deutschland52.24T13.04Fmez
recklinghausen, deutschland51.37T7.12Fmez
regensburg, deutschland49.01T12.06Fmez
remscheid, deutschland51.11T7.12Fmez
rostock, deutschland54.05T12.08Fmez
saarbrücken, deutschland49.14T7.00Fmez
salzgitter, deutschland52.05T10.20Fmez
schwerin, deutschland53.38T11.23Fmez
siegen, deutschland50.52T8.02Fmez
solingen, deutschland51.11T7.05Fmez
stuttgart, deutschland48.46T9.11Fmez
ulm, deutschland48.25T10.00Fmez
wiesbaden, deutschland50.05T8.15Fmez
witten, deutschland51.26T7.20Fmez
wolfsburg, deutschland52.26T10.48Fmez
wuppertal, deutschland51.16T7.11Fmez
würzburg, deutschland49.48T9.56Fmez
zwickau, deutschland50.44T12.30Fmez
amstetten, österreich48.07T14.52Fmez
baden, österreich48.01T16.14Fmez
braunau, österreich48.16T13.02Fmez
bregenz, österreich47.30T9.46Fmez
bruck/mur, österreich47.25T15.17Fmez
dornbirn, österreich47.25T9.44Fmez
eisenstadt, österreich47.51T16.31Fmez
feldkirch, österreich47.14T9.36Fmez
graz, österreich47.05T15.22Fmez
hallein, österreich47.41T13.06Fmez
innsbruck, österreich47.16T11.24Fmez
kapfenberg, österreich47.26T15.18Fmez
klagenfurt, österreich46.38T14.20Fmez
klosterneuburg, österreich48.18T16.19Fmez
krems, österreich48.25T15.36Fmez
leoben, österreich47.23T15.06Fmez
linz, österreich48.19T14.18Fmez
mödling, österreich48.05T16.28Fmez
salzburg, österreich47.48T13.03Fmez
sankt pölten, österreich48.13T15.37Fmez
steyr, österreich48.04T14.25Fmez
ternitz, österreich47.43T16.02Fmez
traun, österreich48.13T14.14Fmez
villach, österreich46.37T13.51Fmez
wels, österreich48.10T14.02Fmez
wien, österreich48.12T16.22Fmez
wiener neustadt, österreich47.48T16.15Fmez
wolfsberg, österreich46.50T14.50Fmez

5.14 Was kann man gegen Internet-Werbung per PM machen?

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.

5.15 Was kann man gegen Werbung in Mails machen?

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.

5.16 Was tun bei MsgId-Dupes?

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.

Siehe auch Was tun nach einem Crash?

5.17 Was tun bei zu wenig freien MsgIDs?

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:

  1. Online in die Mauseinloggen, Mitteilungen anrufen, Stichwort listen, alle aufrufen. Dann bekommt man als Liste die ältesten Mails in der Maus angezeigt.

  2. Zu den angezeigenten Gruppen die Mausputz-Parameter MsgOutDefaultKB, MsgOutDefaultAnzahl und MsgOutDefaultTage kontrollieren

  3. vielleicht nochmal mit dem Programm msgid.exe die Verteilung der Message-IDs kontrollieren.

  4. Die Mausputz-Parameter entsprechend ändern

  5. 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.

  6. Das war es

5.18 Was tun nach einem Crash?

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.

5.19 Wenn ein Netzpaket verloren geht

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.

5.20 Welche Grenzen gibt es bei der Maussoft

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.
Die Grenze von 64KB für PMs pro Tag und User ist allerdings eine, die man verändern kann. Im Moment haben sich die Sysops allerdings auf die 64KB geeinigt.

Programmteil-Taggen

Bei mehr als 50 selektierten/angezeigten Programmen stürzt die Maus ab.

5.21 Wenn mal die Maus ein Datum in der Zukunft hat

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

5.22 Wer ist der Ansprechpartner bei der c't für Änderungen des Eintrags?

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:

FILES

Was wohl

NEWFILES

s.o., 30 Tage

ABOUT

Infos zur c't-Mailbox

MAUSGATE

Info zur Adressierung zum Mausnetz

ABO

Formular fuer ein Probeabo

GERNET

GerNet-Infopaket - Rules, aktuelle Nodeliste, Nodeantrag

BOXEN

Liste der auch in der c't veroeffentlichten Supportmailboxen

ELRAD

Fileliste der ELRAD-Mailbox (taeglich neu)

NODEDIFF

aktuelle Nodediff des GerNet

LISTINGS

Listings zum aktuellen Heft

ADRESSEN

Herstelleradressen zum aktuellen Heft

INHALT

Heise-Register-Update zum aktuellen Heft


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.

5.23 Wie kann man eine Maus noch beschleunigen?

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.

5.24 Wie richte ich ein lokales Gate zum InterNet ein?

Dazu jetzt mal mei erster Erfahrungsbericht. Wir haben hier vor zwei Wochen sowas eingerichtet. Zuerst die Voraussetzungen:

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.

5.25 Wie richte ich ein lokales Gate zu einer anderen Maus ein?

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

5.26 Wie richte ich eine Fremdbox unter der Maus ein?

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)

5.27 Wie schließe ich einen ATARI am Direktport an?

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

5.28 Wie schließe ich einen MAC an den Direktport an?

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)

5.29 Wie werde ich ein zu langes mprog.dat wieder los?

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ß!

5.30 Wo gibt es eine Demo-Maus?

Die aktuelle Demomaus liegt immer in AC oder K2

5.31 TIC-File-Generatoren-Liste

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.


System2345
NameVers.AutorMP
ArchivnameZu finden
[optionale Bemerkung]
Amiga
AmiTIC1.4Oliver Schuler @ SIGFW 
  ÖPT@SIG 
Atari
DirToTIC Frank Roeske @ LU2BetaJ
 DTT*.LZH  
 Version auf Anfrage
 benötigt Filelist (SW)
MakeNews1.14Manfred Ssykor @ AC3FW 
 MKN_vvv.LZHÖPT@AC3
MAKEUPL3.40Volker Keck @ SIGFWN
ÖPT@SIGanpaßbar
Weiterentwicklung evtl. 
von Volker Janzen @ UL
MausHelp0.32Manfred Ssykor @ AC3SW
MAUS?vvv.LZHÖ&S@AC3
Saug-Utility6.0Frank Rüger @ OS2FW
SAUGUT60.TOSÖPT@OS
Final Version!
(Kein Update/Support meehr)
TIC-Kreator1.18Ulf DunkelSWEJ
TICK_vvv.???GPT MAUSTAUSCH @ EL + DAL
DOS
PAUL1.12?Michael Streichsbier @ M2?SWJ
PAULXvvv.ARJÖPT@WHV
TICMAKER0.5ßAndreas Mayer @ ZWFW(N)
????????????
benutzt Text-basierte
Beschreibungsdatei
anstatt MPROG.DAT
Mac
Mausefalle1.4??????????SW
???????
Im Maustauschpr. eingebaut
OS/2
Lst2Tic1.08Karsten Iwen @ HLSW
LST2Tvvv.ZIPGPT MAUSTAUSCH @HL + ÖPT@S3
Windows
TIC-File-Gen1.02Markus Schober @ ZWFWJ
TICFGENv.ZIPÖPT@ZW
TVMTIC1.0cHans-Peter Bock @ TBBFWJ
TVMTIC.ZIPÖPT@TBB
Upload0.1dGeorg Bauer @ MS3FWJ
#UPL*.EXEÖPT@MS3
XPHatch2.02Carsten Schmitz @ HH2SW
ÖPT@TBB
?für Fido?
Windows
TIC-Creator1.01ßAndreas Suffner @ S4SW
tic.zipGPT MouseEye@S3
trotz Shareware kostenlos
UTic1.10Ulrich Tönnies @ OS2SWN
ÖPT@OS2
Unix
nix
SonstigeoderNicht
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 CommanderMichael Keukert @ AC2 GPT Sysop.Prog
TicTac(Standalone-Programm zur Tic-Generierung,
bei Maus ohne James)

Anmerkungen und Erklärungen:

  1. MP: Benutzt MPROG.DAT der Maus

  2. ein vvv z.B. bei beim Archivnamen leitet sich von der Version ab

  3. FW = Freeware, SW = Shareware, SWE = Shareware (eingeschränkt)

  4. zu [4]: Tools nur für Mäuse erhältlich und dort einsetzbar, z.B. um "Download mit TIC" anzubieten, normalerweise DOS-Programme


6 Wichtige Hinweise, Abstimmungsergebnisse usw

Hier habe ich mal völlig unverbindlich die Sachen über das Verhalten im MausNet zusammengesucht, die mir wichtig erscheinen.


6.1 IN und Kommerz

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:

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

6.2 IN und Kommerz FAQ

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:

  • dienen in erster Linie dem eigenen Gelderwerb/-ersparnis durch die Wirkung der Aktion die Nutzerschaft, also:

    • Anzeigen für neue Produkte / -releases

    • Anzeigen für bekannte Produkte

    • Schilderungen von Leistungumfang, Verfügbarkeiten ...

    • Preislisten u.ä.

  • dauerhafter Support für Produkte des Herstellers gegenüber dem Kunden

  • Durch den Anbieter oder mittelbar daran Verdienende bewertete Informationen über Produkte auf Anfrage in einer Newsgruppe (Vergleichende Werbung)

  • Wissentliches Zurückhalten von Information zum eigenen oder mittelbar eigenen Nutzen. (bspw. Dienstleistung statt Information anbieten)

  • Product placement durch den Hersteller oder mittelbar daran Verdienende Das umfasst insbesondere auch Hinweise von Dienstleistungsanbietern, die das erst durch sie mögliche Produkt ankündigen. (Announce: Neuer Dienst X bei Y)

  • Hinweise auf Sponsoring (Werbung)

  • unmotivierte regelmässige Meinungseusserung zu Produkten auch von Kunden

Nicht als gewerblich wird angesehen u.a.:
  • Support von Kunden gegenüber Kunden (Hilfestellungen, Tips, ...)

  • Persönliche Erfahrungen mit Produkten auf Anfrage in einer Gruppe

  • Product placement durch (un)zufriedene Kunden auf Anfrage in einer Gruppe

  • FAQs zu übergeordenten Themen

Bem: (Dienst)Leistungen sind auch Produkte. Die obrigen Auszählungen sind nicht vollständig. Selbstverständlich gibt es eine Grauzone, die im Falle der Einmaligkeit als Nichtgewerblich beurteilt wird. Fortgesetztes oder defaultmässiges (Softwarekonfiguration) Gebrauchen der Grauzone wird als gewerblich beurteilt. Die Höhe der erwarteten Einnahmen steht nicht in Zusammenhang mit dem gewerblichen Charakter eines Postings. So zählt selbstverständlich auch Shareware in den gewerblichen Bereich.
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
Student der Informatik und arbeitet für div. Firmen
private EMail: willi.wusel@in-domain.de

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:

  • Eine Sponsoring-Information der Form "Wir bedanken uns bei Firma gargelpueh GmbH, Irgendwo, für die freundliche Bereitstellung von 350 Modems und 27 Linux-Servern" darf eingebaut werden, wenn keine "volle" Anschrift gegeben wird, d. h. nur Firmenname und Ort, aber nicht volle Anschrift, Telefonnumern o. ä. Damit ist der Leser in jedem Falle gezwungen, selbst noch zu recherchieren, es handelt sich also nicht um eine Form der Werbung, die auf "sofort da anrufen" hinausläuft.

  • Wenn die Firma, die erwähnt wird, anderswo direkt am Netz hängt und WWW-Seiten hat, darf in der Sponsoring-Information nicht direkt eine URL dorthin veröffentlicht werden, sondern es sollte zunächst eine Seite dahintergehängt werden, die klarstellt, daß die IN- Domain eine nichtkommerzielle Betreibergemeinschaft ist und daß eine klare organisatorische Trennung zwischen dieser Firma und der IN- Domain besteht. Wenn der WWW-Benutzer dann den Firmen-URL vorfindet und anwählt, hat er auf jeden Fall lesen können, wie die Zusammenhänge aussehen. Möglicherweise sollte man in dieser "Zwischenseite" direkt noch einen Link auf ein zentrales "IN-Non-Kommerz-Dokument" aufnehmen.

  • Firmen*logos* nicht auf die WWW-Hauptseite, sondern - wenn überhaupt - auf eine separate "Sponsoren"-Seite.


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:
jc@hb.maus.de - gs@k2.maus.de - ms@bm.maus.de

6.3 Sysop-Info

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:

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.

6.4 Mitlesen von Betreibern Stand-alone Mäusen in den Sysopgruppen

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.

6.5 Wo sollen neue Betreiber und neue CoSysops angekündigt werden?

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).

6.6 geschäftsmäßiger <> geschäftlicher / BDSG

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

6.7 Die fünf goldenen Regeln für Sysops

  1. Regel: Schreibe keine Msgs wenn du schlecht geschlafen hast.

  2. Regel: Schreibe keine Msgs wenn du sehr müde bist.

  3. Regel: Schreibe am besten überhaupt nix...:-)

  4. Regel: Schreibe keine Msgs wenn Du schlechte Laune hast.

  5. Regel: Regst Du Dich über irgendetwas auf (insbesondere über Kollegen), tritt Regel Nr. 4 in Kraft.

6.8 Betreffkürzel in Programme

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:

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.


7 Was für Programme für die Maus gibt es sonst noch?

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 '-'.


7.1 ANAMSG

Archivename:

ANAMSG14.ZIP

Archivlänge:

24981

Beschreibung:

ANAMSG Version 1.4 - analysiert die Lesegewohnheiten eurer User

Autor:

Jörg Stattaus

7.2 BINKCOST

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

7.3 Binkley_Term

Archivename:

BDOS_259.LZH

Archivlänge:

339701

Beschreibung:

Binkley Term V 2.59 für DOS
Auch eine 386er (extender) Version dabei. Kann als Mailer für MAUS-FIDO Gates verwendet werden.

7.4 CDDRV

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)

7.5 CDPTH

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.

7.6 Chefwart

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-

7.7 Erwinsgate

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

7.8 DRIVEDA

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.

7.9 DokuServe

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

7.10 FIXPPAR

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!

7.11 FixRnum

Archivename:

FXRNM215.ZIP

Archivlänge:

17951

Beschreibung:

FixRnum - Messagebasereparierer V 2.15

7.12 Formelinterpreter

Archivename:

FORMEL.ZIP

Archivlänge:

21044

Beschreibung:

Der Formelinterpreter von Andreas Mayer @ ZW für den Sysop-Teil der MAUS

Autor:

Andreas Mayer @ ZW

7.13 ForwardPM

Archivename:

FWDPM20.ARJ

Archivlänge:

37512

Beschreibung:

FWD_PM Version 2.0 Programm zum weiterleiten von PMs

7.14 GATE2GRP

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

7.15 GATESTAT

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

7.16 Güntersgate

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


7.17 Gateway Beschreibung

Archivename:

GATEWAY.ZIP

Archivlänge:

31081

Beschreibung:

Beschreibung zum Gateway von Günter Stück Als TEX und DVI.

7.18 GENDBDIF

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

7.19 GLASNOST

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

7.20 GODLIKE

Archivename:

GODLIKE.EXE

Archivlänge:

11391

Beschreibung:

Setzt von der Kommandozeile aus für beliebige User den Sysop-Status.

Autor:

Michael Keukert @ AC2

7.21 GroupStat

Archivename:

GRPST12.ZIP

Archivlänge:

18434

Beschreibung:

GroupStat V 1.2 Erstellt Statistik über das Messagevolumen von Gruppen

7.22 HISTAT

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

7.23 James

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

7.24 Jane

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

7.25 Jerry

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

7.26 Jimmy

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

7.27 KILLLOKL

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

7.28 KILLMSG

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

7.29 Klette

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:

7.30 KrunUser

Archivename:

KrunUser

Beschreibung:

Programm um die als gelöscht markierten User auch wirklich aus den Mausdaten zu löschen.

7.31 M2M-Gate

Archivename:

M2M.ZIP

Archivlänge:

20216

Beschreibung:

Maus-to-Maus-GateWay Stand 21.11.94

7.32 MAKEPKT

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

7.33 MakeTIC

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.
V 0.4: Es können ISAM-Indexdateien verwendet werden, dadurch noch schneller
V 0.5: Wird benoetigt fuer (alten) ProgTeil ohne ProgTeilDatPath, da die Units der 0.4 einen Bug hatten.

Autor:

Frithard Meyer-zu-Uptrup @ S3

7.34 MAUS CD CONTROLLER

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

7.35 MausChat

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:

7.36 MAUSDOOR

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

7.37 Mausdown

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

7.38 MausFile

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

7.39 MausFileSucher

Archivename:

MFS108.ZIP

Archivlänge:

119244

Beschreibung:

MausFileSucher 1.08. Der MAUS-Archie.

7.40 MausRingComander

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

7.41 mcall.exe

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

7.42 MCC

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

7.43 MCDC

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.

7.44 MCLOCK

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

7.45 MegaHang

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.

7.46 MEVENT

Archivename:

MEVENT.ARJ

Archivlänge:

11876

Beschreibung:

Zeigt die Maus-Events im grafischen Überblick an. Kurz und gut!

Autor:

Michael Keukert @ AC2

7.47 MFORMEL

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

7.48 MLZWO

Archivename:

MLZWO.ZIP

Archivlänge:

22063

Beschreibung:

MLZWO - Neue Version 5/94 Verwaltet Mailinglisten

Autor:

Marcus Schmidke @ BM

7.49 MPROGVW

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

7.50 MPWD

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

7.51 MSGID-EXE

Archivename:

MSGID111.ZIP

Archivlänge:

23335

Beschreibung:

Analysiert die vergebenen MSG-Ids (Allg & Pers) und man kann die ID damit auch setzen.

7.52 MT2BIN

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

7.53 MUSER.EXE

Archivename:

Beschreibung:

Trägt $-User in Gruppen ein, die über die Kommandozeile übergeben werden.

7.54 MUVIEW

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

7.55 MVIEW

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

7.56 MV-Pack

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

7.57 NetJames

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

7.58 NETMC

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

7.59 NetStat

Archivename:

NSTAT19.ZIP

Archivlänge:

59468

Beschreibung:

Netstat V 1.9. Kann bereits das Tarifsystem ab 1.1.96 Realmode und DPMI

7.60 NewUse2Maus

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

7.61 Rejectit

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)

7.62 REQUEST

Archivename:

REQUEST.ZIP

Archivlänge:

304830

Beschreibung:

Wie man der Maus den FidoNet Filerequest beibringt.

Autor:

Michael Keukert @ AC2

7.63 SCHEDULE

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

7.64 Schnulli

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

7.65 Service-Programm

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

7.66 SETPTDAT

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.

7.67 Speedtausch

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

7.68 TeamShell

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

7.69 TICTAC11

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

7.70 TOPLINES

Archivename:

TOPLIN11.ZIP

Archivlänge:

12137

Beschreibung:

TopLines v1.1, zeigt jetzt auch Anrufzahl und Zahlerstatus an.

7.71 VONXY

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

7.72 XENOPHOB

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


8 Die Maus-News-Files der letzten Versionen

Die gesammelten News-Texte aller Mausversionen sollten eigentlich immer in der K2, Gruppen-PT Sysop.Prog liegen. Deshalb hier nur die der letzten Versionen.


8.1 Welche Softwareversionen sind aktuell?

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:

Tabelle 9: Maussoftversionen in K2 letzte Änderung: 07.07.96 gs
MAUS7.95i
MausNet2.54
MNconfig2.0
NetStat1.9
KrunUser2.95
Fwd-PM2.1
MsgID1.11
OUT_IN1.0
TopLines1.1

Aktuelle Versionen von Hilfsprogrammen zur Maus (Monatliches Posting in der Gruppe Tools.Beta)

Tabelle 10: Aktuelle Versionen von Hilfsprogrammen zur Maus (Stand 16.2.97)
Programmaktuelleaktuelleaktuelle
ReleaseBetaEntwicklerversion
BinkCost2 (incl. Source)2.0
CDFNet (incl. Source)1.0
Gate2Grp1.01.1
Gatestat1.2
Glasnost (incl. Source)1.0
Histat0.2
KillLokl (incl. Source)1.0
KillMsg (incl. Source)1.0
MC Mausring Commander2.41
MCC Maus Control Center0.59
MCall1.0
MClock0.1
MFormel1.01
MProg (incl. Source)1.0
MT2Bin (incl. Source)1.2d1.2j
MUView0.1
MUser1.0
MView0.05
MakePkt (incl. Source)0.01
Maus2RA (incl. Source)1.4
MausDoor1.1
MausDown1.0
MausFile2.7
MistPassword1.4
NetMC (Fileversand per Netz)0.4
Schedule (Autom. Abrechnung)1.0
VonXY (incl. Source)1.0
Xenophob (Zufallspassworte)1.01.1

Tabelle 11: Sourcen verloren, daher Entwicklungsstopp bei:
Programmaktueller
Release
DokuServe0.7
MEvent1.0 (klappt nicht mit Multiplex-Events)

8.2 Bekannte Bugs, Probleme zur Maus

Folgendes ist bei der aktuelle Maussoft zu beachten

8.3 News zur Maus 7.95h


8.3.1 What's new in MAUS 7.95h?

MNconfig:

8.4 News zu Maus 7.95i und MNConfig 2.0

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


8.4.1 What's new in Maus 7.95i

8.4.2 Änderungen am MNconfig:

8.4.3 Ergänzung zum Programmteil Maus 7.95i

Von : Frithard Meyer-Zu-Uptrup @ S4 (Do, 11.07.96 15:12)

Ferner zum Programmteil:

Änderungen am Programmteil

MAUS 7.95i Programmteil V 35

fritz

8.5 News zu Maus 7.95j und MNConfig 2.01


8.5.1 What's new in Maus 7.95j

8.5.2 Änderungen am MNconfig 2.01


9 Die Variablen aus der m7com

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.


9.1 AbschiedsText

Default:

'Tschüß'

Bedeutung:

Damit werden die Benutzer verabschiedet. Also 'Tschüß, Herr Heinz'

Einzutragen in m7com.cfg

9.2 AllgDupMax

Default:

'500'

Bedeutung:

Soviele Mails durchsucht der Dupecheck in der Maus bei öffentlichen Mails. Defaultwert ist DupMaxDefaultUser bzw DupMaxDefaultGate

Einzutragen in m7com.cfg

9.3 AllgProgPath

Default:

'MausPath\MAUSPROG\'

Bedeutung:

In dem Verzeichnis werden die Ordner für die verschiedenen Betriebssysteme angelegt

Einzutragen in m7com.cfg

9.4 AMIGAProgPath

Default:

'GruppenProgPath\AMIGA\'

Bedeutung:

Pfad für Programme des AMIGA-Betriebssystems

Einzutragen in m7com.cfg

9.5 AsyncTauschPath

Default:

'MausPath\AsyncTau\'

Bedeutung:

Pfad für den AsyncTausch

Einzutragen in m7com.cfg

9.6 AutoEventX

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

9.7 AutoLogX

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:
AutoLog3 := 'ZyXEL'; ''
Dann startet der Event 67 auf der Maus (Fax annehmen).
AutoEvent3 := 67 ; [0]

Einzutragen in m7com.cfg

Siehe Auch die Frage dazu.

9.8 BangLogout

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

9.9 BatchExecPath

Default:

MausPath

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

9.10 BatchWorkPath

Default:

'MausPath\Batch\'

Bedeutung:

Pfad in dem die Uploads, Packerergebnisse usw landen.

Einzutragen in m7com.cfg

9.11 BeepNeuUser

Default:

FALSE

Bedeutung:

Was passiert hier? Hmmmmm..:-)

Einzutragen in m7com.cfg

9.12 BeitragsLevel

Default:

'0'

Bedeutung:

Beitragslevel sagt, wie die MAUS die Beiträge "einfordern" soll.

0

"Hier wird nicht gezahlt", Default

1

"Man darf zahlen": in HiScore- und UserListe gibt's ein '$' für Zahler

2

"Zahlen wird gern gesehen": extra Zahler-Liste unter Benutzerliste verfügbar

3

"Eigentlich sollte man ja zahlen": in der Anrufstatistik erscheint eine Zahlungsmoral

4

"Eigentlich man muß zahlen": '/' = muß noch zahlen erscheint in der Benutzerliste

5

Warnung beim Einloggen 14 Tage bevor Zahlung abläuft

6

Nach abgelaufener Zahlung wird beim Einloggen daran erinnert

7

"Ihr sollt zahlen !": beim Einloggen erhalten alle aktiven Benutzer bei 50% der Anrufe (Zufall) einen freundlichen Hinweis auf (I)(M).

8

Neu einloggen gesperrt für Nicht-Zahler.

9

reserviert

10

reserviert

Einzutragen in m7com.cfg

9.13 BoxConfPath

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

9.14 CallCheckAtInterval

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

9.15 CharWaitTimeOut

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

9.16 ChatExtern

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

9.17 ChatMenuePunkt

Default:

'0'

Bedeutung:

Extern.X.Menue-Nummer für den Chat.

Einzutragen in m7com.cfg

9.18 ChatOhneNachfrage

Default:

FALSE

Bedeutung:

Bei TRUE wird ohne Nachfrage der CHAT gestartet.

Einzutragen in m7com.cfg

9.19 ChatZeitAnrechnen

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

9.20 CheckBetweenCalls

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

9.21 CheckBreak

Default:

FALSE

Bedeutung:

Wenn das TRUE ist, kann man die MAUS mit Ctrl-Break killen. Keine gute Idee.

Einzutragen in m7com.cfg

9.22 CheckFreeList

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!
mfg,

_______
 _/_ (
 / rank

Einzutragen in m7com.cfg

9.23 CheckSnow

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

9.24 CloseAllHandles

Default:

FALSE

Einzutragen in m7com.cfg

9.25 CloseFilesDebug

Default:

FALSE

Einzutragen in m7com.cfg

9.26 CommitCache

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

9.27 ComPort

Default:

'2'

Einzutragen in m7com.cfg

9.28 ComSpec

Default:

Enviroment-Variable SHELL aus der CONFIG.SYS

Einzutragen in m7com.cfg

9.29 ConfigFile

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

9.30 ConfigRequestFile

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.
Nachdem das aber zu starken Verzögerungen beim hochfahren der Maus führte, wartet die Maus jetzt nicht mehr.

Einzutragen in m7com.cfg

9.31 ConfigVerbose

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

9.32 ConnectBaudX

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:
10 Bit/Byte ohne Fehlerkorrektur, 8 Bit/Byte mit. Also: 16800/10=1680, 16800/8=2100 und von den Werten zieht man dann nochmals ca. 10% für den Protokoll-Overhead und eventuelle Schlechte Leitungen ab.

Einzutragen in m7com.cfg

9.33 ConnectEventX

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

9.34 ConnectMitPort

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

9.35 ConnectOhneARQ

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

9.36 ConnectStringX

Default:

'CONNECT'

Bedeutung:

String, den das Modem beim Connect meldet


Beispiel:
ConnectString1 := 'CONNECT 14400/*'
ConnectBaud1 := 14400

Es sind maximal 40 verschiedene Connect-Strings möglich.

Einzutragen in m7com.cfg

9.37 ConsoleKey.FX

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:

ConsoleKey.F5

'JFrithard Meyer-Zu-Uptrup^MGeheim^M'; Login

ConsoleKey.F6

'pad-7^M^Ml'; Progliste der letzten 7 Tage

ConcoleKey.F7

#222'JChristian Goßlar'; Anstatt ALT-222 usw nur ALT-F8 Der Eintrag im m7com.cfg sieht dann so aus:

ConsoleKey.F7 := #222'JChristian Goßlar'

ConcoleKey.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.

Siehe auch das Kapitel zum Konsolenlogin

Einzutragen in m7com.cfg

9.38 CRbeforeAT

Default:

TRUE

Bedeutung:

Bei FALSE wird vor dem AT kein CR gesendet

Einzutragen in m7com.cfg

9.39 DefaultSysOpName

Default:

'SysOp'

Bedeutung:

Wird als Defaultwert für den Eintrag von SysOpName im EXTERN.CFG benutzt.

Einzutragen in m7com.cfg

9.40 DelayVorProt

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

9.41 DirectBaud

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

9.42 DirectChat

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

9.43 DirectDCDignore

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

9.44 DirectLog

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

9.45 DirectLogin

Default:

FALSE

Bedeutung:

Siehe Direktlogin-Anleitung. Wenn DirectLogin FALSE ist, fehlen auch alle anderen DirectLogin-Variablen im m7com.req.

Einzutragen in m7com.cfg

9.46 DirectTextInfile

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

9.47 DirectPortModemSimulator

Default:

FALSE

Bedeutung:

DirectPortModemSimulator (Boolean, default FALSE). Bei TRUE versucht die MAUS auf dem DirectPort ein Modem zu simulieren:

  • alle Eingaben werden geecacht.

  • bei CR wird der Eingabe-Puffer des DirectPorts gelöscht.

  • wenn "ATblabla" ankommt, sendet die MAUS "OK"

  • wenn DirectRing ankommt, sendet die MAUS "CONNECT xxx" mit xxx=DirectBaudRate

  • wenn grade ein User drin ist, sendet die MAUS stattdessen "BUSY"

  • beendet man ein DirectLogin, sagt die MAUS "NO CARRIER"

  • die MAUS schaltet DTR am DirectPort jetzt so, daß man damit auf der anderen Seite CD bedienen kann. Dazu braucht man aber ein spezielles Kabel, etwa so:


   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

9.48 DirectPortRtsCts

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

9.49 DirectPortShowLogin

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

9.50 DirectPortWakeup

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

9.51 DirectRing

Default:

'222'

Bedeutung:

Zeichenfolge zum einloggen über den Direktport Siehe auch Direktlogin-Anleitung

Einzutragen in m7com.cfg

9.52 DirectShowLogin

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

9.53 DirectTime

Default:

'howl8'

Bedeutung:

Wenn über den DirectPort der String aus DirectTime empfangen wird, sendet die MAUS die aktuelle Uhrzeit.

Einzutragen in m7com.cfg

9.54 DisconnectWait

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.
Ich fahre hier in Berlin mit einem Wert von 1 sehr gut. Keine Beschwerden von Usern wegen fehlender Zeichen beim Übertragen, dafür aber ein schon schneller Logout.

Einzutragen in m7com.cfg

9.55 DownloadSperre

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

D

- Sperre deaktiviert,

N

- Uploads von Neulingen werden gesperrt,

$

- Uploads von Nichtzahlern werden gesperrt.

James unterstützt diese Feature im Moment nur in der Betaversion.

Einzutragen in m7com.cfg

9.56 DOSProgPath

Default:

GruppenProgPath\DOS\'

Bedeutung:

Pfad für Programme des DOS-Betriebssystems

Einzutragen in m7com.cfg

9.57 DSZlogFile

Default:

''

Einzutragen in m7com.cfg

9.58 DtrDelay

Default:

'300'

Bedeutung:

Bestimmt wie lange DTR runtergezogen wird. Angabe in ms.

Einzutragen in m7com.cfg

9.59 DumpCore

Default:

FALSE

Bedeutung:

Soll das File 'Core.Dmp' (im MausPath) erzeugt werden? Keine Ahnung, was das ist.

Einzutragen in m7com.cfg

9.60 DupMaxDefaultGate

Default:

'2000'

Bedeutung:

Soviele Mails durchsucht die Maus nach Dupes beim Gatetausch.

Einzutragen in m7com.cfg

9.61 DupMaxDefaultUser

Default:

'500'

Bedeutung:

Soviele Mails durchsucht die Maus beim Dupecheck

Einzutragen in m7com.cfg

9.62 EditorName

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

9.63 EliminateBirthDayLier

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

9.64 EventXXAktiv

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

9.65 EventXXBisZeit

Default:

''

Bedeutung:

EventXXBisZeit - spätestmögliche Zeit für Event XX Siehe EventXXVonZeit

Einzutragen in m7com.cfg

9.66 EventXXDauer

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

9.67 EventXXHinweis

Default:

''

Bedeutung:

Text-Beschreibung der Events,

Einzutragen in m7com.cfg

9.68 EventXXMultiplex

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

9.69 EventXXVonZeit

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

9.70 EventXXWurfZeit

Default:

''

Bedeutung:

Zeit, zu der ein User gewaltsam hinausgeworfen wird. Siehe EventXXVonZeit

Einzutragen in m7com.cfg

9.71 ExternMenue

Default:

TRUE

Bedeutung:

Aktiviert den ExternMenü-Eintrag in Hauptmenü. Sinnvollerweise definiert man dann auch externe Programme

Einzutragen in m7com.cfg

9.72 ExternX.Acc

Default:

'1'

Bedeutung:

Bestimmt ab welchen Userlevel ExternX.Name erscheint.

0 ab Gäste

1 ab User

2 ab Zahler

3 ab SysOp

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

9.73 ExternX.Door

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

9.74 ExternX.Event

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

9.75 ExternX.Name

Default:

''

Bedeutung:

Das ist der Name, der im Externen-Menü erscheint. In Klammern wird der Buchstabe zum anwählen des Externen Programmes angegeben. Beispiel:
Extern1.Name := '(M)aus B Service'; [' ']

und das EXTERN.BAT sieht dann so aus (normales DOS):


if "%1"=="M" goto service
goto trente
:service
c:
cd \maus
service.exe
goto trente
:trente


Einzutragen in m7com.cfg

9.76 FixedBaudRate

Default:

TRUE

Bedeutung:

Kommunikation Rechner-Modem immer mit MaxBaud

Einzutragen in m7com.cfg

9.77 FloppyDefaults

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

9.78 FlushCallInfo

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

9.79 FormelProgramm

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

9.80 GarKeinChat

Default:

FALSE

Bedeutung:

Bei TRUE wird der Punkt (K) im Hauptmenü nicht mehr angezeigt.

Einzutragen in m7com.cfg

9.81 GeizhalsNach

Default:

'40'

Bedeutung:

Nach wievielen Anrufen gilt ein Anrufer als Geizhals.

Einzutragen in m7com.cfg

9.82 GeizhalsSchonfrist

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

9.83 GeizhalsTauschLimit

Default:

'0'

Bedeutung:

Ein Wert >0 gibt an, wie groß (in Kilobytes gemessen) das OUTFILE.TXT eines Geizhalses sein darf

Einzutragen in m7com.cfg

9.84 GeizhalsTauschOK

Default:

TRUE

Bedeutung:

Bei FALSE wird der MausTausch für Geizhälse gesperrt. Gilt nicht für Sysops

Einzutragen in m7com.cfg

9.85 GetCallWithDTR

Default:

FALSE

Bedeutung:

Bei TRUE Anruf über S0=1/DTR^ annehmen anstatt über ATA

Einzutragen in m7com.cfg

9.86 Gruppenliste.Oeffentlich

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

9.87 GruppenProgPath

Default:

MausPath\GRUPROG\'

Bedeutung:

Pfad für die Gruppenprogrammteile

Einzutragen in m7com.cfg

9.88 InfoFileCRCcache

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

9.89 InfoPath

Default:

MausPath

Bedeutung:

Hier liegen die Infotexte der Maus. Also eigentlich alles was mit *.Inf im Mausverzeichnis rumliegt.

Einzutragen in m7com.cfg

9.90 ImmerSpannen

Default:

FALSE

Bedeutung:

Bei TRUE wird schon beim Start der MAUS der Spannermodus aktiviert.

Einzutragen in m7com.cfg

9.91 ISDNCallReject

Default:

FALSE

Bedeutung:

Siehe ISDNCallRejectEAZs

Einzutragen in m7com.cfg

9.92 ISDNCallRejectEAZs

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

9.93 KByteStattRecsAnzeigen

Default:

FALSE

Bedeutung:

Bei TRUE werden die Up-und Downloads nicht mit mit Recs (128 Byte) sondern mit KB protokolliert.

Einzutragen in m7com.cfg

9.94 LocalInfoX.Desc

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.
LocalInfoX.Desc ist die Beschreibung eines solchen Infofiles, eins der Zeichen in diesem String muss fuer die Menüauswahl 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.

Einzutragen in m7com.cfg

9.95 LocalInfoX.File

Default:

''

Bedeutung:

Lokales Infofile. Siehe LocalInfoX.Desc

Einzutragen in m7com.cfg

9.96 LogChat

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

9.97 LogFileStatMitISDN

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

9.98 LogLevel

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

9.99 LogIgnored

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

9.100 LogInHinweisX

Default:

'' X von A bis Z möglich

Bedeutung:

Hinweis zur Loginzeit

Einzutragen in m7com.cfg

9.101 LogInProgX

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

9.102 LogInZeitX

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.
Insgesamt können LogInZeiten von A-Z definiert werden. Jede Definition gilt stundenweise, bis eine andere Definition eintritt.
Wenn eine Zeit auf 0 gesetzt ist, ist diese Anruferklasse für diese Zeit gesperrt und wird vorm Hauptmenü wieder aus der MAUS geworfen.

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

9.103 LogPath

Default:

MausPath

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

9.104 LowMemoryLimit

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

9.105 MACINTOSProgPath

Default:

GruppenProgPath\MACINTOS\'

Bedeutung:

Pfad für Programme des MACINTOS-Betriebssystems

Einzutragen in m7com.cfg

9.106 MausHeader

Default:

''

Bedeutung:

Mit dem Text werden die User beim einloggen begrüßt.

Einzutragen in m7com.cfg

9.107 MausMeter.ZugangAb

Default:

'G'

Bedeutung:

Ab dieser Userklasse ist der Mausmeter-Zugang erlaubt

Einzutragen in m7com.cfg

9.108 MausNetPath

Default:

MausPath\net

Bedeutung:

Pfad für MNconfig, MausNet

Einzutragen in m7com.cfg

9.109 MausPath

Default:

'\MAUS\'

Bedeutung:

Hier wird der Pfad für die Maus festgelegt.

Einzutragen in m7com.cfg

9.110 MausPMRealName

Default:

FALSE

Bedeutung:

Experimentelles Flag ab Maus 7.95j
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).

Einzutragen in m7com.cfg

9.111 MaxBaud

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

9.112 MaxConnectWait

Default:

'60'

Bedeutung:

Wie lange (in s) soll auf eine CONNECT Meldung gewartet werden

Einzutragen in m7com.cfg

9.113 MaxExceed

Default:

'5'

Bedeutung:

Gibt die Zeit in Minuten an, ab der eine harte Onlinzeitüberschreitung gegeben ist.

Einzutragen in m7com.cfg

9.114 MaxRelogins

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

9.115 MenueTrenner

Default:

TRUE

Bedeutung:

Schaltet die '-' in den Menüs an.

Einzutragen in m7com.cfg

9.116 MinRamKBFrei

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

9.117 MittAllgPath

Default:

MausPath

Bedeutung:

Pfad für die öffentliche Messagebase.

Einzutragen in m7com.cfg

9.118 MittPersPath

Default:

MausPath

Bedeutung:

Pfad für die persönliche Messagebase. Siehe auch MittAllgPath

Einzutragen in m7com.cfg

9.119 ModemAbheben

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

9.120 ModemAnnehmen

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

9.121 ModemAuflegen

Default:

'M1 H'

Bedeutung:

String, den die Maus beim Auflegen ans Modem schickt. Maximale Länge 20 Zeichen

Einzutragen in m7com.cfg

9.122 ModemCheck

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

9.123 ModemCheckS2

Default:

'S2?'

Einzutragen in m7com.cfg

9.124 ModemCheckInterval

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

9.125 ModemCmdMode

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

9.126 ModemDa

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

9.127 ModemDataMode

Default:

'O'

Bedeutung:

Mit diesem Kommando geht das Modem wieder in den Datamode.

Einzutragen in m7com.cfg

9.128 ModemExit

Default:

''

Bedeutung:

Das bekommt das Modem, beim beenden der Maus geschickt. Darf maximal 80 Zeichen lang sein.

Einzutragen in m7com.cfg

9.129 ModemInit

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

9.130 ModemLog

Default:

FALSE

Bedeutung:

Bei TRUE wird in LogPath\MODEM.LOG ein Protokoll der Kommunikation zwischen MAUS und Modem angelegt.

Einzutragen in m7com.cfg

9.131 ModemNoAutoCall

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

9.132 ModemPort

Default:

'0'

Bedeutung:

Port an dem das Modem hängt

Einzutragen in m7com.cfg

9.133 ModemPorts

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

9.134 ModemPortWakeup

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

9.135 ModemReset

Default:

'Z'

Bedeutung:

Wird beim Start der Maus ans Modem geschickt. Maximale Länge 20 Zeichen

Einzutragen in m7com.cfg

9.136 ModemStatus

Default:

''

Bedeutung:

Befehl um eventuell Statusmeldungen nach dem auflegen ins ModemLogFile zu schreiben. Interessant für die Fehlersuche.
ACHTUNG
Sobald der dort irgendwas drinsteht, wird dieser Befehl wirklich nach jedem Auflegen zum Modem geschickt und in ein File MODEM.STA geschrieben. Wenn man nicht aufpaßt, wird das File schnell sehr groß!

Maximale Länge 20 Zeichen

Einzutragen in m7com.cfg

9.137 ModemSetS2

Default:

'S2=0'

Bedeutung:

Wert des Escape-Zeichen für das MausModem festlegen.

Einzutragen in m7com.cfg

9.138 ModulDebug

Default:

FALSE

Bedeutung:

sicher irgendwas für Debug-Zwecke

Einzutragen in m7com.cfg

9.139 Modem.DeAktivVorProt

Default:

TRUE

Bedeutung:

TRUE deaktiviert den Fossilport vor dem Protokoll

Einzutragen in m7com.cfg

9.140 Modem.RedirectOK

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

9.141 Modem.ReInitNachProt

Default:

TRUE

Bedeutung:

TRUE reaktiviert den Fossilport nach dem Protokoll wieder

Einzutragen in m7com.cfg

9.142 Modem.RingCount

Default:

'0'

Bedeutung:

Damit kann eingestellt werden, beim wievielten Klingeln die MAUS abheben soll.

Einzutragen in m7com.cfg

9.143 ModemX.X00Port

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

9.144 ModemX.ComPort

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

9.145 MsgIndexMax

Default:

'0'

Bedeutung:

Siehe MsgIdxReserveAllg

Einzutragen in m7com.cfg

9.146 MsgIndexMaxAllg

Default:

'0'

Bedeutung:

Siehe MsgIdxReserveAllg

Einzutragen in m7com.cfg

9.147 MsgIndexMaxPers

Default:

'0'

Bedeutung:

Siehe MsgIdxReserveAllg

Einzutragen in m7com.cfg

9.148 MsgIdxReserveAllg

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

9.149 MsgIdxReservePers

Default:

'1000'

Bedeutung:

Siehe MsgIdxReserveAllg

Einzutragen in m7com.cfg

9.150 MTPaidOnly

Default:

FALSE

Bedeutung:

Damit kann der MausTausch den Nichtzahlern gesperrt werden

Einzutragen in m7com.cfg

9.151 NeulingFrist

Default:

'0'

Bedeutung:

Soviel Tage lang gilt ein User als Neuling.

Einzutragen in m7com.cfg

9.152 NeulingSchreibSperre

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

9.153 NeuLoginZeit

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

9.154 NetIOPath

Default:

'MausNetPath\IO\'

Bedeutung:

Path für die empfangenen/zu sendenden Netzpakete.

Einzutragen in m7com.cfg

9.155 NMittAllgPath

Default:

MausPath

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

9.156 NeuerUserErlaubt

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

9.157 NMittPersPath

Default:

MausPath

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

9.158 OS_2ProgPath

Default:

GruppenProgPath\OS_2\'

Bedeutung:

Pfad für Programme des Betriebssystems

Einzutragen in m7com.cfg

9.159 ParCacheSize

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

9.160 Partitions

Default:

'CDEFGHIJKLMNOPQRSTUVWXYZ'

Bedeutung:

Welche Partitions gibt es.

Einzutragen in m7com.cfg

9.161 PersProgPath

Default:

'MausPath\PERS\'

Bedeutung:

Pfad für den persönlichen Programmteil

Einzutragen in m7com.cfg

9.162 PackerX.Ext

Default:

unterschiedlich, X von 1 bis 20 möglich

Bedeutung:

Extension des Packers Siehe auch PackerX.Select

Einzutragen in m7com.cfg

9.163 PackerX.IDoffset

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

9.164 PackerX.IDstring

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

9.165 PackerX.Name

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

9.166 PackerX.PackRate

Default:

unterschiedlich, X von 1 bis 20 möglich

Bedeutung:

Packerrate Siehe auch PackerX.Select

Einzutragen in m7com.cfg

9.167 PackerX.Select

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:

1 (Z)IP v1.1

2 (A)RC

3 (L)Harc

4 Z(O)O

5 ZIP-SFXe

6 AR(J)

7 Z(I)P v2.0

8 L(H)A

9 bis Packer 20 sind nicht belegt

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

9.168 PackerX.ShowOutput

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

9.169 ProgDebug

Default:

FALSE

Bedeutung:

Da gibt's dann eine erweiterte Ausgabe, was der Programmteil an Dateien so öffnet, ... (Nicht zu empfehlen :-)

Einzutragen in m7com.cfg

9.170 PersDupMax

Default:

'500'

Bedeutung:

Soviele Mails durchsucht der Dupecheck in der Maus bei persönlichen Mails. Defaultwert ist DupMaxDefaultUser bzw DupMaxDefaultGate

Einzutragen in m7com.cfg

9.171 ProgSaugQuot

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

9.172 ProgTeilDatPath

Default:

''

Bedeutung:

Pfad für die Programmteilbeschreibungen

Einzutragen in m7com.cfg

9.173 ProgTeil.an

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

9.174 ProgTeil.Ö.Upload

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

9.175 ProgTeil.Ö.Download

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

9.176 ProgTeil.P.Upload

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

9.177 ProgTeil.P.Download

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

9.178 ProgTeil.*.Download

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

9.179 ProgTeil.*.Upload

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

9.180 ProgTyp.DFUE

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

9.181 ProgTyp.Packer

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

9.182 PromiDarfChatten

Default:

FALSE

Bedeutung:

Bei TRUE darf ein Promi auch außerhalb der Sprechstunde chatten (wie ein SysOp).

Einzutragen in m7com.cfg

9.183 PromptsMitESC

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

9.184 Protokoll.X.DownOK

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

9.185 Protokoll.X.ModemOK

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

9.186 Protokoll.X.MultiOK

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

9.187 Protokoll.X.Name

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

1

:= (X)

2

:= (Y)

3

:= (Z)

4

:= (M)Pt/Puma

5

:= Ymodem(G)

6

:= (H)S/Link

7 bis 10

sind nicht 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

9.188 Protokoll.X.NameMitModem

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

9.189 Protokoll.X.Restricted

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

9.190 Protokoll.X.TauschOK

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

9.191 Protokoll.X.UpOK

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

9.192 Protokoll.X.ZeitFaktor

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

9.193 PTWhatSysOpZeit

Default:

FALSE

Bedeutung:

Bei TRUE bekommt ein Programmteilwart die gleiche Loginzeit wie ein SysOp. Siehe auch SysopLoginZeit

Einzutragen in m7com.cfg

9.194 Response_BUSY

Default:

'BUSY*'

Bedeutung:

Diesen String soll das Modem bei einem besetzt zurückmelden.

Einzutragen in m7com.cfg

9.195 Response_ERROR

Default:

'ERROR*'

Bedeutung:

Diesen String soll das Modem bei einem Fehler (z.B. falsches AT-Kommando zurückliefern.

Einzutragen in m7com.cfg

9.196 Response_IgnoreX

Default:

unterschiedlich, X von 1 bis 9 möglich

Bedeutung:

Diesen String vom Modem kann die Maus ignorieren. Vorbelget sind folgende Werte:

1

RRING

2

DIALING

3

RINGING

4

ID=*

5 bis 9

''

Besonderheit bei 4:
Mit den beiden neuen Variablen ModemX.DeAktivVorProt und ModemX.ReInitNachProt kann eingestellt werden, ob der Fossilport vor dem Protokoll deaktiviert und nachher wieder reaktiviert werden soll. Die Defaults sollten für den "Standardfall" Modem + cFOS ok sein. Response_Ignore4 hat als Default jetzt auch den Wert "ID=*", so daß man sich darum nicht mehr kümmern muß und beim cFOS getrost X7 einschalten kann.

Einzutragen in m7com.cfg

9.197 Response_NO_ANSWER

Default:

'NO ANSWER*'

Bedeutung:

Diesen String soll das Modem zurückmelden, wenn kein Connect zustande kam.

Einzutragen in m7com.cfg

9.198 Response_NO_CARRIER

Default:

'NO CARRIER*'

Bedeutung:

Modem-Meldung fürs Auflegen

Einzutragen in m7com.cfg

9.199 Response_NO_DIALTONE

Default:

'NO DIALTONE*'

Bedeutung:

Diesen String soll das Modem zurückmelden, wenn kein Freizeichen da ist.

Einzutragen in m7com.cfg

9.200 Response_OK

Default:

'OK'

Bedeutung:

Diesen String soll das Modem zurückmelden, wenn ein Kommando korrekt verstanden wurde.

Einzutragen in m7com.cfg

9.201 Response_RING

Default:

'RING'

Bedeutung:

Modem-Meldung wenn es bimmelt.

Einzutragen in m7com.cfg

9.202 RingAllowedSec

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

9.203 SingleRing

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

9.204 SommerzeitUpdate

Default:

TRUE

Bedeutung:

Damit läßt sich die automatische Sommerzeit-Umstellung abschalten

Einzutragen in m7com.cfg

9.205 SONSTIGEProgPath

Default:

GruppenProgPath\SONSTIGE\'

Bedeutung:

Pfad für Programme die unter SONSTIGE einsortiert werden.

Einzutragen in m7com.cfg

9.206 SpruchDesTages

Default:

TRUE

Bedeutung:

Bei TRUE wird beim einloggen ein Spruch des Tages angezeigt.

Einzutragen in m7com.cfg

9.207 StatusZeileMitFlimmern

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

9.208 ST_TOSProgPath

Default:

GruppenProgPath\ST_TOS\'

Bedeutung:

Pfad für Programme des ST-TOS-Betriebssystems

Einzutragen in m7com.cfg

9.209 SysOpImmerMitFormel

Default:

FALSE

Bedeutung:

Bei TRUE wird zum Zugang zum SysOp-Teil *IMMER* die Formel abgefragt, auch bei einem Tastaturanruf.

Einzutragen in m7com.cfg

9.210 SysopLoginZeit

Default:

'60'

Bedeutung:

Loginzeit für Sysops. Die Loginzeit für Programmteilwarte wird über PTWhatSysOpZeit festgelegt.

Einzutragen in m7com.cfg

9.211 SysOpPayWarn

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

9.212 SysopSprechstunde

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

9.213 UhrAnzeigen

Default:

TRUE

Bedeutung:

Durch UhrAnzeigen := FALSE; wird jetzt wirklich nur die Uhrzeit-Anzeige in der Statuszeile abgeschaltet.

Einzutragen in m7com.cfg

9.214 UNIXProgPath

Default:

GruppenProgPath\UNIX\'

Bedeutung:

Pfad für Programme des UNIX-Betriebssystems

Einzutragen in m7com.cfg

9.215 UploadSperrebeiKBfrei.X

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

9.216 UseDtrC

Default:

FALSE

Bedeutung:

Bei TRUE geht das Modem bei DTR auf LOW in den Commandmodus

Einzutragen in m7com.cfg

9.217 UseMsgIdxFile

Default:

TRUE

Bedeutung:

Wenn TRUE, wird das MsgIdxFile benutzt

Einzutragen in m7com.cfg

9.218 UseMsgIdxFileAllg

Default:

TRUE

Bedeutung:

Wenn TRUE, wird das MsgIdxFileAllg benutzt

Einzutragen in m7com.cfg

9.219 UseMsgIdxFilePers

Default:

TRUE

Bedeutung:

Wenn TRUE, wird das MsgIdxFilePers benutzt

Einzutragen in m7com.cfg

9.220 UseUsrIdxFile

Default:

TRUE

Bedeutung:

Wenn TRUE, wird das UsrIdxFile benutzt;

Einzutragen in m7com.cfg

9.221 UserDarfChatten

Default:

FALSE

Bedeutung:

Bei TRUE darf ein User den CHAT anwählen

Einzutragen in m7com.cfg

9.222 Userliste.Anrufzaehler

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

9.223 Userliste.Baudrate

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

9.224 Userliste.Inaktivitaet

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

9.225 Userliste.ZahlerStatus

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

9.226 Userliste.ZugangAb

Default:

'G'

Bedeutung:

Ab welchen Userlevel ist der Zugang zur Userliste möglich.

Einzutragen in m7com.cfg

9.227 UserPath

Default:

MausPath

Bedeutung:

Beim beenden der Maus wird ein User-Index in der Datei
MUSER.IDX

gesichert und beim start dann wieder eingelesen, wenn die User-Dateien nicht neuer sind. Der Mausputz löscht die Datei, damit mindestens einmal am Tag die Files neu aufgebaut werden.

Einzutragen in m7com.cfg

9.228 UseDtrH

Default:

TRUE

Bedeutung:

Auflegen der Verbindung mit DTR = low. Bei FALSE geschieht es mit "+++" und dann mit ModemAuflegen

Einzutragen in m7com.cfg

9.229 UseMausAlias

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

9.230 UseXmodemExtern

Default:

FALSE

Einzutragen in m7com.cfg

9.231 Uuuaaah

Default:

TRUE

Bedeutung:

Mit FALSE kann das "Gähnen" zwischen 1 und 4 Uhr morgens abgeschaltet werden. :-)

Einzutragen in m7com.cfg

9.232 WaitforDCDafterConnect

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

9.233 WaitWithATA

Default:

'0'

Bedeutung:

Wie lange (in ms) soll nach dem RING noch mit dem ATA gewartet werden

Einzutragen in m7com.cfg

9.234 WatchDog

Default:

FALSE

Bedeutung:

WatchDog, der bei CarrierLost in externen Programmen einen Reset auslöst

Einzutragen in m7com.cfg

9.235 WINDOWSProgPath

Default:

GruppenProgPath\WINDOWS\'

Bedeutung:

Pfad für Programme des WINDOWS-Betriebssystems

Einzutragen in m7com.cfg

9.236 WriteSuccessMsg

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

9.237 XonPause

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

9.238 <Gruppenname>.CD

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

9.239 <Gruppenname>.GrpMsg

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.
Der Gruppenname ist hierbei nicht unbedingt identisch mit dem normalerweise in der MAUS verwendeten, wg. DOS-Filenamen-Konventionen. Die korrekte gewandelte Form kann im M7COM.REQ bei den .GruppPath-Variablen gefunden werden.

Einzutragen in m7com.cfg

9.240 <Gruppenname>.GrpMsgLocal

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

9.241 <Gruppenname>.GruppPath

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


10 Mausputz-Variablen

Am einfachsten ist es, die Mausputz-Variablen auch in die m7com.cfg einzutragen. Viele Sachen sind dort sowieso schon definiert (Gruppen-Pfade usw).


10.1 AllgFreiKB

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

10.2 AufbewahrungsCheck

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

10.3 BAltKA

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

10.4 BAltKZ

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

10.5 BAltLZ

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

10.6 BEinmalKA

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

10.7 BEinmalKZ

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

10.8 BEinmalLZ

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

10.9 BNeuLZ

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

10.10 CDGruppe

Default:

''

Bedeutung:

???

Einzutragen in m7com.cfg oder Mausputz.cfg

10.11 ForceAllwaysProgPutz

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

10.12 KrunchMax

Default:

'60000'

Bedeutung:

Siehe KrunchProzent

Einzutragen in m7com.cfg oder Mausputz.cfg

10.13 KrunchProzent

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

10.14 GrpRenExpire

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

10.15 MsgOutActivePM

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

10.16 MsgOutDefaultAnzahl

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

10.17 MsgOutDefaultKB

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

10.18 MsgOutDefaultTage

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

10.19 MsgOut_<Gruppenmane>

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

10.20 MsgOutOldPM

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

10.21 NumFiles

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

10.22 PersProgOutNew

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

10.23 PersProgOutOld

Default:

'20'

Bedeutung:

Nach der Zeit in Tagen werden persönliche Programme, die abgeholt wurden, gelöscht.

Einzutragen in m7com.cfg oder Mausputz.cfg

10.24 PutzUploadDirs

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

10.25 SYSOPSverschonen

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

10.26 TotalMsgMax

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.


11 MausNet-Variable

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.


11.1 AbwimmelFile

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

11.2 AmEndeAbheben

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

11.3 AnfangSenden

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

11.4 CallDelay

Default:

'15'

Bedeutung:

Anwahlpause die das Mausnetz zwischen zwei Versuchen einlegt.

Einzutragen in mausnet.cfg

11.5 CallOrder

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

11.6 DSZLOGFile

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

11.7 DontCall

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

11.8 DontScroll

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

11.9 DontWaitFor

Default:

''

Bedeutung:

Auf diese Boxen unter einem wird beim Nachtnetz nicht gewartet bis sie angerufen haben.

Einzutragen in mausnet.cfg

11.10 DualLine

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

  • DualLine 2 Betriebsarten:

  • DualLine = TRUE [Default] -> 2 Modems an 2 Leitungen (Modem und ISDN)

  • DualLine = FALSE -> 2 Modems an 1 Leitung (2 verschiedene Modems)

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

11.11 EndeNachOben

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

11.12 EndeNachUnten

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

11.13 EndeVonOben

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

11.14 EndeVonUnten

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

11.15 ExportMax

Default:

'65535'

Bedeutung:

??

Einzutragen in mausnet.cfg

11.16 FehlerBusy

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

11.17 FehlerNoAnswer

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

11.18 FehlerNoCarrier

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

11.19 FehlerNoDialtone

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

11.20 FehlerVerbindung

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

11.21 Funkuhr

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

11.22 FunkuhrZeitFuerMin

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

11.23 InitToMAUSCount

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:

InitToMAUSDelay

Einzutragen in mausnet.cfg

11.24 InitToMAUSDelay

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

11.25 InitToNetDelay

Default:

'3000

Bedeutung:

??? Das gleiche wie InitToMAUSDelay ?

Einzutragen in mausnet.cfg

11.26 LangePersMsg

Default:

'5000'

Bedeutung:

???? Auch beim lokalen PM-Export Ausgabe der Msglänge, wenn größer LangePersMsg

Einzutragen in mausnet.cfg

11.27 MaxFiles

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

11.28 MinBaudXY

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

11.29 Modem.Nummer.XY

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

11.30 ModemDialPost

Default:

''

Bedeutung:

Eigentlich abgeschaft. Steht aber noch drin.

Einzutragen in mausnet.cfg

11.31 ModemDialPre

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

11.32 MsgStatTage

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

11.33 NetGrpExport

Default:

'0'

Bedeutung:

??? Keine Ahnung

Einzutragen in mausnet.cfg

11.34 NoExpTo

Default:

''

Bedeutung:

??? Keine Ahnung

Einzutragen in mausnet.cfg

11.35 PMMassenFilter

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

11.36 PMMassenHinweis

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

11.37 PMVerlustMax

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

11.38 PMVerlustMin

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

11.39 PackZeitProMB

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

11.40 PasswordB2

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

11.41 Protokoll.XY

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

11.42 Protokoll.Bidirect

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

11.43 TimStatTage

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

11.44 UhrAbgleichMax

Default:

'300'

Bedeutung:

Wenn die Uhren um mehr als dieser Wert voneinander abweichen, gibt es keinen Uhrabgleich.

Einzutragen in mausnet.cfg

11.45 WarteAufPacken

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


12 Stichwörter / Schnellsuche

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

Gatefragen/InterNetfragen

Und hier der ganze Rest


A Sysoptreffen Mosbach September 91


A.1 Einleitung zum Mosbacher Protokoll

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

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.

A.2 TOP 1: Abstimmungen in der Maus

Es wurde folgendes beschlossen:

  1. Wir haben ab jetzt folgende Abstimmungsmodi:

  2. 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.

  3. 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:

  4. 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).

  5. 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.

  6. 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.

  7. 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.

  8. 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.

  9. Als Abstimmungsleiter wurden gewählt:

   Abstimmungsleiter:   Erwin Timmerbeil @ BN
   Stellvertreter:      Frank Tegtmeyer @ HRO

A.3 TOP 2: Individual Network

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:

  1. Nach außen hin nehmen alle Mäuse am IN teil!

  2. 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!

  3. Wir empfehlen jeder Maus, am IN teilzunehmen. Dies gilt insbesondere auch für neue Mäuse, die neu in das Netz kommen.

  4. 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.

  5. 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.

  6. 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.

A.4 TOP 3: Ignorer in Kunterbunt

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.

A.5 TOP4: Vergrößerung des Mausnetzes (Grenzen/Perspektiven)

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.

A.6 TOP 5: Topologie des Mausnetzes

Im Prinzip ging es bei dieser Frage um das gleiche wie bei Punkt 4 und wurde deshalb damit schon erledigt.

A.7 TOP 6: Farben in der Maus (ANSI-Sequenzen)

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.

A.8 TOP 7: Technische Fragen

Es wurde beschlossen, diese Fragen (Mehrbenutzer-Maustausch etc.) in den entsprechenden Gruppen zu behandeln, da dies in einer Diskussion sowieso nicht möglich ist.

A.9 TOP 8: GEnie-Gate

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.

A.10 TOP 9: Zerberus Gruppen Suche/Biete

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?)

A.11 TOP 10: Mindestanforderungen für neue Mäuse

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:

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.

A.12 TOP 11: Maus-Logo

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)

A.13 TOP 12: Pool für Hardware

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.

A.14 TOP 13: Pseudo-Accounts

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.

A.15 TOP 14: Fido 241, Dieter Soltau

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.
-------------------------------------------------

B Sysoptreffen Flensburg 9.10-11.10.92


B.1 Einleitung zum Flensburger Protokoll

         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?).

B.2 1.0. GATEWAYS:


B.2.1 1.1. Gateway Zerberus:

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

B.2.2 1.2 & 1.3 Gateway UseNet in HB

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.

B.2.3 1.4. Gateway Genie:

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.

B.2.4 1.5. lokale Gateways:

Ü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.

B.3 2.0. IN:


B.3.1 2.1 Kosten, Kostensenkung

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.

B.3.2 2.2 Kosten und Schutz bei Anschlägen von Hackern

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.

B.3.3 2.3. Alternativen zum IN:

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.

B.4 3.0. MAUS:


B.4.1 3.1. MAUS 9: wann kommt sie, was kann sie?

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:

Wünsche von Sysops, die in der MAUS 9 eingebaut werden sollen:

B.4.2 3.2. Multiport MAUS:

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.

B.4.3 3.3. Online Editor:

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.

B.4.4 3.4 Netzstruktur und Netztopologien

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.

B.4.5 3.5 neue Regelung für Netzgruppeneinrichtung

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.

B.4.6 3.6. neue Regelung für neue Sysops:

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ß:

  1. Personaldebatte unter Ausschluß des Aspiranten in SYSOPS

  2. Personaldebatte MIT dem Aspiranten in SYSOPS.NEU

  3. 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.

B.4.7 3.7. $ per MauTau setzen können (Erleichterung der Wartung):

$ 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.

B.4.8 3.8. MausTauschformat und Erweiterung:

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.

B.4.9 3.9 Verbreitung der MAUS im Osten

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).

B.4.10 3.10 Wahl eines stellvertretenden Abstimmungsleiters

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.

B.5 4.0. SYSOPS:


B.5.1 4.1. Welche Pflichtgruppen für Sysops?

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ß).

B.5.2 4.2. soll eine Gruppe SYSOP-LALL/LITE eingerichet werden?

Ja: 21 Nein: 24

B.5.3 4.3. Pflichtgruppen jeder Maus:

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

B.5.4 4.4. nächstes Treffen wo und wer?

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.

B.5.5 4.5. kommerzielle Werbung in der Maus:

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.

B.6 Anhang: Teilnehmerliste:

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)

B.7 Kurzfassung mit wichtigen Beschlüssen für MAUS.INFO

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.


C Sysoptreffen Stuttgart 7.10-10.10.93

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.


C.1 1.0 Technik


C.1.1 1.1 Bericht der Programmierer

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.

C.1.2 1.2 ISDN

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).

C.1.3 1.3 Gruppennamen

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".

C.2 2.0 Allgemeines


C.2.1 2.1 einheitliches Logo

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.

C.2.2 2.2 Markenzeichen

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.)

C.3 3. Gruppe SYSOPS / Abstimmungen

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.

C.4 4. Druckmittel für Mäuse, die Abstimmungsergebnisse ignorieren

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.

C.5 5.0 Gateways


C.5.1 5.1 Berichte der Betreiber

C.5.1.1 5.1.1 Fido

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.

C.5.1.2 5.1.2 Z-Netz

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.

C.5.1.3 5.1.3 GerNet

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.

C.5.1.4 5.1.4 Usenet

Über dieses Thema folgt an anderer Stelle ein eigenes Kapitel.

C.5.2 5.2 Gruppenexport

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.

C.6 6.0 IN/Usenetgate


C.6.1 6.1 Bericht der Betreiber (K)

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.

C.6.2 6.2 Gebühren und Mailbeschränkung

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.

C.6.3 6.3 MX-Records

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.

C.6.4 6.4 Domainverantwortlicher maus.de

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.

C.7 7.0 Maus-Lokales


C.7.1 7.1 Co-Sysops

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.

C.7.2 7.2 Doppelmäuse

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.

C.8 8.0 Maus-Guide, Moderatoren

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.

C.9 9.0 Anträge


C.9.1 9.1 DL-Team

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!

C.9.2 9.2 Regeln

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.

C.9.3 9.3 PM-Status

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.

C.9.4 9.4 geheime Gruppe

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.

C.9.5 9.5 SysOp-Treffen 1994

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.

C.9.6 9.6 Teilnehmerliste 1993

@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

C.9.7 10.0 Nachtrag zum Protokoll

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)

D Außerordentliches Sysoptreffen Wiesbaden 28.5.94

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:

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


E Sysoptreffen Oer-Erkenschwick 26.8-28.8.94

Protokoll des MausNet-Sysop-Treffens 1994
vom 26.8.-28.8.1994 in Oer-Erkenschwick


E.1 0. Vorbemerkung des Protokollführers Claus Wickinghoff @ AC3

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).

E.2 1. Begrüßung

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.

E.3 2. Technik


E.3.1 2.1 MAUS-Software

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.

E.3.2 2.2 ISDN

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.

E.3.3 2.3 UMaus

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.

E.3.4 2.4 Quark

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.

E.3.5 2.5 OS/2-MAUS

Marco Hahn @ SL: "Es gibt das Betriebssystem, es gibt ein paar Ideen und die Quark ist zwei Jahre voraus."

E.3.6 2.6 UMS-MAUS

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.

E.3.7 2.7 Warenzeichen "MausNet"

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.

E.4 3. Gateways


E.4.1 3.1 UseNet

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.

E.4.2 3.2 Mail-Massen

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.

E.4.3 3.3 Name-Server für maus.de und WWW-Page

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.

E.4.4 3.4 Z-Netz und Sub.Org-Gate

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.

E.4.5 3.5 Gateway-Koordinator

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.

E.4.6 3.6 Domainverwaltung für maus.de

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.

E.4.7 3.7 Infofiles, Gator und Adressierungs-FAQ

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.

E.5 4. Administration


E.5.1 4.1 AL-Team

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.

E.5.2 4.2 DL-Team

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.

E.5.3 4.3 Zukunft des AL-Teams

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.

E.5.4 4.4 Maschinenlesbares Format für den Abstimmungsdämon

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

E.5.5 4.5 Grundsatzpapier

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:

E.5.6 4.6 Arbeitsgruppen

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.

E.5.7 4.7 Störer in den Sysop-Gruppen

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.

E.5.8 4.8 Sysops als lokale Angelegenheit des Betreibers?

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.

E.5.9 4.9 PM-Manifest

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.

E.6 5. Gruppen


E.6.1 5.1 Neueinrichtungen und Zusammenlegungen

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.

E.6.2 5.2 überflüssige Postings in den INFO-Gruppen

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.

E.6.3 5.3 Gruppen für Produkt-Ankündigungen

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

E.6.4 5.4 Abschaffung der Gegenstimmen bei Gruppeneinrichtungen

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."

E.6.5 5.5 Notwendige Stimmenzahlen

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.

E.6.6 5.6 Pflichtgruppen

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!

E.7 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.

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 --


F Sysoptreffen Heilbronn 30.9.95

Protokoll des Sysoptreffens 1995 in Heilbronn

Datum: Samstag, der 30.9.1995


F.1 1. Bericht der Gatewaybetreiber


F.1.1 Z-Netz: Friedrich Laemmle @ H

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.

F.1.2 Fido: Timm Ganske @ OF

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.

F.1.3 Atari-Net: Roman Kunz @ GI und Udo Fleckenstein @ FÜ

Das Gate zum Atari-Net ist von GI nach FÜ verlegt worden. Soll auch das englischsprachige Atarinetz NeST importiert werden?

F.1.4 Usenet, Internet: Jörg Henne @ BB

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.

F.2 2. Bericht des AL-Teams

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.

F.3 3. Bericht der Boxprogrammierer

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.

F.4 4. Neuwahl des Al-Teams

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.5 5. regionales PM-Massenlimit

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:

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:

Weiterhin wünschen sich die anwesenden Sysops eine Steigerung der maximalen Nachrichtengröße über 16 kB hinaus.

F.6 6. Bericht über den "Megahacker"

Harald Krusekamp @ MS gibt einen ausführlichen Bericht über die Jagd auf den Megahacker, der im Sommer dieses Jahres aktiv war.

F.7 7. Vorverlegung des Nachtnetzes

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.

F.8 8. lange Gruppennamen - Importgruppen

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.

F.9 9. lange Gruppennamen - eigene Gruppen

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.

F.10 10. alternatives Netzprotokoll

>*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.

F.11 11. alternative Transportwege für Netzpakete

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.

F.12 12. das MausNet im WWW

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.13 13. Infomaterial für die IN-Geschäftsstelle

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.

F.14 14. Vergabe von regionalen Gruppen

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.
22 Stimmen.

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.
26 Stimmen

c)

Jede Maus kann 3 regionale Gruppen führen. Darüber hinausgehende Wünsche sind in Sysops vorzubringen und durchzusetzen.
1 Stimme

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.
6 Stimmen

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.

F.15 15. Betreiberwechsel

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.

F.16 16. Sysoptreffen

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.

F.17 17. Teilnehmerliste

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


G Sysoptreffen Bremen 18. Oktober 1996

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.


G.1 PARTTIME ARBEITSGRUPPEN


G.1.1 AG Soziales

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.

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.


Das Schiedsteam wird erst auf Anforderung von Usern aus 5% der Mäuse, mindestens jedoch 3, hin aktiv.


Sollen die Mitglieder des Schiedsteams auf dem SysOp-Treffen gewählt werden?


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.

G.1.2 AG MausRäte / User und SysOps

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.

G.1.3 AG Informationsfeldweg

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.

G.1.4 AG Kommerz

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?


Darf eine lokale kommerzielle Gruppe den Status Default haben, wenn der Benutzer darauf hingewiesen wird, wie er diese wieder abstellen darf?


Darf in lokalen Pflichtgruppen 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.


Im Abspann der MAUS dürfen 5 Zeilen (incl. Sternchen) für kommerzielle Belange verwendet werden.


Darf die MausNet-Adresse (Realname) nach außen hin für kommerzielle Belange verwendet werden?


Darf die technische Adressierung (Info-Account, Chef) nach außen hin für kommerzielle Belange verwendet werden?


Darf bei Fragen in öffentlichen (netzweiten) Gruppen öffentlich mit kommerziellen Inhalten geantwortet werden?


Soll eine neue (netzweite) Gruppe zur Kanalisierung von kommerziellen Inhalten gegründet werden?

G.1.5 AG Außeneinflüsse

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).

G.1.6 AG Sonstiges/Diverses

Thema

Die Arbeitsgruppe beschäftige sich mit den Themen

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.

G.2 FULLTIME ARBEITSGRUPPEN


G.2.1 AG Great Renaming

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.

G.2.2 AG Gateways

Themen

Die Arbeitsgruppe behandelte verschiedene Themen zu 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.

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.

  1. Die Splittingkonventionen müssen realisiert werden.

  2. Sender/Reply-To/Followup-To müssen unterstützt werden, sobald sie verfügbar sind.

  3. 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.

  4. 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.

  5. Als Absenderadressen sind die Angaben aus der D-Zeile im EXP zu verwenden. Mäuse ohne D-Zeile werden nicht exportiert.

  6. Transit von Mail, verursacht durch den PM-Forwarder (Usenet an Maus weitergeleitet an Usenet) muß erlaubt sein.

  7. Die Konventionen zur M-Zeile müssen implementiert sein (rudimentäre Mime-Unterstützung)

  8. 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.

G.2.3 AG AL-Team

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?


Soll das AL-Team ermächtigt werden, Aufgaben an User zu übertragen?


Soll das AL-Team auch weiterhin aus 3 Personen bestehen?


Soll die Amtsdauer des AL-Teams 1 Jahr betragen?


Soll das AL-Team jetzt sofort auf dem SysOp-Treffen gewählt werden?


Soll das AL-Team in spätestens einem Monat gewählt werden?

G.3 PLENUM des Sysoptreffens Bremen


G.3.1 Plenum: Neuer Standort der Netzzentrale

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.

G.3.2 Plenum: Bedeutung der einzelnen MausTausch Status

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.

G.3.3 Plenum: Bericht der MAUS-Programmierer und Zukunft der Software

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.

G.3.4 Plenum: Bericht der QUARK-Programmierer

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.

G.3.5 Plenum: Umpacken von Sharewarearchiven - Urheberrecht

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.

G.3.6 Plenum: Berichte von den Gateways

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.

G.3.7 Plenum: Sonstiges im Plenum

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.

G.3.8 Plenum: Orte der nächsten SysOp-Treffen

Das SysOp-Treffen 1997 findet in Bamberg statt. Für 1998 hat sich der Frankfurter Raum als Austragungsort des SysOp-Treffens angeboten.

G.3.9 Plenum: ANHANG

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

G.4 Wahl zum schönsten (männlichen) SysOp des MausNet in Bremen

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. ;-)

  1. Marcus Schmidke @ BM

  2. Jörg Stattaus @ W

  3. Timm Ganske @ OF, Harald Krusekamp @ MS

  4. Sebastian Hempel @ WUN

  5. Dirk Reinarz @ MK2, Peter Böhnke @ HB2

  6. Karsten Iwen @ HL, Patrick Jerchel @ B, Martin Schwenk @ BA

  7. Peter Redecker @ BOR, Roland Füßl @ WÜ, Stefan Heidrich @ TBB

  8. Hans-Peter Bock @ TBB, Ulrich Frey @ BB, Markus Ohlhaut @ BA,

  9. Thomas Morgenthaler @ WHV, Uwe Ohse @ DU3

  10. Uwe Seidler @ LB, Andreas Hoffmann @ K2

  11. Steffen Engel @ SZ, Harald Labeit @ HH


H Sysoptreffen Bamberg 26.-28. September 1997


Protokoll SysOp-Treffen 26.-28.09.1997 in Bamberg
Protokoll: Matthias Stürmer und Stefan Heidrich




H.1 Jörg Stattaus: Maus-Programmierung

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.



H.2 AG Import-Präfix / hierarchische Gruppennamen /Netzgruppen löschen

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.



H.3 Abmahnen von Usern

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.



H.4 Maus-Hilfe-Fond

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.
CG@B wird als Koordinator eingesetzt.


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.



H.5 Ziele des MausNet

Wie bekommen wir neue User und können alte halten?


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



H.6 Pflege von EXPs

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:

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.



H.7 Spam / Netzweites Löschen von ÖMs

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.



H.8 AL-Team, Abstimmungen, Vereinfachung Gruppeneinrichtung, SysOp-Abstimmungen, div.


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.



H.9 Schlusswort:

Ä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:

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:

BTW: Nächstes Jahr schreibt jemand anderes!!!

In diesem Sinn :)
Stefan



H.10 Teilnehmerliste am SysOp-Treffen

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

Björn Schmidgall

Thomas Niering

Udo Fleckenstein

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


UDO6

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

Made with UDO

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

Home