Subj : Grunged message cap pointer help?
To   : Mike Luther
From : Paul Quinn
Date : Wed Jul 25 2001 09:42 am

Hi! Mike,

On 24 Jul 01 15:49, Mike Luther wrote to Paul Quinn:

ML> Thanks Paul ..

Oh thanks for the headaches, Mike.  ;)

ML> I really do not know the editor in use for that IM application.  It
ML> came with the HUB when I took it over by default and ported it to my
ML> OS/2 system. It ran just fine for a year when WHAM!

Intermail?  It's the same sort of beastie as FrontDoor (FroDo), isn't it?  So,
you have a minimum of three progrms potentially screwing with your netmail
(*.msg type?) area: IM's editor; FE; and, MsgEd.  (FroDo's editor was/is called
FM.exe, so IM's editor will probably be a similar, separate, *.exe file.)

If that's the hub setup, then what mailer are you using for your regular
node(s)?

ML> No other program uses the same netmail area.  The other systems use
ML> totally separate paritions even!
[ ...trim... ]
ML> I wish you would expand on something you said above! MSGED is what
ML> came to me with the HUB.  It is in use.

Let's talk about lastread pointer files...

*  In *.msg netmail areas the lastread is a file called "lastread<dot>",
  in the netmail directory.

*  In Squish areas it's a file called "<filename>.SQL", in the same
  directory as the other <filename>.* files that make a Squish area.

*  For a JAM area it's called "<filename>.JLR", in the same directory
  as the other <filename>.* files that make a JAM area.

*  For Hudson areas it's called "lastread.BBS", in the Hudson directory.

I have at least one of each messagebase type all looked after by FastEcho (with
some help with Squish 1.11 itself to update reply-links in the Squish areas).
:-)

ML> I notice that in the MSGED.CFG file there are two references to
ML> 'lastread' in it.  The first calls for a lastread lastread, which
ML> implies to me that there should be a file "lastread..something" in
ML> the MSGED directory.  There is no file that has been created there by
ML> that name.

Not in MsgEd's directory; it's in the *.msg netmail area (directory).

In the MsgEd.Cfg file, there should be two references to MsgEd's lastread
netmail pointer, and I quote from my config file:

1.  Name "%SYSOP%" LASTREAD 0
2.  LastRead lastread

The first sets the *name* of the lastread file to use for _you_, the sysop.  I
had to set that for my config to work correctly.  The second "should always be
lastread"; author's statement, not mine.  (I really wonder at the utility of
providing the option for changing the value, when it should never be
changed.<shrug>)

Groping back through the grey matter, back about a year, I think the *.msg
netmail lastread pointer file was called "0<dot>", until I included the
'LASTREAD' info at line 1 (above).  Of course, prior to the change, it was out
of synch with FE and Binkley which were using another file called
"lastread<dot>".

Sound familiar?

ML> This HUB system isn'y my original setup.  In that SQUISH is used in
ML> various places for different runs at things, there are the following
ML> SQUISH.CFG files, which, I think I'm being told are the things that
ML> MSGED uses for its indexing for caps!

Such is the nature of the beast; it was a culture shock for me when I switched
from FroDo to Binkley-style outbound mail, where the system events use the
filenames of the outbound mail as 'flag' files, to drive the routing.  It still
gives me tingles down the spine, two & half years later.

Depending on how MsgEd's config file is set, then yes, it might be told to use
the Squisg.Cfg file for its indexing/lastread (*.SQLs) information.  I've just
got my config pointed to FE's config file and it's happy to use it (for the
netmail/Squish areas; I use TimEd for the JAM/Hudson areas - yes! I'm on the
lookout for a [Win/32] editor that'll do all four messagebase types, in the
same way as does MsgEd).

ML>  These are in my OS/2 related efforts and I use AREAS.BBS for them:

Oooh!  I thought I was the only one in Fido still using an Areas.BBS file! :)

ML>   SQUISH  .CFG   36736 27-Apr-01 21:27:02 ---- D:\SQUISH
ML>   SQUISH  .CFG   36736 23-May-00 05:41:38 ---- D:\SQUISHI

I guess you know what's happening with those.

ML>  These all relate to the IM/FE setup I was dosed with:
ML>   SQUISH  .CFG   16067 29-Jun-01 07:52:42 A--- E:\IM
ML>   SQUISH  .CFG   16256 25-Jun-01 22:23:48 A--- E:\MAIL
ML>   SQUISH  .CFG   19584 17-Mar-01 11:30:36 A--- E:\MAIL\TMP
ML>   SQUISH  .CFG   16384 26-Mar-01 01:13:12 A--- E:\MAILER
ML>   SQUISH  .CFG     649 15-Feb-96 15:57:18 A--- E:\MAILER\160
ML>   SQUISH  .CFG   17792 26-Mar-01 01:11:46 A--- E:\MSGED
ML> About the 25th or June or so is sure about where this mess was
ML> created!  I notice that the MSGED and MAILER directory are frozen in
ML> time at 26-Mar. MAILER\TMP is a slush directory implanted by the
ML> former sysop.
ML> SQUISH.CFG in E:\IM has the new stuff in it as of 29-Jun-2001, as
ML> does the one in E:\MAIL which has the real SQUISH in it!  The others
ML> do not.  Neither does the file "SQUISH" in E:\MSGED which I assume is
ML> the "ASCI" listing of what the export of FE did there:
ML>   SQUISH            24,934 14-02-96 18:10
ML> Years ago before my time!

:)  Have a look at the batch file(s) for the IM/FE system and see where (the
directory) the Squish *.exe files are, or, if the previous sysop used a
"-c<pathname>\Squish.Cfg" parameter on the command-lines.  That's where the one
& only Squish.cfg file should be.  Dump the rest.  (I can make brave statements
like that from this distance. :-)

Did he auto-generate a fresh Areas.BBs/Squish.Cfg pair of files during his
BATch operation?  (Gee, I thought I was the only sysop in Fido to do that.)

Did any of the above help, Mike?

ML> Thus, from your perspective, is the fact that this thing was laid out
ML> with all this stuff scattered all over heck and back, resposible?
ML> Before I just go copying again, you would advise that I simply
ML> conform all this to what is in the E:\MAIL directory for the MAILER
ML> ??

I'd say to slip the previous sysop a couple of six-packs of Bud and employ him
as a 'consultant' to sort the crap out, to suit your needs.  :-)  But, that's
just what I would do...

Pity you aren't running BinkD.  I could have blown a couple of hours running
through a zipped-up copy of the hub config.<sfx: finger-down-throat>  ;-)

Cheers,
Paul.

--- BT-W32 2.60XEg6/BinkD-W32 0.9.4
* Origin: Road Kill on the Information Super Dirt Road (ZMH only) (3:640/384)

You are viewing proxied material from vert.synchro.net. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.