Script to script parameters 1

[madesjardins]

Hi there (Knob),

I currently have a script running every night that connects to roughly 450 telnet or dial up sites, downloads X amount of reports and moves on to the next one. It works to my liking but it takes WAY too long to run.

What I was thinking of doing is a main script that "dispatches" another script to connect and retreive the reports from another (new) Procomm session. The main script would have to monitor wether the new procomm session is still working, or how many procomm session are running, and launch a new one with a directory entry as a parameter. When the "connecting" script is done doing its thing, it would close Procomm to let the "main" script know that it's done.

I have 2 problems with this :

1) How do I pass a parameter from 1 script to another without using files (for fear of multiple scripts accessing the same file at the same time, etc).

2) How can I tell if another Procomm session is still running? I can't use $PWTASK since it's all the same for all Procomm sessions.

Thanks for any help you may provide.

 

[knob]

Probably the easiest way to do this is via DDE. Here is some text from my site:

Here is one final example illustrating DDE operations. The script launches a second instance of Procomm Plus, which the first instance then makes a DDE connection with and requests the second instance run the hints script. This script was slightly modified from the script located in this technical bulletin. If you have further interest in this topic, I recommend reading item nine of this file. Please note that this script will only work with version 4.8 due to the the DDE server name changing from PW4 to PW5 with version 4.8.

One problem with the way Procomm Plus is architected is that it is difficult to know which instance of the program you are communicating with if there are multiple windows in existence. Using the above script as a starting point, this example shows how one script run in a "parent" Procomm Plus window can launch two additional windows, then command each "child" window to run a script using DDE.

The text above is from the samples page on my site. If you go there, you can find the links to the scripts. You may be able to build on the second sample to have a "master" script that starts several Procomm windows and runs the "child" scripts that collect the information. To determine if a Procomm window is still open, I think you should be able to use the winexists command with the value of pwhwnd1/pwhwnd2 (from the sample script) but have not tested this theory.


aspect@aspectscripting.com

http://www.aspectscripting.com

 

[madesjardins]

Alright. If all works well, that takes care of the 2nd question. Thanks.

I still don't see how I can tell the "child" Procomm which connection entry to use for the child script.... Unless I missed something??

 

[knob]

Sorry about that. You can use the same format for the ddexecute command, you would just change the argument to read "ASPECTCMD set modem connection \"connection_name\"" (may not have the quoting of the double quotes quite right off the top of my head).


aspect@aspectscripting.com

http://www.aspectscripting.com

 

[madesjardins]

Oh right. I kept talking about connection entries as if I was using the connection directory, but I'm not. I need more information per connection than what the directory can hold, so it's all in a seperate text file. It really would have to be a string variable.

 

[madesjardins]

Here's thought. Tell me what you think...

I read your technical bulletin about DDE and noticed that only 2 sessions could be used at once. If that means that a single PW5 session can only be a DDE client twice, maybe I could set the CHILD script to be the DDE client and do dderequest command to get the next connection entry to connect to.

Now the questions... Do you know if a PW5 sessions can be a server to more than one client, and if so, more than 2 clients.

Do you know if the DDE client limitation proper to a PW5 SESSION or the PW5 process? Since it's all the same process, I could be in troube.

Since I'm thinking of using AT LEAST 10 sessions, I need something that's scalable.

What do you think? I don't really have time to test it today so if you see something's wrong in there, I'd appreciate your input.

Thanks!

 

[knob]

I would have to do more research on this come the weekend, but I think the technical bulletin may be incorrect about the limit of sessions. The second sample script I reference has a main script that launches two other Procomm windows and has them btoh run scripts as DDE servers, so there you have three machines being able to communicate via DDE. Granted, it is not as involved as what you are trying to undertake.


aspect@aspectscripting.com

http://www.aspectscripting.com

 

[madesjardins]

I wrote two little test scripts this morning.

The server or parent script is this:


=================================================

string NextSite
string Sites[5]
integer SiteNumber=0

proc main

integer MainPWWin = $PWMAINWIN
string LineBuffer

Sites[0] = "Site0"
Sites[1] = "Site1"
Sites[2] = "Site2"
Sites[3] = "Site3"
Sites[4] = "Site4"

NextSite = Sites[0]

when NextSite call ChangeSite

if fopen 10 "WindowHandle.txt" CREATE TEXT
strfmt LineBuffer "%d" MainPWWin
fputs 10 LineBuffer
fclose 10
endif

while 1
yield
endwhile

endproc

proc ChangeSite

NextSite = Sites[++SiteNumber]
usermsg "WHEN triggered."

endproc

=================================================


The child and client script is this :


=================================================

proc main

string LineBuffer, SiteEntry
integer MainPWWin
long DDEInstance

if fopen 11 "WindowHandle.txt" READ TEXT
fgets 11 LineBuffer
atoi LineBuffer MainPWWin
endif

if ddeinit DDEInstance "PW5" "System" MainPWWin
if dderequest DDEInstance "NextSite" SiteEntry
if ddepoke DDEInstance "NextSite" "BogusSite"
usermsg "Everything succeeded. SiteEntry = `"%s`"" SiteEntry
else
usermsg "DDEPole Failed."
endif
else
usermsg "DDERequest Failed."
endif
else
usermsg "DDEInit Failed."
endif

endproc


=================================================


Now I launch the first one first, then run the second one manually. The second one should and does get the window handle of the first from that file. The DDEInit command succeeds, but the DDERequest fails.

In the first script, I have a "when" to monitor the variable "NextSite". Theoritically, when "ddepoked" by the second script, that should trigger the "ChangeSite" procedure and change the value of the "NextSite" variable so that the next session may take it. We don't get that far, but I did try to just do the DDEPoke without the DDERequest and it failed as well.

So I'm left wondering why it is that the DDEInit succeeds but the other two don't. Of course, this is my first attempt at DDE so I could've gotten everything wrong.

Do you have any ideas?

 

[madesjardins]

w00t!

I got things by changing the topic in my DDE init to the name of the parent script ("test.wax" in my test case) and changing to a predefined global string variable ("s0&quot as the variable that is transmitted back and forth.

I also had to change my ChangeSite procedure to

proc ChangeSite

when s0 clear
s0 = Sites[++SiteNumber]
when s0 call ChangeSite

endproc

as the assigment of s0 triggered the WHEN again and it would loop.

I think I'm ready to go. Thanks for bringing DDE to my attention!

 

[madesjardins]

Hi Knob,

Me again. My script is coming along nicely and there's only things that bug me.

1) Seems that when if I do a DDEInit from my "slave" script to my "master" script and the "master" was already running before, the DDEInit fails. So I need the slave the start the master, but it's the master that starts the slave. Chicken and egg anyone?

2) This is minor, but it seems that DDEInit doesn't like having scripts in another directory than the default aspect one. Know of a way around that?

Thanks a lot for your help.

 

[madesjardins]

I noticed this in the Aspect help about my 1) issue.

"
Procomm Plus makes available two DDE topics when acting as a server: "System" and the name of a script file with a .wax extension. If a valid script name is supplied, the script will run when the DDE session is established. If a script is already running when the session is established, the script name topic will be accepted only if one of the following is true:

· The supplied name is the same as the executing script.
· ASPECT is allowed to spawn other scripts on top of the executing script.
"

That last bullet point is intresting. I can't see where I would check if Aspect is allowed to do such a thing and maybe that's what's preventing my slave script to hook onto the master script if the master script is already running.

No?

 

[knob]

Wanted to let you know I haven't forgot about your questions, I just haven't had time to sit down and work through them yet. I should be able to this weekend.


aspect@aspectscripting.com

http://www.aspectscripting.com

 

[knob]

Regarding having ddeexecute launch a script from a non-default location, I was able to do this by specifying the path to the file (for example, ddeexecute c:\script.wax). Were you using a path with long filenames or spaces that might need quoting?

As for spawning another ASPECT script, your master script would need to issue:

set aspect spawn on

You might give that a try and see if it resolves your problem. Here is some additional information from the help file:

Determines whether a script may be executed while another script is running. If ON, scripts can be spawned from a Connection Directory entry, in response to a Meta Key press, via a ddeexecute command or by other methods. By default, this setting is OFF when a script is initially executed. fetch returns 0 for OFF or 1 for ON.

This command has no effect on the execute and chain commands.

aspect@aspectscripting.com

http://www.aspectscripting.com