PE> I thought the squish routing commands might have
PE> automatically attempted to dial out straight away when you
PE> next get into Binkley.  Next time you do the run, just

 AM> I does work.

I'm not sure if you're saying that the squish routing commands work
automatically, or changing your batch file worked.  The latter will
definitely work, so I'll leave the former in the "untested as
yet" pile.

 AM> There's one last line I would like to either unrem or 
 AM> delete:

 AM> del binkley.scd

 AM> the binkley schedule file.  Is there any point in deleting 
 AM> it?

Yes, so that it will exit for the first time.  If you don't do that, then
if you poll for mail again, then the first one will not exit straight away,
it will be the one that gets your mail, and when it exits, it will then
start up another one, which you have to exit manually.  You could get
around this by saying "if errorlevel=start_of_event then start binkley
again" instead of the blind two starts that I did.

 AM> Also, since modifying msgareas.ctl to limit the messagebase 
 AM> to a certain number of days rather than a certain number of 
 AM> messages, Max now complains when its processing .rep 
 AM> uploads, that I specified an invalid area number and asks me 
 AM> to select a new area.  All the areas are tagged in the QWK 
 AM> section, so it isnt that.  It seems to be happening to 
 AM> messages bound for any and all echos.  Here's a bit of my
 AM> msgareas.ctl file that is typical.

Sounds like you've lost your sysop status.  Can you try going into the
messages section in Max and seeing if you can enter a message into these
areas?  The renum days instead of renum max has nothing to do with it.

 AM> Also, the Public Only line - is that the one that stops 
 AM> echomail messages with the PVT flag set from being seen?  
 AM> What do I do to be able to see messages with PVT set.  
 AM> (occasionally/accidentally people set the PVT flag...)

No, Public Only means that if you enter a message locally (or with QWK)
that the attribute will be stripped.  However, incoming echomail needs the
"StripAttributes" in squish.cfg to delete the PVT flag.

 AM> Lastly, when polling for mail, Binkley says that the 
 AM> outbound packet (replies) is truncated after its finished.  
 AM> It also leaves the file in the outbound directory, albeit 
 AM> zero bytes in length.  Is this "normal"?  A part of a 
 AM> typical binkley.log file:

Yes, this is normal, so that if there's more mail for you the same day, it
will start on the next number, so that you don't get a name clash your end
if you haven't processed your inbound mail yet.

 AM> Well, almost lastly, I've noticed that after polling early 
 AM> in the evening, and then polling to send the replies back 
 AM> later that night, that there is sometimes another inbound 
 AM> packet sent.  How often does a packet get made for me?  And 
 AM> at what time/s?  I thought outbound point packets would only 
 AM> be processed once, and after your early morning
 AM> poll?

Every time mail comes into my system, it gets processed.  Mail comes into
my system from all my points (anytime at all), Dave (once a day at about
6.45 am), and a guy from Melbourne (about once a week, at any time).  BFN.

Paul

---