Hello all!

i'm running bink xe ver 6 i believe, and the ALT-O doesn't work. is there a reason why? i told it to poll a node, and it doesn't see it in the outbound area, and alt-o won't make it look at it.

thanks in adavance

ross


--- timEd/386 1.10.y2k+
* Origin: The Inner Circle, Cleveland, TN (423)479-3686 (1:362/708)

Ross Smarekar wrote in a message to all:


i'm running bink xe ver 6 i believe, and the ALT-O doesn't work. is there a reason why? i told it to poll a node, and it doesn't see it in the outbound area, and alt-o won't make it look at it.

_________

well, i just went and checked and it doesn't see the outbound area. i think this is weird, as it worked the last year, with no problem. i don't understand.

thanks in advance

ross




--- timEd/386 1.10.y2k+
* Origin: The Inner Circle, Cleveland, TN (423)479-3686 (1:362/708)

Hello, Ross...

Dec 05, 2002 at 08:23, Ross Smarekar wrote to all:

i'm running bink xe ver 6 i believe, and the ALT-O doesn't work. is
there a reason why? i told it to poll a node, and it doesn't see it
in the outbound area, and alt-o won't make it look at it.

Here, it usually means that there is a left-over flag in the FLAGS directory and Binkley thinks another task is accessing the outbound. Shut down Bink, delete all of the files in your flags directory (there will probably be 3 or 4)
and restart it.

Regards,

Jerry Schwartz

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

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

Jerry Schwartz wrote in a message to Ross Smarekar:

i'm running bink xe ver 6 i believe, and the ALT-O doesn't work. is
there a reason why? i told it to poll a node, and it doesn't see it
in the outbound area, and alt-o won't make it look at it.

Here, it usually means that there is a left-over flag in the FLAGS directory and Binkley thinks another task is accessing the outbound.
Shut down Bink, delete all of the files in your flags directory
(there will probably be 3 or 4) and restart it.

i don't have a flags directory. i run one dos task. i looked in the home and outbound directory for task files, and found nothing. still don't see the outbound.

thanks anyway

ross


--- timEd/386 1.10.y2k+
* Origin: The Inner Circle, Cleveland, TN (423)479-3686 (1:362/708)

Jerry Schwartz wrote in a message to Ross Smarekar:

i'm running bink xe ver 6 i believe, and the ALT-O doesn't work. is
there a reason why? i told it to poll a node, and it doesn't see it
in the outbound area, and alt-o won't make it look at it.

Here, it usually means that there is a left-over flag in the FLAGS directory and Binkley thinks another task is accessing the outbound.
Shut down Bink, delete all of the files in your flags directory
(there will probably be 3 or 4) and restart it.

well, i found it. there were some files in the bink directory that were called btrescan.???. i deleted them, and it fixed it. somehow i ended up with the orginal 2.60, so could someone please tell me where i can get the y2k update for it.

thanks

ross


--- timEd/386 1.10.y2k+
* Origin: The Inner Circle, Cleveland, TN (423)479-3686 (1:362/708)

Hello, Ross...

Dec 10, 2002 at 05:08, Ross Smarekar wrote to Jerry Schwartz:

Jerry Schwartz wrote in a message to Ross Smarekar:

i'm running bink xe ver 6 i believe, and the ALT-O doesn't work. is
there a reason why? i told it to poll a node, and it doesn't see it
in the outbound area, and alt-o won't make it look at it.

Here, it usually means that there is a left-over flag in the FLAGS
directory and Binkley thinks another task is accessing the outbound.
Shut down Bink, delete all of the files in your flags directory
(there will probably be 3 or 4) and restart it.

i don't have a flags directory. i run one dos task. i looked in the
home and outbound directory for task files, and found nothing. still don't see the outbound.

I think the rescan flags are still used, but I'm not sure where they are put. Look for files with names like BTRESCAN*

Regards,

Jerry Schwartz

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

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

Hi Ross,

somehow i ended up with the
orginal 2.60, so could someone please tell me where i
can get the y2k update for it.

I can't recall a Y2K release specificaly for Bink 2.60 nor Bink xe, both versions run fine here (using OS/2). My Bink/2 2.60 is dated 7 Apr 96 and Bink/2 XE is dated 5 Oct 98.

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


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

Ross Smarekar wrote in a message to Jerry Schwartz:

somehow i ended up with the orginal 2.60, so could someone please
tell me where i can get the y2k update for it.

I wasn't aware of any y2k issues with 2.60, which is what I run here. Been running it for several years now...

---
* Origin: TANSTAAFL BBS 717-838-8539 (1:270/615)

Peter Knapper wrote in a message to Ross Smarekar:

Hi Ross,

somehow i ended up with the
orginal 2.60, so could someone please tell me where i
can get the y2k update for it.

I can't recall a Y2K release specificaly for Bink 2.60 nor Bink xe,
both versions run fine here (using OS/2). My Bink/2 2.60 is dated 7
Apr 96 and Bink/2 XE is dated 5 Oct 98.

What does that XE version get you that the 2.60 version doesn't? I never went past 2.60 here...

---
* Origin: TANSTAAFL BBS 717-838-8539 (1:270/615)

Roy J. Tellason wrote in a message to Ross Smarekar:

somehow i ended up with the orginal 2.60, so could someone please
tell me where i can get the y2k update for it.

I wasn't aware of any y2k issues with 2.60, which is what I run
here. Been running it for several years now...

Yes there are a few issues with y2k and bink 260. Most noteably, IIRC, one which it shares with the XR6?? BTXE version I still run today... FTS0001 packet
dates get grunged ummm... might even grundge the packets altogether to where they don't process on some systems ??????. I know fer sure that there is a code
release out there that addresses the y2k stuff directly cause I have it... somewhere... and actually compiled it once.


*Paul*
--- timEd/386 1.10.y2k+
* Origin: Dumb Guy's!!! (1:124/5025)

Ross Smarekar wrote to Jerry Schwartz <=-

orginal 2.60, so could someone please tell me where i can get the y2k update
for it.

I have it here at Planet Maca's. its not Frequable though.
you will need to login and download it. Heres the info on the file: bd2k260a.zip BinkleyTerm 2.60, patched with severalY2K fixes.
Includes BinkleyTerm 2.60, patched with several
Y2K fixes. Includes DOS EXE and patched source code.


... My bbs is Toll free for any AT&T unlimited customer
--- blueMail/Linux 0.11
--- SBBSecho 2.00-Linux
* Origin: Planet Maca's Opus 860-738-7176 300-33.6kbps (1:142/7176)

Replying to a message from Peter Knapper 3:772/1.10 to Ross Smarekar,

About binkley xe , On Sat Dec 14 2002

I can't recall a Y2K release specificaly for Bink 2.60 nor Bink xe,
both versions run fine here (using OS/2). My Bink/2 2.60 is dated 7
Apr 96 and Bink/2 XE is dated 5 Oct 98.

Binkley 2.60 DOS has a Y2K patch. The OS/2 version did not need it.

Bd2K260A.Zip 222,754 10-12-98 6:46pm

File_Id.Diz:

BinkleyTerm 2.60, patched with several
Y2K fixes. Includes DOS EXE and patched
source code.

I will ship via the internet to anyone that wishes, or it was available at juge.com.

Hope this helps. Keep us posted.

We are a fine board trying to make it better.
http://www.pris.bc.ca/ghannah
ghannah@pris.bc.ca
Cheers! Gord
-=Team OS/2=-
--- timEd/2 1.10.y2k+
* Origin: Marsh BBS (c), Dawson Creek, BC Canada (1:17/23.1)

Hi Roy,

I can't recall a Y2K release specificaly for Bink 2.60 nor Bink xe,
both versions run fine here (using OS/2). My Bink/2 2.60 is dated 7
Apr 96 and Bink/2 XE is dated 5 Oct 98.

What does that XE version get you that the 2.60
version doesn't? I never went past 2.60 here...

I switched my Point to XE6 so long ago I forgot exactly why I did that....;-) It was something to do with the way it could be configured, but I can't remember the details because my point has been using BinkD for several years now........;-) I don't think you are missing much.

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


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

Paul Lentz wrote in a message to Roy J. Tellason:

Roy J. Tellason wrote in a message to Ross Smarekar:

somehow i ended up with the orginal 2.60, so could someone please
tell me where i can get the y2k update for it.

I wasn't aware of any y2k issues with 2.60, which is what I run
here. Been running it for several years now...

Yes there are a few issues with y2k and bink 260. Most noteably,
IIRC, one which it shares with the XR6?? BTXE version I still run
today... FTS0001 packet dates get grunged ummm... might even
grundge the packets altogether to where they don't process on some
systems ??????. I know fer sure that there is a code release out
there that addresses the y2k stuff directly cause I have it... somewhere... and actually compiled it once.

I guess I must be missing something here, because I don't see where bink has anything to do with packet dates. It doesn't create them, at least not here.
The only thing I have it doing is answer the phone, transfer files back and forth, and hand off to another package for dialing my uucp connection, or to the bbs. That, and kick off the mail tossing process when there's some incoming.

Where does it deal with packet dates?

---
* Origin: TANSTAAFL BBS 717-838-8539 (1:270/615)

Roy J. Tellason wrote in a message to Paul Lentz:

today... FTS0001 packet dates get grunged ummm... might even

I guess I must be missing something here, because I don't see
where bink has anything to do with packet dates. It doesn't create
them, at least not here. The only thing I have it doing is answer
the phone, transfer files back and forth, and hand off to another package for dialing my uucp connection, or to the bbs. That, and
kick off the mail tossing process when there's some incoming.

Where does it deal with packet dates?

FTS-0001 calls produce an outgoing packet header that it sends to the other machine that is filled up like normal packets with originating/destination zone/net/node info and password, date/time info, etc.. Both machines exchanges that instead of the EMSI handshake information. Of course FTS-0001 is rarely used... but it is broken in older non-y2k binks.

Also for example... the BTXE 2.60 XR6??? early-ish version I'm running right now also has the date proudly displayed as "102/12/14"... I couldn't get later versons running correctly so I live with it, also later verions had pull down this, zoom that, buffer this other stuff that was useless code bloat for an unattended mailer that you touch a key on once a week.


*Paul*
--- timEd/386 1.10.y2k+
* Origin: Dumb Guy's!!! (1:124/5025)

Peter Knapper wrote in a message to Roy J. Tellason:

I can't recall a Y2K release specificaly for Bink 2.60 nor Bink xe,
both versions run fine here (using OS/2). My Bink/2 2.60 is dated 7
Apr 96 and Bink/2 XE is dated 5 Oct 98.

What does that XE version get you that the 2.60
version doesn't? I never went past 2.60 here...

I switched my Point to XE6 so long ago I forgot exactly why I did that....;-) It was something to do with the way it could be
configured, but I can't remember the details because my point has
been using BinkD for several years now........;-) I don't think you
are missing much.

I never did get a hold of any subsequent versions, somehow.

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

But I _do_ have 2.60 for OS/2! :-)

---
* Origin: TANSTAAFL BBS 717-838-8539 (1:270/615)

Paul Lentz wrote in a message to Roy J. Tellason:

Roy J. Tellason wrote in a message to Paul Lentz:

today... FTS0001 packet dates get grunged ummm... might even

I guess I must be missing something here, because I don't see
where bink has anything to do with packet dates. It doesn't create
them, at least not here. The only thing I have it doing is answer
the phone, transfer files back and forth, and hand off to another package for dialing my uucp connection, or to the bbs. That, and
kick off the mail tossing process when there's some incoming.

Where does it deal with packet dates?

FTS-0001 calls produce an outgoing packet header that it sends to
the other machine that is filled up like normal packets with originating/destination zone/net/node info and password, date/time
info, etc.. Both machines exchanges that instead of the EMSI
handshake information. Of course FTS-0001 is rarely used... but it
is broken in older non-y2k binks.

Oh! Well, here I am, running broken software and not even realizing it... :-)

I'm pretty sure that most all of my calls lately have been using that EMSI handshake when the two systems connect.

Also for example... the BTXE 2.60 XR6??? early-ish version I'm
running right now also has the date proudly displayed as
"102/12/14"... I couldn't get later versons running correctly so I
live with it,

I have a version of LIST like that, shows today's date as 12/15/:2. I actually did get a newer one but have never bothered to install it, since it's
only cosmetic here.

also later verions had pull down this, zoom that, buffer this
other stuff that was useless code bloat for an unattended mailer
that you touch a key on once a week.

That sounds to me like a lot of the reason that I didn't move past 2.60, maybe
it was stuff that I was reading in here at the time, I don't recall. About all I ever do with mine is blank or unblank the screen, manually generate a poll from time to time, and that's about it. Guess I'll stay with it, then...

---
* Origin: TANSTAAFL BBS 717-838-8539 (1:270/615)

Hello, Roy;

15 Dec 02 12:05, Roy J. Tellason wrote to Paul Lentz:

That sounds to me like a lot of the reason that I didn't move past
2.60, maybe it was stuff that I was reading in here at the time, I

XE versions hve Hydra protocol built in, which is an improvement over Janus
- if it bothers anybody these days...

Regards,

Robert.

--- GoldED 3.00.Beta2+
* Origin: The Luminous Void (2:250/501.4)

Robert Bull wrote in a message to Roy J. Tellason:

Hello, Roy;

15 Dec 02 12:05, Roy J. Tellason wrote to Paul Lentz:

That sounds to me like a lot of the reason that I didn't move past
2.60, maybe it was stuff that I was reading in here at the time, I

XE versions hve Hydra protocol built in, which is an improvement
over Janus - if it bothers anybody these days...

I could probably count the number of times that people have connected with such
a bidirectional protocol without running out of fingers...

---
* Origin: TANSTAAFL BBS 717-838-8539 (1:270/615)

Hi Roy J. Tellason, hope you are having a nice day

That sounds to me like a lot of the reason that I didn't move past RT>>>2.60, maybe it was stuff that I was reading in here at the time, I RB>>XE versions hve Hydra protocol built in, which is an improvement

over Janus - if it bothers anybody these days...

I could probably count the number of times that people have connected RJT>with such a bidirectional protocol without running out of fingers...

Well then how about the ability of 2.60XEbeta-XH7 to handle f'reqs
that use longfilenames? ]:>

Yours sincerely, Paul Williams <=-

... "Musta gone through a brain-freeze there."--K'vin vanH'ten
--- Terminate 4.00/Pro
* Origin: Armed...Dangerous...and off my medication. (1:387/710)

Paul Williams wrote in a message to Roy J. Tellason:

Hi Roy J. Tellason, hope you are having a nice day

Not bad...

That sounds to me like a lot of the reason that I didn't move past RT>>>2.60, maybe it was stuff that I was reading in here at the time, I

XE versions hve Hydra protocol built in, which is an improvement
over Janus - if it bothers anybody these days...

I could probably count the number of times that people have
connected with such a bidirectional protocol without running out of RJT>fingers...

Well then how about the ability of 2.60XEbeta-XH7 to handle f'reqs
that use longfilenames? ]:>

Now with THAT you caught my attention... :-)

I'd like to see all of what I have on hand here deal well with LFNs, but hadn't really held out much hope of that. From what I understand Maximus doesn't deal with them at all, so I'd figured on sticking with 8.3 in the files section for now and seeing what worked out over time as things got ported
to other platforms.

Is that version available for OS/2 as well as dos?

---
* Origin: TANSTAAFL BBS 717-838-8539 (1:270/615)

Hi Roy J. Tellason, hope you are having a nice day

Well then how about the ability of 2.60XEbeta-XH7 to handle f'reqs PW>>that use longfilenames? ]:>

Now with THAT you caught my attention... :-)

Thought it might. Can't say to what degree it works w/ 8.3 dos
systems but I told it to get a file w/ more than one . in it and
the .req in the outbound had the whole name.

Figure where lfn abled os's are concerned though it oughta do
just fine.

Is that version available for OS/2 as well as dos?

I've got the dos, w32, and os/2 versions plus the sourcecode archive.

You might have a prob w/ the os/2 version but I'm not certain. I
sent a copy to my feed in a othernet who runs warp4 and he couldn't
get it to work. Something abt the xh7 being a watcomm compile instead
of the vaxx compiled version. <shrug>

Yours sincerely, Paul Williams <=-

... "BTW, Rivendell still has your rump."--Scotty "Deservedly so."--Dex
--- Terminate 4.00/Pro
* Origin: Texas math: .357 + .30x.30 + .44 = 0 (1:387/710)

Paul Williams wrote in a message to Roy J. Tellason:

Hi Roy J. Tellason, hope you are having a nice day

Well then how about the ability of 2.60XEbeta-XH7 to handle f'reqs PW>>that use longfilenames? ]:>

Now with THAT you caught my attention... :-)

Thought it might. Can't say to what degree it works w/ 8.3 dos
systems but I told it to get a file w/ more than one . in it and
the .req in the outbound had the whole name.

Figure where lfn abled os's are concerned though it oughta do just
fine.

Is that version available for OS/2 as well as dos?

I've got the dos, w32, and os/2 versions plus the sourcecode
archive.

You might have a prob w/ the os/2 version but I'm not certain. I
sent a copy to my feed in a othernet who runs warp4 and he couldn't
get it to work. Something abt the xh7 being a watcomm compile
instead of the vaxx compiled version. <shrug>

Still sounds to me like it'd be worth trying out. Thanks!

---
* Origin: TANSTAAFL BBS 717-838-8539 (1:270/615)

Hello, Roy;

23 Dec 02 04:06, Roy J. Tellason wrote to Robert Bull:

I could probably count the number of times that people have connected
with such a bidirectional protocol without running out of fingers...

My Binkley is set to offer bidirectional protocols as standard,

BiDiBaud 2400 ; BiDi default max speed
BiDiOK /Arq/V ; BiDi ok any Arq except HST ProtocolPreference HYD,JAN,ZAP,ZMO

and that's what I get;

: 29 Dec 19:26:01.74 BINK Session method: xHydra
* 29 Dec 19:26:01.29 BINK HCON: * Remote has chat facility (bell enabled)
* 29 Dec 19:26:02.95 BINK HMSGDEV: Remote has 153590 bytes for us

Of course, given that I'm a point, it's usually very unbalanced and there's
no great improvement in efficiency. OTOH there's no significant penalty either, so on the odd occasion when I upload something, there's a gain. It used to be more valuable when I uploaded more, but of course these days everybody tends to get things off the Internet.

Regards,

Robert.

--- GoldED 3.00.Beta2+
* Origin: The Luminous Void (2:250/501.4)

Hello, Neil;

29 Dec 02 08:19, Neil Walker wrote to Paul Williams:

It's been a long time but I seem to remember being unable to get the Watcom version to run. The VAC++ version is in BOS2IXH7.ZIP available

Mine Watcom-compiled version seems fine, but then I'm using DOS not OS/2.

Regards,

Robert.

--- GoldED 3.00.Beta2+
* Origin: The Luminous Void (2:250/501.4)

Hello Robert!

Sunday December 29 2002 19:53, you wrote to me:

It's been a long time but I seem to remember being unable to get
the Watcom version to run. The VAC++ version is in BOS2IXH7.ZIP
available

Mine Watcom-compiled version seems fine, but then I'm using DOS not
OS/2.

Yes, it was just the Watcom OS/2 version that was a problem but, as the VAC++ version worked fine, I never persevered with the Watcom compile.


Be lucky,

Neil

This OS/2 system uptime is 102 days 21:38 hours and 47 seconds
... A $300.00 Picture tube will protect a 10 cent fuse by blowing first.
--- GoldED+/EMX 1.1.5-21110
* Origin: Living in interesting times (2:250/501)

Hello Roy!

Monday December 23 2002 04:06, Roy J. Tellason wrote to Robert Bull:

I could probably count the number of times that people have connected with such a bidirectional protocol without running out of fingers...

Same here. Back in the days of POTS echomail transfers, bidirectional support made sense. It basically gave you free outgoing while picking up your incoming. With most people using the internet in some form for echomail transfers today, bidirectional support is no longer nearly as important as it used to be.

Andrew

---
* Origin: Bits & Bytes BBS * V.Everything! * 860/535-4284 (1:320/119)

Robert Bull wrote in a message to Roy J. Tellason:

Hello, Roy;

23 Dec 02 04:06, Roy J. Tellason wrote to Robert Bull:

I could probably count the number of times that people have connected
with such a bidirectional protocol without running out of fingers...

My Binkley is set to offer bidirectional protocols as standard,

Mine's got stuff in there too about them, not sure what you mean by "as standard" -- default? I could post the lines from my config if you're interested.

BiDiBaud 2400 ; BiDi default max
speed BiDiOK /Arq/V ; BiDi ok any
Arq except HST ProtocolPreference HYD,JAN,ZAP,ZMO

and that's what I get;

: 29 Dec 19:26:01.74 BINK Session method: xHydra
* 29 Dec 19:26:01.29 BINK HCON: * Remote has chat facility (bell
enabled) * 29 Dec 19:26:02.95 BINK HMSGDEV: Remote has 153590 bytes
for us

Of course, given that I'm a point, it's usually very unbalanced and there's no great improvement in efficiency.

Same here.

OTOH there's no significant penalty either, so on the odd occasion
when I upload something, there's a gain.

I don't think there is an occasion when I don't have outgoing. <g>

It used to be more valuable when I uploaded more, but of course
these days everybody tends to get things off the Internet.

Not here yet. Though I suppose that it's probably gonna get there eventually.

---
* Origin: TANSTAAFL BBS 717-838-8539 (1:270/615)

Hello, Roy;

30 Dec 02 20:10, Roy J. Tellason wrote to Robert Bull:

My Binkley is set to offer bidirectional protocols as standard,

Mine's got stuff in there too about them, not sure what you mean by
"as standard" -- default? I could post the lines from my config if
you're interested.

AIUI, my Binkley offers the protocols _in the order in which I've entered them_ in the config, with the idea that both ends try to agree on the
highest common denominator. Of course, Andrew's right now that Internet transfers are so common, but then I'm still on POTS.

I don't think there is an occasion when I don't have outgoing. <g>

:-)

Regards,

Robert.

--- GoldED 3.00.Beta2+
* Origin: The Luminous Void (2:250/501.4)

Robert Bull wrote in a message to Roy J. Tellason:

Hello, Roy;

30 Dec 02 20:10, Roy J. Tellason wrote to Robert Bull:

My Binkley is set to offer bidirectional protocols as standard,

Mine's got stuff in there too about them, not sure what you mean by
"as standard" -- default? I could post the lines from my config if
you're interested.

AIUI, my Binkley offers the protocols _in the order in which I've
entered them_ in the config, with the idea that both ends try to
agree on the highest common denominator.

This got me curious enough to go in there and look, but it's been *so* long since I've messed with anything at all in there I'm not even sure any more which bits apply to this. Perhaps it's this stuff:

Janusbaud 2400
JanusOK /Arq/V
JanusOK /V

that I found near the end of the file. The file date only goes back to last September, but that must have been a relatively minor edit...

Of course, Andrew's right now that Internet transfers are so
common, but then I'm still on POTS.

As am I, for the most part.

I don't think there is an occasion when I don't have outgoing. <g>

:-)

Actually the morning and noon polls don't usually get answered until I get home
from work. On work days, that is. :-)

---
* Origin: TANSTAAFL BBS 717-838-8539 (1:270/615)

Hello, Roy;

02 Jan 03 04:06, Roy J. Tellason wrote to Robert Bull:

AIUI, my Binkley offers the protocols _in the order in which I've
entered them_ in the config, with the idea that both ends try to
agree on the highest common denominator.

This got me curious enough to go in there and look, but it's been
*so* long since I've messed with anything at all in there I'm not even sure any more which bits apply to this. Perhaps it's this stuff:

Janusbaud 2400
JanusOK /Arq/V
JanusOK /V

I don't have Janus stuff as such. I think - _without_ having checked the Binkley docs - that that area is covered by

BiDiBaud 2400 ; BiDi default max speed
BiDiOK /Arq/V ; BiDi ok any Arq except HST ProtocolPreference HYD,JAN,ZAP,ZMO

meaninig the BiDis apply to whichever bidirectional protocol is in use.
The last line, ProtocolPreference, seems to be the key one in that it tells
my end to offer Hydra first, then Janus, ZedZap, and so on, /in that
order/, and to use the first one that the remote end accepts. The record
of my last call to you (freq'd PLZ22.LZH) has got chopped off the top of my log file, so I can't check it.

Actually the morning and noon polls don't usually get answered until I
get home from work. On work days, that is. :-)

:-)

Regards,

Robert.

--- GoldED 3.00.Beta2+
* Origin: The Luminous Void (2:250/501.4)

Robert Bull wrote in a message to Roy J. Tellason:

AIUI, my Binkley offers the protocols _in the order in which I've
entered them_ in the config, with the idea that both ends try to
agree on the highest common denominator.

This got me curious enough to go in there and look, but it's been
*so* long since I've messed with anything at all in there I'm not even sure any more which bits apply to this. Perhaps it's this stuff:

Janusbaud 2400
JanusOK /Arq/V
JanusOK /V

I don't have Janus stuff as such. I think - _without_ having
checked the Binkley docs - that that area is covered by

BiDiBaud 2400 ; BiDi default max speed BiDiOK
/Arq/V ; BiDi ok any Arq except HST ProtocolPreference HYD,JAN,ZAP,ZMO

meaninig the BiDis apply to whichever bidirectional protocol is in
use. The last line, ProtocolPreference, seems to be the key one
in that it tells my end to offer Hydra first, then Janus, ZedZap,
and so on, /in that order/, and to use the first one that the
remote end accepts.

It's been so long since I've fiddled with any of this stuff I have no recollection at this point in time as to what protocols are included in the setup, which I might need to have available as "external", and so forth. What difference would the order make? Are some of these to be preferred over others? It's been a *long* time since I've seen any discussion of this sort of
thing. <g>

The record of my last call to you (freq'd PLZ22.LZH) has got
chopped off the top of my log file, so I can't check it.

I keep old logs:

# 22 Nov 16:08:49 BINK Ring
# 22 Nov 16:09:04 BINK Connect 4800/Arq/V34/Lapm/V42Bis
* 22 Nov 16:09:09 BINK The Luminous Void (2:250/333.4@fidonet.org)
: 22 Nov 16:09:09 BINK Aka: 2:250/501.4@fidonet.org 509:100/1.4@fidonet.org 2:2 * 22 Nov 16:09:09 BINK Remote Uses BT 2.60XE/Beta-XH4+CE1+AW1+AW2+AW3+AW4 Watco : 22 Nov 16:09:09 BINK SysOp: Robert Bull from Coleford_Somerset
: 22 Nov 16:09:09 BINK Tranx: 3DDE56A3 / 3DDE9D33
: 22 Nov 16:09:11 BINK Session method: Janus
# 22 Nov 16:09:12 BINK Receiving Mail Packet 22211014.Pkt
* 22 Nov 16:09:13 BINK File Request (PLZ22.LZH)
# 22 Nov 16:09:13 BINK Sending H:\Max\File\Bbs\PLZ22.LZH
+ 22 Nov 16:09:21 BINK CPS: 1904 (15237 bytes) Efficiency: 396%
+ 22 Nov 16:09:21 BINK Sent-J/32 H:\Max\File\Bbs\PLZ22.LZH
+ 22 Nov 16:09:43 BINK CPS: 8 (273 bytes) Efficiency: 1%
+ 22 Nov 16:09:43 BINK Received-J/32 M:\Max\File\Inbound\22211014.Pkt
* 22 Nov 16:09:44 BINK End of WaZOO/EMSI Session

Almost pasted the wrong call in there, the other one being from the other person who started this thread, Paul Williams.

Wow, 396% efficient! I like those numbers... :-)

---
* Origin: TANSTAAFL BBS 717-838-8539 (1:270/615)

Hello Roy!

Sunday January 05 2003 20:03, you wrote to Robert Bull:

It's been so long since I've fiddled with any of this stuff I have no recollection at this point in time as to what protocols are included
in the setup, which I might need to have available as "external",
and so forth. What difference would the order make? Are some of
these to be preferred over others? It's been a *long* time since I've seen any discussion of this sort of thing. <g>

Just thought I would do a little trial and freq that same file. This is what I got:

=== Cut ===
06 Jan 06:38:56.10 BINK 'CONNECT 28800/ARQ/V34/LAPM/V42BIS'
: 06 Jan 06:38:58.81 BINK LocMOH: 310b
* 06 Jan 06:39:00.85 BINK System: TANSTAAFL BBS (1:270/615)
06 Jan 06:39:00.85 BINK Aka : 1:270/0 70:5/0 176:500/13 9:6800/615
* 06 Jan 06:39:00.85 BINK Uses : BinkleyTerm 2.60/(UNREGISTERED)
: 06 Jan 06:39:00.85 BINK Sysop : Roy J. Tellason from Palmyra, PA
06 Jan 06:39:00.86 BINK Flags : (null)
06 Jan 06:39:00.86 BINK Phone : (717) 838-8539
: 06 Jan 06:39:00.86 BINK RemTim: Mon, 06 Jan 2003 01:36:29 +0000
: 06 Jan 06:39:00.86 BINK LocTim: Mon, 06 Jan 2003 06:38:58 +0000
: 06 Jan 06:39:00.86 BINK UTCdif: -18149
: 06 Jan 06:39:00.98 BINK Session method: Hydra
: 06 Jan 06:39:00.98 BINK Outbound file requests.
+ 06 Jan 06:39:02.30 BINK CPS: 40 (11 bytes) Efficiency: 1%
+ 06 Jan 06:39:02.30 BINK Sent-H/32 D:\MAIL\OUTBOUND\OUT.001\010E0267.REQ
06 Jan 06:39:02.30 BINK Sending Mail Packet.
+ 06 Jan 06:39:02.91 BINK CPS: 906 (299 bytes) Efficiency: 25%
+ 06 Jan 06:39:02.91 BINK Sent-H/32 D:\MAIL\OUTBOUND\OUT.001\010E0267.CUT
# 06 Jan 06:39:04.30 BINK Receiving Net File plz22.lzh
+ 06 Jan 06:39:09.91 BINK CPS: 2716 (15237 bytes) Efficiency: 75%
+ 06 Jan 06:39:09.91 BINK Received-H/32 D:\Mail\In\Known\plz22.lzh
* 06 Jan 06:39:11.74 BINK End of WaZOO/EMSI Session.
06 Jan 06:39:12.41 BINK '3Com USRobotics Courier V.Everything EXT'
06 Jan 06:39:12.41 BINK '3Com USRobotics Courier V.Everything Link Diagnostics...'
06 Jan 06:39:12.41 BINK 'Chars sent 1507 Chars Received 16523'
06 Jan 06:39:12.41 BINK 'Chars lost 0'
06 Jan 06:39:12.42 BINK 'Octets sent 1205 Octets Received
16431'
06 Jan 06:39:12.42 BINK 'Blocks sent 68 Blocks Received
196'
06 Jan 06:39:12.42 BINK 'Blocks resent 0'
06 Jan 06:39:12.42 BINK 'Retrains Requested 0 Retrains Granted 0'
06 Jan 06:39:12.43 BINK 'Line Reversals 0 Blers 0'
06 Jan 06:39:12.43 BINK 'Link Timeouts 0 Link Naks 0'
06 Jan 06:39:12.43 BINK 'Data Compression V42BIS 2048/32'
06 Jan 06:39:12.43 BINK 'Equalisation Long'
06 Jan 06:39:12.44 BINK 'Fallback Enabled'
06 Jan 06:39:12.44 BINK 'Protocol LAPM SREJ 244/15'
06 Jan 06:39:12.44 BINK 'Speed 31200/26400'
06 Jan 06:39:12.44 BINK 'Last Call 00:00:15'
06 Jan 06:39:12.56 BINK 'Disconnect Reason is DTR dropped'
06 Jan 06:39:16.88 BINK Received: 1/15K Sent: 2/0K Total: 3/15K CPS: 555
* 06 Jan 06:39:16.88 BINK Seconds: 28 Tariff: 0 Fee: 0 RFee: 0 System: 1:270/615
=== Cut ===

Looks like you have Hydra working. :-)


Be lucky,

Neil

This OS/2 system uptime is 110 days 06:56 hours and 13 seconds
... [sigh] Nostalgia just isn't what it used to be ...
--- GoldED+/EMX 1.1.5-21110
* Origin: The Electric Pigeon, Telford, UK (2:250/501)

Neil Walker wrote in a message to Roy J. Tellason:

Hello Roy!

Sunday January 05 2003 20:03, you wrote to Robert Bull:

It's been so long since I've fiddled with any of this stuff I have no recollection at this point in time as to what protocols are included
in the setup, which I might need to have available as "external",
and so forth. What difference would the order make? Are some of
these to be preferred over others? It's been a *long* time since I've seen any discussion of this sort of thing. <g>

Just thought I would do a little trial and freq that same file.
This is what I got:

=== Cut ===
06 Jan 06:38:56.10 BINK 'CONNECT 28800/ARQ/V34/LAPM/V42BIS' : 06
Jan 06:38:58.81 BINK LocMOH: 310b
* 06 Jan 06:39:00.85 BINK System: TANSTAAFL BBS (1:270/615)
06 Jan 06:39:00.85 BINK Aka : 1:270/0 70:5/0 176:500/13
9:6800/615 * 06 Jan 06:39:00.85 BINK Uses
: BinkleyTerm 2.60/(UNREGISTERED)
: 06 Jan 06:39:00.85 BINK Sysop
: Roy J. Tellason from Palmyra, PA
06 Jan 06:39:00.86 BINK Flags
: (null)
06 Jan 06:39:00.86 BINK Phone : (717) 838-8539
: 06 Jan 06:39:00.86 BINK RemTim: Mon, 06 Jan 2003 01:36:29 +0000
: 06 Jan 06:39:00.86 BINK LocTim: Mon, 06 Jan 2003 06:38:58 +0000
: 06 Jan 06:39:00.86 BINK UTCdif: -18149
: 06 Jan 06:39:00.98 BINK Session method: Hydra
: 06 Jan 06:39:00.98 BINK Outbound file requests.
+ 06 Jan 06:39:02.30 BINK CPS: 40 (11 bytes) Efficiency: 1%
+ 06 Jan 06:39:02.30 BINK Sent-H/32
D:\MAIL\OUTBOUND\OUT.001\010E0267.REQ
06 Jan 06:39:02.30 BINK Sending Mail Packet.
+ 06 Jan 06:39:02.91 BINK CPS: 906 (299 bytes) Efficiency: 25%
+ 06 Jan 06:39:02.91 BINK Sent-H/32
D:\MAIL\OUTBOUND\OUT.001\010E0267.CUT
# 06 Jan 06:39:04.30 BINK Receiving Net File plz22.lzh
+ 06 Jan 06:39:09.91 BINK CPS: 2716 (15237 bytes) Efficiency: 75%
+ 06 Jan 06:39:09.91 BINK Received-H/32 D:\Mail\In\Known\plz22.lzh
* 06 Jan 06:39:11.74 BINK End of WaZOO/EMSI Session.
06 Jan 06:39:12.41 BINK '3Com USRobotics Courier V.Everything
EXT'
06 Jan 06:39:12.41 BINK '3Com USRobotics Courier V.Everything
Link Diagnostics...'
06 Jan 06:39:12.41 BINK 'Chars sent 1507
Chars Received 16523'
06 Jan 06:39:12.41 BINK 'Chars lost 0'
06 Jan 06:39:12.42 BINK 'Octets sent 1205
Octets Received 16431'
06 Jan 06:39:12.42 BINK 'Blocks sent 68
Blocks Received 196'
06 Jan 06:39:12.42 BINK 'Blocks resent 0'
06 Jan 06:39:12.42 BINK 'Retrains Requested 0
Retrains Granted 0'
06 Jan 06:39:12.43 BINK 'Line Reversals 0
Blers 0'
06 Jan 06:39:12.43 BINK 'Link Timeouts 0
Link Naks 0'
06 Jan 06:39:12.43 BINK 'Data Compression V42BIS 2048/32'
06 Jan 06:39:12.43 BINK 'Equalisation Long'
06 Jan 06:39:12.44 BINK 'Fallback Enabled'
06 Jan 06:39:12.44 BINK 'Protocol LAPM SREJ 244/15'
06 Jan 06:39:12.44 BINK 'Speed 31200/26400' 06
Jan 06:39:12.44 BINK 'Last Call 00:00:15'
06 Jan 06:39:12.56 BINK 'Disconnect Reason is DTR dropped' 06
Jan 06:39:16.88 BINK Received: 1/15K Sent: 2/0K Total: 3/15K CPS:
555 * 06 Jan 06:39:16.88 BINK Seconds: 28 Tariff: 0 Fee: 0 RFee:
0 System: 1:270/615
=== Cut ===

Looks like you have Hydra working. :-)

Yeah, it sure does. Here's what it looks like from this end:

# 06 Jan 05:36:58 BINK Ring
# 06 Jan 05:37:11 BINK Connect 24000/Arq/V34/Lapm/V42Bis
* 06 Jan 05:37:16 BINK -=Templar's XPoint=- (2:250/501.11@fidonet.org)
: 06 Jan 05:37:16 BINK Aka: 509:100/1.11@fidonet.org
* 06 Jan 05:37:16 BINK Remote Uses CrossPoint/XP-FM 3.11b/R/19982
: 06 Jan 05:37:16 BINK SysOp: Archie Swan
: 06 Jan 05:37:17 BINK Session method: Hydra
# 06 Jan 05:37:17 BINK Receiving Net File 010e0267.r01
+ 06 Jan 05:37:17 BINK CPS: 0 (11 bytes) Efficiency: 0%
+ 06 Jan 05:37:17 BINK Received-H/32 M:\Max\File\Inbound\010e0267.r01
* 06 Jan 05:37:18 BINK File Request (PLZ22.LZH)
+ 06 Jan 05:37:24 BINK CPS: 3047 (15237 bytes) Efficiency: 126%
+ 06 Jan 05:37:24 BINK Sent-H/32 H:\MAX\FILE\BBS\PLZ22.LZH
+ 06 Jan 05:37:24 BINK Nothing to send to 2:250/501.11@fidonet.org
* 06 Jan 05:37:24 BINK End of WaZOO/EMSI Session
* 06 Jan 05:37:28 BINK Seconds: 19 Tariff: 0 Fee: 0 System: 2:250/501.11@fid # 06 Jan 05:37:28 BINK Usrobotics Courier V.Everything Link Diagnostics...
# 06 Jan 05:37:28 BINK Chars Sent 16673 Chars Received
# 06 Jan 05:37:28 BINK Chars Lost 0
# 06 Jan 05:37:28 BINK Octets Sent 16515 Octets Received
# 06 Jan 05:37:28 BINK Blocks Sent 203 Blocks Received
# 06 Jan 05:37:28 BINK Blocks Resent 0
# 06 Jan 05:37:28 BINK Retrains Requested 0 Retrains Granted
# 06 Jan 05:37:28 BINK Line Reversals 0 Blers
# 06 Jan 05:37:28 BINK Link Timeouts 0 Link Naks
# 06 Jan 05:37:28 BINK Data Compression V42Bis 2048/32
# 06 Jan 05:37:28 BINK Equalization Long
# 06 Jan 05:37:28 BINK Fallback Enabled
# 06 Jan 05:37:28 BINK Protocol Lapm 128/15
# 06 Jan 05:37:28 BINK Speed 24000/28800
# 06 Jan 05:37:28 BINK Last Call 00:00:14

Dunno what I did to get hydra working, but there it is.

---
* Origin: TANSTAAFL BBS 717-838-8539 (1:270/615)

following up a message from Roy J. Tellason to Neil Walker:

Neil Walker wrote in a message to Roy J. Tellason:

Hello Roy!

Sunday January 05 2003 20:03, you wrote to Robert Bull:

It's been so long since I've fiddled with any of this stuff I have no recollection at this point in time as to what protocols are included
in the setup, which I might need to have available as "external",
and so forth. What difference would the order make? Are some of
these to be preferred over others? It's been a *long* time since I've seen any discussion of this sort of thing. <g>

Just thought I would do a little trial and freq that same file.
This is what I got:

=== Cut ===
06 Jan 06:38:56.10 BINK 'CONNECT 28800/ARQ/V34/LAPM/V42BIS' : 06
Jan 06:38:58.81 BINK LocMOH: 310b
* 06 Jan 06:39:00.85 BINK System: TANSTAAFL BBS (1:270/615)
06 Jan 06:39:00.85 BINK Aka : 1:270/0 70:5/0 176:500/13
9:6800/615 * 06 Jan 06:39:00.85 BINK Uses
: BinkleyTerm 2.60/(UNREGISTERED)
: 06 Jan 06:39:00.85 BINK Sysop
: Roy J. Tellason from Palmyra, PA
06 Jan 06:39:00.86 BINK Flags
: (null)
06 Jan 06:39:00.86 BINK Phone : (717) 838-8539
: 06 Jan 06:39:00.86 BINK RemTim: Mon, 06 Jan 2003 01:36:29 +0000
: 06 Jan 06:39:00.86 BINK LocTim: Mon, 06 Jan 2003 06:38:58 +0000
: 06 Jan 06:39:00.86 BINK UTCdif: -18149
: 06 Jan 06:39:00.98 BINK Session method: Hydra
: 06 Jan 06:39:00.98 BINK Outbound file requests.
+ 06 Jan 06:39:02.30 BINK CPS: 40 (11 bytes) Efficiency: 1%
+ 06 Jan 06:39:02.30 BINK Sent-H/32
D:\MAIL\OUTBOUND\OUT.001\010E0267.REQ
06 Jan 06:39:02.30 BINK Sending Mail Packet.
+ 06 Jan 06:39:02.91 BINK CPS: 906 (299 bytes) Efficiency: 25%
+ 06 Jan 06:39:02.91 BINK Sent-H/32
D:\MAIL\OUTBOUND\OUT.001\010E0267.CUT
# 06 Jan 06:39:04.30 BINK Receiving Net File plz22.lzh
+ 06 Jan 06:39:09.91 BINK CPS: 2716 (15237 bytes) Efficiency: 75%
+ 06 Jan 06:39:09.91 BINK Received-H/32 D:\Mail\In\Known\plz22.lzh
* 06 Jan 06:39:11.74 BINK End of WaZOO/EMSI Session.
06 Jan 06:39:12.41 BINK '3Com USRobotics Courier V.Everything
EXT'
06 Jan 06:39:12.41 BINK '3Com USRobotics Courier V.Everything
Link Diagnostics...'
06 Jan 06:39:12.41 BINK 'Chars sent 1507
Chars Received 16523'
06 Jan 06:39:12.41 BINK 'Chars lost 0'
06 Jan 06:39:12.42 BINK 'Octets sent 1205
Octets Received 16431'
06 Jan 06:39:12.42 BINK 'Blocks sent 68
Blocks Received 196'
06 Jan 06:39:12.42 BINK 'Blocks resent 0'
06 Jan 06:39:12.42 BINK 'Retrains Requested 0
Retrains Granted 0'
06 Jan 06:39:12.43 BINK 'Line Reversals 0
Blers 0'
06 Jan 06:39:12.43 BINK 'Link Timeouts 0
Link Naks 0'
06 Jan 06:39:12.43 BINK 'Data Compression V42BIS 2048/32'
06 Jan 06:39:12.43 BINK 'Equalisation Long'
06 Jan 06:39:12.44 BINK 'Fallback Enabled'
06 Jan 06:39:12.44 BINK 'Protocol LAPM SREJ 244/15'
06 Jan 06:39:12.44 BINK 'Speed 31200/26400' 06
Jan 06:39:12.44 BINK 'Last Call 00:00:15'
06 Jan 06:39:12.56 BINK 'Disconnect Reason is DTR dropped' 06
Jan 06:39:16.88 BINK Received: 1/15K Sent: 2/0K Total: 3/15K CPS:
555 * 06 Jan 06:39:16.88 BINK Seconds: 28 Tariff: 0 Fee: 0 RFee:
0 System: 1:270/615
=== Cut ===

Looks like you have Hydra working. :-)

Yeah, it sure does. Here's what it looks like from this end:

# 06 Jan 05:36:58 BINK Ring
# 06 Jan 05:37:11 BINK Connect 24000/Arq/V34/Lapm/V42Bis
* 06 Jan 05:37:16 BINK -=Templar's XPoint=-
(2:250/501.11@fidonet.org) : 06 Jan 05:37:16 BINK Aka:

Whoops! Wrong session... Guess _two_ of you guys freq'd that file today...

Here's the right one:

# 06 Jan 01:36:15 BINK Ring
# 06 Jan 01:36:27 BINK Connect 26400/Arq/V34/Lapm/V42Bis
* 06 Jan 01:36:30 BINK The Electric Pigeon #1 (2:250/501@fidonet.org)
: 06 Jan 01:36:30 BINK Aka: 2:250/502@fidonet.org 2:250/503@fidonet.org 81:444/ : 06 Jan 01:36:30 BINK 81:444/2@fidonet.org 81:444/3@fidonet.org 111:7044/ : 06 Jan 01:36:30 BINK 111:7044/107@fidonet.org 111:7044/108@fidonet.org 1 : 06 Jan 01:36:30 BINK 115:4400/12@fidonet.org 115:4400/13@fidonet.org 509 : 06 Jan 01:36:30 BINK 81:444/0@fidonet.org 111:7044/0@fidonet.org 115:440 : 06 Jan 01:36:30 BINK 115:4400/1@fidonet.org 282:2500/0@fidonet.org
* 06 Jan 01:36:30 BINK Remote Uses BT/2 2.60XE/Beta-XH7(mxcom) VAC++/i386
: 06 Jan 01:36:30 BINK SysOp: Neil Walker from Telford, Shropshire, UK
: 06 Jan 01:36:30 BINK Tranx: 3E18DD9D / 3E192482
: 06 Jan 01:36:32 BINK Session method: Hydra
# 06 Jan 01:36:32 BINK Receiving Net File 010e0267.r01
+ 06 Jan 01:36:33 BINK CPS: 0 (11 bytes) Efficiency: 0%
+ 06 Jan 01:36:33 BINK Received-H/32 M:\Max\File\Inbound\010e0267.r01
# 06 Jan 01:36:33 BINK Receiving Mail Packet 06063906.pkt
+ 06 Jan 01:36:33 BINK CPS: 0 (299 bytes) Efficiency: 0%
+ 06 Jan 01:36:33 BINK Received-H/32 M:\Max\File\Inbound\06063906.pkt
* 06 Jan 01:36:34 BINK File Request (PLZ22.LZH)
+ 06 Jan 01:36:41 BINK CPS: 2539 (15237 bytes) Efficiency: 96%
+ 06 Jan 01:36:41 BINK Sent-H/32 H:\MAX\FILE\BBS\PLZ22.LZH
+ 06 Jan 01:36:41 BINK Nothing to send to 282:2500/0@fidonet.org
* 06 Jan 01:36:41 BINK End of WaZOO/EMSI Session
* 06 Jan 01:36:45 BINK Seconds: 21 Tariff: 0 Fee: 0 System: 2:250/501@fidone # 06 Jan 01:36:46 BINK Usrobotics Courier V.Everything Link Diagnostics...
# 06 Jan 01:36:46 BINK Chars Sent 16523 Chars Received
# 06 Jan 01:36:46 BINK Chars Lost 0
# 06 Jan 01:36:46 BINK Octets Sent 16431 Octets Received
# 06 Jan 01:36:46 BINK Blocks Sent 196 Blocks Received
# 06 Jan 01:36:46 BINK Blocks Resent 3
# 06 Jan 01:36:46 BINK Retrains Requested 0 Retrains Granted
# 06 Jan 01:36:46 BINK Line Reversals 0 Blers
# 06 Jan 01:36:46 BINK Link Timeouts 0 Link Naks
# 06 Jan 01:36:46 BINK Data Compression V42Bis 2048/32
# 06 Jan 01:36:46 BINK Equalization Long
# 06 Jan 01:36:46 BINK Fallback Enabled
# 06 Jan 01:36:46 BINK Protocol Lapm Srej 244/15
# 06 Jan 01:36:46 BINK Speed 26400/31200
# 06 Jan 01:36:46 BINK Last Call 00:00:15
: 06 Jan 01:36:46 BINK Exit after receiving mail with errorlevel 20
+ 06 Jan 01:36:46 BINK end, BinkleyTerm Version 2.60A -uSoft7.0

:-)

---
* Origin: TANSTAAFL BBS 717-838-8539 (1:270/615)

Hello Roy!

Tuesday January 07 2003 04:06, you wrote to me:

Whoops! Wrong session... Guess _two_ of you guys freq'd that file today...

Yep, I noticed. ;-)


Be lucky,

Neil

This OS/2 system uptime is 111 days 10:48 hours and 09 seconds
... A $300.00 Picture tube will protect a 10 cent fuse by blowing first.
--- GoldED+/EMX 1.1.5-21110
* Origin: The Electric Pigeon, Telford, UK (2:250/501)

Hi Neil,

You wrote to Roy J. Tellason on 07.01.03 about "binkley xe":

Whoops! Wrong session... Guess _two_ of you guys freq'd that
file today...

Yep, I noticed. ;-)

Now - just who would that be ? ;)

TTFN,

Archie

--- CrossPoint [OpenXP/16] v3.40 RC3 R
* Origin: Templar's Refuge #2 (2:250/501.11)

Hello Archie!

Tuesday January 07 2003 11:12, you wrote to me:

Whoops! Wrong session... Guess _two_ of you guys freq'd that
file today...

Yep, I noticed. ;-)

Now - just who would that be ? ;)

Dunno - just one of those oddball points I got saddled with............ohhhh...errrr.....Hello Archie... ;-)


Be lucky,

Neil

This OS/2 system uptime is 111 days 11:51 hours and 51 seconds
... You have the capacity to learn from mistakes. You'll learn a lot today.
--- GoldED+/EMX 1.1.5-21110
* Origin: The Electric Pigeon, Telford, UK (2:250/501)

Hi Neil,

You wrote on 07.01.03 about "binkley xe":

[snip]

Now - just who would that be ? ;)

Dunno - just one of those oddball points I got saddled with............ohhhh...errrr.....Hello Archie... ;-)

For that "cheek", you can now do a small x-check on the c.p.s
figures you got for the PLZ22.ZIP F'req as compared to mine.
And I wuz using the Pace ............. ?!!?

Agreed, it's not really a large enough transfer to nit-pick about
throughputs - just surprised me to note that you had your pricey
whiz-bang Courier up against Roy's USR - plus your aftercall
report indicated a better Connect state. So, on the surface
reading of those reports your F'req should have shown a higher
c.p.s. rate than mine Neil.

One probable difference on my call to Roy though, I've got my
RxWindow in Hydra set to 8K at the moment. Both Roy's and your's
are possibly using the default full-stream in the RxWindow and
TxWindow settings ................ until an interfering oddball
point sneaks in and remotely adjusts same behind yer back :)

TTFN,

Archie

--- CrossPoint [OpenXP/16] v3.40 RC3 R
* Origin: Templar's Refuge #2 (2:250/501.11)

Hello, Roy;

05 Jan 03 20:03, Roy J. Tellason wrote to Robert Bull:

It's been so long since I've fiddled with any of this stuff I have no recollection at this point in time as to what protocols are included
in the setup, which I might need to have available as "external",
and so forth. What difference would the order make? Are some of
these to be preferred over others? It's been a *long* time since I've seen any discussion of this sort of thing. <g>

I see Archie Swan has now entered the thread, and I bow to his infinite
wisdom in the matter of protocols ;-) Actually, the results got me
puzzled. AIUI, my Binkley started by offering Hydra. As the connect was Janus, I assumed that your end declined my Hydra, so my end tried Janus instead, and that's what the two agreed on. ISTR asking which was "better"
at the time I first looked at BTXE, some years ago, and was told Hydra, but I'm blowed if I can now remember why.

Wow, 396% efficient! I like those numbers... :-)

Hard to do better :-)

Regards,

Robert.

--- GoldED 3.00.Beta2+
* Origin: The Luminous Void (2:250/501.4)

Hello Archie!

Tuesday January 07 2003 23:37, you wrote to me:

Sorry for the delay, Archie, I've been a bit busy.

For that "cheek", you can now do a small x-check on the c.p.s
figures you got for the PLZ22.ZIP F'req as compared to mine.

2716.

And I wuz using the Pace ............. ?!!?

My Pace is sitting on the desk beside me, at the moment. There's another USR (a
56K Faxmodem) on 2:250/502 for the time being. ;-)

Agreed, it's not really a large enough transfer to nit-pick about throughputs - just surprised me to note that you had your pricey
whiz-bang Courier up against Roy's USR

Mine cost me all of 10 UKP. ;-) The I-modem was even less at 3 for 20 UKP. ;-))

- plus your aftercall report indicated a better Connect state. So,

on the surface reading of those reports your F'req should have shown a higher c.p.s. rate than mine Neil.

I've never been a great fan of USRs but they are reliable and dirt cheap on eBay. ;-) I used to get the best transfers with my old Zoom but, unfortunately,
that died. :-(

One probable difference on my call to Roy though, I've got my
RxWindow in Hydra set to 8K at the moment. Both Roy's and your's
are possibly using the default full-stream in the RxWindow and
TxWindow settings ................ until an interfering oddball
point sneaks in and remotely adjusts same behind yer back :)

Hydra doesn't seem to be at it's best in BinkleyTerm (phew, back on topic). ZedZap seems to work better for uni-directional transfers.


Be lucky,

Neil

This OS/2 system uptime is 124 days 21:00 hours and 08 seconds
... When PIG's fly they will be called PIGeons
--- GoldED+/EMX 1.1.5-21110
* Origin: The Electric Pigeon, Telford, UK (2:250/501)

Hi Neil,

You wrote on 20.01.03 about "binkley xe":

[hack to my "playing" bit]

One probable difference on my call to Roy though, I've got my
RxWindow in Hydra set to 8K at the moment. Both Roy's and
your's are possibly using the default full-stream in the
RxWindow and TxWindow settings ................ until an
interfering oddball point sneaks in and remotely adjusts same
behind yer back :)

Hydra doesn't seem to be at it's best in BinkleyTerm (phew, back
on topic). ZedZap seems to work better for uni-directional
transfers.

During the past month or so, I've been keeping tabs on your
Bink's Hydra performance. Definitely "iffy" at times - but it's
not a consistant "iffyness".

Best way to sorta describe it, is probably in terms that Martin
would understand. By that I mean, it's closely similar to the
way T-Mail used to perform until we got the message across to
Andy Elkins and he fixed it.
T-Mail, somewhat similar to Bink's implementation, also had the
Janus core being accessed - and I've a feeling it's something to
do with that.

For those who're interested in the spasmodic "basic fault" -
Hydra timeouts occur at the session end, which causes an error
state and a re-dial action subsequently takes place.

Is there any means whereby you can totally disable Janus with
your BinkXE ?? If so - would you be willing to do so for maybe a
week or so ?
I'll then go back to bashing with Arjen's "standard" (currently
I've disabled that and am using ZedZap, as you *might* have
noticed).

TTFN,

Archie

--- CrossPoint [OpenXP/16] v3.40 RC3 R
* Origin: Templar's Refuge #2 (2:250/501.11)

Hi Neil,

You wrote on 22.01.03 about "binkley xe":

Is there any means whereby you can totally disable Janus with
your BinkXE ??

There's the "NoJanus" keyword.

Looks good :)

If so - would you be willing to do so for maybe a week or so ?

"NoJanus" is now enabled - and can stay that way. ;-)

Sounds good :))

I'll then go back to bashing with Arjen's "standard" (currently
I've disabled that and am using ZedZap, as you *might* have
noticed).

Bash away. ;-)

Bashing now to start ;)

TTFN,

Archie

--- CrossPoint [OpenXP/16] v3.40 RC3 R
* Origin: Templar's Refuge #2 (2:250/501.11)

Hi Neil,

You wrote on 22.01.03 about "binkley xe":

[hack]

I'll then go back to bashing with Arjen's "standard" (currently
I've disabled that and am using ZedZap, as you *might* have
noticed).

Bash away. ;-)

First 3 bashes report ;*)

1. Full-streaming engaged. One timing error in the early part
of the transfer - quickly recovered and continued OK.
That one-off timing error could have been an old-fashioned line
problem.
Throughput of F'req: 5090 cps

2 & 3. Rxwindow at my end changed to 16K size. Smooth as silk
in both cases. :*)
That partially confirms that there may have been a line hiccup.
Throughput of F'req No.2: 5188 cps
F'req No.3: 5031 cps


So I'll leave my config of Hydra in that 16K rxwindow state
until/unless those iffies crop up again.
Although it's really too soon to judge matters, Hydra operation
seemed to be "smoother" with all 3 of those test shots Neil. But
- that could be just wishful thinking :*)

TTFN,

Archie

--- CrossPoint [OpenXP/16] v3.40 RC3 R
* Origin: Templar's Refuge #2 (2:250/501.11)

Hello Archie!

Wednesday January 22 2003 11:28, you wrote to me:

First 3 bashes report ;*)

1. Full-streaming engaged. One timing error in the early part
Throughput of F'req: 5090 cps

2 & 3. Rxwindow at my end changed to 16K size. Smooth as silk
Throughput of F'req No.2: 5188 cps
F'req No.3: 5031 cps

Hmm. Looks pretty good. :-)

So I'll leave my config of Hydra in that 16K rxwindow state
until/unless those iffies crop up again.
Although it's really too soon to judge matters, Hydra operation
seemed to be "smoother" with all 3 of those test shots Neil. But
- that could be just wishful thinking :*)

I wonder how the Janus code interferes once Hydra is selected? It's a shame the
XE team stopped work or we could have got them to have a look at this. :-(


Be lucky,

Neil

This OS/2 system uptime is 126 days 17:44 hours and 15 seconds
... 2.000.000 Lemmings can't be wrong.
--- GoldED+/EMX 1.1.5-21110
* Origin: The Electric Pigeon, Telford, UK (2:250/501)

Hi Neil,

You wrote on 22.01.03 about "binkley xe":

[hack]

Although it's really too soon to judge matters, Hydra operation
seemed to be "smoother" with all 3 of those test shots Neil.
But - that could be just wishful thinking :*)

I wonder how the Janus code interferes once Hydra is selected?

Dunno Neil. ISTR that "some folks" decided that there was some
commonality between the Janus and Hydra protocol code - Arjen had
disagreed IIRC. But both Bink (Vince et al) and T-Mail (Andy
Elkins) went ahead with the commonality idea.

With T-Mail, it also turned out that the sequence order of what
protocols could be used - had to be altered *carefully*. Check
with Martin re that bit of info - he'll probably recall, better
than me, the twiddling which had to be done.
Later, as I muttered before, Andy was persuaded to alter bits.

It's a shame the XE team stopped work or we could have got them
to have a look at this. :-(

Pity no-one's picked up from where they left off. :(
Early days at the moment though - a couple of test shots don't
really prove my theory.

TTFN,

Archie

--- CrossPoint [OpenXP/16] v3.40 RC3 R
* Origin: Templar's Refuge #2 (2:250/501.11)

Hello, Neil;

20 Jan 03 20:59, Neil Walker wrote to Archie Swan:

Hydra doesn't seem to be at it's best in BinkleyTerm (phew, back on topic). ZedZap seems to work better for uni-directional transfers.

There's no way to make Bink dynamically select Hydra for bidi and ZedZap
for unidirectional, is there?

Regards,

Robert.

--- GoldED 3.00.Beta2+
* Origin: The Luminous Void (2:250/501.4)