XFRTOOL v4

XFRTOOL, XFR.LOG, and RIC.LOG,  are copyright 1987 by AB17/HOST
Systems of Dayton, Ohio.  The XFR4.BAS program may be altered
for accuracy of the mathematical algorithms only and may not be
distributed as a higher version unless such changes are in an
associated DOC file.  All such alterations should be made only
with the express consent of the authors of the program.  No
changes may be made to the XFR.LOG or RIC.LOG output files also
referred to herein as "screens", at all, except for local use
and display. Likewise, no additional data may be entered or the
location of any of the data items. If changes are made to the
screens name the library differently, take credit for all the
work done here, and suffer the consequences.

PURPOSE:

XFRTOOL provides the RCP/M sysop a method of analyzing two LOGS
formerly of little use to anyone except as a curiosity.  With
this single program you can quickly make more than just a guess
as to the use and usage of your system, as well as be informed
of your users most common hours and file transfer habits.

Additionally, these two screens can be quickly converted to a
COM file using TXT71 or NOTE2 for the (normally A0:) system
drive of the RCP/M so that all users can also find useful
information from them also. You can keep a previous month XFR
and RIC program as well as a cumulative stats file on-line at
all times - there is no real limit to the size of the files
the programs will analyze except perhaps the limits of your
operating system!

PREPARATION:

XFRTOOL requires COPIES of two files on the default drive:
KMD.LOG and the CALLERS file (preferably PBBS378 or higher).
The output files, XFR.LOG and RIC.LOG, normally take up 2 to
4k each on a 2k block system.  There are no intermediate files
as with previous versions - all calculations are done entirely
in memory in a cumulative manner and performance is much much
faster than previously, especially for really long files.

XFR4.BAS requires some alterations to properly run on your
system.  Check the CLS$ variable to make sure it is ok for what
you have - distribution = Kaypro machine.  Canadian and other
countries using the DD/MM/YY format for dates should look at
the KMD.LOG input starting areas for starting locations of
these variables. Another area to look at closely begins with
the read in of the variable "B$" from the CALLERS log.  Make
sure the length of each record is compatible with your
CALLERS file.  Some PBBS users have HAKked the "@" out of the
CALLERS file for extra characters in the user's names - check
the starting location for everything that follows this if you
have done this or something similar.  Make sure you enter the
2 or 3 character indicator for your state or province or you
will end up with all out of state or all local calls and
screen funnies...
 
BARFIES:

XFRTOOL does not like high bits in either the KMD.LOG or the
CALLERS file.  KMD handles high bits just like Wordstar - if
they are there when the file was transferred to disk then
they are in the file. The only way to get rid of them is to
use FILT7 or an equivalent PRIOR to using XFRTOOL.

The CALLERS file for PBBS will normally contain a character at
the head-of-file which must be removed as well as all the null
characters that precede each record. The rule here is edit first
and then use FILT7.
 
It should go without saying that both input files MUST be
squeaky clean or the statistics will be meaningless or even
worse - misleading.  The biggest offenders for the KMD.LOG are
KNEW and Wordstar edits. For CALLERS it is the method of
input that is usually the culprit - let's face it folks lots
and lots of users can't read what is in front of their face so
unless you stay on top of your CALLERS file or are willing to
set down and edit it for an hour or so each month this program
won't give you good stats.  It would be nice to have a "smart"
program that did all these neat things with a single command
but first we have to educate the programs that made the input
files...
 
ODOMETER:
 
XFRTOOL runs as two connected modules with XFR.LOG output as
the first product and RIC.LOG as the second. Throughout the
operation of the program you are kept aware of the current
status with an output line indicating the current date and
the record number the program is analyzing. You may stop the
program at any time with ESC or if under MBASIC with ^C. All
files will close before the program stops.  If you are having
problems with the program watch the status line first all the
way through - XFRTOOL will output erroneous data or DIE if
the two files are not COMPLETELY sequential and it WILL NOT
cross over years.  If you thought you started with July and
all of a sudden it is March chances are you have trouble...
 
CRYPTOANALYSIS:
 
XFR.LOG - Shouldn't be any terms here that are confusing. You
get basically two columns or rows of information, one with
the raw totals for each category and then one of the same
data as a percentage of the total.

RIC.LOG - Uses the XFR.LOG as the source for several items of
data which have confused some individuals not versed in the
acronymics of computercountry.  In the upper left-hand corner
is a data element named "CPH Factor".  This is the "Calls per
Hour" for the system for the period of time analyzed. See the
source for the formula.  In the upper right-hand corner is a
term "XFR Factor".  This is the "File Transfer Factor" and is
derived by taking the total hours the system was in a file
transfer mode from the XFR.LOG and dividing this time by the
total time the system was in an "active" mode. Note that an
AWFUL lot of things affect these factors. It is possible for
example to exceed the the total time on-line of CALLERS in
XFR.LOG with heavy KNEW entries.  Also in the upper right
corner is the term "utilization".  This is derived with an
XFRTOOL subroutine taken from the public domain program oft
called TWODATES or something similar - it determines the days
between two dates.  "Utilization" simply means the percent of
time the system was in an active state for the period. If you
were down for any length of time or the power went out then
this one is meaningless. If your system does not log your time
it is misleading (mine does).

WARNING: For any of these last three mentioned factors the
two files should BOTH be from the same period - anything else
would be meaningless.  Operators having two KMD logs and only
one CALLERS file I'll leave it up to you to figure out the
mechanics of the matter....

The rest of RIC.LOG is pretty much like XFR.LOG and should
not require any further explanation.
 
APPEARANCES:

Neither XFR.LOG or RIC.LOG were meant to be used as Bulletins
or INFO files inside of a BBS. As 23-line screens they were
developed expressly for use as a COM or TXT file on-line in
the system drive of the RCP/M. However if you insist on using
them inside of the OS then please insert a carriage return in
the first line so that it doesn't append itself to the last
PBBS command.  You may want to remove one or more of the
"---" lines so that they will show without the "[more]" key
interfering with the stats if you do this.  Note that with
PBBS it will appear ok without the CR if you run it LOCAL but
take a look at it remote (yech..).
 

PROBLEMS:

These programs have received wide-spread use since their
initial release in March of 1987. To date the calendrical
routines seem solid, however, the foibles of calendars and
computers in tandem are widely known so it is not impossible
that a problem will turn up in the future. Random two-week
samples from two systems were analyzed manually as test data
as well as donated older KMD and CALLERS LOGs (thanks to Al
Hawley and others). Additionally, converting the formally four
programs to one required re-use and alteration of some names
and terms so it is possible a bomb is in there somewhere...


AUF WIEDERSEHN:

Thanks to all who have contributed to the development of this
program including Norm Beeler and Peter Essl as well as Ian
Cottrell whose threats of writing something better have been a
constant spur these last few months.

Tom Ensminger
AB17 Remote Systems
[513] 879-6263
6 September 1987