BINKHM History (+) new function (-) removed function (*) fix (i) for info only ------------------------------------------------------------------ 17.08.2012 v4.35 * fixing dozens of "rerror: Local error saving file" reports in undef.log 28.06.2012 v4.34 * Log maintenance in the background leaves a logfile with half of a started/finished session. Binkhm tries to read a previous line and ends in a deadlock as it cannot find a starting line (BOF scenario) Problem fixed. * Proc DBGLOG line 1953, undefined identifier BOL_ Problem occured with a configuration error. Binkhm terminates and wants to write to the dbglog file. var defined global. Problem fixed. 25.12.2011 v4.33 i ARI3 line 1067 internal error 19 fix in 4.30-gamma3 seems working, no further reports received bug report #071 closed. i possible problem if delimiters [] in systemname?!? eg Systemname [V110,X75] (aka) not critical, no problem found yet. bug report #068 closed i loop problems and caching problems with logfiles fix in 4.33 seems working, no further reports received bug report #065 closed. 17.12.2011 v4.33 + added dbglevel default 2 to prevent Session not found (1) logging to undef.log New config parameter: DBGLEVEL + added "recv: {10053} An established connection was aborted .." exception * Reset() on analyze long logfiles annoys in very long runtimes without gaining any addtl. infos. Reset() now resets to last confirmed stamp position and only resets to 0 if new logfile is smaller then old logfile (eg daily log cleanup routine) 23.08.2010 v4.32 + Added log analyze before view before v4.32 binkhm view was started. After exiting the view window binkhm runs a reorg that triggers a full loganalyze, so new logentries will be imported. The loganalyze now has been moved before view, so the newest, not imported logs now included in the current view. 05.05.2010 v4.31 * Records from Dec displayed at bottom of view for months Problem occured by wrong year definition of records that are imported in January next year. Fixed crtidt() routine to take care about the month of analyzed session. 20.12.2008 v4.30-gamma3 * Problem with record locking: ARI3 line 1067 internal error 19 trying a fix. 19.10.2008 v4.30-gamma2 * BinkD parsing: fallback analyze for primary AKA 17.10.2008 v4.30-gamma2 * BINKD log analyze: sometimes, the aka field contains systemname fragments: mailonly.homei... or secondary akas. now, system aka is allways used by the keyword 'addr:' and only the primary aka is logged (if multiple akas used, the secondarys will be skipped). fixed. + BINKD analyze displays systemname only (BINK-XE displays (aka). The aka will now be displayed also in on stdout, but not saved into BINKHM's database (redundant data). Its only for display purpose on analyzing. 18.09.2008 v4.30-gamma * addtl. BinkD v0.9.9 and v1.0a-515 keywords i shift from beta12 to new gamma1 version i earlier Log analyze problems probably caused by logfile cachings i changed packer format from arj to zip 23.10.2006 v4.21-beta12 * "unable to connect" and "trying" sequenze at begin of logfile caused endless loop. Fixed. + prevent "unable to connect" and "trying" sequenzes from logging to undef.log. Mark of other not found sequenzes in BeginOfLog cases. 25.6.2006 v4.21-beta11 i internal error 1. Problems with stampfile. Workaround. Reset all logfiles value to 0 in binkhm.stp 19.02.2006 v4.21-beta11 + add info 'rebuilding indizes ... ' after index files removal in index file corruption cases: ocdbicrt line 131 expression error (in index key) Manual removal of files hmi, hmj, hc1-7 starts rebuilding of indizes. 26.01.2006 v4.21-beta10 + add '... skipped by remote' keyword to skip in analyse * fixed leak in garbage collection of finished sessions records that seems to be deleted aren't. 15.12.2005 v4.21-beta9 + add 'Can't send after socket shutdown' case 6.11.2005 v4.21-beta8 + added adtl. keywords * Fixed multiple 'Session not found: ... [###] done (to ...' and 'Session not found: ... [###] done (from ...' cases. * Fixed 'Proc ARI3 line 1000, index file corrupted' * Fixed special not found sessions: From debugging: ROLLBACK() triggerd more than 3 times. + 05 Jun 19:54:13 [706] done (to 2:20/11@fidonet, failed, S/R: 0/0 (0/0 bytes)) Session not found (2): + 05 Jun 19:54:13 [706] done (to 2:20/11@fidonet, failed, S/R: 0/0 (0/0 bytes)) ROLLBACK() triggerd more than 3 times. 05 Jun 19:54:13 [706] session closed, quitting... Session not found (2): 05 Jun 19:54:13 [706] session closed, quitting... Problem is caused by a 'holding' line followed by a 'done' and 'session closed, quitting...' line. ? 05 Jun 19:54:13 [706] timeout! + 05 Jun 19:54:13 [706] holding 2:20/11@fidonet (2005/06/05 20:04:13) + 05 Jun 19:54:13 [706] done (to 2:20/11@fidonet, failed, S/R: 0/0 (0/0 bytes)) 05 Jun 19:54:13 [706] session closed, quitting... The 'holding' line has been identified as a end-session event. Now the statement 'holding' line will be skipped from interpreting. 12.9.2005 v4.21-beta7 * Error 1: saverec 363 internal error 19 continue? Executions hangs on following lines: + 12 Sep 00:05:23 [221] addr: 2:xxxx/xxx@fidonet ? 12 Sep 00:05:23 [221] `CRAM-MD5-5f5f50bc5390e8323d334f287cb9e88f': incorrect password + 12 Sep 00:05:23 [221] done (from 2:xxxx/xxx@fidonet, failed, S/R: 0/0 (0/0 bytes)) 12 Sep 00:05:23 [221] session closed, quitting... Error 2: Proc ASUCH line 136, index file corrupted corrupted index binkhm.hmi or binkhm.hmj manualy removed. binkhm rebuilds the missing index and all runs well. + added "CRAM-MD5....: incorrect password" case 11.6.2005 v4.21-beta6 * 2 debug report log entries: - bad session detection, id [491] not found in psid[] (1105). - bad session detection, id [701] not found in psid[] (1105). caused by analyze session starting at ? 09 Jun 20:06:37 [701] unable to connect: {10060} Connection timed out The beta5 rollback routine was called successful and bad calls stack routine reports that the id isn't yet found in protocol list. Thats expected, 'cause analyze starts in between a mailer session log. Debug log removed in this case. Fixed. 9.6.2005 v4.21-beta5 * fwline() lines contains trailing 0Dh chars + 08 Jun 04:41:59 [449] call to 2:20/11@fidonet{0Dh} ^-- 0Dh !! With UPDCHECK 5.x updated low/level routines problem persists. Fixed with fwline() 0Dh check. * Multiple session not found cases: Session not found (1): + 31 May 23:04:50 [181] done (to ... possible problem: session 1 starts session 2 starts session 2 finishes session 2 triggers binkhm session 2 binkhm stamps end of session 2 session 1 finishes session 1 triggers binkhm session 1 binkhm cannot find start of session as of session 2 stamp and there are many unhandled arr[] overflows ! resulting in undef. sessions in 2nd step ... and problem with unfinished bad sessions: + 07 Jun 02:57:31 [373] call to 2:20/11@fidonet 07 Jun 02:57:31 [373] trying 83.227.134.58... ? 07 Jun 02:58:16 [373] unable to connect: {10052} A socket operation was ? 07 Jun 02:58:31 [373] f11.n20.z2.fidonet.net.: unknown host + 07 Jun 02:58:31 [303] call to 2:244/1111@fidonet ? 07 Jun 02:59:01 [303] railroad.dnsalias.net: unknown host ? 07 Jun 02:59:31 [303] railroad.myip.org: unknown host ? 07 Jun 03:00:01 [303] railroad.dtdns.net: unknown host ? 07 Jun 03:00:31 [303] railroad.dyns.cx: unknown host + 07 Jun 02:59:31 [278] call to 2:20/11@fidonet <-- session id changes 07 Jun 02:59:31 [278] trying 83.227.134.58... see id [373] ? 07 Jun 03:00:16 [278] unable to connect: {10052} A socket operation was ? 07 Jun 03:00:46 [278] f11.n20.z2.fidonet.net.: unknown host and db2() undef. (831): ? 08 Jun 04:47:30 [449] timeout! problem exists on incremental analyze if logfile analyzed in whole, no errors were found if "unable to connect" or "unknown host" BINKHM closes the open session, removes ids from active ids table. This should prevent array overflows. if "session not found" BINKHM now uses a smooth handling by rollback to the related "call to" line. This should handle all incremental analyze cases. other related problems that were found are fixed by the updated low/level i/o routines (see fwline() fix above). all cases of incremental analyze and not found starting session ids cases now handled by the new rollback() routine, that is triggered everytime an unopened session-id is found. The rollback() function should only be called once in a BINKHM session. A loop detection is implemented therefor. All array overflows, sessions not found cases that cannot detected are triggered with a debug mode log (undef.log in execution dir) and triggered with BINKHM termination of errorlevel 99. 8.6.2005 v4.21-beta4 * Problems with multiple unresolved bad and open sessions (BinkD): + 07 Jun 02:57:31 [373] call to 2:20/11@fidonet 07 Jun 02:57:31 [373] trying 83.227.134.58... ? 07 Jun 02:58:16 [373] unable to connect: {10052} A socket operation was ? 07 Jun 02:58:31 [373] f11.n20.z2.fidonet.net.: unknown host + 07 Jun 02:58:31 [303] call to 2:244/1111@fidonet ? 07 Jun 02:59:01 [303] railroad.dnsalias.net: unknown host ? 07 Jun 02:59:31 [303] railroad.myip.org: unknown host ? 07 Jun 03:00:01 [303] railroad.dtdns.net: unknown host ? 07 Jun 03:00:31 [303] railroad.dyns.cx: unknown host + 07 Jun 02:59:31 [278] call to 2:20/11@fidonet 07 Jun 02:59:31 [278] trying 83.227.134.58... ? 07 Jun 03:00:16 [278] unable to connect: {10052} A socket operation was ? 07 Jun 03:00:46 [278] f11.n20.z2.fidonet.net.: unknown host results in session not found and/or array overflows. Now, every possible bad sessions, identified by "unable to connect" or "unknown host" are added to a bad list protocol stack. Every new call to session is verified against the bad list and if a session is reinstated (see samples 1 and 3), the prior session markers are cleared that frees up the open sessions stack. One problem are the multiple tries in sample 2 with different addresses, but with the same session id. So "unknown host" cannot be used as an 'end of session' marker, but "unknown host" is also the last logentry. So these type of sesions have to be identified in a later stage by reusing the same session id or by identifying the same calling destination. If a session cannot identified directly, addtl. over all sessions protocoll with all call to's and session ids is filled by every new 'call to' session, so these unidentified and unresolved sessions can be identified by the 'call to' destination address and their related session id to prevent further unclosed sessions. + Beta-4 code now includes debug log output codes for every possible stack overflows that are logged into the undef.log in BINKHMs execution directory. If one or more debug lines are written to the undef.log file BINKHM terminates with an errorlevel 99, that can be used to trigger a sysops notify. State: monitoring 2.6.2005 v4.21-beta3 * "] done (from" lines found in undef. log. (BinkD) Changed "done (from" handling routine to clean old records with same session id before add. problem now seems to be solved. Fixed. 1.6.2005 v4.21-beta2 * possible loop with old entries in temp db (BinkD) i.e. entry 29.5. id [338] is unfinished, left in db next entry on 30.5. same id [338] ends with session length of multiple hours, 'cause old id hasn't cleaned. Before inserting new id, clean old unclosed sessions with same id. Problem comes with call to, trying, unable to connect sessions, they are left open. Fixed. 22.5.2005 v4.21-beta1 * BINKHM runs into loop (BinkD) several "session not found" entrys noted in undef.log. After debug its found that + 22 May 02:57:28 [842] session with ... ? 22 May 03:02:28 [842] timeout! + 22 May 03:02:28 [842] done (to ... 22 May 03:02:28 [842] session closed, quitting... analyse cleared in "timeout" line and following lines marked as "session not found". removed break code. Now session ends and closed in "session closed" line. Fixed. i After modifications on Cost.cfg with new Flat tarif BINKHM stops execution without any further info. I called BINKHM via batch and checking errorlevel conditions. Errorlevel 21 - cost group definition error - now was reported. I've found that addtl. new CALLZONE "Flat" that i've included into the groups definition was unknown. After moving CALLZONE parameter prior the groups section BINKHM knows about new CALLZONE parameter and continues execution. Sample cost.cfg's updated. * After 4.21 bugfixes and BINKHM execution under win xp dos shell conclusion never ends. Displays quarter conclusion: , . . , . . , and so on bhmreorg, _reo2(), qcall(), do while !c2stop_ loop. After debug manual setting c2stop_ = .T. session terminates regular ... Now in c2stop loop addtl. counter is added to detect and prevent endless loops. Fixed. + Added Windows detection and display enhancements. 24.3.2005 v4.20-beta1 * try fix "session not found" conditions. (BinkD) repos() and restart log reading from beginning. incl. loop detection, so repos() can only occur once. 11.2.2005 v4.13 + addtl. BinkD keywords. 29.2.2004 v4.12 + added many new BinkD keywords to known. 16.11.2003 v4.11 + added many BinkD keywords as known keywords. upto loglevel 5. 15.6.2003 v4.10-beta1 * BinkD log: cfg setting SHOW_NOC -> No 2:2437/370 {60} Connection timed out wird trotzdem angezeigt ... Fixed. 6.5.2003 v4.10-alpha2 * Fixed "Interrupted by Close" Abschluss aller offenen Sessions - Erweiterte BinkD Analyse Funktion zur Unterstuetzung multipler paralleler Tasks. - Abschluss von Session-Erkennung bei unterschiedlichen BinkD ShutDowns 3.5.2003 v4.10-alpha1 * Fixed BinkD Log analyze. - Erweiterte BinkD Analyse Funktion zur Unterstuetzung multipler paralleler Tasks. 25.1.2000 v4.01 * Hotfix: Low-Level i/o Routine. BOF Erkennung. Aufgrund aktivierter Clean-Log Funktion koennen Logfiles bis an die Zeile heran geloescht werden ... Da vor einem CONNECT Eintrag noch wesentliche Bestandteile zur Erkennung eines Inbound- oder Outbound-Calls analysiert werden muessen, wird bei der Analyse im Log zurueck und vorgesprungen. Beim Einlesen einer "vorherigen" Zeile trat erstmals der Fall ein, dass ein in die allererste Logzeile plaziert war. Da beim Erreichen eines Buffer-Anfangs auch der "vorherige Buffer" dann noch einmal eingelesen wird, im vorliegendem Fall der Pointer aber bereits am Dateianfang stand, der Fall aber nicht abgefangen wurde - bei einem Tageswechsel hinterlaesst an sich Binkley im Log Spuren, so dass an sich Systemmeldungen erst garnicht in der 1. Zeile stehen koennen - und somit in eine Endlosschleife lief ... (lese vorherige Zeile, lese vorherigen Buffer). Da an sich die Logfiles auch nur Sequentiell von oben nach unten abgearbeitet werden, bestand bislang auch keine Notwendigkeit einen Fall abzufangen, bei dem ein Pointer _vor_ den Dateianfang gesetzt werden koennte ... bis eben auf den besagten "Sonderfall" bei der Analyse der In/Outbound Erkennung ... Alle moeglichen Fehlersituationen im Zusammenhang mit dem Dateiende wurden bislang schon abgefangen. Nur nicht der Dateianfang .... (reported by Werner Blatt) 1.6.2000 v4.00 i Freigabe zur oeffentlichen v4.00 Vollversion. * Bei erneuter BinkD Loganalyse, wenn keine neuen Sessions zu finden sind, wird Stamp-Counter auf 0 zurueckgesetzt. Erst wenn wieder eine neue Session gefunden wird, wird Stamp wieder korrekt gesetzt. Fixed. Stamp wird nun, wenn es nichts zu analysieren gibt, beibehalten. 30.5.2000 v4.00-gamma * Verkuerzung des Helpaufrufs wenn -O? angegeben wurde, werden nicht mehr erst die Configs durchgeackert. * cOsts help design ueberarbeitet. Seitenweise Steuerung, Direktauswahl einzelner Help-Seiten, direkte Abbruchmoeglichkeit mit - Subroutine "under construction" entfernt. 23.5.2000 v4.00-gamma * Einige Unstimmigkeiten sind aufgetreten, nachdem Quartalsabschluesse mehrfach aufgerufen wurden. An sich sollten die Daten bei jedem erneuten Aufruf nur aktuallisiert werden, statt dessen haben sich die entsprechenden Werte vermehrt .... (die gesammelten Kosten stiegen von Aufruf zu Aufruf). Das Problem als solches ist nun gefixt. Gleichzeitig habe ich einen Fix eingebaut, der eine die Quartals- abschluesse einer bereits aktivierte Costsanalyse noch einmal komplett ueberarbeitet. * Im Beispiel Costs.Cfg der RAILROAD.CFG hatte sich noch ein Fehler eingeschlichen. Die AKA Liste der [Group3,UUCP] UUCP,German,P3 enthielt eine Callzone, die bei der entsprechenden Costsmatrix des entsprechenden Providers nicht aufgefuehrt war. Fixed. (reported by Werner Blatt) 21.5.2000 v4.00-gamma i Freigabe der Version v4.00-gamma 21.5.2000 v4.00-beta7 * Ausgabe bei Analyse: UUCP Anzeige ist versetzt ... O 3 31 Mar 19:20:37 Railroad BBS 2 00:00:24 O 7 07 Apr 00:00:36 prima.robin.de 00:04:16 Fixed. * Maintenance kann durch -a genauso ausgeloest werden wie durch -r. Bei -r ist sichergestellt, dass alle Daten vom Vortag in die interne Datenbank ueberfuehrt sind und somit auch die Costsanalyse vollstaendig ist. Nicht so bei -a. Hier ist allenfalls sichergestellt, dass die Costsdaten von dieser einen Line vollstaendig sind ... Moegliche Loesung waere, vor automatischer Maintenance _alle_ Line-Logs auszuwerten, bevor mit der eigentlichen Maintenance begonnen wird, egal mit welchen Aufrufparametern Binkhm gestartet wurde .... Fixed. 20.5.2000 v4.00-beta7 i Erweiterung des Sourcecodes von 189 kb seit v3.11 um 120 kb auf ueber 309 kb!!! * Wenn manueller Monatsabschluss vom aktuellen Monat durchgefuehrt wird muesste Stamp von "heute" gesetzt werden.... Bei allen anderen Conclusions -> nix. Fixed. * Daily inc costs Analyse ... Wenn mal 1 oder 2 Tage fehlen muss komplette Monatsanalyse durchgefuehrt werden ... inc Maintenance fuer mehrere Tage moeglich? Beispiel fuer Grenzwert: wenn aktueller Tag und last CDA <= 3 Tage Differenz sind, die fehlenden Tage nachberechnen? durch Flag wurden bislang Daily Conclusions gesteuert. durch STP Abfrage wird die Differenz Anzahl Tage nun an die Conclusion Routine zurueckgeliefert. Bei <= 3 Tagen werden fuer die entsprechenden Tage die Conclusions nachgefuehrt. > 3 Tage wird ein Monatsabschluss gefahren. Monatsabschluss bis einschl. gestern.... Fixed. * Genereller Check: CDA Routine (inc. daily costs analyse) Wenn Maint, dann Maint bis einschl. "Heute" -1 ? Ist das ueberall durchgehalten? oder wird Maint irgendwas bis einschl. heute durchgefuehrt? wenn Monats-Abschluss nachgeholt wird, wird Maint bis einschl. gestern oder bis einschl. heute durchgefuehrt? -> Schluessigkeit der incremental daily costsanalyse vs. Monatsabschluss. Aufrufe: cfn1 183, reorg 74, reorg 85, reorg 98 -> check ob Monat = aktueller Monat wenn aktueller Monat, Tage bis einschl. "heute" -1 Zu analysierende Tage bis "heute" -1 durch Pruefung in der Routine selbst ausgeschlossen. Fixed. 19.5.2000 v4.00-beta7 * History db Maintenance wird bislang vor der Costs Analyse durchgefuehrt. Beim erstmaligen Aufruf werden somit eventuell noch vorhandene Sessiondaten geloescht, bevor die Daten in die Costscalculation haetten aufgenommen werden koennen. Reihenfolge bei der Maintenance getauscht. Fixed. * Beim erstmaligen Aufruf nach Aktivierung der Costs-Analysefunktionen erscheint zwar bei der Maintenance: "Re-Calculating costs after config changes ..." Aber die Kalkulation der Vormonate muesste von Hand nachgefahren werden. Eine erstmalige Kalkulation aller moeglichen Monats- und Quartals- Abschluesse waere wuenschenswert ... Ein Flag bei Erstellung der internen Datenbanken steuert nun auch den erstmaligen Komplett-Abschluss bei Initialisierung der Costs-Funktionen. Fixed. 18.5.2000 v4.00-beta7 * Viewer - Verbose mode - Calculating costs ... laesst sich nicht abbrechen Bei einem groesseren Monatsdatenbestand dauert die Berechnung der bisherigen "Gesamt-Monatskosten fuer _diesen_ Node" zum Ende eines Monats hin immer laenger. Da bereits die Maintenance auf incrementelle Verarbeitung der Costsdaten umgestellt wurde (siehe 14.5.) kann nun direkt auf die bereits ermittelten Daten zugegriffen werden. Fixed. i Sicherungskonzept? BinkHM ist bedingt reperaturfaehig (Indizes). mind. 1x im Monat Sicherung der dbs. In docu aufgenommen. * Bei Aufrufparameter "-og:hosts" erscheint im Report "hosts" statt "HOSTS" Fixed. 17.5.2000 v4.00-alpha7 * Die am 6.5. geaenderte Database Struktur fuehrte nachhaltig zu einem Problem beim Costscompile (Aenderung von Configparametern). Da ich bei der Database-Structure Reorganisation auch eine Reduktion der Anzahl von Indexfiles vorgenommen habe, wurden nun die Costs-Gruppen nicht mehr gefunden und immer wieder neu angelegt und somit Dupes erzeugt, die beim Output keine Ergebnisse mehr lieferten. Fixed. * Costs Group Report Output Fixes. 16.5.2000 v4.00-alpha7 + Added manuellen Quartals-Abschluss: Commandline Aufruf: -OC:Q#/yyyy Bsp.: -OC:Q1 od. -OC:Q4/1999 + Added Costs-Config Parameter CREPTYP 0|1 Report type fuer Costs Report: 0=Long (default) or 1=Short for Month, Quarter, Year reports ... Long: Node MM Year #Calls Session Total Costs #Files #Bytes #Files #Bytes Times [DM] -----Sent---- ---Received-- Short: Node MM Year #Calls Session Total Costs Times [DM] + Added Costs Group Report. Commandline Aufruf: -OG: Groupname as defined in COSTS.CFG 15.5.2000 v4.00-alpha7 + Added Quartals-Abschluss. Bei der Initialisierung werden erstmalig saemtliche Quartalsabschluesse (sofern ueberhaupt soviele Costsdaten vorliegen) nachgefahren. Bei einem erneuten Quartalsabschluss werden bestehende Daten ersetzt (nachtraegliche Korrekturen). + Added Costs History Database Maintenance in Quartalsabschluss. Monatsdaten > 2 Jahre und Quartalsdaten > 5 Jahre werden geloescht. 14.5.2000 v4.00-alpha7 * Monthly Conclusion in Daily Costs Analyse umgewandelt. "Monatsanalyse vom aktuellen Monat" bei Reports entfaellt nun voellig. + Alle Monatsabschluesse werden beim erstmaligen Initialisieren der Costs Calculation automatisch nachgefuehrt. 13.5.2000 v4.00-alpha7 * Costs Report Routine fixed so dass jetzt alle relevanten Records gefunden und ausgegeben werden. 12.5.2000 v4.00-alpha7 + Added AKA Costs Report. Commandline Aufruf: -OA: * Problem: es werden noch keine Records fuer die Ausgabe gefunden .. ?!? 11.5.2000 v4.00-alpha7 i AKA Costs Report Routine angefangen .... Probleme bei Auswertung der Aufrufparameter zusammen mit Outputfilename fixed. Tests soweit ok. 10.5.2000 v4.00-alpha7 * Costs Report Design ueberarbeitet. + Added Quartals Report fuer beliebiges Quartal, beliebiges Jahr. Commandline Aufruf: -OQ:q oder -OQ:q/yy oder -OQ:q/yyyy Ohne Angabe des Jahres bezieht sich der Report auf das aktuelle Jahr. i Additional -M Parameter fuer Costs Reports: (entfaellt. 17.5.2000) Fuer Reports zum aktuellen Monat, Quartal oder Jahr wird automatisch eine Costs-Calculation fuer den aktuellen Monat getriggert. In der Testphase, wenn wenig neue Daten hinzukommen, wird die Cost-Calculation fuer den aktuellen Monat bei jedem Lauf erneut durchgefuehrt. Mit dem zusaetzlichen Commandlineaufrufparameter -M (als 2. Parameter) kann die Costs-Calculation unterdrueckt werden und BINKHM greift auf die in einem vorherigenn Lauf gewonnenen Zwischenergebnisse zurueck. 9.5.2000 v4.00-alpha7 + Added "Grouped-By AKA" fuer Quartals- und Jahres-Ausgaben Routine. 8.5.2000 v4.00-alpha7 + Added Jahres-Report fuer anzugebendes Jahr (inclusive Erkennung auf "Aktuelles Jahr") Commandline Aufruf: -OY:yyyy + Commandline Aufruf mit Exportfilename ohne "zusaetzliche" Aufrufparameter benoetigen einen doppelten Doppelpunkt (Colon). Beispiel: binkhm -OM::mai2000.rep Costreport fuer aktuellen Monat Mai 2000, Export in File "mai2000.rep" aber ohne weitere -OM: Parameters + Monatsreport mit Parameters fuer Monat/Jahr: Commandline Aufruf: -OM:mm oder -OM:mm/yy oder -OM:mm/yyyy Ohne Jahresangabe wird der angegebene Monat im aktuellen Jahr ausgegeben. * Tabs in Help Screen werden nicht richtig widergegeben. Seitenweise Anzeige des Helpscreens (3 Seiten). Fixed. + Logische Pruefung auf Gueltigkeit von Monatsangaben, andernfalls Ausgabe des Helpscreen. 7.5.2000 v4.00-alpha7 + Added Monats-Report for actual month. Commandline Aufruf: -OM + Added Quarter-Report for actual quarter. Commandline Aufruf: -OQ + Added Jahres-Report for last year. Commandline Aufruf: -OY:-1 + Added Jahres-Report for actual year. Commandline-Aufruf: -OY 6.5.2000 v4.00-alpha7 * Datenbankstruktur erweitert fuer Group-Order: Cost-Group + AKA + Year,Month + Added nachtraeglicher Monatsabschluss fuer einzelne Monate per Commandline Aufruf: -OC:mm/yyyy 5.5.2000 v4.00-alpha7 * Modifications on Monthly Report + Added Report for last quarter 3.5.2000 v4.00-alpha7 i Erste Testversuche auf Zeit ergaben 1 Minute fuer 1000 Sessions Verarbeitungsgeschwindigkeit. i Versuch mit einer Alternativ-Routine, die Monatsabrechnung zu beschleunigen ergab nur, dass eine vergleichbare Alternative um das 10-fache laenger braucht. + Tuning an der Monatsabschluss-Routine. Ergebnis: fuer 1000 records (= Sessions) werden etwa 40 Sekunden zur Verarbeitung benoetigt (Reduzierung um 30% gegenueber der urspruenglichen Routine). Bei etwa 6000 Sessions / Monat benoetigt die Routine zur Auswertung saemtlicher Costinfos ca. 4 Minuten .... + Added -O... cOsts commandline Routinen. Erste Komplettroutine: Monatsreport vom Vormonat. i Erster Monatsabrechnungslauf und Monats-Report Ausgabe per Commandline Aufruf ... 2.5.2000 v4.00-alpha7 + Added "Costs Monatsabschluss Routine". Automatisch getriggert waehrend der daily Maintenance. Wurde noch kein Monatsabschluss vom Vormonat durchlaufen, wird der Abschluss automatisch angestossen. Fuer die Testphase kann man diese automatische Funktion mit dem Configparameter: ; No Monthly Conclusion (for disable monthly conclusion in test phase) NOMNTHCNCL YES erst einmal unterdruecken (bis alle Costs-Parameter im Config richtig eingetragen und getestet sind). NOMNTHCNCL YES bedeutet dabei, dass saemtliche Monats Abschluss Versuche unterbunden (nicht ausgefuehrt) werden. NOMNTHCNCL NO dagegen bedeutet, der Monatsabschluss wird nicht mehr unterdrueckt. 1.5.2000 v4.00-alpha7 + Costs Config Routinen implementiert. + Costs Config Compile only if Config has been changed. + Added Costs Info im BinkHM Viewer, Verbose Mode. + Bundesweit einheitliche Feiertage werden in der Cost-Kalkulation beruecksichtigt. * Minimum DAYS2KEEP wurde fuer Costs Funktionalitaet von 15 days auf 40 days angehoben. Bei einem zu gering parameterisierter DAYS2KEEP Wert wird BINKHM mit Errorlevel 23 beendet. 30.4.2000 v4.00-beta6 * Die nach der Freigabe der beta-5 noch weiter laufenden Tests haben im Zusammenhang mit der Analyse eines regulaeren Binkley Logs noch einen Type Mismatch Fehler produziert, der auf die Umstellung der zentralen i/o Routinen zurueckzufuehren ist. Fixed. 30.4.2000 v4.00-beta5 i Freigabe der alpha-5 Zwischenversion Stand 30.4. als beta-5. 29.4.2000 v4.00-alpha5 * BinkD Sessions wurden eine ganze Zeit lang nicht mehr ausgewertet. nachdem ich ein aktuelles Log zur Analyse erhalten hatte, stellte sich heraus, dass die Laenge des Task-identifiers variiert. Der Zeitraum, bei denen keine Sessions analysiert werden konnte wurden 4-stellige statt wie urspruenglich angenommen 5-stellige Task-identifiers benutzt. Der Code wurde nun so angepasst, dass die Laenge des Task-identifiers zwischen 1 und 5 betragen kann. + Neuer Parameter: MAXBINKDTASKS Maximale Anzahl gleichzeitiger (paralleler) BinkD Tasks defaults to 25 (min 5, max 100) value: 4 < Max BinkD Tasks <= 100 i.e. MAXBINKDTASKS 10 Wird zur Reservierung von Memory fuer die Verarbeitung mehrerer paralleler BinkD Sessions benoetigt. Als Faustregel sollte gelten: MAXBINKDTASKS >= Anzahl in BinkD definierter Calls + 5 Die Parametereinfuehrung soll es ermoeglichen flexibel die Anzahl moeglicher paralleler Sessions an die Gegebenheiten anzupassen. Moeglichst flexibel, dafuer aber auch wesentlich langsamer waere eine Verarbeitung ueber Temporaerdateien. Hier wurde aber die Hauptspeicherbenutzung fuer eine schnelle Verarbeitung bevorzugt, was jeddoch eine Belastung des Hauptspeichers nach sich zieht. Um hier einem Memoryoverflow vorzubeugen, wurde eine Speicherlimitierung eingebaut, die aber in gewissem Umfang angepasst werden kann. 27.4.2000 v4.00-alpha5 + Low-Level i/o Routinen umgestellt auf Multi-File-Zugriffe. (in Vorbereitung auf "nested" Include-Files i.e. @include cost.cfg). NEUE CONFIG-PARAMETER: INCLUDEPATH @INCLUDE * Fix: missing line in Help Screen 20.4.2000 v4.00-beta3 + Bei der Reportausgabe war es bislang nur moeglich, einen Report ab einem Startpunkt bis zum allerletzten Eintrag in der "internal" Database durchzufuehren. Bei der taeglichen Reportausgabe, konnten so bereits Sessions vom "darauffolgenden" Tag mit aufgefuehrt werden. Das verfaelschte die taeglichen Gesamtsummen. Mit einem neuen Aufrufparameter koennen gezielt nur die Eintraege von -Y(ester)D(ay) ausgegeben werden. Der "Report from Yesterday" wird mit dem Commandozeilenparameter -YD getriggert. Bsp.: binkhm -r -YD Ausgabe aller Eintraege nur von "gestern" ... (by U.Schroeter) 19.4.2000 v4.00-alpha4 + Check empty System oder System Laenge < 4 Zeichen. Ggf. wird das Systemnamensfeld mit dem Sysop Namen gefuellt. Bsp.: 23 Jan 12:27:21 - (2:2426/3165.16) neu: 23 Jan 12:27:21 Alfred Schroeder (2:2426/3165.16) i Bei einer BinkD Session wurde keine AKA erkannt. Trotz vielfacher Analysen konnte das Problem nicht reproduziert werden. Sollte das Problem noch einmal in einer Nachfolgeversion auftreten bitte umgehend den Author informieren. 17.4.2000 v4.00-beta2 * Probleme bei der Analyse - BinkD Log wird scheinbar ueberhaupt nicht analysiert this is a try of fastfix. 19.4.: hat wohl geholfen ;-) 12.4.2000 v4.00-beta + Added BinkD Support Additional Parameters in Logfile-definition: L09LOG v:\bink\log\binkd.log BD ^^^^^^^^^ ^^ | | | BinkD-type Logformat | BinkD-logfilename Aufgrund der BinkD Erweiterung musste die interne Database erweitert werden. Beim ersten Aufruf der neuen Version wird ein automatischer Database Upgrade von v3.x auf v4.x durchgefuehrt. Der "alte" Datenbestand bleibt dabei erhalten. Clean Logfile funktioniert ebenfalls. 9.4.2000 v3.11-gamma + Problem: Nach Providerwechsel wurde UUCP Log nicht mehr analysiert Hint: Fuer die Connect-Erkennung wurde in BINKHM die Zeile "(0) railroa connected to hydra: network link, v protocol, z grade" ausgewertet bzw. der Connect auf diese Zeile getriggert. Da mit dem Providerwechsel auch ein Protokoll-Wechsel stattfand, wurde die Zeile nicht mehr "erkannt" und die Sessions tauchten in der History nicht mehr auf. Nun wird das zum Beginn der Session verwendete Protokoll: "(2) remote=hydra, when=Any, device=elsa, phone=..." bzw. "(2) remote=prima, when=Any, device=elsa, phone=..." ausgewertet. Somit sollte es auch fuer alle zukuenftigen Variationen egal sein, welches Protokoll eingestellt wird ... (reported by Werner Blatt) + Die in v3.00 eingefuehrte Cleaning Function ist nun auch fuer UUCP-Logs aktiv und folgt den gleichen Regeln wie das Binkley-Log Cleaning. 3.4.2000 v3.10-gamma + Da es bislang vor Report-Erzeugung ZWINGEND notwendig war unbedingt eine Analyse _ALLER_ Logfiles durchzufuehren, habe ich diese Funktion direkt in BINKHM implementiert. Somit entfallen die BINKHM -a Aufrufe voellig (ausser fuer die Online-Verarbeitung, wenn also die Sessioneintraege sofort nach der Verbindung in die BINKHM Database eingebunden werden sollen). (Erweiterung der Idee aus der Clean-Log Routine) 2.4.2000 v3.00-gamma + Neue Funktion: Cleaning Logfile(s) Aufruf: BINKHM -c Neuer Parameter: ; days remaining in logfile by cleaning/shorten logfile DAYSINLOG 2 (Aufgrund einer Idee von Werner Blatt) 1.3.2000 v2.02-gamma + UUCICO via TCP Unterstuetzung 10.2.2000 v2.01-gamma + Summen-Ausgabe im "regulaeren" Report Text (fuer daily Report oder manuellen Export ueber alle exportierten Eintraege). Neuer Parameter ; Append Totals MB received and sent in report text ; default: No ADDTOTALS Yes Beispiel: Total Mb received: 30K Total Mb sent : 0 25.1.2000 v2.00-gamma i UUCICO und BT2.60XE beta6 Funktionalitaeten funktionieren jetzt wohl hinrreichend ohne weitere Einschraenkungen der bisherigen Funktionalitaeten. Shift auf Gamma Status. Official v2.00-gamma release. 24.1.2000 v2.00-alpha2 + xe5,xe6 Freepoll Erweiterungs Erkennung (liefert zusaetzliche Zeilen zwischen Ring und Connect Message) (in Zusammenarbeit mit Werner Blatt) 23.1.2000 v2.00-alpha + add UUCICO support Additional Parameters in Logfile-definition: L07LOG d:\projects\binkhm\196\reps\uucico.log UUC 2:244/1111.99 ^^^^^^^^^^ ^^^ ^^^^^^^^^^^^^ | | fake uucp aka | UUC-type Logformat uucp-logfilename UUCP Log kann NICHT im Binkley-Log mitgeschrieben werden. Muss ein eigenstaendiges Log sein!! UUCP Type Logformat MUSS hinter die Log-Definition im Cfg angegeben werden. (Anregung durch Werner Blatt) 23.6.99 v1.96 * ich habe nun den Wert fuer die Parameteruebergabe der Lowlevel- FileOpen Funktion gefunden um die "aktiven" Binkley-Logs im Modus ReadOnly/Sharable zu oeffnen ... :-) Auf Hochdeutsch: der Update vom Mailer Log funktioniert nun auch im Background beim vom Mailer "angezogenem" Logfile ... kann also in einer Umgebung mit Backgroundtosser durch den Tossertask angestossen bzw. selbst ausgefuehrt werden. Dies duerfte insbesondere fuer die OS/2 Systeme von Bedeutung sein, nicht nur einmal am Tag ein Update laufen zu lassen, sondern jedesmal wenn eine Line Mails oder Files empfangen hat ... so kann die History-Database ziemlich aktuell gehalten werden, ohne dass ein OS/2 Mailer ein DOS Programm aufrufen muss .... (reported im Zusammenhang mit P24CVRT durch Oliver Kopp) * Der Gamma-Status der v1.95 kann nun wohl so langsam aufgehoben werden, nachdem das Programm ueber einen Monat stabil ohne Ausfallerscheinung im Produktivbetrieb lief .... 19.5.99 v1.95-gamma2 * und noch eine Korrektur zur "Spezialversion" BT2.60XE beta6: 16.5.99 v1.95-gamma * der Schnellschuss mit der 1.95-beta hatte zur Folge, dass keine "saubere" Zuordnung der Ring- und Connect-Zeiten mehr erfolgte (ging irgendwie bischen durcheinander). Habe daraufhin auf den Code von v1.92 zurueckgegriffen und die Besonderheiten der Zwischenzeilen zwischen Ring- und Connect der BT2.60XE6-beta einzeln aufgenommen. Jetzt funktionieren auch wieder die Zeitzuordnungen ... ;-) (reported by Werner Blatt) 1.5.99 v1.95-beta * einige Korrekturen zur Inbound/Outbound-Erkennung der BT2.60XE-beta6 Version (reported by Werner Blatt) 1.8.98 v1.92 + MAXREPFLEN und PAGELEN koennen nun fuer Interaktiven- und Batchmodus unterschiedlich konfiguriert werden -> neue Parameter: IMAXREPFLEN, IPAGELEN 6.4.98 v1.91 + BT 2.60XE/beta2/6 additional Log-Session Keywords Filter 19.7.97 v1.90 * Datenbank-Struktur-Upgrade. Erweiterung der Felder: Files Received: len 3 auf len 4 Kb Received : len 8 auf len 10 Files Sent : len 3 auf len 4 Kb Sent : len 8 auf len 10 nachdem in letzter Zeit immer oefters Sessions mit Datenmengen > 99 Mb zustande kamen ... * Anpassung der Anzeigen "Sent/Rcvd Bytes". Die Anzeigen erfolgen nun groesstenteils in Mb -> 99M Kb -> 999K 14.7.97 v1.85i * Beschleunigung der Summenanzeige des aktuellen Tages (es werden nur die Records des gewuenschten Tages gescannt) + Summenhistory (wird bei der daily Report-Erstellung geschrieben) Zusaetzlicher Logfile. Neuer Parameter: SUMHIS <[path\]filename> 13.7.97 v1.85h + noch weiterer Stuff to skip for display system information 8.7.97 v1.85g + noch weiterer Stuff to skip for display system information 3.7.97 v1.85f * kosmetische Aenderungen - Summenanzeige des "aktuellen" angezeigten Tages Aktuallisierung bei Tageswechsel in der Anzeige - Angaben in Bytes, Kb oder Mb je nach Groessenordnung 2.7.97 v1.85e * kosmetische Aenderungen fuer "bytes Recv" + "bytes Sent" in der Anzeige und im Report. 2.7.97 v1.85d + noch weiterer Stuff to skip for display system information 1.7.97 v1.85c + Additional Logentry to skip for Systeminformation (BT 2.60/XE Support Gamma 5) 29.6.97 v1.85b + Add BT 2.60/XE Support Gamma 5 (BTVER -> 26XE5) Es wurde mal wieder reichlich an den Logeintraegen gebastelt ... 17.3.97 v1.85a * Fixed jede Menge zusaetzlichen Log-Stuff bei 260XE Version: - Local Mail on Hold: - Remote Mail on Hold: - Id=.... (nur bei "manchen" ISDN-Lines) - Unable to open (null). 5.2.97 v1.85 + Add BT 2.60/XE Support (BTVER -> 260XE) Noch kein Test mit FAX-Receive, BBS-Caller ! * Fix in Indexroutine zur Ermittlung des Jahres beim Wechsel vom 31.12. zum 1.1. des darauffolgenden Jahres. Wurde eine Session am 31.12. erst am 1.1. des darauffolgenden Jahres mittels -A in die Database aufgenommen, erhielt dieser Eintrag bereits den Timestamp mit der Jahreszahl des neuen Jahres. Somit tauchten in der Database immer diese Eintraege mit jedem neuen Tag als letzte Eintraege auf. Als Datum trugen diese Eintraege aber den gueltigen Tag und Monat. 8.8.96 v1.83 * Fix in QScan() In some cases QScan returns correct Line starting at pos 2. (see also fix in updcheck und p24cvrt) 10.7.95 v1.82 * Add some more Connect identifiers (BT 2.50/EE) im Zusammenhang mit ISDN calls/call ins 4.1.95 v1.81 + Add -s calling parameter for starting hour for reports (binkhm -r -d -s only available in batch mode). 4.1.95 v1.80e * Cosmetics with "BINK End of connection attempt" entrys handles as No Carrier. * reduce sum overflow in the viewer by dividing to Mb values up to 999 Mb. * also fix sent and received Kb values overflow with more than 99 Mb 29.12.94 v1.80d2 + Add BT 2.50/EE // MAX extended Modem-Informationen Support zwischen und Meldung (BINK Data, etc.). (reported by J.Weber) 28.12.94 v1.80d * Extended BINK Ring ... Erkennung (im Zusammenhang mit ISDN Lines) 9.8.94 v1.80c + Environment-Variablen BINKLEY oder BINKHM werden ausgewertet, so dass BINKHM von ueberall aus aufgerufen werden kann. Im definierten Laufwerk/Pfad sucht BINKHM nach einem Configfile und legt hier auch die Databases und das Stampfile ins Rootdirectory dieses Laufwerks. 9.8.94 v1.80b * Stephan Grosse reports: Ungewoehnliche "BINK Connect" <-> "BINK Connection terminated" Kombination fuehrte zu einer Endlosschleife. Fixed. 17.5.94 v1.80a + Verknuepfung BBS-RA Analyse unter BT 3.0#xx * Viewer cosmetics fuer Systeme die mehr "Off-Line" sind ... ;-) (Anzahl der Historyeintraege < 20) 27.4.94 v1.80 * 1 more Viewer cosmetic 25.4.94 v1.80 + Database Structure upgrade (automaticly -> v1.8). * Problem im Zusammenhang mit History-Database-Maintenance, wenn die Database bereits durch einen anderen Task geoeffnet ist, konnte in dem Task, in der die Maintenance durchgefuehrt werden sollte die Structur der Database nicht mehr ueberprueft werden und fuehrte zu einem Structure-Version-Upgrade 1.0 auf 1.10 auch wenn eine Datastructure Aenderung nicht noetig waere. Fixed. * Viewer cosmetics 20.4.94 v1.7à3 * Fixed special "ring,connect,ring" condition + Erweiterte Session-Ende-Erkennungen fuer BT 2.50/EE und BT 3.0#xx * Fixed some conditions, in denen bislang keine Sessionlaenge erkannt, bzw. berechnet werden konnte (duration) + add UNDEF Mailbox-Software-Support (Spawning BBS, Returned from BBS) Erweiterter Config-Parameter: BBSTYPE UNDEF + Add automatischen FileLaengen-Support fuer Reports New Config-Parameter: MAXREPFLEN [bytes] * Fixed Fax-Erkennung unter BT 3.0#xx (Endebedingung) * Fixed global special Receive FAX condition (-> '+Fcon'). * Fax-Support unter BT 2.50/EE wird NICHT unterstuetzt (see doc). 17.4.94 v1.7à2 + Add BT 3.0#xx Support (Russen-BT) + Add Transfer Kb Rcvd/Sent for BT 2.50/EE + 3.0#xx 15.4.94 v1.70à + Add BT 2.50/EE Support + Add MAX v2.00 Support RA-Support unter BT 2.50/EE doesn't functionaly. Send me your Logs for analysing RA-Support under BT 2.50/EE 23.3.94 v1.60á * Low-Level-Problem: noch 2 Sonderfaelle angepasst. Fehlermeldung in einer anderen Anwendung nach v1.6à3 Abschlusstest war auf einen Transferfehler zurueckzufuehren. 22.3.94 v1.6à3 * Low-Level Routinen neuerlich auf "Grenzsituationen" (Fileanfang,Fileende) hin durchleuchtet und modifiziert. Umfangreiche "incremental analyse" Tests. Damit duerfte das Problem "fehlender" Eintraege nun zu 99% "erschlagen" sein. Sollte doch noch einmal ein Fall bekannt werden, so erbitte ich die Zusendung des entsprechenden Logs ... 20.3.94 v1.6à1 * Probleme bei der Analyse von neuerlichen Eintraegen. Musste fuer die Analyse im Logfile rueckwaerts gelesen werden, (Stampposition annaehernd am Fileende und ein vielfaches der Buffersize) wurden etliche Eintraege nicht mehr "gefunden". Low-Level Routine fuer Rueckwaerts-Schritte komplett neu geschrieben. 17.3.94 v1.5à3 * Reports wonach es Schwierigkeiten unter DV-Fenster mit 500 Kb Hauptspeicher gibt konnten nicht nachvollzogen werden. Selbst Tests mit 450 Kb HS liefen noch klaglos (umfangreiche Tests). * Records, die im Viewer als geloescht markiert wurden, wurden trotzdem beim anschl. Report noch mit ausgegeben (ohne Verlassen des Viewers). Fixed. * Anscheinend wurde einige Eintraege in den Logs "nicht gefunden". add definierte Such-Methoden fuer Datensatz und andere Vergleiche. 16.3.94 v1.5à2 + Herausanalysieren von BBS-Usernamen bei aktiviertem SHOW_BBS. (klappt nicht immer, optimiert fuer BBS RA, fuer andere Mailboxprogramme benoetige ich erst einmal eine Reihe von Logs, um die analysieren zu koennen ... prinzipiell aber erweiterbar ...) + Auswahl zweier Reporttypen durch Configparameter (incl. aller zusaetzlicher Wahlparameter in der Config - Seitenlaenge, Spaltenbreite, etc.) 15.3.94 v1.5à1 + View Mode BT (erweiterter Systemname) (Configparameter VIEWMODE [FD|BT]) + Viewer Online Toogle Viewmode mit Alt+V * Fix der Tagessummen fuer Received- und Sent- Kb's * Report Angabe der Spaltenanzahl [68..132] (Systemname wird mehr oder weniger expandiert), Angabe des Datums nur noch in jedem Header. (Configparameter COLUMNS [##]) * Einige Verwirrung hat der "Balkenhintergrund" bei der Angabe des Filenamens gestiftet. Durch andere "Farbwerte" ersetzt. + Zusaetzlicher Schalter, der beim Analysevorgang aktiv wird, ob die zusaetzliche Systemadresse aus dem Systemnamen entfernt werden soll. (Configparameter KILLALTNO [Y|N]) + Fehlt eine gueltige Systemadresse ("0/0") wird, sofern eine im Systemnamen vorhanden, diese durch die Adresse im Systemnamen ersetzt. Funktioniert auch dann, wenn der zusaetzliche Schalter KILLALTNO auf Yes gesetzt ist. 14.3.94 v1.41á * weiterer Bugfix in Low-Level I/O-Routine, EOF-Erkennung * ueberarbeiteter BBS-Callers Erkennung und Eintrag + add Schalter fuer "No Carrier" und "Lost Carrier" * Erkennung weiterer Sonderfaelle 14.3.94 v1.40á * Bugfix in Low-Level I/O Routine, Pointer-Reposition * add one Binkley 2.59 EE specific Syntax + add receive FAX Erkennung (siehe Zusatzparameter SHOW_FAX in Config) + erweiterte BBS-Caller Erkennung (speziell fuer stark frequentierte BOX-Systeme) * Optimierung von Mailer-Connections und deren Erkennung (SHOW_BBS Yes Mode noch nicht weiter beruecksichtigt) * Fix debug function program waiting for key press 8.3.94 v1.30á + Viewer - einfache Editierfunktion: Delete Record DEL - Record loeschen, INS - geloeschten Record zurueckholen 7.3.94 v1.20á + Implementierung -Export Zusaetzliche Parameter fuer Config: PAGELEN,FORMFEED,TABTRENNER + Report auch von der Commandozeile mit dem Schalter -R aufrufbar (Type binkhm -? for details) * Spaltenbegrenzung fuer Reports auf 78 Spalten zur Ausgabe auf Laserdrucker, Einbindung in FTS-Messages 6.3.94 v1.12á - Erkennung diverser Inbound Sonderfaelle BINK No Dial Tone BINK Incoming call, dial aborted - Erkennung diverser weiterer Binkley-Logs Sonderfaelle FTS-0001 Session BINK Password-protected session - Viewer Kompatibilitaetsanpassungen 5.3.94 v1.11á - fehlende Indizes u.a. fuehrten noch zu einigen Abstuerzen. - einige Datumsfelder wurden fehlerhaft uebernommen: Date 2::3 Time ..03 5.3.94 v1.10á - some cosmetics 4.3.94 v1.10á - Statt Session-Ende wird nun Session-Beginn angezeigt - F2 Verbose Infos zur ausgewaehlten Session - Export in ASCII-File in Vorbereitung - Database Strukturaenderung (add System) Automatisches Upgrade von v1.0 Databases (bereits gespeicherte Daten werden in das neue Format mit uebernommen). 3.3.94 v1.01á - Ueberfuehrung in den á-Status - Database naming geaendert: now BINKHM.HM? - frei definierbare Farben fuer den Viewer - gegenueber einer der 1. Fassungen benoetigt BINKHM 1.01á fuer ein 300 Kb Logfile zur Voll-Analyse nur noch 37 sec. (386/33) (zuvor 156 sec. !!). 3.3.94 v1.00à - Allgemein gueltige Database Initialisierung - Fix der Session-Eintraege: - cosmetics am Systemnamen Eintrag - Multiline-Betrieb gleiche Logfilenamen in verschiedenen Subdirs Problem gefixt (wurde immer das Log des ersten Verzeichnisses ausgewaehlt) - wo ich mich noch nicht dranwage ... Auswertung des Environments BINKLEY und Auswertung des Binkley-Configs ... an und fuer sich keine Schwierigkeit. Ist nur mit 'nem Riesenaufwand verbunden, kostet nur unendlich viel Zeit und bringt vermutlich ausser der absoluten Logfile-Position keine weiteren Infos ... - QuickScan nach der naechsten Connection (statt bisher zeilenweise Abarbeitung) 2.3.94 v1.00à Anzeige: - View eingebunden - Keyboard Help - Shared Database incl. Aktuallisierung Analyse: - Add Parameter SHOW_BBS fuer Eintraege BBS-User - Skip des Zusatz Log Entrys das FD 2.20 und D'Bridge-Systeme erzeugen - Suche nach Dupe-entrys - Stamp-Methode greift nun auf die Daten aus dem Cfg. (gleiche Log-Names in unterschiedlichen Directorys moeglich) Reorganisation: - Reorg eingebunden - Reorg Stamp in die globale Stamp-Methode aufgenommen Allgemeines: - Shared Database-Zugriffsregelung neu definiert: Batch-Mode (Analyse) keine Warteschleife *1 manuell mode (View) User Waiting mit Abbruchsmoeglichkeit Reorg keine Warteschleife *1 *1 wird beim naechsten mal wieder versucht - Stamp-Methode nochmals ueberarbeitet (Austausch der alten Stampeintraege) - variable Buffersize fuer Low-Level I/O's - Problems bei fehlendem Stampfile und fehlender Databases nun wohl hoffentlich beseitigt 1.3.94 v1.00à Only Analyse: - weitere Modifikationen der Lowlevel-Routinen. - Auswertung der Logzeilen modifiziert - Database-Struktur erweitert. - Automatische Database-Neuerstellung falls nicht vorhanden. - Stamp-Methode auf Multilinebetrieb erweitert. 28.2.94 v1.00à Only Analyse - Erste Umsetzung; Analyse und Umsetzung von Logs - Auswertung des Configfiles, Uebergabeparameter - Auswahl der LowLevel-I/O-Methode Anpassung vorhandener Low-Level-Routinen zunaechst zur Sichtung der Logs - 1. Auswertung der gefundenen Logzeilen. - Database-Struktur entworfen. - 1. Entwurf fuers Stamping (z.Zt. nur Single-Line) 27.2.94 - erster Algorithmus fuer Analyse-Routine 26.2.94 1. erste Ideen fuer einen Historymanager unter Binkley Uebersicht aller Sessions aller Lines In- wie Outbounds auf einer Seite. 2. Soll Multiline-faehig sein (mehrere Logs auswerten koennen) 3. nachdem das COST-Log nicht sonderlich ergiebig war analysierte ich das "normale" Binkley-Log, das letztendlich die einzigste Quelle fuer eine gesicherte History hergibt. 4. Konfiguration von 99 Ports (1-99) per ASCII-Cfg und den zugeordneten Logs 5. Auswertung eines Environments zum Auffinden von Systemfiles 6. Das Programm sollte gleichzeitig analysieren als auch ausgeben koennen. BINKHM only Scrollfenster BINKHM -a analysiert das entspr. Logfile und wertet die neuesten Verbindungen aus. 7. Damit nicht immer das komplette Log durchscannt wird, wird ein Stamp genommen. 8. Database soll Multi-User-faehig (shareble) sein (gleichzeitig Analyse + Anzeige)