advertisement
CA XCOM™ Data
Transport® for z/OS
Release Notes
Version 12.0.00
This Documentation, which includes embedded help systems and electronically distributed materials, (hereinafter referred to as the “Documentation”) is for your informational purposes only and is subject to change or withdrawal by CA at any time. This
Documentation is proprietary information of CA and may not be copied, transferred, reproduced, disclosed, modified or duplicated, in whole or in part, without the prior written consent of CA.
If you are a licensed user of the software product(s) addressed in the Documentation, you may print or otherwise make available a reasonable number of copies of the Documentation for internal use by you and your employees in connection with that software, provided that all CA copyright notices and legends are affixed to each reproduced copy.
The right to print or otherwise make available copies of the Documentation is limited to the period during which the applicable license for such software remains in full force and effect. Should the license terminate for any reason, it is your responsibility to certify in writing to CA that all copies and partial copies of the Documentation have been returned to CA or destroyed.
TO THE EXTENT PERMITTED BY APPLICABLE LAW, CA PROVIDES THIS DOCUMENTATION “AS IS” WITHOUT WARRANTY OF ANY
KIND, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE, OR NONINFRINGEMENT. IN NO EVENT WILL CA BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY LOSS OR DAMAGE,
DIRECT OR INDIRECT, FROM THE USE OF THIS DOCUMENTATION, INCLUDING WITHOUT LIMITATION, LOST PROFITS, LOST
INVESTMENT, BUSINESS INTERRUPTION, GOODWILL, OR LOST DATA, EVEN IF CA IS EXPRESSLY ADVISED IN ADVANCE OF THE
POSSIBILITY OF SUCH LOSS OR DAMAGE.
The use of any software product referenced in the Documentation is governed by the applicable license agreement and such license agreement is not modified in any way by the terms of this notice.
The manufacturer of this Documentation is CA.
Provided with “Restricted Rights.” Use, duplication or disclosure by the United States Government is subject to the restrictions set forth in FAR Sections 12.212, 52.227-14, and 52.227-19(c)(1) - (2) and DFARS Section 252.227-7014(b)(3), as applicable, or their successors.
Copyright © 2013 CA. All rights reserved. All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.
CA Technologies Product References
This document references the following CA Technologies products:
■
CA Chorus™ Software Manager (CA CSM)
■
CA Chorus™
■
CA ACF2™ (CA ACF2)
■
CA Top Secret® (CA Top Secret)
■
CA XCOM™ Data Transport® (CA XCOM Data Transport)
■
CA XCOM™ Data Transport® Management Center (CA XCOM Management Center)
Contact CA Technologies
Contact CA Support
For your convenience, CA Technologies provides one site where you can access the information that you need for your Home Office, Small Business, and Enterprise CA
Technologies products. At http://ca.com/support , you can access the following resources:
■
Online and telephone contact information for technical assistance and customer services
■
Information about user communities and forums
■
Product and documentation downloads
■
CA Support policies and guidelines
■
Other helpful resources appropriate for your product
Providing Feedback About Product Documentation
If you have comments or questions about CA Technologies product documentation, you can send a message to [email protected]
.
To provide feedback about CA Technologies product documentation, complete our short customer survey which is available on the CA Support website at http://ca.com/docs .
Contents
Chapter 1: New Features 7
Chapter 2: Enhanced Features 11
Contents 5
Chapter 3: New and Changed Messages 35
Appendix A: Known Issues 59
Appendix B: Migrating Security Settings 61
Appendix C: Deprecated or Obsolete Features 63
6 Release Notes
Chapter 1: New Features
This version of CA XCOM Data Transport for z/OS v12 supports the following new features:
■
Conversion of mainline code from non-reentrant to reentrant and LPA eligible
■
■
■
Allow the servers to be included in multiple PLEXQ systems
Ability to disable locally and/or remotely initiated transfers on servers
Ability to control which compression algorithms are permitted
■
■
■
■
■
Enhanced the ability to control compression negotiation between partners
Enhancements and more criteria for history reporting
Ability to run XCOMJOB without requiring APF authorization
Migration tools to upgrade from CA XCOM Data Transport for z/OS 11.5 and
11.6
Ability to control the dataset that is used for configuration members
■
■
■
■
ISPF Operator command sessions releases connection to server on submission of the command rather than waiting for the response
OPS/MVS Heartbeat
Perform the SSL transfers with FIPS-compliant encryption services
Infrastructure for CA XCOM Gateway
This section contains the following topics:
CA Chorus™ Software Manager (see page 7)
CA OPS/MVS System State Manager (see page 8)
Health Checks for Your Product (see page 9)
CA Chorus™ Software Manager
CA Chorus™ Software Manager (CA CSM) is an application that simplifies and unifies the management of CA Technologies mainframe products on z/OS systems.
CA CSM provides services that make it easier for you to perform the following actions:
■
Acquire, install, deploy, and configure products
■
Automatically obtain and apply maintenance
Chapter 1: New Features 7
CA OPS/MVS System State Manager
These services enable you to easily manage your software based on industry-accepted best practices. A web-based interface makes the look-and-feel of the environment friendly and familiar. This interface helps you install and maintain your products faster and with less chance of error.
You can acquire CA CSM from http://ca.com/support .
Note: For more information, see your product installation instructions and the CA CSM online help.
CA OPS/MVS System State Manager
Your product can automatically communicate active status events and heart beat events to CA OPS/MVS EMA. The communication is established through a generic active status or heartbeat event API call that CA OPS/MVS EMA provides. With this feature, other products can communicate events consistently to CA OPS/MVS EMA.
More information:
CA XCOM Data Transport for z/OS Administrator Guide.
CA XCOM Data Transport for z/OS User Guide.
8 Release Notes
Health Checks for Your Product
Health Checks for Your Product
Your product is now integrated with the IBM Health Checker for z/OS through the CA
Health Checker Common Service, and automatically checks for the following potential problems:
■
XCOM_ABOVE_16M@stcname
■
This check monitors the amount of above-the-line storage that has been allocated within the CA XCOM Data Transport address space.
XCOM_BELOW_16M@stcname
■
■
■
This check monitors the amount of below-the-line storage that has been allocated within the CA XCOM Data Transport address space.
XCOM_MAXTASK_LEVEL@stcname
This check monitors the total number of tasks that are active within the CA
XCOM Data Transport region.
XCOM_MAXLOC_LEVEL@stcname
This check monitors the number of locally-initiated tasks that are active within the CA XCOM Data Transport region.
XCOM_MAXREM_LEVEL@stcname
This check monitors the number of remotely-initiated tasks that are active within the CA XCOM Data Transport region.
Note: For more information, see the appendix "CA XCOM Data Transport Health Checks" in the CA XCOM Data Transport for z/OS Administration Guide.
Chapter 1: New Features 9
Chapter 2: Enhanced Features
This version of CA XCOM Data Transport for z/OS v12 supports the following enhanced features.
This section contains the following topics:
All Product LOAD Libraries now PDS/E (see page 13)
Shipped USS Files Now Hosted in ZFS (see page 13)
CICS Load Library PDSE (see page 13)
SSL Configuration Files ZFS Format (see page 13)
User Exits Assembled and Linked as Reentrant and Reusable (see page 13)
APF Authorization Requirements (see page 14)
Enhancements for History Reports/Queries (see page 15)
Fully Reentrant Executable Code (see page 18)
Expansion of RRDS Record (see page 19)
Expansion of History Record (see page 19)
Expansion of SMF Record (see page 19)
History Migration Utility (XCOMUTIL) (see page 20)
Request Queue Migration Utility (XCOMMIGR) (see page 21)
Integration with CA OPS/MVS (see page 21)
Support for IBM System SSL (see page 22)
Support for CA XCOM Gateway Destination Path (see page 23)
Use of SYSID and SYSNAME for Trusted Transfers (see page 23)
EXEC and Configuration Member Parameters (see page 24)
ISPF Sessions for Operator Commands (see page 24)
Default Options Enhancements (see page 25)
Support for New HISTORY Configuration Parameter Value (see page 25)
Support for New MultiPlexQ Feature (see page 26)
Restart count maintained in History and SMF records (see page 26)
PLEXQ Group Name Stored in History and SMF Records (see page 27)
Migration capability for PLEXQ groups (see page 27)
Migrating to Newer Releases using MultiPlexQ (see page 28)
Allow STC parameters in Configuration Members (see page 29)
Allow for Control of Which Compression Methods Are Used (see page 30)
Allow for Control of which Transfer Types are Processed (see page 34)
Chapter 2: Enhanced Features 11
CA CSM
CA CSM
CA Mainframe Software Manager™ (CA MSM) is renamed to CA Chorus™ Software
Manager (CA CSM) and adopts the CA Chorus look-and-feel.
CA CSM Release 5.1 lets you manage and organize tasks with policies. Use task management policies to copy, delete, and move task output. Select tasks that are based on criteria including their age and their type. Create task policies using the Task Policy wizard.
Note: For more information, see the CA Chorus Software Manager User Guide.
Documentation
This section contains topics that are related to documentation enhancements.
Technical Information Content Philosophy
The documentation set focus on the following key areas:
■
Role-based scenarios that detail steps to complete key business processes. These scenarios can appear in traditional guides and as standalone Knowledge Database articles on http://ca.com/support .
■
An end-to-end view that gives you access to content across the full lifecycle of your product, including content from technical information, product management, support, sales, services, and education. The bookshelf that is based on the end-to-end model provides you with traditional guides and links to various information sources that are related to your product.
■
Concise product content that promotes usability and accessibility.
Installation Guide
The Installation Guide has been restructured and describes the following methods of installing your product:
■
CA CSM
■
Pax-Enhanced Electronic Software Delivery (Pax ESD)
■
DVD
12 Release Notes
All Product LOAD Libraries now PDS/E
All Product LOAD Libraries now PDS/E
The CA XCOM Data Transport for z/OS v12.0 CICS Interface LOAD library is now shipped as a PDS/E. This library now aligns with the CA XCOM Data Transport base product LOAD library. The CA XCOM CICS Interface LOAD library was formerly a PDS.
Shipped USS Files Now Hosted in ZFS
The SSL configuration files are unloaded in ZFS format to the user specified USS file system. References to the data set DD name CBXGHFS become CBXGZFS.
CICS Load Library PDSE
The format of the CICS load library is in PDS/E format to align with the CA XCOM Data
Transport load library. CICS load library was formally PDS.
SSL Configuration Files ZFS Format
The SSL configuration files are unloaded in ZFS format to the user specified HFS file system. References to the data set DD name CBXGHFS becomes CBXGZFS.
User Exits Assembled and Linked as Reentrant and
Reusable
CA XCOM Data Transport runs reentrant and reusable. All user exits can be assembled and linked as reentrant and reusable so that the exits can be called from CA XCOM Data
Transport. Sample JCL member CAI.CBXGJCL(ASM#TBLS) reflects this change by changing default assemble and link options to be reentrant and reusable.
Chapter 2: Enhanced Features 13
APF Authorization Requirements
APF Authorization Requirements
Certain features of CA XCOM Data Transport require APF authorization. For this reason, all CA XCOM Data Transport server regions must run APF authorized. For XCOMJOB, APF authorization is optional if no features are used which require it. This is also true for user programs which call XCOMJOB as an API interface to CA XCOM Data Transport functions.
The features of CA XCOM Data Transport requiring APF authorization are:
■ zIIP Enablement
■
■
■
■
PLEXQ facility – uses the IBM Coupling Facility
Notification Facility
XCOMPLEX facility – uses the IBM Coupling Facility
Security interface
■
■
USS File Transfers
SAF security
Any programs that call XCOMJOB as an API and use one or more of the above-listed features, linking with link-edit parameter AC(1) is a must.
If XCOMJOB is run in a non-APF Authorized environment, and one of the features are used which require APF authorization, the job terminates with a message appropriate to the function which requires APF authorization.
Note: Including the CA XCOM Data Transport load libraries in the LPA implies APF
Authorization.
14 Release Notes
Enhancements for History Reports/Queries
Enhancements for History Reports/Queries
Status Selection Criteria for TYPE=HISTORY
TYPE=HISTORY requests now allow more refinement criteria for selection of inactive and/or completed transfers. This allows a user to select transfers for reporting based on particular status groups within the inactive and completed categories.
The status group criteria for inactive transfers are:
Held – The select transfers that are currently held.
Suspended – The select transfers that are currently suspended.
The status group criteria for completed transfers are:
Successful – The select transfers that completed successfully.
File Error – Select transfers that terminated due to a file error.
Network Error – Select transfers that terminated due to a network error.
Logic Error – The select transfers that terminated due to a logic error.
Terminated – The select transfers that terminated for any other reason.
Batch History Requests
For batch history requests, new SYSIN01 parameters have been added to allow for selection of transfers that are based on status.
OCOMPLETED
Specifies a subtype of completed transfer requests to report on. Any combination of the following values can be specified.
S - Report on completed transfers which completed successfully.
F - Report on completed transfers which terminated as a result of a file error.
L - Report on completed transfers which terminated as a result of a logic error.
N - Report on completed transfers which terminated as a result of a network error.
T - Report on completed transfers which terminated for other conditions.
Note: If this parameter is not specified, all completed transfers can be reported on when OTYPE=C or OTYPE=ALL is specified.
Chapter 2: Enhanced Features 15
Enhancements for History Reports/Queries
OINACTIVE
Specifies a subtype of inactive transfer requests to report on. Any combination of the following values can be specified.
H - Report on inactive transfers which are in a HELD status.
S - Report on inactive transfers which are in a SUSPENDED status.
Note: If this parameter is not specified, all inactive transfers can be reported on when
OTYPE=I or OTYPE=ALL is specified.
Date Range Selection for TYPE=HISTORY
TYPE=HISTORY requests now allow the capability to report only transfers that executed within a specified date/time range. That is, the transfer started at or after the specified start time and completed at or before the specified end time. The report only includes transfers that have completed (not in active or inactive status).
Batch History Requests
For batch history requests, a new SYSIN01 parameter has been added to specify how date and time range is used for selecting transfers.
OINCLUDE
OINCLUDE indicates how transfers are selected to meet the date and time range criteria.
ACTIVE
The selected transfers that are or were active within the date and time range criteria.
EXECUTED
The selected transfers that started and ended within the date and time range criteria.
STARTED
Only the transfers that started in the specified time range are reported.
COMPLETED
Only the transfers that completed in the specified time range are reported.
Default: Active
16 Release Notes
Enhancements for History Reports/Queries
PlexQ Group Name Selection for TYPE=HISTORY
TYPE=HISTORY requests now allow the capability to report only transfers that are scheduled over a specified PlexQ group.
Batch History Requests
For batch history requests, a new SYSIN01 parameter has been added to specify a filter for the name of the PLEXQ Group used to schedule transfers.
OPLEXQ
Limits the history request to only those locally initiated file transfers which were scheduled using the named PLEXQ Group.
xxxxxxxx
A one to eight character PLEXQ Group name that is used to limit the history request to only those locally initiated file transfers scheduled using the specified PLEXQ
Group.
Default: None
Note: The wildcard character, *, can be used for this parameter only when specified as the last character.
Chapter 2: Enhanced Features 17
Fully Reentrant Executable Code
ISPF Updates for History Requests
The File Transfer Display Select ISPF panel has been updated to allow selection of status groups and specification of which transfers to include.
-------------------------------------------------------------------------
13/07/24 CA XCOM Release v12.0 SP00 VUOLO01
13.205 File Transfer Display Select 08:37:47
--------------------------------------------------------------------------
COMMAND ===>
Local System Identification
Server: 141.202.65.31 Port: 9833 Protocol: TCP
Select Transfers ===> Inactive Active Completed
==> Held ==> Successful
==> Suspended ==> File Error
==> Network Error
==> Logic Error
==> Terminated
History Location ===> X Queue X Database
Limit display to transfers for the following:
History System ID ===> | History System Name ===>
Requesting User ID ===> VUOLO01 | Request Number ===>
Transfer ID ===> | Last Message ===>
Local or Remote ===> (L/R) | File Type ===> (J/R/F)
Transfer Type ===> (S/R) | Origin PLEXQ Group ===>
Remote System:
ID ===>
TCP/IP ===> (Y/N)
Include Transfers ==> E (A/E/S/C)
Range Start Date ===> 20140103 (YYYYMMDD) Time ===> 080000 (HHMMSS)
Range End Date =====> 20140103 (YYYYMMDD) Time ===> 170000 (HHMMSS)
Range File Size ====> (Min.) ===> (Max.)
Maximum Entries ===> (NNNN)
Jobname ===>
Vol ===>
Case Sensitive ===> N (Is the search on File Case Sensitive?)
File ==>
--------------------------------------------------------------------------
PFK 1/Help 3/End Copyright (c) 2013 CA. All rights reserve
Fully Reentrant Executable Code
All shipped LOAD modules are now reentrant. This means that the product LOAD libraries can be placed in the LPA for customers who run multiple CA XCOM Data
Transport for z/OS v12.0 regions within a single LPAR. This reduces the storage that is required for individual server regions by using a single LPA-resident copy of executable modules.
18 Release Notes
Expansion of RRDS Record
Expansion of RRDS Record
The RRDS record has been increased in size to 8080 bytes from 3030 in release 11.6.
This increase allows CA XCOM Data Transport to support more parameters for new features. A new RRDS VSAM Data Set must be created before using version 12.0.
Version 12.0 cannot support any existing RRDS created by a previous release of CA
XCOM Data Transport.
Expansion of History Record
The history record has been increased in size to 8080 bytes from 3030 in release 11.6.
This increase allows CA XCOM Data Transport to support storing more information for new or existing features. If you are using a VSAM data set to record history, a conversion of the data set is required to continue to use it with version 12.
Note: The expansion of the history record size has also required an increase in the entry size in the LIST STRUCTURE used by the deprecated XCOMPLEX facility. This increase in entry size can reduce the number of entries that can concurrently be in a LIST by slightly more than one half.
Expansion of SMF Record
The SMF record that CA XCOM Data Transport produced has been increased in size to
8248 bytes from 3198 in release 11.6. This increase is due to the increase in size of the
CA XCOM Data Transport history record, which is included as part of the SMF record generated.
Chapter 2: Enhanced Features 19
History Migration Utility (XCOMUTIL)
History Migration Utility (XCOMUTIL)
Modifications to the format of the VSAM history file cluster have been implemented for version 12. This can require either defining a new VSAM history file cluster or migrating an existing one. The XCOMUTIL History File utility has been modified to perform a conversion of an existing release 11.5 or 11.6 VSAM history file cluster to the new version 12 format. For more details, refer to the CA XCOM Data Transport User Guide for the description of the XCOMUTIL utility. The format changes implemented for version 12 are as follows:
■
The maximum length of the history record has been increased to 8080 bytes from 3030 in the 11.6 release and 2020 in the 11.5 release to allow for recording of more transfer information.
To use an existing VSAM history file from the 11.5 or 11.6 releases in version 12, this migration utility must be performed to create a new format history file. Some unpredictable results can occur when using an 11.5 or 11.6 format VSAM history file with 12.
Using a VSAM History file that does not have a logical record length (LRECL) of 8080 can result in the CA XCOM Data Transport server issuing a XCOMM0478E XCOMHIST
RECSIZE(xxxx) INVALID. THIS RECSIZE SHOULD BE 8080. The server can continue but history records cannot be logged.
20 Release Notes
Request Queue Migration Utility (XCOMMIGR)
Request Queue Migration Utility (XCOMMIGR)
Modifications to the format of the VSAM request queue file have been implemented for release 11.6 and version 12. In prior releases of CA XCOM Data Transport for z/OS, a new request queue file needed to be defined when installing a new release. Beginning with version 12, it can be possible to migrate an existing request queue file from a prior release of CA XCOM Data Transport for z/OS. This can allow any transfer requests that are in a request queue to be brought forward to a new release of CA XCOM Data
Transport without having to reschedule them into a new request queue. The
XCOMMIGR Request Queue Migration utility has been created to perform a conversion of an existing release 11.5 or 11.6 VSAM request queue file to the new version 12 format. For more details, refer to the CA XCOM Data Transport User Guide for the description of the XCOMMIGR utility. The format changes implemented for version 12 are as follows:
■
The maximum length of the history record has been increased to 8080 bytes from 3030 in the 11.6 release and 2020 in the 11.5 release to allow for recording of more transfer information.
To use an existing VSAM request queue file from the 11.5 or 11.6 releases in version 12, this migration utility must be performed to create a new format request queue file. If a properly formatted version 12 request queue is not supplied, the CA XCOM Data
Transport for z/OS server can terminate.
Using a VSAM request queue file that does not have a logical record length (LRECL) of
8080 can result in the CA XCOM Data Transport server issuing the message
XCOMM0288E XCOMRRDS RECSIZE(xxxx) INVALID. THIS RECSIZE SHOULD BE 8080. The server will terminate.
Integration with CA OPS/MVS
The CA XCOM Data Transport servers provide updates and heartbeat calls to CA
OPS/MVS. The CA XCOM server notifies CA OPS/MVS when it is STARTING, UP,
STOPPING, and DOWN. Additionally, a recurring call affirming the NORMAL status of the server is also made to CA OPS/MVS every time the ERRINTV number of minutes elapses.
Chapter 2: Enhanced Features 21
Support for IBM System SSL
Support for IBM System SSL
A new configuration parameter SSL_VERSION has been added to allow for the usage of
IBM System SSL in addition to the previously provided OpenSSL. Specifying
SSL_VERSION=SYSTEM causes IBM System SSL to be used, while specifying
SSL_VERSION=OPEN causes OpenSSL to be used.
The SSL_VERSION can be specified in the configuration member and overridden by the
XCOMJOB/XCOMXFER EXEC parameter. Using the DFLT operator command, you can dynamically modify the SSL_VERSION.
CA XCOM Data Transport support for IBM System SSL requires z/OS 1.13 or above.
The System SSL Configuration File
During the installation of CA XCOM Data Transport, a sample System SSL configuration file that is named SYSconfigSSL.cnf is created in the sysssl directory of the USS file system. The System SSL configuration file contains parameters that System SSL uses to configure the SSL connection between CA XCOM Data Transport partners.
For more information on the parameters that can be specified in the System SSL configuration file, see How to use the System SSL Configuration Parameters in the CA
XCOM Data Transport Administration Guide.
The Sample Certificate Conversion Script
A sample certificate conversion script that is called makesysssl is provided in the sysssl directory of the USS file system. During the installation of CA XCOM Data Transport, the makesysssl script converts the sample OpenSSL certificates (PEM files) generated by the makeca, makeclient, and makeserver scripts to PKCS12 certificate files. It then imports them into a sample System SSL certificate database.
If the makeca, makeclient and makeserver scripts are run manually after installation, the makesysssl script can also be run manually to convert the generated sample certificates for use by System SSL.
The makesysssl script can also be used to convert a PEM certificate file and corresponding PEM key file to a PKCS12 certificate file. The PKCS12 certificate file can then be imported to a System SSL certificate database using the IBM gskkyman utility.
This utility is described in the IBM Cryptographic Services System Secure Sockets Layer
Programming guide.
For more information on the actions and options that can be specified to the makesysssl script, see Converting the Sample Certificates in the CA XCOM Data Transport
Administration Guide.
22 Release Notes
Support for CA XCOM Gateway Destination Path
ISPF Transfer Request Detailed Display
The ISPF Transfer Request Detail display has been enhanced to display SSL and cipher information for the transfer. Two new fields have been added under a new SSL Details section:
SSL Version - the version of SSL used for the transfer. If System SSL was used, the value
System SSL is presented. If OpenSSL was used, the value is blank.
Cipher Suite Used – the cipher or cipher suite that is used for the System SSL transfer.
For the OpenSSL transfers, the value displays as *Not Available*.
For the OpenSSL transfers
SSL Details:
SSL Version:
Cipher Suite Used: *Not Available*
For the System SSL transfers:
SSL Details:
SSL Version: SystemSSL
Cipher Suite Used: TLS_RSA_WITH_AES_256_GCM_SHA384
Support for CA XCOM Gateway Destination Path
A new parameter GATEWAYDPATH has been added to specify the destination path that
CA XCOM Gateway uses when the remote file is a CA XCOM Gateway file. CA XCOM
Gateway makes the destination path available as symbolic parameter &GWDPATH for onward delivery.
GATEWAYDPATH can be specified in the destination member or in the SYSIN01. Its presence is checked for first in the SYSIN01 and then in the destination member.
Use of SYSID and SYSNAME for Trusted Transfers
Starting with CA XCOM Data Transport for z/OS v12, the values for configuration parameters SYSID and SYSNAME can be passed to partner systems as the system identification for trusted transfers.
In prior releases of CA XCOM Data Transport for z/OS, the SMFID and Job Name were passed to partner systems.
Chapter 2: Enhanced Features 23
EXEC and Configuration Member Parameters
EXEC and Configuration Member Parameters
If an error is detected when processing either an EXEC or Configuration member parameter, CA XCOM Data Transport terminates with a non-zero return code.
A message indicating which parameter caused termination is displayed in the XCOMINIT log.
This applies to the Server, Admin Server, Worker Server, or running XCOMJOB.
ISPF Sessions for Operator Commands
With prior releases of CA XCOM Data Transport, the ISPF screens for operator commands maintain a session with the server during processing. Maintaining these sessions reduces the number of available sessions for the server, impacting the ability to process more transfer requests. Also, if the ISPF session was open and idle, the client side can experience a session timeout.
Beginning with CA XCOM Data Transport v12.0, the session with the server will be disconnected after the requested transfer information is returned to the client session.
The client session maintains the history information for display in the panels to view detailed information for a transfer as before. This process eliminates the session timeouts on the client side and releases resources on the server.
Now, command and update requests are queued and processed upon termination of the Transfer Request Display screen using PF3. Once all commands and updates are processed, the Transfer Request Display screen is refreshed. If no commands or updates are queued, the display terminates and control is passed back to the File Transfer
Display Select screen. Any messages that are issued as a result are shown in the
XCOMLOG for the request. An XCOMLOG is generated for each request that is submitted.
24 Release Notes
Default Options Enhancements
Default Options Enhancements
CA XCOM Data Transport has a set of system parameters that govern its operation across all of its various interfaces. The CA XCOM Data Transport system parameters take effect as soon as CA XCOM Data Transport is started and, unless overridden, they remain in effect as long as CA XCOM Data Transport is active. These system parameters have historically been kept in the CA XCOM Data Transport Default Options Table. These parameters are now stored in a TYPE=CONFIG control library PDS member.
The TYPE=CONFIG members can be stored in either a PDS data set specified in the
XCOMCNTL DD concatenation or a PDS data set specified by the CONFIGDSN symbol. A new symbol CONFIGDSN controls the search order CA XCOM Data Transport uses to load the TYPE=CONFIG member. The CONFIGDSN symbol is set at the system level and must be set using the CA XCOM Data Transport CAIRIM Initialization program
(FXC0INIT).
When migrating from r11.5 or r11.6, the CA XCOM Data Transport Default Options Table can be automatically converted to a TYPE=CONFIG member. For new installations or for installations migrating from a release before r11.5, a sample TYPE=CONFIG member is provided.
See Configure the Default Options in the CA XCOM Data Transport Administration Guide for more details.
Support for New HISTORY Configuration Parameter
Value
A new value for the CONFIG member “HISTORY” parameter has been added. It is now possible to specify HISTORY=VSAMREQ. This parameter setting REQUIRES a valid
HISTORY data set in order for the server to start.
If the XCOMHIST data set does not have the correct characteristics during server startup, message XCOMM0682E is issued. The server terminates with a return code of
16. This function prevents the inadvertent execution of a CA XCOM Data Transport server without writing history records.
The default for this parameter continues to be HISTORY=VSAM which permits the server to run without a history data set.
Chapter 2: Enhanced Features 25
Support for New MultiPlexQ Feature
Support for New MultiPlexQ Feature
The CA XCOM Data Transport feature has been enhanced to provide support for a server to maintain up to eight simultaneous PLEXQ group connections.
A new PLEXQ command has been added with three new subcommands (QUERY, JOIN, and LEAVE) to manage these connections. These subcommands can respectively display all current connections to PLEXQ groups, dynamically connect to a new PLEXQ group, and dynamically disconnect from a PLEXQ group.
Up to eight PLEXQ group connections can also be automatically established during server initialization by specifying multiple PLEXQ parameter values in the configuration member or on the EXEC PARM.
Additional Commands updated for the New MultiPlexQ Feature
The following commands have been updated to allow for the specification of a PLEXQ group name as shown:
■
■
■
F XCOM,STAT,group
F XCOM,XSHOW,group
F XCOM,XRSHOW,group
The new group operand is optional and can be used to route these commands to a specific PLEXQ group. If omitted, the command is routed to each PLEXQ group to which the server is connected.
Restart count maintained in History and SMF records
The CA XCOM Data Transport feature has been enhanced to include the number of transfer restarts in the History and SMF records. This value is displayed on the ISPF
Transfer Detail panel for transfers in any status (Active, Inactive, or Completed). The sample Easytrieve report for transfer detail (XCOMEHRP) also includes the restart count.
The restart count includes error retries as well as resumption of suspended or held transfers.
26 Release Notes
PLEXQ Group Name Stored in History and SMF Records
PLEXQ Group Name Stored in History and SMF
Records
The CA XCOM Data Transport feature has been enhanced to include the PLEXQ Group name used (if applicable) to schedule a transfer. This value is only stored in the history record for the initiating (LOCAL) side of the transfer.
Migration capability for PLEXQ groups
CA XCOM Data Transport now supports running servers of mixed releases in a PLEXQ group to allow for easier migration to new releases. In this manner, servers can be updated one at a time instead of having to upgrade all servers participating in the group. This also allows job requests from different releases to access the group, so upgrading of JCL to use new releases can be performed when viable.
When scheduling the requests to the PLEXQ group, a server can be selected to process the request that does not support a specific feature requested. This can happen if the request is using a newer release than the server in the PLEXQ group which is selected. In that event, the feature would be ignored but the request is still processed.
Informational and Warning messages are issued to the log files when mixed releases are detected by servers and jobs running with PLEXQ groups.
Chapter 2: Enhanced Features 27
Migrating to Newer Releases using MultiPlexQ
Migrating to Newer Releases using MultiPlexQ
The MultiPlexQ feature facilitates release migration by allowing CA XCOM servers (v12.0 and above) to participate in more than one PLEXQ group at a time. The following diagram provides an example of such a MultiPlexQ configuration:
28 Release Notes
In this example, the blue circle represents a PLEXQ group (PLEXQ120) with a single v12.0 server. The green circle is a PLEXQ group (PLEXQALL) which encompasses all servers, with mixed release levels.
Allow STC parameters in Configuration Members
Allow STC parameters in Configuration Members
CA XCOM Data Transport now supports specification of STC parameters in configuration members. Currently the STC parameters can only be specified as EXEC parameters. This change allows you to change the CA XCOM Data Transport Server to which scheduled transfers, inquires, history, and recover requests are directed toward without having to modify JCL.
The configuration member can contain values for all STC parameters (STCIP, STCPORT,
SECURE_SCHEDULE, STCAPPL and STCPLEXQ). A new parameter, STCPROTOCOL, has been added to specify the default protocol to use for connecting to the CA XCOM Data
Transport server. These parameters can be overridden when specified in the EXEC parameter for the job.
To make the most effective use of this feature, STC parameters should not be specified as EXEC parameters. To alter the server and/or protocol to which the CA XCOM Data
Transport job communicates with, simply change the configuration member values so that JCL does not have to be modified.
Chapter 2: Enhanced Features 29
Allow for Control of Which Compression Methods Are Used
STCPROTOCOL
STCPROTOCOL specifies the started task communication protocol XCOM jobs uses when scheduling requests.
SNA
TCP
Specifies that an XCOMJOB schedules the request with the started task using SNA communications.
Specifies that the XCOMJOB schedules the request with the started task using
TCP/IP communications (non-SSL).
SSL
Specifies that the XCOMJOB schedules the request with the started task using
Secure Socket Layer (SSL) communications.
PLQ
Specifies that the XCOMJOB schedules the request with the started task using IBM
Parallel Sysplex Signaling Services. This is referred to as the PLEXQ by CA XCOM
Data Transport.
Default: Determined dynamically if STCAPPL, STCIP, STCPLEXQ, or SECURE_SCHEDULE are specified as the EXEC parameters. If more than one of these parameters is specified, the value is decided based on the following order:
■
SNA if STCAPPL is specified
■
TCP if STCIP is specified and SECURE_SCHEDULE is not specified or set to NO
■
■
SSL if STCIP is specified and SECURE_SCHEDULE=YES is specified
PLQ if STCPLEXQ is specified.
Allow for Control of Which Compression Methods Are
Used
CA XCOM Data Transport now supports a new parameter that can be used to control which compression methods the transfers are allowed use. The negotiated substitution compression method can also now be designated by way of configuration.
The parameter which controls allowed compression methods is COMPRESS_ALLOWED.
Usage of the COMPNEG parameter has been changed to allow the specification of the compression method to be substituted in the event a disallowed compression method is requested for a transfer.
30 Release Notes
Allow for Control of Which Compression Methods Are Used
COMPRESS_ALLOWED
COMPRESS_ALLOWED specifies in a list form which compression methods this invocation of XCOMJOB uses. This parameter only has meaning for TYPE=EXECUTE
XCOMJOBs.
This list is comprised of the names of specific compression methods, or groups of compression methods that ":" separate, which the server allows or disallows. The values that are used in this list can be any of the following values:
ALL
NONE
COMPACT
COMPACTL
YES
RLE
HUFFMAN
LZALL
LZLARGE
LZMEDIUM
LZSMALL
LZRW3
ZLIBALL
ZLIB
ZLIB1 – ZLIB9
Default: ALL
Notes:
■
Placing a “!” character immediately before the name of a compression method in the list can prevent that algorithm from being used.
■
Specifying any value other than ALL can cause only the methods explicitly added to be set as being allowed.
■
Specifying a value of NONE can disable compression processing on the local server.
Examples:
■
To turn off compression on a server:
■
COMPRESS_ALLOWED=NONE
■
To allow any compression method on a server:
Chapter 2: Enhanced Features 31
Allow for Control of Which Compression Methods Are Used
■
■
COMPRESS_ALLOWED=ALL
To disable the LZ family of compression methods on a server:
■
COMPRESS_ALLOWED=ALL:!LZALL
32 Release Notes
Allow for Control of Which Compression Methods Are Used
COMPNEG
COMPNEG specifies whether the compression negotiation is allowed, and if so, which compression algorithm the negotiation process substitutes.
compression-method
Specifies the data compression method which the negotiation process substitutes.
The possible values for this parameter are:
COMPACT
COMPACTL
YES
RLE
HUFFMAN
LZLARGE
LZMEDIUM
LZSMALL
LZRW3
ZLIB
ZLIB1 – ZLIB9
NO
Specifies that the data compression method is not negotiated. This causes transfers requesting an unsupported or disallowed compression method to be failed.
Default: YES
Notes:
■
If a transfer’s compression method that the initiator or partner requests by both participants is known and allowed, that method is used to compress the transfer data.
■
If the suggested compression method is not known or is not permitted by a participant involved in the transfer, the compression method that is specified for the COMPNEG parameter can be used to attempt to negotiate to an alternate compression method which is acceptable to both partners of the transfer.
■
The compression method that is specified for COMPNEG must be on the list of allowed algorithms for the local server, as an example, the COMPRESS_ALLOWED parameter.
Chapter 2: Enhanced Features 33
Allow for Control of which Transfer Types are Processed
Allow for Control of which Transfer Types are
Processed
CA XCOM Data Transport now supports a new parameter and command that can be used to control which types of transfers a server processes. This feature enables an operator to help balance the load on CA XCOM Data Transport servers.
The parameter which controls which transfer types the server can process is
TRANSFERS_ALLOWED. This parameter is used to enable or disable processing of locally or remotely initiated transfers. The value of the parameter can also be modified at any time by issuing the DFLT,TRANSFERS_ALLOWED command on the CA XCOM Data
Transport server.
TRANSFERS_ALLOWED
TRANSFERS_ALLOWED specifies which types of transfers the CA XCOM Data Transport server is allowed to process.
ALL
All transfer types are allowed to be processed.
LOCAL
The server only processes locally initiated transfer requests.
REMOTE
The server only processes remotely initiated transfer requests.
NONE
The server cannot process any transfer requests.
Default: ALL
Notes:
■
The server processes all meta transfers, commands, inquiries, and history requests, regardless of the value selected.
■
Transfers that are not processed remain on the queue in an inactive or remote suspended state. The transfers are subject to retries based on the server configuration.
■
If the server participates in a PLEXQ or XCOMPLEX environment, a high ranking is applied to the server when locally initiated transfers are disabled. This prevents transfers that are submitted to the PLEXQ or XCOMPLEX from being rejected in the event the server is selected to process the request.
34 Release Notes
Chapter 3: New and Changed
Messages
This section lists new or changed messages for this release.
XCOMM0288E
XCOMRRDS RECSIZE(xxxx). THIS RECSIZE SHOULD BE yyyy.
Reason:
CA XCOM Data Transport has successfully opened the XCOMRRDS Restart File but the record length that is defined for the file is xxxx bytes. CA XCOM is expecting a record length of yyyy bytes. The CA XCOM Data Transport Server terminates with RC=8.
Action:
The XCOMRRDS Restart file RECSIZE has changed with this release. Use the Request
Queue Migration Utility (XCOMMIGR) to convert your previous r11.5 or r11.6
XCOMRRDS, or create a new XCOMRRDS using the sample DEFRRDS JCL supplied with this release of the product. Ensure that the procedures for defining the XCOMRRDS
Restart File are followed correctly.
Chapter 3: New and Changed Messages 35
Allow for Control of which Transfer Types are Processed
XCOMM0419I
REQ#=nnnnnn ID=XXXXXX STATUS=XXXXXXXX
IPNAME=999.999.999.999 (or LUNAME=)
TYPE= FILETYPE= COUNT=999999999
CMPRBYTES= UNCMBYTES=
LCL USER= SDATE=YYYYMMDD
REM USER=
AGE=999
SPRTY=99
PSO=
RECSEP= PACK= COMPRESS=
GROUP= CKPT= TDUDATA=
STIME=9999
EPRTY=99
CODE=
TRUNCATE= FILEOPT= INITIATE=
SECURE_SOCKET=
XCOM_CONFIG_SSL=
GATEWAYDPATH=
Reason:
This message is displayed as the result of a CA XCOM Data Transport SHOW or RSHOW command that is entered with a specific request number.
Action:
None
XCOMM0420I
LDSN=local_data set_name
LVOL= LUNIT= SYSUDATA=
Reason:
This message is displayed as the result of a CA XCOM Data Transport SHOW or RSHOW command that is entered with a specific request number.
Action:
None
36 Release Notes
Allow for Control of which Transfer Types are Processed
XCOMM0421I
XCOMM0422I
RDSN=xxxxxx
VOL= UNIT= CODETABL=
GATEWAYGUID=
Reason:
This message is displayed as the result of a CA XCOM Data Transport SHOW or RSHOW command that is entered with a specific request number.
Action:
None
CLASS= DEST=
FORM= FCB= HOLD=
CONTROL= NAME=
WRITER= CHARS= COPY=
Reason:
This message is displayed as the result of a CA XCOM Data Transport SHOW or RSHOW command that is entered with a request number. This message is displayed when transmitting or receiving a report. The following fields are displayed:
■
The Class, Destination, Form, and FCB of the report
■
A hold flag, control flag (that is, ASA, MACHINE or name)
■
The report name that is printed on the report banner page
Action:
None
Chapter 3: New and Changed Messages 37
Allow for Control of which Transfer Types are Processed
XCOMM0478E
XCOMHIST RECSIZE(xxxx) INVALID. THIS RECSIZE SHOULD BE yyyy - NOT LOGGING
HISTORY
Reason:
CA XCOM Data Transport has successfully opened the XCOMHIST History File but the record length that is defined for the file is not yyyy bytes. The actual record length of the file is xxxx. CA XCOM Data Transport will not log any data to the History File, but initiates local requests and accepts remote initiates from the conversation partner.
Action:
The VSAM history file RECSIZE has changed with this release. Use the History Migration
Utility (XCOMUTIL) to convert your previous r11.5 or r11.6 VSAM History File or create a new VSAM History File using the DEFHIST JCL supplied with this release of the product.
Ensure that installation procedure for XCOMHIST was followed properly.
XCOMM0504E
SNA TRANSFERS DISABLED DUE TO CONFIG OPTION SNA=NO
Reason:
The CA XCOM Data Transport address space in which this message appears has been configured with SNA=NO which disables all SNA transfer activity within the address space.
Action:
Verify that the transfer is being attempted on the correct CA XCOM Data Transport server. If it is the correct server, change the configuration option to SNA=YES (or allow it to default), recycle the server and try the transfer again.
XCOMM0597E xxxxxx TASK LIMIT EXCEEDED ON INCOMING ALLOCATE—TRANSFER SUSPENDED
Reason:
The installation specifies an upper limit to the number of simultaneous file transfers.
This limit was exceeded and the transfer terminated. CA XCOM Data Transport can process multiple file transfer requests simultaneously. The maximum number of requests can be defined locally or remotely. This number can be changed by using the
DFLT console command or by changing the default table limits of MACLOC, MAXREM, or
MAXTASK.
Action:
Increase or remove the limit.
38 Release Notes
Allow for Control of which Transfer Types are Processed
XCOMM0679E
MISMATCHED MODULE RELEASE LEVELS DETECTED. XCOM TERMINATING
Reason:
One or more of the XCOM modules that were loaded during the initialization does not match the release of the primary program. This message most likely indicates an error with the STEPLIB, LINK LIST, or LPA configuration.
Action:
To use a library structure that is comprised of a single release of XCOM, correct the
STEPLIB, LINK LIST, or LPA configuration.
XCOMM0682E
SERVER TERMINATING DUE TO INVALID XCOMHIST DATA SET AND
'HISTORY=VSAMREQ'
Reason:
A problem was detected with the XCOMHIST data set during server initialization (such as an incorrect record length or a non-KSDS type). The startup value for the HISTORY= parameter is VSAMREQ, which means that a valid XCOMHIST data set MUST be available in order for the server to start.
Action:
To point to an XCOMHIST data set with the appropriate characteristics, either change the server JCL or change the HISTORY= parameter to a value that allows execution without an XCOMHIST data set.
Chapter 3: New and Changed Messages 39
Allow for Control of which Transfer Types are Processed
XCOMM0684W
COMPRESS=xxxxxxxx NOT PERMITTED DUE TO COMPRESS_ALLOWED PARAMETER
SETTING
Reason:
The value that is provided for the COMPRESS= parameter specifies a compression method which has been excluded from use by the COMPRESS_ALLOWED parameter.
If the COMPRESS= parameter occurs in a DEST member, the DEST member ENABLE operation fails and the member cannot be used.
If the COMPRESS= parameter was used in SYSIN01, CA XCOM attempts to negotiate to an acceptable compression method based on the COMPNEG parameter value.
Action:
Change the COMPRESS= parameter value to a compression method that is allowed in the CA XCOM environment.
XCOMM0685I
CHANGING COMPRESSION METHOD FROM COMPRESS=xxxxxxxx TO
COMPRESS=yyyyyyyy
Reason:
The value that is provided for the COMPRESS= parameter for a locally initiated transfer specified a compression method which has been excluded from use by the
COMPRESS_ALLOWED parameter. If the compression negotiation is allowed (COMPNEG set to a value other than NO), the compression method has been changed to the
COMPNEG setting.
Action:
If the new compression method is acceptable as configured, no further action is required.
40 Release Notes
Allow for Control of which Transfer Types are Processed
XCOMM0686I
---------------- wwwwwwwww, dd mmm yyyy ----------------
Reason:
This is either the first write to the XCOMLOG after server initialization, or the first write since the system clock changed to a new date.
■ wwwwwwwww is the current day of the week
■
■
■ dd is the corresponding day of the month mmm is the three character abbreviation for the current month yyyy is the current year.
Action:
None
XCOMM0687E
RELEASE LEVEL IN XCOMINQ RECORD (xx.x) DOES NOT MATCH XCOMJOB (yy.y)
Reason:
The XCOMINQ dataset being processed for an XCOMJOB TYPE=INQUIRE operation contains records that a different release of CA XCOM Data Transport created. Records from a different release level cannot be processed. xx.x represents the release level in the XCOMINQ records. yy.y represents the release level of XCOMJOB.
Action:
Using the DEFINQ sample JCL supplied with the yy.y release of XCOM, create a new
XCOMINQ dataset or invoke a version of XCOMJOB that matches the release indicated in the XCOMINQ records.
Chapter 3: New and Changed Messages 41
Allow for Control of which Transfer Types are Processed
XCOMM0689E
COMPNEG VALUE IS NOT A PERMITTED COMPRESSION ALGORITHM
(COMPRESS_ALLOWED)
Reason:
The value that is provided for the COMPNEG= parameter in either the startup configuration or a DEST member has been excluded from use by way of the
COMPRESS_ALLOWED parameter.
Action:
To be a compression method that is allowed in the CA XCOM region and retry the operation, change the value of the COMPNEG parameter.
XCOMM933E xxxxxx TRANSFERS ARE CURRENTLY DISABLED ON SERVER yyyyyyyy
Reason:
A transfer request was submitted to a server which currently is not allowing the request to be processed. The xxxxxx value indicates the type of transfer, which is either LOCAL or REMOTE depending on how the transfer was initiated. The yyyyyyyy value is the
ACBNAME of the server processing the request.
Action:
If the failure is a locally initiated transfer, it is marked as inactive and retries are attempted based on configuration values in place for the server or job. If the failure is a remotely initiated transfer, it is marked in remote suspend status and retries are attempted on the locally initiated server that is based on configuration values in place for the server or job. Once all retries are exhausted, the transfer is terminated.
XCOMM0990I
Configured Settings:
Reason:
An informational message preceding the individual configured options of the XCOM server.
Action:
None
42 Release Notes
Allow for Control of which Transfer Types are Processed
XCOMM0992I
XCOMM0993I
XCOMM0994I
* - Defaulted Value
Reason:
An informational message indicating the “*” symbol preceding an XCOMM099I message is the XCOM CONFIG parameter default value.
Action:
None
+ - EXEC PARM Override
Reason:
An informational message indicating the “+” symbol preceding an XCOMM099I message is the XCOM CONFIG parameter value which the EXEC parameter changed.
Action:
None
XCOMM0995I
(Values from CONFIG unless noted as follows)
Reason:
An informational message preceding the configured options of the XCOM server.
Action:
None
# - Changed by DFLT Command
Reason:
An informational message indicating the “#” symbol preceding an XCOMM099I message is the XCOM CONFIG parameter value which the DFLT modify command changed.
Action:
None
Chapter 3: New and Changed Messages 43
Allow for Control of which Transfer Types are Processed
XCOMM0999I
X CONFIG PARM = value
Reason:
An informational message indicating the XCOM CONFIG parameter and its value, as well as where the value was obtained.
Action:
None
XCOMM1104I wwwwwwww / xxxxxxxx CONNECTED TO PLEXQ GROUP yyyyyyyy AS (vvvv)zzzzzzzz
Reason:
This message indicates that another CA XCOM program has connected to the PLEXQ
GROUP identified in the message, and to which the region which issued the message was already connected. Variable substitution in the message text is as follows:
■ wwwwwwww = the name of the system where the connector is running.
■ xxxxxxxx = the name of the job or started task which connected.
■
■
■ yyyyyyyy = the name of the PLEXQ group to which the program connected. vvvv = the version level of the server connecting to the PLEXQ group. zzzzzzzz = the name by which the program is known in the PLEXQ group.
Action:
None
XCOMM1107I
CONNECTING TO PLEXQ GROUP xxxxxxxx WHICH IS RUNNING WITH MIXED LEVEL
SERVERS
Reason:
An XCOM server attempted to connect to a PLEXQ where some other XCOM servers in the PLEX are at a different release of CA XCOM Data Transport. xxxxxxxx specifies the name of the PLEXQ group connecting to.
Action:
None required. The XCOM Server connects to the PLEX group.
44 Release Notes
Allow for Control of which Transfer Types are Processed
XCOMM1108W
XCOMM1109W
NEWER XCOM FEATURES MAY NOT BE ACKNOWLEDGED BY THE PLEXQ SERVER
PROCESSING THIS REQUEST
Reason:
An XCOM job attempted connecting to a PLEXQ where other XCOM servers in the PLEX are at lower release levels of CA XCOM Data Transport. Depending on which server the request is assigned to, some features can be ignored.
Action:
None required. Transfers continue to function. To eliminate this warning message and have access to all XCOM features, convert all servers to the latest CA XCOM Data
Transport release level.
XCOMM1125E
NEWER XCOM FEATURES ARE NOT SUPPORTED ON THIS PLEXQ SERVER
Reason:
This XCOM server that is connected to a PLEXQ where other XCOM servers in the PLEX are at a different release of CA XCOM Data Transport. For any requests processed by this server, features added in the newer releases are ignored.
Action:
None required. Transfers continue to function. To eliminate this warning message and have access to all XCOM features, convert all servers to the latest CA XCOM Data
Transport release level.
COMMAND REJECTED – NOT CONNECTED TO PLEXQ xxxxxxxx
Reason:
A STAT, XSHOW, or XRSHOW command was issued for a PLEXQ group to which this CA
XCOM Data Transport server is not connected.
Action:
Check the PLEXQ group name that is specified on the command and correct if necessary.
Chapter 3: New and Changed Messages 45
Allow for Control of which Transfer Types are Processed
XCOMM1140E xxxxx PROTOCOL SELECTED BUT xxxxxxxx IS NOT SPECIFIED – JOB TERMINATED
Reason:
A value was specified for the STCPROTOCOL parameter, but the corresponding parameter to define the server to schedule the transfer to was omitted.
Action:
To define the server to schedule the transfer to, either in the configuration member or as an EXEC parameter, specify the proper parameter.
XCOMM1185E
MAXIMUM PLEXQ CONNECTIONS ALREADY ACTIVE
Reason:
An attempt to join a PLEXQ group has failed because the maximum number of connections are already active.
Action:
Dynamically disconnect from any unneeded or unused PLEXQ groups using the
PLEXQ,LEAVE command or remove them from the PLEXQ configuration parameter and restart the server.
XCOMM1186E
ALREADY CONNECTED TO PLEXQ GROUP xxxxxxxx
Reason:
An attempt to connect to a PLEXQ group has failed because the CA XCOM Data
Transport server already has an active connection to the named PLEXQ group.
Action:
If the error occurs during server initialization, remove the duplicate PLEXQ group name from the PLEXQ configuration parameter. If the error occurs as a result of a PLEXQ,JOIN command, the connection already exists, and no further action is required.
46 Release Notes
Allow for Control of which Transfer Types are Processed
XCOMM1187E
NO ACTIVE CONNECTION WITH PLEXQ GROUP xxxxxxxx
Reason:
An attempt to disconnect from a PLEXQ group has failed because the CA XCOM Data
Transport server has no active connection to the named PLEXQ group.
Action:
If the PLEXQ group name is correct in the PLEXQ,LEAVE command, no further action is required, as the connection is not active. Otherwise, reissue the PLEXQ,LEAVE command with the correct PLEXQ group name.
XCOMM1188I
CURRENT PLEXQ CONNECTIONS:
Reason:
A PLEXQ,QUERY command was entered on the CA XCOM Data Transport server. This message identifies the subsequent output as being the response to the QUERY command.
Action:
None
XCOMM1189E xxxxxxxx INVALID PLEXQ SUBCOMMAND
Reason:
A PLEXQ command was entered with an invalid SUBCOMMAND. The valid PLEXQ
SUBCOMMANDS are QUERY, JOIN, and LEAVE.
Action:
Choose one of the valid SUBCOMMANDS listed and reenter the command with a correct option.
Chapter 3: New and Changed Messages 47
Allow for Control of which Transfer Types are Processed
XCOMM1190E xxxxxxxx PLEXQ GROUP NAME IS NOT VALID
Reason:
An invalid PLEXQ group name was provided as a parameter to the PLEXQ configuration parameter.
Action:
See the CA XCOM Data Transport Administration Guide for the requirements for PLEXQ group names.
XCOMM1191E
PLEXQ GROUP NAME REQUIRED BUT NOT PROVIDED
Reason:
A PLEXQ JOIN or LEAVE command was issued, but no PLEXQ group name was provided.
Action:
Specify a valid PLEXQ group name as a parameter for the command.
XCOMM1192E
GETMAIN FAILED FOR PLEXQ QUERY BUFFER
Reason:
Insufficient virtual storage was available to satisfy a request to allocate a buffer to hold an IXCQUERY response.
Action:
Retry the request later, or run the server with a larger storage allocation.
XCOMM1403E xxxxxxxxxxxxxxxxxxx – UNBALANCED PARENTHESES OR MISSING DELIMITER
Reason:
The value specified for the parameter named in this message either has a missing parenthesis or a delimiting “,” was not found as expected.
Action:
Correct the format of the parameter value and restart the CA XCOM Data Transport server.
48 Release Notes
Allow for Control of which Transfer Types are Processed
XCOMM1450I
XCOMM1451E
Action Parameter Missing or Invalid
Reason:
The CA XCOM Data Transport for z/OS CAIRIM initialization program (FXC0INIT) requires at least one parameter (INIT, REINIT or DELETE).
Action:
Update the CAIRIM parameter file entry for CA XCOM Data Transport for z/OS with the required action parameter and rerun CAIRIM.
XCOMM1452E
CA XCOM Data Transport for z/OS Initialization [Started | Ended]
Reason:
The CA XCOM Data Transport for z/OS CAIRIM initialization program (FXC0INIT) has started or ended.
Action:
None
CONFIGDSN Parameter Missing or Invalid
Reason:
The CA XCOM Data Transport for z/OS CAIRIM initialization program (FXC0INIT) requires the CONFIGDSN parameter for action INIT or REINIT. Either the CONFIGDSN parameter was not supplied or the CONFIGDSN valid is invalid.
Action:
Update the CAIRIM parameter file entry for CA XCOM Data Transport z/OS with the required or correct CONFIGDSN parameter and rerun CAIRIM.
Chapter 3: New and Changed Messages 49
Allow for Control of which Transfer Types are Processed
XCOMM1453I
CONFIGDSN Deleted Successfully
Reason:
The CA XCOM Data Transport for z/OS CAIRIM initialization program (FXC0INIT) successfully deleted the CONFIGDSN value.
Action:
None
XCOMM1454E
Symbol Call (xxxxxxxxxxxx) Failed RC=nnnnnnnn RS=nnnnnnnn
Reason:
The CA XCOM Data Transport for z/OS CAIRIM initialization program (FXC0INIT) attempted symbol call xxxxxxxxxxxx failed with return code nnnnnnnn and reason code nnnnnnnn.
Action:
If the return code is 8 and the action specified was DELETE, CONFIGDSN could not be deleted because it did not exist. For all other cases please contact CA XCOM Data
Transport technical support.
XCOMM1455I
CONFIGDSN Set: xxxxxxxx
Reason:
The CA XCOM Data Transport for z/OS CAIRIM initialization program (FXC0INIT) successfully set CONFIGDSN to xxxxxxxx.
Action:
None
50 Release Notes
Allow for Control of which Transfer Types are Processed
XCOMM1456I xxxxxxxx
Reason:
Used by the CA XCOM Data Transport for z/OS CAIRIM initialization program (FXC0INIT) for debugging messages.
Action:
None
XCOMM1460I
Symbol CONFIGDSN=xxxxxxxx
Reason:
CA XCOM Data Transport found the symbol CONFIGDSN with value xxxxxxxx.
Action:
None
XCOMM1461I
Searching xxxxxxxx for TYPE=CONFIG member yyyyyyyy
Reason:
CA XCOM Data Transport is searching XCOMCNTL or CONFIGDSN for the TYPE=CONFIG member yyyyyyyy.
Action:
None
XCOMM1462E
Error Allocating CONFIGDSN RC=xxxxxxxx Error=yyyyyyyy
Reason:
CA XCOM Data Transport could not allocate the CONFIGDSN data set. The dynamic allocation return and reason code is provided.
Action:
Correct the error and retry the batch job.
Chapter 3: New and Changed Messages 51
Allow for Control of which Transfer Types are Processed
XCOMM1463I
Skipping CONFIGDSN due to Allocation Error
Reason:
CA XCOM Data Transport is skipping the search for the TYPE=CONFIG member in the
CONFIGDSN data set because the CONFIGDSN data set could not be allocated.
Action:
Refer to the 1462E message for the cause of the allocation error.
XCOMM1464I
STCPROTOCOL set to xxxxx based on EXEC PARM xxxxxxxx
Reason:
STCAPPL, STCIP, or STCPLEXQ was specified as an EXEC parameter for the job. The value for STCPROTOCOL is determined from the overriding EXEC parameter. If a value is specified for STCPROTOCOL in the configuration member, it is ignored.
Action:
None
XCOMM1490W
XCOMM1490W Callable service aaaaaaaa failed, RV=xxxxxxxx, RC=yyyyyyyy,
RSN=zzzzzzzz
Reason:
The call to IBM callable service aaaaaaaa failed with return value xxxxxxxx, a return code yyyyyyyy and, reason code zzzzzzzz.
Action:
For the callable service that failed, refer to the IBM z/OS UNIX System Services
Programming: Assembler Callable Services Reference for details on the meaning of the return value, return code, and reason code
52 Release Notes
Allow for Control of which Transfer Types are Processed
XCOMM1510E
System SSL Function XXXX: RC = ZZZ: Reason = YYYY
Reason:
XXXX is the System SSL function that failed. ZZZ is the return value of said function and
YYYY is the reason.
Action:
To determine the appropriate action, examine the message. Many errors are the result of the specification of the wrong IPNAME or IPPORT, configuration problems, name resolution, or network problems.
These codes are not CA XCOM Data Transport error codes, but are passed back from
System SSL.
XCOMM1511E
System SSL XCOM_CONFIG_SSL read error. Section: <PARAMETER>
Parameter: <INITIATE_SIDE/RECEIVE_SIDE> not found in the config file.
Reason:
Specified Section and/or Parameter is missing for the XCOM_CONFIG_SSL config file specified for System SSL
Action:
Add the mentioned section and/or parameter to the config file using the following format:
[PARAMETER]
INITIATE_SIDE = value1
RECEIVE_SIDE= value2
XCOMM1512E
System SSL XCOM_CONFIG_SSL error. One or more verify criteria were not met.
Reason:
One or more of the criteria that is specified in the XCOM_CONFIG_SSL config file did not match the certificate on the corresponding end.
Action:
Verify that the criteria specified in the XCOM_CONFIG_SSL config file matches the information in the corresponding certificate.
Chapter 3: New and Changed Messages 53
Allow for Control of which Transfer Types are Processed
XCOMM1513W
System SSL CERT warning. Using sample certificates, for testing only!
Reason:
The system detected that you are using the sample certificates provided.
Action:
The sample certificates can be used for testing purposes, but it is not recommended that they be used in a production environment. New certificates should be created for use in a production system.
XCOMM1514E z/OS 1.13 or above is required for System SSL support
Reason:
The CA XCOM Data Transport configuration specifies System SSL
(SSL_VERSION=SYSTEM) and the system detected that you are not at z/OS 1.13 or above.
Action:
CA XCOM Data Transport support for IBM System SSL requires z/OS 1.13 or above. Sites running an IBM supported z/OS system below z/OS 1.13 must use OpenSSL for secure socket (SSL) transfers (SSL_VERSION=OPEN).
XCOMM8001E
UNABLE TO OPEN xxxxxxxx DD—XCOMUTIL TERMINATED
Reason:
When XCOMUTIL or XCOMMIGR attempted to open the data set, the call failed.
Action:
Correct the DD name and rerun XCOMUTIL/XCOMMIGR.
54 Release Notes
Allow for Control of which Transfer Types are Processed
XCOMM8002E
XCOMM8011E xxxxxxxx PROGRAM ENDED WITH ERRORS
Reason:
XCOMUTIL or XCOMMIGR did not run successfully.
Action:
To determine the reason it was not successful, check the return code from XCOMUTIL or
XCOMMIGR:
■
4—No history records were written to the output file
■
8—XCOMUTIL could not open one of the files
■
12—One of the SYSIN parameters was in error
■
16—For XCOMMIGR, an attempt to migrate to an unsupported release was made
XCOMM8012I
INVALID PARAMETER CARD—NOT xxxxxxxxxxxxxxxxxxxx
Reason:
The only valid SYSIN statements for XCOMUTIL are DATE=, AGE=, PROCESS= and
RELEASE=.
The only valid SYSIN statements for XCOMMIGR are RELEASE=.
Action:
Remove the incorrect SYSIN statement and rerun XCOMUTIL/XCOMMIGR.
xxxxxxxx PROGRAM ENDED SUCCESSFULLY
Reason:
XCOMUTIL or XCOMMIGR ran successfully.
Action:
Check the other informational messages for details.
Chapter 3: New and Changed Messages 55
Allow for Control of which Transfer Types are Processed
XCOMM8013I xxxxxxxx RECORDS READ FROM yyyyyyyy FILE
Reason:
XCOMUTIL read xxxxxxxx records from the history file (HSTIN).
XCOMMIGR read xxxxxxxx records from the request queue file (RRDSIN)
Action:
Informational message. No action required.
XCOMM8014I xxxxxxxx RECORDS WRITTEN TO yyyyyyyy FILE
Reason:
XCOMUTIL wrote xxxxxxxx records to the HISTOUT file. These are the records that were kept.
XCOMMIGR wrote xxxxxxxx records to the RRDSOUT file.
Action:
None
XCOMM8018E
INVALID RELEASE FOR MIGRATION SPECIFIED – MUST BE 11.5, 11.6 or 12.0
Reason:
When running a history or request queue migration, the RELEASE= parameter does not contain a valid release to migrate the history file cluster or request file to.
Action:
Correct the RELEASE parameter to be 11.5, 11.6 or 12.0 and rerun
XCOMUTIL/XCOMMIGR. Specify 11.5 or 11.6 to perform backward migration of the
VSAM History File cluster or request queue file. Specify 12.0 to perform forward migration of an 11.5 or 11.6 VSAM History File cluster or request queue file to the new version 12.0 format. If you do not have release 11.5, 11.6 or 12.0, create a new history or request queue for the target system using the sample DEFHIST or DEFRRDS JCL for that system.
56 Release Notes
Allow for Control of which Transfer Types are Processed
XCOMM8019E
XCOMM8020E
MULTIPLE RELEASE PARAMETERS ENTERED
Reason:
Multiple RELEASE parameters were specified for the history/request queue file migration process.
Action:
Remove the extra RELEASE parameters and rerun XCOMUTIL/XCOMMIGR.
XCOMM8021E
YYYYYYYY FILE XXXXXXXX NOT AT PROPER RELEASE LEVEL FOR MIGRATION
Reason:
When running a history migration, the source history file sequential data set does not contain the proper size history records for the migration selected.
When running a request queue migration, the source request queue file sequential data set does not contain the proper size queue records for the migration selected.
Action:
Correct the LRECL for the history/request queue file sequential data set created by the
IDCAMS job to repro the history file cluster/request queue file. The proper size of the record is 2024 for 11.5, 3034 for 11.6 or 8084 for 12.0 and rerun
XCOMUTIL/XCOMMIGR. If you do not have release 11.5, 11.6 or 12.0, create a new history or request queue for the target system using the sample DEFHIST or DEFRRDS
JCL for that system.
BACKWARD MIGRATION OF A REQUEST QUEUE TO 11.5 IS NOT SUPPORTED
Reason:
A request queue file cannot be migrated from version 12.0 to a release 11.5 format, due to changes made in release 11.6 in support of new features.
Action:
You can only migrate back to release 11.6. If you have release 11.5 or lower, you cannot migrate and must create a new request queue for the target system using the sample
DEFRRDS JCL for that system.
Chapter 3: New and Changed Messages 57
Appendix A: Known Issues
Published Fixes for Version 12.0.00
All published fixes are available at Published Solutions on http://ca.com/support .
Appendix A: Known Issues 59
Appendix B: Migrating Security
Settings
This appendix provides information that is related to any product changes affecting your existing implementation of CA ACF2™ for z/OS, CA Top Secret® z/OS, or IBM RACF access control products. Any new product enhancements that impact your current security settings are documented in New Features or Enhancements to Existing Features.
This section contains the following topics:
Data Set Security (see page 61)
Started Task Requirements (see page 61)
Sensitive Utilities and Programs (see page 61)
General Resource Security (see page 62)
Product Configuration Settings Affecting Security (see page 62)
Additional Security Considerations (see page 62)
Data Set Security
Your product has the following data set security requirement changes:
■
Installation data sets
■
Started task data sets
■
User data sets
■
UNIX System Services (USS) data sets
Started Task Requirements
This section identifies changes that are related to permissions required to data sets and resources, and to any required attributes such as UID(0), TSS facility matrix table definitions, or IBM RACF TRUSTED.
Sensitive Utilities and Programs
Evaluate the following program module security attributes for their impact on your current security settings:
[program name]
[description]
Appendix B: Migrating Security Settings 61
General Resource Security
General Resource Security
Evaluate the following resource security settings for their impact on your current security settings:
[resource name]
[description]
Product Configuration Settings Affecting Security
Evaluate the following configuration settings for their impact on your current security settings:
[configuration setting]
[description]
Additional Security Considerations
Evaluate the following topics <security exits, user IDs, passwords> for their impact on your current security settings:
Security exit
Description
User ID
Description
Password
Description
62 Release Notes
Appendix C: Deprecated or Obsolete
Features
The following features have been deprecated in r11.6 release of XCOM.
This section contains the following topics:
Default Options Table Deprecated (see page 63)
XCOMPLEX Environment Deprecated (see page 63)
XCOM CICS Interface Deprecated (see page 64)
TYPE=USER Destination Member Obsolete (see page 64)
Version 1 Transaction Programs Obsolete (see page 64)
Japanese Character Set Parameters Obsolete (see page 65)
Default Options Table Deprecated
The Default Options Table is deprecated and replaced by TYPE=CONFIG members in this release. The migration from Default Options Table to TYPE=CONFIG member is simplified by an automatic conversion process the first time a server loads the Default
Options Table, admin server, or batch job. In addition, existing batch JCL with the
DFLTAB parameter specified interprets the DFLTAB parameter as the CONFIG parameter, without failing the job.
The #DFLTAB macro that is used to generate the Default Options Table is no longer supplied with CA XCOM Data Transport v12.0.
XCOMPLEX Environment Deprecated
The XCOMPLEX deprecated environments include:
■
■
ADMIN server
TYPE=ADMIN XCONCNTL destination member
The PLEXQ facility that was introduced in r11.6 is used for a replacement. A PLEXQ environment has been introduced in servers which are also part of an XCOMPLEX. The two coexist so that migration to the PLEXQ is accomplished more easily.
Appendix C: Deprecated or Obsolete Features 63
XCOM CICS Interface Deprecated
XCOM CICS Interface Deprecated
The CICS interface panels for XCOM are deprecated. The ISPF interface for XCOM is used instead.
TYPE=USER Destination Member Obsolete
The TYPE=USER XCOMCNTL destination member and associated parameters are now obsolete. This destination type used “USER” for a remote system parameter and was historically used for the Windows 3.1 environment and is no longer supported.
The obsolete features include:
■
USER batch parameter
■
“Login User Name” on ISPF panels
■
LOGNREQ system parameter
■
TYPE=USER Destination Member
Version 1 Transaction Programs Obsolete
The DFLTVER parameter is now obsolete. Version 1 Transaction Programs for performing CA XCOM Data Transport file transfers have been removed from the product and are no longer available for use. As a result, any value that is specified for the
DFLTVER parameter in the #DFLTAB macro generation or in a DEST member is ignored.
Messages are issued indicating that the parameter is no longer supported.
Incoming transfer requests are processed using the current Transaction Program code which can process transfer requests appropriately without regard for the version being requested.
64 Release Notes
Japanese Character Set Parameters Obsolete
Japanese Character Set Parameters Obsolete
The Japanese Character Set parameters JPNCNTL, JPNDATA, JPNDBL and JPNSHFT, that were used for transfers to the CA XCOM Data Transport for PC-DOS and CA XCOM Data
Transport for OS/2 products, have been deprecated. As a result, any value that is specified for any of these parameters in the SYSIN01 file is ignored.
Messages are issued indicating that the parameters are no longer supported.
The Japanese Character Set Support Screen has been removed from the CA XCOM Data
Transport ISPF Interface.
Appendix C: Deprecated or Obsolete Features 65
advertisement
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Related manuals
advertisement