I have multiple message abses that are now in the 10,000's of messages
and it only displays numbers like xxxx instead of xxxxx
I have multiple message abses that are now in the 10,000's of messages
and it only displays numbers like xxxx instead of xxxxx
Is there any way I can add one more thousandth?
I have multiple message abses that are now in the 10,000's of messages
and it only displays numbers like xxxx instead of xxxxx
Is there any way I can add one more thousandth?
This is a small change to a prompts 400 and 401 I think. It does not require any change to Mystic code, its just a poorly configured default that I should probably fix in the default installation.
If you change the |$L04 to |$L05 on those prompts you should be good to go:
400 |12|&5|08|23|$L05|&1|16
401 |12|&5|07|$L05|&1
Thanks Jeff... not poorly configured...
Thanks Jeff... not poorly configured... just some people have bigger archives than others. Also can you please increase the memory on the index reader... when I had all my usenet going into Mystic it was
crashing things the code was out of memory.
Thanks Jeff... not poorly configured... just some people have bigger
usenet messages, I'm at just over 1.2 million messages online. I can run the Indexed Message Reader on here. It takes about a minute or so for it to load everything, but it's still usable.
usenet messages, I'm at just over 1.2 million messages online. I can the Indexed Message Reader on here. It takes about a minute or so for to load everything, but it's still usable.
I've managed to reduce the time it takes to start up the reader when
using giant message bases by quite a bit in the next alpha. The hold up is when it is calculating the statistics when you have a ton of unread messages.
On my test system it takes less than half of the time in A34 as it did
in A33.
As you mention, the index reader should work fine with millions of messages. The only limitation is that it can only support 10,000 message bases, but that is something I can easily extend if anyone were to get close to that number.
Just out of curiosity, about how many messages did you have when you were running Mystic before? The reason I'm asking, is right now, with the usenet messages, I'm at just over 1.2 million messages online. I can run the Indexed Message Reader on here. It takes about a minute or so for it to load everything, but it's still usable.
On my test system it takes less than half of the time in A34 as it did
in A33.
As you mention, the index reader should work fine with millions of messages. The only limitation is that it can only support 10,000 message bases, but that is something I can easily extend if anyone were to get close to that number.
I know I'm not even close to that. Right now, I'm around 2400 message bases. I'm in the process of trimming some of the dead echos, and
networks from the system as well.
I had a traditional spinning Hard drive at the time that I was
crashing... and boy did it ever thrash that drive hard when I used
messages. One thing that I may suggest that would help things
tremendously is to perhaps consider not scanning message bases for personal messages that are flagged as newsgroup... just then look at the
But when I had everything on mystic I would hit the I go off and put on a kettle of water for tea wait for it to boil and come back to it still counting things up. And eventually it started to crash... and in retrospect that hard drive failed so it's entirely possible that could have been the culprit too.
On my test system it takes less than half of the time in A34 as it di in A33.
I had a traditional spinning Hard drive at the time that I was
crashing... and boy did it ever thrash that drive hard when I used
JAM can only grow to a certain size per message base before it cannot
grow any bigger. I did put a check in to stop Mystic from crashing if
the .JDT file gets too big, but that doesn't really solve the problem which is simply that you've reached the end of the road as far as what
JAM can do.
I've thought about making an optional "JAM64" format which would allow file sizes up to 18 terabytes. This revised JAM would be enough to
store billions of messages in a single base, but the problem with that
is that it wouldn't work with existing 3rd party JAM utilities.
I think creating this new format is a good move and just allow users to decide when they set up their bases which format they want to select. You could make it a default message base setting but allow that to be
changed on a per message base basis.
Everything is great UNTIL... You hit the *JAM file size limitation*
JAM can only grow to a certain size per message base before it cannot
grow any bigger. I did put a check in to stop Mystic from crashing if
I've thought about making an optional "JAM64" format which would allow file sizes up to 18 terabytes. This revised JAM would be enough to
store billions of messages in a single base, but the problem with that
is that it wouldn't work with existing 3rd party JAM utilities.
JAM can only grow to a certain size per message base before it cannot grow any bigger. I did put a check in to stop Mystic from crashing i
What is the current limitation of the JAM message base?
I personally don't think it would be worth it at this point. How many systems are going to need that size of a message base available? As far
What is the current limitation of the JAM message base?
None of the file sizes can grow past 4.2 gigs in size or it will blow
up. Dates will not work after 2038, CRC32 isn't a good way to hash for
To give some perspective 1 million messages with 250 lines in each was around 20 gigs, or 4 times too big for JAM. So in that case you are looking at a cap of maybe ~250,000 messages, drastically more or less depending on message content.
I personally don't think it would be worth it at this point. How many systems are going to need that size of a message base available? As f
I can't say but I do know that at least one person has hit the limit
thus far.
Mystic works perfectly fine with millions of messages in a single base. All readers are instant and snappy in A35 and it doesn't use more memory to scroll around a list of 1,000,000 messages than it does to do so with 2 messages. The index reader calculation was so fast that at first I thought it wasn't working!
To give some perspective 1 million messages with 250 lines in each
was around 20 gigs, or 4 times too big for JAM. So in that case you
are looking at a cap of maybe ~250,000 messages, drastically more or
less depending on message content.
Thank you. That does put it into perspective for me. I knew there was
a limit to JAM, but couldn't remember what it was... The joys of
getting old... :)
Mystic works perfectly fine with millions of messages in a single
base. All readers are instant and snappy in A35 and it doesn't use
more memory to scroll around a list of 1,000,000 messages than it
does to do so with 2 messages. The index reader calculation was so
fast that at first I thought it wasn't working!
Don't tell Mark Lynch that...
according to him Jam does not have size limitations. The biggest base
I had going were the UFO bases, and the grandaddy food cooking
newsgroup.
directory... that was causing them to run into a slow down in the OS
when it enumerated the files in a directory... it was found that
limiting the number of JAM bases to a specific directory brought the
speed back up again... IIRC, there was a problem with the OS and enumerating files when there were more than 1024 files in a directory...
since JAM has four files per base, the easiest thing to do was for the
what we did during the BETA phase of JAM development and today we have
the bases split into alpha directories so those beginning with 'a' are
in the JAM/a/ directory and similar with others... plus we're grouping by
I personally don't think it would be worth it at this point. How many systems are going to need that size of a message base available? As far
as I know, there are only a couple of systems that have a high retention period for messages. While it would be nice to have those capabilities,
I don't see a practical use for it. But that is just my opinion. :)
who is that???
directory... that was causing them to run into a slow down in the OS
when it enumerated the files in a directory... it was found that
limiting the number of JAM bases to a specific directory brought the
speed back up again... IIRC, there was a problem with the OS and
enumerating files when there were more than 1024 files in a
directory...
I wonder if that might be part of the problem on my end. While I do
have the files separated by network, I still have directories with
11,577 files, 1586 files and 1204 files. Perhaps it would be a good
idea if I broke those down a bit...
since JAM has four files per base, the easiest thing to do was for
the
I thought the JAM bases only had four files per base... Under Windoze
10 64bit here, Mystic has seven files per base... For example:
mystic.jdt
mystic.jdx
mystic.jhr
mystic.jlr
mystic
mystic.scn
mystic.xlr
what we did during the BETA phase of JAM development and today we
have the bases split into alpha directories so those beginning with
'a' are in the JAM/a/ directory and similar with others... plus we're
grouping by
That's not a bad idea. As I said, I've got them divided by network
here. At least the larger networks, and usenet areas I think I should split up some more.
Don't tell Mark Lynch that... according to him Jam does not have size limitations. The biggest base I had going were the UFO bases, and the grandaddy food cooking newsgroup.
mystic.jdt
mystic.jdx
mystic.jhr
mystic.jlr
mystic
mystic.scn
mystic.xlr
the jdt, jdx, jhr, and jlr files are the only ones related to JAM... the others are something for the BBS and its tosser, i guess...
I personally don't think it would be worth it at this point. How many systems are going to need that size of a message base available? As f as I know, there are only a couple of systems that have a high retent period for messages. While it would be nice to have those capabilitie I don't see a practical use for it. But that is just my opinion. :)
I am one of them :-) I had ten years retention on my newsgroups at one tim and thought that the JAM base was more than capable of handling them. See like it was at the time.
I have no idea who that is, but I can assure you they're mistaken. This is something that is "debatable" - its 100% certain. :)
The JAM index file uses a byte position and its an unsigned 32-bit integer which has a max value of 4,294,967,295. The message header itself also ha byte position stored as an unsigned 32-bit integer which has the same prob
I am one of them :-) I had ten years retention on my newsgroups at
one tim and thought that the JAM base was more than capable of
handling them. See like it was at the time.
Who do you have as your newgroup provider?
Who do you have as your newgroup provider?
It's a private server from the university... probably one of the few Dec PDP11
micros that are still in operation... and there's much more than 10 years there.
Who do you have as your newgroup provider?
It's a private server from the university... probably one of the few
Dec PDP11 micros that are still in operation... and there's much more
than 10 years there.
--- Platinum Xpress/Win/WINServer v3.0pr5
* Origin: Neptune's Lair - Olive Branch MS - winserver.org (1:116/17)
It's a private server from the university... probably one of the few
Dec PDP11 micros that are still in operation... and there's much more
than 10 years there.
Ah, ok, cool! :)
Re: Re: Increasing display digits
By: Robert Wolfe to ALLEN PRUNTY on Mon Jul 24 2017 08:46 pm
It's a private server from the university... probably one of the few ->> Dec PDP11 micros that are still in operation... and there's much more ->> than 10 years there.
Ah, ok, cool! :)
Yeah... and they have a pretty good amoutn of disk space on it. They have ->adapted a modern 5gb hard drive raid system to it. They are soon goin to shut
down the whole vax cluster and run it on one of the newer multi-core macs on a
virtual machine environment.
I know that a lot of the educational and programming newsgroups go back to the
early 1980's
Well, if you need a news feed, I can give you one via FTN :) You just need to tell me what groups you want so I can request them from my uplink and put them in place :)
| Sysop: | Winzlo |
|---|---|
| Location: | Minnesota, USA |
| Users: | 11 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 495941:47:16 |
| Calls: | 82 |
| Files: | 1,070 |
| D/L today: |
27 files (11,920K bytes) |
| Messages: | 286,991 |