@pushkan, maybe you can use this tool:
PsExec a light-weight telnet-replacement that lets you execute processes on other systems
@pushkan, maybe you can use this tool:
@beppe while I am able to access Amibroker instance from remote m/c (say m/c 2), I am using the current m/c (say m/c 1) processor for working. My idea of working parallel on 2 machines is to share the processing loads. For that I just need to trigger Amibroker open in m/c 2 through a command in batch file of m/c 1 (Amibroker will open in m/c 2 when I trigger it through m/c 1).
The Amibroker on m/c 2 has a scheduler batch file which would then start processing on m/c 2
@pushkan, I'm not sure to fully understand what your goal is, but using psExec from an AmiBroker batch job, I was able to launch another AmiBroker instance on a remote machine in my local network.
First step: in the remote machine I created a DOS/Windows batch file (to simplify things I saved it in a folder included in the machine system PATH) naming it "run_ab.bat" as follow:
C: CD "\Program Files (x86)\Amibroker" start Broker.exe
(Note that you need to use the "start" commando to launch AmiBroker and NOT wait for its termination)
Second step: on the main machine I created another DOS/Windows batch file named "run_ps.bat" used to invoke psExec.exe as follow:
C: CD \PSTools psexec \\myremotemachinename -s -i run_ab.bat
where the \PSTools is the folder where I extracted the psExec.exe file (also the other tools since they are quite useful).
See the PSTools documentation for any additional parameters that you may need in your system (like to specify a username and password to ensure the running remote app will have access to certain system resources)
Third step: launch the "run_ps.bat" file from the AmiBroker an "Execute & Wait" line in a Batch job.
(The remote AmiBroker application will remain open; when/how to close it is up to you). If needed, PSTools allow to access the list of remote processes and kill them...
@beppe - > So far so good. However it has issues with launching of the default database & therefore the default path. I am attaching the screenshots.
Would it be because the default database & default afl paths are on a server (read it as a 3rd machine)?
Seems a network within a machine...
@pushkan that is the tricky part (dealing with Windows resources security settings...)
As I pointed before you need to read with attention the documentation and in particular the psExec Security section of this article to correctly understand how it works.
By default, the process you execute on the remote system impersonates the account from which you run PsExec on the local system. .... If the account in which you're running doesn't have local administrative privileges on the remote system, the process you want to run requires access to network resources, or you want to run a process in a different account, then use PsExec's -u switch to provide an alternative account name since it is running impersonating.
(In your case you'll probably need to use both the -u and the -p switches for username and password)
You need to experiment a bit, and if needed, modify your network users security settings (in general I recommend to use a user account with a non-empty password).
Probably, the best strategy to see if you can circumvent this kind of issue is to test psExec directly from a command prompt from your main machine.
I suggest you to launch on the remote machine a simpler application like Notepad.exe passing to it as argument a text filename stored on the server (on a share reachable from the remote machine). The filename should be a fully qualified network path like \myserver\data\readme.txt
Then, if you find a working solution, apply it to your AmiBroker batches.
@beppe - Firstly a thank you for your relentless efforts & patient hearing to my queries. As required, I have gone through the documentation part, did some trial & error, and tested it out on 2 different setups. I will try to recreate each of them here.
- Setup 1 : Wired LAN, with single login & password (Though not required). For ease of operations I defined the folder paths in environment variables on the m/c itself. There is no error in the actual operations except for the fact that the Amibroker triggered on remote m/c doesn't recognize the default path of the databases & afl folders. This maybe so because the databases & afl folders are present on different server (Again the login & password is not required per say). In normal operations, this server is accessed as a drive that is mapped on the local m/c. Probably @Tomasz, may throw some light on this. I tried changing the default database to a local database & it worked fine.
- Setup 2: Wireless LAN, connected through normal WiFi. Here again both m/c are part of same WORKGROUP with Windows10. Now under normal operations, again Amibroker can access on to database on the primary m/c; but psexec fails to trigger the interface on remote m/c
Maybe just a step forward for me...
@pushkan, thanks for our nice words.
Unfortunately, I cannot comment on setup # 2 since I do not have access to any Windows 10 machine.
Re: setup #1. Since you are using a mapped disk I suggest you to try to disconnect and reconnect it* in your remote machine batch file before the lines that will launch AmiBroker.
Add command lines similar to these:
net use w: /delete net use w: \\servername\pathtodata
where w is the mapped disk letter and \servername\pathtodata is the actual server path mapped as a disk.
Check the Net use documentation to see the various parameter available (in this case too maybe you should supply the username and password).
@beppe, Thanks once again. It indeed did work out well. Now to the inquisitive part (Apologies as it may only be academic in nature)
The bat file w/o the "net use" functionality did work stand alone on the remote machine, while error was generated only when triggered from the base machine. Any particular reason for this?
Also, the command prompt completes with an error, although there is no problem with the actual operation :
"RunAmi.bat exited on pushkarajk with error code 0."
@pushkan "All's Well That Ends Well"
Re the batch file returned error code, by convention, command line execution should return zero when execution succeeds and non-zero when execution fails (so there is no actual error). If required, you can set these codes in your batch files.
I'm not sure to fully understand the second paragraph, but the reason I suggested to use the "net use" for a mapped drive is related to "impersonating" (do a Google search to learn more).
.... and if you want to also automatically exit your remote AmiBroker when the "scheduled batches" are done check the recently introduced command line parameters.