Hall of Fame/HallofFameCDROM.cdr/comp/pakit106.lzh/PAKIT.DOC

Text File | 1989-04-09 | 26KB | 467 lines

PAKIT - Version 1.05  04/05/89
Semi-intelligent ARCA to PAK/ZIP/ZOO/DWC/LHarc Converter for use with oMMM
Written by Jack Decker - LCRnet 77:1011/8, NetWork 8:70/8, Fidonet 1:154/8
No warranty expressed or implied - use at your own risk!

BETA VERSION of the program and instructions, for test purposes only!
(Actually, I've said this for the last four revisions, hopefully it's getting
pretty solid by now...)


***** WARNING TO USERS OF PREVIOUS VERSIONS OF PAKIT *****

This version of PAKIT requires that if you use PKZIP, you MUST have PKZIP
version 0.92 or newer.  If you are still using the older version 0.90 of
PKZIP, do NOT install this version of PAKIT until you have upgraded PKZIP!

[The following applied to release 1.4 of PAKIT and is reprinted here for those
who may have missed that release:]

This version of PAKIT requires that if you use PAK, you MUST have PAK version
1.5 or newer.  If you are still using the older version 1.0 of PAK, do NOT
install this version of PAKIT until you have upgraded PAK!  Also, when
installing PAK version 1.5 or higher, you ABSOLUTELY MUST run PAKINST.EXE and
use the "D" option to "set [D]irectory for pak.cnf" (I strongly suggest that
this is the ONLY thing you do with PAKINST.EXE... it should be obvious that if
you change PAK's command line interface by changing pak.cnf, programs like
PAKIT may not operate correctly)!  For your own safety, be SURE you run
PAKINST.EXE using the "D" option!

Those not using the batch file (small memory) version of PAKIT can skip the
remainder of this warning.  In the past, the batch file version sometimes
created two separate outgoing mail bundles for the same destination node. This
problem has been fixed, but you must now heed the following warnings when
using the batch file version.  NONE OF THE FOLLOWING APPLY TO THE STANDARD
"BIG" VERSION OF PAKIT:

1) If you are using the batch file version of PAKIT, and you are using oMMM
version 1.30 or higher, you now MUST use oMMM's "-o" command line option, or
the "mo?" option in the ommm.cfg file. See the technical pointer below for
more information.

2) Do NOT use this version of PAKIT with oMMM version 1.08.  In fact, you
shouldn't be using oMMM 1.08 anyway, it was a beta version that was never
supposed to be released to the general public, and it contained serious bugs!

3) The batch file created by PAKIT (pakit.bat) must be executed immediately
after oMMM runs (in other words, follow the setup instructions for the batch
file version exactly).  In particular, you cannot defer running the batch file
until a later time.  If you do, the batch file may delete valid mail bundles,
because it contains lines intended to delete certain null (zero length)
bundles that are no longer needed.  If you don't run the batch file
immediately, though, it's possible that those (formerly) null mail bundles
might wind up containing actual mail that could be erased.  I can't imagine
WHY anyone would want to defer running pakit.bat, but figured I'd better warn
everyone of this change in operation, just in case.

[End of warning to previous users of PAKIT]

**********************************************************


PAKIT was written to allow you to create smaller outgoing mail archives (*.mo?
files, etc.) for systems that can accept them, by using any of several
different file compression utility programs (PAK, ZOO, DWC, LHarc, and/or
PKWARE programs) with oMMM version 1.07 or higher (it will probably work with
earlier versions of oMMM as well, but you should upgrade anyway!  Do NOT use
oMMM version 1.08, though, it was buggy).  Those who use oMMM may be aware
that oMMM calls ARCA for file compression purposes.  This program intercepts
the call to ARCA, translates it to a format that another file compression
utility can understand, and then hands it over to that utility.  While this
program is specifically designed for use with oMMM, it MAY also work with
other packers that call ARCA using the "/D" parameter at the end of the
invocation line.

PAKIT was originally intended to be used with NoGate Consulting's PAK File
Compression Utility, and still defaults to the use of PAK (Version 1.5 or
higher), however you may also optionally specify that PKWARE's PKARC or PKPAK
program is to be called when creating "Crunched" or "Squashed" mail archives
(these programs are no longer available from PKWARE, but may still be
available on some BBS's).  You also have the option of using ZIP ("Reducing"),
ZOO, DWC ("Shrinking"), or LHarc ("Freezing"?!) as the compression method to
be used for mail packets.

If you use this program and PAK without a PAKIT.CTL file, the resulting mail
archive files should be no different than if you had just used ARCA only
(obviously, there's no real advantage in doing that, but you can do it if you
want to).  The major advantage in using this program is that you can use a
control file called PAKIT.CTL, which will allow you to specify which
compression method, or which of PAK's three possible compression levels, will
be used when packing mail to any given node.  Thus, if you KNOW that a
particular node is using PKWARE's PKXARC (or PKUNPAK) program to de-archive
mail packets, you can create mail packets using "Squashing", which will make
smaller packets and possibly save you some transmission time.  If you
regularly communicate with a node that uses PAK to unpack mail, you can create
mail bundles using "Crushing" and save even more disk space and transmission
time.  And, the most recent versions of PAKIT will allow you to create
compressed mail bundles using any of several other popular file compression
formats, should you have a need to send mail bundles in one of those formats.
These options should only be used with nodes with which you communicate
regularly, and know what program is being used to uncompress mail packets.

How to use PAKIT:

* First, make sure that the compression utilities you plan to use, e.g.
PAK.EXE (version 1.5 or higher), PKARC or PKPAK (or the "JR" variations
thereof), PKZIP.EXE, DWC.EXE, LHARC.EXE and/or ZOO.EXE, are either in the same
directory as the one from which oMMM is run, or in some other directory
defined in your PATH statement in AUTOEXEC.BAT.

* Second, rename ARCA.COM to something else (like OLDARCA.COM).

* Third, rename one of the two .EXE programs in this archive to ARCA.EXE (they
are currently named ARCA_BIG.EXE and ARCA_BAT.EXE).

If you are running with a full 640K of memory and don't have too many TSR's,
you can use ARCA_BIG.  This is the preferred method, but it uses a lot of
memory, because oMMM shells to ARCA.EXE (really PAKIT, but we have to name it
ARCA.EXE to make oMMM use it), and then our ARCA.EXE shells to the file
compression utility, which of itself requires quite a bit of memory.  Still,
you should have enough memory for it to work if you're not using multitasking,
or too many TSR's.  If you find that your mail packets aren't getting archived
and sent out (and perhaps wind up getting tossed back into your netmail area
on the next import cycle), this is one of the two usual reasons (the other one
being that the file compression utility ran out of disk space and aborted).

If you are short on memory, you must use ARCA_BAT.EXE, which does not directly
call the file compression utility.  Instead, it creates a batch file called
PAKIT.BAT which contains the commands used to invoke the file compression
utility.  This batch file then can be run after oMMM has exited, when neither
oMMM nor ARCA_BAT.EXE are still in memory.  In order to use this method, your
batch file should contain a sequence of commands similar to this:

REM ** run oMMM to prep mail, then loop back to start
ommm -hc:\opus\outbound\ -mc:\msg\net\ -ic:\opus\bbs.prm -cc:\opus\route.ctl
if not exist pakit.bat goto start
command /c pakit.bat
del pakit.bat
goto start

This method should work in all but the smallest memory partitions.  Please
note that you must execute pakit.bat IMMEDIATELY after the call to oMMM.  Do
not defer processing of pakit.bat until a later time, as doing so could cause
undelivered outbound mail packets to be deleted under certain circumstances.
Execute pakit.bat right after calling oMMM, then delete it immediately after
it has run, as shown above.

ALSO PLEASE NOTE:  If you use the batch file method with oMMM version 1.30 or
higher, you MUST use oMMM's "-o" command line option, or the "mo?" option in
the ommm.cfg file.

* Fourth, create a PAKIT.CTL file.  This file must follow the exact format
shown below (it is NOT advisable to try and put comments in this file):

The FIRST line must contain your PRIMARY net/node number... that is, the
net/node that oMMM thinks your system is operating under.  If you change your
PRIMARY net node to something else, be SURE to change it here.  If you use
PKARC or PKPAK (or the "JR" variations), you should follow your net/node
number with a space and then the name of the PKWARE program you use (PKARC,
PKPAK, PKARCJR, or PKPAKJR).  Please note that only the aforementioned PKWARE
programs may be specified on this line at this time.  For example, any of the
following three lines would be a valid first line in the PAKIT.CTL file for
node 154/8:

154/8
154/8 PKARC
154/8 PKPAK

Each SUCCESSIVE line should contain the net/node numbers of those systems you
regularly communicate with, one to a line, followed by a space and
(optionally) one of the letters C, D, L, P, R, S, or Z, where:

C = Crunching (the normal method used by ARCA) must be used.
D = DWC (Shrinking) is to be used (receiver must use DWC to uncompress).
L = LHarc (Freezing) is to be used (receiver must use LHarc to uncompress).
P = Crushing is allowed (use if the receiving system uses PAK to unpack mail).
R = PKZIP (Reducing) is to be used (receiver must use PKUNZIP to uncompress).
S = Squashing is allowed (receiver uses PAK, PKXARC, PKUNPAK, or newer ARCE).
Z = Zoo is to be used (receiver must use Zoo to uncompress).

If you do not specify any of these letters, or if a node is not listed in
PAKIT.CTL, or if no PAKIT.CTL file is found in the current directory, then
Crunching will be used by default (in order to comply with current Fidonet
technical standards).  If you DO use one of these letters, it should be the
last character on the line.

Here's a sample PAKIT.CTL file for node 154/8:

154/8 PKPAK
154/7 P
154/9 S
222/70 P
1011/7 P
1999/2 S

The FIRST line (154/8) is my PRIMARY net node number followed by the name of a
PKWARE program that I wish to call when "Crunching" or "Squashing" mail.  The
other nodes are ones that I know are capable of receiving and de-archiving
Crushed (using "P") or Squashed (using "S") mail packets.  If one of the
listed nodes were using PKUNZIP to unpack mail, and if I had a copy of
PKZIP.EXE in my path, I could use a "R" instead of a "P" or an "S" after that
node's listing.  Similarly, if one of the listed nodes were using ZOO to
unpack mail, and if I had a copy of ZOO.EXE in my path, I could use a "Z"
after that node's listing.  The same applies for "D" (DWC.EXE) and "L"
(LHARC.EXE).

A few technical pointers:

* If you don't specify a PKWARE product on the first line of PAKIT.CTL, then
PAK (PAK.EXE) will be called to perform all types of compression that it can
handle (including Squashing and Crunching).  However, there are three reasons
that one may wish to use a PKPAK or PKARC where possible: 1) The PK products
are much faster in operation, 2) The PK products generally create smaller
archives than PAK does when Squashing or Crunching is specified, 3) If
Squashing is specified but a smaller archive would be created by Crunching,
the PK products are smart enough to fall back to the older method.

* If you DO specify a PKWARE product on the first line of PAKIT.CTL, and do
NOT specify "P" as the compression method for any node, then PAK.EXE does not
have to be available online (this is considered cheating, but you can do it).
However, you must have at least one of these file compressors in your path
(either PAK.EXE, or one of the older PKWARE products mentioned above).

* If you specify "R" as a compression method for any node, you must have a
copy of PKZIP in your path.  PKZIP is invoked using the -m -ex options (this
is a change from versions 1.4 and earlier) in an attempt to insure that the
greatest amount of compression is used.

* If you specify "Z" as a compression method for any node, you must have a
copy of ZOO.EXE in your path.  I do not recommend the use of Zoo for the
purpose of creating mail bundles, because it creates larger bundles than PAK
or PKZIP, but if you have a desperate need to create Zoo packets you now have
a way to do it (even if you're not using oMMM version 1.30 or higher, which
can create Zoo bundles without help from PAKIT).  Zoo is invoked using the
"ZOO -move" option, the same method used by oMMM 1.30.

* If you specify "D" as a compression method for any node, you must have a
copy of DWC.EXE in your path.  DWC is invoked using the mz options in order to
insure that the greatest amount of compression is used.  I suggest that you do
not set any of environment variables mentioned in the documentation for DWC,
unless you are careful not to create a situation where DWC would stop and wait
for keyboard input (not a desirable situation when your system is running
PAKIT in an unattended batch mode!).

* If you specify "L" as a compression method for any node, you must have a
copy of LHARC.EXE in your path.  LHarc is invoked using the m /m options.

* IMPORTANT!!!  PLEASE NOTE - THERE IS NO ERROR TRAPPING TO DETERMINE WHETHER
PAK, PKZIP, ZOO, DWC, LHARC, or another of the PK products (PKARC, PKPAK,
etc.) is in your path!  If you specify that you want to use one of these
methods (via the PAKIT.CTL file), PAKIT *assumes* you've made the
corresponding programs available!

* If you are using the batch file version of PAKIT (originally named ARCA_BAT
in the distribution archive), and you are using oMMM version 1.30 or higher,
you MUST use oMMM's "-o" command line option, or the "mo?" option in the
ommm.cfg file.  This ONLY applies if you are using the BATCH FILE VERSION of
PAKIT with oMMM version 1.30 or higher!  You do NOT need to use this switch if
you're using the "BIG" version of PAKIT (unless you need it for other reasons,
e.g. you send mail to an Opus version 1.03 system that does not use ConfMail
to unpack mail).

* If you want to use PAK to unpack incoming mail (so that you can receive mail
packets that are Crushed, Squashed, or Crunched), you may now do so more
easily since version 1.5 now allows wildcards to be used (PAK version 1.0 did
not!).  If you use ConfMail, for example, use the -A command line option and
specify that PAK is to be used to uncompress mail archives.  I suggest the
following syntax:

ConfMail Import areas.bbs {other options} -A PAK X /WN /OT

If you have lots of disk space and you would prefer that the mail archive not
be deleted until after all mail packets have been tossed, use "E" instead of
"X", as follows (in this case ConfMail will delete the mail archive after
tossing is completed):

ConfMail Import areas.bbs {other options} -A PAK E /WN /OT

The /WN option keeps PAK from overwriting an existing packet on your system
with another packet with the same name from a mail archive.  You should never
have that problem anyway, but if it ever happens, this switch will keep your
BBS from being held offline while PAK waits for you to tell it whether to
overwrite the file or not.  You can omit it if you're more worried about
possibly losing a mail packet than about your system being taken down by such
an occurrence (or change it to one of PAK's other /W? options if you prefer).

DON'T omit the /OT switch, though.  It specifies that packets should be
extracted in time order (oldest first).  This will help keep messages in the
proper order on your system, so that you don't see replies to messages before
you see the original messages.  Some archiving programs store .PKT files in
alpha order (by filename and extension), not in the order the packets were
added to the archive, and if you receive a mail packet from a system like
that, the /OT flag should correct the problem so that messages will be tossed
in order (of course, if the message order got mixed up any further upstream,
there's nothing PAK can do about it).  The only time you should even think
about not using the /OT switch is if you are receiving mail from a system that
has an unreliable clock/calendar, and is not time-stamping the packets
correctly.

If you are using a multitasker, or for some other reason are short on memory,
you may find that the combination of ConfMail calling PAK exhausts available
memory, and PAK refuses to extract mail packets.  In that case, just put a
line similar to the following in your batch file, just before you call
ConfMail Import:

for %%a in ( SU MO TU WE TH FR SA ) do if exist c:\file\net\*.%%a?
                                           pak x /wn /ot c:\file\net\*.%%a?
confmail import areas.bbs -M -N -F confmail.out -A PKUNPAK

(note that the first two lines shown in the above example are really one long
line, so DON'T split them into two lines as shown above.  Also, I have
included my call to ConfMail Import for clarity.  Note that the option -A
PKUNPAK is normally unnecessary here, since all mail packets will have already
be unpacked, but I left it in under the theory that if PAK ever barfs on a
mail archive and refuses to unpack it, I'll give PKUNPAK a crack at it.  You
may wish or need to change other options on the ConfMail Import command line
as well.  If you are running both echomail and GroupMail on your system, your
call to GROUP IN should be placed immediately AFTER the call to ConfMail
Import, for reasons that are beyond the scope of this document).

When you run PAK from the batch file to extract mail packets in this manner,
you MUST use the "X" option of PAK (rather than the "E" option) to delete the
mail bundles after the individual .PKT files have been extracted.  Be sure to
substitute your net files path for "c:\file\net" in the two places it appears
in the line above, if you use a different path on your system.

* If you want to be able to receive and process mail packets that have been
created using any of PAK/ARCA, ZOO, DWC, or PKZIP, you will need an external
program that will detect the type of mail archive, and call the appropriate
program to uncompress it.  At this writing, the only such program that I am
aware of is SPAZ, written by Dan A. Thomson and Andrew D. Farmer, and
available from Alternet node 7:483/1 or Fidonet node 1:163/115.  Please note
that earlier versions of SPAZ did not support all the compression types listed
above, so it's best to pick up a copy of the most recent version of SPAZ that
is available.  It's probable that newer versions of SPAZ may support LHarc
packets as well, although I am not aware of a version that does so at this
writing.

* Starting with version 1.01, PAKIT renames individual .PKT files prior to
placing them in the mail archive, in order to assure that older files are
always placed before newer ones in the archive.  This is done to overcome a
difference in operation between ARCA and PKARC/PKPAK/PAK 1.0.  ARCA always
added packets to the END of an existing archive (as does PAK 1.5 if the "/O-"
modifier is used), but some of the newer programs do us the favor(?) of
inserting new files into an existing archive in alphabetical order.  At least
some versions of oMMM create packets using a naming sequence that restarts
every day, thus packets created just after midnight would be stored in the
archive BEFORE packets created on the previous day (when one of the newer
archivers is used).  The result is that replies to messages are sometimes
stored prior to the original messages when the destination system unpacks the
mail!  PAKIT attempts to overcome this problem by renaming the packets using a
naming sequence that restarts at the beginning of every year, rather than
every day.  Thus, it is only possible to create out-of-order mail packets at
the beginning of January. The packet names used contain only the hexadecimal
digits 0-9 and A-F, and are always eight characters long (not counting the
.PKT extension).  As far as I can determine, this will not cause any problem
for any existing mail unpacker, but please let me know if you discover
otherwise.

When creating mail bundles, PAK 1.5 is called using the "/O-" (no sort) option
to overcome the above problem (and to perhaps make recovery from an
interrupted transmission easier for the various mailer programs, since new
packets are always added to the END of the existing archive).  However, the
packet renaming mechanism described above is still retained in this version of
PAKIT, mostly to keep packets in proper order when a PKWARE product is called
for Crunching or Squashing mail archives.  In any event, this renaming of the
.PKT files doesn't seem to hurt anything.

* Only PAKIT version 1.02 or higher should be used with oMMM version 1.30 or
higher (you MAY use PAKIT 1.02 or higher with ANY known version of oMMM,
except oMMM version 1.08 which should not be used).  Do NOT use the -a command
line option, or the pkarc option of the ommm.cfg file, if you use oMMM version
1.30 or higher.  PAKIT will convert the calls from an ARCA-style format to a
PK-style format where necessary, if you have given the name of a PKWARE
product in the first line of your PAKIT.CTL file.  As noted above, though, if
you are using the batch file version of PAKIT, be sure to use the -o option of
oMMM or the "mo?" option in the ommm.cfg file.

* When switching compression methods for any node that you currently send mail
to, try to make sure that no existing mail packets for that node reside in
your outbound area.  This is particularly important when switching between
compression methods that are mutually incompatible.  If a mail packet for the
node in question already exists in your outbound area, either convert it to
the new compression format, or crash it to that node before making the change
in the PAKIT.CTL file.

That's about all there is to it.  Please remember that this should be
considered a Beta test copy and is NOT guaranteed to function properly under
all possible circumstances, but if you find a bug, I'd appreciate it if you'd
let me know about it.  The most recent copy of this program should be file
requestable from Fidonet node 1:154/7 (LCRnet node 77:1011/7, NetWork node
8:70/7), under the filename PAKIT*.ZIP.

If you find an archiving program that creates archives that are even smaller
than any of the presently supported compression methods (particularly if it's
truly public domain, or at least free to non-commercial users), please send a
copy of the program to me and I will at least consider making a version of
this program that will use it.  Also, if the Fidonet (or any "other" net)
nodelist is ever modified to include a "compression level" flag for mail
archives, I will consider rewriting this program to look directly to the
nodelist for compression level information.

PAKIT is written in QuickBASIC.  If you feel that you have a legitimate need
for the source code, please send netmail to 1:154/8 or 77:1011/8, or call me
voice at [phone] and we'll talk about it.  Don't expect anything
fantastic, I'm not a professional programmer.

Jack Decker (77:1011/8, 8:70/8, 1:154/8)


Trademark acknowledgements (some as given in the documentation for oMMM):

"The following names are either trademarks of and/or the efforts of the
person and/or organization given:"

ARCA, ARCE - Vernon Buerg, Wayne Chin, System Enhancement Associates, Inc.
ARCmail, ARC - Thom Henderson, System Enhancement Associates, Inc.
DWC - Dean W. Cooper
Fido, FidoNet - Tom Jennings, Fido Software
LHarc - Haruyasu Yoshizaki
oMMM - Marshall Presnell, Jim Nutt, Bob Hartman, Wynn Wagner, Alan Applegate,
     Vince Perriello, BS Software
Opus-CBCS - Wynn Wagner
PKARC, PKXARC, PKPAK, PKUNPAK, PKZIP, ZIP - Phil Katz, PKware, Inc.
SPAZ - Dan A. Thomson, Andrew D. Farmer, Jeffrey Nonken
ZOO - Rahul Dhesi

My apologies if anyone was inadvertently omitted from the above list.


NOTE ON ARCHIVE PACKAGING:  If you want to re-package the programs in this
archive using a different compression scheme, feel free to do so.  All I
ask is that you don't change or modify the three files in the archive
(ARCA_BAT.EXE, ARCA_BIG.EXE, or PAKIT.DOC), or add any other files to the
archive.


Version History:

Version 1.00 - First working version

Version 1.01 - Added renaming of mail packets to try and make sure they are
unpacked in chronological order at the receiving end, support for the use
of PKARC or PKPAK when creating "Crunched" or "Squashed" mail archives, plus
other minor fixes.

Version 1.02 - Added support for fully-pathed bundle and packet names, as
supported by new versions of oMMM.  This is the last version that worked
with PAK version 1.0.

Version 1.03 - Made changes to use new options of PAK 1.5, and added ZOO
support (somewhat against my better judgement, but, it was only one line
of added code).  Fixed (I hope) problem in batch file version that allowed
two outbound mail archives (with different names and contents) to be created
simultaneously for the same node.

Version 1.04 - Minor code revisions, added support for PKZIP.

Version 1.05 - Changed calling options for PKZIP from "-ea4 -eb4" to "-ex",
a new switch first supported in PKZIP version 0.92.  Added support for DWC
and LHarc.

Version 1.06 - Bug fix version.  PAKIT barfed on blank lines in PAKIT.CTL.
That should be fixed now, although it's still safer not to put any blank
lines in PAKIT.CTL.