Thanks for the help, Wolfgang and Sagi. Maybe I just assumed you couldn’t start more than one RPC/SRV1/CALLNAT for a given Broker node or that it would get confused and unmanageable if you did. Also guess I was thinking like jobs, STCs couldn’t have more than one of the same name executing at the same time but that is not so. I like the NTASKS idea better though and it seems more consistent with how XML RPC Servers seem to naturally function.
I found this in the documentation:
Natural RPC Batch Server with NTASKS >1
The main task and all replicas run in the same z/OS region or z/VSE partition.
- Use the reentrant batch link routine ADALNKR instead of ADALNK.
If you want to use ADAUSER, you must not link ADAUSER with your front-end, because ADAUSER is non-reentrant (see Item 5). Instead, use the Natural profile parameter ADANAME and set ADANAME=ADAUSER. This will cause Natural to load ADAUSER dynamically at runtime.
Note for z/VSE: If you use ADAUSER, you must rename ADALNKR to ADALNK.
- In the Natural parameter module:
Set the keyword subparameter NTASKS=n of profile parameter RPC or parameter macro NTRPC, where n is the number of parallel servers (< 100) to be started, including the main task.
Note for z/VSE: The number of subtasks is restricted by the operating system. Ask your system administrator.
Use the Natural profile parameter ETID to specify the Adabas user identification as a blank character. This is necessary to prevent a NAT3048 error (ETID not unique in Adabas nucleus) when the subtask is started.
- When using dynamic Natural profile parameters:
Use the dynamic parameter dataset CMPRMIN to pass the dynamic Natural profile parameters to Natural. Do not use the PARM card or the primary command input dataset CMSYNIN.
- When using a local buffer pool (z/OS only):
Each subtask allocates its own local buffer pool unless you specify a shared local buffer pool. See subparameter LBPNAME of profile parameter OSP or parameter macro NTOSP (in the Parameter Reference documentation).
- In the Natural front-end link job (z/OS only):
Link the front-end reentrant by using the RENT option of the linkage editor.
If the front-end were not linked with the RENT option, only the main task would start the communication with the EntireX Broker. All subtasks would be set to a WAIT status by z/OS, until the main task would have been terminated. If you would terminate the RPC server later on, the address space would hang and would have to be cancelled.
- Make sure that any other modules that are additionally linked to the Natural nucleus are reentrant. Any dynamically loaded programs must also be reentrant.
Note for z/OS: If you cannot make a module reentrant, link the module as non-reusable; this means, you should not specify the link option RENT or REUS. This is to ensure that each subtask will get its own copy.
This will get me started and make the mainframe side of this more reliable and available.