Virtual Private Server (VPS) Hosting provided by Central Point Networking cpnllc.com
For some reason, the "Nodelist" and "Recent Callers" features are not working.
| Sysop: | Ray Quinn |
|---|---|
| Location: | Visalia, CA |
| Users: | 60 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 69:30:00 |
| Calls: | 12 |
| Files: | 12,938 |
| Messages: | 99,240 |
Check out the US 99 menu above for links to information about US Highway 99, after which the US 99 BBS is named.
Be sure to click on the Amateur Radio menu item above for packet BBSes, packet software, packet organizations, as well as packet how-to's. Also included is links to local and some not-so-local Amateur Radio Clubs.
I have Radius 4.010 runnimg on XP along with Synchronet 3.15b. One of my problems is that any files from my Interbbs doors are not sent to the hubs until 1. A netmail message is created to any system (no matter if its the doors hub or not) or 2 I create a manual Normal Poll.
They are all listed in the Outbound Tab and sit until the 1st scheduled poll of that day (Midnight), it wont send them on the regular hourly polls after that. I did notice that all net messages for these files are #'d 2.msg, 3.msg, 4.msg, etc, which is strange as 1.msg is never there. That is until a netmail message is created from the BBS. It becomes 1.msg and then everything works as it should, polls all systems and delivers the files and messages. I can't figure this out, why message 1.msg is never created for the door files. Any help would be appreciated.
I have Radius 4.010 runnimg on XP along with Synchronet 3.15b.
They are all listed in the Outbound Tab and sit until the 1st
scheduled poll of that day (Midnight), it wont send them on the
regular hourly polls after that. I did notice that all net messages
for these files are #'d 2.msg, 3.msg, 4.msg, etc, which is strange
as 1.msg is never there. That is until a netmail message is created
from the BBS. It becomes 1.msg and then everything works as it
should, polls all systems and delivers the files and messages.
I can't figure this out, why message 1.msg is never created for the
door files. Any help would be appreciated.
exists?They are all listed in the Outbound Tab and sit until the 1st
scheduled poll of that day (Midnight), it wont send them on the
regular hourly polls after that. I did notice that all net messages
for these files are #'d 2.msg, 3.msg, 4.msg, etc, which is strange
as 1.msg is never there. That is until a netmail message is created from the BBS. It becomes 1.msg and then everything works as it
should, polls all systems and delivers the files and messages.
what tool are you using that creates 1.MSG when a higher numbered MSG
the next message created should be at the end of the line, not at the beginning... UNLESS (read on)...Synchronet is creating (or SBBSecho to be exact) the 1.msg when ever a
theI can't figure this out, why message 1.msg is never created for 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
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...I dont know what is in it as I have never looked. I will get back to you on that.
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 removingthe
1.MSG file? it should never be removed if it is the highwater mark... forone
thing, it tells the next MSG number to be used if there are no MSGs in the directory...Yes, after being sent, the out dir is empty. I would think its Radius
what specific door games are these you are having problems with?
No, Synchronet is set for Binkley-type. All mail exported from Synchronet functions in Radius fine.I have Radius 4.010 runnimg on XP along with Synchronet 3.15b.
I know stuff all about Synchro, except where to find reference dox for it on the 'net. :)
Step #1: Radius is a "FLO mailer". In your Synchronet's FidoNet Packet Toss configuration...
--- 8< ---
Mailer Type:
Selecting this option will toggle between the mailer types supported
by SBBSecho, either FrontDoor (message attach) type mailers or Binkley
(FLO file) type mailers. Choose the one that matches your front-end
mailer type.
--- 8< ---
It should be defined as a Binkley-type mailer.
Did that help?
It should be defined as a Binkley-type mailer.
Did that help?
No, Synchronet is set for Binkley-type. All mail exported from
Synchronet functions in Radius fine.
They are all listed in the Outbound Tab and sit until the 1st scheduled poll of that day (Midnight), it wont send them on the regular hourly polls after that. I did notice that all net
messages for these files are #'d 2.msg, 3.msg, 4.msg, etc,
which is strange as 1.msg is never there. That is until a
netmail message is created from the BBS. It becomes 1.msg and
then everything works as it should, polls all systems and
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)...
Synchronet is creating (or SBBSecho to be exact) the 1.msg when
ever a netmail or echomail message is exported.
I can't figure this out, why message 1.msg is never created for
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...
I dont know what is in it as I have never looked. I will get back
to you on that.
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...
Yes, after being sent, the out dir is empty. I would think its
Radius removing the *.msg files and their corresponding door files attached to them.
Thats what I thought as well, no matter what is creating 1.msg,
what ever prg runs next, should create the next *.msg in line. But
the InterBBS doors seem to be creating message #s 2 if the folder
is empty, or the next one in line if 2.msg or what # isalready
there.
what specific door games are these you are having problems with?
BRE, FE, WaHoo, BJ, FC, TAL, LORD, all the InterBBS doors I have installed. There is not one in specific, its all of them, no
matter which one runs 1st and creates the outbound packet. If BRE
runs is outbound maint 1st, it creates 2.msg. If FE does its 1st,
it creates 2.msg. It all depends on what door files are received
from the hub. I have it so that the batch file looks for specific
inbound door files and then runs that doors inbound/outbound maint.
If no BRE files arrive, it does not run its interbbs maint.
It should be defined as a Binkley-type mailer.
Did that help?
No, Synchronet is set for Binkley-type. All mail exported from
Synchronet functions in Radius fine.
Synchronet is creating (or SBBSecho to be exact) the 1.msg whenSorry for the delay, I was called away on business, that pesky work always seems to get in the way!
ever a netmail or echomail message is exported.
ok... that sounds fine...
I can't figure this out, why message 1.msg is never created for
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...
I dont know what is in it as I have never looked. I will get back
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...
Yes, after being sent, the out dir is empty. I would think its
Radius removing the *.msg files and their corresponding door files 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...
Thats what I thought as well, no matter what is creating 1.msg,
what ever prg runs next, should create the next *.msg in line. But
the InterBBS doors seem to be creating message #s 2 if the folder
is empty, or the next one in line if 2.msg or what # isalready
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...
BRE, FE, WaHoo, BJ, FC, TAL, LORD, all the InterBBS doors I have installed. There is not one in specific, its all of them, no
matter which one runs 1st and creates the outbound packet. If BRE
runs is outbound maint 1st, it creates 2.msg. If FE does its 1st,
it creates 2.msg. It all depends on what door files are received
from the hub. I have it so that the batch file looks for specific inbound door files and then runs that doors inbound/outbound maint.
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...
It should be defined as a Binkley-type mailer.
Did that help?
No, Synchronet is set for Binkley-type. All mail exported from Synchronet functions in Radius fine.
that's sync but what about those doors? they need their tools to be set to B format, too... then they won't be writing MSG files in a netmail area... instead they'll be creating ?LO files in the outbound directory and putting game data archives somewhere where those ?LO files can find them for sending
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....
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?
that's sync but what about those doors? they need their tools to be
set to B [...]
format, too... then they won't be writing MSG files in a netmail area... instead they'll be creating ?LO files in the outbound directory and
putting game data archives somewhere where those ?LO files can find
them for sending
I have tried going in to their configs, setting them from Bink to
FD, saving, go back and change to Bink and save. None of the
create ?LO files, just MSG.
I am baffled.