This section describes actions which must be taken prior to performing Adabas System Coordinator installation.
Adabas System Coordinator operates correctly only if the configuration file is continuously available while the client is active. Operational procedures are necessary to ensure that the database where the configuration file (or the optional alternate configuration file) resides is active
before any application opens to clients
before any TP initialization processing that involves pseudo- or real database communication
before any Coordinator daemons are started
Prior to beginning with the installation, allocate a database number and file number for the configuration file that is shared by Adabas System Coordinator, Adabas Fastpath, Adabas Vista, and Adabas Transaction Manager.
Notes:
Prior to beginning with the installation, a Node ID for each Adabas System Coordinator daemon must be allocated.
System Coordinator is activated by linking a stub module with the
LNKGBLS module. The LNKGBLS module must be re-assembled, specifying the
parameter COR=YES in the LGBLSET macro. The Coordinator
will not activate if the stub is incorrectly linked.
Note:
The LNKGBLS module is not used in BS2000 systems. The Coordinator
stub is linked with ADALNK.
Note:
Adabas client-based products are not compatible with the Adabas
DBID/SVC routing feature. If you wish to use multiple SVCs in the same client
job you should implement the COR versioning feature instead.
The Coordinator client component is activated by binding a stub module to the Client Adabas Link Module (ADALNK or other). This stub module is for use in client environments only. In previous versions it has been a documented restriction that the ADALNK module used by the COR daemon and Adabas servers must not contain the COR client stub. This remains the recommended procedure. However, in this version COR will auto-detect and bypass invalid client stub invocation in the COR daemon and Adabas servers.
You must still ensure that you use an unmodified ADALNK in Adabas utility and Entire Net-Work jobs.
Your site may attach user exits to the Adabas Link module such as LUEXIT1/UEXITB and LUEXIT2/UEXITA. These exits will see Adabas command traffic in a form that is (mostly) unaffected by products such as Adabas Vista, Fastpath, etc. However, some sites have a need for exits to see Adabas command traffic in its modified form. If your site needs to see this then you can use some special purpose exits to achieve it:
IEXIT1 receives control after a command has been adjusted by products such as Vista but before the command is passed through the Adabas router.
IEXIT2 receives control after a command has been completely processed through the Adabas router and before the command result is processed by the after-processing of products such as Vista.
These exits must use CSECT names IEXIT1 and IEXIT2. They receive control in 31-bit addressing mode, they must be re-entrant and should specify AMODE 31, RMODE ANY.
The exits are linked with the COR stub and the link module by adding link-edit INCLUDE statements to the relevant COR link job. In addition to linking the exits a specific step is needed to activate for each client job (so you are able to choose which jobs they are used with and which ones they are not). In the System Coordinator Runtime Controls panel set Use additional exits to Y. See the section Maintain Client Runtime Controls in the Online Services documentation for further information.
At entry to the exit(s), the registers contain the following:
| Register | Contents |
|---|---|
| 1 | Address of the UB. |
| 2 | Address of an 18-word save area (CICS environments) |
| 13 | Address of an 18-word save area (non-CICS environments) |
| 14 | Return address |
| 15 | Entry point address: IEXIT1 or IEXIT2 |
Any registers except register 15 that are modified by the user exits must be saved and restored. On return from IEXIT1/2 register 15 must be set to zero.
Note:
IEXIT1/2 can be mixed with LUEXIT1/UEXITB, LUEXIT2/UEXITA.
