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 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 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 being present in each system where a CICSPlex member is active. Clients should be configured to use daemon latency.
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.
Group wide latency service:
Full crash recovery disk file (Y/N): N
Command ==>
PF1 Help PF3 Exit PF5 Upd PF9 More
|
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).: 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 ensure the daemon group name is specified.