This section describes actions which must be taken prior to performing Adabas System Coordinator installation.

• License

• Configuration File

• Adabas System Coordinator Daemon

• Using System Coordinator With Adabas Link Modules

• Use of Unmodified ADALNK

• Use of Client-Side ADALNK User Exits with Adabas System Coordinator

---

License

The Adabas System Coordinator daemon requires an associated license file to make its services available.

The Adabas System Coordinator license file can be transferred to the mainframe in the same way as the Adabas license and made available as a load module named CORLIC. Alternatively, the license file can be referred to by a "DDLCOR" DD statement in the COR daemon’s job/started task. This is a fallback in case the CORLIC license load module cannot be loaded.

For installation information regarding the Adabas System Coordinator license file, refer to the section Installation Procedure.

For general information on Adabas licensing procedures, license check software and license files, refer to the Mainframe Product Licensing topic in the Adabas for Mainframes documentation.

Configuration File

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:

1. If an (optional) alternate configuration file is to be used, this must be allocated in a different database to the primary file.
2. It is your responsibility to ensure the alternate file has the same configuration content as the primary file. If either configuration file is modified, the equivalent change must also be made to the other configuration file. Failure to do so may lead to unpredictable results.
3. Both the primary and the alternate configuration files must be available at startup and shutdown of Coordinator daemons.

Adabas System Coordinator Daemon

Prior to beginning with the installation, a Node ID for each Adabas System Coordinator daemon must be allocated.

Using System Coordinator With Adabas Link Modules

Adabas System Coordinator is activated by linking an appropriate client component (CORSnn) 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 component is incorrectly linked.

Use of Unmodified ADALNK

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, Entire System Server, or Adabas Review Hub nuclei.

You must still ensure that you use an unmodified ADALNK in Adabas utility and Entire Net-Work jobs.

Use of Client-Side ADALNK User Exits with Adabas System Coordinator

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.