Subj : Compression question To : Peter Knapper From : Bob Jones Date : Wed Jul 23 2003 12:34 am PK> Incidentally, your message made me remember my PK> rationale for the way I have done things for so long, I PK> had forgotten the little details......;-) ... You're also reminding me of something I do here that impacts how Squish works under my OS/2 setup.... I serialize (almost) all my squish and related processing.... PK> In addition, you can use the SEND and ROUTE commands to process PK> traffic for a specific set of nodes, and then the output of those PK> commands is NOT included in any other ROUTE PK> statement processing that PK> encompass those nodes within a global statement (EG 4:ALL). However PK> note that this ALL must happen within ONE Squish operation to work PK> this way. There is a bug in squish concerning this when '(send or route) NOARC NORMAL 'is used. A subsequent 'ROUTE X:ALL' where X is the same zone as the NOARC NORMAL node will result in squish re-processing that already packaged .PKT file into the archive for node 2 when the X:ALL line is processed, even in when squish is run in one pass mode.... JS> I don't think that's really true. Even within a single JS> run, SEND and ROUTE commands only operate on mail that JS> is marked NORMAL at the time the command is executed. PK> I don't now how the above mis-conception stared, but PK> Squish has always worked fine for me by ONLY processing PK> mail in HOLD status. In fact I determined quite some PK> time ago (I started using Squish V1.01 when it first PK> came out), that HOLD was the ONLY status mail that PK> could be safely processed by Squish, expecially when PK> running multi-node. I find I can get away with any flavor execept NORMAL *AS LONG AS* all processes dealing with the files squish deals with (inbound areas, outbound areas, and echo / netmail database) are using the same control flags Squish is using. Maximus, Squish, Binkley and BinkD all observe the proper flags. Some of the third party utilities don't.... At least that's my current opinion. How I keep things from clobbering each other is I do run a semiphore / processing lock, to keep my script that runs squish clean and only allowing one execution at a time, and this also forces all my third party applications to run when Squish is not running..... I'll agree that your method of changing things to HOLD before squish processes packets is a reasonable stradegy, and avoids problems that can happen in an environment where some disks are remote mounts. All my disks are local mounts, and so the file and process locks are all local to a single machine. Yes, some of the processing I do would probably fail in an networkd disk drive enviornment, and I think your solution would work better in the multi-machine / remote file mount environment.... PK> Here is an example of my default Schedule that is PK> called every time mail is processed except during ZMH. ... PK> and that in essence is the way this system has processed mail since PK> Squish V1.01 came alive. Mail here is only ever set to PK> NORMAL status during ZMH, or I have a specific PK> situation requiring me to manually set it. ALL my mail PK> processing by Squish normally takes place using HOLD PK> status. The very FIRST statement in a Schedule CHANGES PK> all mail to HOLD, and the LAST statements in any of my PK> Schedules CHANGE's a HOLD packet to whatever Flavour is PK> needed. Also note that I use other utilities that will PK> change the Flavour of a packet, usually as a result of PK> other external events that Squish does not manage. JS> For example, assume that you have mail for 123/45 that JS> is marked DIRECT, and mail for 123/67 that is marked JS> NORMAL. The following commands JS> ROUTE CRASH 123/0 ALL JS> SEND CRASH 123/67 PK> Yep, I am sure you are seeing exactly the reason I PK> abandoned using a ROUTE or SEND output FLAVOUR of PK> anything other than HOLD, many years ago, there were PK> quite a few gotchas that could upset things, especially PK> when running multi-node. The only way I manage Mail PK> into any status other than HOLD, is via the CHANGE PK> Command, I dont use ROUTE (or SEND) CRASH/NORMAL/DIRECT PK> etc, I always use ROUTE (or SEND) HOLD ... and then PK> CHANGE the Flavour. A reasonable stradegy..... I tend to use just crash and hold for most things. I'll have to take another look to make sure the locks (.BSY files) are being properly processed in BinkD and Binkley. Last I looked they were working fine.... I some times see "still have mail for " in Binkley or BinkD after a session because squish had the .BSY file set, prohibiting sending stuff for a given node while the session was going on.... Now, the dupes I see may be a result of re-processing a packet that was only partially received at the time of the previous squish session.... Hmmmm..... I've tend to ignore the dupe problem. Thanks for the note..... Bob Jones, 1:343/41 --- Maximus/2 3.01 * Origin: Top Hat 2 BBS (1:343/41) .