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:15:48 |
| Calls: | 12 |
| Files: | 12,938 |
| Messages: | 99,215 |
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.
Yesterday I received a new seg from R13, but it was obviously
corrupted somewhere along the way such that the segment was full of non-printable high-ascii garbage.
When I ran the dailylist last night, makenl left R13 out of the Zone1 dailylist.
Shouldn't makenl_ng have just selected the previous day's segment for
R13 if "today's" segment was bad or not present?
11 Dec 14 14:11, you wrote to all:
Yesterday I received a new seg from R13, but it was obviously
corrupted somewhere along the way such that the segment was full of
non-printable high-ascii garbage.
When I ran the dailylist last night, makenl left R13 out of the Zone1
dailylist.
Shouldn't makenl_ng have just selected the previous day's segment for
R13 if "today's" segment was bad or not present?
Can you provide logfiles so I can investigate this further?
Shouldn't makenl_ng have just selected the previous day's segment
for R13 if "today's" segment was bad or not present?
Can you provide logfiles so I can investigate this further?
Sure, Andrew, I'll send them over. Thanks :)
Yesterday I received a new seg from R13, but it was obviously
corrupted somewhere along the way such that the segment was full
of non-printable high-ascii garbage.
When I ran the dailylist last night, makenl left R13 out of the
Zone1 dailylist.
Shouldn't makenl_ng have just selected the previous day's segment
for R13 if "today's" segment was bad or not present?
--- BBBS/Li6 v4.10 Dada-2 * Origin: Prism bbs (1:261/38)
Sure, Andrew, I'll send them over. Thanks :)Got them. NetMail on it's way to you for more info.
Sure, Andrew, I'll send them over. Thanks :)
Got them. NetMail on it's way to you for more info.
Sad other nc does not benefit from netmail :(
At this point, the issue appears to have happened on Janis' system. I'm
attempting to gather information that will allow me to reproduce the issue, so
that it can be fixed.
Janis has already contacted the coordinator involved.
At this point, the issue appears to have happened on Janis' system.
I'm attempting to gather information that will allow me to reproduce
the issue, so that it can be fixed.
Janis has already contacted the coordinator involved.
And there have been no problems since, just wanted to let you know.
:)
Happy New Year to all :)
Good. I have not been able to reproduce the circumstances that led to the corrupted segment file. However, I am looking at the logic for handling update files, to ensure that the segment in the master directory is not overwritten until the update is validated as correct.
Although I applaud that the update is validated, be aware that that requires that the update is generated by makenl. Some RC's collate their segement by other means and do not provide a valid CRC in the first
line.
Good. I have not been able to reproduce the circumstances that
led to the corrupted segment file. However, I am looking at the
logic for handling update files, to ensure that the segment in
the master directory is not overwritten until the update is
validated as correct.
Although I applaud that the update is validated, be aware that that
requires that the update is generated by makenl. Some RC's collate
their segement by other means and do not provide a valid CRC in the
first line.
Although I applaud that the update is validated, be aware thatRunning it through ERRFLAGS prior to submitting would take care of
that requires that the update is generated by makenl. Some RC's
collate their segement by other means and do not provide a valid
CRC in the first line.
that.
my wish for 2015 is to see makenl does not create invalid nodelists, errflags is good, but that programing should have being added to makenl long time ago
my wish for 2015 is to see makenl does not create invalid nodelists, errflags is good, but that programing should have being added to makenl long time ago
I will count on my North American brethren and sistern to laugh that away...
The general reaction to inclusion is, that a higher level C should not
make any changes to the segments offered for inclusion.
It's been happening for at least 24 years so why the FTSC has not documented this as "current practice" really escapes me.
It's been happening for at least 24 years so why the FTSC has not
documented this as "current practice" really escapes me.
Just write a proposal and submit it to the FTSC and we'll try to
evaluate the merits of it.
The general reaction to inclusion is, that a higher level C
should not make any changes to the segments offered for
inclusion.
In a way this makes sense. The lower level C knows, that he
submits a segment with errors, or ignores the results of the
testrun, that is available to him.
The general reaction to inclusion is, that a higher level C should not
make any changes to the segments offered for inclusion.
I tend to disagree.
When I became ZC in 1994 auto-correction of segments in Z2 was
already part of the deal by the then previous-ZC. I think it
started with Felix Kasza.
It's been happening for at least 24 years so why the FTSC has not documented this as "current practice" really escapes me.
in a plain old text editor with no assistance from any software... there is no guarrantee that they had any sort of ""testrun"" or "validation" of their segment other than that returned by the next *C up the chain... those *Cs should be able to edit the submitted segment to fix it so as to ensure that the net or region covered by the broken segment is not left out of their segment being passed on upstream...
let's not fall into the fallacy that everyone can even run makenl or any other nodelist tool or that they even have the desire to do so...
When I became ZC in 1994 auto-correction of segments in Z2 was already part of the deal by the then previous-ZC. I think it started with Felix Kasza.
It's been happening for at least 24 years so why the FTSC has not documented this as "current practice" really escapes me.
My headaches are totally different than the ones of FTSC-members.its just best pratice, not must
Besides, Roy claims I can't spell.not alone here either
It's been happening for at least 24 years so why the FTSC has not
documented this as "current practice" really escapes me.
Perhaps because it was ONLY being done in Z2, and no other zone?
Perhaps because it was ONLY being done in Z2, and no other zone?
2 things come to mind:
* The FTSC has documented pet projects of individual members in the past with
absolute zero-relevance. There even is the case of someone who got
himself
elected years ago to push something through that no-one cared about and then quit.
* If something is being done all over zone-2 then it is relevant
* If something is being done all over zone-2 then it is relevant
It is still ONLY Z2 and not the other 3 zones.
I have no doubt about that. That however is political, and not
technical.
It is still ONLY Z2 and not the other 3 zones.
(yeah I know what you think of Z4)
It is still ONLY Z2 and not the other 3 zones.
Just so you are aware, there is a file-distribution for ERRFLAGS.ZC2 which is the parameter file in use here. Whenever there's a change, several *Cs update their systems, so it's not just a ZC2-thingie.
Z4 is a joke ... 1 active node. Basically that one node operates as a point of Janis' system or mine, depending how you look at it.
Everyone knows its presence is a political thing too ... even the deniers know it, but will deny that too...
* If something is being done all over zone-2 then it is relevant
It is still ONLY Z2 and not the other 3 zones.
Irrelevant. What's relevant is that it's actually something that can be put into a technical definition file.
As I said before, if Ward had put it into writing and submitted it to
the FTSC, it would have been judged by it's merits. Not that I think it would have any real value to add to our FTN -- but at least he could have given it a try. We've seen far more queer proposals during the decades... 8-)
Why. The FTSC documents general practice. If it is only done in one
zone, it is not general practice.
Not even if that zone covers 80% of the membership?
Not even if that zone covers 80% of the membership?
Does it really though?
Does it really though?
Actually, it's irrelevant.
I'm pretty certain the real size of the overal nodelist is less than 50% active people than those listed in it. What the distribution would be, I don't know.
Does it really though?
Actually, it's irrelevant.
I'm pretty certain the real size of the overal nodelist is less
than 50% active people than those listed in it. What the
distribution would be, I don't know.
I'll agree with you there.
as far as "active" goes in areas that can be found in the public eye, that's probably pretty true... we can't count private areas and no one has to actually post anything anywhere to be a member of the network...
that said, eliminating duplicates, there's 1948 operator names listed in nodelist.006... that's with eliminating obvious non-names... there's only one or two that may be the same person listed with two variations of their name...
eg: FA_Stare Fred_A_Stare Fred_Stare (ficticious example)
Still, I think there is a lot of dead wood in the nodelist, at least in Z1 and 2. I have no idea about Z3
There is none in Z3, % wise Z4 tops all.
There was a node from Argentine, testing Binkd, yesterday.
Ward Dossche wrote to Joe Delahaye <=-
I'm pretty certain the real size of the overal nodelist is less than
50% active people than those listed in it. What the distribution would
be, I don't know.
that said, eliminating duplicates, there's 1948 operator names
listed in nodelist.006... that's with eliminating obvious
non-names... there's only one or two that may be the same person
listed with two variations of their name...
eg: FA_Stare Fred_A_Stare Fred_Stare (ficticious example)
Still, I think there is a lot of dead wood in the nodelist, at
least in Z1 and 2. I have no idea about Z3
there might be but how is "dead wood" being determined? counting posts from a system can't be used because that's never been a requirement for membership... in fact, the only requirement was the ability to send and receive netmail... right?
There is none in Z3, % wise Z4 tops all.
there might be but how is "dead wood" being determined? counting
posts from a system can't be used because that's never been a
requirement for membership... in fact, the only requirement was
the ability to send and receive netmail... right?
If a system cannot be contacted, or does not contact his NC etc, I
would consider that pretty dead in most cases. I have one or two
nodes, but I occassionally see posts by them, so I know they are
still alive.
how would you have viewed my system when it ran on auto-pilot for a year or two while i was burnt out and staying away from it and most other electronics?? i /might/ have posted 5-10 messages in that period... i think i peeked in on the system once every 3 or 4 months... it certainly wasn't dead or deadwood... it was very active processing and distributing mail and files...
there might be but how is "dead wood" being determined? counting
posts from a system can't be used because that's never been a
requirement for membership... in fact, the only requirement was
the ability to send and receive netmail... right?
If a system cannot be contacted, or does not contact his NC etc,
I would consider that pretty dead in most cases. I have one or
two nodes, but I occassionally see posts by them, so I know they
are still alive.
how would you have viewed my system when it ran on auto-pilot for a
year or two while i was burnt out and staying away from it and most
other electronics?? i /might/ have posted 5-10 messages in that
period... i think i peeked in on the system once every 3 or 4
months... it certainly wasn't dead or deadwood... it was very active processing and distributing mail and files...
mark lewis wrote to Joe Delahaye <=-
how would you have viewed my system when it ran on auto-pilot for a
year or two while i was burnt out and staying away from it and most
other electronics??
mark lewis wrote to Joe Delahaye <=-
how would you have viewed my system when it ran on auto-pilot for
a year or two while i was burnt out and staying away from it and
most other electronics??
Did it have a functioning mailer and a non-PVT nodelist entry?
I don't think a minimum posting criteria is relevant, but knowing
which mailers are up is...