Hello, All...

Since I've been feeding from 1:106/1, I get some messages that Squish says are "too long." This gets the packet renamed as *.LNG and left in my Squish directory. I'm using BUFFERS LARGE.

Any suggestions?

Regards,

Jerry Schwartz

mailto:jerryschwartz@comfortable.com
http://www.writebynight.com

--- Msged/NT 6.0.1
* Origin: Write by Night (1:142/928)

Hi Jerry,

Since I've been feeding from 1:106/1, I get some
messages that Squish says are "too long." This gets the
packet renamed as *.LNG and left in my Squish
directory. I'm using BUFFERS LARGE.

Any suggestions?

Are you using SQUISH or SQ386?

Cheers..................pk.


--- Maximus/2 3.01
* Origin: Another Good Point About OS/2 (3:772/1.10)

Hello, Peter...

Feb 06, 2006 at 17:01, Peter Knapper wrote to Jerry Schwartz:

Since I've been feeding from 1:106/1, I get some
messages that Squish says are "too long." This gets the
packet renamed as *.LNG and left in my Squish
directory. I'm using BUFFERS LARGE.

Any suggestions?

Are you using SQUISH or SQ386?

SQ386 in a .BAT file under Windows XP. I haven't tried changing the file to a .CMD file, but I doubt that would do it.

Regards,

Jerry Schwartz

mailto:jerryschwartz@comfortable.com
http://www.writebynight.com

--- Msged/NT 6.0.1
* Origin: Write by Night (1:142/928)

Hi Jerry,

Are you using SQUISH or SQ386?

SQ386 in a .BAT file under Windows XP. I haven't tried
changing the file to a .CMD file, but I doubt that
would do it.

No, that should be fine then. Do you know what size the messages are that are being trapped? About the only thing I can think of causing this are messages larger than 64KB, but its unusual that no-one else is mentioning them.

About the only other thing I can think of is that something is corrupt. Possibly the executable, or a Message base, or perhaps the packet itself. Does something like INSPECTA complain about the packet or its contents?

Cheers..............pk.


--- Maximus/2 3.01
* Origin: Another Good Point About OS/2 (3:772/1.10)

Peter Knapper wrote to Jerry Schwartz:

No, that should be fine then. Do you know what size the messages are that are being trapped? About the only thing I can think of causing this are messages larger than 64KB, but its unusual that no-one else is mentioning them.

I've seen things like that with the linux version too. It could be
messages in the stats echo, some of them can be 500KB. I'd get .pkt's
renamed to .lng in my inbound. I never did find a solution. I just
checked my stats msg base, 70 megs!

Ttyl :-),
Al

... Age and treachery can always overcome youth and skill.

--- MBSE BBS v0.83.12 (GNU/Linux-x86_64)
* Origin: The Rusty MailBox - Penticton, B.C. Canada - trmb.ca (1:153/757)

On 02-07-06 19:54, Peter Knapper <=-
spoke to Jerry Schwartz about Messages too long? <=-

Are you using SQUISH or SQ386?

SQ386 in a .BAT file under Windows XP. I haven't tried
changing the file to a .CMD file, but I doubt that
would do it.

I use sq386n.exe, called from a CMD file by Argus running in Win XP.

No, that should be fine then. Do you know what size the
messages are that are being trapped? About the only thing I
can think of causing this are messages larger than 64KB,
but its unusual that no-one else is mentioning them.

I noticed them quite some time ago. Now that the line in my batch
file immediately after the call to sq386n reads
*del /q *.lng
I no longer notice them -- they go poof as soon as they get here.

As I recall, it was because of a message in the STATS echo that was
posted periodically by someone -- don't recall exactly who. I think
that the files often ran in excess of 100KB.

Dale Shipp
fido_261_1466 (at) comcast (dot) net
(1:261/1466)


... Shipwrecked on Hesperus in Columbia, Maryland. 23:14:10, 07 Feb 2006
___ Blue Wave/DOS v2.30

--- Maximus/NT 3.01
* Origin: Owl's Anchor (1:261/1466)

Hello, Peter...

Feb 07, 2006 at 19:54, Peter Knapper wrote to Jerry Schwartz:

Are you using SQUISH or SQ386?

SQ386 in a .BAT file under Windows XP. I haven't tried
changing the file to a .CMD file, but I doubt that
would do it.

No, that should be fine then. Do you know what size the messages are
that are being trapped? About the only thing I can think of causing
this are messages larger than 64KB, but its unusual that no-one else
is mentioning them.

About the only other thing I can think of is that something is
corrupt. Possibly the executable, or a Message base, or perhaps the packet itself. Does something like INSPECTA complain about the packet
or its contents?

I have never used INSPECTA. So far as I can tell, Squish simply skips the oversized message and tosses the rest of the package. It doesn't bark about anything other than to say

# 07 Feb 00:04:10 SQSH Tossing/scanning msgs from . (secure)
* 07 Feb 00:04:10 SQSH 43e82a7e.Pkt, 02/06/06, 23:05:01, by ff 1.04
- 07 Feb 00:04:10 SQSH Orig=1:106/1.0, Dest=1:142/928.0, Type=2+
! 07 Feb 00:04:10 SQSH Msg too long to toss: skipping to next msg.
! 07 Feb 00:04:10 SQSH Packet contains long msg: renamed to .\43e82a7e.LNG
: 07 Feb 00:04:10 SQSH BATPOWER (Toss=0001 Sent=0001)
: 07 Feb 00:04:10 SQSH COFFEE_KLATSCH (Toss=0002 Sent=0008)
: 07 Feb 00:04:10 SQSH MBSE (Toss=0002 Sent=0006)
: 07 Feb 00:04:10 SQSH MENSA (Toss=0001 Sent=0001)
: 07 Feb 00:04:10 SQSH POL_INC (Toss=0003 Sent=0006)
: 07 Feb 00:04:10 SQSH STATS (Toss=0002 Sent=0004)
: 07 Feb 00:04:10 SQSH WIN95 (Toss=0001 Sent=0001)

Regards,

Jerry Schwartz

mailto:jerryschwartz@comfortable.com
http://www.writebynight.com

--- Msged/NT 6.0.1
* Origin: Write by Night (1:142/928)

Hello, Alan...

Feb 07, 2006 at 01:20, Alan Ianson wrote to Peter Knapper:

I've seen things like that with the linux version too. It could be messages in the stats echo, some of them can be 500KB. I'd get .pkt's renamed to .lng in my inbound. I never did find a solution. I just
checked my stats msg base, 70 megs!

Thanks. I've always suspected the STATS echo, although it was just a WAG.


Regards,

Jerry Schwartz

mailto:jerryschwartz@comfortable.com
http://www.writebynight.com

--- Msged/NT 6.0.1
* Origin: Write by Night (1:142/928)

Hi Jerry,

About the only other thing I can think of is that something is
corrupt. Possibly the executable, or a Message base, or perhaps the packet itself. Does something like INSPECTA
complain about the packet or its contents?

I have never used INSPECTA.

I can recommend it, its invaluable for looking into mail packets, etc.

Cheers............pk.


--- Maximus/2 3.01
* Origin: Another Good Point About OS/2 (3:772/1.10)

Jerry Schwartz wrote to Alan Ianson:

I've seen things like that with the linux version too. It could be messages in the stats echo, some of them can be 500KB. I'd get .pkt's renamed to .lng in my inbound. I never did find a solution. I just checked my stats msg base, 70 megs!

Thanks. I've always suspected the STATS echo, although it was just a WAG.

Luckily squish doesn't crash on a message like that, it just skips
it and continues on. Dale's del /q *.lng is probably a safe operation
on those .lng's..

Ttyl :-),
Al

... DISK ERROR: DISK ERROR: DISK ERROR: @$%#&%!! *WHACK* C:\>

--- MBSE BBS v0.83.12 (GNU/Linux-x86_64)
* Origin: The Rusty MailBox - Penticton, B.C. Canada - trmb.ca (1:153/757)

I've seen things like that with the linux version too. It could be messages in the stats echo, some of them can be 500KB. I'd get .pkt's renamed to .lng in my inbound. I never did find a solution. I just
checked my stats msg base, 70 megs!

If I remember correctly, with the SQ386(p) version of squish, the maximum message size is aboue 256Kb. If you are seeing 500Kb message size in an echo, that is probably what is doing it....

I suspect the Linux version of Squish could be updated to support longer messages. I don't know if anyone has the code compiling to change toe OS/2 and
Win NT versions for larger packets.

Take care.....

Bob Jones, 1:343/41


--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

Hello Bob!

09 Feb 06 22:22, Bob Jones wrote to Jerry Schwartz:

If I remember correctly, with the SQ386(p) version of squish, the
maximum message size is aboue 256Kb. If you are seeing 500Kb message
size in an echo, that is probably what is doing it....

I believe you are correct, for the parameters pointed to by the "Large" keyword. However, if you take manual control of the individual parameters, you
should be able to tax whatever the limits of your environment are (theoretically 2gb for OS/2).

I tried allowing 512k for some of my gated newsgroups for a while. It worked, but I didn't find the content of those messages particularly useful (usually UUENCODEd trash unrelated to the group topic) and eventually went back to letting LARGE filter the trash, instead.<g>

.\\ike

--- GoldED 2.50+
* Origin: -=( The TechnoDrome )=- Austin,TX 512-327-8598 33.6k (1:382/61)

Mike Tripp wrote to Bob Jones <=-

If I remember correctly, with the SQ386(p) version of squish, the
maximum message size is aboue 256Kb. If you are seeing 500Kb message
size in an echo, that is probably what is doing it....

I believe you are correct, for the parameters pointed to by the "Large" keyword. However, if you take manual control of the individual parameters, you should be able to tax whatever the limits of your environment are (theoretically 2gb for OS/2).

How did you do that?

I tried allowing 512k for some of my gated newsgroups for a while. It worked, but I didn't find the content of those messages particularly useful (usually UUENCODEd trash unrelated to the group topic) and eventually went back to letting LARGE filter the trash, instead.<g>

That's a useful option too.. :)


Ttyl :-),
Al

... My opinions are my own; mistakes are the computer's fault.
--- MultiMail/Linux v0.47
* Origin: The Rusty MailBox - Penticton, B.C. Canada - trmb.ca (1:153/757)

Hello Jerry.

05 Feb 06 18:14, you wrote to All:

Since I've been feeding from 1:106/1, I get some messages that Squish
says are "too long." This gets the packet renamed as *.LNG and left in
my Squish directory. I'm using BUFFERS LARGE.

Any suggestions?

Find out what areas they are in. Reading into the thread I see stats echo being mentioned. I see that two systems post large messages there. 229/2000 with messages around 400K+ and 123/500 with messages around 130K+. My node does not split passthrough traffic but does split traffic originating from itself. Its been many years since I ran squish but I recall even with 'large' the message buffer is either 512K or 256K.

Some folks forget that others run software that might crash or not pass on large messages. Even though many of us run systems capable of handling large messages; all to often the software cannot or at least is not configured to do so. At least squish is smart enough to skip them. I suspect there are tossers
that stop up completely when they encouter very large messages?

Let me know if there is anything I can do to help.

Matt

e-mail: matt [at] thunderdome.us | icq: 16568532 | yahoo: mbedynek

"to be loved is fortunate, but to be hated is to achieve distinction"

---
* Origin: ..::[ high speed feeds - http://fido.thunderdome.us/ ]::.. (1:106/1)

Hello Jerry.

08 Feb 06 18:27, you wrote to Alan Ianson:

Thanks. I've always suspected the STATS echo, although it was just a
WAG.

If that is the case, you may want to leave your buffer small to stop them. Reason being that some of your downlinks might have severe issues with them? People really should split large messages before injecting them into the echomail stream; especially if they are the originator of them ..

Matt

e-mail: matt [at] thunderdome.us | icq: 16568532 | yahoo: mbedynek

"to be loved is fortunate, but to be hated is to achieve distinction"

---
* Origin: ..::[ high speed feeds - http://fido.thunderdome.us/ ]::.. (1:106/1)

Matt Bedynek wrote to Jerry Schwartz:

Some folks forget that others run software that might crash or not pass on large messages.

One thing I never concidered when I commented deleting *.lng files is
nodes that need to pass messages on. In a case like that then it is
more of a problem.

I suspect there are tossers that stop up completely when they
encouter very large messages?

I took the new dbridge out for a test drive a month or two back and
it crashed completely on those messages...

I think 229/2000 runs hpt, maybe we should ask him if he wouldn't
mind splitting messages at 128 or 256kb or some safe value, just so
those who run tossers that can't handle the large messages can still
pass those messages on for those interested in reading them. I read
the area myself periodiclly just to see what areas are getting
traffic.

Ttyl :-),
Al

... An Elephant; A Mouse built to government specifications.

--- MBSE BBS v0.83.12 (GNU/Linux-x86_64)
* Origin: The Rusty MailBox - Penticton, B.C. Canada - trmb.ca (1:153/757)

Hello, Matt...

Feb 10, 2006 at 18:43, Matt Bedynek wrote to Jerry Schwartz:

Let me know if there is anything I can do to help.

I doubt anyone misses those messages. I haven't gotten any complaints, so I'll continue letting Squish skip them.

Regards,

Jerry Schwartz

mailto:jerryschwartz@comfortable.com
http://www.writebynight.com

--- Msged/NT 6.0.1
* Origin: Write by Night (1:142/928)

Hello, Matt...

Feb 10, 2006 at 18:52, Matt Bedynek wrote to Jerry Schwartz:

Thanks. I've always suspected the STATS echo, although it was just a
WAG.

If that is the case, you may want to leave your buffer small to stop them. Reason being that some of your downlinks might have severe
issues with them? People really should split large messages before injecting them into the echomail stream; especially if they are the originator of them ..

Nobody has complained.

Regards,

Jerry Schwartz

mailto:jerryschwartz@comfortable.com
http://www.writebynight.com

--- Msged/NT 6.0.1
* Origin: Write by Night (1:142/928)

On 02-11-06 19:44, Jerry Schwartz <=-
spoke to Matt Bedynek about Messages too long? <=-

I doubt anyone misses those messages. I haven't gotten any
complaints, so I'll continue letting Squish skip them.

IIRC, they are automatically generated by whatever stats program those
sysops are using, and they are the listing of echos that had no
traffic.

Dale Shipp
fido_261_1466 (at) comcast (dot) net
(1:261/1466)


... Shipwrecked on Hesperus in Columbia, Maryland. 22:58:22, 11 Feb 2006
___ Blue Wave/DOS v2.30

--- Maximus/NT 3.01
* Origin: Owl's Anchor (1:261/1466)

Some folks forget that others run software that might crash or not
pass on large messages.

speaking as one of those folk, /i/ don't forget... i _know_ that there is software available for those who can't/don't want to handle large messages... this software can cut/split (by FTSC proposal) messages too large for their systems to handle... i've said this for years... in fact, i've had this stance ever since the ^aSPLIT proposal was presented to the FTSC... i have /always/ believed it the responsibility of the -=recieving=- system to split messages according to _their_ capabilities rather than "forcing" everyone else to succumb to their individual restrictions...

Even though many of us run systems capable of handling large
messages; all to often the software cannot or at least is not
configured to do so.

that is the operator's problem, IMHO... the real "problem" is getting folk to look at the other side of the coin...

At least squish is smart enough to skip them.

and thus loose mail... there's one part of that blackhole that folk speak of...

I suspect there are tossers that stop up completely when they
encouter very large messages?

i don't doubt that... that's one of the main reasons why i see that ^aSPLIT proposal is written and directed to the wrong folk...

Let me know if there is anything I can do to help.

educate folk and teach them to cut messages up to what /their/ systems can handle and don't restrict others in what they can handle ;) O:)

)\/(ark


* Origin: (1:3634/12)

Thanks. I've always suspected the STATS echo, although it was just a
WAG.

If that is the case, you may want to leave your buffer small to
stop them. Reason being that some of your downlinks might have
severe issues with them? People really should split large messages
before injecting them into the echomail stream; especially if they
are the originator of them ..

wrong... should i wear a condom to prevent you from getting a disease that i may transmit to a whore that you may also spend time with or should you wear a condom to protect yourself from anything she may have and try to deliver to you?

i believe that it should be you wearing that condom, my friend... CYOA and all that stuff... if your system has a limit of 100k messages, then -=you=- should be running "preprocessor" software to cut messages down to 100k of smaller...

)\/(ark


* Origin: (1:3634/12)

I took the new dbridge out for a test drive a month or two back and
it crashed completely on those messages...

did you report those details back to the d'bridge echo so they might be fixed in the sources?

I think 229/2000 runs hpt, maybe we should ask him if he wouldn't
mind splitting messages at 128 or 256kb or some safe value, just so
those who run tossers that can't handle the large messages can
still pass those messages on for those interested in reading them.
I read the area myself periodiclly just to see what areas are
getting traffic.

i'd say that you need to be running software as i just spoke of in previous messages to matt...

)\/(ark


* Origin: (1:3634/12)

Hello mark!

15 Feb 06 04:57, mark lewis wrote to Matt Bedynek:

speaking as one of those folk, /i/ don't forget... i _know_ that there
is software available for those who can't/don't want to handle large messages... this software can cut/split (by FTSC proposal) messages
too large for their systems to handle... i've said this for years...
in fact, i've had this stance ever since the ^aSPLIT proposal was presented to the FTSC... i have /always/ believed it the
responsibility of the -=recieving=- system to split messages according
to _their_ capabilities rather than "forcing" everyone else to succumb
to their individual restrictions...

This is really a dirt-common networking design issue that has been addressed in
both hardware and software protocols years before Fido emerged. There are appropriate data structures and algorithms to accommodate datagrams of fixed length or variable length, but unfortunately Fido standards failed to define quite enough technical detail to realistically accomplish either.

Nobody in Fido has hardware and software that can process and forward infinitely sized messages, though that is what is effectively allowed by the Fido standards.<g> The advantage of a formal splitting algorithm is that it implies a formal unsplitting mechanism, which means that all are not required to "succumb" to the lowest common denominator determined by one worst-case hop on the route.

I suspect there are tossers that stop up completely when they
encouter very large messages?

i don't doubt that... that's one of the main reasons why i see that ^aSPLIT proposal is written and directed to the wrong folk...

All Fido systems are theoretically "tranceivers", so it is really irrelevant whether the responsibility for the execution of the algorithm is assigned to the sending process, the receiving process, or distributed between both...since
we'd all need to support "it", whatever "it" is. Whether I like messages "too small" or you like messages "too big" is simply a matter of perspective...and there is a technical path to render it transparent to us both. Unfortunately, the necessary groundwork to lay the infrastructure to resolve the issue came along a little too late to benefit the folks that need it the most.

.\\ike

--- GoldED 2.50+
* Origin: -=( The TechnoDrome )=- Austin,TX 512-327-8598 33.6k (1:382/61)

mark lewis wrote to Alan Ianson:

I took the new dbridge out for a test drive a month or two back and
it crashed completely on those messages...

did you report those details back to the d'bridge echo so they might be fixed in the sources?

No, I never did. I presumed that there were folks who knew the software
better than I did so I didn't. My bad I think. I'll go post that today.

I think 229/2000 runs hpt, maybe we should ask him if he wouldn't
mind splitting messages at 128 or 256kb or some safe value, just so those who run tossers that can't handle the large messages can
still pass those messages on for those interested in reading them.
I read the area myself periodiclly just to see what areas are
getting traffic.

i'd say that you need to be running software as i just spoke of in previous messages to matt...

Sounds repulsive to me. Glad my software tosses them, and hope I don't
find any limits in the future. ;)

Ttyl :-),
Al

... Our program, who art in memory. EXE be thy name.

--- MBSE BBS v0.83.13 (GNU/Linux-x86_64)
* Origin: The Rusty MailBox - Penticton, B.C. Canada - trmb.ca (1:153/757)

Hello mark.

15 Feb 06 04:57, you wrote to me:

speaking as one of those folk, /i/ don't forget... i _know_ that there
is software available for those who can't/don't want to handle large messages... this software can cut/split (by FTSC proposal) messages
too large for their systems to handle... i've said this for years...
in fact, i've had this stance ever since the ^aSPLIT proposal was presented to the FTSC... i have /always/ believed it the
responsibility of the -=recieving=- system to split messages according
to _their_ capabilities rather than "forcing" everyone else to succumb
to their individual restrictions...

If you are thinking of pktsort and psrt, both are buggy despite the fact that there are at least a few hubs out that that still use it. pktsoft had a bug with regard to occassionally grunging netmail messages. i believe that splitting and recombination should be built into the tosser anyway but the likelihood of a standard, dated and valuable as it seems, will make a mass entry into software being utilized by sysops today.

that is the operator's problem, IMHO... the real "problem" is getting
folk to look at the other side of the coin...

and thus loose mail... there's one part of that blackhole that folk
speak of...

educate folk and teach them to cut messages up to what /their/ systems
can handle and don't restrict others in what they can handle ;) O:)

In a perfect fidonet of conformity and appreciation for the latest technology that is true. However, when joe sysop comes home every day and his tosser is frozen because it hit a large message (he does not know why) he will likely shutdown the system in frustration because his use of it and/or time is limited. The problem is two fold in that you have sysops running systems that might not have the memory to handle large messages or they have the hardware but they are using older software that does not take advantage of it (abandonware, ect).

My tosser is generations ahead of yours just like yours is above the guy using software 10 years old. A message here can be the size of free memory. Being that I have two gigs of ram and a highspeed disk backplane, i could handle messages in minutes that might take you hours but that is beside the point.

Not everybody wants to or can run fastecho or hpt. Besides, you cant register fastecho anymore anyway. :-)

:-)

Matt

e-mail: matt [at] thunderdome.us | icq: 16568532 | yahoo: mbedynek

"to be loved is fortunate, but to be hated is to achieve distinction"

---
* Origin: ..::[ high speed feeds - http://fido.thunderdome.us/ ]::.. (1:106/1)

Hello mark.

15 Feb 06 05:04, you wrote to me:

i believe that it should be you wearing that condom, my friend... CYOA
and all that stuff... if your system has a limit of 100k messages,
then -=you=- should be running "preprocessor" software to cut messages down to 100k of smaller...

Feel free to code that preprocessor for the rest of us to use.

Matt

e-mail: matt [at] thunderdome.us | icq: 16568532 | yahoo: mbedynek

"to be loved is fortunate, but to be hated is to achieve distinction"

---
* Origin: ..::[ high speed feeds - http://fido.thunderdome.us/ ]::.. (1:106/1)

Hi Mark,

i've said this for years... in fact, i've
had this stance ever since the ^aSPLIT proposal was
presented to the FTSC... i have /always/ believed it
the responsibility of the -=recieving=- system to split
messages according to _their_ capabilities rather than
"forcing" everyone else to succumb to their individual restrictions...

I think you overlook some pretty basic human instincts here, and your ability to read so many 500KB messages is nothing short of staggering......;-)

If Fidonet were a 100% commercial environment then I doubt many people would disagree with you, but the origins of the network have forced all of us to accept that some things are historical and need to be accomodated in the interests of self preservation.

Message length has long been an issue, and in the case of Fidonet I see no reason to force everyone to change to a new method of handling these things, voluntarily perhaps, but not by force.

Netmail and Echomail were constructed to allow people to communicate with each other, and stuffing 500KB of computer generated text into a message in which the text is NOT created by humans, but with the expectation that SOMEONE will read it, is nothing short of abuse of the medium (IMHO).

I use and generate stats myself, but unless they are only 1 or 2 screens in length I do NOT output it via messages, the longer form of stats presentation is meant for a file (IMHO).

Cheers.........pk.


--- Maximus/2 3.01
* Origin: Another Good Point About OS/2 (3:772/1.10)

15 Feb 06 21:03, Matt Bedynek wrote to mark lewis:

Not everybody wants to or can run fastecho or hpt. Besides, you cant register fastecho anymore anyway. :-)

Yes you can.


Roy
--- Twit(t) Filter v2.1 (C) 2000
* Origin: Hacienda de Rio de Guadalupe * South * Texas, USA * (1:1/22)

Not everybody wants to or can run fastecho or hpt. Besides, you
cant register fastecho anymore anyway. :-)

says who? certainly not me ;) i'm also aware of at least one individual who has registered FE in the recent past ;)

)\/(ark


* Origin: (1:3634/12)

i believe that it should be you wearing that condom, my friend... CYOA
and all that stuff... if your system has a limit of 100k messages,
then -=you=- should be running "preprocessor" software to cut messages down to 100k of smaller...

Feel free to code that preprocessor for the rest of us to use.

that preprocessor has already been coded and available to fidonet in several flavors for... hummm... gee... at least 10 years...

)\/(ark


* Origin: (1:3634/12)

|11┌─|03─[|15Quoting |12Mark Lewis |15to |12Matt Bedynek |03]──∙·· |11└─|03─[|15Taken from: |13[Fido] Squish Help |03]──»

Feel free to code that preprocessor for the rest of us to use.

that preprocessor has already been coded and available to fidonet in severa flavors for... hummm... gee... at least 10 years...

A link to where we can find this jewel would be of some help, as well as the name of such a program.

The GameMaster BBS Home of Marty's Mercantile, an IGM for L.O.R.D.
Also home of Bluenet message network. Telnet to any of the following.
gamemasterbbs.darktech.org gamemaster.dtdns.net gamemasterbbs.no-ip.com gamemaster.bbs.us Lots of InterBBS games available as well as local ones.

--- Renegade v08-30.5 DOS/EXP
* Origin: The GameMaster BBS | gamemasterbbs.darktech.org (1:2320/303)

Hello mark.

17 Feb 06 14:38, you wrote to me:

Feel free to code that preprocessor for the rest of us to use.

that preprocessor has already been coded and available to fidonet in several flavors for... hummm... gee... at least 10 years...

)\/(ark

If you're thinking pktsort, I have already said, I found numerous bugs in it.

Matt

e-mail: matt [at] thunderdome.us | icq: 16568532 | yahoo: mbedynek

"to be loved is fortunate, but to be hated is to achieve distinction"

---
* Origin: ..::[ high speed feeds - http://fido.thunderdome.us/ ]::.. (1:106/1)