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?
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.
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.
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
The general reaction to inclusion is, that a higher level C should not
make any changes to the segments offered for inclusion.
I will count on my North American brethren and sistern to laugh that away...
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.
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?
* 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)
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?
Does it really though?
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 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...
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.
| Sysop: | Nelgin |
|---|---|
| Location: | Plano, TX |
| Users: | 513 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 00:09:46 |
| Calls: | 8,291 |
| Calls today: | 4 |
| Files: | 15,520 |
| Messages: | 928,872 |