PC Online 1998 January

home *** CD-ROM | disk | FTP | other *** search

/ PC Online 1998 January / PCO0198.ISO / filesbbs / dos / uniswb07.arj / UNISWB07.ZIP / UNISCHED.DOK < prev next >

Wrap

Text File | 1997-10-14 | 75.2 KB | 1,675 lines

U N I S C H E D - The Universal Scheduler --------------------------------------------- Version 1.0 Wide Beta 07 (C) 1996,97 by Tobias Ernst --> DIES IST UNGETESTETE BETA-SOFTWARE. <-- --> DIE BENUTZUNG ERFOLGT AUF EIGENE GEFAHR <-- --> ICH BITTE DARUM, MIR GEFUNDENE BUGS ZU MELDEN! <-- (An English Documentation will be supplied with the 1.0 release of UniSched) INHALT ------ 1. Was ist UniSched? 2. Wozu brauche ich Unisched? 3. UniSched Schritt für Schritt: 3.1 Vor der Installation 3.1.1 Die TZ-Umgebungsvariable 3.1.2 Richtig entpacken 3.2 Beschreibung der Konfigurationsdatei 3.3 Events und Actions 3.3.1 Events 3.3.2 Rekursionen 3.3.3 Aktionen 3.4 Aufruf und Bedienung 4. UniSched für Fortgeschrittene 4.1 Online-Tossing 4.2 Logausgaben fallweise unterdrücken 5. Shareware 6. Verschiedenes 1. WAS IST UNISCHED? -------------------- UniSched ist ein Scheduler, der speziell auf die Bedürfnisse eines Nodesystems im Fidonet zugeschnitten ist. Kurz gesagt: UniSched reagiert auf Ereignisse mit Aktionen. Als Ereignisse kommen in Betracht: - Termingesteuerte Ereignisse (z.B. täglich um 15:00, am 1. des Monats ab 10:00, alle 30 Minuten, ...) - Auftreten von Semaphore-Dateien (von anderen Programmen erstellt) - Maileingang im Mailer-Inbound - Drücken von Funktionstasten Als Aktionen sind möglich: - Ausführen externe Programme, Batches, Skripte - Sich mit Errorlevel beenden - Manipulationen im Binkley-Outbound (Poll generieren, Flavours ändern, ...) - Diverse (z.B. WAV-Files abspielen, Semaphoren erzeugen, Dateien löschen, ..) UniSched ist an sich ein sehr simples Programm, dabei aber gerade in seiner Einfachheit sehr mächtig. Deshalb lege ich es jedem nahe, diese Doku sorgfältig zu lesen (zumindest aber Abschnitt 3.2), denn nur, wenn man das Prinzip von UniSched verstanden hat, kann man seine Genialität erkennen. :-) UniSched existiert als DOS-Executable (getestet unter DOS, DESQview, Win95, Windows NT, OS/2 MDOS) und natürlich als OS/2-Version (UNISCHE2.EXE). Bei Verwendung der DOS-Version ***MUSS*** Share.Exe oder ein vergleichbarer Support für File-Locking geladen sein! 2. WOZU BRAUCHE ICH UNISCHED? ----------------------------- Die Einsatzgebiete von UniSched sind sicher vielfältig. Ich habe es aber geschrieben als Frontend für den Tossertask, eines Fido-Nodes und hier liegen seine Stärken. Statt in den Mailer-Batches rumzufummeln, läuft mit UniSched ein separater Tossertask (sei das nun ein Task unter einem Multitasker, oder ein extra Rechner in einem Netzwerk). UniSched ist die ganze Zeit aktiv. Zu bestimmten Uhrzeiten startet es den Tosser, um Mail zu exportieren. Wenn im Mailer Mail empfangen wurde, legt der Mailer eine Sempahore-Datei an, die UniSched findet und daraufhin den Tosser anweist, die Mail zu importieren. Wenn man von Hand Mail exportieren will, drückt man einfach in UniSched eine Funktionstaste. Außerdem weist UniSched den Mailer zu gegebener Zeit an, den Uplink anzrufuen. Und morgens um sieben startet UniSched ein Weck-Programm ... und und und ... Der Vorteil dieser Vorgehensweise ist klar ersichtlich: Wenn man den Tosser aus der Mailer-Batch heraus startet, besteht die Gefahr, daß bei einem Multiline-System beide Mailer gleichzeitig tossen. Um das zu umgehen, müßte man aufwendige Semaphore-Konstrukte bauen. Und selbst wenn man diese Hürde umschifft hat, ist da immer noch ein Problem: Nur, weil man z.B. um halb neun Mail exportiern möchte, muß man (wenn man UniSched nicht hat) im Mailer ein Event definieren, was unweigerlich nach sich zieht, daß um halb neun alle Online-User aus der Box geschmissen werden. Und so fort. Mit Unisched dagegen ist getrennt, was getrennt gehört: Der Mailer bedient die Modems, und Unisched kümmert sich um den Rest. Der Mailer hat dann i.d.R. nur noch zwei Events, nämlich ZMH und der Rest, so daß er sich voll und ganz dem Mailen widmen kann. ;-) 3. UNISCHED SCHRITT FUER SCHRITT -------------------------------- 3.1. VOR DER INSTALLATION ------------------------- 3.1.1 Die TZ-Umgebungsvariable ------------------------------ UniSched wertet die TZ-Umgebungsvariable aus. Es ist nicht unbedingt notwendig, diese zu setzen, verhindert aber unschöne Effekte bei der Umstellung Sommer->Winterzeit und umgekehrt. Um an dieser Stelle nicht zu langweilen: Es ist nicht intuitiv (intuitiv würde ich für Deutschland GMT+1 setzen, aber das stimmt überhaupt nicht) und für einen Nicht-Programmierer auch absolut nicht-trivial, wie sich die TZ-Variable zusammensetzt. Daher gebe ich hier einfach die richtigen Werte an: Mitteleuropäische Winterzeit: SET TZ=MEZ-1 Mitteleuropäische Sommerzeit: SET TZ=MEZ-2MSZ Viele anderen Programe werten diese Variable ebenfalls aus (insbesondere der Tosser beim Erstellen der VIA-Zeilen), es ist also auf jeden Fall ratsam, diese Werte so in die Autoexec.Bat (bei OS/2 zusätzlich auch in die Config.Sys, aber auch in die Auotexec.Bat im Boot-Drive, wenn das ganze auch für DOS-Sessions gelten soll!) zu übernehmen und erstmal neu zu booten. Wenn man dann die Zeitumstellung (Uhr vor- oder zurückstellen) vornimmt, sollte man erst Unisched runterfahren, dann die TZ-Variable ändern, und dann Unisched wieder hochfahren. Anderenfalls werden periodische Events mehrfach ausgeführt. (Damit kann man natürlich auch leben, z.B., wenn man eine Funkuhr hat ...). 3.1.2 Richtig entpacken ----------------------- Das originale Distributionsarchiv von Unisched ist mit ZIP gepackt OS/2-User entpacken die Datei bitte unbedingt mit der OS/2-Version von INFOZIP oder PKZIP. UNISCHE2.EXE enthält nämlich erweiterte Attribute (das Icon), die der DOS-PKUNZIP nicht korrekt umsetzen kann. (Wens interessiert, mit RAR habe ich abgeschlossen. Ich hatte an einer Sammelregistration der DS teilgenommen und auf dem Formular angegeben, daß ich DOS- und OS/2-Versionen benötige. Statt daß man mich nun davon in Kenntnis setze, daß ich für den Sammelregistrierungspreis nur eine Lizenz für ein BS erhalten kann und zu fragen, welches ich denn gern hätte, habe ich schlicht nur die DOS-Version erhalten. Man war auch nicht bereit, diesen Key gegen einen OS/2-Key umzutauschen. Und nochmal Geld ausgeben tue ich bei so einem "Service" sicher nicht.) Wenn Ihr eine umgepackte Version ohne erweiterte Attribute erhalten habt, müßt Ihr entweder ohne das Icon leben, oder das korrekte Archiv bei mir requesten, oder (für Fortgeschrittene), das Icon per Ressourcenkompiler selbst wieder an die EXE-Datei linken (es ist auch separat als UNISCHED.ICO beigefügt). Am Besten aber macht Ihr Euren Uplinks Dampf. Umpackerei ist IMO eines der größten Übel in der Filenetz-Welt. 3.2. BESCHREIBUNG DER KONFIGURATIONSDATEI ----------------------------------------- Vorab: In der Regel (...) ist Unisched bei der Auswertung der Konfigurationsdatei nicht casesensitiv (d.h., Groß- oder Kleinschreibung ist egal), auch bei Aktionsnamen nicht, aber es ist trotzdem eine gute Idee, sich eine konsistente Schreibweise anzugewöhnen. Bevor wir uns nun dem eigentlichen Prinzip von EREIGNIS und AKTION zuwenden, muß UNISCHED erst mal vorkonfiguriert werden (Pfade und der ganze Kram). Deshalb folgt im Anschluß eine Beschreibung aller gültigen Schlüsselwörter in der Datei UNISCHED.CFG. Falls Du zu den Personen gehörst, die die magische Gabe haben, aus kryptischen Schlüsselwörtern instantan deren Bedeutung zu erschließen, kannst Du diesen Abschnitt 3.2 überspringen. Lies aber ab 3.3 auf jedenfall wieder mit, da wirds wichtig. Genaugenommen besteht die UNISCHED.CFG aus zwei Teilen. Zunächst die allgemeinen Einstellungen, die im Anschluß beschrieben werden, und dann die Event-Action-Config, die in Kapitel 3.2 beschrieben wird. Die Reihenfolge der zugehörigen Kommandos in der Config-Datei ist übrigens beliebig (Ausnahme: SemaDir). In der Konfigurationsdatei können %UMGEBUNGSVARIABLEN% verwendet werden. Einzelne %-Zeichen lassen sich im Zweifelsfalle durch ein dooepltes %-Zeichen (also %%) erzwingen. Alivetime = <minutes> --------------------- UniSched legt beim Start eine Datei "UNISCHED.BSY" an (Busy-Semaphore), die er erst bei Beendigung wieder löscht. Dieser Parameter gibt an, alle wieviel Minuten der Timestamp diese Semaphore auf die neuste Uhrzeit gesetzt werden soll. Wird diese Zeile gar nicht in der Config angegeben, wird die Busy-Semaphore nur bei Programmneustart auf neuere Uhrzeiten gesetzt. Autofail = On | Off ------------------- Dies ist wichtig für die DOS-Version. Es wird ein Errorhandler installiert, der die Frage "Retry, Abort, Fail?" immer mit "Fail" beantwortet. In der DOS-Version sollte das immer gesetzt sein, denn es kann u.U. bei den Semaphoren sonst zu Probleme kommen (Mailer erstellt Sempahore, und Unisched will sie schon löschen, bevor der Mailer sie überhaupt freigegeben hat -> Sharing Violation -> Die besagte Meldung -> Tossertask steht bis man "F" drückt - es sei denn, man hatte Autofail=On gesetzt). Unter OS/2 ist dieser Schalter ohne Bedeutung. Hier gibt es sowas nämlich schon für die Config.Sys (dort: Autofail=Yes). Bsp: Autofail = On Clock = On | Off ---------------- Gibt an, ob in der Titelzeile eine Uhr eingeblendet werden soll. Default ist On, aber Off spart ein kleines bißchen Rechenzeit ... Bsp.: Clock = On DiskLog = <Loglevels> --------------------- Gibt an, welche Arten von Meldungen alle ins Log-File geschrieben werden sollen. Es existieren folgende Loglevel: ! Statusmeldungen ("starting", "shutting down", nicht abschaltbar) ? Fehlermeldungen und Warnungen (nicht abschaltbar) * Semaphore-Events \ . Funktionstasten-Events \ Das sind alles Auslöser für Aktionen ~ Periodische Events / von Unisched # Statische Events / + Aktionen (das, was von Events ausgelöst wird) - Ausgewählte Wide-Beta Debug-Meldungen p Meldungen des Parsers bei der Abarbeitung von Aktionsdefinitionen _ Eine Leerzeile nach einem Event-Aktion-Block (erhöht die Übersichtlichkeit, wenn man sehr viel Loggen läßt - ich empfehle, _ immer dann zu verwenden, wenn man auch p verwendet). Wenn man die Chance, daß ich auf Bugreports reagiere, drastisch erhöhen will, sollte man das mir übersandte Logfile MINDESTENS mit folgendem DiskLogLevel erstellen: DiskLog = !?*.~#+- Während der Wide-Beta Phase sollte man generell nicht weniger nehmen. ExcessiveSlicing = <zahlenwert> | Yes | No ------------------------------------------ Dieser Schalter betrifft die Abgabe von Zeitscheiben in Multitaskingumgebungen. Wird er auf einen Zahlenwert ungleich Null gesetzt (Yes entspricht 5, No entspricht 0), werden deutlich mehr Zeitschreiben freigegeben. Du mußt selbst ausprobieren, ob Du diesen Schalter brauchst. Generell gilt: Wenn Dir die Systemlast von Unisched zu hoch erscheint, solltest Du ihn soweit hochsetzen, daß die Uhr rechts oben gerade noch jede Sekunde einzeln auflöst (etwas ruckelig darfs sein, aber es sollten keine Sekunden übersprungen werden). Hier ein paar Erfahrungswerte, mit denen Unisched akzeptabel arbeitet: OS/2 nativ: 0 OS/2 DOS-Box: 1 oder 0 Windows NT: 20 Windows 95: Mit 0 läuft es akzeptabel, weitere Tests liegen nicht vor. IgnoreOldBusySem = <minutes> ---------------------------- Wenn UniSched beim Starten die Datei UNISCHED.BSY vorfindet, geht er davon aus, daß bereits ein anderer Unisched-Task gestartet ist, und startet selbst nicht. Wird "IgnoreOldBusySem" verwendet, so prüft Unisched aber zuvor, wie alte die Busy-Semaphore ist, und startet ggf. trotzdem, falls sie nämlich älter ist als die angegebene Anzahl von Minuten. (In dem Fall geht er davon aus, daß die Busy-Semaphore von einem Systemabsturz o.ä. übrig geblieben ist). Wenn man IgnoreOldBusySem verwendet, muß man natürlich auch AliveTime (s.o.) verwenden, sonst könnte die Busy-Semaphore ein sehr altes Timestamp tragen, obwohl der zugehörige Task noch arbeitet. Die Anforderungen an die Zahlenwerte für AliveTime und IgnoreOldBusySem hängen von der Konfiguration von UniSched ab. Wenn man (z.B. unter OS/2 mit EXEC START /C /MIN BLAHBLUBB.CMD) alle externen Programme, die Unisched startet, in einem separaten Hintergrundtask startet, kann man davon ausgehen, daß UniSched nie lange daran gehindert wird, den Timestamp der Busy-Semaphore zu aktualisieren, und man kann kleine Zahlenwerte nehmen: AliveTime = 1 IgnoreOldBusySem = 5 In dem Fall ist eine übriggebliebene Busy-Semaphore nach einem Systemneustart vermutlich schon überaltert, und UniSched startet schon wieder. Wenn man jedoch, z.B. um Zugriffskonflikte auf der Messagebase auszuschließen, externe Aufgaben wie Tossen im UniSched-Fenster selbst ausführen läßt (EXEC BLAHBLUBB.CMD), muß man damit rechnen, daß UniSched für längere Zeitspannen die Busy-Semaphore nicht updaten kann, und IgnoreOldBusySem auf einen entsprechend hohen Wert setzen. Ein Aufräumevent kann schon mal zwei Stunden dauern: AliveTime = 10 IgnoreOldBusySem = 180 Egal wie man es löst - in jedem Fall sollte man auch unter OS/2, um Tosserausfälle während Abwesenheit zu verhindern, UniSched aus einer Batch heraus starten, die, falls UniSched wegen BusySemaphore nicht startet (er liefert in dem Fall Errorlevel 255), den UniSched wieder erneut startet, solange, bis die BusySemaphore veraltet ist: :start unische2 /cunisched.cfg if errorlevel 255 goto start UniSched gibt genug Zeitschreiben frei, damit diese Konstellation im Zweifelsfalle zumindest unter OS/2 NICHT zu 100% Systemlast führt). Include = <path+filename> ------------------------- Einbinden zusätzlicher Konfigurationsdateien. Fügt die angegebene Datei an genau dieser Stelle in die Konfiguration ein. Bsp: Include = e:\configs\colors.cfg KeyColumns = <Spaltenzahl> -------------------------- Gibt an, in wieviel Spalten die Funktionstastenbeschreibungen angeordnet werden sollen. Default ist 4, wenn man aber kleinere Fenstergrößen oder längere Eventnamen wählt, können 3 Spalten besser lesbar sein. Bsp: KeyColumns = 3 Logfile = <path+filename> ------------------------- Hier gibst Du das UniSched-Logfile an. Dieses Schlüsselwort sollte als allererste Zeile in der Unisched.Cfg stehen, da nur so Konfigurationsfehler im weiteren Verlauf der Datei, die zum Programmabbruch führen, auch im Logfile festgehalten werden können. Bsp.: Logfile = e:\box\log\unisched.log Wenn Du mehrere Kopien von UniSched gleichzeitig laufen läßt (warum sollte man das tun?), muß jede ein anderes Logfile haben. MTask = <multitasker> --------------------- Diese Option existiert nur in der DOS-Version. Man kann hier angeben, für welchen Multitasker Unisched Timeslices freigeben soll. Normalerweise erkennt Unisched den Multitasker automatisch, aber manche Multitasker lassen sich nicht erkennen (z.B. Topview), und manchmal klappt die Erkennung nicht richtig (z.B. Windows NT). Für <multitasker> können folgende Strings eingesetzt werden: DESQview Quarterdeck DESQview PC-MOS PC-MOS (von wem war das doch gleich?) Windows Windows 3.1, 95 und NT DoubleDOS DoubleDOS OS/2 Warum nicht gleich UNISCHE2.EXE nehmen? ;-) TopView TopView Multilink Multilink BIOS Timeslicing über BIOS Generic Timeslicing über Multiplexerinterrupt None Timeslicing ganz ausschalten Beachte auch die zugehörige Einstellung von "ExcessiveSlicing" (siehe oben). Outbound = <path> ----------------- Gibt den Basispfad des statischen (Binkley-) Outbounds an. Diese Angabe wird für das Erzeugen von Polls beim Uplink benötigt und ist obligatorisch. Auch wenn Du keinen Binkley-Outbound hast und/oder die Poll-Funktion gar nicht nutzen willst, mußt Du hier was angeben. Nimm dann halt irgend ein leeres Verzeichnis. Bsp.: Outbound = e:\box\binkley\outbound Die Outbound-Verzeichnisse anderer Zonen (outbound.0f2 usw.) errechnet UniSched selbst. Wenn Du allerdings ein vollständiges Domain-Setup hast, wo die Outbound-Pfad anders heißen (z.B. Zone 456, Domain mediaserve.de führt zu mediaser.1c8 statt outbound.1c8), mußt Du diese Verzeichnisse in der Config wie folgt angeben: <Zonennummer> = <Outboundbasisname> ----------------------------------- Das Domain-Setup. Braucht man, wenn der Outbound für Zone 456 nicht Outbound.1c8, sondern Mediaser.1c8 heißt. (Domainesetup bei Binkley; bei McMail verändert sich der Outboundname auch bei eingetragenen Domains nicht). Wichtig: Bei Outboundbasisname den tatsächlichen Pfadnamen angeben, *nicht* den eigentlichen Domainnamen. Die Zonennummer muß aber dezimal angegeben werden. Beispiel: Zonennummer: Domainname: Outboundverzeichnisname: 1 fidonet e:\inout\outbound.001 2 fidonet e:\inout\outbound ... 6 fidonet e:\inout\outbound.006 9 virnet e:\inout\virnet.009 242 fido.de e:\inout\fidode.0f2 Eine solche Outboundkonfiguration wird in Unisched eingetragen als: Zone = 2 Outbound=e:\inout\outbound 9 = Virnet 242 = FIDODE Man beachte: fidode, NICHT fido.de, aber 242, NICHT 0f2. Pipe = <pipename> ----------------- Schreibt Unisched-Logmeldungen in eine Named Pipe, aus der sie mit Snooper-Programmen wie PMPIPER, PIPEMAN, RXSNOOP u.a. ausgelesen werden können. Nützlich, wenn man einen auf dem Server laufenden Unisched von einem anderen Rechner aus überwachen will. Beispiel: Pipe = \\pipe\unisched Unisched unterstützt bei Pipes übrigens auch Reconnects, im Gegensatz zu Binkley und anderen, die in dem Fall immer neu gestartet werden müssen. Eine Pipe sollte nur konfiguriert werden, wenn sie auch tatsächlich benutzt wird, da dies sonst den Start von Unisched unnötig verzögert. PipeLog = <Loglevels> ----------------------- Gibt an, welche Arten von Meldungen in die Named Pipe geschrieben werden sollen. Syntax und verfügbare Loglevels ist genau gleich wie bei "DiskLog". ResetDialCounters = Yes | No ---------------------------- Vor einem Poll grundsätzlich alle Nodial-Marks, Dial-Counters, Overtry-Marks etc. des betreffenden Nodes löschen. Kann man alternativ aber statt hier global auch nur für einzelne Polls über RDC bei der Aktion POLL definieren (siehe dort). RescanSema = <path+filename> ---------------------------- Name der Semaphore-Datei, die Deinen Mailer dazu bewegt, einen Rescan zu machen. UniSched muß einen solchen z.B. beim Erzeugen eines Polls auslösen. Bsp: RescanSema = e:\box\sema\btrescan.flg RescanSema = e:\box\sema\mcmscan.all UniSched kann auch nur auf der Line, die konkret pollen soll, einen Rescan auslösen. Die Linenummer wird dann erst von UniSched in den Dateinamen eingefügt. Die Stelle, an der die Nummer eingefügt wird, wird wie in C üblich eingetragen: %d für dezimal %03d für dezimal, aber immer drei Stellen, ggf. mit 0en auffüllen %x für hexadezimal %02x für hex, aber immer zwei Stellen, ggf. mit Nullen auffüllen etc. Bsp.: RescanSema = e:\box\sema\mcmscan.%d Dies führt dann zu mcmscan.1, mcmscan.2 usw., je nachdem, welche Line gewünscht ist. Es können bis zu zehn verschiedene "RescanSema"-Zeilen angegeben werden. Dies ist dann interessant, wenn man im Wechsel verschiedene Mailer (Binkley, McMail, ...) benutzt und immer für alle gleichzeitig die richtigen Semaphoren erstellen möchte. Registername = <Name> Registerkey = <Key> --------------------- Überweis' mir zehn Mark, und ich sage Dir, was Du hier eintragen mußt. :-))) ScreenLog = <Loglevels> ----------------------- Gibt an, welche Arten von Meldungen im Log-Fenster auf dem Bildschirm erscheinen sollen. Syntax und verfügbare Loglevels ist genau gleich wie bei "DiskLog". SemaDir = <Pfadname> -------------------- Hier kannst Du Dein Semaphorenverzeichnis eintragen (das Verzeichnis, in dem die Signaldateien mit Nullänge liegen, über die verschiedene Programme untereinander kommunizieren). Semaphoren können hinterher auch woanders sein, dies ist nur das Default-Verzeichnis, das verwendet wird, wenn Du in der Event-Action-Config keinen expliziten Pfad für eine bestimmte Sempahore angibst. SemaDir wirkt sich nur auf diejenigen Semaphoren-Definitionen aus, die in der Konfigurationsdatei UNTERHALB des SemaDir-Statements stehen. Deshalb schreibt man SemaDir am Besten GANZ AN DEN ANFANG der KONFIGURATIONSDATEI. Bsp.: SemaDir = e:\box\sema SmallWindow = On | Off ---------------------- Mit SmallWindow = On benutzt UniSched statt 80x25 nur 66x18 Zeichen. Das macht unter DESQview Sinn, wenn man eine kleinere Fenstergröße einstellt. Unter OS/2 wird dieser Parameter von zukünfitgen Versionen nicht mehr unterstützt werden. Unter OS/2 kann man vor dem Start von UniSched über Kommandozeile mittles MODE beliebige Fenstergrößen einstellen (zum Beispiel MODE CO66,80), die UniSched automatisch erkennt und sich dann entsprechend anpaßt. Bsp.: SmallWindow = Off SpawnInit = $Aktionsname ------------------------ Führt die angegebene Aktion einmalig bei Programmstart aus. Was Du bei $Aktionsname eintragen kannst, erfährst Du in Abschnitt 3.1. Es sind bis zu 16 SpawnInit-Angaben zulässig. Bsp: SpawnInit = $Begrüßungslied Hinweis für OS/2-User: Was NICHT funktioniert, ist sowas wie "SpawnInit = EXEC MODE CO150,80". Wenn man die VIO-Fenstergröße verändern will, muß man dies echt vor dem Aufruf von Unisched machen (in einer CMD), weil UniSched das sonst nicht merkt (liegt an Beschränkungen meines Compilers, nicht an mir ...). Zone = <nr> ----------- Hier gibst Du Deine "Heimatzonennummer" an (Europa: 2, USA: 1). Diese Angabe ist obligatorisch, da sie für die korrekte Ermittlung der Namen der Outbound-Verzeichnisse notwendig ist. Wenn Du keinen Binkley-Outbound hast und/oder die Pollfunktion nicht nutzen willst, gibst Du einfach irgendwas an. Bsp.: Zone = 2 ColBorder = <nr> ColKeys = <nr> ColKeyDescriptions = <nr> ColHeadLine = <nr> ColEvent = <nr> ColLog = <nr> ------------------------- Farbnummern, falls die Defaults nicht gefallen, und zwar wird die Nummer berechnet über Vordergrundfarbe+16*Hintergrundfarbe aus folgender Tabelle: │ │Hinter-│Vorder- │ │Hinter-│Vorder- Farbe │ Wert│grund? │grund? Farbe │ Wert│grund? │grund? ═════════════╪═════╪═══════╪═══════ ══════════════╪═════╪═══════╪═══════ BLACK │ 0 │ Ja │ Ja DARKGRAY │ 8 │ Nein │ Ja BLUE │ 1 │ Ja │ Ja LIGHTBLUE │ 9 │ Nein │ Ja GREEN │ 2 │ Ja │ Ja LIGHTGREEN │ 10 │ Nein │ Ja CYAN │ 3 │ Ja │ Ja LIGHTCYAN │ 11 │ Nein │ Ja RED │ 4 │ Ja │ Ja LIGHTRED │ 12 │ Nein │ Ja MAGENTA │ 5 │ Ja │ Ja LIGHTMAGENTA │ 13 │ Nein │ Ja BROWN │ 6 │ Ja │ Ja YELLOW │ 14 │ Nein │ Ja LIGHTGRAY │ 7 │ Ja │ Ja WHITE │ 15 │ Nein │ Ja Beispiel: Roter Vordergrund, grüner Hintergrund = 4+16*2 = 36, also z.B. ColKeys = 36 3.3. Events und Actions ----------------------- 3.3.1 ACTIONS ------------- Wie bereits erwähnt: UniSched reagiert auf Ereignisse (EVENT) mit Aktionen (ACTION). Bevor wir Events festlegen, müssen wir erst die Aktionen definieren (*was* soll UniSched tun?). Eine Definition einer Aktion beginnt immer mit einem $-Zeichen, gefolgt von dem Name der Aktion (NUR Buchstaben und der Unterstrich!!!). Dann ein Gleichheitszeiten, und dahinter die eigentliche Aktion. Bsp.: $HUB_ANRUFEN = POLL 2:2476/404 crash 2 Im Folgenden wird nun die Syntax aller Aktionen erklärt, die hinter dem Gleichheitszeichen verwendet werden können: BEEP [<Frequenz> [<Dauer>]] --------------------------- Gibt einen Piepton aus. Frequenz und Dauer können angegeben werden in Hertz bzw. Millisekunden; werden sie weggelassen, werden 1000 Hz und 100 ms angenomen (kurzer Piepser). Anwendungsgebiete: Weck-Piepser, Stündliches Piepsen wie bei Armbanduhr, ... Bsp.: $LANG_UND_LAUT = BEEP 800 4000 $PIEPSIG = BEEP 1000 80 Wer mehr machen will als nur einen Piepston ausgeben, der sollte sich die Aktion "PLAY" in Verbindung mit MUS-Dateien ansehen. EXEC <command> -------------- UniSched führt das externe Programm <command> aus und wartet dessen Beendigung ab. <command> wird dabei an den Kommando-Interpreter (COMMAND.COM, CMD.EXE) übergeben, so daß neben EXE- und COM-Programmen auch BAT- und CMD-Dateien ausgeführt werden können ebenso wie Befehle des Kommando-Interpreteres (z.B. COPY). Also nochmal: > Alles, was hinter EXEC kommt, wird genauso ausgeführt, als würde man > von UniSched aus eine DOS/OS/2Shell gehen und dort genau diesen String > eingeben. Bsp.: $MAIL_Exportieren = EXEC e:\box\batch\export.bat Ein Tip für OS/2-User: Wenn der Tosser in einem separaten Task gestartet werden soll, so daß UniShed nicht das Tossen abwarten muß, sondern sofort wieder aktiv wird, kann das START-Kommando von OS/2 verwendet werden: Bsp.: $MAIL_Importieren = EXEC START /C /MIN e:\box\batch\import.cmd Der Paramter /C bewirkt, daß das Fenster der IMPORT.CMD nach deren Beendigung wieder geschlossen wird. Man muß sich bei dem Tossen via START allerdings bewußt sein, daß es passieren könnte, daß UniSched kurz hintereinander zweimal die IMPORT.CMD startet, so daß wieder gleichzeitig von zwei Tasks getosst wird, was unweigerlich zu Datenmüll führt. Eine entsprechende Vorkehrung muß deshalb in der IMPORT.CMD getroffen werden. EXIT <errorlevel> ----------------- Unisched beendet sich mit <errorlevel>. Dies ist nützlich, wenn UniSched selbst aus einer Batch heraus aufgerufen wird. Der Errorlevel kann dann von der Batch ausgewertet werden, um das passende Programm zu starten. Gegenüber dem direkten Starten eines Programmes mit EXEC hat diese Methode den Vorteil, daß UniSched während der Ausführung des Programmes sich nicht mehr im Speicher befindet, so daß ca. 60KB mehr zu Verfügung zu stehen. Bsp: $TOSSER_UEBER_BATCH_STARTEN = EXIT 80 IGNORE ------ Tut schlicht und ergreifend nichts. PLAY <filename.MUS> ------------------- Spielt die angegebene MUS-Datei ab. MUS-Dateien enthalten Klartext-Kommandos, die in der Syntax ganz ähnlich sind wie BEEP: TONE <frequenz> <hundertstelsekunden> WAIT <hundertstelsekunden> Man kann damit selbst komponieren, wenn man Lust hat. Es handelt sich um das Format, in dem auh die Proboard- und Remote Access - Musikdateien (Pagesongs) gehalten sind. Ein paar Beispiel-MUS-Dateien kann man bei mir (2:2476/418) unter UAPS10.ARJ requesten. In der OS/2-Version werden die Kunstwerke im Hintergrund abgespielt, die Abarbeitung von Events wird also nicht aufgehalten. Das Abspielen kann mit der Aktion ABORTMUSIC abgebrochen werden. Bsp: $Wecker = PLAY f:\box\pb\Wecker.MUS $Jajajaistjagut = ABORTMUSIC In der DOS-Version muß man den Wecker bis zum Ende ertragen ... PLAY <filename.WAV|.MID> ------------------------ Spielt die angegebene WAV- oder MID-Datei ab. Diese Aktion funktioniert nur in der OS/2-Version und erfordert installierten MMPM/2. Das Abspielen erfolgt im Hintergrund. Bsp: $Bigben = PLAY f:\sounds\gong.wav POLL <node> [<flavour>] [COND] [RDC] [LINE<linenr>] --------------------------------------------------- Legt im Binkley-Outbound einen Poll für <nodenumber> an. Die Reihenfolge der Paramter ist wie obenstehend angegeben einzuhalten. <node>: Nodenummer in 3D oder 4D <flavour>: Folgende Flavours können angegeben werden: "crash", "immediate", "direct", "normal", "hold" (Unsinn, oder? ;-), "poll". Man beachte, daß "immediate" nicht bei BinkleyTerm funktioniert, und daß "poll" ausschließlich bei McMail ab Gamma 5 implementiert ist. (Ebenfalls möglich sind die Flavours FL0 bis FL9. Diese generieren FLO-Pakete der Art 0LO bis 9LO. Dies ist in einem Draft für einen erweiterten Binkley-Outbound vom BT-XE-Team spezifiert, aber noch nicht konkret in die Praxis umgesetzt ... außer in Unisched ;-) COND: Wird diese Zeichenfolge angegeben, so wird der Poll nur ausgeführt, wenn für die angegebene Nodenummer bereits irgendetwas da liegt. RDC: Abkürzung für "Reset Dial Counters". Wenn angegeben, werden vor Anlegen des Polls alle Dial Counter, Busy Marks u.ä. entfernt. Dies sind die Dateien <nodenetz>.$??, .&??, .#?? und .-??. Ich hoffe, damit alle derartigen Flags aller üblichen Mailer erschlagen zu haben ... Wenn man das sowieso bei jedem Poll machen lassen will, kann man, statt bei jedem einzelnen Poll RDC angeben zu müssen, auch global "ResetDialCounters=Yes" in das Config-File aufnehmen. <line>: Gibt die Nummer der Line an, die den Poll ausführen soll. Falls bei "RescanSema" (s.o.) die %-Parameter verwendet wurden, sollte die Linenummer immer angegeben werden, damit UniSched auf der richtigen Line den Rescan auslösen kann (so daß der Mailer von dem Poll überhaupt was mitkriegt). Man beachte, daß zwar der Rescan dann nur für die entsprechende Line angelegt wird, daß man so aber nicht verhindern kann, daß evtl. nicht doch eine andere Line rauswählt. Ausnahme: Bei dem Flavour "Poll", der nur von McMail unterstützt wird, wird ein spezieller Line-Poll angelegt, der bewirkt, daß definitv keine andere Line rauswählt. Es ist mehr als ein LINEx-Statement zulässig, jedoch werden zusätzliche LINEx-Statements nur zum Erstellen zusätzlicher Rescan-Semaphoren verwednet. Ein McMail-Taskpoll wird immer nur für die erste angegebene Line erstellt. Die maximale Line-Nummer beträgt 32, alles darüber gibt einen Syntax-Error. (Wer mehr als 32 Lines fährt, ist vermutlich neureich und kann mir gern eine größere Spende zukommen lassen, in dem Fall erweitere ich die Anzahl der möglichen Lines gerne <g>). Beispiele: $POLL_Hub = Poll 2:2476/998 crash rdc line2 line 3 Pollt im Flavour "crash" bei 2:2476/998, rescannen sollen die Lines 2 und 3. Vorher Busy-Marks und Dialcounters löschen. $Requeste_bei_Niels = Poll 2:2476/999 immediate cond line1 Falls was für 2:2476/999 da liegt (z.B. Requests, die tagsüber mit dem Flavour direct erstellt wurden), dort sofort mit Line 1 pollen. REFLAVOUR <node> [<oldflavour>] [<newflavour>] [RDC] [COND] [LINE<line#>] ------------------------------------------------------------------------- Setzt im Binkley-Outbound alle Mails für den angegebenen Node, die mit Flavour "oldflavour" im Outbound liegt, auf den Flavour "newflavour" um. <node>: Nodenummer in 3D oder 4D <oldflavour>: Hier sind alle Flavours zulässig, die auch bei POLL (siehe <newflavour>: dort) zulässig sind. [RDC] [LINE#]: Haben beide die gleiche Bedeutung wie bei POLL (denn auch REFLAVOUR läßt natürlich den Mailer hinterher rescannen). [COND]: Das "Reflavouring" wird nur durchgeführt, falls bereits Mail mit dem angegebenen neuen Flavour existiert. Man beachte dabei, daß UniSched ungepackte Mail (?UT-Pakete) nur dann "reflavouren" kann, wenn NOCH KEINE Mail mit dem angegebenen Zielflavour vorhanden ist. (Falls doch, wird eine Warnung ausgegeben, und die ungepackte Mail nicht geändert - man muß also nicht Angst haben, daß etwas überschrieben wird). Bei Arcmail/Files (?LO-Pakete) ist das dagegen kein Problem - Hier wird z.B. Hold-Mail auch dann auf Crash geändert, wenn bereits CLO-Pakete existieren. Das ganze hat zwei wichtige Anwendungsgebiete. Erstens kann man damit Polls wieder löschen. Bsp: Du pollst um 2 Uhr Deinen GFD-Uplink an. Falls Du jedoch bis 4 Uhr noch nicht durchgekommen bist, möchtest Du an dem Tag nich mehr pollen (Telefongebühren ...): $POLL_GFDnet = POLL 2:2476/999 crash $UNPOLL_GFDnet = REFLAVOUR 2:2476/999 crash normal #001 02:00 03:59 = $POLL_GFDnet #002 04:00 10:00 = $UNPOLL_GFDnet (Ich weiß, es ist blöd, daß dieses Beispiel bereits Zeit-Event-Definitionen enthält, obwohl die erst unten behandelt werden ... Ein weiterer möglicher Anwendungsfall ist das, was ehemaligen Frontdoor-Sysops als "UNHOLD" bekannt ist. Wenn jemand z.B. sein System so konfiguriert, daß es während des Billigtarifs auch für Direct-Mail rauswählt (z.B. eine gute Möglichkeit, File-Requests in die Nacht zu verlegen), muß er, da der Mailer nicht zwischen Normal und Direct unterscheidet, die Echomail auch für seinen Uplink HOLD packen, weil der sonst auch in der fraglichen Zeit immer angerufen würde, sobald für ihn etwas auf Hold liegt. - Damit die Mail für den Uplink nun trotzdem rausgeht, wenn man "absichtlich" bei ihm anruft, muß man vor dem Anruf diese wieder auf "Normal" setzen: $POLL_OLAF = POLL 2:246/9999 crash $UNHOLD_OLAF = REFLAVOUR 2:246/9999 hold normal $Olaf_Anrufen = $UNHOLD_OLAF $POLL_OLAF REMOVE <filename> ----------------- Löscht die Datei <filename>. Sinn dieses Befehls und Beispiele siehe unter SEMAPHORE. Wildcards sind (seit der Wide Beta 07) erlaubt. Wird kein Verzeichnispfad angegeben, wird das zuvor definierte Semaphoren-Verzeichnis verwendet. REQUEST <filename> [!<password>] <nodenumber> [<flavour>] [LINE<line#>] ----------------------------------------------------------------------- Requestet beim angegebenen Node die angegebene Datei. Außer dem Filerequest selbst wird auch ein Poll angelegt, damit der Filerequest auch verschickt wird, daher sind die restlichen Parameter auch identisch mit denen der Aktion POLL. Beispiel1: $Request_Private_Filelist = REQUEST PVTFILES !GEHEIM 9:99/999 crash 2 $Request_BLAND_Files = REQUEST FILES 2:2476/418 crash 1 SEND <filename> <nodenumber> [<flavour>] [kfs | tfs] [LINE<line#>] ------------------------------------------------------------------ Verschickt eine Datei an den angegebenen Node. Die Parameter sind identisch wie bei REQUEST. Zusätzlich gibt es noch: kfs: Steht für "kill file when sent": Die Datei wird nach dem Versenden gelöscht. tfs: Steht für "truncate file when sent": Die Datei wird nach dem Versand auf Nullänge gesetzt. Beispiel: $Send_Hubdiff = SEND 24760900.UPD 2:2476/1 crash line2 RESTART ------- Initialisiert Unisched neu. Dabei wird auch das Config-File neu eingelesen. SEMAPHORE <filename> REMOVE <filename> -------------------- Die Aktion SEMAPHORE legt die Semaphorendatei <filename> an. Eine Semaphore-Datei ist eine Datei mit Nulllänge, über die man anderen Programmen bestimmte Dinge signalisieren kann. Über bestimmte Semaphoren kann man z.B. das Verhalten des Mailers beeinflussen. Entsprechend löscht die Aktion REMOVE die angegebene Datei (Vorsicht: Dies geht nicht nur bei Semaphoren, sondern auch bei Dateien, die nicht Nullänge haben!). REMOVE nimmt ebenso wie SEMAPHORE das Semaphore-Verzeichnis als Standardverzeichnis. So könnte z.B. die Sempahore BTFREEZE.01 angelegt werden, um zu verhindern, daß der Binkley-Task Numero 1 weiterhin abhebt oder sonst irgendwas tut. Wenn Binkley wieder aktiv werden darf, muß die von Binkley nach dem freezing angelegte Datei BTFROZEN.01 gelöscht werden. (Hinweis: Manchmal kann es einfacher sein, Semaphoren von der die eigentliche Aktion ausführenden Batch aus mit ECHO>SEMAPHORE.SEM bzw. DEL SEMAPHORE.SEM erstellen und löschen zu lassen). Wird kein Pfadname angegeben, wird die Datei im zuvor in der Config definierten Sempahoren-Verzeichnis angelegt. $Freeze_BT1 = SEMAPHORE BTFREEZE.01 $Unfreeze_BT1 = REMOVE e:\mailer\bt\flags\BTFROZEN.02 3.3.2 Rekursionen ----------------- Bei der Definition von ACTIONS sind übrigens auch Rekursionen zulässig. Beispiel: $Tobias_Pollflag = POLL 2:2476/418 crash $Tobias_Unhold = REFLAVOUR 2:2476/418 hold normal $Tobias_Anrufen = $Tobias_Unhold $Tobias_Pollflag Die Reihenfolge der Defintion im Config-File ist beliebig, die letzte Zeile im obigen Beispiel hätte also durchaus auch als erste dastehen können. 3.3.3 EVENTS ------------ So, jetzt haben wir bereits Aktionen definiert, die UniSched u.U. ausführen soll, und ihnen Namen gegeben. Jetzt müssen wir nur noch festlegen, *WANN* UniSched diese Aktionen ausführen soll: Es gibt vier mögliche Bedingungen (Ereignisse, EVENTS): Semaphore-Dateien, statische Zeit-Events, periodische Events und Funktionstasten. Funktionstasten --------------- Syntax: Key<key> = $<action name> [$<action2 name> .. $<actionn name>] Dies ist die einfachste Sorte von Event. Sie dient dazu, daß man alle von UniSched verwalteten Funktionen auch von Hand über eine Funktionstaste starten kann. Derzeit definiert sind folgende Tasten: KeyF1 .. KeyF10 KeySF1 .. KeySF10 (SF steht für Shift+Fkt.) KeyAltA .. KeyAltZ (Ausnahme: Alt+X, damit wird nämlich UniSched beendet) KeyAlt0 .. KeyAlt9 KeyS0 .. KeyS9 (Shift + 0 .. Shift + 9) Key0 .. Key9 KeyESC Bsp.: KeyF3 = $Mail_Exportieren KeyAltI = $Mail_Importieren $WAV_Abspielen Semaphore-Dateien ----------------- Es gibt seit wb06 zwei verschiedene Semaphore-Typen: Flagfiles (die konventionellen Semapohoren) und Triggerfiles. Flagfiles ("normale Semaphoren") -------------------------------- Syntax: *<path+filename> = $<action name> [$<action2 name> ... ] Wenn UniSched die Datei <path+filename> vorfindet, löscht es sie und führt anschließend die angegebene Aktion aus. Wenn der Pfadname nicht mit angegeben wird, wird die Datei in dem durch SemaDir (s.o.) bezeichneten Verzeichnis gesucht. Bsp.: *e:\box\sema\MAILIN.SEM = $MAIL_Importieren Hauptzweck der Semaphore-Funktion ist es wohl, den Tosser zu starten, wenn Mail eingegangen ist. Dazu muß man den Mailer dazu überreden, bei Maileingang die besagte Semaphore-Datei anzulegen. Schau' dazu in die Doku Deines Mailers. Bei McMail und Binkley XE (nur XE!) heißt das zugehörige Schlüsselwort "MailFlag", wobei man dann noch im Event-File den Errorlevel für Mail-Exits auf 0 setzen muß (McM) bzw. den Eintrag für den Mail-Exit-Level ganz löschen muß (BTXE). Bei Binkley XE heißt die Datei immer BTMAIL.IN, bei McMail kann man den Namen frei definieren). Bei anderen Mailern muß man es, findet man keine entsprechende Funktion, notfalls über die Mailerbatch machen: Jeder Mailer kann sich nach Maileingang mit einem bestimmten Errorlevel beenden, und in der Batch kann man dann mit z.B. ECHO > MAILIN.SEM die Semaphore-Datei von Hand anlegen. Triggerfiles ("daskannurunischedundsonstkeiner <g>") ---------------------------------------------------- Syntax: ^<path+filename> = $<action name> [$<action2 name> ... ] Im Gegensatz zu Flagfiles werden Triggerfiles von UniSched NICHT gelöscht, bevor die Aktion ausgeführt wird. Bei Triggerfiles muß die aufgerufene Aktion (normalerweise eine Batch) selbst dafür sorgen, daß die Datei gelöscht/woandershin verschoben wird. Ein typisches Anwendungsbeispiel: Man läßt durch ein zeitgesteuertes Event (s.u.) regelmäßig eine Fileliste requesten und möchte diese, sobald sie eingetroffen ist, automatisch entpacken und in ein anderes Verzeichnis verschieben lassen: ^e:\mailer\inbound\24760999.zip = $Fileliste_von_999_Entpacken Es ist übrigens problemlos möglich, daß die betreffende Aktion ein externes Programm in einer Hintergrundsitzung startet und sich mit dem Löschen der Datei Zeit läßt. UniSched ist nicht braindead - er wird NIEMALS für die SELBE Trigger-Datei zweimal die gleiche Aktion starten. Nachdem er erstmalig für eine Trigger-Datei eine Aktion gestartet hat, reagiert er zunächst nicht mehr auf Dateien diesen Namens im Inbound. Kriterium, damit UniSched auf das Auftreten einer Triggerdatei besagten Namens wieder reagiert, ist, daß die Datei zwischenzeitlich entweder verschwunden gewesen sein muß oder zumindest ihr Dateidatum/Dateilänge geändert hat. Ferner wird UniSched auch nie auf eine Trigger-Datei reagieren, solange diese nicht für Schreibzugriffe zugänglich ist. Somit ist es - so Dein Mailer File-Sharing unterstützt, was heute die meisten tun - problemlos möglich, als Trigger-File direkt eine Datei im Mailer-Inbound anzugeben; UniSched wird auf diese erst reagieren, wenn sie vollständig empfangen wurde. Und schließlich unterstützt das Triggerfiles-Feature auch Wildcards (Jokerzeichen). Dabei werden alle auf das Wildcard passende Triggerfiles als Einheit betrachtet. Will heißen: Wenn UniSched auf eine bestimmte Datei reagiert hat, reagiert es auf beliebige auf das Wildcard passende Dateien solange nichtmehr, bis die Datei, auf die er ursprünglich reagiert hatte, gelöscht/wegverschoben wird oder ihr Dateidatum ändert. Also nochmal deutlich: Aktionen, die auf das Erscheinen von Triggerfiles hin ausgeführt werden, müssen grundsätzlich IMMER das Triggerfile löschen! invertierte Flagfiles ("invertierte normale Semaphoren") -------------------------------------------------------- Syntax: !*<path+filename> = $<action name> [$<action2 name> ... ] Die genaue Umkehrung eines Flagfiles. Die Aktion(en) wird/werden ausgelöst, wenn die Datei <path.filename> nicht existiert. Unisched erstellt die Datei daraufhin sofort selbst wieder neu. Dieses Feature läßt sich z.B. um von einem anderen Programm aus zu kontrollieren, ob Unisched noch "am Leben ist". Hierzu wird nicht mal eine spezielle Aktion benötigt. Bsp.: !*e:\flags\unisched.alv = IGNORE invertierte Triggerfiles ------------------------ Syntax: !^<path+filename> = $<action name> [$<action2 name> ... ] Hier wird wie folgt vorgegangen: Die Aktion(en) wird/werden ausgelöst, wenn die angegebene Datei nicht exisitert. Anschließend wird die Aktion so lange nicht wieder ausgelöst, wie die Datei verschwunden bleibt. Unisched registriert intern, wenn die Datei erneut erscheint, und erst, wenn sie nach einem erneuten Erscheinen anschließend dann wieder verschwindet, wird die Aktion wieder ausgelöst. Wildcards sind hier nicht zulässig. Praktisches Anwendungsbeispiel: Weiß jemand eines? ;) Statische Zeitgesteuerte Events ------------------------------- Die Bezeichnung "statisch" dient der Unterscheidung mit den weiter unten erläuterten periodischen Events. Statische Events sind am ehesten mit dem vergleichbar, was man auch von den eingebauten Schedulern vieler Mailer her kennt. Allerdings handhabt UniSched auch die statischen Events etwas anders (besser! ;-) als die meisten Mailer. Erfahrungsgemäß verursacht dies zunächst leichte Verständnisprobleme ... lies Dir bitte die Doku sorgfältig durch, bevor Du damit rumspielst. ;-) Syntax: #<nr> <from> <to> [<weekday>] [<fromdate> <todate>] [even|odd] = $<action> <nr>: Nummer des Events, UniSched bestimmt, ob das Event schon ausgeführt wurde oder nicht. Diese Nummer dient lediglich dazu, das Event eindeutig zu identifizieren. Die Nummern müssen nicht aufeinanderfolgend sein, es muß auch keine Reihenfolge eingehalten werden (ein Event, das später kommt, darf problemlos eine niedrigere Nummer haben) - das einzige, was man beachten muß, ist, daß man nicht zwei Events die gleiche Nummer geben darf (sollte ...) Wenn man an der Config was ändert, sollte man gleichbleibende Events nicht umnumerieren, ansonsten werden sie nämlich an dem Tag, an dem man an der Config rumbastelt u.U. nochmal ausgeführt. <from>, <to>: Die Start- und End-Uhrzeit des Events. UniSched verhält sich hier grundlegend anders als die Braindead-Scheduler einiger Mailer. UniSched stellt sicher, daß die angegebene Aktion innerhalb der angegebenen Zeitspanne *genau* einmal ausgeführt wird. Solche Effekte, daß der Tosser zwanzig Mal gestartet wird, weil innerhalb der Zeitspanne, innerhalb derer er eigentlich nur einmal gestartet werden soll, was anderes passierte, der Mailer runterfuhr, das Event dann neu startete und damit auch den Tosser nochmal, etc, pp., - solche Effekte gibt es mit UniSched nicht. Deshalb kann man die Zeitspanne ruhig schön groß wählen. Wenn z.B. um 05:00 eine Statistik generiert werden soll, und es von eminenter Wichtigkeit ist, daß die Statistik auf jeden Fall erstellt wird, wähle man als Zeitspanne einfach 05:00 24:00 - dann wird die Statistik mit großer Wahrscheinlichkeit irgendwann erstellt werden, selbst, wenn der um 04:30 gestartete Tosser mal 3 Stunden statt 30 Minuten brauchen sollte. Um darüber auf dem Laufenden zu bleiben, was bereits ausgeführt wurde und was noch nicht, verwendet UniSched die Datei UNISCHED.DAY, die es im aktuellen Verzeichnis anlegt. Es ist daher keine gute Idee, diese Datei zu löschen. (Ausnahme: Du hast den Eindruck, daß UniSched überhaupt nicht das tut, was Du konfiguriert hast - in dem Fall ist es möglich, daß die DAY-Datei kaputt ist, und Du kannst mal probieren, sie zu löschen, vielleicht hilfts). Die Zeitspanne darf auch die 24:00-Grenze überschreiten, UniSched hat damit kein Problem. (Seit der wb05 wirklich nicht mehr ;-))) <weekday>: Defaultmäßig wird die Aktion an jedem Wochentag ausgeführt. Hier kann man aber explizit einen oder mehrere Wochentage angeben, an denen die Aktion ausgeführt werden soll (wenn mindestens ein Wochentag angegeben wird, wird die Aktion an allen nicht angegebenen Tagen nicht ausgeführt). Die Tage werden auf Deutsch oder Englisch in Zwei-Buschstaben-Abkürzungen angegeben: Mo Di Mi Do Fr Sa So oder Mo Tu We Th Fr Sa Su. Ebenfalls möglich sind die Abkürzungen "Week" (für Mo-Fr) und "WkEnd" (für Sa+So). Bei Events, die die 24:00-Grenze überschreiten, wird als Wochentag der Wochentag *nach* 24:00 genommen! <fromdate>, <todate>: Normalerweise wird die Aktion an jedem Tag im Monat ausgeführt. Hier kann man optional angeben, daß die Aktion nur innerhalb der Tagesnummern fromdate bis todate gestartet werden soll. Die Tagesnummer muß dabei *von einem Punkt gefolgt* angegeben werden. Soll z.B. nur am 1. jeden Monats eine Statistik erstellt werden, verwende man "01. 01." , soll der Uplink nur bis zum 20. jeden Monats angepollt werden (wer macht sowas? ;), verwende man "01. 20." even, odd: Wenn das Wörtchen "even" oder "odd" in der Eventdefintionszeile erscheint, wird das Event nur ausgeführt, wenn die aktuelle Wochennummer gerade (even) bzw. ungerade (odd). Nützlich, wenn man z.B. etwas im 14-Tage-Rhytmus tun will. Für diesen Zweck muß zusätzlich zu "even" oder "odd" natürlich noch ein Wochentag angegeben werden, da sonst das Event an *jedem* Tag in den geraden bzw. ungeraden Wochen ausgeführt würde. <action>: Der Name der Aktion wie zuvor definiert. Beispiele: #010 00:00 24:00 01. 01. = $Statistik #020 00:00 04:00 = $Exportieren #030 04:05 04:15 Mo We Fr = $POLL_THOMAS #040 04:10 04:25 = $POLL_Hub #050 12:00 13:00 Mo even = $Preisliste_in_KOMMERZ_GER_Posten Periodische Events ------------------ Periodische Events dienen dazu, bestimmte Aktionen regelmäßig durchführen zu lassen. Beispielsweise könnte man alle 15 Minuten ein REXX-Skript aufrufen lassen, das überprüft, ob noch alle Mailer-Tasks oben sind, und falls nicht, diese neu startet (oder den Rechner neu bootet, je nach Gesachmack). Ein anderes Anwendungsgebiet wäre, z.B. alle xx Minuten automatisch Netmail exportieren zu lassen. Syntax: #<nr> ~<min> [+<sync> | -<sync>] [exact] [<from> <to>] [<weekday[s]>] [<fromdate> <todate>] = $<action[s]> <nr>: Wie oben eine Nummer, aufgrund derer das Event identifiziert wird, nicht mehr und nicht weniger. <min>: Nach so viel Minuten wird die Aktion erneut ausgeführt. ACHTUNG: Wenn man die Periodendauer eines bereits bestehenden Events ändert, sollte man wie folgt vorgehen: Event auskommentieren, Konfig neu einlesen, Semikolon wieder entfernen, neue Periodendauer einstezen, Konfig nochmal neu einlesen. Ansonsten kann es passieren, daß die ersten zwei, drei Ausführungen des Events zu falschen Zeiten kommen. Wenns doch passiert, zur Not das DAY-File löschen (s.u.). <+sync>: Normalerweise werden periodische Events an 0:00 Uhr <-sync>: synchronisiert, d.h., die projektierten Ausführungszeiten liegen dann bei 0:00 Uhr + n * Periodendauer. Diese Synchronisation kann man mit "+<minutenzahl>" nach "später" oder mit "-<minutenzahl>" nach "früher" verschieben. Sinn macht das, wenn man viele Aufgaben regelmäßig ausführen läßt, und es dann z.B. bei 60-minütigen Periodendauern immer zur vollen Stunde zu einem regelrechten "Eventstau" kommt. exact: Normalerweise holt UniSched die Ausführung des periodischen Events nach, wenn er sie nicht genau zur synchronisierten Ausführungszeit starten kann. Dies ist in den meisten Fällen sinnvoll (z.B. ist es bei Mail-Export-Events nicht so wichtig, wann genau sie ausgeführt werdne, nur, DASS sie mindestens einmal pro xx Minuten ausgeführt werden), manchmal kann es aber nerven, z.B., wenn man zu bestimmten Uhrzeiten einen Gong abspielen will o.ä. Die Angabe der Zeichenfolge "exakt" in der Event-Definition bewirkt, daß das periodische Event NICHT nachgeholt wird, falls es nicht genau zur synchronisierten Zeit ausgeführt werden kann. Die übrigen Parameter haben genau die gleiche Syntax wie bei statischen Events. Bsp.: #510 ~60 -10 = $Exportieren ;Exportiert immer um 10 Minuten nach der vollen Stunde (oder später, ;falls es geanu zu dem Zeitpunkt nicht klappt) #520 ~60 exact 08:00 20:00 Week = $Stundengong ;Ein "Kuckuck", aber nur, wenn es wirklich genau die volle Stunde ist. #530 ~60 +30 exact 08:00 20:00 Week = $Halbstundengong ;Ebenso, zur halben Stunde Wie genau behandelt UniSched nun periodische Events? Zunächst einmal synchronisiert UniSched ein neu definiertes Event mit 00:00h (oder einer entsprechend verschobenen Zeit, s.o.) des aktuellen Tages. Wird also ein viertelstündliches Event definiert, wird dieses auch immer genau um xx:00h, xx:15h, xx:30h und xx:45h ausgeführt. Etwas wirr wird dies nur, wenn man eine Zeitspanne definiert, die kein Teiler von 1440 (der Zahl der Minuten eines Tages) ist. Z.B. 27 Minuten. Dann sind von Tag zu Tag die Ausführzeiten unterschiedlich ... Kann UniSched zur synchronisierten Zeit das Event nicht ausführen, weil er down ist oder ein Event mit höherer Priorität startet, wird das periodische Event nachgeholt - aber nur solange, bis bereits die nächste Instanz dieses periodischen Events fällig wäre. So wird vermieden, daß es einen Stau von Events gibt, wenn man ein Event definiert, das jede Minute ausgeführt werden soll, das aber 10 Minuten dauert ... Will man das Nachholen von periodischen Events ganz unterdrücken, muß man die Zeichenkette "exact" in die Definition einfügen. Dies ist aber wirklich NUR für Stunden-Gongs o.ä. geeigenet - alles, was irgendwie wichtig ist, sollte man auf jeden Fall nachholen lassen. Die Parameter from, to, weekdays, fromday etc. pp. definieren einen Zeitrahmen, in dem das Event ausgeführt werden darf. An der Behandlung und Synchronisation ändert sich dadurch gar nichts - Unisched arbeitet das alles durch, und erst, wenn es so weit ist, das Event genau jetzt auszuführen, wird geprüft, ob die aktuelle Uhrzeitn dem erlaubten Zeitrahmen liegt oder nicht und evtl. die Ausführung unterlassen. Um diese etwas theoretische Ausführungen zu verdeutlichen, einfach ein paar Beispiele. Nehmen wir das folgende Viertelstündliche Event: #123 ~15 14:50 17:25 = $Tue_Was Dieses Event wird erstmals um 15:00h ausgeführt. Um 15:10 startet UniSched ein anderes Event, das bis 15:20 dauert. Die nächsten Ausführzeiten des periodischen Events 123 sind nun: 15:20 15:30 15:45 etc. Das Event um 15:15 hat sich also auf 15:20 verschoben. - Um 15:50 startet UniSched wieder ein anderes Event, das bis 16:47 dauert. Die weiteren Ausführzeiten sind nun 16:47 17:00 17:15. Die Events um 16:00, 16:15 und 16:30 sind also unter den Tisch gefallen. Das Event um 16:45 hat sich auf 16:47 verschoben. Das Event um 17:30 liegt außerhalb des erlaubten Zeitrahmens. So, nun viel Spaß beim Einrichten. Falls Du Probleme hast, die auch nach mehrmaligem Durchlesen der Doku sich nicht lösen, kannst Du Dich gerne bei mir melden. Siehe dazu Kapitel 5. 3.4 AUFRUF UND BEDIENUNG ------------------------ UniSched wird einfach durch Aufruf von UNISCHE2.EXE bzw. UNISCHED.EXE gestartet. Dabei wird dann die Datei UNISCHED.CFG (ausschließlich!) in dem Verzeichnis gesucht, in dem sich die .EXE-Datei befindet. Ein anderer Ort oder anderer Namen der Konfigurationsdatei kann mit dem Parameter /c<filename> angegeben werden. In diesem Verzeichnis legt Unisched unter dem Stammnamen der Config-Datei (also i.d.R. UNISCHED) noch ein paar weitere Dateien an: UNISCHED.DAY Enthält Informationen des Schedules darüber, welche Events heute schon wann gestartet wurden. Löscht man diese Datei, während Unisched nicht läuft, werden beim nächsten Startup alle noch ausführbaren Events nachgeholt. - Manchmal kann es nützlich sein, Unisched herunterzufahen, diese Datei zu löschen, und Unisched wieder zu starten. Insbesondere dann, wenn Unisched periodische Events zu anderen Zeiten ausführt als gedacht. UNISCHED.ACT Enthält einen Dump des Logfensters und kann problemlos gelöscht werden. UNISCHED.BSY Semaphore-Datei, die anzeigt, daß Unisched bereits (mit der dazugehörigen Config-Datei UNISCHED.CFG) läuft. Unisched startet dann bei einem erneuten Aufruf nicht. Es ist somit eine gute Idee, diese Datei während des Systemstartvorgangs vorsorglich löschen zu lassen. Falls der Rechner mal während Abwesenheit neu bootet oder so ... Bsp: UNISCHED /Ce:\configs\usched1.cfg Startet Unisched mit der Konfigurationsdatei e:\configs\usched1.cfg. Die restlichen Dateien nennt Unisched dann entsprechend e:\config\usched1.day, usched1.act und usched1.bsy. Wenn sich ein grundlegender Fehler in der Config befindet, startet Unisched nicht, sondern gibt (mittlerweile <g>) einen sauberen Log-Dump aus (die Fehlerursache steht meist fast ganz unten) und wartet 30 Sekunden auf einen Tastendruck, bevor es sich beendet. Behebare Fehler während der Ausführung (Tippfehler in Event-Definitionen) werden gelogged, ohne daß sich Unisched beendet. Zur Bedienung von Unisched ist nicht viel zu sagen, die einzige vorbelegte Taste ist Alt+X zum Beenden. Alle anderen Funktionen können bzw. müssen mit Hilfe der KeyXXX-Statements in der Config selbst erzeugt werden. Eine DOS-Shell gefällig? KeyAltJ = EXEC COMMAND.COM bzw. KeyAltJ = EXEC CMD.EXE Konfiguration aus Unisched heraus editieren? $EditConfig = EXEC c:\msdos\edit.exe e:\mailer\sys\unisched.cfg $ReadConfig = RESTART $Konfigurieren = $EditConfig $ReadConfig KeyAltC = $Konfigurieren Die Möglichkeiten sind unbegrenzt. 4. UNISCHED FUER FORTGESCHRITTENE --------------------------------- 4.1 Online-Tossing ------------------ 4.1.1 - Was ist Online-Tossing? Normalerweise erhältst Du von Deinem Uplink z.B. zwei 2 MB-Pakete in einem Poll. Erst wenn sämltiche Pakete komplett empfangen sind und die Session beendet ist, wird Dein Tosser gestartet. Die Zeit, bis die Mail komplett für Downlinks von Dir zur Verfügung steht, ist also die Zeit, die für den Transfer benötigt wird, plus die Zeit, die fürs Tossen benötigt wird. Ruft Dein Downlink schon an, während Du noch die letzten 50 KB von den 4 MB transferierst, bekommt er - NICHTS. Mit Online-Tossing bittest Du Deinen Uplink, Dir mehrere kleine Pakete (z.B. 10 400K - Pakete) zu schicken. Mit modernen Tossern ist das kein Problem. Unisched überwacht kontinuierlich Deinen Inbound. Sobald dort ein Mailpaket *komplett empfangen* bereitliegt, startet er Deinen Tossertask. Dieser kann nun das erste / die ersten Pakete schon eintossen und bereitlegen, während der Mailer die restlichen Pakete transferiert. Solange der Tosser dies tut, setzt Unisched die Inbound-Überprüfung aus (kann aber sonstige Funktionen, wie Polls generieren, weiterhin ausführen). Erst, wenn er von dem gestarteten Tossertask signalisiert bekommt, daß er fertig ist, schaut er wieder in den Inbound und startet den Tosser ggf. erneut. Wenn Dein Uplink nun anruft, während Du die letzten 50 KB von den 4 MB transferierst, bekommt er bereits 3.6 MB mitgesendet. 4.1.2 - Systemanforderungen für Online-Tossing. 1. Du solltest Dich mit Unisched und Deinem System schon gut auskennen. Begriffe wie Semaphore-Datei, Unprotected Inbound, Maximum Pack Ratio, Badmail etc. sollten bei Dir keine Bauchschmerzen hervorrufen. 2. Dein Mailer muß File-Sharing unterstützen, d.h. Pakete während des Empfangs mit SH_DENYALL öffnen. Ansonsten kann Unisched nicht erkennen, ob das Paket bereits empfangen ist, oder nicht. 3. Dein System muß einwandfrei multitaskingtauglich sein. 4. Der Tosser muß einwandfrei konfiguriert sein. Bemerkungen zu 2.: Getestet habe ich selbst McMail und Binkley XE. McMail 1.0g5 hatte kein Problem. Binkley XE unterstützt File-Sharing in allen Versionen außer den DOS-Versionen XR1 und XR2. Die OS/2-Versionen und die DOS-Versionen ab XR3 sind kein Problem. Ob Dein Mailer Online-Tossing-tauglich ist, kannst Du wie folgt herausfinden: Requeste Dir ein großes File, das ein bißchen zur Übertragung braucht. Versuche nun, bereits während der Übertragung dieses File mit TYPE anzuzeigen oder sonstwie zu lesen. Dabei mußt Du eine SHARING VIOLATION als Fehlermeldung erhalten. Kriegst Du das nicht, ist Dein Mailer / Dein Betriebssystem / Dein Netzwerk nicht geeignet. Ich bitte hierbei um Rückmeldung, welche Mailersoftware hier außer der von mir getesteten problemlos ist. Bemerkungen zu 3.: Heutzutage schimpft sich ja fast jedes Betriebssystem und vieles, wo "Betriebssystem" auf der Packung steht, multitaskingtauglich. Es ist dann meist auch kein allzugroßes Problem, eine kleine Zwei-Line-BBS zu fahren mit einem Background-Tossertask. In den meisten Fällen läuft der Tossertask ja eh nicht während eines Transfers, und wenn doch, sind kurzfristige geringfüge Rückgänge in der cps-Rate ja nicht so tragisch. Mit Online-Tossing forcierst Du aber geradezu, daß praktisch während der ganzen Transferzeit grundsätzlich immer der Tosser läuft. Sagen wir, daß das einen Rückgang der cps-Rate um 300 cps bedingt, dann verursachst Du durch Einsatz des Online-Tossing Deinen Downlinks nicht von der Hand zu weisende Mehrkosten. Ideal geeignet für den Einsatz von Online-Tossing ist ein System mit folgenden Merkmalen: 80486dx2-66, SCSI, FIFOs, aktive ISDN-Adapter, OS/2 Warp 3 mit nativen OS/2-Mailern, einem nativen OS/2-Tosser und Ray Gwinns SIO als Schnittstellentreiber. Eine derartige Konfiguration ist in der Lage, Online-Tossing auch im Multilinebetrieb ohne den geringsten Einfluß auf die cps-Rate durchzuführen. Bei allen anderen Konfigurationen kann ich keinerlei Garantien abgeben. Bemerkungen zu 4: Du mußt ABSOLUT sicherstellen, daß Dein Tosser ALLE PKTs im Inbound und im Protected Inbound sowie ALLE Arcmail-Pakete im Protected Inbound ENTFERNT. Wenn er ein Archiv nicht entpacken will oder kann, muß er es umbennen oder sonstwohin verschieben. Wenn er ein PKT verweigert, muß er es in BAD umbenennen. Ansonsten fängt sich Unisched in einer ENDLOSSCHLEIFE, weil der Tosser immer wieder für das gleiche Paket aufgerufen wird. Online-Tossing is not for the weak of heart. Unisched macht es Dir so einfach wie möglich, aber es ist trotzdem problemlos möglich, damit Dein System lahmzulegen, Downlinks zu vergraulen, etc. pp. Sage nicht, ich hätte Dich nicht gewarnt. Wenn man aber sein System im Griff hat, kann Online-Tossing eine sehr feine Sache sein. 4.1.3 - Jetzt aber ran ans Werk! Folgende (in Kapitel 3 nicht erwähnte) Konfigurationsstatements sind für Online-Tossing relevant. Lese Dir das *genau* und *sorgfältig* durch und aktiviere die Statements erst, wenn Dir alles klar ist. Inbound = <inbound directory> ----------------------------- In dem angegebenen Directory sucht Unisched (ausschließlich) nach .PKT-Dateien. Das Keyword INBOUND darf in der Config mehr als einmal auftauchen, so daß es möglich ist, durch Wiederholung der Zeile mehrere Verzeichnisse anzugeben, z.B. den Unprotected Inbound und den Local Inbound. Bsp: Inbound=e:\bt\inound Inbound=e:\bt\local ProtIn = <directory> -------------------- In dem angegebenen Directory sucht Unisched nach .PKT-Dateien *und* Arcmail-Paketen (*.MO?, *.TU?, ..., *.SU?). Auch hier könnten mehrere Verzeichnisse angegeben werden, mir ist aber gerade kein Anwendungsfall dafür bewußt. Bsp: ProtIn=e:\bt\secure TosserSema = <dateiname> ------------------------ Diese Datei zeigt an, ob gerade der Tosser aktiv ist oder nicht. Sie wird, wenn kein Pfadname angegeben ist, im SemaDir (siehe dort) abgelegt. Unisched legt diese Datei automatisch an, wenn es nach einem gefundenen Mailpaket den Tosser startet. Umgekehrt wird der Tosser nur gestartet, wenn diese Datei noch nicht existiert. Es ist deshalb eine sehr gute Idee, diese Datei beim Systemstart vom Startup-Skript LOESCHEN zu lassen, sonst läuft der Tosser z.B. nach einem Stromausfall u.U. nicht mehr. Bsp: TosserSema = e:\sema\tossing.sem TosserAction = $<action1> [$<action2> ...] ------------------------------------------ Die eigentliche Aktion, die nach einem gefundenen Mailpaket ausgeführt werden soll. Beim Entwerfen der zugehörigen Batch sind einige besonders wichtigen Regeln zu beachten: - Ich betone es nochmal, die Batch MUSS MUSS MUSS UNBEDINGT alle PKT-Dateien und ARC-Mail-Packets aus den angegebenen Inbound- und ProtIn-Verzeichnissen entfernen. Wenn das durch die Arbeitsweise des Tossers nicht sichergestellt ist, sollte man dies am Ende der Batch durch RENAMEs von Hand sicherstellen. - Am Ende der Batch MUSS die unter TosserSema angegebene Datei gelöscht werden, um Unisched zu singnalisieren, daß es den Tosser gegebenenfalls erneut wieder starten kann. - Es ist nicht ratsam, in dieser Batch den Ticker anzuwerfen. Man sollte nur Echomail und Netmail tossen. Grund: Der Ticker könnte anlaufen, wenn zwar schon ein TIC-File, aber noch nicht die dazugehörige Datei angekommen sind. Dann landet das schon mal im BAD-Verzeichnis. Aus genau diesem Grund reagiert UniSched auch gar nicht auf TIC-Files. (Das kann man mit CheckTIC = Yes ändern, wird aber nicht empfohlen). Den Ticker solltest Du erst nach Session-Ende starten - dazu gibts die Tosser-Semaphoren, siehe unten. Bsp: TosserAction = $Import_Mail_Only Tosser-Sempahore-Dateien ------------------------ Syntax: +<path+filename> = $<action name> [$<action2 name> ... ] Auf die auf diese Art definierten Semaphore-Dateien funktionieren wird genau so geprüft wie auf normale (mit * statt mit + deklarierte) Semaphore-Dateien (siehe dort), mit dem einen Unterschied, daß hier nur reagiert wird, wenn die unter TosserSema angegebene Datei nicht existiert. Du brauchst das für folgenden Zweck: Vermutlich wirst Du mit dem unter TosserAction angegebenen Skript/Batch nicht die komplette Importprozedur durchlaufen. Der Ticker z.B. *darf* gar nicht aufgerufen werden, und vielleicht möchtest Du ja auch noch andere Aufgaben trotzdem nur nach Sessionende ausführen. Dann mußt Du weiterhin auf die MailIn-Sempahore Deines Tossers (BTMAIL.IN o.ä.) prüfen. Würdest Du das jetzt weiterhin mit der Methode mit * machen, dann könnte es passieren, daß die Aktionen nach Sessionende schon ausgeführt werden, während noch getosst wird. Um das zu verhindern, prüfst Du mit der + - Methode, dann wird die Aktion erst ausgeführt, wenn alle Pakete getosst sind. Umgekehrt wird bei der + - Methode auch vor Ausführen der Aktion die bei TosserSema angegebene Datei angelegt, so daß diese Datei von der angegebennen Aktion GELOESCHT WERDEN MUSS. Genau wie bei TosserAction. Bsp: +btmail.in = $ImportAbschluss 4.1.4 - Viel Spass! Nachdem Du das jetzt alles konfiguriert hast, lasse Dir erst nochmal die komplette Logik der Konfiguration durch den Kopf gehen. Ich möchte nochmals betonen, dass man hier im Zweifelsfall viel verbocken kann ... 4.2 Logausgaben fallweise unterdrücken -------------------------------------- In manchen Fällen ist es sehr ärgrlich, daß sich ein bestimmtes Event immer wieder im Logfile meldet. Hierzu gehören z.B. periodische Events mit sehr hoher Frequenz wie z.B. das Erstellen einer Alive-Semaphore o.ä. Man kann nun periodische Events gar nicht mehr anzeigen lassen, allerdings möchte man alle anderen außer dem einen bestimmten vielleicht doch sehen. Deshalb gibt es neben der Möglichkeit, die Logausgaben über die Schlüsselworte DiskLog, ScreenLog und PipeLog zu steuern, noch die Möglichkeiten, einzelne Aktionen oder Events "zu klammern". Man schließt hierzu die zugehörige Zeile in der Konfiguration, das kann eine Aktionsdefinition oder eine Eventdefinition sein, in eckige Klammern ein. Es wird dann alles, was mit dieser Aktion oder diesem Event zusammenhängt, *nicht* geloggt, weder im Disklog, noch im Fenster, noch in der Pipe, unabhängig vom Loglevel. Beispiel: $Create_Alivesemaphore = SEMAPHORE e:\flags\unisched.alv #111 ~1 = $Create_Alivesemaphore Dies führt zu sehr häufigen Einträgen im Logfile. Ändert man diese Zeilen nun entweder so: [ $Create_Alivesemaphore = SEMAPHORE e:\flags\unisched.alv ] #111 ~1 = $Create_Alivesemaphore oder so: $Create_Alivesemaphore = SEMAPHORE e:\flags\unisched.alv [ #111 ~1 = $Create_Alivesemaphore ] oder so: [ $Create_Alivesemaphore = SEMAPHORE e:\flags\unisched.alv ] [ #111 ~1 = $Create_Alivesemaphore ] ab, dann wird nichts, was mit der Alive-Semaphore zu tun hat, mehr im Logfile erscheinen. 5. SHAREWARE ------------ UniSched ist (C) 1996,97 by Tobias Ernst. Diese Software ist Shareware und darf innerhalb einer Testphase von 30 Tagen kostenlos verwendet werden. Die Sharewareversion darf beliebig weitergegeben werden, sofern das Programm vollständig und unmodifiziert weitergegeben wird. Nach der Testphase von 30 Tagen muß man sich registrieren lassen. Die Registrierung kostet während der Betaphase lediglich DM 10.-. Dieser Preis wird auf jeden Fall noch bis 31.03.1998 zugesichert. Ein erworbener Beta-Key wird für alle zukünftigen textorientierten Versionen von UniSched gültig sein. Das Registrier-Formular findet sich in der Datei ORDER.FRM. Die Sharewareversion ist im Funktionsumfang nicht eingeschränkt. Eine Garantie für Funktionstüchtigkeit des Programmes oder eine Verantwortung für aus der Nutzung entstehende Folgeschäden kann, soweit gesetzlich zulässig, nicht übernommen werden. Wer die Sharewareversion länger als 30 Tage unregistriert verwendet, den möge der Blitz beim Sch...en treffen ;-))). 6. VERSCHIEDENES ---------------- Für Fragen und Bugreports bin ich zu erreichen unter Tobias Ernst @ 2:2476/418.0 tobi@bland.fido.de Die jeweils neuste Version von UniSched kann mit dem Magic UNISCHED bei mir requestet werden. (Mit S-C-H! ;-) [EOF]