• Verson260A

    From Kevin Klement@1:134/77 to All on Friday, April 29, 2005 13:36:18
    Hi All,

    Binkley 260A has lost it's mind over here. I have downlinks that are
    on "hold" because they poll or I dilivier via the internet.

    But right after midnight maintenance Bink keep on trying to dial them, I made a "DialTMP.Scr" which does nothing, to stop my modem dialing out.

    Can anyone suggest something.

    * 29 Apr 00:10:19 BINK Processing node 1:134/303 -- Ice Zone
    : 29 Apr 00:10:19 BINK Dialing with script 'DialTMP.Scr'
    + 29 Apr 00:10:19 BINK Script 'DialTMP.Scr' failed at line 1
    + 29 Apr 00:10:22 BINK End of connection attempt
    * 29 Apr 00:14:01 BINK Processing node 1:134/503 -- The Adventurers Guild
    : 29 Apr 00:14:01 BINK Dialing with script 'DialTMP.Scr'
    + 29 Apr 00:14:01 BINK Script 'DialTMP.Scr' failed at line 1
    + 29 Apr 00:14:04 BINK End of connection attempt
    * 29 Apr 00:16:23 BINK Processing node 1:134/303 -- Ice Zone
    : 29 Apr 00:16:23 BINK Dialing with script 'DialTMP.Scr'
    + 29 Apr 00:16:23 BINK Script 'DialTMP.Scr' failed at line 1
    + 29 Apr 00:16:26 BINK End of connection attempt
    * 29 Apr 00:18:19 BINK Processing node 1:134/503 -- The Adventurers Guild
    : 29 Apr 00:18:19 BINK Dialing with script 'DialTMP.Scr'
    + 29 Apr 00:18:19 BINK Script 'DialTMP.Scr' failed at line 1
    + 29 Apr 00:18:22 BINK End of connection attempt
    * 29 Apr 00:22:28 BINK Processing node 1:134/303 -- Ice Zone
    : 29 Apr 00:22:28 BINK Dialing with script 'DialTMP.Scr'
    + 29 Apr 00:22:28 BINK Script 'DialTMP.Scr' failed at line 1
    + 29 Apr 00:22:31 BINK End of connection attempt
    * 29 Apr 00:25:55 BINK Processing node 1:134/503 -- The Adventurers Guild
    : 29 Apr 00:25:55 BINK Dialing with script 'DialTMP.Scr'
    + 29 Apr 00:25:55 BINK Script 'DialTMP.Scr' failed at line 1
    + 29 Apr 00:25:58 BINK End of connection attempt
    * 29 Apr 00:29:27 BINK Processing node 1:134/303 -- Ice Zone
    : 29 Apr 00:29:27 BINK Dialing with script 'DialTMP.Scr'
    + 29 Apr 00:29:27 BINK Script 'DialTMP.Scr' failed at line 1
    + 29 Apr 00:29:30 BINK End of connection attempt
    * 29 Apr 00:32:24 BINK Processing node 1:134/503 -- The Adventurers Guild
    : 29 Apr 00:32:24 BINK Dialing with script 'DialTMP.Scr'
    + 29 Apr 00:32:24 BINK Script 'DialTMP.Scr' failed at line 1
    + 29 Apr 00:32:27 BINK End of connection attempt

    Kevin
    klement@shaw.ca
    --- Squish/386 v1.11
    * Origin: This unit must survive! (1:134/77)
  • From Sean Dennis@1:18/200 to Kevin Klement on Friday, April 29, 2005 19:40:36
    *** Quoting Kevin Klement from a message to All ***

    But right after midnight maintenance Bink keep on trying to dial
    them, I made a "DialTMP.Scr" which does nothing, to stop my modem
    dialing out.

    Have you tried setting up a non-dialable event in BINKLEY.EVT?

    Later,
    Sean

    // sysop@outpostbbs.net | http://outpostbbs.net | ICQ: 19965647

    --- Telegard/2 v3.09.g2-sp4/mL
    * Origin: Outpost BBS - Kennesaw, GA - outpostbbs.net (1:18/200)
  • From Peter Knapper@3:772/1.10 to Kevin Klement on Saturday, April 30, 2005 10:45:36
    Hi Kevin,

    Binkley 260A has lost it's mind over here. I have downlinks that are
    on "hold" because they poll or I dilivier via the internet.

    Boy, its been a LONG time (8+ years???) since I used Dial Scripts to access the
    Internet from Bink, so some of my memory may be stuck back in time and have faded some what......;-) I can't find any of my old config for this around so if I remember correctly you need a Binkley Event file entry to run an event that causes Binkley to need to poll a Node via a Dialer Script that does the dialing work.

    The first thing I thought of is that as your events start after midnight, that suggests to me that Bink is re-reading your Events file at this time, and thats
    when things start going wrong, so something has likely changed in your events files thats causing this. The fact its a dialer script is probably a red herring, the critical part is "Why is the event being triggered in the first place?", and the driver for that is within your Events file.

    Roll back any recent changes you made to that file, also look for any events that might overlap in execution BEGIN/END time, particularly for things running
    past 24:00 hrs. If nothing is obvious, the next step is to clear out Binks compiled schedule and force a complete Binkley restart to see what happens.

    So to roll things back to the very start (this process will re-run ALL events for today so be very careful), end Binkley, delete the Binkley.SCD file (this forces Binkley to "re-compile" that file and run EVERYTHING up until the "current" event time), then start Binkey again. What you want to see are which EVENTS are being run, and when they kick in. The Binkley LOG file for this will
    give you the clues...

    I suspect this may not show much at all, because it seems your problem may relate to the LAST EVENT OF THE DAY being run, so your problem wont be visible until Binkley does a natural roll over of the day. Also consider event entries which have recently been added or changed, or which have only just become ACTIVE (IE an event set to run after a certain date/time/day of week, etc...).

    Lastly, a postig a copy of your .EVT file here may be useful.

    Good luck..............pk.


    --- Maximus/2 3.01
    * Origin: Another Good Point About OS/2 (3:772/1.10)
  • From Mike Tripp@1:382/61 to Kevin Klement on Friday, April 29, 2005 20:48:48
    Hello Kevin!

    29 Apr 05 12:36, Kevin Klement wrote to All:

    But right after midnight maintenance Bink keep on trying to dial them,
    I made a "DialTMP.Scr" which does nothing, to stop my modem dialing
    out.

    You shouldn't have to trick Bink not to dial "hold" nodes. My guess is that something in that maintenance routine is changing the flavor of the mail to crash...which sends Bink into wardial mode when it comes back up. Check your outbound to see if you have .HLO or .CLO files.

    .\\ike

    --- GoldED 2.50+
    * Origin: -=( The TechnoDrome )=- Austin,TX 512-327-8598 33.6k (1:382/61)
  • From Kevin Klement@1:134/77 to Sean Dennis on Saturday, May 07, 2005 14:39:17
    Hi Sean,

    Friday April 29 2005, Sean Dennis writes to Kevin Klement:

    Have you tried setting up a non-dialable event in
    BINKLEY.EVT?

    Well, *ALL* the mail that is marked HOLD, I want it heald. Here have a look at my event file.

    ;
    ;
    ; For MDT $ B D N L M F R X C Q A T E1 E2 ;------------------------------------------------------------------------------ Event All 00:00 00:00 F E1=100 ; Event All 01:00 01:00 F Q=0 E1=97 ; Event All 00:00 03:00 $ B Q=0 T=2,25 E2=40 ; Event All 03:00 03:30 D N M X C A=60 T=2,25 E2=40 ; Event All 03:00 04:00 N L M X A=60 T=2,25 E2=40 ; Event All 04:00 06:00 $ B L Q=0 E2=40 ; Event Sat 10:00 10:00 F Q=0 E1=98 ; Event All 06:00 24:00 B L Q=0 E2=40 ; ;

    Kevin
    klement@shaw.ca
    --- Squish/386 v1.11
    * Origin: This unit must survive! (1:134/77)
  • From Kevin Klement@1:134/77 to Peter Knapper on Saturday, May 07, 2005 14:44:14
    Hi Peter,

    Saturday April 30 2005, Peter Knapper writes to Kevin Klement:

    The first thing I thought of is that as your events start
    after midnight, that suggests to me that Bink is re-reading
    your Events file at this time, and thats when things start
    going wrong,

    Yep, because none of my midnight maintenance batch files touch my outbound.

    Roll back any recent changes you made to that file, also
    look for any events that might overlap in execution
    BEGIN/END time, particularly for things running past 24:00

    Every thing is in order, I think. :)

    I suspect this may not show much at all, because it seems
    your problem may relate to the LAST EVENT OF THE DAY being
    run,

    Yep.

    Lastly, a postig a copy of your .EVT file here may be
    useful.

    Here she is.

    ;
    ; For MDT $ B D N L M F R X C Q A T E1 E2 ;------------------------------------------------------------------------------ Event All 00:00 00:00 F E1=100 ; Event All 01:00 01:00 F Q=0 E1=97 ; Event All 00:00 03:00 $ B Q=0 T=2,25 E2=40 ; Event All 03:00 03:30 D N M X C A=60 T=2,25 E2=40 ; Event All 03:00 04:00 N L M X A=60 T=2,25 E2=40 ; Event All 04:00 06:00 $ B L Q=0 E2=40 ; Event Sat 10:00 10:00 F Q=0 E1=98 ; Event All 06:00 24:00 B L Q=0 E2=40 ; ;

    Kevin
    klement@shaw.ca
    --- Squish/386 v1.11
    * Origin: This unit must survive! (1:134/77)
  • From Kevin Klement@1:134/77 to Mike Tripp on Saturday, May 07, 2005 14:51:10
    Hi Mike,

    Friday April 29 2005, Mike Tripp writes to Kevin Klement:

    You shouldn't have to trick Bink not to dial "hold" nodes.

    Agreed.

    My guess is that something in that maintenance routine is
    changing the flavor of the mail to crash...which sends Bink
    into wardial mode when it comes back up. Check your outbound
    to see if you have .HLO or .CLO files.

    I'll look again but "none" of my midnight maintenance batch
    files touch my outbound.

    My event file looks like so..

    ;
    ; For MDT $ B D N L M F R X C Q A T E1 E2 ;------------------------------------------------------------------------------ Event All 00:00 00:00 F E1=100 ; Event All 01:00 01:00 F Q=0 E1=97 ; Event All 00:00 03:00 $ B Q=0 T=2,25 E2=40 ; Event All 03:00 03:30 D N M X C A=60 T=2,25 E2=40 ; Event All 03:00 04:00 N L M X A=60 T=2,25 E2=40 ; Event All 04:00 06:00 $ B L Q=0 E2=40 ; Event Sat 10:00 10:00 F Q=0 E1=98 ; Event All 06:00 24:00 B L Q=0 E2=40 ; ;
    Kevin
    klement@shaw.ca
    --- Squish/386 v1.11
    * Origin: This unit must survive! (1:134/77)
  • From Peter Knapper@3:772/1.10 to Kevin Klement on Sunday, May 08, 2005 09:47:46
    Hi Kevin,

    Lastly, a postig a copy of your .EVT file here may be useful.

    Here she is.

    <<< Re-edited to prevent word wrap >>>

    ;
    ; For MDT $ B D N L M F R X C Q A T E1 E2 ;---------------------------------------------------------------------------- Event All 00:00 00:00 F E1=100 Event All 01:00 01:00 F Q=0 E1=97 Event All 00:00 03:00 $ B Q=0 T=2,25 E2=40 Event All 03:00 03:30 D N M X C A=60 T=2,25 E2=40 Event All 03:00 04:00 N L M X A=60 T=2,25 E2=40 Event All 04:00 06:00 $ B L Q=0 E2=40 Event Sat 10:00 10:00 F Q=0 E1=98 Event All 06:00 24:00 B L Q=0 E2=40
    ;
    ;

    The START Times for several events overlaps with other events for the SAME day (IE All) . If I need to run something during a longer event, I always ended the
    first instance, ran the single event, then ran the last part of the original event, I NEVER overlap the event times. I think this is ok when using different
    days in there, but not for same days...

    EG: Event 3 overlaps events 1 and 2, and Event 5 overlaps event 4.

    The next thing is that for the last Event, an END time of 24:00 is also the same time as 00:00. I think the docs read that this should be ok, but I had issues with it many years ago, so I always had a final event END time of 23:59 regardless. I have never missed a day rollover since I started doing that back in 1994...

    See if that helps.

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


    --- Maximus/2 3.01
    * Origin: Another Good Point About OS/2 (3:772/1.10)
  • From Kevin Klement@1:134/77 to Peter Knapper on Saturday, May 07, 2005 18:37:45
    Hi Peter,

    The START Times for several events overlaps with other
    events for the SAME day (IE All) . If I need to run

    Yes, it should work .. Yes?

    But that shouldn't make Binkley dial out to 'HOLD' nodes?

    Kevin
    klement@shaw.ca

    --- Squish/386 v1.11
    * Origin: This unit must survive! (1:134/77)
  • From Peter Knapper@3:772/1.10 to Kevin Klement on Sunday, May 08, 2005 17:20:20
    Hi Kevin,

    The START Times for several events overlaps with other
    events for the SAME day (IE All) . If I need to run

    Yes, it should work .. Yes?

    I can't say for sure because I have never used them like that, but I would not be surprised if it did cause problems. Binkley displays the currently executing
    Event number, what does it do around the time of the intermediate event?

    As far as I can read in the Binkley docs, the events are processed squentially as time goes by. So Binkley NEVER goes back and process event 3 again, if event
    4 has been started for the same day. If event 4 has already been processed, unless it is a FORCED event or the .SCD and .DAY files have been removed. You will end up "between events" with no specific event being processed. But that should not cause dialing to take place (that I can see).

    But that shouldn't make Binkley dial out to 'HOLD' nodes?

    I would not expect so, because no event was active to cause that. HOWEVER, I also note that you have several forced events. Do you really need these, because these can cause issues when an event with 0 time is "missed". I had odd
    problems with the Event file when including FORCED events, so I removed them all, changed them to a 1 min duration, and have never had a problem since then.

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


    --- Maximus/2 3.01
    * Origin: Another Good Point About OS/2 (3:772/1.10)
  • From Mike Tripp@1:382/61 to Kevin Klement on Monday, May 09, 2005 08:41:12
    Hello Kevin!

    07 May 05 13:51, Kevin Klement wrote to Mike Tripp:

    into wardial mode when it comes back up. Check your outbound
    to see if you have .HLO or .CLO files.

    I'll look again but "none" of my midnight maintenance batch
    files touch my outbound.

    Yep...physically check the filenames, rather than troubleshooting the batch logic. If you've got the unexpected .CLO files, then determine why...and eliminate Bink from the suspect list, because it will only reflavor manually with user interaction in the outbound manager screen.

    My event file looks like so..

    Event All 00:00 00:00
    Event All 01:00 01:00
    Event All 00:00 03:00
    Event All 03:00 03:30
    Event All 03:00 04:00
    Event All 04:00 06:00
    Event Sat 10:00 10:00
    Event All 06:00 24:00

    There is likely trouble here, too, with events being both out of sequence and overlapping events, though it is probably not causing the flavor prob. Try moving the 0100 event after the 0000 event below it. Try moving the 0600 event
    before the 1000 event above it.

    If that doesn't work, try making more smaller events to eliminate overlap:

    0000 - 0100
    0100 - 0100
    0100 - 0300
    0300 - 0330
    0330 - 0400
    0400 - 0600
    0600 - 2359

    .\\ike

    --- GoldED 2.50+
    * Origin: -=( The TechnoDrome )=- Austin,TX 512-327-8598 33.6k (1:382/61)
  • From Kevin Klement@1:134/77 to Peter Knapper on Monday, May 09, 2005 17:02:41
    Hi Peter,

    Sunday May 08 2005, Peter Knapper writes to Kevin Klement:

    I can't say for sure because I have never used them like
    that, but I would not be surprised if it did cause problems.

    By chance, do you use Squish?
    Kevin
    klement@shaw.ca
    --- Squish/386 v1.11
    * Origin: This unit must survive! (1:134/77)
  • From Kevin Klement@1:134/77 to Mike Tripp on Monday, May 09, 2005 17:04:05
    Hi Mike,

    Monday May 09 2005, Mike Tripp writes to Kevin Klement:

    There is likely trouble here, too, with events being both
    out of sequence and overlapping events, though it is
    probably not causing the flavor prob.

    By chance do you use Squish? That might be whats causing my
    flavor prob.
    Kevin
    klement@shaw.ca
    --- Squish/386 v1.11
    * Origin: This unit must survive! (1:134/77)
  • From Sean Dennis@1:18/200 to Kevin Klement on Monday, May 09, 2005 20:03:39
    Hello, Kevin.

    On 09 May 05 at 16:02, Kevin Klement wrote to Peter Knapper:

    By chance, do you use Squish?

    Both Peter and Mike do. If ya run Maximus, like they both do, ya run Squish more than likely. ;) It's like Mom and apple pie-they both go together.

    I use Squish too.

    Later,
    Sean

    // hausmaus@darktech.org | http://midnightshour.net | ICQ: 19965647

    --- GoldED+/EMX 1.1.5-21020
    * Origin: Outpost BBS - Kennesaw, GA - outpostbbs.net (1:18/200)
  • From Kevin Klement@1:134/77 to Mike Tripp on Monday, May 09, 2005 17:51:04
    Hi Mike,

    Monday May 09 2005, Mike Tripp writes to Kevin Klement:
    If that doesn't work, try making more smaller events to
    eliminate overlap:

    0000 - 0100
    0100 - 0100
    0100 - 0300
    0300 - 0330
    0330 - 0400
    0400 - 0600
    0600 - 2359

    Okay, I new everything was overlapping on my setup, I set it for some reason, can't remember why.
    Kevin
    klement@shaw.ca

    --- Squish/386 v1.11
    * Origin: This unit must survive! (1:134/77)
  • From Kevin Klement@1:134/77 to Peter Knapper on Monday, May 09, 2005 17:56:26
    Hi Peter,

    But that should not cause
    dialing to take place (that I can see).

    Agreed.

    It's SQ386.exe (squish) that's changing the flavor, I
    think I found the problem.
    Kevin
    klement@shaw.ca
    --- Squish/386 v1.11
    * Origin: This unit must survive! (1:134/77)
  • From Kevin Klement@1:134/77 to Sean Dennis on Monday, May 09, 2005 18:02:50
    Hi Sean,

    Friday April 29 2005, Sean Dennis writes to Kevin Klement:

    Have you tried setting up a non-dialable event in
    BINKLEY.EVT?

    Say, if your "events" are overlapping, Do you think it shouldn't make any difference?
    Kevin
    klement@shaw.ca

    --- Squish/386 v1.11
    * Origin: This unit must survive! (1:134/77)
  • From Kevin Klement@1:134/77 to Sean Dennis on Monday, May 09, 2005 18:13:04
    Hi Sean,


    It's like Mom and
    apple pie-they both go together.

    Oh oh ... can't AGREE with you MORE Sean, I'm also a Bink/Max/SQ user for
    over 7 years. :)

    Say,

    When does Suqish read the route.cfg file?
    Kevin
    klement@shaw.ca

    --- Squish/386 v1.11
    * Origin: This unit must survive! (1:134/77)
  • From Sean Dennis@1:18/200 to Kevin Klement on Monday, May 09, 2005 20:34:32
    Kevin,

    Say, if your "events" are overlapping, Do you think it shouldn't make any difference?

    From what I remember, if events overlap, there can be problems. I've never had
    overlapping events, so I couldn't tell you what would happen. I haven't had a dialup line in quite some time (but once I move, I will).

    I've always just used four main blocks of events for my main line.

    Later,
    Sean

    --- ProBoard v2.17 [Reg]
    * Origin: Outpost BBS - Kennesaw, GA - outpostbbs.net (1:18/200)
  • From Sean Dennis@1:18/200 to Kevin Klement on Monday, May 09, 2005 20:36:02
    Kevin,

    When does Suqish read the route.cfg file?

    I do believe it reads it after everything's been archived. However, it might read ROUTE.CFG first so it'll know how to archive everything.

    That's a good question-there's people around here who've worked on the Squish code-they might know.

    Later,
    Sean

    --- ProBoard v2.17 [Reg]
    * Origin: Outpost BBS - Kennesaw, GA - outpostbbs.net (1:18/200)
  • From Mike Tripp@1:382/61 to Kevin Klement on Tuesday, May 10, 2005 00:26:31
    Hello Kevin!

    09 May 05 16:51, Kevin Klement wrote to Mike Tripp:


    Okay, I new everything was overlapping on my setup, I set it for some reason, can't remember why.

    In theory, overlapping should be OK, even though I don't need to do it myself, but I think the trick is to get those start times in ascending order while you do it. That's why I suggesting moving your 0100-0100 forced event down below your 0000-0300 "normal" event.

    .\\ike

    --- GoldED 2.50+
    * Origin: -=( The TechnoDrome )=- Austin,TX 512-327-8598 33.6k (1:382/61)
  • From Mike Tripp@1:382/61 to Kevin Klement on Tuesday, May 10, 2005 00:31:44
    Hello Kevin!

    09 May 05 17:13, Kevin Klement wrote to Sean Dennis:

    When does Suqish read the route.cfg file?

    I believe it builds everything in \OUT.SQ based on the SQUISH.CFG, and then references ROUTE.CFG as it moves things from \OUT.SQ to \OUT. It would take some tinkering to prove my rusty memory, though.

    .\\ike

    --- GoldED 2.50+
    * Origin: -=( The TechnoDrome )=- Austin,TX 512-327-8598 33.6k (1:382/61)
  • From Peter Knapper@3:772/1.10 to Kevin Klement on Tuesday, May 10, 2005 20:13:18
    Hi Kevin,

    Sunday May 08 2005, Peter Knapper writes to Kevin Klement:

    I can't say for sure because I have never used them like
    that, but I would not be surprised if it did cause problems.

    By chance, do you use Squish?

    Yes, BinkD/2, Binkley/2, Maximus/2, Squish/2.

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


    --- Maximus/2 3.01
    * Origin: Another Good Point About OS/2 (3:772/1.10)
  • From Sean Dennis@1:18/200 to Peter Knapper on Tuesday, May 10, 2005 10:50:10
    Hello, Peter.

    On 10 May 05 at 19:13, Peter Knapper wrote to Kevin Klement:
    Yes, BinkD/2, Binkley/2, Maximus/2, Squish/2.

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

    pk/2 ;)

    Later,
    Sean

    // hausmaus@darktech.org | http://midnightshour.net | ICQ: 19965647

    --- GoldED+/EMX 1.1.5-21020
    * Origin: Outpost BBS - Kennesaw, GA - outpostbbs.net (1:18/200)
  • From Kevin Klement@1:134/77 to Sean Dennis on Tuesday, May 10, 2005 14:20:07
    Hi Sean,

    Monday May 09 2005, Sean Dennis writes to Kevin Klement:

    I do believe it reads it after everything's been archived.
    However, it might read ROUTE.CFG first so it'll know how to
    archive everything.

    Okay, I think I found what's changing the flavor of my outbound nodes right after midnight maintenance.

    So these are the "ONLY" two commands at the beginning of midnight maintenance. My netmail is packed and bbs reports are produced.

    SCANBLD MATRIX
    z:
    CD \
    CD \sq386
    echo REPORTS.134 > z:\sq386\echotoss.log
    sq386 out -cz:\sq386\squish.cfg -fz:\sq386\echotoss.log

    Now don't pick on me about my route.cfg, because it was set this reason at one time, can't remember why. I think my route.cfg is changing outbound nodes flavor.

    route.cfg:
    ;
    ; Modified: 05/09/05 05:19 pm
    ;
    ; Nodes we DO NOT wish to have routed via LPM
    SEND normal 1:17/0
    SEND normal 30:100/all
    SEND normal 30:1000/all
    SEND normal 1:134/all
    SEND normal 1:342/1
    SEND normal 1:134/1 65535/65535 -1/-1
    ;
    ;
    ; All fall-through mail is now routed through our LPM feed node, 1:140/1
    ROUTE normal 1:140/1 1:all 2:all 3:all 4:all 5:all 6:all
    SEND normal world
    ;
    ;
    SEND hold 1:17/80
    SEND hold 1:134/10
    SEND hold 1:134/33
    SEND hold 1:134/703
    SEND hold 1:134/503
    SEND hold 1:134/303
    SEND hold 1:140/1
    SEND hold 30:250/140
    SEND hold 30:1000/0
    ;
    ;
    SCHED Hold134
    ;
    CHANGE normal hold 1:134:all
    CHANGE crash hold 1:134:all
    ;
    SCHED UnHold134
    ;
    CHANGE hold normal 1:134:all
    ;
    Kevin
    klement@shaw.ca

    --- Squish/386 v1.11
    * Origin: This unit must survive! (1:134/77)
  • From Kevin Klement@1:134/77 to Mike Tripp on Tuesday, May 10, 2005 14:22:23
    Hi Mike,

    Monday May 09 2005, Mike Tripp writes to Kevin Klement:

    I believe it builds everything in \OUT.SQ based on the
    SQUISH.CFG, and then references ROUTE.CFG as it moves things
    from \OUT.SQ to \OUT. It would take some tinkering to prove
    my rusty memory, though.

    Okay, I think I found what's changing the flavor of my outbound nodes right after midnight maintenance.

    So these are the "ONLY" two commands at the beginning of midnight maintenance. My netmail is packed and bbs reports are produced.

    SCANBLD MATRIX
    z:
    CD \
    CD \sq386
    echo REPORTS.134 > z:\sq386\echotoss.log
    sq386 out -cz:\sq386\squish.cfg -fz:\sq386\echotoss.log

    Now don't pick on me about my route.cfg, because it was set this reason at one time, can't remember why. I think my route.cfg is changing outbound nodes flavor.

    route.cfg:
    ;
    ; Modified: 05/09/05 05:19 pm
    ;
    ; Nodes we DO NOT wish to have routed via LPM
    SEND normal 1:17/0
    SEND normal 30:100/all
    SEND normal 30:1000/all
    SEND normal 1:134/all
    SEND normal 1:342/1
    SEND normal 1:134/1 65535/65535 -1/-1
    ;
    ;
    ; All fall-through mail is now routed through our LPM feed node, 1:140/1
    ROUTE normal 1:140/1 1:all 2:all 3:all 4:all 5:all 6:all
    SEND normal world
    ;
    ;
    SEND hold 1:17/80
    SEND hold 1:134/10
    SEND hold 1:134/33
    SEND hold 1:134/703
    SEND hold 1:134/503
    SEND hold 1:134/303
    SEND hold 1:140/1
    SEND hold 30:250/140
    SEND hold 30:1000/0
    ;
    ;
    SCHED Hold134
    ;
    CHANGE normal hold 1:134:all
    CHANGE crash hold 1:134:all
    ;
    SCHED UnHold134
    ;
    CHANGE hold normal 1:134:all
    ;
    Kevin
    klement@shaw.ca
    --- Squish/386 v1.11
    * Origin: This unit must survive! (1:134/77)
  • From Kevin Klement@1:134/77 to Peter Knapper on Tuesday, May 10, 2005 17:38:04
    Hi Peter,

    Yes, BinkD/2, Binkley/2, Maximus/2, Squish/2.

    Nice, I remember when OS/2 hit fidonet... :)
    Kevin
    klement@shaw.ca
    --- Squish/386 v1.11
    * Origin: This unit must survive! (1:134/77)
  • From Kevin Klement@1:134/77 to Kevin Klement on Tuesday, May 10, 2005 17:39:34
    Hi Kevin,

    Yes, BinkD/2, Binkley/2, Maximus/2, Squish/2.

    Nice, I remember when OS/2 hit fidonet... :)

    My network runs on genuineIntel 3.2 Ghz. Three Boxes hooked into a Linksys.
    Two boxes OS is XPH, the third box OS is MS-DOS 6.22.

    Kevin
    klement@shaw.ca
    --- Squish/386 v1.11
    * Origin: This unit must survive! (1:134/77)
  • From Peter Knapper@3:772/1.10 to Sean Dennis on Wednesday, May 11, 2005 20:05:18
    Hi Sean,

    On 10 May 05 at 19:13, Peter Knapper wrote to Kevin Klement:
    Yes, BinkD/2, Binkley/2, Maximus/2, Squish/2.

    pk/2 ;)

    Oh yes, Nef/pk too..........;-)

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


    --- Maximus/2 3.01
    * Origin: Another Good Point About OS/2 (3:772/1.10)
  • From Peter Knapper@3:772/1.10 to Kevin Klement on Wednesday, May 11, 2005 20:07:40
    Hi Kevin,

    This reminded me of something I have also done for years -

    SEND normal 1:17/0
    SEND normal 30:100/all
    SEND normal 30:1000/all
    SEND normal 1:134/all
    SEND normal 1:342/1
    SEND normal 1:134/1 65535/65535 -1/-1

    ALL my SEND's and ROUTE's use a flavour of HOLD in ALL cases. Once all of those
    are complete, if I then want something to go, I then CHANGE its flavour. This can help prevent some nasty things happening if you are runing in a multi-system, multi-tasking environment.

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


    --- Maximus/2 3.01
    * Origin: Another Good Point About OS/2 (3:772/1.10)
  • From Peter Knapper@3:772/1.10 to Kevin Klement on Wednesday, May 11, 2005 20:13:32
    Hi Kevin,

    Yes, BinkD/2, Binkley/2, Maximus/2, Squish/2.

    Nice, I remember when OS/2 hit fidonet... :)

    My network runs on genuineIntel 3.2 Ghz. Three Boxes
    hooked into a Linksys.
    Two boxes OS is XPH, the third box OS is MS-DOS 6.22.

    The BBS here runs on a Celeron 700 with 64MB RAM, Warp4 + FP15, TCP/IP 4.21. It
    runs the above plus NAMED/2, CRON/2, Apache/2, OREXX (for automated FTP and a few other things) and the LAN is ADSL connected... The C700 was the smallest CPU I could buy when I needed a new Motherboard about 3-4 years ago, it still twiddles its thumbs 95% of the time.........;-)

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


    --- Maximus/2 3.01
    * Origin: Another Good Point About OS/2 (3:772/1.10)
  • From Sean Dennis@1:18/200 to Peter Knapper on Wednesday, May 11, 2005 09:26:36
    Hello, Peter.

    On 11 May 05 at 19:05, Peter Knapper wrote to Sean Dennis:

    Oh yes, Nef/pk too..........;-)

    Heheheh. Couldn't forget that.

    Later,
    Sean

    // hausmaus@darktech.org | http://midnightshour.net | ICQ: 19965647

    --- GoldED+/EMX 1.1.5-21020
    * Origin: Outpost BBS - Kennesaw, GA - outpostbbs.net (1:18/200)
  • From Mike Tripp@1:382/61 to Kevin Klement on Wednesday, May 11, 2005 08:47:11
    Hello Kevin!

    10 May 05 13:22, Kevin Klement wrote to Mike Tripp:

    sq386 out -cz:\sq386\squish.cfg -fz:\sq386\echotoss.log

    Now don't pick on me about my route.cfg, because it was set this
    reason at one time, can't remember why. I think my route.cfg is
    changing outbound nodes flavor.

    So it appears that you never flavor anything crash, have a short list that goes
    normal, and then hold for a majority. Your midnight invoke doesn't include any
    of the schedule switches, so only the global stuff before the the first SCHED is being used for that run.

    So presumably the issue is that some address that you're expecting to end up with .HLO file is ending up as .FLO and Bink is trying to dial them? If so, which addresses are ending up with unexpected flavors?

    .\\ike

    --- GoldED 2.50+
    * Origin: -=( The TechnoDrome )=- Austin,TX 512-327-8598 33.6k (1:382/61)
  • From Gord Hannah@1:17/23.1 to Kevin Klement on Wednesday, May 11, 2005 07:52:42
    Replying to a message from Kevin Klement 1:134/77 to Kevin Klement,

    About Verson260A, On Tue May 10 2005

    My network runs on genuineIntel 3.2 Ghz. Three Boxes hooked into a
    Linksys. Two boxes OS is XPH, the third box OS is MS-DOS 6.22.

    Change one of the XPH to OS/2 and then have real fun..:-) Then just for fun add a Mac, and build a Linux box, then you have all the bases covered, sort of.:-)

    We have OS/2 Warp 4 here, wife has XPP, my laptop Win98, A Mac Performa, and a spare Laptop and a spare Desktop, If I had room I would use my hub in conjunction with my router, or I would pick up an eight port router.

    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 Kevin Klement@1:134/77 to Mike Tripp on Wednesday, May 11, 2005 15:33:42
    Hi Mike,

    Wednesday May 11 2005, Mike Tripp writes to Kevin Klement:
    So presumably the issue is that some address that you're
    expecting to end up with .HLO file is ending up as .FLO and
    Bink is trying to dial them? If so, which addresses are
    ending up with unexpected flavors?

    Yes, everything you just said is happening. I just went and looked at my binkley.log and S*** it's doing it again.

    Node 1:134/303 is always flavored as HOLD, I send his mail via binkp.

    ===========================[ BEGINNING OF DAILY LOG=========================== ! 11 May 00:00:13 NOTE Backing up logs for yesterday took 0 seconds
    ! 11 May 00:00:13 NOTE End bbslogs.bat----------------------------------

    + 11 May 00:04:09 BINK begin, BinkleyTerm Version 2.60A -uSoft7.0
    : 11 May 00:04:09 BINK Starting Event 3
    * 11 May 00:04:25 BINK Processing node 1:134/11 -- Mike'S Madhouse
    : 11 May 00:04:25 BINK Dialing 288-8208
    # 11 May 00:04:44 BINK Connect 28800/Arq/V34/Lapm/V42Bis
    * 11 May 00:04:53 BINK MikE'S MaDHousE (1:134/11)
    : 11 May 00:04:53 BINK Aka: 30:30/2 30:250/0 30:250/110
    : 11 May 00:04:53 BINK 510:501/0 510:501/5.1 510:5120/0
    * 11 May 00:04:53 BINK Remote Uses BinkleyTerm 2.60/(UNREGISTERED)
    : 11 May 00:04:53 BINK SysOp: Michael Grant from Calgary, Alberta
    11 May 00:04:53 BINK Phone: +1-403-288-8208
    11 May 00:04:53 BINK Flags: 9600,XA,V32b,V34
    : 11 May 00:04:53 BINK Tranx: 42814C1E / 42814C13
    : 11 May 00:04:53 BINK Session method: Janus
    # 11 May 00:04:53 BINK Sending Z:\Outbound\0086000b.OUT
    + 11 May 00:05:10 BINK CPS: 904 (15380 bytes) Efficiency: 31%
    + 11 May 00:05:10 BINK Sent-J/32 Z:\Outbound\0086000b.OUT
    11 May 00:05:10 BINK File Z:\Outbound\0086000b.OUT deleted
    * 11 May 00:05:10 BINK End of WaZOO/EMSI Session
    11 May 00:05:13 BINK Received: 0/0 Sent: 1/15380 Total: 1/15380 CPS: 290
    * 11 May 00:05:13 BINK Seconds: 53 Tariff: 0 Fee: 0 System: 1:134/11
    * 11 May 00:08:06 BINK Processing node 1:134/178 -- The Opportunity Network
    : 11 May 00:08:06 BINK Dialing 241-8911
    # 11 May 00:08:16 BINK Ringing
    # 11 May 00:08:33 BINK Connect 14400/Arq/V32/Lapm/V42Bis
    * 11 May 00:08:36 BINK Intro: <PCB#1@05-09-05*22:58:51> CONNECT 14400/ARQB
    * 11 May 00:08:37 BINK The Opportunity Network (1:134/178)
    * 11 May 00:08:37 BINK Remote Uses PCBoard 15.22/9902131
    : 11 May 00:08:37 BINK SysOp: Janusz Suchorolski from Calgary AB
    11 May 00:08:37 BINK Phone: 403-241-8911
    11 May 00:08:37 BINK Flags: V32B,V42B,CM,XA
    : 11 May 00:08:37 BINK Session method: ZedZip
    11 May 00:08:37 BINK Sending Mail Packet
    + 11 May 00:08:46 BINK CPS: 2563 (15380 bytes) Efficiency: 177%
    + 11 May 00:08:46 BINK Sent-Z/32 Z:\Outbound\008600b2.OUT
    * 11 May 00:08:51 BINK End of WaZOO/EMSI Session
    11 May 00:08:54 BINK Received: 0/0 Sent: 1/15380 Total: 1/15380 CPS: 290
    * 11 May 00:08:54 BINK Seconds: 53 Tariff: 0 Fee: 0 System: 1:134/178
    * 11 May 00:11:43 BINK Processing node 1:134/303 -- Ice Zone
    : 11 May 00:11:43 BINK Dialing 011-000-000-0000
    # 11 May 00:12:32 BINK Busy
    + 11 May 00:12:35 BINK End of connection attempt
    * 11 May 00:15:57 BINK Processing node 1:134/303 -- Ice Zone
    : 11 May 00:15:57 BINK Dialing 011-000-000-0000
    # 11 May 00:16:46 BINK Busy
    + 11 May 00:16:49 BINK End of connection attempt
    * 11 May 00:18:50 BINK Processing node 1:134/303 -- Ice Zone
    : 11 May 00:18:50 BINK Dialing 011-000-000-0000
    # 11 May 00:19:39 BINK Busy
    + 11 May 00:19:42 BINK End of connection attempt
    * 11 May 00:23:25 BINK Processing node 1:134/303 -- Ice Zone
    : 11 May 00:23:25 BINK Dialing 011-000-000-0000
    # 11 May 00:24:14 BINK Busy
    + 11 May 00:24:17 BINK End of connection attempt
    * 11 May 00:27:15 BINK Processing node 1:134/303 -- Ice Zone
    : 11 May 00:27:15 BINK Dialing 011-000-000-0000
    # 11 May 00:28:04 BINK Busy
    + 11 May 00:28:06 BINK End of connection attempt
    * 11 May 00:31:58 BINK Processing node 1:134/303 -- Ice Zone
    : 11 May 00:31:58 BINK Dialing 011-000-000-0000
    # 11 May 00:32:47 BINK Busy
    + 11 May 00:32:50 BINK End of connection attempt
    # 11 May 00:34:32 BINK Forced exit - errorlevel 70
    + 11 May 00:34:32 BINK end, BinkleyTerm Version 2.60A -uSoft7.0


    Kevin
    klement@shaw.ca

    --- Squish/386 v1.11
    * Origin: This unit must survive! (1:134/77)
  • From Kevin Klement@1:134/77 to Gord Hannah on Wednesday, May 11, 2005 17:50:02
    Hi Gord,

    Wednesday May 11 2005, Gord Hannah writes to Kevin Klement:

    \ > Change one of the XPH to OS/2 and then have real fun..:-)
    Then just for fun add a Mac, and build a Linux box, then you
    have all the bases covered, sort of.:-)

    Right on ... Lot's to do. I'm also getting ready to setup gypsy-designs.com too, should be all good.
    Kevin
    klement@shaw.ca

    --- Squish/386 v1.11
    * Origin: This unit must survive! (1:134/77)
  • From Kevin Klement@1:134/77 to Mike Tripp on Wednesday, May 11, 2005 18:45:35
    Hi Mike,

    Wednesday May 11 2005, Mike Tripp writes to Kevin Klement:

    So it appears that you never flavor anything crash, have a
    short list that goes normal, and then hold for a majority.
    Your midnight invoke doesn't include any of the schedule
    switches, so only the global stuff before the the first
    SCHED is being used for that run.
    ^^^^^^

    Then it does the second (SCHED) run?
    Kevin
    klement@shaw.ca

    --- Squish/386 v1.11
    * Origin: This unit must survive! (1:134/77)
  • From Mike Tripp@1:382/61 to Kevin Klement on Thursday, May 12, 2005 09:05:40
    Hello Kevin!

    11 May 05 17:45, Kevin Klement wrote to Mike Tripp:

    Your midnight invoke doesn't include any of the schedule
    switches, so only the global stuff before the the first
    SCHED is being used for that run.
    ^^^^^^

    Then it does the second (SCHED) run?

    I don't use them myself, but the way I interpret the docs says that SCHED never
    run at all unless explicitly named in a commandline switch. If invoked, then all the "global stuff" before the first SCHED is run followed by whatever is between the specified SCHED tag and the next SCHED statement.

    I also don't flavor anything "normal" as that is basically "unflavored" and still leaves the result open to any following commands. So I basically do:

    CHANGE CRASH normal world
    SEND HOLD <list of folks who poll me for pickup>
    SEND CRASH <list of known links who will always answer>
    ROUTE CRASH 140/1 <forward any unknowns left over via Bob>

    The CHANGE is there to catch any BBS-entered netmail or routed netmail from downlinks that already had the crash flag set, and force it to follow my routing logic instead. I deliberately don't reflavor anything that's already HOLD, because I like to use the Bink outbound screen to change a CRASH node over to HOLD manually if they are NO ANSWER, not responding, or rejecting my sessions due to a stray .BSY flag. Once I manually put them on HOLD, I don't want Squish re-CRASHing them again in the next run.

    So I'm having difficulty imagining the flow of yours:

    SEND NORMAL <list of some folks>
    ROUTE NORMAL BOB <world basically>
    SEND NORMAL world
    SEND HOLD <list of folks that poll>

    It would make more sense to me that you single out the HOLD folks first, then NORMAL the known folks you want to deliver to, then ROUTE the leftovers. Also curious as to if/when you actually call which of the schedule events.

    .\\ike

    --- GoldED 2.50+
    * Origin: -=( The TechnoDrome )=- Austin,TX 512-327-8598 33.6k (1:382/61)
  • From Kevin Klement@1:134/77 to Mike Tripp on Friday, May 13, 2005 14:17:43
    Afternoon Mike,

    I don't use them myself, but the way I interpret the docs
    says that SCHED never run at all unless explicitly named in
    a commandline switch.

    If I remember correct, YES i did at one time use the SCHED with a command line variable, at one time here in Calgary we had 90+ BBS on line and I HUBED them all, so my setup has changed as things change.

    It would make more sense to me that you single out the HOLD
    folks first, then NORMAL the known folks you want to deliver
    to, then ROUTE the leftovers.

    Okay. :)

    Also curious as to if/when
    you actually call which of the schedule events.

    Nope not any more, so I just commented it out for now.

    Well with all things said and done, I've used all your ideas to see if Bink STOPS dialing HOLD nodes. So here is my current (as of today) setup. Now I'll just sit back and see what happens. Let me know what you think of my current setup. :)

    route.cfg:
    ;
    ;
    ; Modifited: 05/13/05 01:13 pm
    ;
    ; Nodes we put on HOLD
    SEND hold 1:17/80
    SEND hold 1:134/10
    SEND hold 1:134/33
    SEND hold 1:134/703
    SEND hold 1:134/503
    SEND hold 1:134/303
    SEND hold 1:140/1
    SEND hold 30:250/140
    SEND hold 30:1000/0
    ;
    ; Nodes we DO NOT wish to have routed via LPM
    SEND normal 1:17/0
    SEND normal 30:100/all
    SEND normal 30:1000/all
    SEND normal 1:134/all
    SEND normal 1:342/1
    SEND normal 1:134/1 65535/65535 -1/-1
    ;
    ;
    ; All fall-through mail is now routed through our LPM feed node, 1:140/1
    ROUTE normal 1:140/1 1:all 2:all 3:all 4:all 5:all 6:all
    SEND normal world
    ;
    ;
    ; SCHED Hold134
    ;
    ; CHANGE normal hold 1:134:all
    ; CHANGE crash hold 1:134:all
    ;
    ; SCHED UnHold134
    ;
    ; CHANGE hold normal 1:134:all
    ;

    binkley.evt
    ; For MDT $ B D N L M F R X C Q A T E1 E2 ;---------------------------------------------------------------------------- Event All 00:00 01:00 F E1=100
    Event All 01:00 01:00 F Q=0 E1=97
    Event All 01:00 03:00 $ B Q=0 T=2,25 E2=40 Event All 03:00 03:30 D N M C A=60 T=2,25 E2=40 Event All 03:30 04:00 N L M A=60 T=2,25 E2=40 Event All 04:00 06:00 $ B L Q=0 E2=40 Event Sat 10:00 10:00 F Q=0 E1=98
    Event All 06:00 23:59 B L Q=0 E2=40


    Kevin
    klement@shaw.ca
    --- Squish/386 v1.11
    * Origin: This unit must survive! (1:134/77)
  • From Kevin Klement@1:134/77 to All on Saturday, May 14, 2005 14:43:30
    Hi!

    HELP, Binkley has been smoking too too much POT over her and has lost it's mind, I can't stop it from dialing out to nodes marked HOLD.

    I had to trick Bink not to dial out to HOLD nodes like this ... It uses a script file called "Dialtmp.Scr" which does nothing. :)

    binkley.cfg:
    ; Dialing Translation Table
    ; -----------------------------
    ; Force V.32 connects with the following ...
    ;
    ;Dial 1-206-473-8675 1-206-473-8675B1/
    ;Dial 546-3109 546-3109M1/
    ;
    ;Dial 247-3888 "Fido120.Scr"/
    Dial 1-000-000-0000 "Dialtmp.Scr"/
    Dial 011-000-000-0000 "Dialtmp.Scr"/
    Dial 000-000-0000 "Dialtmp.Scr"/
    ;

    It only does it after midnight maintenance.
    Node 1:134/303 is marked HOLD.


    binkly.log
    ===========================[ BEGINNING OF DAILY LOG ]===========================
    ! 14 May 00:00:14 NOTE Backing up logs for yesterday took 1 second
    ! 14 May 00:00:14 NOTE End bbslogs.bat----------------------------------

    + 14 May 00:04:15 BINK begin, BinkleyTerm Version 2.60A -uSoft7.0
    * 14 May 00:04:32 BINK Processing node 1:134/11 -- Mike'S Madhouse
    : 14 May 00:04:32 BINK Dialing 288-8208
    # 14 May 00:04:51 BINK Connect 28800/Arq/V34/Lapm/V42Bis
    * 14 May 00:05:00 BINK MikE'S MaDHousE (1:134/11)
    : 14 May 00:05:00 BINK Aka: 30:30/2 30:250/0 30:250/110
    : 14 May 00:05:00 BINK 510:501/0 510:501/5.1 510:5120/0
    * 14 May 00:05:00 BINK Remote Uses BinkleyTerm 2.60/(UNREGISTERED)
    : 14 May 00:05:00 BINK SysOp: Michael Grant from Calgary, Alberta
    14 May 00:05:00 BINK Phone: +1-403-288-8208
    14 May 00:05:00 BINK Flags: 9600,XA,V32b,V34
    : 14 May 00:05:00 BINK Tranx: 428540A6 / 4285409C
    : 14 May 00:05:01 BINK Session method: Janus
    # 14 May 00:05:01 BINK Sending Z:\Outbound\0086000b.OUT
    + 14 May 00:05:20 BINK CPS: 940 (17868 bytes) Efficiency: 32%
    + 14 May 00:05:20 BINK Sent-J/32 Z:\Outbound\0086000b.OUT
    14 May 00:05:20 BINK File Z:\Outbound\0086000b.OUT deleted
    * 14 May 00:05:20 BINK End of WaZOO/EMSI Session
    14 May 00:05:23 BINK Received: 0/0 Sent: 1/17868 Total: 1/17868 CPS: 319
    * 14 May 00:05:23 BINK Seconds: 56 Tariff: 0 Fee: 0 System: 1:134/11
    * 14 May 00:07:35 BINK Processing node 1:134/178 -- The Opportunity Network
    : 14 May 00:07:35 BINK Dialing 241-8911
    # 14 May 00:07:45 BINK Ringing
    # 14 May 00:08:02 BINK Connect 14400/Arq/V32/Lapm/V42Bis
    * 14 May 00:08:04 BINK Intro: <PCB#1@05-12-05*22:58:16> CONNECT 14400/ARQB
    * 14 May 00:08:06 BINK The Opportunity Network (1:134/178)
    * 14 May 00:08:06 BINK Remote Uses PCBoard 15.22/9902131
    : 14 May 00:08:06 BINK SysOp: Janusz Suchorolski from Calgary AB
    14 May 00:08:06 BINK Phone: 403-241-8911
    14 May 00:08:06 BINK Flags: V32B,V42B,CM,XA
    : 14 May 00:08:06 BINK Session method: ZedZip
    14 May 00:08:06 BINK Sending Mail Packet
    + 14 May 00:08:17 BINK CPS: 2233 (17868 bytes) Efficiency: 155%
    + 14 May 00:08:17 BINK Sent-Z/32 Z:\Outbound\008600b2.OUT
    * 14 May 00:08:22 BINK End of WaZOO/EMSI Session
    14 May 00:08:25 BINK Received: 0/0 Sent: 1/17868 Total: 1/17868 CPS: 324
    * 14 May 00:08:25 BINK Seconds: 55 Tariff: 0 Fee: 0 System: 1:134/178
    * 14 May 00:10:44 BINK Processing node 1:134/303 -- Ice Zone
    : 14 May 00:10:44 BINK Dialing with script 'Dialtmp.Scr'
    + 14 May 00:10:44 BINK Script 'Dialtmp.Scr' failed at line 1
    + 14 May 00:10:47 BINK End of connection attempt
    * 14 May 00:13:20 BINK Processing node 1:134/303 -- Ice Zone
    : 14 May 00:13:20 BINK Dialing with script 'Dialtmp.Scr'
    + 14 May 00:13:20 BINK Script 'Dialtmp.Scr' failed at line 1
    + 14 May 00:13:23 BINK End of connection attempt
    * 14 May 00:15:06 BINK Processing node 1:134/303 -- Ice Zone
    : 14 May 00:15:06 BINK Dialing with script 'Dialtmp.Scr'
    + 14 May 00:15:06 BINK Script 'Dialtmp.Scr' failed at line 1
    + 14 May 00:15:09 BINK End of connection attempt
    * 14 May 00:19:11 BINK Processing node 1:134/303 -- Ice Zone
    : 14 May 00:19:11 BINK Dialing with script 'Dialtmp.Scr'
    + 14 May 00:19:11 BINK Script 'Dialtmp.Scr' failed at line 1
    + 14 May 00:19:14 BINK End of connection attempt
    * 14 May 00:22:46 BINK Processing node 1:134/303 -- Ice Zone
    : 14 May 00:22:46 BINK Dialing with script 'Dialtmp.Scr'
    + 14 May 00:22:46 BINK Script 'Dialtmp.Scr' failed at line 1
    + 14 May 00:22:49 BINK End of connection attempt
    * 14 May 00:25:30 BINK Processing node 1:134/303 -- Ice Zone
    : 14 May 00:25:30 BINK Dialing with script 'Dialtmp.Scr'
    + 14 May 00:25:30 BINK Script 'Dialtmp.Scr' failed at line 1
    + 14 May 00:25:33 BINK End of connection attempt
    * 14 May 00:29:14 BINK Processing node 1:134/303 -- Ice Zone
    : 14 May 00:29:14 BINK Dialing with script 'Dialtmp.Scr'
    + 14 May 00:29:14 BINK Script 'Dialtmp.Scr' failed at line 1
    + 14 May 00:29:18 BINK End of connection attempt
    * 14 May 00:30:43 BINK Processing node 1:134/303 -- Ice Zone
    : 14 May 00:30:43 BINK Dialing with script 'Dialtmp.Scr'
    + 14 May 00:30:43 BINK Script 'Dialtmp.Scr' failed at line 1
    + 14 May 00:30:46 BINK End of connection attempt
    * 14 May 00:34:23 BINK Processing node 1:134/303 -- Ice Zone
    : 14 May 00:34:23 BINK Dialing with script 'Dialtmp.Scr'
    + 14 May 00:34:23 BINK Script 'Dialtmp.Scr' failed at line 1
    + 14 May 00:34:26 BINK End of connection attempt
    # 14 May 00:34:34 BINK Forced exit - errorlevel 70
    + 14 May 00:34:34 BINK end, BinkleyTerm Version 2.60A -uSoft7.0


    Kevin
    klement@shaw.ca

    --- Squish/386 v1.11
    * Origin: This unit must survive! (1:134/77)