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
which, for any appropriately defined job, enables current activities to be
displayed in the
Current
Activity Displays option of the
SYSCOR Natural
application.
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 an area size is specified, then a dataspace name must 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 – 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 configuring the daemon to use shared memory and configuring the clients to use daemon latency.
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.
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, this will incur a performance overhead 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 configuring the daemon group as multi-system, with a daemon member using shared memory present in each system where a CICSPlex member is active, and a Sysplex Cache Structure shared by all daemon group members.
CICS regions that form a CICSplex must be defined within a service configured using the CICS (DTR) client runtime control job-type, with the client runtime controls "Latency – Daemon (Y/N)" set to Y and "Enable CICSplex DTR" set to Y.
The daemon group will then coordinate the management of the client context each time the client "jumps".
The daemon group should be defined to be a multi-system image group:
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.
Command ==>
PF1 Help PF3 Exit PF5 Upd PF9 More
|
PF9 shows more parameters for the System Coordinator Group:
17:26:10 Additional Group Parameters 2025-07-24
System Coordinator Groups C11230M2
Messages - daemon...... Console: Y and/or DDMSG file: N
Messages - databases... Console: Y and/or DDMSG file: N
Full crash recovery disk file (Y/N): N
Sysplex Cache Structure Name: RDU_CACHE2______
Command ==>
PF3 Quit PF5 Upd
|
A Sysplex Cache Structure Name should be provided.
The cache structure should already be created and sized based on the following calculation:
Size of cache (k) = (Max no. of concurrent CICS terminal sessions in all CICSplex’s)/4
The daemon members 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.
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, this will incur a performance overhead 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).: N (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 Enable CICSplex DTR....: Y (Y/N)
to disk........: N
Activity pulse every.....: _______ commands or _____ seconds
Group name...............: WORKSHOP Daemon connection messages (Y/N): N
Environment..............: ________ Level....................: ________
Read CORIN file (Y/N)....: N Review.: N Client Monitor.: N
and ensure the daemon group name is specified and "Enable CICSplex DTR" is set to Y.