These are the usage instructions for the 04/2019 version 0.99 of vtbl
It will read and extract data from a compressed Iomega *.113 backup file.

See the project pages http://www.willsworks.net/file-format/iomega-1-step-backup
See also the rd113 program that will read the data from and uncompressed file.

These backups were typically written to Iomega removable media and released
with the drive installation software that came with the device.  To date I
have only worked with backups from Iomega 100Mb zip drives.  I believe the same
software can be used with 1Gb Iomega Jazz drives and 20Gb Iomega Peerless drives.
Apparently there were Mac and Linux versions, but I have only work with Windows backups.
The original software only wrote a backup file on the Iomega drive, but it could
then be copied to any medium.  A typical backup often required several zip disks.
In this case each disk was given a sequential sequence # starting with 1, and
a flag in the image file header was set indicating the file was part of a seqential 
backup spanning multiple disks along with the sequence number in the set.

This is version, 0.99, is the 2nd major release of the software.  It adds some 
options which are particuarly useful for incremental backups processing. As well
as correctly a bug in the decompression which has come to my attention.
The current version is limited to 2Gb files per the early Windows OS standard.
This is not a limitation in the file format, it has to do with 32 bit compilers
and my code. If built on a linux 64 bit system this limit goes away, but for your
average backup image from a zip disk collection it is not likely to be a problem.

The usage message below is seen if the program is run with no command line arguments:

vtbl version 0.99 compiled for WIN32

usage: vtbl <iomega.113 archive file> [-a] [-d] [-r] [-s#[:#]] [-v[v]] [-z]
       -a append data from source image to existing 'dcomp.out' and write new catalog
       -d surpress file decompression, just display compressed file segments
       -r only decompress and write raw data to new file 'raw.out'
       -s#[:#] start with seg #, optionally limit action to :# segments
       -v enables verbose mode for display, vv makes dcomp verbose
       -z surpress decompress and only display segs with cum_sz and cum_sz_hi = 0
   by default write decompressed *.113 data to new file 'dcomp.out'
   use -z to locate multiple catalog regions and -r with -s#:# to extract
   by default -r will attempt to extract the last catalog in the set


The output above is from the Win32 version of the program.  If compiled for Linux
the only difference is that 'Linux' would be displayed rather than 'Win32'.

An <iomega.113 archive file> name is required.  If this is the only argument given the
program attempts to read the input file and output the decompressed data to dcomp.out.

The the other options will modify this behavior.
-v and -vv just enable progressively more verbose debug messages.

-s#[:#] allows a sub set of the records to be processed starting with s#
        and continuing to EOF, or if the 2nd # is provided until this #
        of records have been processed.

-a  similar to above, but appends data from current image file to end of existing
    dcomp.out.  This is used to concatonate backup images that use more than one disk 
    together into a single images file to simplify subsequent processing.

-r  enable raw mode.  Be default an new *.113 file is created with appropriate
    file headers and a vtbl.  In raw mode these are not written.  Just the range
    of records desired up to decompressing all data records in the file and writting
    them to the file raw.out starting at output file offset 0.  This is typically 
    used to examine a small section of the file such as a catalog or data region of 
    special interest.  Its basically a debugging tool.

-d  surpress decompression output to dcomp.out, it just displays the compressed
    data headers in the file.

-z  surpress decompression and limit the display above to just those records 
    where both cum_sz and cum_sz_hi are zero.  This condition indicates either the 
    start of a new decompressed region, either a data region or a catalog region.
    Hint, catalog regions are much smaller than data regions.

Don't be impatient, it takes a while to decompress a zip disk image.
On a fairly recent 64 bit machine which by my standards is pretty fast
it still takes 20-30 seconds to process a zip disk image.  It displays
each record as it is decompressed, but the list scrolls by for a long time.

In the simplist case you can just decompress a compressed *.113 file via
  vtbl <file name>
This writes a new decompressed file to dcomp.out that can be read by rd113.

If you have a multi volume backup.  Decompress the 1st disk per above.
Then for each additional disk run
  vtbl <file name> -a

It concatonates the images together into the final dcomp.out with all the data
from the backup.  If this is done you don't have to worry about data files
which may have been split across two disk images.

The -d and -z options let you examine the images a little without actually doing
any decompression.  This is especially interesting if you want to extract just
one incremental backup from a disk image that has multiple backups on it.   

The -d option lists all data segments in the compressed file and indicates
if multiple passes are required to extract the compressed date in the segment. 

One can use the -z option to see where the region breaks occur by record number
in the source file.  Typically the # of records for the data section is much
greater than for the catalog section.  The first disk image will start with a
data section, then a catalog.  If its a set of incremental backups this pattern
may repeat and number of times in each image.  But there appears to be no certainty
whether subsequent disks will start with a data or catalog section.
Both my loaned sample files are seq 2, so one has to guess which are the data
regions and which are the catalogs.  Once a data section and catalog section
are identified, use s# = starting data section record and :# count = total
records in the data and catalog sections in command
   vtbl <file name> s#:#

This will create a new uncompressed *.113 file in dcomp.out that just contains
the incremental backup of interest.  Sadly to date I know no way of determining
what is in an incremental backup without decompressing it.  I suspect the system
had supplimental files that recorded this, but have not researched it.

Per above some guess work is required if you don't have all the disks in a 
multi disk backup, but it just takes a little disk space and time to try sampling
different groups of segments by decompressing with the -s#:# option and then
examining the output with rd113 or a dump program.  The alternative is to decompress
the entire image and use the rd113 option -di to examine the contents to determine
whether or not it contains multiple backups and where they are located.
--------------------------------------------------------------------------------

Decompression references:
I did not work out the decompression from scratch.  Originally it baffled me.
Then an internet colleague enlightened me by saying wass covered by the
Quarter Inch Tape documentation.
http://www.qic.org/html/standards/11x.x/qic113g.pdf   - general file format
http://www.qic.org/html/standards/12x.x/qic122b.pdf   - compression algorithm
This was really embarassing for me as I was very familiar with this from the MSbackup
work I published in 2010, but I just didn't make this connection until it was pointed
out to me.  If interested that project is described at the site below:
http://ntbkup.jacobytech.net/   - my original MSbackup pages

