[Dxspider-support] Starting DXSpider...'error' messages?. Also BPQ32 issues.

[Ron Stordahl]

Dirk

Here is a screen output from a startup.  That is all the context I know about:

Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.

C:\Documents and Settings\Ron Stordahl>cd \spider\perl

C:\spider\perl>perl cluster.pl
Prototype mismatch: sub Msg::F_GETFL () vs none at (eval 9) line 1.
Prototype mismatch: sub Msg::F_SETFL () vs none at (eval 10) line 1.
cluster
DXSpider V1.54, build 0.201 started
Copyright (c) 1998-2008 Dirk Koopman G1TLH
loading prefixes ...
US Database not loaded
loading band data ...
loading user file system ...
starting listeners ...
Internal port: localhost 27754 using IntMsg
External Port: 0.0.0.0 7300 using ExtMsg::login
AGW Listener
AGW initialising and connecting to localhost/8000 ...
Cannot connect to AGW Engine at localhost/8000 Unknown error
load badwords: Ok
Starting Dupe system
Read in Messages
Read in Aliases
Start WWV
Start WCY
Starting DX Spot system
Start Protocol Engines ...
DXChannel N5IN-5 created (1)
reading existing message headers ...
load badmsg: Ok
load forward: Ok
load swop: Ok
reading cron jobs ...
cron: reading /spider/cmd/crontab
cron: adding 1 0 * * 3 DXUser::export("$main::data/user_asc")
cron: adding 5 0 * * * DXDebug::dbgclean()
cron: adding 0 3 * * * Spot::daily()
reading database descriptors ...
doing local initialisation ...
orft we jolly well go ...
queue msg (0)
cluster
DXSpider V1.54, build 0.201 ended

C:\spider\perl>

You will see from the above that DXS tried to connect to AGWPE, but failed, as I did not have AGWtoBPQ running.  The delay during the startup was not too long, but it did wait for a bit longer than I would have expected.  But then it continued and DXS is running, however as far as I can tell it does not retry to connect to AGWtoBPQ as I think it should, perhaps once/minute would be reasonable.  The tiemout for failure to connect could be short I would think, as it is to localhost, but of course it could be to AGWtoBPQ on a remote machine.

You mention build 0.205 where 'the man' John G8BPQ has provided some updates.  I am glad to hear you have included them.  The release of BPQ32 which I am currently completing the packaging thereof (an installer and revised documents) is the version which works with DXS, either via the DLL interface or via AGWtoBPQ.  Of course the 'retry connection to AGWtoBPQ' is something you would have to do.

As to updating my copy of 0.205, I admit to not knowing how to do that other than by perhaps removing and doing a new install.  I suppose there is some easy method to update...perhaps I need to read the docs?  I should do the update so that my BPQ32 installation document description is current with DXS.

Ron, N5IN



Dirk Koopman <djk at tobit.co.uk> wrote: Ron

I have not tried this particular version of perl on Windows. I would 
appreciate it if you could give me some more context for the errors that 
you see. These are new to me.

Also, as of 0.205, there is now a native BPQ interface for Windows 
machines (only), supplied by the man himself. You will find the (rather 
sparse) instructions in /spider/txt.

And you are probably right about retrying the connection. I will look at 
that.

Dirk

Ron Stordahl wrote:
> I have installed on W2K Active Perl 5.10.0 build 1002, and then DXSpider 
> v 1.54 build 0.201.  My main purpose was to test the latest BPQ32, 
> testing both the DLL and AGWtoBPQ (AGWPE emulator) interfaces.
> 
> When I start DXSpider thus:
>  > perl cluster.pl
> I get these two lines which I don't understand:
> 
> Prototype mismatch: sub Msg::F_GETFL <> vs none t  line 1.
> Prototype mismatch: sub Msg::F_SETFL <> vs none t  line 1.
> 
> Then it continues and appears to start DXS just fine.
> 
> With the most recent, not yet released, version of BPQ32 I am able to 
> use BPQ32 successfully with either the DLL or AGWtoBPQ interfaces.
> 
> The only issue I see is that when using the AGWtoBPQ interface, DXSpider 
> requires that it be already running when Spider is started, and if 
> AGWtoBPQ is later cancelled, Spider does not attempt to reconnect to it 
> as it should if AGWtoBPQ be restarted.  
> 
> Ideally DXS should, when starting (when configured to use AGWtoBPQ) if 
> it cannot make the connection it should swiftly continue on, and then 
> periodically attempt a connection to AGWtoBPQ, perhaps every 2 minutes.  
> Later if it has been connected, but AGWtoBPQ is cancelled, it should 
> drop the associated users, but try to reconnect to AGWtoBPQ 
> periodically.  The big advantage of this procedure is that existing 
> telnet users will continue without interuption, yet BPQ32 can be 
> reconfigured, cancelled and restarted.  Also in as much as AGWtoBPQ 
> could be running on a remote machine, one must expect that the link 
> could be interupted and restored.
> 
> Ron, N5IN
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at dxcluster.org
> http://mailman.tobit.co.uk/mailman/listinfo/dxspider-support


_______________________________________________
Dxspider-support mailing list
Dxspider-support at dxcluster.org
http://mailman.tobit.co.uk/mailman/listinfo/dxspider-support

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20080224/f6980d39/attachment.htm