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)

*** 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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)