Bob,

I appreciate you sending me my key file, but I've tried everything and it
just does not work. Do you have the version that may work because the instructions say for me to file request a specific file... I cna't get that file to come back when I try. I don't have a dialup line either.

I'm lost as to what I need to do.

Allen

--- LiveWire
# Origin: LiveWire BBS -*- telnet://livewirebbs.com (1:2320/100)
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)

Bob,

I appreciate you sending me my key file, but I've tried everything and
it
just does not work. Do you have the version that may work because the instructions say for me to file request a specific file... I cna't get
that
file to come back when I try. I don't have a dialup line either.

That makes two of us, I don't offer dialup either. However nobody has file requested any of the Gecho distribution files in years. My system does offer file requesting via ip, also not happened.

Yes, I do have the original Gecho 1.20 file here, the one mentioned in the instructions. I'll place it on hold for you at 1:140/1 sometime over the weekend, so all you'll have to do is poll 1:140/1 DIRECT! I'll let you know here when it's available.

I'm lost as to what I need to do.

It's simple, you've just done it, probably something you should have done days ago. :)





.....Bob

Allen

--- LiveWire
* Origin: LiveWire BBS -*- telnet://livewirebbs.com (1:2320/100)

--- GEcho/32 & IM 2.50
# Origin: Direct from the desktop of the Echo Moderator (1:140/12)
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)

Done, poll away, just manke sure you have a DIRECT link with 1:140/1, nothing else will work.





.....Bob

--- GEcho/32 & IM 2.50
# Origin: Direct from the desktop of the Echo Moderator (1:140/12)
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)

On 10/21/16, Bob Seaborn said the following...

Done, poll away, just manke sure you have a DIRECT link with 1:140/1, nothing el se will work.

I think it's working now... thanks Bob.

Allen

--- LiveWire
# Origin: LiveWire BBS -*- telnet://livewirebbs.com (1:2320/100)
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)

However nobody has file requested any of the Gecho distribution files in

years.

My system does offer file requesting via ip, also not happened.

Well, how many GEcho users there are still around? You and me, anyone else? :)

'Tommi

--- Sylpheed 3.5.1 (GTK+ 2.24.23; i686-pc-mingw32)
# Origin: *** nntp://rbb.bbs.fi *** Lake Ylo *** Finland *** (2:221/360)
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)

Hi,

On 2016-10-21 23:18:41, Allen Prunty wrote to Bob Seaborn:
about: "My GECHO Pro 120 key":

@TID: FMail-W32 1.72.0.0

I'm lost as to what I need to do.

Keep using what is mentioned in your TID! ;)

Bye, Wilfred.


--- FMail-W32 1.73.0.14-B20161022
# Origin: Native IPv6 connectable node (2:280/464)
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)

On 10/22/16, Wilfred van Velzen said the following...

Keep using what is mentioned in your TID! ;)

Add a few things for me... fmail is a great tosser but I need some help with the maintenance. I have NNTP access to all my message bases.

I need to be able to purge the message bases (as they do get quite large and slow things down) and retain more than 9999 messages. I also need to be able to pack the jambases without renumbering them. The only two tossers that do this are Fastecho and Gecho. HPT renumbers FMAIL renumbers. I'm also going
to transition back to wildcat 4 as opposed to winserver as winserver's tosser is just too slow to handle my volume. GECHO can do Jam / Wildcat / PCBoard / Hudson and .msg.

I ran GECHO with Wildcat for years and know it's a very capable tosser for wildcat.

Allen

--- LiveWire
# Origin: LiveWire BBS -*- telnet://livewirebbs.com (1:2320/100)
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)

However nobody has file requested any of the Gecho distribution files in

years.

My system does offer file requesting via ip, also not happened.

Well, how many GEcho users there are still around? You and me, anyone
else? :)

I have no idea, sorry.





.....Bob

--- GEcho/32 & IM 2.50
# Origin: Direct from the desktop of the Echo Moderator (1:140/12)
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)

On 10/21/16, Bob Seaborn said the following...

Done, poll away, just manke sure you have a DIRECT link with 1:140/1,
nothing el se will work.

I think it's working now... thanks Bob.

So you don't need/want what I placed on hold for you?





.....Bob

--- GEcho/32 & IM 2.50
# Origin: Direct from the desktop of the Echo Moderator (1:140/12)
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)

I thought that was what I was using... unless you put something else on hold for me?

Allen

--- LiveWire
# Origin: LiveWire BBS -*- telnet://livewirebbs.com (1:2320/100)
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)

I thought that was what I was using... unless you put something else on
hold
for me?

Nope, I didn't see you poll.




.....Bob

--- GEcho/32 & IM 2.50
# Origin: Direct from the desktop of the Echo Moderator (1:140/12)
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)

Hi,

On 2016-10-22 08:34:29, Allen Prunty wrote to Wilfred van Velzen:
about: "Re: My GECHO Pro 120 key":

Keep using what is mentioned in your TID! ;)

Add a few things for me... fmail is a great tosser but I need some help with the maintenance. I have NNTP access to all my message bases.

I need to be able to purge the message bases (as they do get quite large and slow things down) and retain more than 9999 messages.

I've changed that to a maximum of 65535, for the next release. ;)

I also need to be able to pack the jambases without renumbering them.

Why do you need that?


Bye, Wilfred.


--- FMail-W32 1.73.0.16-B20161023
# Origin: Amiga Offline BBS Lisse (2:280/464)
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)

Hello Wilfred!

23 Oct 16 23:46, you wrote to me:

I need to be able to purge the message bases (as they do get quite
large and slow things down) and retain more than 9999 messages.

I've changed that to a maximum of 65535, for the next release. ;)

That would help as my magic # is 25000

I also need to be able to pack the jambases without renumbering
them.

Why do you need that?

For those of us who provide NNTP reading services it's necessary.

In NNTP the last read pointer is not kept on the BBS... It is kept on the newsreaders. It's important to not renumber on the bases that are read by NNTP

readers and since some of us are providing fido by NNTP then we need a message packer that does not renumber. Every time my message base is renumbered it throws my NNTP users for a loop.

Allen

Bye, Wilfred.

--- FMail-W32 1.73.0.16-B20161023
* Origin: Amiga Offline BBS Lisse (2:280/464)

Allen


... Bluff means never having to sway your story.
--- GoldED+/W32-MINGW 1.1.5-b20160322
# Origin: LiveWire BBS -=*=- telnet://livewirebbs.com (1:2320/100)
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)

23 Oct 16 23:46, you wrote to Allen Prunty:

Keep using what is mentioned in your TID! ;)

Add a few things for me... fmail is a great tosser but I need some
help with the maintenance. I have NNTP access to all my message
bases.

I need to be able to purge the message bases (as they do get quite
large and slow things down) and retain more than 9999 messages.

I've changed that to a maximum of 65535, for the next release. ;)

that's crazy... especially when JAM can have 2M messages and at least MSG can store up to 99999999...

I also need to be able to pack the jambases without renumbering them.

Why do you need that?

some software doesn't take kindly to renumbering the messages underneath it... JAMNNTPD comes to mind... so why pack, you ask? to remove deleted and dead message bodies... every time you edit a JAM message, the header is updated to the new message body location and the old one is left floating as trash... packing the message bases removes the dead wood from deletions and edits...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Cat: Murphy's way of saying "Nice Furniture!"
---
# Origin: (1:3634/12.73)
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)

Hi mark,

On 2016-10-23 19:21:44, you wrote to me:

I need to be able to purge the message bases (as they do get quite
large and slow things down) and retain more than 9999 messages.

I've changed that to a maximum of 65535, for the next release. ;)

that's crazy... especially when JAM can have 2M messages and at least MSG can store up to 99999999...

Well it's better than the current 9999. And as the config file stores it as a 16 bits value, that's all I can do without making things complicated... ;)

I also need to be able to pack the jambases without renumbering
them.

Why do you need that?

some software doesn't take kindly to renumbering the messages underneath it... JAMNNTPD comes to mind...

So it stores last read pointers in it's own config? And doesn't use the .jlr file for that, as it is supposed to?

so why pack, you ask? to remove deleted and dead message bodies...
every time you edit a JAM message, the header is updated to the new message body location and the old one is left floating as trash...
packing the message bases removes the dead wood from deletions and edits...

I know that. ;)

Bye, Wilfred.

--- FMail-W32 1.73.0.16-B20161023
# Origin: FMail development HQ (2:280/464)
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)

24 Oct 16 08:44, you wrote to me:

I need to be able to purge the message bases (as they do get quite
large and slow things down) and retain more than 9999 messages.

I've changed that to a maximum of 65535, for the next release. ;)

that's crazy... especially when JAM can have 2M messages and at least
MSG can store up to 99999999...

Well it's better than the current 9999. And as the config file stores
it as a 16 bits value, that's all I can do without making things complicated... ;)

it isn't that complicated to increase it to a 32bit or possibly a 64bit number... then when the new release comes out and setup is run, setup can easily detect that the config file is from an older version and update it to the new format... the config file does have a format version number in it for this type of detection and updating, doesn't it??

I also need to be able to pack the jambases without renumbering
them.

Why do you need that?

some software doesn't take kindly to renumbering the messages
underneath it... JAMNNTPD comes to mind...

So it stores last read pointers in it's own config? And doesn't use
the .jlr file for that, as it is supposed to?

no... news servers don't know what the last read message is... there's no way for the client software to tell them... the client software stores the last read in their own configs on the user's machine... when the BBS renumbers the message bases, the client has no way of knowing that and no way of knowing what

the new numbers... the only option is to unjoin and rejoin and then mark all the old messages as read and start again... if this is done daily, users won't be using that service or they will be complaining long and loud about it being broken...

so why pack, you ask? to remove deleted and dead message bodies...
every time you edit a JAM message, the header is updated to the new
message body location and the old one is left floating as trash...
packing the message bases removes the dead wood from deletions and
edits...

I know that. ;)

ok then... you know why to pack and now you know why to /not/ renumber...

FWIW: i've never knowingly renumbered my system since switching to JAM when we were beta testing it in RA/FD/FE... it was only recently that it came to light that FE would do so at a certain point... i think i've taken care of that on that system but it is still a major problem on others... especially when the developers mistakenly shove it in automatically... i can understand doing it in

certain circumstances (like when the HMB approaches its limits) but it should always be an option for the operator to choose... if they break their message bases because they let the numbers get too large than that's their fault... even with JAM there is this possibility but the numbers are much larger before something like this should handled and then it should be handled by notifying the operator in the logs and letting them make the decision...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Old BBSers don't die, they just drop their carrier.
---
# Origin: (1:3634/12.73)
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)

Hi mark,

On 2016-10-24 05:32:10, you wrote to me:

Well it's better than the current 9999. And as the config file stores
it as a 16 bits value, that's all I can do without making things
complicated... ;)

it isn't that complicated to increase it to a 32bit or possibly a 64bit number... then when the new release comes out and setup is run, setup can easily detect that the config file is from an older version and update it to the new format...

That's what I meant with "making things complicated". This little change isn't worth the trouble, of creating an updated config file and all the hassle that it involves...

the config file does have a format version number in it for this type
of detection and updating, doesn't it??

Yes it does.

ok then... you know why to pack and now you know why to /not/
renumber...

... If your system/software needs it. ;)

Bye, Wilfred.

--- FMail-W32 1.73.0.16-B20161023
# Origin: FMail development HQ (2:280/464)
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)

24 Oct 16 12:52, you wrote to me:

Well it's better than the current 9999. And as the config file
stores it as a 16 bits value, that's all I can do without making
things complicated... ;)

it isn't that complicated to increase it to a 32bit or possibly a
64bit number... then when the new release comes out and setup is run,
setup can easily detect that the config file is from an older version
and update it to the new format...

That's what I meant with "making things complicated". This little
change isn't worth the trouble, of creating an updated config file and
all the hassle that it involves...

that's not complicated in the least... the setup program loads the bytes of the

config file that contain the version... if it is an old version, it loads the old config into the new config making the needed var type changes... once that's done and the operator looks over all the settings to be sure they are correct, then we save the config and we're done... nothing to it... remoteaccess was doing this back in 1990 with at least v0.04... we always had to run setup and exit and then run it again... the conversion of the config file was done during the first run but you had to exit and then run it again...

i've used that same method for some of my own tools except that i don't require

the exit and restart... it isn't that hard or complicated... FD and FE also did

the same type of conversion when their config file formats were updated...

the config file does have a format version number in it for this type
of detection and updating, doesn't it??

Yes it does.

excellent... i was pretty sure it did... there's no other reason to have this other than automatically upgrading the config file format...

ok then... you know why to pack and now you know why to /not/
renumber...

... If your system/software needs it. ;)

renumbering should /never ever ever ever/ be forced except in the single extreme circumstance of message base breakage due to overpopulation... it should always be the operator's choice... just like purging and packing are not

forced...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... You need to be at least 10% smarter than the equipment.
---
# Origin: (1:3634/12.73)
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)