Kbase P97313: How to run internal procedures in the server side for a Dynamics Manager or PLIP
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
11/1/2005 |
|
Status: Unverified
GOAL:
How to run internal procedures in the server side for a Dynamics Manager or PLIP
GOAL:
What are the parameters for dynlaunch.i
FACT(s) (Environment):
Dynamics 2.1x
OpenEdge 10.0B
FIX:
The dynlaunch.i include file provides the simplest and easiest way to invoke the Progress Dynamics Call Wrapper. Progress Software Corporation recommends that you use dynlaunch.i when using an AppServer where the procedure handle is not needed after the call.
dynlaunch.i accepts a temp-table of call information, constructs the call using this information and then invokes the call. Although using dynlaunch.i is the simplest way to invoke the call wrapper, the performance overhead is greater than when invoking the call wrapper using the single-entry point or at the API level. Therefore, Progress Software Corporation recommends that you use dynlaunch.i as follows:
* When making calls across the AppServer and the benefits of reduced AppServer calls and an unbound connection outweigh the disadvantage of the overhead associated with the dynamic call.
* When call parameters are only known at run time.
dynlaunch.i supports calls to an internal procedure inside a server-side procedure that might or might not already be running. When you invoke the dynamics call wrapper using dynlaunch.i, it handles all of the following in a single AppServer call:
* Identifies whether the external procedure is already running on the server and starts the procedure if it is not running.
* Runs the internal procedure inside the server-side persistent procedure.
* Gets back the OUTPUT parameters from the internal procedure call.
* Deletes the server-side procedure if it was started just for this call.
The following list the include file arguments for dynlaunch.i:
* &PLIP ? Named argument that names the external procedure needed on the server. Alternatively, it can be the logical name (the Manager Type name) of any registered Progress Dynamics? Manager, including a newly created manager.
* &Iproc ? Named argument that names the internal procedure to run.
* &clearHandlen ? Deletes the TABLE-HANDLE or BUFFER after the call completes.
* &Define-only ? If set to Yes, you can define the variables that you need that require no action.
There must also be three named arguments for each parameter in the internal procedure?s calling sequence. For each argument, the n represents the order of the parameter in the call:
* &moden ? Named argument is INPUT, OUTPUT, or INPUT-OUTPUT.
* &parmn ? Named argument that names the variable or table field storing the parameter.
* &datatypen ? Named argument that holds the data type of the parameter.