• binkley xe

    From Ross Smarekar@1:362/708 to all on Thu Dec 5 08:23:30 2002
    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)
  • From Ross Smarekar@1:362/708 to all on Thu Dec 5 08:32:36 2002
    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)
  • From Jerry Schwartz@1:142/928 to Ross Smarekar on Sat Dec 7 10:31:53 2002
    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)
  • From Ross Smarekar@1:362/708 to Jerry Schwartz on Tue Dec 10 05:08:54 2002
    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)
  • From Ross Smarekar@1:362/708 to Jerry Schwartz on Tue Dec 10 19:38:56 2002
    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)
  • From Jerry Schwartz@1:142/928 to Ross Smarekar on Fri Dec 13 14:45:24 2002
    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)
  • From Peter Knapper@3:772/1.10 to Ross Smarekar on Sat Dec 14 08:52:18 2002
    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)
  • From Roy J. Tellason@1:270/615 to Ross Smarekar on Sat Dec 14 04:05:58 2002
    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)
  • From Roy J. Tellason@1:270/615 to Peter Knapper on Sat Dec 14 04:05:58 2002
    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)
  • From Paul Lentz@1:124/5025 to Roy J. Tellason on Sat Dec 14 04:41:23 2002
    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)
  • From Michele Marie Dalene@1:142/7176 to Ross Smarekar on Fri Dec 13 21:11:00 2002
    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)
  • From Gord Hannah@1:17/23.1 to Peter Knapper on Sat Dec 14 07:21:03 2002
    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)
  • From Peter Knapper@3:772/1.10 to Roy J. Tellason on Sun Dec 15 08:19:30 2002
    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)
  • From Roy J. Tellason@1:270/615 to Paul Lentz on Sat Dec 14 20:06:15 2002
    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)
  • From Paul Lentz@1:124/5025 to Roy J. Tellason on Sat Dec 14 21:08:05 2002
    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)
  • From Roy J. Tellason@1:270/615 to Peter Knapper on Sun Dec 15 04:06:27 2002
    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)
  • From Roy J. Tellason@1:270/615 to Paul Lentz on Sun Dec 15 12:05:52 2002
    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)
  • From Robert Bull@2:250/501.4 to Roy J. Tellason on Sun Dec 22 20:19:08 2002
    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)
  • From Roy J. Tellason@1:270/615 to Robert Bull on Mon Dec 23 04:06:12 2002
    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)
  • From Paul Williams@1:387/710 to Roy J. Tellason on Mon Dec 23 21:47:01 2002
    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)
  • From Roy J. Tellason@1:270/615 to Paul Williams on Wed Dec 25 20:06:17 2002
    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)
  • From Paul Williams@1:387/710 to Roy J. Tellason on Sat Dec 28 21:32:30 2002
    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)
  • From Roy J. Tellason@1:270/615 to Paul Williams on Sun Dec 29 12:06:02 2002
    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)
  • From Robert Bull@2:250/501.4 to Roy J. Tellason on Sun Dec 29 19:46:56 2002
    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)
  • From Robert Bull@2:250/501.4 to Neil Walker on Sun Dec 29 19:53:32 2002
    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)
  • From Neil Walker@2:250/501 to Robert Bull on Sun Dec 29 21:37:16 2002
    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)
  • From Andrew Leary@1:320/119 to Roy J. Tellason on Sun Dec 29 04:24:00 2002
    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)
  • From Roy J. Tellason@1:270/615 to Robert Bull on Mon Dec 30 20:10:56 2002
    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)
  • From Robert Bull@2:250/501.4 to Roy J. Tellason on Wed Jan 1 20:22:54 2003
    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)
  • From Roy J. Tellason@1:270/615 to Robert Bull on Thu Jan 2 04:06:37 2003
    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)
  • From Robert Bull@2:250/501.4 to Roy J. Tellason on Sun Jan 5 15:38:08 2003
    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)
  • From Roy J. Tellason@1:270/615 to Robert Bull on Sun Jan 5 20:03:20 2003
    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)
  • From Neil Walker@2:250/501 to Roy J. Tellason on Mon Jan 6 06:55:02 2003
    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)
  • From Roy J. Tellason@1:270/615 to Neil Walker on Mon Jan 6 20:01:26 2003
    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)
  • From Roy J. Tellason@1:270/615 to Neil Walker on Tue Jan 7 04:06:32 2003
    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)
  • From Neil Walker@2:250/501 to Roy J. Tellason on Tue Jan 7 10:46:58 2003
    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)
  • From Archie Swan@2:250/501.11 to Neil Walker on Tue Jan 7 11:12:00 2003
    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)
  • From Neil Walker@2:250/501 to Archie Swan on Tue Jan 7 11:50:42 2003
    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)
  • From Archie Swan@2:250/501.11 to Neil Walker on Tue Jan 7 23:37:00 2003
    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)
  • From Robert Bull@2:250/501.4 to Roy J. Tellason on Sun Jan 12 19:45:07 2003
    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)
  • From Neil Walker@2:250/501 to Archie Swan on Mon Jan 20 20:59:34 2003
    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)
  • From Archie Swan@2:250/501.11 to Neil Walker on Tue Jan 21 14:49:00 2003
    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)
  • From Archie Swan@2:250/501.11 to Neil Walker on Wed Jan 22 09:51:00 2003
    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)
  • From Archie Swan@2:250/501.11 to Neil Walker on Wed Jan 22 11:28:00 2003
    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)
  • From Neil Walker@2:250/501 to Archie Swan on Wed Jan 22 17:43:42 2003
    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)
  • From Archie Swan@2:250/501.11 to Neil Walker on Wed Jan 22 20:01:00 2003
    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)
  • From Robert Bull@2:250/501.4 to Neil Walker on Sun Jan 26 20:30:32 2003
    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)