[news.software.b] Max article number reached?

law@ioe.lon.ac.uk (Lindsay Wakeman) (04/25/91)

(Apologies to those who have seen this request - I got my distribution
wrong the first time around)

We have a problem with relaynews - it reports errors (many!) about
an article number being too large (100000) for the max field of 5 digits.
This has affected the junk newsgroup (possible overflow of articles with
bad newsgroups?)

Anyway, it wouldn't go beyond 99999. All the articles have now been expired
but /usr/lib/news/sys still has 99999 as the last article number.

How do we reset this - isn't it normally done automatically?

I don't have my original sources online so it isn't easy to check.
I'd be very grateful for any clues - Thanks.

Lindsay


PS we run Cnews 6.4 but not very up to date with patches. Could this be the 
problem?
-- 
JANET: law@uk.ac.lon.ioe			| Lindsay Wakeman
EARN/BITNET: law%ioe.lon.ac.uk@ukacrl.bitnet	| Institute of Education
INTERNET:law%ioe.lon.ac.uk@nsfnet-relay.ac.uk	| 20 Bedford Way London WC1H OAL
UUCP: !mcvax!ukc!educ-isis!law			| VOICE +44 71 636 1500 ext.512

geoff@world.std.com (Geoff Collyer) (04/26/91)

Lindsay Wakeman:
> Anyway, it wouldn't go beyond 99999. All the articles have now been expired
> but /usr/lib/news/sys still has 99999 as the last article number.
> How do we reset this - isn't it normally done automatically?

Assuming that you mean /usr/lib/news/active, no, the fields are not
widened automatically.  The active file is (and always has been, I
believe) updated in place, so the fields must be made wide enough in
advance (that's why there are all those leading zeros).  To quote news(5):

	Both article-number fields are at least five digits wide.

To fix this problem forever (or until we need article numbers larger
than 32 bits anyway), lock the news system with locknews (see
newsmaint(8)), add 5 zeroes onto the left of the second field of each
line of the active file, and unlock the news system.

> PS we run Cnews 6.4 but not very up to date with patches. Could this be the 
> problem?

Where did you get your C News distribution from?  We don't number our
releases.
-- 
Geoff Collyer		world.std.com!geoff, uunet.uu.net!geoff

henry@zoo.toronto.edu (Henry Spencer) (04/26/91)

In article <1991Apr25.122242.1179@ioe.lon.ac.uk> law@ioe.lon.ac.uk (Lindsay Wakeman) writes:
>We have a problem with relaynews - it reports errors (many!) about
>an article number being too large (100000) for the max field of 5 digits...
>How do we reset this - isn't it normally done automatically?

No, it never has been, not by B News or C News.  There have to be enough
digis in the active-file field to begin with -- hence the leading zeros --
because it gets updated in place.  The fix is to add some more zeros on
the front manually.
-- 
And the bean-counter replied,           | Henry Spencer @ U of Toronto Zoology
"beans are more important".             |  henry@zoo.toronto.edu  utzoo!henry

law@ioe.lon.ac.uk (Lindsay Wakeman) (04/26/91)

OK - fixed now. You have to manually edit the article numbers in
/usr/lib/news/active (having first run /usr/lib/newsbin/maint/locknews)
and make them large enough fields (add a few zeros on the front, better
still zero altogether if no articles present - ie. 000000000 00000000 y

Thanks to Jerry Aguirre of Olivetti ATC, USA and Icarus Sparry of Bath
University, UK.

:-)

Lindsay

-- 
JANET: law@uk.ac.lon.ioe			| Lindsay Wakeman
EARN/BITNET: law%ioe.lon.ac.uk@ukacrl.bitnet	| Institute of Education
INTERNET:law%ioe.lon.ac.uk@nsfnet-relay.ac.uk	| 20 Bedford Way London WC1H OAL
UUCP: !mcvax!ukc!educ-isis!law			| VOICE +44 71 636 1500 ext.512

mrl@uai.com (Mark R. Ludwig) (04/27/91)

In article <1991Apr25.215042.25734@world.std.com>, geoff@world (Geoff Collyer) writes:
>To fix this problem forever (or until we need article numbers larger
>than 32 bits anyway), lock the news system with locknews (see
>newsmaint(8)), add 5 zeroes onto the left of the second field of each
>line of the active file, and unlock the news system.

The version of NEWSBIN/expire/upact I have (circa December, 1990)
explicitly rewrites the third field of NEWSCTL/active with 5
digits...if this hasn't been changed yet...$$
-- 
INET: mrl@uai.com       UUCP: uunet!uaisun4!mrl       PSTN: +1 213 822 4422
USPS: 7740 West Manchester Boulevard, Suite 208, Playa del Rey, CA  90293
WANT: Succinct, insightful statement to occupy this space.  Inquire within.

henry@zoo.toronto.edu (Henry Spencer) (04/27/91)

In article <1991Apr26.182609.23026@uai.com> mrl@uai.com (Mark R. Ludwig) writes:
>>... add 5 zeroes onto the left of the second field of each
>>line of the active file, and unlock the news system.
>
>The version of NEWSBIN/expire/upact I have (circa December, 1990)
>explicitly rewrites the third field of NEWSCTL/active with 5
>digits...

2 != 3.  If you read the upact coverage in expire(8) carefully, you will
find a discussion of why the second and third fields get treated differently.
-- 
And the bean-counter replied,           | Henry Spencer @ U of Toronto Zoology
"beans are more important".             |  henry@zoo.toronto.edu  utzoo!henry

jerry@olivey.ATC.Olivetti.Com (Jerry Aguirre) (04/27/91)

In article <1991Apr26.182609.23026@uai.com> mrl@uai.com (Mark R. Ludwig) writes:
>The version of NEWSBIN/expire/upact I have (circa December, 1990)
>explicitly rewrites the third field of NEWSCTL/active with 5
>digits...if this hasn't been changed yet...$$

The third field is not updated "in place" as the second field is.
Besides I think you will find that it writes it with a minimum of 5
digits, more if needed.  The update of the minart field involves
re-writing the entire active file so it can expand the field when it is
needed.

On the other hand I don't know why the minart could not be updated in
place just as the second field is.  That would eliminate the need to
lock out news processing while doing the update.

henry@zoo.toronto.edu (Henry Spencer) (04/27/91)

In article <50711@olivea.atc.olivetti.com> jerry@olivey.ATC.Olivetti.Com (Jerry Aguirre) writes:
>On the other hand I don't know why the minart could not be updated in
>place just as the second field is.  That would eliminate the need to
>lock out news processing while doing the update.

Alas, not so.  Apart from that being harder to do, the in-place updates are
done *in memory* by relaynews on a large-memory machine, and it rewrites the
entire active file in one shot when it's done, so you really have to lock
it out.
-- 
And the bean-counter replied,           | Henry Spencer @ U of Toronto Zoology
"beans are more important".             |  henry@zoo.toronto.edu  utzoo!henry

wisner@ims.alaska.edu (Bill Wisner) (04/28/91)

>                                   The fix is to add some more zeros on
>the front manually.

Or do what I did a few days ago:

% cat > widen < FnorD
#!/usr/bin/perl

while (<>) {
	($ng, $low, $high, $flag) = split;
	printf("%s %010d %010d %s\n", $ng, $low, $high, $flag);
}
FnorD
% chmod +x widen
% locknews
% mv active foo
% ./widen foo > active
% exit

Bill Wisner <wisner@ims.alaska.edu> Gryphon Gang Fairbanks AK 99775
bnug, dude
yeah
.

gemini@geminix.in-berlin.de (Uwe Doering) (04/29/91)

geoff@world.std.com (Geoff Collyer) writes:

>Lindsay Wakeman:
>> PS we run Cnews 6.4 but not very up to date with patches. Could this be the 
>> problem?
>
>Where did you get your C News distribution from?  We don't number our
>releases.

This number looks rather like the nn news reader release number. It's
currently at release 6.4.

      Uwe
-- 
Uwe Doering  |  INET : gemini@geminix.in-berlin.de
Berlin       |----------------------------------------------------------------
Germany      |  UUCP : ...!unido!fub!geminix.in-berlin.de!gemini

law@ioe.lon.ac.uk (Lindsay Wakeman) (04/30/91)

In <U7FQGOO@geminix.in-berlin.de> gemini@geminix.in-berlin.de (Uwe Doering) writes:

>geoff@world.std.com (Geoff Collyer) writes:

>>Lindsay Wakeman:
>>> PS we run Cnews 6.4 but not very up to date with patches. Could this be the 
>>> problem?
>>
>>Where did you get your C News distribution from?  We don't number our
>>releases.

>This number looks rather like the nn news reader release number. It's
>currently at release 6.4.

>      Uwe
>-- 
      Oops, yes you are quite right, I confused our nn release number
       with this in my effort to give some pertinent info. Silly. 
      It's all sorted now anyway.
      ..Lindsay
-- 
JANET: law@uk.ac.lon.ioe			| Lindsay Wakeman
EARN/BITNET: law%ioe.lon.ac.uk@ukacrl.bitnet	| Institute of Education
INTERNET:law%ioe.lon.ac.uk@nsfnet-relay.ac.uk	| 20 Bedford Way London WC1H OAL
UUCP: !mcvax!ukc!educ-isis!law			| VOICE +44 71 636 1500 ext.512