Ensure your systems are properly configured for remote promotions. Because remote promotion generates several layers of nested transactions, there must be at least six peer servers available for each user that is involved with the remote promotion.
Remote promotions require that each node must be configured with the necessary table entries. At the node where you are administering promotions, you must specify:
The following example uses two nodes called LONDON and CHICAGO. If promotions are submitted at LONDON and administered remotely at CHICAGO, the CHICAGO node would require the following table entries for promotions to be possible at both nodes:
If you also want to administer promotions from the LONDON node, the LONDON node would require the exact same entries as the CHICAGO node above.
In z/OS, nodes must have the @SCHEDULEMODEL('MVS','PROM_ALLOC') member customized on each node where promotions are administered, unless data set allocation is done outside TIBCO Object Service Broker. If you are doing batch promotions, other members of @SCHEDULEMODEL are also required.
A backup file is allocated for each table instance of @PROM_BACKUPDS that has an entry with the promotion’s source node as the primary key. Another backup file is allocated for a copy of the promotion based on the entry in @PROM_CONSTANTS that has the promotion’s source node as the primary key.
In environments where files do not need to be pre-allocated (that is, Windows and Solaris), set the value of the
ALLOC_DATASET field to N. The promotion step to allocate data sets ignores any table entries where ALLOC_DATASET=N.