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", in the netmail directory. * In Squish areas it's a file called ".SQL", in the same directory as the other .* files that make a Squish area. * For a JAM area it's called ".JLR", in the same directory as the other .* 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.) Groping back through the grey matter, back about a year, I think the *.msg netmail lastread pointer file was called "0", 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". 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\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. ;-) 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) .