Skip to content
CA Top Secret® for z/OS - 16.0
Documentation powered by DocOps

Define a CPF Node in the NDT Record

Last update May 17, 2016

You can define CPF nodes in the NDT record in the CA Top Secret security file. CPF nodes are grouped on the NDT record by system ID to allow multiple CA Top Secret systems to use separate CPF node definitions. The system ID entry contains the global system defaults for CPF processing.

CA Top Secret supports defining CPF nodes by using the CPFNODES control option. After a CPF node is defined to the NDT record, a control option definition for the same node name is ignored. When a node is defined by using the parmlib CPFNODE method, the word STATIC appears during the issuance of a TSS MODI STATUS(CPF) command.

Note: CPF node definitions can be created or modified in the NDT record at any time after CA Top Secret starts. The START and REFRESH commands activate newly defined CPF nodes or apply new processing options to existing active CPF nodes. When refreshing an individual node, CPF processing for other nodes is not interrupted.


When the NDT has a CPFSYSID entry for the local system, the following parmfile control options are ignored:


Follow these steps:

  1. Administer the system ID definition:

    TSS ADD(NDT)	CPFSYSID(system_id)
    • CPFSYSID(system_id)
      Specifies the system name where global options are applicable.
      Specifies the default value for the TARGET keyword of the TSS command. This keyword specifies which nodes receive commands.
      • *
        Propagates commands to all nodes defined as send-only or send/receive in the CPFNODES control option.
      • LOCAL
        Propagates commands to a particular local node.
      • AUTO
        Propagates a command to nodes identified by the ACID's DEFNODES (if a target node is not explicitly identified on a command).
      Default: LOCAL
      Specifies the default value for the WAIT keyword of the TSS command:
      • YES
        Processes commands on a synchronous basis (which requires users to wait for the commands to complete on specified nodes before the local command completes).
      • NO
        Processes commands on an asynchronous basis (which does not require a response from each node to resume processing).
      Note: The CPFWAIT control option can be overridden by the WAIT value on an individual TSS command.

      Default: NO

      Specifies whether the local node can receive commands from undefined nodes.
      Default: NO
      Specifies whether CPF allows routing of LIST(ACIDS) and WHOHAS FACILITY commands to more than a single node.
      Default: NO
      Specifies whether CPF transmits a TSS command with an assigned UID value (instead of the ? value).
      Default: NO
      Specifies whether CPF transmits a TSS command with an assigned GID value (instead of the ? value).
      Default: NO
      Specifies whether activity for propagated commands that are received from remote nodes is logged to a SYSOUT file.
      Default: YES
    • RECVDSN(dsname)
      Specifies a data set that is used to hold log data when RECVCMDS(YES) is in effect.
  2. Administer the node definition:

    TSS ADD(NDT)	CPFNODE(node_name)
    • CPFNODE(node_name)
      Specifies a one-to-eight character CPF node name.
    • CPFSYSID(system_id)
      Specifies the system name where this node definition is applicable. If you do not specify a name, the CPF node definition is used on all systems that share the security file.
      Specifies whether the node is available to send or receive commands and passwords.
      Default: YES
      Specifies whether the local node can receive commands from the remote node.
      Default: ALL
      Specifies whether the local node can send all commands to the node specified by CPFNODE. CMD indicates that only administrative command changes are sent to that node. PWD indicates that only password changes and suspensions are sent to that node.
      Default: ALL
      Specifies whether the node can act as a CPF gateway or CPF server for another node.
      Default: NO
      Specifies whether the node is valid to receive password and command changes that are sent to all nodes through TARGET(*) or the CPFTARGET(*) control option. If NO is specified, changes are sent only when DEFNODES are associated with the ACID or a node name is specified with the TARGET keyword.
      Default: YES
      Specifies whether CPF node activity is logged to a SYSOUT file. If SEND(NONE) is in effect, nothing is written to the journal. If you modify the SEND attribute to any value other than NONE (and refresh the node), the journal is opened.
      Default: YES
    • JOURNALDSN(dsname)
      Specifies a data set to use as a logging file when JOURNAL(YES) is in effect.
  3. Activate the newly defined CPF node:

    S TSS

    Your definition is complete.

Example: Define a CPF Node

This example sets up the NDT CPFNODE definitions for system SYS1 to allow the following activities:

  • Sending CPF commands and passwords to remote system SYS2
  • Receiving CPF commands and passwords from SYS2

Example: Define a New System

This example defines a new system:


Example: Define a Node

This example defines a node:


Example: Remove a Node Definition

This example removes a node definition:


Example: List the CPF Node Definitions

This example lists the CPF node definitions:

TSS LIST(NDT) CPFNODE(nnnnnnnn) CPFSYSID(ssssssss)

Example: List All Nodes for All Systems

This example lists all nodes for all systems:


CPF (ON) and CPF (OFF)

If all CPF related control options are migrated from the control options parameter file to the NDT, control option CPF(ON) or CPF(OFF) is required in the parameters file for CPF to initialize using the NDT based definition. If neither is specified, CPF will not initialize and cannot be activated unless CA Top Secret is recycled. CPF(ON) activates CPF as soon as CA Top Secret is started up. CPF(OFF) starts CA Top Secret with CPF inactive. CPF is activated with TSS MODIFY(CPF(ON)).

Adding a new CPF node to an active CA Top Secret system requires adding a NODE definition to CAICCI.

CPF in a SYSPLEX Environment

CAICCI allow you to define two or more CAICCI sysids as parts of a sysplex. CA Top Secret systems residing on these hosts can be collectively targeted by their common SYSPLEXID to allow CAICCI to distribute the workload.

When setting up the CPF node definitions on CA Top Secret systems outside the CAICCI sysplex, only a single CPFNODE definition using the generic CAICCI SYSPLEXID is required. Commands are transmitted into the SYSPLEX using the generic name as the target node. CAICCI forwards the commands to any available CA Top Secret system within the SYSPLEX.

Administrative Authority

Security Administrator authority and scope are verified at the sending and target nodes before a command is applied to the targeted security files. To enter TSS commands with a targeted destination, you need MISC2(TARGET) authority.

The CPF allows the security administrator to view the contents of security files in remote nodes. This is secure since scope is verified at both locations and the data is encrypted between nodes.

Propagated administration commands execute on the remote system using the authority and scope of the user as defined on the remote system, and not from the originating system. For example, if a user who is defined as an SCA on one system propagates a TSS command to a system where that user is defined only as a USER, then the command is limited to the USER authority.

User initiated (versus administrator initiated) password changes propagated through CPF cause the user's password to change at each node where the change is sent, provided that the user's existing passwords are the same. The password will not change at nodes where the existing passwords are not identical or are not synchronized. This prevents one user from changing the password of an identically named ACID on another node used by another person.

Was this helpful?

Please log in to post comments.