Subj : Radius Does Not Send files until Netmail or Echomail posted To : mark lewis From : Jeff Earle Date : Sun May 05 2013 12:31:53 Re: Radius Does Not Send files until Netmail or Echomail posted By: mark lewis to Jeff Earle on Tue Apr 30 2013 14:15:03 > Synchronet is creating (or SBBSecho to be exact) the 1.msg when > JE> ever a netmail or echomail message is exported. > > ok... that sounds fine... > > > JE> I can't figure this out, why message 1.msg is never created for > > JE> the door files. Any help would be appreciated. > > > > what is the content of that 1.MSG file? is it actually a message or > > is it the highwater mark instead? traditionally speaking, 1.MSG is > > not a message but a holder for the highest/last processed MSG file > > counter... it is known as the highwater mark... some software chose > > to use other files for this purpose to avoid confusion but then you > > run into problems similar to this... > JE> I dont know what is in it as I have never looked. I will get back > JE> to you on that. > > what did you find out? Sorry for the delay, I was called away on business, that pesky work always seems to get in the way! 1.msg is a normal file attach message from 1 of the doors. There is a file in the OUT folder called lastread which would be the high water mark. I watched the folder while a connectiong was made. I see that as usual at midnight all files are sent. As files were being received, the batch file runs that imports the door files, and creating new outbound files at the same time. This is where 1.msg was coming from. As a result, 1.msg was sent in this same connection as the batch completed before the connection to the hub did. So when you look at the out folder after everything has completed, 1.msg is missing (already sent) and 2.msg and so on are there. Hmmmm.... > > > then comes the question of are those MSG files removed after they > > have been processed or are they simply marked as having been sent? > > what is removing the 1.MSG file? it should never be removed if it is > > the highwater mark... for one thing, it tells the next MSG number to > > be used if there are no MSGs in the directory... > JE> Yes, after being sent, the out dir is empty. I would think its > JE> Radius removing the *.msg files and their corresponding door files > JE> attached to them. > > ok... did this ever work properly before or is this the first time you've se > it all up? > > it sounds like you are running those tools in File Attach mode instead of > binkley style BSO mode which ARGUS, RADIUS and TAURUS operate in... > > JE> Thats what I thought as well, no matter what is creating 1.msg, > JE> what ever prg runs next, should create the next *.msg in line. But > JE> the InterBBS doors seem to be creating message #s 2 if the folder > JE> is empty, or the next one in line if 2.msg or what # isalready > JE> there. > > > what specific door games are these you are having problems with? > > well, if 1.MSG is the highwater mark and it is being removed and there are n > other MSG files left, then there is nothing to indicate what the next messag > number should be... effectively that area gets renumbered from the beginning > every time but that should be no problem as long as nothing overwrites an > existing MSG... > > JE> BRE, FE, WaHoo, BJ, FC, TAL, LORD, all the InterBBS doors I have > JE> installed. There is not one in specific, its all of them, no > JE> matter which one runs 1st and creates the outbound packet. If BRE > JE> runs is outbound maint 1st, it creates 2.msg. If FE does its 1st, > JE> it creates 2.msg. It all depends on what door files are received > JE> from the hub. I have it so that the batch file looks for specific > JE> inbound door files and then runs that doors inbound/outbound maint. > JE> If no BRE files arrive, it does not run its interbbs maint. > > ok... it sounds like these tools are assuming that there are other existing > files and highwater mark so they are not messing with them at all... > > it has been so long that i've run ARGUS, RADIUS or TAURUS that i don't recal > if they can even do file attach mode... > > [time passes] > > wow that took some deep rummaging... i finally found an english ARGUS.HLP > file... yes, these mailers use BSO (Binkleyterm Style Outbound) instead of f > attach style like frontdoor... you need to adjust those tools to use BSO > instead... this would be similar to configuring them for use with the origin > POTS dial-up binkleyterm mailer or the current binkd mailer... I checked all the doors, they are set to Binkley (BRE, TAL, FE, AB1, AB2, GAC BJ, FC & WH). Do they need to be re-stalled to get set right? Thanks Mark Vorlonze Sysop - Mystic Realms mysticrealms.myddns.com --- SBBSecho 2.12-Win32 * Origin: Mystic Realms - Angel Voices, Nature's Alchemy (1:250/468) .