Dirk<br><br>Here is a screen output from a startup. That is all the context I know about:<br><br>Microsoft Windows 2000 [Version 5.00.2195]<br>(C) Copyright 1985-2000 Microsoft Corp.<br><br>C:\Documents and Settings\Ron Stordahl>cd \spider\perl<br><br>C:\spider\perl>perl cluster.pl<br>Prototype mismatch: sub Msg::F_GETFL () vs none at (eval 9) line 1.<br>Prototype mismatch: sub Msg::F_SETFL () vs none at (eval 10) line 1.<br>cluster<br>DXSpider V1.54, build 0.201 started<br>Copyright (c) 1998-2008 Dirk Koopman G1TLH<br>loading prefixes ...<br>US Database not loaded<br>loading band data ...<br>loading user file system ...<br>starting listeners ...<br>Internal port: localhost 27754 using IntMsg<br>External Port: 0.0.0.0 7300 using ExtMsg::login<br>AGW Listener<br>AGW initialising and connecting to localhost/8000 ...<br>Cannot connect to AGW Engine at localhost/8000 Unknown error<br>load badwords: Ok<br>Starting Dupe system<br>Read in Messages<br>Read in
Aliases<br>Start WWV<br>Start WCY<br>Starting DX Spot system<br>Start Protocol Engines ...<br>DXChannel N5IN-5 created (1)<br>reading existing message headers ...<br>load badmsg: Ok<br>load forward: Ok<br>load swop: Ok<br>reading cron jobs ...<br>cron: reading /spider/cmd/crontab<br>cron: adding 1 0 * * 3 DXUser::export("$main::data/user_asc")<br>cron: adding 5 0 * * * DXDebug::dbgclean()<br>cron: adding 0 3 * * * Spot::daily()<br>reading database descriptors ...<br>doing local initialisation ...<br>orft we jolly well go ...<br>queue msg (0)<br>cluster<br>DXSpider V1.54, build 0.201 ended<br><br>C:\spider\perl><br><br>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.<br><br>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.<br><br>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.<br><br>Ron, N5IN<br><br><br><br><b><i>Dirk
Koopman <djk@tobit.co.uk></i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> Ron<br><br>I have not tried this particular version of perl on Windows. I would <br>appreciate it if you could give me some more context for the errors that <br>you see. These are new to me.<br><br>Also, as of 0.205, there is now a native BPQ interface for Windows <br>machines (only), supplied by the man himself. You will find the (rather <br>sparse) instructions in /spider/txt.<br><br>And you are probably right about retrying the connection. I will look at <br>that.<br><br>Dirk<br><br>Ron Stordahl wrote:<br>> I have installed on W2K Active Perl 5.10.0 build 1002, and then DXSpider <br>> v 1.54 build 0.201. My main purpose was to test the latest BPQ32, <br>> testing both the DLL and AGWtoBPQ (AGWPE emulator) interfaces.<br>> <br>> When I start DXSpider thus:<br>> > perl cluster.pl<br>> I
get these two lines which I don't understand:<br>> <br>> Prototype mismatch: sub Msg::F_GETFL <> vs none t <eval 9=""> line 1.<br>> Prototype mismatch: sub Msg::F_SETFL <> vs none t <eval 10=""> line 1.<br>> <br>> Then it continues and appears to start DXS just fine.<br>> <br>> With the most recent, not yet released, version of BPQ32 I am able to <br>> use BPQ32 successfully with either the DLL or AGWtoBPQ interfaces.<br>> <br>> The only issue I see is that when using the AGWtoBPQ interface, DXSpider <br>> requires that it be already running when Spider is started, and if <br>> AGWtoBPQ is later cancelled, Spider does not attempt to reconnect to it <br>> as it should if AGWtoBPQ be restarted. <br>> <br>> Ideally DXS should, when starting (when configured to use AGWtoBPQ) if <br>> it cannot make the connection it should swiftly continue on, and then <br>> periodically attempt a connection to AGWtoBPQ, perhaps
every 2 minutes. <br>> Later if it has been connected, but AGWtoBPQ is cancelled, it should <br>> drop the associated users, but try to reconnect to AGWtoBPQ <br>> periodically. The big advantage of this procedure is that existing <br>> telnet users will continue without interuption, yet BPQ32 can be <br>> reconfigured, cancelled and restarted. Also in as much as AGWtoBPQ <br>> could be running on a remote machine, one must expect that the link <br>> could be interupted and restored.<br>> <br>> Ron, N5IN<br>> <br>> <br>> ------------------------------------------------------------------------<br>> <br>> _______________________________________________<br>> Dxspider-support mailing list<br>> Dxspider-support@dxcluster.org<br>> http://mailman.tobit.co.uk/mailman/listinfo/dxspider-support<br><br><br>_______________________________________________<br>Dxspider-support mailing
list<br>Dxspider-support@dxcluster.org<br>http://mailman.tobit.co.uk/mailman/listinfo/dxspider-support<br></eval></eval></blockquote><br>