Considerations and Configuration for using a Daemon

#### Search Results

Search

# Considerations and Configuration for using a Daemon

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:

- Single-seat current activity displays

- Single-system dynamic transaction routing

- Multi-system dynamic transaction routing

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.

## Single-seat current activity displays

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.

- Daemon configuration

- Client configuration

### Daemon configuration

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.

### Client configuration

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.

## Single-system dynamic transaction routing

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.

- Daemon configuration

- Client configuration

### Daemon configuration

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.

### Client configuration

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.

## Multi-system dynamic transaction routing

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".

- Daemon configuration

- Client configuration

### Daemon configuration

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.

### Client configuration

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.

### On this page

- Single-seat current activity displays
- Single-system dynamic transaction routing
- Multi-system dynamic transaction routing