

NOTE:  This diskette contains three executables of the exact same COBOL
       program.  There is a standard DOS executable, a 16 bit OS/2 1.x
       executable and a 32 bit OS/2 2.x executable.

       Each of these programs uses the same facilities to perform indexed
       I/O.  Therefore you CAN use these programs to benchmark performance
       differences between DOS, DOS within a Microsoft Windows DOS Box,
       DOS under OS/2 1.x, DOS under OS/2 2.x, DOS under Win-OS2, OS/2 1.x
       and OS/2 2.x systems.

       The next release of this benchmark will support DB2/2 tables.  This
       can not be directly related to the timings generated by the above
       environments, but will allow you to achieve an idea of the scalar
       needed to project performance under DB2/2 for a given set of I/O
       requirements.






                   Contents of this Diskette:

    1.    Disktest.txt - This read me file.
    2.    16bit Subdirectory - 16 bit OS/2 1.x files
          a.    Disktest.exe
          b.    Disktest.inp - input execution parameters
    3.    32bit Subdirectory - 32 bit OS/2 2.x files
          a.    Disktest.exe
          b.    MFRTS32.DLL, run time DLL necessary for execution
          c.    MFCLIB.DLL, run time DLL necessary for execution
          d.    Disktest.inp - input execution parms
    4.    Dos Subdirectory - DOS programs
          a.    Disktest.exe
          b.    Disktest.inp - input execution parameters

Disktest is a single cobol program which uses BTRIEVE to create and
indexed file of the specified amount of 80 byte records.  This file is keyed
by sequential record number with a key of 9 bytes long (left zero filled
display numeric).

Upon completion of the creation of this dataset the program then turns
right around and performs the requested number of random read/rewrite
pairs.

There are a few things to consider during this test.

First, the question is - Is this test of any value.  The answer is complex
but the short answer is yes.  Standard transactional applications - as
opposed to batch programs, are typically heavy users of the random read,
update and rewrite record type.  This means that you can use this
program to determine the maximum amount of I/O activity that a disk
can handle in a transaction environment.

Second, you can also run this program against two or more disks simultaneously.
This test will tell you two things about the system.

1.      How many physical I/O's per second the disk can support.
2.      How much system overhead is involved in processing the I/O
        requests.  This can be calculated by computing the reduction
        in physical I/O's on each disk when more than one disk is
        being tested.

Obviously you can take this to the max and try it on a server with
25 hard disks.  This would tell you just what you can expect from your
hardware.

Third, you can evaluate the performace of the disk caching, including lazy
writes.  Running this with different cache sizes and with lazy writes
turned on and off will tell you a lot about your system performance.

Fourth, if you wish to execute multiple tests you may need to delete
the files disktest.dat and disktest.idx before executing the second
and following tests. You must delete the mentioned two files if you
wish to change the number of records in the file. For instance,
the first parameter in the disktest.inp file tells disktest how
many records "are to be/or have been" loaded into the disktest.dat
file. If you are changing the value of this number, then the two
datasets must be deleted.

This is necessary because Disktest only creates the datasets if
they do not currently exist. This allows multiple random access tests
without having to recreate the datasets.

I am not so sure that this was a good design, but it did seem
like a smart move at the time. Now however, it is appearing to be
more of a nuisance.  Sorry about that.

---------------------    How to use the program    ---------------

Disktest reads in a dataset named disktest.inp which contains two
numbers in a fixed format.

The first number indicates the number of 80 byte indexed records to create.
The second number indicates the number of read/rewrite combinations to
perform.  The following line indicates the format of the input record:

NNNNNNNNN RRRRRRRRR

Notice that NNNNNNNNN is 9 digits long, and so is RRRRRRRRR.  That is the
size of the two fields.  The following is what I use to test the program
with:

000001000 000001000

This will create a 1000 record file, and perform 1000 random read/rewrite 
combinations.  Note that both of these values are way to small to get
valuable results - The entire file could fit in the cache, and if lazy
writes were turned on the benchmark would really fly.

I recommend that you create at least 50000 records, and I suggest that the
file be about 10% of your hard disk in size (80 bytes per record plus 
30 bytes overhead - so 110 bytes per record).

I also recommend that you perform from 10000 to 50000 random reads/rewrites.

Remember that you will be executing 10 to 20 read/rewrites per second so
expect the benchmark to run from 15 to 60 minutes.


-------------------   Apologies to All    ----------------------

If the benchmark executes for over 24 hours the calculation of records
written and read/rewrites per second will be incorrect.  In cases where
the benchmark has executed for over 24 hours you will have to do your
own calculations based on the start and stop times presented during the
execution.


For any questions feel free to contact me:

        Robert Chapman
        11 Mareblu
        Suite 130
        Aliso Viejo, CA 92656
        (714) 831-4442
        Fax: (714) 831-4432

