Dieser Text soll nur kurz beschreiben, wie das vorliegende Programm installiert und gestartet werden kann. Die Details der einzelnen Konfigurations-Optionen für die auszuführenden Jobs können in der integrierten 'online-Hilfe' des Programmes <CronEdit.Exe> nachgelesen werden. ACHTUNG: In v0.42 habe ich (neben jeder Menge Interna) sowohl die Eingabe-Maske als auch die Struktur der Job-Datei verändert! Job- Dateien früherer Programm-Versionen sind damit nicht mehr verwendbar! Dieser Einschnitt wurde nötig, um eine noch 'freiere' Konfigurierbarkeit der Job-Zeiten zu ermöglichen, die mit der alten Programm-Logik (und dem früheren Format der Job-Datei) nicht realisierbar war. Das Programm läuft zwar stabil, ist aber (noch) =kein= offizielles Release, sondern noch immer eine Betatest-Version! ICH KANN KEINERLEI ZUSICHERUNG ÜBER DIE FUNKTIONSFÄHIGKEIT DES PROGRAMMES FÜR IRGENDEINEN ANWENDUNGSZWECK MACHEN! Das einzige, was ich versprechen kann, ist, daß das Programm Platz auf der Festplatte verbraucht ... Auch habe ich noch einige Ideen zu Optionen, die zu implementieren wären, aber noch keine Zeit gefunden, auch alles tatsächlich zu realisieren. Die in diesem Archiv enthaltenen Dateien DFG_Cron.Exe CronEdit.Exe cWork.Exe sind in ein =eigenes= Verzeichnis (Directory) zu kopieren. Sollen mehrere Cron-Tasks gefahren werden, ist für jeden Task ein eigenes Verzeichnis (Directory) anzulegen, in welche die o.a. Dateien zu kopieren sind. <DFG_Cron> verwaltet seine Dateien (Start- und Job- Batch sowie die Job-Datei, s.u.) Verzeichnis-abhängig und geht davon aus, daß sie ihm sozusagen 'exklusiv' zur Verfügung stehen. Als nächstes wird mit dem Befehl DFG_Cron S ---------- (mit einem großen 'S') die spätere Start-Batchdatei erzeugt. Dies ist zudem die =einzige= Situation, in der <DFG_Cron.Exe> direkt aufgerufen wird, denn gestartet wird die Job-Verarbeitung (später) durch <Cron.Bat>. Das ist die hier erzeugte Batch-Datei, die dann ihrerseits <DFG_Cron.Exe> aufruft sowie die jeweils aktuellen Jobs abarbeitet. Das Hauptprogramm <DFG_Cron> hat einen eingebauten Bildschirm- Schoner (Marke: Sternen-Himmel). Wenn der =nicht= aktiviert werden soll, so daß die Bildschirm-Ausgaben der aufgerufenen Jobs sichtbar bleiben, kann bei der Erzeugung der Start-Batchdatei zu dem Parameter "S" noch der Parameter "kS" (kein Schoner) angegeben werden. Bei jedem Aufruf von Jobs gibt das Programm ein kurzes akustisches Signal von sich. Falls das =nicht= gewünscht ist, kann bei der oben erwähnten Erzeugung der Start-Batchdatei der zusätzliche Parameter "kB" (kein Bimmeln) angegeben werden. Die unterste Bildschirm-Zeile (also 25, 43, 50 oder 60, je nach dem, welcher Bildschirm-Modus eingestellt ist) wird von <DFG_Cron> als 'Status-Zeile' verwendet. Dort sind Angaben zur aktuellen Uhrzeit, zum Zeitpunkt des nächsten Jobs sowie dessen Aufruf (und -Parameter) zu sehen. Wenn diese Zeile ein wenig lebendiger erscheinen soll, kann bei der Erzeugung der Start-Batchdatei der zusätzliche Parameter "mS" (mit Sekunden) angegeben werden. - Soll hingegen überhaupt =keine= Status-Anzeige sichtbar sein, so kann bei der Erzeugung der Start-Batchdatei noch der Parameter "kA" (keine Anzeige) angegeben werden. Da das Programm selbstverständlich am meisten Sinn hat, wenn es unter einem Multitasking-System läuft, ist es so kooperativ, regelmäßig nicht benötigte Rechenzeit freizugeben (bis zu 15 Tics pro Sekunde), unter DesqView, OS/2 und sogar unter der sog. 'graphischen' Oberfläche WinDoz, im 'nackten' DOS wird stattdessen der Idle- Interrupt aufgerufen.. - Falls eine solche Rechenzeit-Freigabe =nicht= geschehen soll (Weshalb eigentlich nicht?), kann bei der Erzeugung der Start-Batchdatei zu dem Parameter "S" noch der Parameter "kM" (kein Multitasking) zusätzlich angegeben werden. Zusammenfassung der Start-Optionen: DFG_Cron S [kS | kB | mS | kA | mD | kM] Nocheinmal: <DFG_Cron.Exe> wird =nur= hier, bei der Erzeugung der Start-Datei <Cron.Bat> direkt aufgerufen! Sonst wird die Arbeit stets durch diese Batch-Datei gestartet. Was nun noch fehlt, ist das Wichtigste: die Liste der abzuarbeitenden Jobs für <DFG_Cron>. Diese könnte zum einem mit einem beliebigen ASCII-Editor angelegt werden. Um das Ganze ein wenig zu vereinfachen, kann diese Arbeit auch recht komfortabel (ahem) mit dem Programm <CronEdit.Exe> erledigt werden (daher dokumentiere ich die simple Struktur der Job-Datei auch nicht ausdrücklich). Also einfach mal aufrufen: CronEdit Hier erscheint eine Liste variabler Länge (ich hab' sie schon mit über 600 Einträgen getestet), in der die einzelnen Einträge aus der <CronJobs.Dat> dargestellt werden. Mithilfe der Cursor-Tasten kann man sich nun bewegen, mit <CR> einen Eintrag zur Bearbeitung auswählen. Ein Druck auf <F1> zeigt hier, daß mit <ALT-N> (oder <Ins>) ein neuer Datensatz erzeugt und mit <ALT-C> der aktuelle Satz kopiert werden kann, während er mit <ALT-D> (oder <Del>) gelöscht wird. Ich hoffe, daß die Maske halbwegs verständlich ist. Hier sind einige Prüfungen eingebaut, die sicherstellen sollen, daß die eingegebenen Daten konsistent sind. Durch einen Druck auf <F1> erscheint eine 'online-Hilfe', in welcher die einzelnen Felder erklärt werden. Alles in allem haben wir dann irgendwann im Cron-Verzeichnis die folgenden Dateien: Cron.Bat Start-Batch für die Job-Verarbeitung: hierdurch wird die Cron-Arbeit gestartet; CronDown.!!! tmp. Flag-Datei (0-Byte): kann jederzeit gelöscht werden; CronDump.$$$ tmp. Datei mit Status-Informationen: kann gelöscht werden, dient nur Debugging-Zwecken (kann im Cron mit ALT-W erzeugt werden); CronEdit.Exe Maskeneditor für die Job-Liste: hiermit können die Einträge in <CronJobs.Dat> gepflegt werden; CronJobs.Bat Hilfs-Batch für die Job-Verarbeitung: ist meistens nur 0-Byte groß, darf aber nicht gelöscht werden. CronJobs.Dat Job-Liste: kann mit <CronEdit.Exe> bearbeitet werden; CronJobs.Log Protokoll-Datei der aufgerufenen Jobs: dient nur der Information und kann jederzeit gelöscht werden; CronJobs.In! Flag (0-Byte), das erzeugt wird, wenn das Programm die <CronJobs.Dat> neu eingelesen hat; die Datei dient nur der Information und kann jederzeit gelöscht werden; cWork.Exe Hilfsprogramm für Job-Protokollierung: protokolliert u.a. die Job-Aufrufe in <CronJobs.Log>; DFG_Cron.Exe Hauptprogramm: wird über <Cron.Bat> aktiviert; LiesMich.!!! diese Datei (ach ja?) TagesWex.el! Flag (0-Byte), das erzeugt wird, wenn das Programm einen Tages-Wechsel erkannt hat; die Datei dient nur der Information und kann jederzeit gelöscht werden; So, nachdem nun alles beisammen ist, kann die Job-Verarbeitung jetzt gestartet werden: Cron Nun geschieht erstmal überhaupt nichts Spektakuläres, vielmehr wartet das Programm, bis die Zeit gekommen ist, um den ersten/ nächsten Job aufzurufen. Je nach dem, ob der Bildschirm-Schoner aktiviert ist oder nicht, erscheint allmählich ein Sternen-Himmel oder aber der vorherige Bildschirm-Inhalt bleibt sichtbar. Jeweils beim Wechsel einer Minute zur nächsten wird geprüft, ob aktuelle Jobs vorliegen. Ist dies der Fall, werden sie mithilfe der temporär erzeugten (bzw. gefüllten) Datei <CronJobs.Bat> abgearbeitet. Ist dies jedoch nicht der Fall, wird überprüft, ob sich das Datei-Datum der Job-Liste <CronJobs.Dat> geändert hat. Ist dem so, wird die Datei neu eingelesen. Auf die Weise kann diese Liste auch verändert werden (z.b. in einem anderen Task), ohne daß dazu der laufende Cron-Task extra abgebrochen werden müßte. Heiße Schlüssel: ================== Folgende 'Hot-Keys' sind während des Programm-Laufes von <DFG_Cron.EXE> bzw. <Cron.Bat> möglich: Alt-A schaltet die Statuszeilen-Anzeige ein/aus (Toggle für Start-Parameter "kA") Alt-B schaltet das Bimmeln bei Job-Aufruf ein/aus (Toggle für Start-Parameter "kB") Alt-D schaltet die DataDump-Erzeugung ein/aus (Toggle für Start-Parameter "mD") Alt-N erzwingt einen Neustart des Programmes; Alt-M schaltet die Rechenzeit-Freigabe ein/aus (Toggle für Start-Parameter "kM") Alt-R erzwingt Einlesen von <CronJobs.Dat> Alt-S schaltet den Bildschirm-Schoner ein/aus (Toggle für Start-Parameter "kS") Alt-T schaltet die Sekunden-Anzeige ein/aus (Toggle für Start-Parameter "mS") Alt-W erzeugt eine DataDump-Datei ESC, Alt-X, Alt-F4 brechen das Programm ab Bekannte Eigenheiten: ====================== * Wenn einzelne Jobs als 'nachzuholen' markiert sind, werden sie beim ersten Programm-Start des Tages komplett nachgeholt. Falls das =nicht= gewünscht ist, einfach vor dem Aufruf von <Cron.Bat> am Dos-Prompt eingeben: Echo Bitte nix nachholen >CronJobs.Bat * Als eines der größten Probleme hat sich die zweifelsfreie Erkennung eines Tages-Wechsels entpuppt. Da es natürlich dem Ziel einer möglichst geringen Rechner-Belastung widerspräche, permanent System- Datum und -Zeit abzufragen, bleibt nur der Weg über die sog. "Timer- Tics". Allerdings muß wenigstens zur Erkennung eines Minuten- Wechsels (wg. der damit ggf. verbundenen Aktivierung von Jobs) bisweilen die aktuelle System-Zeit ermittelt werden. Um nun diese Abfragen möglichst gering zu halten, wird eine bestimmte Anzahl von Timer-Tics (16 von 18,2/Sek.) für diese Abfragen übersprungen und anstelle dessen die nicht benötigte Prozessor-Zeit freigegeben: Unter DesqView/386, DV/X und OS/2 durch entsprechende Int-15- Funktionen, unter WinDoz und anderen virtuellen 8086-Tasks mithilfe des Multiplex-Interrupts, im 'nackten' DOS durch den Idle-Interrupt. * Jobs, die =vor= Mitternacht 'verpaßt' wurden, werden =nach= 0 Uhr =nicht= nachgeholt. * Der 'DataDump' wird von <CronEdit> jetzt nicht mehr automatisch bei Terminierung erzeugt, sondern nur noch, wenn er manuell mit <Alt-W> 'angefordert' wird. * Dank an Moritz für Fehler-Hinweise und Verbesserungs-Vorschläge. * Mehr fällt mir im Moment nicht ein. So long ... Für weitere Hinweise & Anregungen bin ich stets empfänglich ... Matthias -- EMail: Matthias@OLN.ComLink.APC.org