The following features are new for Version 8.1:
Support for Adabas SQL Gateway Running with RACF Security (z/Os)
New Link Module Stubs and Control Module for Triggers and Stored Procedures
Adabas System Coordinator supports the extended Adabas control block (ACBX) and the new Adabas Buffer Description (ABD) command structures.
Adabas System Coordinator supports calls made with ACBX or ACB structures to Adabas Version 8 databases, and calls made with ACB structures to Adabas Version 7 databases. In both cases, the Version 8 System Coordinator components (ADAPOx modules) must be present in the target database.
The Adabas SQL Gateway can (optionally) be installed with RACF-security enabled. This requires APF authorization and re-entrant operation which has additional installation considerations for products based upon Adabas System Coordinator. This operation mode is now supported via a new reentrant Coordinator Link module stub (CORLNKR).
New link module stubs are provided for enhanced support of Triggers and Stored Procedures. You may now link the stubs (CORS08 for z/OS, CORS18 for z/Vse) directly with the same ADALNK module used by the Adabas nucleus.
Additionally for z/Os and z/Vse implementations, a new control module (CORTSP) provides better management of COR client sessions running in TSP subtasks. CORTSP runs in its own subtask and manages initialization of the COR client environmnent. This gives:
Virtual memory reduction. All TSP subtasks share the same COR client environment.
Enhanced abend protection. A session abend in one subtask should not affect concurrent units of work in other subtasks.
Session monitoring capability. The SYSCOR online application can be used to view session and memory usage information for TSP sessions.
Adabas System Coordinator can be installed in all client jobs, but will remain inactive until a runtime control is defined for the job. This enables an installation to deploy System Coordinator and add-on products in advance of their actual use in a job. It also enables the use of a common library-set between jobs that use add-on services and those that do not.
Adabas System Coordinator allows configuration by runtime controls (previously called Job Parameters) through the SYSCOR administration tool.
Additionally there is increasing need for Adabas client sessions to operate differently within the same job. For example:
Client ABC in CICSXYZ needs special tracing controls to be in use, all other clients do not
Transaction D412 in CICSXYZ must be able to operate with a lower timeout limit than other transactions
Stepname S0010 in job PRODA032 must be excluded from using the Adabas System Coordinator
Adabas System Coordinator Version 8.1 allows these configuration controls to be prescribed in advance by adding optional override controls to the original base job level controls.
For example, Transaction overrides can be defined for a TP monitor job. As a terminal operator moves from one transaction to another the runtime behaviors will alter dynamically according to what is prescribed in the override control.
In addition to being able to pre-set the different configurations to be adopted at runtime it is also now possible to dynamically change the runtime controls for your "current" session. So, you may decide to switch tracing on or off, for example, regardless of what is prescribed in the configuration file.
You can store your own site information (variable data) in the configuration file. You can enter this along with client runtime controls. The use of this information is completely open to you. For example, for your own documentation notes about the associated controls. But, you may choose to make more sophisticated use of this information at runtime by using the new site information retrieval API. Up to 256 bytes can be supplied (and retrieved at runtime). For more information, refer to API To Retrieve Runtime Control Site Information.
The configuration file is now a vital part of the runtime operation. As such it can become a single point of failure. Version 8.1 now allows you to nominate an alternate configuration file. Each session will attempt to use the primary and if it is unavailable the alternate will be used if it is nominated. Once a configuration file has been identified for a session that file will continue to be the primary file for that session until it becomes unavailable, and then the other file will be used. Consequently, over time different sessions may be using different files at the same time until you forcibly cause all sessions to switchover by making one or the other unavailable for a long period.
On first logon to the SYSCOR application, SYSCOR recognises a Version 7.4 configuration file and guides you through a conversion procedure. The old definitions will be converted and copied to a new configuration file.
In Version 7.4 System Coordinator is always active when the Coordinator stub is bound to the Link Module and add-on products are detected. In Version 8.1 there is a new runtime control parameter to specify that System Coordinator should be "Always on" or "Always off" for a job:
"Always on" allows you to use Coordinator facilities (for example, automatic command retry), even when there are no active add-on products in the job.
"Always off" can be useful when you want to use the same Link module for jobs that require Add-on product services and those that do not.
In a Multi-Systems environment COR daemons may now be configured to use either Entire Net-Work or IBM Parallel Sysplex (XCF) for cross-systems communication. XCF is the recommended communications protocol, where available.
The Configuration module (CORCFG) defines the SVC, database ID and File number of the Coordinator System File. Some installations may wish to create several System Files for different application environments. Each environment therefore needs it's own CORCFG module. Previously it has been necessary to use a different Load library for each copy of CORCFG. The Configuration Module name exit now enables an installation-written exit program to override the default name for each environment. All copies of CORCFG can then be loaded into the same library.
For some installations the correct functioning of an Add-on product is critical to the whole operation. By default System Coordinator auto-detects and invokes whichever add-ons are available at job start time, and ignores those that are not present. But it is now possible to specify that a product is critical to the operation, and that database activity should not be allowed if the product is missing or not functioning. The specification is made with a macro keyword in the CORMCFG macro and assembled into the CORCFG module. To protect against the possibilty of the CORCFG module itself being unavailable, it is now possible to bind CORCFG with the Adabas Link module and the Coordinator stub.
Additionally, when Critical product support is defined the System Coordinator treats the System Configuration file as a critical component. Database activity will not be allowed if the file (or the Alternate file if specified) is not available.
The Versioning feature allows you to go through a gradual upgrade to adopt to using Version 8.1. This covers the clients and databases where this software is introduced. In TP systems a front-end to the ADALNK technology is introduced allowing (for example) ADALNK74 versus ADALNK81 to be used within the same client job. The ADALNK “path” is chosen according to transaction code (by default). This allows you to convert gradually.
A similar approach is taken for the software in Adabas target databases. You can use COR 7.4/AFP 7.4/etc in parallel to COR8.1/AFP 8/1/etc. This accomodates clients coming through the 7.4 versus 8.1 paths simultaneously.
