A daemon is required for Adabas Fastpath and Adabas Transaction Manager and is optional for Adabas SAF Security. There are other reasons for using a daemon:
As you will see, the daemon is a critical component and a failure can have a serious effect on the whole system. You can prevent a daemon failure by configuring your daemon jobs to use continuous operation.
You can define jobs to send activity pulses to their local daemon, enabling current activities to be displayed for any appropriately defined job.
Single-seat current activity displays are only possible if the daemon is defined to use shared memory:
Run-mode: Daemon (node 2650)
Group: WORKSHOP Daemon: ICFDCOR5 SVC: 254 Node: 2650 System: Multi
Recovery
Continuous Operation (Y/N).......: Y
Daemon latency/pulse services
Shared memory area size (k)......: 100000 Minimum (k): 0_______
Dataspace name (if used)..: #COR5DSP
Here we specify that a 100 megabyte dataspace is to be used. If no dataspace name is specified, the memory is taken from ECSA for z/OS, ESVA for z/VSE or the specified common memory pool for BS2000. When using ECSA or ESVA a minimum size may also be specified.
The shared memory area size required is dependent on a number of
factors: the products you have installed, the work profile of your
applications, the number of sessions. As a rule of thumb, start off at 2k per
session and monitor shared memory usage with the
DRES daemon operator command.
If a session is unable to allocate shared memory, it will operate as normal but you will not be able to view its current activities.
You must also specify that activity pulsing is required in the client runtime controls of each job:
Activity pulse every.....: 5000___ commands or 60___ seconds Group name...............: WORKSHOP Daemon connection messages (Y/N): N
The above controls define how frequently sessions in the job should update their shared memory area (in this example every 5000 commands or 60 seconds) and also the group name of the local daemon to which activity pulses will be sent.
Adabas System Coordinator and its associated products need to maintain context information about client sessions. In some systems – UTM, IMS and CICS/MRO - client sessions can "jump" from one job to another and Adabas System Coordinator must ensure that the context information “jumps” with them. This is achieved by using daemon latency. This means that the daemon holds the context information for all sessions – either in daemon local memory, shared memory or on the COLAT disk file. For optimum performance and recoverability, Software AG recommends the use of shared memory and continuous operation.
The daemon should be defined to use continuous operation and shared memory:
Run-mode: Daemon (node 2650)
Group: WORKSHOP Daemon: ICFDCOR5 SVC: 254 Node: 2650 System: Multi
Recovery
Continuous Operation (Y/N).......: Y
Daemon latency/pulse services
Shared memory area size (k)......: 600000 Minimum (k): 0_______
Dataspace name (if used)..: #COR5DSP
Here we specify that a 600 megabyte dataspace is to be used. If no dataspace name is specified, the memory is taken from ECSA for z/OS, ESVA for z/VSE or the specified common memory pool for BS2000. When using ECSA or ESVA a minimum size may also be specified.
The shared memory area size required is dependent on a number of
factors: the products you have installed, the work profile of your
applications, the number of sessions. As a rule of thumb, start off at 50k per
session and monitor shared memory usage with the
DRES daemon operator command.
If a session is unable to allocate shared memory, the daemon will use its local memory. However, daemon local memory is not recoverable in the event of a daemon restart and so its use should be avoided if possible.
Define the job as one of the DTR types, which enforce Daemon latency:
Type: CICS (DTR) Name: WKS-DTR_
Operation: Normal autodetect: X Enable without products: _ Disable all: _
API runtime overrides....: N (Y/N) Threadsafe operation...: N (Y/N)
Use additional exits.....: N (Y/N)
Maximum idle time (sec)..: 300_______ Non-terminal idle time.: __________
Generate RSP009/79 (Y/N).: Y (until 0_________ seconds elapse)
Messages - Local.........: Console Y and/or DDMSG file _
Or - Daemon routing: _
Latency - Local (Y/N)....: N
Latency - Daemon (Y/N)...: Y
to disk........: N
Activity pulse every.....: _______ commands or _____ seconds
Group name...............: WORKSHOP Daemon connection messages (Y/N): N
and specify the group name of the daemon.
Adabas System Coordinator and its associated products need to maintain context information about client sessions. In some systems – CICSPlex for example - client sessions can “jump” from one system image to another and Adabas System Coordinator must ensure that the context information "jumps" with them. This is achieved by using a daemon in every system image together with a common daemon latency file.
The latency file must be formatted using job CORI040 and should use
Adabas device type 8390. The required file size depends on the products you
have installed, the work profile of your applications and the number of
sessions. As a rule of thumb, allocate 1 cylinder for every 10 sessions. This
latency file must be allocated (as COLAT) to each
daemon in the group.
The daemon group should be defined to use a disk file:
17:23:35 Modify 2015-02-06
System Coordinator Group C11230M1
Group Name: WORKSHOP SVC ID: 254__
System Type: _ Standard single-system image...
(Mark one) There is only one daemon in the group.
X Standard multi-system images - XCF...
This enables multiple XCF group daemons.
_ Standard multi-system images - Net-Work...
This enables multiple Net-Work group daemons.
Group wide latency service:
Full crash recovery disk file (Y/N): Y
Command ==>
PF1 Help PF3 Exit PF5 Upd PF9 More
|
The daemon should be defined to use continuous operation. Shared memory is not required for daemon latency, however you may still define it to allow activity pulsing:
Run-mode: Daemon (node 2650)
Group: WORKSHOP Daemon: ICFDCOR5 SVC: 254 Node: 2650 System: Multi
Recovery
Continuous Operation (Y/N).......: Y
Daemon latency/pulse services
Shared memory area size (k)......: 100000 Minimum (k): 0_______
Dataspace name (if used)..: #COR5DSP
Define the job as one of the DTR types, which enforce Daemon latency:
Type: CICS (DTR) Name: WKS-DTR_
Operation: Normal autodetect: X Enable without products: _ Disable all: _
API runtime overrides....: N (Y/N) Threadsafe operation...: N (Y/N)
Use additional exits.....: N (Y/N)
Maximum idle time (sec)..: 300_______ Non-terminal idle time.: __________
Generate RSP009/79 (Y/N).: Y (until 0_________ seconds elapse)
Messages - Local.........: Console Y and/or DDMSG file _
Or - Daemon routing: _
Latency - Local (Y/N)....: N
Latency - Daemon (Y/N)...: Y
to disk........: Y
Activity pulse every.....: _______ commands or _____ seconds
Group name...............: WORKSHOP Daemon connection messages (Y/N): N
and specify Y for "to disk" and the group name of the daemons.