From: "George D. Greenwade" <bed_gdg@SHSU.BITNET>
Newsgroups: vmsnet.mail.mx
Subject: RE: A question and an enhancement request.
Date: Thu, 23 Jul 1992 16:02:27 CDT
Organization: Mx-List<==>Vmsnet.Mail.Mx Gateway
X-Gateway-Source-Info: Mailing List

On Thu, 23 Jul 1992 08:56:24 EDT, Brian Tillman <tillman@swdev.si.com> posted:
> John F. Sandhoff (sandhoff@csus.edu) writes:
>
> >My system is what I consider busy (typically over 1000 messages a day) and
> >I don't recall seeing this problem. I seem to recall that ONCE I got
> >a 'currently locked' error from FLQU SHOW but other than that I don't
> >see locks. CPU speed may have a lot to do with it - MX runs on an 8820
> >here (though sometimes at priority 1 - ouch!)
>
> Well, we use MX a *whole* lot less (about six people) and it's happened
> twice in the past month.  Now, that may seem very little, but it seems that
> if we release MX to all 500 of our accounts, we could very well see this
> much more frequently. This would mark MX in the minds of the Email people
> here as a flawed product and we would be forced to use our previous SMTP
> mailer (yuck!).

I guess we're lucky -- in two-plus years of use, I've only seen or heard of
this happening once (when MX 3.0 was still in beta), and we viewed it as a
chance occurrence (I'm sure Ken or someone looked at it hard, but as I
recall chance was the final verdict).  We are a busy site, I think -- we
run 15 processes under MX on three nodes, our FILESERV handles over 300
outbounds a day (it's been months since we've handled fewer than 200 in a
day; last month we handled 16,871 files, not including the verification
messages and error replies) and we have three quasi-active lists with over
100 subscribers, another with 300+ and still another with around 500 (which
is probably the most active of all of our lists).  That's even before
getting to our local users.  The MCP/FLQ count can easily go up
8,500-11,000 in a normal school day (yes, I know MX generates 2-4 per
message, but that's still quite a few).

Hunter already shared our approach -- we don't allow MX to ever compress
the file; instead, we shut it down each morning around 0100, then do the
compression in a daily batch job (the SYSTEM_QUEUE.FLQ_CTL file generally
goes from 7000+ blocks back down to <300 during this process).  Each of the
3 nodes has its own batch queue and its own restart file called by the main
file, verifying JNET, doing things to help in the FILESERV directories,
which are also our anonymous ftp directories, etc.  The main file even
waits to see if SYSTEM_QUEUE is locked before it does its thing:
 $loop:
 $ open/read file SYSTEM_QUEUE.FLQ_CTL/error=not_yet
 $ back/ign=int SYSTEM_QUEUE.FLQ_CTL.0 SYSTEM_QUEUE.FLQ_opt.0
 $ OPT SYSTEM_QUEUE.FLQ_opt !OPT calls a command file to optimize the file
 $ copy SYSTEM_QUEUE.FLQ_opt SYSTEM_QUEUE.FLQ_Ctl
 $ close file
 $not_yet:
 $wait 00:00:10
 $goto loop
At 0100, with all processes down, this is relatively safe, and it allows
all open processes to complete prior to doing anything.

> John, if you still use FLQU, then you must still be using V2.x.  Perhaps
> this problem didn't exist in versions prior to V3.x (we're using V3.1C).

Huh????  The two tools give different information.  I commonly use FLQ to
get a quick look at the queue, then take given numbers from it to MCP QUE
SHO/ALL.  FLQ, at least in our environment, is far superior for a quick
look; MCP QUEUE has better features -- you (or we) really need both.

Regards,   George
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
George D. Greenwade, Ph.D.                            Bitnet:  BED_GDG@SHSU
Department of Economics and Business Analysis         THEnet: SHSU::BED_GDG
College of Business Administration                    Voice: (409) 294-1266
P. O. Box 2118                                        FAX:   (409) 294-3612
Sam Houston State University              Internet:        bed_gdg@SHSU.edu
Huntsville, TX 77341                      bed_gdg%SHSU.decnet@relay.the.net
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Xref: sparky vmsnet.mail.mx:759 vmsnet.uucp:603