Hello!

I like to keep a lot of messages in some areas...
but looks like "feutil LINK" is limited?
fn_sysop now contains 21574 messages -> too much
nodes.024 contains 14877 messages -> too much
enet.sysop contains 8017 messages -> too much
skypoints contains 4996 messages -> this worked still :-)

are t here other JAM linkers avaible that don't have this problem?


o Steven Leeman,
)/\,[_) Sysop SkyNET Bbs
`T7 ]=[ steven@fido.be

--- Fidolook Lite FTN stub
* Origin: Another SkyNET Bbs Message (2:292/624.1)

Steve ..

I like to keep a lot of messages in some areas...
but looks like "feutil LINK" is limited?
fn_sysop now contains 21574 messages -> too much
nodes.024 contains 14877 messages -> too much
enet.sysop contains 8017 messages -> too much
skypoints contains 4996 messages -> this worked still :-)

If they are there you must have been using something else that would handle the
job. What were you using before?

Sleep well; OS/2's still awake! ;)

Mike @ 1:117/3001

--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)

I like to keep a lot of messages in some areas...
but looks like "feutil LINK" is limited?
fn_sysop now contains 21574 messages -> too much
nodes.024 contains 14877 messages -> too much
enet.sysop contains 8017 messages -> too much
skypoints contains 4996 messages -> this worked still :-)

are t here other JAM linkers avaible that don't have this
problem?

i don't see this problem on my system... are you sure you have enough room on the current drive for temp files?

)\/(ark


* Origin: (1:3634/12)

Hello, mark!
You wrote to "steven leeman" <steven.leeman@p1.f624.n292.z2.fidonet.org>to steven leeman on Mon, 16 Sep 2002 10:01:26 -0400:

I like to keep a lot of messages in some areas...
but looks like "feutil LINK" is limited?
fn_sysop now contains 21574 messages -> too much nodes.024 contains
14877 messages -> too much enet.sysop contains 8017 messages -> too
much skypoints contains 4996 messages -> this worked still :-)

are t here other JAM linkers avaible that don't have this problem?

i don't see this problem on my system... are you sure you have
enough room on the current drive for temp files?

623megabytes free space not enough?

o Steven Leeman,
)/\,[_) Sysop SkyNET Bbs
`T7 ]=[ steven@fido.be

--- Fidolook Lite FTN stub
* Origin: Another SkyNET Bbs Message (2:292/624.1)

I like to keep a lot of messages in some areas...
but looks like "feutil LINK" is limited?
fn_sysop now contains 21574 messages -> too much
nodes.024 contains 14877 messages -> too much
enet.sysop contains 8017 messages -> too much
skypoints contains 4996 messages -> this worked still :-)

are t here other JAM linkers avaible that don't have this problem?

I've seen the same sort of problem here, only with FAR fewer messages. Usually
once a message base hits 1000-1500 messages, messages start to disappear. If I
leave things too long, the index file gets corrupted and pointers start to go into the middle of messages instead of the start.

(This is with message bases where messages are not allowed to expire for any reason. The drive(s) involved have plenty of free space: 400M to 600M.)

What I end up doing is just renaming the message base entirely and keeping it out of the FE config.

---
* Origin: Xanadu (403-439-8364): it's a jungle out there! (1:342/806)

I like to keep a lot of messages in some areas...
but looks like "feutil LINK" is limited?
fn_sysop now contains 21574 messages -> too much
nodes.024 contains 14877 messages -> too much
enet.sysop contains 8017 messages -> too much
skypoints contains 4996 messages -> this worked
still :-)

are t here other JAM linkers avaible that don't
have this problem?

i don't see this problem on my system... are you
sure you have enough room on the current drive for
temp files?

623megabytes free space not enough?

if i did my math right, that should be ok even with signed int being used istead of unsigned int... but i don't think that is the problem...

when FE packs the JAM bases, it makes a local copy during the pack that becomes
the final where it is supposed to be... if you are changing directory to fe's install directory, then those temps files get written there...

what flavor of FE are you running? DOS, DPMI, OS/2??

)\/(ark


* Origin: (1:3634/12)

I like to keep a lot of messages in some areas...
but looks like "feutil LINK" is limited?
fn_sysop now contains 21574 messages -> too much
nodes.024 contains 14877 messages -> too much
enet.sysop contains 8017 messages -> too much
skypoints contains 4996 messages -> this worked still :-)

are t here other JAM linkers avaible that don't have this problem?

I've seen the same sort of problem here, only with FAR fewer
messages. Usually once a message base hits 1000-1500
messages, messages start to disappear. If I leave things too
long, the index file gets corrupted and pointers start to go
into the middle of messages instead of the start.

yuck... once a pointer gets out of whack, there are (generally) at least two messages tagged out... it is possible to repair but definitely takes a tool and/or some serious hexediting and study... i had something way back that is/was extremely crude that allowed me to repair some things but it was manual and could lead to further corruption...

(This is with message bases where messages are not allowed to
expire for any reason. The drive(s) involved have plenty of
free space: 400M to 600M.)

that is wierd... i had that problem a few times back during fd, fe, ra beta testing times but not since then... ra does, even in the latest beta, (still) have a message delete bug if users are allowed to delete messages... but i haven't seen this type of error in a long long long time... i've several bases here with huge numbers of messages in them...

i wonder... are you using a filesystem that (automatically) defrags itself or are you using one of the FAT based formats? my system is OS/2 and runs with all
HPFS formatted drives... HPFS doesn't break files into pieces and scatter them all over the place like FAT does...

just something to think about...

)\/(ark


* Origin: (1:3634/12)

i wonder... are you using a filesystem that (automatically) defrags itself or are you using one of the FAT based formats? my system is OS/2 and runs with all HPFS formatted drives... HPFS doesn't break files into pieces and scatter them all over the place like FAT does...

The BBS has been running under OS/2 for nearly 10 years, using HPFS for just as
long.

---
* Origin: Xanadu (403-439-8364): it's a jungle out there! (1:342/806)

i wonder... are you using a filesystem that (automatically)
defrags itself or are you using one of the FAT based
formats? my system is OS/2 and runs with all HPFS
formatted drives... HPFS doesn't break files into pieces
and scatter them all over the place like FAT does...

The BBS has been running under OS/2 for nearly 10 years,
using HPFS for just as long.

darn... there goes that theory... the only other thing that i can think of would be a buggy JAM accessing program... whether its a tool, doorgame, or even
just a report generator/poster... i've had to drop using certain tools for periods of time until i was able to eliminate the problem... don't recall if i was ever actually able to point my finger directly at something... at this point in time, my own PostIt app, FD, RA, and FE are the only (TTBOMK) software
packages on my system that touch JAM areas at all... oh, and TimED from time to
time...

)\/(ark


* Origin: (1:3634/12)

*** Quoting steven leeman from a message to mark lewis ***

i don't see this problem on my system... are you sure you have enough
room on the current drive for temp files?

623megabytes free space not enough?

What version of FE are you using? I found this in the FE_FAQ file..

Q] > When using feutil to link my jam areas, I keep getting a "not enough
> memory" error when it tries to link my genealogy echobase containing
> about 13,000 messages. It links the rest fine. I have 560K of memory
> free before linking.

A] Yeah, nothing to do against this, it needs about 36 bytes or so per
message for linking, take out your calculator and see how much that
makes together with FEUtils program size plus memory needed for the
config etc.

Except when using FEUTIL/16 or /2 ... those ones can handle much
larger bases as the DOS versions.

Ttyl :-),
Al

... Don't be a name dropper. (Bill Gates told me that.)

--- Telegard v3.09.g2-sp4/mL
* Origin: The Rusty MailBox - Vancouver, B.C. Canada (1:153/757)

Hello, Alan!
You wrote to "steven leeman" <steven.leeman@p1.f624.n292.z2.fidonet.org>to steven leeman on 19 Sep 02 01:13:14:

*** Quoting steven leeman from a message to mark lewis ***

Except when using FEUTIL/16 or /2 ... those ones can handle much larger bases as the DOS versions.

I'm now using FEutil/16... that one works...


o Steven Leeman,
)/\,[_) Sysop SkyNET Bbs
`T7 ]=[ steven@fido.be

--- Fidolook Lite FTN stub
* Origin: Another SkyNET Bbs Message (2:292/624.1)

I like to keep a lot of messages in some areas...
but looks like "feutil LINK" is limited?
fn_sysop now contains 21574 messages -> too much
nodes.024 contains 14877 messages -> too much
enet.sysop contains 8017 messages -> too much
skypoints contains 4996 messages -> this worked still :-)

are t here other JAM linkers avaible that don't have this
problem?

i don't see this problem on my system... are you sure you have
enough room on the current drive for temp files?

I saw... only in linking replies, no other problems. Do you have
areas with similar volume of messages stored?

[]s

---
* Origin: HidraSoft BBS * Aruja', SP, Brasil * 55-11-4654-2024 * (4:801/161)

I like to keep a lot of messages in some areas...
but looks like "feutil LINK" is limited?
fn_sysop now contains 21574 messages -> too much
nodes.024 contains 14877 messages -> too much
enet.sysop contains 8017 messages -> too much
skypoints contains 4996 messages -> this worked still :-)

are t here other JAM linkers avaible that don't have this
problem?

i don't see this problem on my system... are you sure you have
enough room on the current drive for temp files?

I saw... only in linking replies, no other problems. Do you
have areas with similar volume of messages stored?

a few... i believe that we've seen that using the DPMI flavor got 'round this problem... evidently, the limits of the 16bit flavor were reached...

)\/(ark


* Origin: (1:3634/12)