Defining Command Propagation Facility (CPF) Journal Files, CPF RECVCMDS File, and CPFNODES In NDT
search cancel

Defining Command Propagation Facility (CPF) Journal Files, CPF RECVCMDS File, and CPFNODES In NDT

book

Article ID: 26050

calendar_today

Updated On:

Products

Cleanup Datacom DATACOM - AD CIS COMMON SERVICES FOR Z/OS 90S SERVICES DATABASE MANAGEMENT SOLUTIONS FOR DB2 FOR Z/OS COMMON PRODUCT SERVICES COMPONENT Common Services CA ECOMETER SERVER COMPONENT FOC Easytrieve Report Generator for Common Services INFOCAI MAINTENANCE IPC UNICENTER JCLCHECK COMMON COMPONENT Mainframe VM Product Manager CHORUS SOFTWARE MANAGER CA ON DEMAND PORTAL CA Service Desk Manager - Unified Self Service PAM CLIENT FOR LINUX ON MAINFRAME MAINFRAME CONNECTOR FOR LINUX ON MAINFRAME GRAPHICAL MANAGEMENT INTERFACE WEB ADMINISTRATOR FOR TOP SECRET Xpertware Top Secret Top Secret - LDAP Top Secret - VSE

Issue/Introduction

Question:

How do we define our CPFNODES to the NDT? How do we setup the CPF journal and receive commands files?

Answer:

There are 2 steps to putting the CPF definitions in the NDT.

  1. Define the CPF control options for that system using:

    TSS ADD(NDT) CPFSYSID(ssssssss) CPFTARGET(tttttttt) CPFWAIT(xxx) CPFRCVUND(xxx) RECVCMDS(xxx) RECVDSN(dddddddd)

    where:

    CPFSYSID(systemid) is the system name where global options are applicable.
    CPFTARGET(*| LOCAL AUTO) is the default value for the TSS command TARGET keyword. The default is LOCAL.
    CPFWAIT(YES| NO ) is the default value for the TSS command WAIT keyword. The default is NO.
    CPFRCVUND(YES| NO ) indicates whether the local node can receive commands from undefined nodes. The default is NO.
    RECVCMDS( YES |NO) specifies that the activity for propagated commands received from remote nodes are logged to a sysout file. The default is YES.
    RECVDSN(dsname) specifies a data set that is used to hold log data when RECVCMDS(YES) is in effect.

  2. Define the CPF node definitions for that system using:

    TSS ADD(NDT) CPFNODE(nnnnnnnn) CPFSYSID(ssssssss) ACTIVE(xxx) RECEIVE(xxxx) SEND(xxxx) GATEWAY(xxx) BROADCAST(xxx)
    JOURNAL(xxx) JOURNALDSN(dddddddd)

    CPFNODE(node name) is the CPF node name (1-8 characters).

    CPFSYSID(systemid) is the system name where this node definition is applicable. If not specified, the CPF node definition is used on all systems that share the security file.

    ACTIVE( YES |NO) specifies whether the nodes is available to send/receive commands and passwords. The default is YES.

    RECEIVE( ALL |NONE) specifies if the local node can receive commands from that remote node. The default is ALL.

    SEND( ALL |CMD|PWD|NONE) specifies if the local node can send commands to that node. The default is ALL. 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.

    GATEWAY(YES| NO ) specifies a node to act as a CPF gateway or CPF server for another node. The default is NO.

    BROADCAST( YES |NO) specifies that a node is valid to receive password and command changes that are sent to all nodes via TARGET(*) or the CPFTARGET(*) control option. The default is YES. If NO is specified then changes will only be sent when there are DEFNODES associated with the ACID or a node name is specified with the TARGET keyword.

    JOURNAL( YES |NO) specifies that the activity for a CPF node is logged to a journal file. The default is YES and the log data is written to a SYSOUT file. If SEND(NO) is in effect, nothing will be written to the journal. Although JOURNAL(YES) is defined, a journal file is not allocated or opened and the status indicates that NOSPOOL is currently in effect. If you modify the SEND attribute to anything other than NO and REFRESH the NODE, the journal is opened and the status indicates SPOOL.

    JOURNALDSN(dsname) specifies a data set that is to be used as a logging file when JOURNAL(YES) is in effect.

    With this step, the CPFNODE is the node being connected to and the CPFSYSID is the system for which this definition is to be used.

    Some things to be aware of:
    • CPF definitions in the NDT override what is in the CA Top Secret parameter file.

    • The CPFSYSID must be defined before the CPFNODE definitions can be made in the NDT. CPFSYSID is the system where the definition is being made.

    • CPFSYSID and CPFNODE can not be the same. CPFSYSID is the system for which this definition is to be used. CPFNODE is the node being connected to.

    • You can list the node information in the NDT using the following:

      TSS LIST(NDT) CPFSYSID(*)
      TSS LIST(NDT) CPFSYSID(xxx) where 'xxx' is a specific sysid
      TSS LIST(NDT) DATA(CPF) (this the same as CPFSYSID(*) )
      TSS LIST(NDT) CPFSYSID(xxx) CPFNODE(yyy) where 'yyy' is a specific node

    • TSS MODIFY(CPF(REFRESH)) refreshes the entire CPF subtask and is required any of the global options for CPFSYSID are changed. This is also the command to be used to refresh the nodes after JES is up to get the CPF sysout files allocated when starting CA Top Secret prior to JES.

      The CPF journal files and RECVCMDS file are informational. The journal files provide an historical record of the command traffic to and from CA Top Secret. The RECVCMDS file is used to record incoming traffic. It is recommended that SYSOUT files be used for these rather than DASD datasets because if using datasets, a SB37 abend will occur when the dataset becomes full.


Additional Information:

Please refer to the CA Top Secret Command Functions Guide for more details about the NDT.

Please refer to the CA Top Secret User Guide for more details about CPF.

Environment

Release: TOPSEC00200-15-Top Secret-Security
Component: