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

Sun Feb 24 22:39:17 GMT 2008

Dirk

I have updated to 0.206 using WinCVS.  As you said it is magic!

There were no changes, in the puzzling to me, 'Prototype mismatch' lines.  Of course I am running a later version of Perl, perhaps that is it..but I don't see where it causes any obvious trouble.

I have tested Spider 0.206 with both the BPQ32 DLL and AGWtoBPQ interfaces and they work fine other than:

1) If you start AGWtoBPQ before Spider, then Spider connects promptly to AGWtoBPQ, but if you later cancel AGWtoBPQ, Spider terminates.  It should not, as you may have telnet users.  

2) If you start Spider without AGWtoBPQ running, there is a perhaps 30 second delay at the 'AGW initializing...' line, then the loading continues and Spider runs.  However if you now start AGWtoBPQ, Spider never does try to connect to it.  I would recommend it try once/minute.

As you understand it is desirable to be able to close AGWtoBPQ, for reconfiguration, without Spider going to end of course, but it should also try to reconnect periodically.  The idea is to be able to close, reconfigure and restart AGWtoBPQ without dropping a likely larger number of telnet users.

John is thinking about how BPQ32, when loaded via the DLL, could have a similar feature, perhaps a command would have to be issued by the application to unload and reload...but this is still in the thinking stage.

The only user effort to include BPQ32, other than running the BPQ32 installer with defaults, is the editing of BPQConnect.pl and AGWConect.pl by enabling or disabling.

It's really easy!

There are updates to BPQ32 needed for Spider, they will be in my new installer.  I am still working on the docs, but the BPQ32 updates are all there.  You probably have the current stuff from John, but I will be glad to send you the installer as long as it understood it is not completely polished!

Thanks,

Ron Stordahl, N5IN

Ron Stordahl <ron_n5in at yahoo.com> wrote: 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

_______________________________________________
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/92b6be3d/attachment-0001.htm 