INETLOG.CMD JUST UPDATED!
|
INETLOG.CMD , by
Jerry Levy
and Chuck McKinnis
just updated and the archive (inetlg54.zip, 27,71K) was uploaded to Hobbes. INETLOG.CMD is a REXX Program
that extracts and totalizes daily and monthly connection times for calls made into
the ibm.net (IGN) gateway to the Internet. Inetlog.cmd accomplishes this by performing
an analysis on entries in the IBM Warp Internet Dialer's connection log file. The
output from this analysis is sent to the console (screen) and also saved to a file.
Getting started
After unzipping inetlgxx.zip, open an OS/2 window, navigate
to the
directory you unzipped to, run inetinst.cmd, and you are all ready
to go. To run INETLOG.CMD, either double-click on its icon, or in
an OS/2 Window type in INETLOG with its path if necessary. The first
time you execute the routine, it will ask for parameters to set up
the environment.
If the inetlog icon has become detached from INETLOG.CMD, run the
INETINST.CMD from the x:\INETLOG directory to update the desktop.
NOTE - If you run multiple OS/2 sessions from different partitions
and/or multiple dialers (such as TCPDIAL). we highly recommend
you point the log file setting on the logging page of the
dialer setup to a common log file to assure that you can
analyze all activity. You may need to merge the separate
existing logs into the combined log.
Read carefully the notes about messing around with the connection log.
You will need to run EOF2CRLF.CMD with the fully qualified names of the
input (the one you messed with) and output log files as parameters after
editing your new connection log.
Defaults and run options
RUN OPTIONS
The following are acceptable command-line parameters (case is
ignored and only the first letter is required). These parameters
can be overridden on a run by run basis only.
L<ogFileName>=connection log file name, default is the log
file pointed to by DIALER.INI or TCPDIAL.INI
Q<uiet> run without output to screen, default is to output
results to the screen
DEFAULTS
The defaults are stored in inetlog.ini and may be overridden
permanently with the following command line parameters.
I<niFileName>=ini file name of dialer, default is dialer.ini
or tcpdial.ini depending upon the dialer you use
O<utputFileName>=output log file name, default is inetlog.log
S<ummaryFileName>=summary log file name, default is inetsum.log
DataPath=path to output log and summary log, default is the install path \ DATA
D<isplayDailyReport>=display daily report? (Yes or No), default is No
P<auseAsScreenFills>=pause as each screen fills up? (Yes or No), default is
Yes
W<arnPercent>=percentage for warning on connect.log, default is 85
SPECIAL RUNS
The following are acceptable command-line parameters for special
runs. Only one of these can be used in a run and case is ignored.
CONDENSE to remove extraneous lines from connection log file
EOF2CRLF to replace any EOF characters added by using an editor
against the log file
WHATS NEW in versions 4.5 (4.6 after
a bug fix) thru 5.4?
CHANGES IN HANDLING RECORDS WITHOUT USER INFO AND CONDENSE
Records without user account and id information will be bypassed.
The condense function will retain the user account and id information
if present.
NEW SUMMARY LOG
Version 5.0 adds a monthly summary log and completely changes the way
in which monthly summaries are generated and maintained. The monthly
summary log will summarize monthly connection information by account
and userid and maintain that data across prunings of the connection log
by the dialer. If long histories of daily activity is not required,
this can significantly reduce the size of the connection log (see also
IS THE LOG FILE BIG ENOUGH?).
NEW DATESTAMP (Dialer v1.33, v1.45 and Later)
Versions 4.5 and 4.6 of inetlog.cmd represented a major change and it
is compatible with a new datestamp in the connection log file entries
that, starting with Advantis Dialer version 1.45 (also dialer version
1.33 distributed with Warp Connect), now indicates the year as well
as the month and day in log entries. Previous versions of inetlog.cmd
will not work with Dialer version 1.33, 1.45 or later-version
connect.log entries but version 4.5 and later WILL work with both
styles of date stamps, EVEN WHEN THEY ARE INTERMIXED in the same
connect.log file.
NEW UTILITY SUBROUTINES (Callable from OS/2 Command Line)
In INETLOG versions 4.5 and later you will find two new embedded
subroutines that enable you to modify your connection logfile to (1)
remove non-essential lines in the connection log file, in order to
shrink the size of the log file and (2) remove the eof characters
that you accidently got in there when you used the system editor
on the log file.
These subroutines both bring up rather complete on-line instructions
when you run them. But, DON'T RUN THEM UNTIL you've got INETLOG.CMD configured and
running normally first.
The respective command lines to run them in an OS/2 Window or
full-screen session are:
INETLOG.CMD condense
which allows you to remove unneeded lines in the connection log file,
which shrinks the logfile by about 80%. The summary file now used
in INETLOG makes the running of this option less necessary.
INETLOG.CMD eof2crlf
which is used to remove any errorneous EOF characters that may be in the
connection log file.
You cannot enter more than one of these arguments at the same time on a
single command line, meaning: you cannot do both at the same time.
They can be done as separate operations in any order.
NOTE: There is a tricky part to running these. It shouldn't be tricky
but since it involves reading the screens (especially the last one)
carefully as they come up, it poses a problem to most mortals. In the
last screen, you will be asked to press the "R" key to rename a
temporary file, which has the changes you've just made, to the name of
your connection logfile. If you just press enter, and don't press "R",
your old connection logfile is not updated. You must press "R" to keep
the changes made by the CONDENSE subroutine.
SUPPORT FOR DIALER.EXE AND TCPDIAL.EXE (5.3)
Versions 1.69 and up of the IBM supplied dialer uses TCPDIAL.EXE.
Inetlog.cmd supports the TCPDIAL.EXE and its associated ini file,
TCPDIAL.INI. If you are installing for the first time, you will be
prompted to identify your dialer. If you are already running InetLog,
you need to run the inetlog.cmd with the parm "i=tcpdial.ini" in order
to update the inetlog.ini control file. Once inetlog.ini has been
updated, you may remove the "i=" parm from the settings. Even though
you switch dialers, your summary log will be maintained and updated.
REMOVED CODE TO FIX DATES IN OLD LOGS (5.4)
If you are still running an IBM supplied dialer that does not put
the 4 digit year in the log, you probably have more problems than
we could ever hope to fix.
Copyright notice
This program is copyright by us (1995, 1996, 1997, 1998).
We intend it
as Freeware, and it may be distributed freely. We only ask that if you
build upon it or modify it and distribute a modified version, you credit
inetlog and us as a source. Naturally, if we can be of help in a
modification, we will be pleased to do so. No warranty of
merchantability or fitness for any purpose of any kind is expressed or
implied.
OTHER THINGS TO DO OR CHECK
You must, of course, have set up your IBM IGN Dialer for logging. Upon
installation of the Internet Highway stuff supplied with the IBM Warp
Bonus Pak (or if you installed Warp Connect you probably installed the
Internet stuff when you installed TCPIP), a small connection logfile is
enabled.
The Logging Page of the Settings Notebook for the IGN Dialer allows
you to enable or disable logging and to change the size, name and
location of the logging file. The logfile can be set anywhere in size
from 5K to unlimited size. 100K will preserve information on about 300
logins. The summary facility should allow you to run with a setting of
10-20K. If your Dialer doesn't have a Logging Page in the Settings
Notebook, get the latest Dialer upgrade (go to the IGN Customer Service
folder to go about downloading it). The CONDENSE option of inetlog.cmd
will allow you to reduce the size of your connect.log file by from
75-80% by stripping out un-needed lines.
How INETLOG.CMD works
The IGN Dialer log (a text file you will want to examine with
your
OS/2 System Editor if you are the least bit curious) stores connection
times as shown below. Such lines are added to the log file upon each
disconnect. The account and user ID for each connect are stored in one
of the lines preceeding this one; I could have created individual
reports for each user for each account (my machine at home, e.g., has a
single account but two users), but I decided not to. If this is
desirable to do, let me know.
1995/11/15 19:18:07 Disconnected after 00:05:59 0 errors 0 discards
(the date is expressed as 11/15 with older dialer versions)
Using the RexxUtil function SysFileSearch, we look for all lines in
the log that contain the string 'Disconnected after'. We parse
those lines to extract out the month and day of each connection, doing
arithmetic on the connect times. We convert hours:minutes:seconds to
minutes, and sum these connection times on a daily and on a monthly
basis. At each entry corresponding to a new day and/or month, we take
the previous day/month's times and store them. Then after all lines
have been analyzed, we output results: all daily figures first, and
monthlies last.
The program logic is straightforward, and you should be able to adapt
this for deciphering other types of .LOG files as well.
MORE ABOUT THE INTERNET DIALER'S LOGGING FILE
Each dialer or service will have its own provisions for logging and may
or may not create a logfile on the client machine. Or even if it does,
the logfile may not be readable as a simple ASCII text file. This
discussion concerns only the logging file created when the IBM Warp
Internet Dialer is used. That dialer creates an ASCII text file as its
connection logfile.
What follows, incidentally, might only be applicable to the IBM Warp
Internet Dialer and its connection logfile, and how it signs on to IBM's
IGN gateway. Nevertheless, if you use a different dialer and even
if the file is not a simple text file, the generalizations here may be
useful in adapting INETLOG.CMD for the dissection of your logfile
assuming one is created on your machine.
Below is an excerpt (modified for purposes of illustration) from my own
logfile, connect.log, created as part of my activity on the IGN
system using a fairly vanilla installation of the Information Highway
BonusPak after installing OS/2 Warp.
DO YOU HAVE A LOGFILE?
A logfile is only created and maintained if the Logging Page of the
Dialer Settings Notebook has the Logging Enabled box checked. That is
the default. You ought to at least see if yours is set up to log. It
is possible that the dialer distributed with Warp did not have a looging
page in its Setup Notebook. If yours doesn't, you may (you do) want to
double-click on the Customer Assistance object in the IBM Internet
Services Folder in with the IBM Internet stuff to download the latest
version.
CHECK THE LOG PATHS
The path and name of the logfile defaults to x:\tcpip\etc\Connect.Log
where x is the drive you selected when the Information Highway BonusPak
was installed. Usually, x will be the c drive. Warp Connect and Warp
4 puts it in the x:\mptn\etc folder rather than the x:\tcpip\etc
folder. You will note from the logfile excerpt that the date is in the
American style: mm/dd. There was no year until Dialer version 4.5.
Lack of a year was somewhat of a bummer. It prevented sorting by date
over periods that extended over more than one year.I kept my logfiles
separate by year: one for '94, one for '95, etc.
THIS THE LOG FILE BIG ENOUGH?
I don't remember what the size of this file defaults to; I think it
might be 20K. With the summary file, this is probably more than
enough for most users. As mentioned, the CONDENSE subroutine in this
latest inetlog.cmd program will strip out unneeded lines, resulting in
about a 75-80% reduction in logfile size.
IF YOU DELETE YOUR LOGFILE
If you delete the logfile but leave logging enabled in the Settings
Notebook, don't worry. You will only lose the information gathered
since the last execution of INETLOG, and a new logfile will be
re-created the next time the Dialer has dialing activity. Each time it
is created from scratch in this way the identifying header bounded top
and bottom by dashed lines is created anew.
If you run INETLOG from you startup folder with the QUIET parameter,
you could delete the dialer log immediately afterward and not lose any
summary information.
Typical start of Connect.Log (first few sign-ons)
(NOTE: Older Dialer versions present dates in the form of 11/13 instead of 1995/11/13)
---------------------------------------------------------------
IBM Global Network - Internet Connection Log
--------------------------------------------------------------
1995/11/13 14:05:56 -------------------------------------------
1995/11/13 14:06:02 usinet jlevy dialed 16172476754 14400
PROTOCOL: LAP-M
COMPRESSION
1995/11/13 14:06:02 Gateway:IBMB3YA0 Port:29 129.37.80.2 assigned 129.37.80.157
1995/11/15 19:02:14 -------------------------------------------
1995/11/15 19:02:20 usinet jlevy dialed 16172476754 14400
PROTOCOL: LAP-M
COMPRESSION
1995/11/15 19:02:20 Gateway:IBMB3YA0 Port:17 129.37.80.2 assigned 129.37.80.145
1995/11/15 19:08:38 Disconnected after 00:06:20 0 errors 0 discards
1995/11/15 19:12:04 ------------------------------------------
1995/11/15 19:12:10 usinet jlevy dialed 16172476754 14400
PROTOCOL: LAP-M
COMPRESSION
1995/11/15 19:12:10 Gateway:IBMB3YA0 Port:23 129.37.80.2 assigned 129.37.80.151
1995/11/15 19:18:07 Disconnected after 00:05:59 0 errors 0 discards
End of the Connect.Log Excerpt
ELEMENTS IN THE CONNECTION LOGFILE
-For each dialup, a dialup line of text is created, with a date and
timestamp, and a bunch of dashes.
-The next line is an ID line and has date and timestamp plus account
name (usinet for IGN), userid, number dialed, and connect speed.
other lines may be blank, have protocol or compression mode indications,
etc.
-Some lines down from the ID line is the Disconnect line with date and
timestamp, and the duration of the connection. Duration-time -- the
timeon -- follows as the next word after the magic string 'Disconnected
after'.
-In-between the ID line and the Disconnect line may be a blank line, a
protocol line, another blank maybe, and something about compression. If
protocol or compression modes or modem setups are different, I believe
the number and content of lines interposed between the ID line and the
Disconnect line may vary. I don't know that for a fact as I haven't
tested it.
But note that for my very first dial-in there is no disconnect line
below it but another dial-in line appears. That is either because I
hung up before signing on, or maybe because it was my very first time I
might have been registering or doing something that wasn't billable.
Whatever, each dial-in does not imply there will be a disconnect line
following it. The reverse is a different matter: for each disconnect
there will be a dial-in line preceeding the disconnect.
YOU CAN EDIT THE LOGFILE, AND A CAUTION
I edit my connect.log file(s) because I am logging to two machines and
periodically I merge entries from one file into the other by copying and
pasting individual sets of lines in proper chronological order. I do
not sweat that a blank line may be missing or shifted. Inetlog.cmd
doesn't care about time of day ordering since inetlog.cmd sums all
connection-times over each day. If days are out of order, though,
inetlog.cmd is not bright enough to handle that. If you have February 5
sandwiched in the middle between two sign-ons for March 13, you will get
one summary for March ending with the first of the two March 13th
signons, another for February, because it will see the February 5
signon, and then another summary for March beginning with the second
March 13th signon.
THE CAUTION, AND THE EOF2CRLF OPTION
On one occasion when I merged two files, I found that the totalizing did
not take into account entries near the end of the connection logfile.
On looking into this more closely I found that I had copied and pasted a
section from one logfile to the end of another; but at the end of the
logfile I was adding on to was a 1Ah byte. My new additions were tacked
on AFTER the 1Ah byte. I was doing this in Microsoft Word. The 1Ah (26
decimal or Control-Z) is an end-of-file character and I am guessing that
the program never got past that. By copying the 1Ah to other places in
the connection logfile, I could make inetlog.cmd think the file ended
there, though word processors were smarter. By the way, the 1Ah is
visible as a small square when the offending logfile is read as a text
file into MS Word (the small square is MS Word's printable stand-in for
a non-printable character). The End-of-File byte is not visible when
the same file is read into the IBM OS/2 System (text) Editor, but it is
there just the same. I remember way back in the days of CP/M that an
End-of-File character really meant something! Ah well, progress!
Bugs, problems
None that I'm now aware of. Until this version, it would crash
if you
had more than 100 signons in a day or a month, but that is now fixed.
If you have a strange failure after the program has been working well,
open the connect.log file in your system editor and look for strange
connection times. I found that negative correction times crashed it
(you'd get them when you did a clock reset from summer-time to
winter-time while on-line), but that is now caught.
If you modify the program, the fact that I save output till the very end
makes debugging harder, and the error-trapping with the signal calls can
be problematic as well. Also comment out or turn off all of the signal
calls until your mod works as planned. This may make it easier to spot
where a modified program is going south. Then when you've made and
tested your changes, build error-trapping back in with the signal calls
re-enabled.
CONTACT:
Chuck McKinnis, Sandia Park, NM (mckinnis@ibm.net)
Jerry Levy, Marblehead, MA (jlevy@ibm.net)
@Macarlo, Inc.
@Macarlo's Shareware & Web
OS/2
Java Lobby Member
Java Site Accredited
[TOP]
[HOME] [INDEX]