marms@sandia.UUCP (Mike Arms) (10/17/86)
We keep getting messages similar to this one forr groups having reached
a fairly high message number. Same with net.sf-lovers and net.women.
> Oct 16 10:16 vnews: Bitmap not large enough for newsgroup net.micro.mac
What is going on here, and how do I fix it? Is there some simple definition
to change for vnews? As it stands now, whenever this error message is given,
vnews dies and the screen is left in some very unusual mode where nothing
besides <break> is recognised. Any help would be greatly appreciated.
Mike Arms
uucp: ...{ucbvax | ihnp4!lanl | gatech}!unmvax!sandia!marmstjc@hrcca.UUCP (Tom Chapin) (10/21/86)
> We keep getting messages similar to this one forr groups having reached > a fairly high message number. Same with net.sf-lovers and net.women. > >> Oct 16 10:16 vnews: Bitmap not large enough for newsgroup net.micro.mac > Mike Arms We got this regularly for a while when our software was scrozzled. The active file got trashed, and before we recreated it, users ran news and got their .newsrc files trashed. Then when they hit a newsrgoup with many postings, the software assumed the postings began with article #1 up to the latest high number, which overran the bitmap. The simplest solution is to run 'expire -u' to update the beginning article number. Any normal expire will also run an 'expire -u' at the end of it. If this happened because you received news while expire was running, your history file may have problems, and you might wish to consider running 'expire -h' to search and destroy any articles the history file lost track of, and then an 'expire -r' to rebuild it from scratch. (Don't do it when you are about to get more news, or you will have the same problem again...sigh...) There are 'doexpire' scripts around which take care of this problem, but the best solution would most likely be to upgrade to version 2.11 which is sposed to fix things. -- ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~ Tom Chapin @ AT&T-RM, Hickory Ridge Conference Centre, Lisle, IL (312) 971-5652 & (312) 960-0481 {ihnp4,allegra}!hrcca!tjc Sitting quietly, doing nothing, Spring comes, and the grass grows by itself.
dhb@rayssd.UUCP (David H. Brierley) (10/21/86)
> We keep getting messages similar to this one forr groups having reached > a fairly high message number. Same with net.sf-lovers and net.women. > > > Oct 16 10:16 vnews: Bitmap not large enough for newsgroup net.micro.mac I have run into this problem on several newgroups and came up with what I think is a pretty good solution. Instead of randomly increasing the size of the bitmap every time I had a problem, I recoded the news software to use a dynamically sized bitmap. This way, no matter how many articles you have in a particular group you will never overflow the bitmap. If other people are interested in this I will post the changes after I get them working on version 2.11. The scheme that I am using is fairly efficient about memory usage so it should even work on small machines (it has to be efficient because I am running 2.10.1 which doesn't have the minimum article number stuff for offsetting the bitmap). Anyway, let me know if you are interested in this and if I get enough requests I will post the mods to mod.sources. -- Dave Brierley; Raytheon Co.; Portsmouth RI; (401)-847-8000 x4073 { allegra, gatech, ihnp4, linus!raybed2 } !rayssd!dhb
tonyb@peewee.uss.tek.com (Tony Birnseth) (10/23/86)
In article <285@rayssd.UUCP> dhb@rayssd.UUCP (David H. Brierley) writes: > We keep getting messages similar to this one forr groups having reached > a fairly high message number. Same with net.sf-lovers and net.women. > > > Oct 16 10:16 vnews: Bitmap not large enough for newsgroup net.micro.mac > The problem is not really in the bit map sizing, but rather in expire. Try running expire with the -I option (if your version of expire supports this). This option tells expire to ignore the 'Expires:' line in the header and to expire news based on the default or the time passed with the '-e' option. If your version of expire doesn't support the -I option, a 'find /usr/spool/news -mtime +60 -exec rm -f {} \;' should do the trick. Adjust the +nn to your comfort level. We have found articles in net.jokes and others that some ignorant sole's ego has decided that their joke should stick around till the turn of the century. This is not only self centered, but causes problems like the ones you are experiencing. One of the largest offenders is mod.conferences. Apparently it is necessary to let people know about upcomming conferences many months in advance. You could be selective in the find above that would only reduce specific newsgroups. You will be amazed at how fast the range of your bitmap will shrink. Tony Birnseth
rcd@nbires.UUCP (Dick Dunn) (10/24/86)
About the problem which shows up as: > > ...vnews: Bitmap not large enough for newsgroup net.micro.mac > The problem is not really in the bit map sizing, but rather in expire. Try > running expire with the -I option (if your version of expire supports this). > This option tells expire to ignore the 'Expires:' line in the header and to > expire news based on the default or the time passed with the '-e' option. I'm sure that there are people who already do this--and frankly, it's irresponsible. The "Expires:" line is put there for a purpose. There ARE those of us who have attempted to use it to create long-expiration articles which provide basic information to new readers of a group or which answer frequently-asked questions. If you arbitrarily blow away these articles, you're just contributing to largely-useless traffic on the net. If the software were more sophisticated, it would use some algorithm for handling sets which are sparse in one region and dense in another. That's a lot to ask someone to write just for a small problem, though. Instead of DISCARDING an article that someone has asked you to KEEP, why don't you MOVE the articles that cause a problem to some higher article number? It shouldn't be hard to do and it doesn't need to be done very often. The active file will tell you which newsgroup(s) are likely to become problems in the near future; you should be able to write a program to check the active file in about five minutes. > > We have found articles in net.jokes and others that some ignorant sole's > ego has decided that their joke should stick around till the turn of the > century... (Ignorant sole, my foot! (fishing for humor, there):-) Is there any facility in the net software that CAN'T be abused?! How does the one offense (needlessly long expiration) justify the other (violating the purpose of "Expires:"). > ...One of the largest offenders is mod.conferences. > Apparently it is necessary to let people know about upcomming conferences > many months in advance... How does a particular need become an offense? Seems to me that mod.confer- ences is just one of the places where longer expirations are justified. HEY--wait a minute--we must be missing LARGE amounts of news! Our mod.conferences' highest article number is currently 47. Does ANYbody have so many articles in that group that it's even close to becoming a problem??? -- Dick Dunn {hao,ucbvax,allegra,seismo}!nbires!rcd (303)444-5710 x3086 ...Don't lend your hand to raise no flag atop no ship of fools.
james@reality1.UUCP (james) (10/25/86)
In article <1768@tektools.UUCP> tonyb@peewee.uss.tek.com (Tony Birnseth) writes: >The problem is not really in the bit map sizing, but rather in expire. Try >running expire with the -I option (if your version of expire supports this). >This option tells expire to ignore the 'Expires:' line in the header and to >expire news based on the default or the time passed with the '-e' option. ... more descriptions of ways to prematurely expire articles ... I hope you don't make a habit of doing this with all.announce. While net.women & net.jokes almost certainly don't need long expire times in their articles, other newsgroups should probably be left alone. I would suggest expiring newsgroups in this manner only if those newsgroups have no need of long expirations... -- James R. Van Artsdalen ...!ut-ngp!utastro!osi3b2!james "Live Free or Die"