Subj : Radius Does Not Send files until Netmail or Echomail posted To : Jeff Earle From : mark lewis Date : Tue Apr 30 2013 14:15:03 > JE> They are all listed in the Outbound Tab and sit until the 1st > JE> scheduled poll of that day (Midnight), it wont send them on the > JE> regular hourly polls after that. I did notice that all net > JE> messages for these files are #'d 2.msg, 3.msg, 4.msg, etc, > JE> which is strange as 1.msg is never there. That is until a > JE> netmail message is created from the BBS. It becomes 1.msg and > JE> then everything works as it should, polls all systems and > JE> delivers the files and messages. > > what tool are you using that creates 1.MSG when a higher numbered > MSG exists? the next message created should be at the end of the > line, not at the beginning... UNLESS (read on)... JE> 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? > 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 set 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 no other MSG files left, then there is nothing to indicate what the next message 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 MSG 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 recall 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 file 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 original POTS dial-up binkleyterm mailer or the current binkd mailer... )\/(ark --- * Origin: (1:3634/12.42) .