I have gotten setup with a node, changed the crashmail.prefs to that node.
Did my Areafix, and added some echos.. but when importing them I get:[ ...let's concentrate on one echo... ]
! 23-Oct-16 22:09:37 Failed to read message #55 in JAM messagebase "/home/rec9140/fido/jam/BINKD"
! 23-Oct-16 22:09:37 Failed to read message #56 in JAM messagebase "/home/rec9140/fido/jam/BINKD"
! 23-Oct-16 22:09:37 Failed to read message #57 in JAM messagebase "/home/rec9140/fido/jam/BINKD"
Also creating a reply or new message, does NOT EXPORT...
I even created a TESTECHO.... same... doesn't export the message.
NETMAIL WORKS FINE! Echos do NOT export.
$ crashmail VERSION
This is CrashMail II version 0.71
! 23-Oct-16 22:09:37 Failed to read message #55 in JAM messagebase "/home/rec9140/fido/jam/BINKD"
rc> ! 23-Oct-16 22:09:37 Failed to read message #55 in JAM messagebase
rc> "/home/rec9140/fido/jam/BINKD"
Did you let crashmail create the message base? Just wondering what permissions you have there.
It's the same one that CrashExport uses to feed to Golded. Ignoring the path, how does the AREA line differ from yours?
! 23-Oct-16 22:09:37 Failed to read message #55 in JAM messagebase
"/home/rec9140/fido/jam/BINKD"
Did you let crashmail create the message base? Just wondering what permissions you have there.
I second the last question. Since it is running under linux, can
jamnntpd read the base created by another user/program
(crashmail/golded?) ?
On 10/24/2016 04:25 AM, Paul Quinn -> rick christian wrote:
It's the same one that CrashExport uses to feed to Golded. Ignoring
the path, how does the AREA line differ from yours?
AREA "BINKD" 1:135/377.0 JAM "/home/rec9140/fido/jam/BINKD"
EXPORT %1:135/300.0
GROUP A
These were added my crashmail, not me.
AREA "BINKD" 1:135/377.0 JAM "/home/rec9140/fido/jam/BINKD"
EXPORT %1:135/300.0
GROUP A
These were added my crashmail, not me.
where'd that % sign come from in the EXPORT line?
AREA "BINKD" 1:135/377.0 JAM "/home/rec9140/fido/jam/BINKD"
EXPORT %1:135/300.0
GROUP A
These were added my crashmail, not me.
where'd that % sign come from in the EXPORT line?
The line and all parts of it added by crashmail directly
and per the documentation in the file:
; and % means that the node is the feed for this area.
ahhhh... ok... i don't know that that is important in the grand scheme
of things but i noticed it and didn't see one in paul's example...
FWIW: FTN echomail is not a hierarchy like so many were lead to believe over the years... if you have only one connection, sure, that may be viewed as your "feed" or "upstream" but if you have several connections
to an echo, they're all "feeds" and there's no real "upstream" or "downstream"...
EXPORT %1:135/300.0
GROUP A
These were added my crashmail, not me.
where'd that % sign come from in the EXPORT line?
AREA "BINKD" 1:135/377.0 JAM "/home/rec9140/fido/jam/BINKD"
EXPORT %1:135/300.0
GROUP A
These were added my crashmail, not me.
Well ummm.. why would you have a feed of the SAME echo from different nodes????
So, which program put those messages into the echo's JAM file(s) in the first place? (I only ask as I 'seeded' _this_ node's messagebase with
some matching JAM files from my other node, created by FastEcho [a DOS program].) If CM did the deed then are there any errors in the/a
previous logfile, when the messages were tossed in?\
Simply put: how can CM put things in that it cannot get out again?
Something changed in the between-times? Some other program changed the JAM-stored data?
ahhhh... ok... i don't know that that is important in the grand scheme
of things but i noticed it and didn't see one in paul's example...
And taking it out, doesn't seem to make it export.
FWIW: FTN echomail is not a hierarchy like so many were lead to
believe over the years... if you have only one connection, sure, that
may be viewed as your "feed" or "upstream" but if you have several
connections to an echo, they're all "feeds" and there's no real
"upstream" or "downstream"...
Well ummm.. why would you have a feed of the SAME echo from different nodes????
I can see if echo a is an echo on my system on not fed via NAB so
nodes come to me to get it...
BUT why would they also want to say add binkd as well??
Especially in 2016, where for the most part the delay is the cycle on which a node runs their exporting process...and/or TZ for the users.
Something changed in the between-times? Some other program changed
the JAM-stored data?
The only program to access things is Golded and Crashmail
I can read messages, BUT they have CORRUPT to and from headers, ie: garbled names and node numbers.
Well ummm.. why would you have a feed of the SAME echo from different nodes????
i currently have only two systems on hold and that only because i cannot connect to them... i don't know why and their operators can't seem to figure out how to get set up so that i can but they (supposedly) have callers connecting to their systems... why they can get one working and not the other is beyond me...
The only program to access things is Golded and Crashmail
I can read messages, BUT they have CORRUPT to and from headers, ie: garbled names and node numbers.
Something changed in the between-times? Some other programThe only program to access things is Golded and Crashmail
changed the JAM-stored data?
I can read messages, BUT they have CORRUPT to and from headers, ie: garbled names and node numbers.
The only program to access things is Golded and Crashmail
I can read messages, BUT they have CORRUPT to and from headers, ie:
garbled names and node numbers.
So why would you use Golded then, when it obviously corrupts your
JAM message bases? Run a JamNNTPd server and use Thunderbird or
something similar and you'll get tons of advantages.
what versions, please?? is that plain old golded or golded+?? which message base library is it compiled with??
well, there's your problem... it would have been nice to know that
sooner ;)
reread my first statement after FWIW... there is no real hierarchy in echomail...........two systems on hold and that
only because i cannot connect to them... i don't know why and their operators can't seem to figure out how to get set up so that i can but they (supposedly) have callers connecting to their systems... why they
can get one working and not the other is beyond me...
I guess you haven't read all the articles about this in the Fidonews the last five or so years ago?
I'll not dive into this just now, since I read mark's excellent explanation, but please do pay attention to the modern fidonet evolution.
* destroy your existing JAM messagebase
but please do pay attention to the modern fidonet evolution.
And with that.. I am out, Peace, love, and all that.. Enjoy..
Singing off.. Out.
* destroy your existing JAM messagebase
Ouch!
There is another way that relies on a program written by one of the originators of the JAM message base. The FrontDoor editor has never
failed me once when investigating or converting message bases to and fro JAM.
but please do pay attention to the modern fidonet evolution.
And with that.. I am out, Peace, love, and all that.. Enjoy..
Singing off.. Out.
Strange reaction... Really?
i currently have only two systems on hold and that only because i
cannot connect to them... i don't know why and their operators can't
seem to figure out how to get set up so that i can but they
(supposedly) have callers connecting to their systems... why they can
get one working and not the other is beyond me...
I have a very similar setup here (but at the moment only one node remaining on hold). Just a thought: can it be that your two troubled
nodes are both running Mystic...?
I've had as many as three troublesome nodes here, but as they realized that Mystic is crappy and changed to something else, they were
gradually making it to the crash gang.
reread my first statement after FWIW... there is no real hierarchy in
echomail...........two systems on hold and that only because i cannot
connect to them... i don't know why and their operators can't seem to
figure out how to get set up so that i can but they (supposedly) have
callers connecting to their systems... why they can get one working
and not the other is beyond me...
Obviously thats changed since the 90's...
It was very very well beaten in to nodes in my area at that time. Thou shalt get echos via the net hub/NC/ what ever it was... Otherwise you
ran the risk of be expelled..
I also can see one little glitch some where misconfigured and huge
amounts of dupes being moved around... in 2016 via TCP/IP who cares mostly.. in the modem days... Some one definitely cares real quick.
* destroy your existing JAM messagebase
Ouch!
There is another way that relies on a program written by one of the originators of the JAM message base. The FrontDoor editor has never failed me once when investigating or converting message bases to and fro JAM.
The only program to access things is Golded and CrashmailSo why would you use Golded then, when it obviously corrupts your
I can read messages, BUT they have CORRUPT to and from headers,
ie: garbled names and node numbers.
JAM message bases?
I use JAM exclusively, and Golded+ never corrupted anything here.
I use JAM exclusively, and Golded+ never corrupted anything here.
The question is what happens when another program (such as crashmail) accesses the same JAM file.
crashmail uses it's own rudimentary lock function, with a lock file, preventing it from having multiple runs at the same time (happens
quite often here) writing to the same JAM file.
I guess Golded don't respect the crashmail busy file? 8-)
The question is what happens when another program (such as crashmail)
accesses the same JAM file.
that shouldn't be a problem in most cases...
It is of course impossible to the rest of us to know what actually happened here...
#1 - why did you give up on your Tedious doover?
#2 - was there ever a public Linux version of Squish?
There's a couple of pennies in it for your musings. 8-)
There's a couple of pennies in it for your musings. 8-)
Fuck the pennies, give me a barrel of good old Aussie beer and I'm game.
Good answer! Just between you, me & that Aardvark over there: I have to confess that all the good beer has 'walked'. :)
I have to confess that all the good beer has 'walked'. :)
That certainly gives a new meaning to Walkabout Creek (Crocodile
Dundee 1, 2 and 3 being some of my absolute favourite movies ever).
#2 - was there ever a public Linux version of Squish?
Oh, yes... beer. I'm not a beer drinking feller but I'll tell you this much: 1982 was a very hot year, and there was a particularly nice ale produced by XXXX in Brisbane for the Commonwealth Games that same year. For that year only. The formula was never bottled again. I did my part for the games and downed a gallon or two. :)
#2 - was there ever a public Linux version of Squish?
Dunno, but the source code is PD so if anybody want to have a go on it, it's up for the grabs.
#2 - was there ever a public Linux version of Squish?
yes... the code for squish and maximus bbs were both released GPL and
were available on a repository... i had compiled the code at one time
but then some changes were made and i couldn't compile it any more...
that was ""several"" years ago... i don't think much of anything has
been done on it since...
There's a couple of pennies in it for your musings. 8-)
Fuck the pennies, give me a barrel of good old Aussie beer and I'm game.
There's a couple of pennies in it for your musings. 8-)
Fuck the pennies, give me a barrel of good old Aussie beer and I'm
game.
Good answer! Just between you, me & that Aardvark over there: I have to confess that all the good beer has 'walked'. :)
But then I discovered the Aussie Cooper's line of products, and my entire beer world changed. I realized that the Englishmen that went to Australia took with them something that was left behind -- true beer making.
I'm forever indebted to you Aussie guys for giving me the best brew you can make yourself.
BTW: From what I've heard it's the Swedish company Alfa Laval that made the machines for Cooper. 8-)
You'll note straight up that there's no warning of bad things about
the headers.
There's your problem. You most likely have bad binaries. I've
seen similar behaviour on my 'shadow' system, even with recent incarnations of later version binaries.
I'll send you a copy of the original archive. It'll just arrive unanounced in your _insecure_ inbound. The original binaries worked
well in Puppy Linux 5.25 and Xubuntu 11.10, and still run nicely in
the current Puppy 4.21 (yes, a retrograde step for very good reasons).
* destroy your existing JAM messagebase (completely? see note, below);
Your netmail area _may_ be okay? Is it a *.Msg area? Otherwise,
trash it too.
No other changes needed... fingers crossed. ;) Just let CM re-create your messagebase...
So why would you use Golded then, when it obviously corrupts your
JAM message bases? Run a JamNNTPd server and use Thunderbird or
something similar and you'll get tons of advantages.
So why would you use Golded then
, when it obviously corrupts your
JAM message bases?
Run a JamNNTPd server
and use Thunderbird
something similar and you'll get tons of
advantages.
Australia took with them something that was left behind -- true beer making.
I don't think it is Golded, you can see reply elsewhere... but
1) I nuked JAM base crashmail recreated them on receving new PKT -
same error 2) repeated #1 - insanity, see def., same 3) Used a 1.5
version on clean machine (VM) which has never had a JAM based, same
error, see reply 4) Used Golded 1.1.5 from the 3/22/16 source code and
it doesn't change anything
So I don't think this is Golded BUT CM II..
I have a hunch but I want some one else to post some info before I go
that route... its a hunch on something....
I believe you were already told that CM v1.5's deb package includes
broken binaries. Your better bet is probably to compile the original (.71?) or have someone (I believe Paul Quinn already offered you
binaries of the original version) give you some binaries to try out.
I believe you were already told that CM v1.5's deb package
includes broken binaries. Your better bet is probably to compile
the original (.71?) or have someone (I believe Paul Quinn already
offered you binaries of the original version) give you some
binaries to try out.
I don't think it matters what version it is...
0.71 has 5-6 files in the directory some too small to be source, no
clear directions on what to use, so moved on to 0.75 instead.
You'll note straight up that there's no warning of bad things aboutWhat is the setup on this? Distro and arch and version(s)?
the headers.
DEV VM for fido
Has no message bases, or anything on it.
took crashmail 1.5 DEB and installed
[ ...trimmed... ]I'll send you a copy of the original archive.
Nothing here...
0.71 has 5-6 files in the directory some too small to be source,
no clear directions on what to use, so moved on to 0.75 instead.
Anything above 0.71 was NOT by the original author. Whoever decided to
FWIW, I've tried three times to help you out (ie: binkd, husky
lets see this cm071linux.zip is big enough to have source[ ...trimmed... ]
hmmm it has binaries already in it: rec9140@fidodev:~/cmzip/crashmail-0.71/bin$ ./crashmail VERSION
This is CrashMail II version 0.71
Operating system: Linux
Compilation date: Jul 10 2004
Compilation time: 14:56:38
So... hmmm.. THIS file seems to work... as no error can't read messages...
I believe you were already told that CM v1.5's deb package includes
broken binaries. Your better bet is probably to compile the original
(.71?) or have someone (I believe Paul Quinn already offered you
binaries of the original version) give you some binaries to try out.
I don't think it matters what version it is...
I've managed to some how compile
1.5 0.75
and *ALL* exhibit the same behavior... error reading ....
So which of these?????????????????????
Only 2 are of any way close to be soure
0.71 has 5-6 files in the directory some too small to be source,
no clear directions on what to use, so moved on to 0.75 instead.
As per above, which of these:
crashmail_0.71-4.diff.gz 2010-08-12 14.3 kB 0
i crashmail_0.71-4.dsc 2010-08-12 1.1 kB 0
i crashmail_0.71-3.diff.gz 2009-07-11 14.0 kB 0
i crashmail_0.71-3.dsc 2009-07-11 1.1 kB 0
i cm071linux.zip 2009-02-17 361.6 kB 0
i crashmail_0.71-2.diff.gz 2007-09-02 4.0 kB 0
i crashmail_0.71-2.dsc 2007-09-02 567 Bytes 0
i crashmail_0.71-1.diff.gz 2004-07-28 3.8 kB 0
i crashmail_0.71-1.dsc 2004-07-28 567 Bytes 0
i crashmail_0.71.orig.tar.gz 2004-07-28 169.9 kB
Only the .orig.tar.gz and the cm071linux.zip seem to big enough to be source
lets see this cm071linux.zip is big enough to have source
Lets throw the library of PKTs at it!
Area NETMAIL -- 10 messages
Area PERSONAL_MESSAGES -- 77 messages
Area BINKD -- 151 messages
Area NET135 -- 3 messages
Area NET135FILE -- 104 messages
Area NET135HUB -- 122 messages
Area FIDONEWS -- 224 messages
Area RBERRYPI -- 110 messages
Area JAMNNTPD -- 150 messages
Total -> Read messages: 881 Written messages: 7 Imported -> Imported messages: 874 Routed netmails: 7
Bad -> Bad messages: 0 Duplicate messages: 0
Scanning for orphan files
Scanning for old packets
Scanning for new files to pack
Sending unpacked netmail to 1:135/300.0 (Normal)
Linking JAM area BINKD
Linking JAM area NET135
Linking JAM area NET135FILE
Linking JAM area NET135HUB
Linking JAM area FIDONEWS
Linking JAM area RBERRYPI
Linking JAM area JAMNNTPD
Scanning all areas for messages to export
Scanning area NETMAIL
Scanning area TESTECHO
Scanning area TEST
Scanning area BINKD
Scanning area NET135
Scanning area NET135FILE
Scanning area NET135HUB
Scanning area FIDONEWS
Scanning area RBERRYPI
Scanning area JAMNNTPD
No messages exported
Scanning for orphan files
Scanning for old packets
Scanning for new files to pack
CrashMail end
rec9140@fidodev:~/cmzip/crashmail-0.71/bin$
So... hmmm.. THIS file seems to work... as no error can't read
messages...
I've spent the better part of 20+ hours on this over the past 2
days...
Thats TOO MUCH! I've moved servers with less headaches in less time
than that.
It should be far simpler.. sudo apt-get install .... edit configs move
on.
Now it appears that possibly I've found a version that is the
"original" version.
Which you could have posted:
"Hey grab this file... cm071linux.zip at..http://......." and then run this.
EXPUNGE the DEB's in the repos. and all the other files on the source thingy and elsewhere... and see what kind of DEB's I can create that
will install a WORKING version of this....
I am not sure yet how to test this on the working setup.. I guess I
can run a parallel setup with the MSG format till it works and toss in things to a test JAM setup.... don't know.
I need booze right now... and lots of it....
I've got to get my notes into some sort of readable fashion and then
work on testing it, and then getting this online so NOBODY ever goes through this crap again!
i'm sorry to say that you seem to be expecting much too much of the software that you are choosing to test... descent linux based FTN
stuff hasn't been around all that long... it has been a long and hard fought battle to get what little bit of fTN software available for
anyone to use...
I use JAM exclusively, and Golded+ never corrupted anything here.The question is what happens when another program (such as
crashmail) accesses the same JAM file.
I have gotten setup with a node, changed the crashmail.prefs to that node.
Did my Areafix, and added some echos.. but when importing them I get:
! 23-Oct-16 22:09:37 Failed to read message #55 in JAM messagebase "/home/rec9140/fido/jam/BINKD"
! 23-Oct-16 22:09:37 Failed to read message #56 in JAM messagebase "/home/rec9140/fido/jam/BINKD"
! 23-Oct-16 22:09:37 Failed to read message #57 in JAM messagebase "/home/rec9140/fido/jam/BINKD"
When I started trying to setup jamnntpd here I noticed that when
posting messages it would corrupt a message base or not see all the messages. I concluded it was an alignment error because the int's
used in the library are not of size specific. the sizeof an int can
vary on architectures.. So when jamnntp's jamlib is built on a 64 bit platform some of them are wrong size.
It wouldn't take much to go thru the code and fix this, or simply
build it with -m32 option (which I tested and works fine).
For jamnntpd, I just went with the smapi version (though it had bad
bugs too) which are now corrected. It builds as a 64bit binary too...
no issues. I used golded, hpt, and jamnntpd together. I just need to
get off my butt and release what I have but there is one more thing I
want to correct before I do as well as test building on windows.
The state of fido software is that once someone gets something working they tend to not share it outright. Not out of malice - just out of
time constaints. they also don't tend to make things "release grade"
such that a novice user can simply install them. I do believe some
people want and would come back. We need to figure out how to make
this great modern software more easy to use and understand.
When I started trying to setup jamnntpd here I noticed that when
posting messages it would corrupt a message base or not see all the messages. I concluded it was an alignment error because the int's
used in the library are not of size specific. the sizeof an int can
vary on architectures.. So when jamnntp's jamlib is built on a 64 bit platform some of them are wrong size.
It wouldn't take much to go thru the code and fix this, or simply
build it with -m32 option (which I tested and works fine).
It wouldn't take much to go thru the code and fix this, or simply
build it with -m32 option (which I tested and works fine).
When I started trying to setup jamnntpd here I noticed that when
posting messages it would corrupt a message base or not see all the
messages. I concluded it was an alignment error because the int's
used in the library are not of size specific. the sizeof an int can
vary on architectures.. So when jamnntp's jamlib is built on a 64
bit platform some of them are wrong size.
It wouldn't take much to go thru the code and fix this, or simply
build it with -m32 option (which I tested and works fine).
DING!! DING!!
Well you have spilled the beans as it were.. I've been digging through that circular bug mess on this exact issue..
So is the V1.3 code at the SF stuff *correct* for *64b* operation or
no one knows as for some reason every one is using 32b??? And the only other working server user seems to be using OS/2 ... although his bug patch was added to the V1.3 code on 9/10/16.....
Again, this is why I asked, I want to use JamNNTPd to do some things..
but not CORRUPT of the Jam base with something that has the same issue..
So where is this -m32 option used????
Seems there IS a *magic golden* code base for JamNNTPd as well!
doesn't seem like that option is supported by "make" per man file:
-b, -m
These options are ignored for compatibility with other versions of make.
So this is changed where??
ahhh... 64bitness hasn't been indicated... i've been compiling my
jamnntpd on OS/2 with EMX so at best, only 32bit...
definitely something to remember... especially if one is, as i am, using the original jamlib instead of the MAPI or SMAPI libraries...
that's kind of my situation, too... but i did post patches or code to
this echo for others to grab and add to their code bases... it is just easier that way for me since i'm not going to fight trying to add repo stuffs to my production OS/2 box ;)
PS: it is good to see you again, matt!
03 Nov 16 22:09, you wrote to rick christian:
ahhh... 64bitness hasn't been indicated... i've been compiling my
ahhh... 64bitness hasn't been indicated... i've been compiling my
I indicated that from the start Ubuntu server 14.0.4.5 *64b*
ahhh... 64bitness hasn't been indicated... i've been compiling my
jamnntpd on OS/2 with EMX so at best, only 32bit...
definitely something to remember... especially if one is, as i am,
using the original jamlib instead of the MAPI or SMAPI libraries...
I specifically choose the smapi route because I knew it would be fine
with 64bit. There was simply a bug in jamnntpd's use of it such that
it wasn't closing the base after posting a message. If the process crashed it would corrupt the msgbase.
that's kind of my situation, too... but i did post patches or code to
this echo for others to grab and add to their code bases... it is
just easier that way for me since i'm not going to fight trying to
add repo stuffs to my production OS/2 box ;)
Does OS/2 support IPV6? I wondered if the changes I made for it would compile there though I am skeptical.
PS: it is good to see you again, matt!
thanks. Hopefully things are more civil in the areas. Havent read
them throughlly for a few months.
You need to edit the Makefile. In jamnntpd, it should be in src/Makefile.unix.
Find the line, CCOPTS and add to it -m32.
kinda yeah but it depends... i've been making liberal use of my twit filter, biting my tongue a lot, and not getting on the machine while consuming adult beverages and saying how i really feel about certain things... that's on my part but i still feel like saying a lot more
than i have, beverages or no...
kinda yeah but it depends... i've been making liberal use of my twit
filter, biting my tongue a lot, and not getting on the machine while
consuming adult beverages and saying how i really feel about certain
things... that's on my part but i still feel like saying a lot more
than i have, beverages or no...
More beverages + Less Fidonet = Happy camper. :)
yup, to a point... now i've been taking my beverages and going outside
to look for and count satellites i see flying over... sometimes i even make notes about them to i can determine which ones i've seen ;)
yup, to a point... now i've been taking my beverages and going
outside to look for and count satellites i see flying over...
sometimes i even make notes about them to i can determine which ones
i've seen ;)
Yeah, right. 8-)
Can you even determine if they are satellites or "falling stars"?
More beverages + Less Fidonet = Happy camper. :)
yup, to a point... now i've been taking my beverages and going outside
to look for and count satellites i see flying over... sometimes i even make notes about them to i can determine which ones i've seen ;)
More beverages + Less Fidonet = Happy camper. :)
yup, to a point... now i've been taking my beverages and going
outside to look for and count satellites i see flying over...
sometimes i even make notes about them to i can determine which ones
i've seen ;)
Still falls under the same category, doesn't it? :)
I'm just done arguing with this guy. He's in multiple echoes demanding
he is correct in everything he says. I just don't care enough. lol
I'm just done arguing with this guy. He's in multiple echoes
demanding he is correct in everything he says. I just don't care
enough. lol
i think he's seeing the light and realizing more now... it just takes time... i remember another fella that came around some years back full
of vim and vigor... he was of similar nature at the time... today he
is much easier to get along with and to chat with ;)
I'm just done arguing with this guy. He's in multiple echoes
demanding he is correct in everything he says. I just don't care
enough. lol
i think he's seeing the light and realizing more now... it just takes
time... i remember another fella that came around some years back
full of vim and vigor... he was of similar nature at the time...
today he is much easier to get along with and to chat with ;)
Hopefully (to the first part)!
Touché (to the second part)!
:)
i think he's seeing the light and realizing more now... it just
takes time... i remember another fella that came around some
years back full of vim and vigor... he was of similar nature at
the time... today he is much easier to get along with and to
chat with ;)
Hopefully (to the first part)!
yep...
Touché (to the second part)!
:)
HAHAHAHAHAHAHAHAHA! i was hoping you'd catch that and understand it as
it was intended... you done great, grasshopper! :)
Sysop: | Nelgin |
---|---|
Location: | Plano, TX |
Users: | 510 |
Nodes: | 10 (1 / 9) |
Uptime: | 131:41:19 |
Calls: | 8,198 |
Files: | 15,446 |
Messages: | 913,794 |