The following features are new for version 7.4.2.
Adabas System Coordinator version 7.4.2 includes additional services and is a prerequisite for Adabas Transaction Manager versions 7.4 and 7.5.
Adabas System Coordinator manages the interface between the add-on
products and Adabas. It supports the latest versions of Adabas, including the
new Parallel Services (CLUSTER=LOCAL) nucleus type.
An inactivity timeout limit can now be specified in the job parameter definition for a job. When any user becomes inactive for longer than the limit, Adabas System Coordinator will perform garbage collection for the session. User session memory will be reclaimed. If the same user subsequently re-activates, the next Adabas command sent by the user session will be rejected with a timeout response (response code 9, subcode 79). If desired, a time limit can be specified, after which the response 9 will be discarded, and any terminal re-activation will be handled as a new session. Also, the response 9 can be completely suppressed, if desired.
For multiuser TP jobs (CICS, IMS/DC, etc.), separate inactivity timeout limits can be specified for terminal users and background tasks. Normally, timeout is not required for background tasks because they are of short duration, but a timeout value can be specified for long-running background tasks if required.
Initial timeout limits can be dynamically changed for a running job. This new feature is provided from the Adabas System Coordinator Online Services (SYSCOR) Special Services menu.
One of the functions of the Adabas System Coordinator daemon is to maintain shared memory pools for client jobs that require the dynamic transaction routing (DTR) capability. When DTR occurs the client session information must be located in shared memory to make it available to the target region or system.
Adabas System Coordinator has been enhanced to preserve current shared pools on a daemon failure, and automatically recover them to the daemon when it is restarted.
The pool recovery feature can be selected with the
Automatic Pool
Recovery parameter in the Coordinator Group definition.
By default the feature is active.
This feature provides automatic retry of Adabas commands that complete with a specified response and subresponse code. The command is retried a specified number of times, until a zero response code is received. The calling application will receive only the successful response.
Up to five response codes can be specified for a job in the configuration file job parameters. The number of retries can be limited and/or restricted to a specific database and file number. A time delay between retries can also be specified.
This feature can be used, for example, to retry a command when a database is inactive (response 148). The calling application could be made to wait for the database to be activated, instead of failing the request. It can also be requested that an operator message is to be issued whenever a retry is attempted. The message is issued once for each command that is retried.
This feature can be activated using the Adabas Systen Coordinator Online Services (SYSCOR) Add Job Parameters function.
This feature can be used to diagnose problems with Adabas commands. It provides a dump of memory areas when a command ends with a specific response code and subcode. Adabas System Coordinator will dump the Adabas control blocks for the command. The debug request can also be restricted to a specific database and file number.
This feature can be activated using the Adabas Systen Coordinator Online Services (SYSCOR) Add Job Parameters function.
Parameters for client jobs are saved in the configuration file. If the
file is not active when the job starts, the job will run with default
parameters. If this is not appropriate for your requirements, you can specify
that jobs must wait for system file activation. This is done by specifying the
parameter SFERR=WAIT in the assembly of the
configuration module (CORCFG).
Adabas System coordinator daemon tasks also need to read the configuration file. Previously, the daemon task would terminate if the file was not active. This has been changed; the daemon will now issue a message (CORD46I), and wait for activation. Activation is attempted every 60 seconds. If the file is still unavailable after 60 attempts, the daemon task is terminated.
The System Coordinator Daemon (SYSCO) now provides a central file store facility. This is used by add-on products as a central file store that is related to a System Coordinator Group. For example, Adabas Transaction Manager (ATM) uses a SYSCO file to hold Migrated Transaction Records (MTRs) for global transactions whose owners migrate across different system images.
