Hello,
(Procomm Plus 4.8, Windows XP)
I work in a department that supports about 400+ Nortel switches/devices. I had a Procomm application that would sequentially telnet to a selected group of switches and process a set of scripts or commands. Like many on this forum, I have been looking for a way to concurrently process a task or set of tasks on multiple target destinations.
I came up with a way to do this and so far, the current version seems very stable. I think the stability comes from eliminating any need for a Procomm window to be the "active" window, for any reason, and using .ini files (Aspect's profileWr and profileRd). I have been doing most of my testing running a pool of 20 "Worker" sessions. Time improvement over the sequential method is about 86% for 5 seconds tasks and about 90% for 20 second tasks.
I redesigned the original application so that a Manager script creates 1 or more Worker sessions.
Manager Script:
* Runs in its own Procomm Window.
The user selects the script(s) or comannds to process (taskList), creates a selected list (selList) of devices from the "available devices list", AND sets the number of Worker sessions to create. Selecting 1 processes the devices in sequential mode.
Overview of the Manager/Worker Interaction:
The Manager launches a Procomm session for each Worker. Each of these Worker sessions will run a personalized version of the Worker script. Once all the Worker sessions are running, until the selList has no more entries, the Manager continues to present entries to idle Workers. The Worker logs in, process the taskList on that entry, and if all went well, reports that entry as "completed".
Manager Script:
When the user clicks the run button...
The Manager counts the number of entries in the selList and, in the .ini file, places a [CompletedList] section with a numeric key for each entry with an empty "" value.
[CompletedList]
0=
1=
2=
3=
(etc.)
Then it creates a [Register] section with a numeric key for each Worker with an empty "" value.
[Register]
0=
1=
2=
3=
(etc.)
Before the Manager launches EACH Worker session, it treats the Worker.WAS file as a .ini file populating it with a path to the main .ini file and the worker's unique register key, and then compiles the Worker.WAS file.
The .ini section of the Worker.WAS script:
;***********************************
; Vars for launcher() interaction.
integer RegKey ; A key for the .ini file.
string iniPath
proc setLocalIniValues
integer okay
;%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
; This file is also a .ini file.
; Launcher.inc::launcher() writes to these keys prior to calling this script.
;%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
#comment
[Register]
#endcomment
iniPath="C:\PROGRAM FILES\SYMANTEC\PROCOMM PLUS\ASPECT\BATCHMGR\BatchMgr.ini"
RegKey=3
#comment
[RegisterEnd]
#endcomment ; Ensure writes to [Register] section don't go beyond this point.
;%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
A running Worker script uses $PWMAINWIN to obtain the Window ID of its Procomm session window and sets the value of its registry key to that Window ID.
For the Manager, a populated value in the [Registry] section indicates that the Worker is established and able to communicate with the Manager.
The Manager creates a section for each window ID:
[3081104]
destString=
mgrMsg=STANDBY
wkrMsg=
destID=3
This section is a communication channel between the Manager and Worker.
The Manager...
* Sets destString= to the selList entry.
* Sets destID= to the selList entry's key in the [CompletedList].
* Sends commands to the Worker by setting wkrMsg to STANDBY, PROCESS, or DIE.
* Reads wkrMsg for the state ("", waiting, processing, done, finished) of the Worker.
The Worker...
* Reads and performs the mgrMsg command.
* Updates its state in wrkMsg
When the worker determines that all went well with processing a particular entry, it places that entry in the [CompletedList]. The Manager will promt the user whether or not to remove completed entries from the original selList.
The Manager uses the current state and previous state for each worker in a state-machine to manage each Worker.
; ""--S->waiting--P->processing-->done-.-D->finished
; ^__________S______________|
Lower case is the Worker's state and the upper case is the manager command to send to get the Worker to the next state.
Once established, each Worker basically waits for a Manager command, remembers the previous command, and keeps up its agreement to the state machine.
The Worker kills itself with pwexit.
%%%%%%%%%%%%%% Other Info. %%%%%%%%
There are two scripts: Manager.was and Worker.was and one
launcher.inc file.
The Manager provies the GUI and #includes the launcher.inc file providing the required parameters when it calls launcher().
Manager and Worker can be customized as a set. The Manager could include custom entries in the .ini file used by the Worker.
The launcher.inc file contains the launcher() proc:
proc launcher
param string script ;name of Worker.was file.
param string selectedListPath
param string iniPath
param integer selectedListSize
param integer numWorkersReq ;How many simultaneous workers to launch.
Launcher.inc should not need to be changed when the Manager/Worker set are customized.
Having multiple workers writing to one text file caused partial writes and overwrites which lead me to try writing to the .ini file. I think this works well because .ini writes happen one at a time and, possibly, are queued. It's too bad there are not more .ini related Aspect commands.
%%%%
Well, if you want to launch and manage multiple Procomm sessions, I hope this info is useful.
Craig
(Procomm Plus 4.8, Windows XP)
I work in a department that supports about 400+ Nortel switches/devices. I had a Procomm application that would sequentially telnet to a selected group of switches and process a set of scripts or commands. Like many on this forum, I have been looking for a way to concurrently process a task or set of tasks on multiple target destinations.
I came up with a way to do this and so far, the current version seems very stable. I think the stability comes from eliminating any need for a Procomm window to be the "active" window, for any reason, and using .ini files (Aspect's profileWr and profileRd). I have been doing most of my testing running a pool of 20 "Worker" sessions. Time improvement over the sequential method is about 86% for 5 seconds tasks and about 90% for 20 second tasks.
I redesigned the original application so that a Manager script creates 1 or more Worker sessions.
Manager Script:
* Runs in its own Procomm Window.
The user selects the script(s) or comannds to process (taskList), creates a selected list (selList) of devices from the "available devices list", AND sets the number of Worker sessions to create. Selecting 1 processes the devices in sequential mode.
Overview of the Manager/Worker Interaction:
The Manager launches a Procomm session for each Worker. Each of these Worker sessions will run a personalized version of the Worker script. Once all the Worker sessions are running, until the selList has no more entries, the Manager continues to present entries to idle Workers. The Worker logs in, process the taskList on that entry, and if all went well, reports that entry as "completed".
Manager Script:
When the user clicks the run button...
The Manager counts the number of entries in the selList and, in the .ini file, places a [CompletedList] section with a numeric key for each entry with an empty "" value.
[CompletedList]
0=
1=
2=
3=
(etc.)
Then it creates a [Register] section with a numeric key for each Worker with an empty "" value.
[Register]
0=
1=
2=
3=
(etc.)
Before the Manager launches EACH Worker session, it treats the Worker.WAS file as a .ini file populating it with a path to the main .ini file and the worker's unique register key, and then compiles the Worker.WAS file.
The .ini section of the Worker.WAS script:
;***********************************
; Vars for launcher() interaction.
integer RegKey ; A key for the .ini file.
string iniPath
proc setLocalIniValues
integer okay
;%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
; This file is also a .ini file.
; Launcher.inc::launcher() writes to these keys prior to calling this script.
;%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
#comment
[Register]
#endcomment
iniPath="C:\PROGRAM FILES\SYMANTEC\PROCOMM PLUS\ASPECT\BATCHMGR\BatchMgr.ini"
RegKey=3
#comment
[RegisterEnd]
#endcomment ; Ensure writes to [Register] section don't go beyond this point.
;%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
A running Worker script uses $PWMAINWIN to obtain the Window ID of its Procomm session window and sets the value of its registry key to that Window ID.
For the Manager, a populated value in the [Registry] section indicates that the Worker is established and able to communicate with the Manager.
The Manager creates a section for each window ID:
[3081104]
destString=
mgrMsg=STANDBY
wkrMsg=
destID=3
This section is a communication channel between the Manager and Worker.
The Manager...
* Sets destString= to the selList entry.
* Sets destID= to the selList entry's key in the [CompletedList].
* Sends commands to the Worker by setting wkrMsg to STANDBY, PROCESS, or DIE.
* Reads wkrMsg for the state ("", waiting, processing, done, finished) of the Worker.
The Worker...
* Reads and performs the mgrMsg command.
* Updates its state in wrkMsg
When the worker determines that all went well with processing a particular entry, it places that entry in the [CompletedList]. The Manager will promt the user whether or not to remove completed entries from the original selList.
The Manager uses the current state and previous state for each worker in a state-machine to manage each Worker.
; ""--S->waiting--P->processing-->done-.-D->finished
; ^__________S______________|
Lower case is the Worker's state and the upper case is the manager command to send to get the Worker to the next state.
Once established, each Worker basically waits for a Manager command, remembers the previous command, and keeps up its agreement to the state machine.
The Worker kills itself with pwexit.
%%%%%%%%%%%%%% Other Info. %%%%%%%%
There are two scripts: Manager.was and Worker.was and one
launcher.inc file.
The Manager provies the GUI and #includes the launcher.inc file providing the required parameters when it calls launcher().
Manager and Worker can be customized as a set. The Manager could include custom entries in the .ini file used by the Worker.
The launcher.inc file contains the launcher() proc:
proc launcher
param string script ;name of Worker.was file.
param string selectedListPath
param string iniPath
param integer selectedListSize
param integer numWorkersReq ;How many simultaneous workers to launch.
Launcher.inc should not need to be changed when the Manager/Worker set are customized.
Having multiple workers writing to one text file caused partial writes and overwrites which lead me to try writing to the .ini file. I think this works well because .ini writes happen one at a time and, possibly, are queued. It's too bad there are not more .ini related Aspect commands.
%%%%
Well, if you want to launch and manage multiple Procomm sessions, I hope this info is useful.
Craig
