ReadMe.1st from INETLOG3.ZIP 18 Mar 1995 Jerry Levy JLEVY@IBM.NET
WHAT IS INETLOG.CMD?
INETLOG.CMD is a REXX Program that extracts and totalizes daily and monthly connection times when signed on to IBM.NET, the IBM Advantis gateway to the Internet. INETLOG.CMD accomplishes this by performing an analysis on entries in the IBM WARP Internet Dialer's connection log file (CONNECT.LOG). The output from this analysis is sent to the console (screen) and also saved to a file.
DEFAULTS
By default INETLOG.CMD expects the connection logfile to be c:\tcpip\etc\connect.log, and it defaults to c:\tcpip\etc\file.$$$ as the file to which output is saved to disk. These defaults can be changed -- and must be -- if you havea different path to your connection logfile or it is named other than connect.log, or you want the output saved to disk to a filename or path different than indicated.
The program defaults to pausing after each screen of data is displayed. This can be changed so data will scroll without a pause.
An equate is provided that may be set to enable/disable the use of PM-style dialog boxes to select connection log or output filenames other than those set as defaults. This may be particularly useful if you are analyzing a colection of connection logfiles from different machines and have either named them differently or stored them in different locations. The default is to disable the use of these dialog boxes. To enable them, you will need to have available three files from the IBM Employee-Written-Software package, VREXX2.ZIP, which are not included in this distribution. See section on VREXX2 below to learn more about this free package; see also the Getting Started section, below. It is recommended you download VREXX2.ZIP and install it, and at least try INETLOG.CMD with the VRexx dialog boxes enabled.
CHANGING THE DEFAULTS
There are four equates near the start of the program you may alter. Simply edit them with a text editor such as the IBM System Editor. They are set as follows in this distribution. For the first two you MUST use the quotes as indicated; quotes are preferred (good programming) but optional for the other two.
log_file = "c:\tcpip\etc\connect.log" (path/name of connection logfile)
output_file = "c:\tcpip\etc\file.$$$" (where to save output to)
Use_VRexx = "NO" (PM-style boxes to prompt for filenames)
one_screen_atatime = "YES" (Pauses each screen)
Setting Use_VRexx = "YES" requires that you have available DEVBASE.DLL, VREXX.DLL, and VREXX.EXE from the VREXX2.ZIP package and that they are installed as described in the Getting Started section, below.
Please pass on comments, suggestions, problems to JLEVY@IBM.NET
I would be more than happy to try to adapt this to the interpretation and summary of other types of logging files.
-Changed all rounding to nearest .01 minutes: Advantis calculates online time to
nearest second, and .01mins is quite close enough.
-Use_VRexx equate was added: bypasses VRexx if not = "YES"
3.0 18 Mar 95
-Corrected output filename bug introduced into 2.0
-Added pausing to prevent scrolling of output off screen
-Added to documentation
-Added EOF2CRLF.CMD to the package for stripping out 26d (^Z) end-of-file characters (refer
the section on editing the connection log file)
-Changed distribution package. VREXX2 components not included.
NOTE: When the VRexx equate is left at its default of "YES" this program includes calls to VREXX functions, which may be obtained in the IBM Employee-Written-Software package of VREXX2.ZIP. VREXX2.ZIP is a quite nice package, and free, and Copyrighted by IBM.
The entire VREXX2.ZIP package can be downloaded from the IBM PCC (PC COMPANY) BBS at (919-517-0001) or from the OS/2 Shareware BBS (703-385-4325) or from any of the several BBS's that focus on the OS/2 world. It can also be downloaded off the internet by anonymous ftp to software.watson.ibm.net, where it can be found in the pub/os2/ews directory. Other anonymous ftp sites that carry it are hobbes.nmsu.edu (os2/ibm/ews directory), ftp-os2.nmsu.edu (os2/ibm/ews directory), and ftp.cdrom.com (pub/os2/ibm.ews directory). VREXX2.ZIP includes a 49-page manual, an on-line .INF help file, and demo programs.
INETLOG.CMD and this README.1ST file are Copyright 1995 by Jerry Levy. INETLOG.CMD and README.1ST may be used and distributed freely without restriction. NO WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PURPOSE IS IMPLIED.
1. If you have made sure that the log_file and output_file equates (see above) are correct in INETLOG.CMD (or if you've changed them to correspond to your setup), 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. INETLOG.CMD may also be run under PMRexx by typing in PMRexx INETLOG (again with its path if needed).
If the OS/2 window does not stay open after everything scrolls by, go into the INETLOG.CMD Settings Notebook, then to the Sessions Page, and de-select "Close Window on Exit". If the inetlog icon has become detached from INETLOG.CMD, open the INETLOG.CMD Settings Notebook to the General Page, and drag INETLOG.ICO over the icon that appears on that Settings Page.
2. If you have the VREXX2 files available, edit the Use_VRexx equate in INETLOG.CMD to Use_VRexx = "YES" and then the surest way to proceed is to place INETLOG.CMD in the same folder that contains the VREXX2 files. No matter where that folder is placed, double-clicking on INETLOG.CMD will start the program properly. If the OS/2 window does not stay open after everything scrolls by, go into the INETLOG.CMD Settings Notebook, then to the Sessions Page, and de-select "Close Window on Exit". Shadows of the INETLOG.CMD file can be placed anywhere you like.
You can also copy both VREXX.EXE and INETLOG.CMD to a utility directory included in your config.sys PATH statement, and then copy VREXX.DLL and DEVBASE.DLL to a directory specified in your config.sys LIBPATH statement.
OTHER THINGS TO DO OR CHECK
You must, of course, have set up your IBM Information Highway Internet Dialer for logging. Upon installation of the Internet Highway stuff supplied with the IBM Warp Bonus Pak, a small connection logfile is enabled. If you installed the tcpip folder to other than to C as the root drive, or if you changed the location or name of the connection logfile, you will need to edit the log_file equate in INETLOG.CMD. You should also, while you are editing INETLOG.CMD, decide if the output_file should stay as defaulted (c:\tcpip\file.$$$)", and the same for scrolling (the one_screen_atatime equate).
The Logging Page of the Settings Notebook for the IBM Internet 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. Mine is set to unlimited; I plan to periodically save a back up, and I periodically will clean out old stuff. If your Dialer doesn't have a Logging Page in the Settings Notebook, get the latest Dialer upgrade (go to the Advantis Customer Service folder to go sbout uploading it).
The IBM Dialer CONNECT.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.
11/15 19:18:07 Disconnected after 00:05:59 0 errors 0 discards
Using the RexxUtil function SysFileSearch, we look for all lines in CONNECT.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.
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 Advantis 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 from my own logfile, connect.log, created as part of my activity on the Advantis 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 PATH
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. You will note from the logfile exerpt that the date is in the American style: mm/dd and that there is no year. Lack of a year is somewhat of a bummer. It prevents sorting by date over periods that extend over more than one year. Eventually, my logfiles will be: one for '94, one for '95, etc.
IS THE LOG FILE BIG ENOUGH?
I don't remember what the size of this file defaults to; I think it might be 20K. I changed mine first to 200K and then to unlimited. 100K will store information on about 300 logins.
IF YOU DELETE IT
If you delete the logfile but leave logging enabled in the Settings Notebook, don't worry. 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.
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 = Advantis), 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 as I do my copy-and-paste. All I care about, really, is that the disconnect lines are in proper chronological order. 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 PROGRAM
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!
Included in this package is a small Rexx program that strips End-of-File characters and replaces them by a carriage-return & linefeed combination. The program is called EOF2CRLF.CMD and has the syntax
eof2crlf infile outfile
where infile is the input file, e.g., connect.log, and outfile is whatever you want to call the resulting stripped-of-EOF's file. This program does not stop when it encounters an E-O-F.
MISCELLANEOUS MUSINGS ABOUT THE LOGGING FILE
I mentioned above that lack of a year in the datestamps was a bummer. That is because if a year were available, different connection logfiles could be combined by concatenating all the files in whatever order, and then sorting the lines in that new file thus created. INETLOG.CMD could then analyze that with no sweat. If you do try this, by the way, the DOS and OS/2 SORT functions are limited to files of 64K or less. You'd ned a separate sorting program.
As stated earlier, INETLOG.CMD finds lines containing the string: "Disconnected after", going after word 1 in that line for the date and word 5 for connection time. If an invalid file is analyzed by INETLOG.CMD but it contains the words "Disconnected after" (e.g., this file you are reading), you may generate a line or a few lines before an error trap knocks you out. For this file, the first two "Disconnected after" strings are in lines that have valid first and fifth word moieties which would compute correctly, but the others don't, and a fatal error occurs before anything is output. I felt that was an OK situation: I didn't bother trying to anticipate things like that in the error traps I set up.
BUGS, PROBLEMS
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. My suggestion is to modify the program after first making sure the Use_VRexx equateis set to "NO". 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, and finally re-enable the use of the VREXX functions if you are using VREXX2.
In arriving at the updates, I found that if I'd screwed up and the program did not exit VRexx properly, either INETLOG.CMD would not execute, or it would not startup properly. AND on trying to shut down OS/2, OS/2 would not always shut down correctly. Rebooting returned all flow to normal.
