Dirk<br><br>I have updated to 0.206 using WinCVS. As you said it is magic!<br><br>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.<br><br>I have tested Spider 0.206 with both the BPQ32 DLL and AGWtoBPQ interfaces and they work fine other than:<br><br>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. <br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>It's really easy!<br><br>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!<br><br>Thanks,<br><br>Ron Stordahl, N5IN<br><br><br><br><br><br><br><br><b><i>Ron Stordahl <ron_n5in@yahoo.com></i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> 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>_______________________________________________<br>Dxspider-support mailing list<br>Dxspider-support@dxcluster.org<br>http://mailman.tobit.co.uk/mailman/listinfo/dxspider-support<br></blockquote><br>