Version 14.0 › CA Datacom Tools Products › New Features and Enhancements › XCF_FROM New MUF Startup Option and Console-Like Command

XCF_FROM New MUF Startup Option and Console-Like Command

The XCF_FROM startup option and console-like command replaces the options: XCFFROM and X_XCFFROM_JOB.

XCF_FROM can be entered at MUF startup or as a command while MUF is executing to define permissible origins for XCF requests to MUF.

Multiple occurrences of XCF_FROM are permitted in the startup parameters. New connections are evaluated against existing XCF_FROM occurrences so that the most specific values are evaluated first, and the most generic are evaluated last. You are responsible for ensuring that the entries form a logical set.

For more information, see the CA Datacom/DB Database and System Administration Guide.

Related External Security Changes

Related to the use of XCF_FROM, XCF External Security changed in the following two ways:

• When security is checked
• What error is produced when an XCF connection is blocked by security

At MUF startup, cxxname.XCF is checked, as it always has been, to determine if XCF connectivity is externally secured, as described in the CA Datacom Security Reference Guide. But only that one XCF security resource is checked at startup.

Individual XCF remote connections are checked when a remote job opens a URT, which in turn initiates a connection to MUF through XCF (if XCF is externally secured). The check has the same format as in Version 12.0: cxxname.XCFFOM.from-system.groupname. It is done using the USERID submitting the MUF startup.

If access is allowed, the open continues. If access is denied, the open fails with a return code 87(003) and no connection is established.

Message DB00205E (error 1081) Removed

Related to the change in XCF security, message DB00205E (error 1081), can no longer occur because XCF security is no longer checked at startup.

Mainframe 2.0 Serviceability

Standardizing CA Product Active and Heartbeat Events

CA Datacom attempts to connect to OPS/MVS when running in z/OS. It sets the STATE of a specific instance to one of four states:

• STARTING indicates the MUF has determined it to be starting and is the only one doing so with the specific MUF name.
• UP is the point where it starts accepting requests.
• STOPPING indicates that an EOJ is committed.
• DOWN occurs before it releases its hold on the MUF name.

Note: If you are using CA Datacom/DB, the short product name for CA Datacom MUF is CADTCMDB , CADTCMAD if you are usingCA Datacom/AD, and CADCMMSM if you are using CA Datacom MSM.

To fit common standards, it has no state change relating to EOJ requested but not committed. This situation is rare and subject to removing the EOJ. If an error is generated with the OPS/MVS communication, the following message is issued and the error is ignored by MUF:

DB00284W - CA OPS/MVS API error return code nn, reason code nn.

For more information about messages, see the CA Datacom/DB Message Reference Guide.

CA OPS/MVS Heartbeat

Approximately every two minutes, MUF issues a CA OPS/MVS heartbeat notification. It provides a 'status' of NORMAL and 'reason' of blank for all conditions other than the following special cases:

• A status of PROBLEM and a reason of TERMINATION IN PROCESS if the MUF has recognized that it is failing and in the process of being terminated.
• A status of NORMAL and a reason of EOJ REQUESTED, NOT COMMITTED if an EOJ has been requested but is not yet committed to occur. An EOJOFF is allowed at this time.
• A status of NORMAL and a reason of EOJ COMMITTED if an EOJ has been requested and is now committed to occur. An EOJOFF is no longer valid.

You can receive a CA OPS/MVS message such as:

OPSLOGSV CAHEARTBT DBDVM

applid:CADTCMDB

version: 14.0

level:DBDVM01

status: Normal

reason:

In this message, DBDVM0 is the MUF job name, CADTCMDB is the short product name, 14.0 is the version, DBDVM01 is the MUF name, and NORMAL is the status.