The following features have been enhanced for Version 8.1:
Command retry is extended to support definition of up to 15 response/sub-response combinations that will be automatically re-tried.
Messages CORI030I and CORI031I are extended to include the Adabas command code and job name.
The Event Monitor can be used to capture information about failing Adabas commands. It is useful for diagnosing problems with System Coordinator and add-on products, but can also be useful for debugging applications.
This version includes the following enhancements:
The Monitor can be started and stopped dynamically.
Monitoring can be selected for the whole job or a specific client session.
Monitoring can be automatically stopped after a specified number of events have been captured.
You can select the data areas to be captured for each event.
All monitor controls are now presented and set on a single screen.
The SYSCOR Maintenance screens now support definition of the new runtime controls, overrides and customer-specific data.
SYSCOR supports automatic conversion of Version 7.4 configuration files to Version 8.1 format.
This version includes a new "Multi-TCB" job type, together with a multi-TCB link module stub (CORS07). This is used for multi-tasking batch jobs and TP monitors running under z/OS platform.
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.
It is still necessary to ensure that an unmodified ADALNK is used in Adabas utility jobs.
The SYSCOR Maintenance screens now give additional help when defining TP services that support dynamic transaction routing (DTR). A single control for the complete service is defined first. Then, this is expanded by defining the jobs for the service – (for example, the names of the CICS regions that participate in the DTR service).
Jobs that do not require DTR services do not need to run in daemon-mode. The ‘Managed by daemon’ option has been removed for these job types.
