TIBCO MFT Platform Server for z/os Release Notes. Software Release November 2014

Transcription

1 TIBCO MFT Platform Server for z/os Release Notes Software Release November 2014

2 Important Information SOME TIBCO SOFTWARE EMBEDS OR BUNDLES OTHER TIBCO SOFTWARE. USE OF SUCH EMBEDDED OR BUNDLED TIBCO SOFTWARE IS SOLELY TO ENABLE THE FUNCTIONALITY (OR PROVIDE LIMITED ADD-ON FUNCTIONALITY) OF THE LICENSED TIBCO SOFTWARE. THE EMBEDDED OR BUNDLED SOFTWARE IS NOT LICENSED TO BE USED OR ACCESSED BY ANY OTHER TIBCO SOFTWARE OR FOR ANY OTHER PURPOSE. USE OF TIBCO SOFTWARE AND THIS DOCUMENT IS SUBJECT TO THE TERMS AND CONDITIONS OF A LICENSE AGREEMENT FOUND IN EITHER A SEPARATELY EXECUTED SOFTWARE LICENSE AGREEMENT, OR, IF THERE IS NO SUCH SEPARATE AGREEMENT, THE CLICKWRAP END USER LICENSE AGREEMENT WHICH IS DISPLAYED DURING DOWNLOAD OR INSTALLATION OF THE SOFTWARE OR IF THERE IS NO SUCH SOFTWARE LICENSE AGREEMENT OR CLICKWRAP END USER LICENSE AGREEMENT, THE LICENSE(S) LOCATED IN THE LICENSE FILE(S) OF THE SOFTWARE. USE OF THIS DOCUMENT IS SUBJECT TO THOSE TERMS AND CONDITIONS, AND YOUR USE HEREOF SHALL CONSTITUTE ACCEPTANCE OF AND AN AGREEMENT TO BE BOUND BY THE SAME. This document contains confidential information that is subject to U.S. and international copyright laws and treaties. No part of this document may be reproduced in any form without the written authorization of TIBCO Software Inc. TIBCO, The Power of Now, Two-Second Advantage, TIBCO Managed File Transfer, TIBCO Managed File Transfer Command Center, TIBCO Managed File Transfer Internet Server, TIBCO Managed File Transfer Platform Server, TIBCO Managed File Transfer Platform Server Agent, Slingshot, and TIBCO Vault are either registered trademarks or trademarks of TIBCO Software Inc. or its subsidiaries in the United States and/or other countries. EJB, Java EE, J2EE, and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. All other product and company names and marks mentioned in this document are the property of their respective owners and are mentioned for identification purposes only. THIS SOFTWARE MAY BE AVAILABLE ON MULTIPLE OPERATING SYSTEMS. HOWEVER, NOT ALL OPERATING SYSTEM PLATFORMS FOR A SPECIFIC SOFTWARE VERSION ARE RELEASED AT THE SAME TIME. THIS DOCUMENT IS PROVIDED AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. THIS DOCUMENT COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS. CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION HEREIN; THESE CHANGES WILL BE INCORPORATED IN NEW EDITIONS OF THIS DOCUMENT. TIBCO SOFTWARE INC. MAY MAKE IMPROVEMENTS AND/OR CHANGES IN THE PRODUCT(S) AND/OR THE PROGRAM(S) DESCRIBED IN THIS DOCUMENT AT ANY TIME. THE CONTENTS OF THIS DOCUMENT MAY BE MODIFIED AND/OR QUALIFIED, DIRECTLY OR INDIRECTLY, BY OTHER DOCUMENTATION WHICH ACCOMPANIES THIS SOFTWARE, INCLUDING BUT NOT LIMITED TO ANY RELEASE NOTES AND "READ ME" FILES. Copyright TIBCO Software Inc. ALL RIGHTS RESERVED. TIBCO Software Inc. Confidential Information TIBCO welcomes your comments on this publication. Please address your comments to:

3 iii Contents Introduction... iv RELATED DOCUMENTATION... V TIBCO MFT Platform Server for z/os Documentation... v CONNECTING WITH TIBCO RESOURCES... VI How to Join TIBCOmmunity... vi How to Access All TIBCO Documentation... vi How to Contact TIBCO Support... vi New Features... 1 Release Changes in Functionality Release Deprecated and Removed Features Release Compatibility and Migration Release Hotfixes Closed Issues Release Known Issues... 28

4 iv Introduction MFT Platform Server for z/os is now generally available. MFT Platform Server enables secure, controlled file-transfer activity on all platforms. With the power of MFT Platform Server, businesses can transfer critical business files between applications, integrate data from a network of stores or branch locations, or send large files to an offshore data center. Release includes valuable enhancements and also resolves outstanding issues from the previous version of Platform Server for z/os. TIBCO continues to stay ahead of the competition by adding the most advanced technology to MFT Platform Server.. Topics Related Documentation How to Contact TIBCO Customer Support

5 v Related Documentation This section lists documentation you may find useful. TIBCO MFT Platform Server for z/os Documentation The following documents form the TIBCO MFT Platform Server for z/os documentation which can be viewed and downloaded from TIBCO MFT Platform Server for z/os Installation and Operations Guide Read this manual for instructions on site preparation, and installation. TIBCO MFT Platform Server for z/os User Guide Read this manual for instructions on using the product to perform transfer requests and more between other Platform Server nodes. TIBCO MFT Platform Server for z/os Message Manual Guide Read this manual to get more detailed descriptions for the Platform Server messages written to the product log. TIBCO MFT Platform Server for z/os Release Notes Read the release notes for a list of new and changed features. This document also contains lists of known issues and closed issues for this release.

6 vi Connecting with TIBCO Resources How to Join TIBCOmmunity TIBCOmmunity is an online destination for TIBCO customers, partners, and resident experts, a place to share and access the collective experience of the TIBCO community. TIBCOmmunity offers forums, blogs, and access to a variety of resources. To register, go to How to Access All TIBCO Documentation How to Contact TIBCO Support After you join TIBCOmmunity, you can access the documentation for all supported product versions here: For comments or problems with this manual or the software it addresses, please contact TIBCO Support as follows. For an overview of TIBCO Support, and information about getting started with TIBCO Support, visit this site: If you already have a valid maintenance or support contract, visit this site: Entry to this site requires a user name and password. If you do not have a user name, you can request one.

7 1 New Features This section lists features added since the last release of this product. Release Updated Started Task JCL Updated Started Task JCL available in the MFT.JCL library. The member name has been changed to MFTSTC from FUSION. The TRCLASS DD Statement has been added and DSN names have replaced FUSION with MFT. New GLOBAL Parameters With the addition of the following new GLOBAL parameters, IPV6 support was added: TAPE_SECURITY_EXIT={IGNORE ERROR} This parameter defines the processing performed when the SMS Tape Security Exit is invoked for a tape mount that has not expired. The following values are accepted: : ERROR: Reject the tape mount. Terminate the transfer with retry-able abend : IGNORE: Performs the default SMS action. This is the default if the parameter is not defined. IGNORE_EBDCIC_LF={YES NO} This parameter is only used when zos is receiving a file and the Delimiter is set to LF. This parameter defines whether EBCDIC line feeds (0x15) are checked when the transfer DELIMITER is set to LF. ASCII line feeds (0x0A) are always

8 2 checked. The default value of NO indicates that both EBCDIC and ASCII line feeds are checked. When set to YES, only ASCII line feeds are checked. TCPIPPORT_IPV6={ nnnnn 0} Specifies the IPV6 Port that the MFT Platform Server z/os will listen on for incoming transfer requests. The valid number is either 0 or 1025 to The default value of 0 indicates that MFT Platform Server will not listen for incoming IPV6 requests. SSLIPPORT_IPV6={ nnnnn 0} Defines the IPV6 Port that MFT Platform Server will listen on for SSL requests. If non-ssl requests are received on this port, then an error message will be sent to the Initiator and the request will be terminated. This field must be different than the IPPORT parameter, and should be unique on the z/os system. There is no default for this parameter. If this parameter is not defined, then responder IPV6 SSL processing will be disabled. TCPCONNET_ADAPTER_IPADDR_IPV6 Defines the IP Address of the TCP network interface that your MFT Platform Server started task will bind to for outgoing IPV6 connections. The default is to bind to all TCP network interfaces. If you wish to bind to only a single network interface, specify the IPV6 address of the network interface. Then MFT Platform Server will bind to that network interface for outgoing requests. This parameter is used only for outgoing requests (i.e. Initiator). It is ignored for incoming requests (i.e. Responder). TCPLISTEN_ADAPTER_IPADDR_IPV6={0123:4567::89 AB:CDEF ALL } Defines the IPV6 Address of the TCP network interface that your MFT Platform Server started task will listen for incoming

9 connections. The default is to listen to all TCP network interfaces. If you wish to listen to only a single network interface, specify the IPV6 address of the network interface. Then MFT Platform Server will only listen to that network interface for incoming requests. This parameter is used only for incoming requests (i.e. Responder). It is ignored for outgoing requests (i.e. Initiator). SSLLISTEN_ADAPTER_IPADDR_IPV6={0123:4567::89 AB:CDEF ALL } Defines the IPV6 Address of the TCP network interface that your MFT Platform Server started task will listen for incoming SSL connections. The default is to listen to all TCP network interfaces. If you wish to listen to only a single network interface, specify the IPV6 address of the network interface. Then MFT Platform Server will only listen to that network interface for incoming requests. This parameter is used only for incoming SSL requests (i.e. Responder). It is ignored for outgoing requests (i.e. Initiator). SSL_REQUEST_IPV6={ NO YES OUTSIDE_NETWORK } Defines when SSL should be used, or when it must be used on IPV6 networks. You can specify: NO SSL is not required but may be used. YES SSL must be used for both initiator and responder. OUTSIDE_NETWORK SSL usage depends on the IPV6 Address of the target system and how it compares with the IPV6 address of the local system. If the target system address is outside the subnet defined by the SSL_NETWORK_IPADDR_IPV6 and SSL_NETWORK_SUBNET_IPV6 parameters, then the request must use SSL. 3

10 4 SSL_NETWORK_IPADDR_IPV6={0123:4567::89AB:CD EF } Defines the IPV6 Address used to define whether a request must be an SSL request. MFT Platform Server takes the IPV6 Address of the local system and the IP Address of the target system. MFT Platform Server determines the subnet of these two addresses by using the SSL_NETWORK_SUBNET_IPV6 parameter. MFT Platform Server then compares the two values to determine if a request is within the subnet, or outside the subnet. It inside the subnet, then the request does not have to be an SSL request. If outside the subnet, then the request MUST be an SSL request. SSL_NETWORK_SUBNET_IPV6={IP Subnet } Defines the subnet of the SSL_NETWORK_IPADDR_IPV6 that should be used when checking if a request should use SSL. A number for 0 to 128 and divisible by 8 must be specified. Any target system that is outside of the subnet defined will require SSL. There is no default for this parameter. With the addition of the following new GLOBAL parameter a user can define the action that will be taken in the Tape Security Exit when a tape is mounted that has not expired: TAPE_SECURITY_EXIT This parameter defines the processing performed when the SMS Tape Security Exit is invoked for a tape mount that has not expired. The following values are accepted: : ERROR: Reject the tape mount. Terminate the transfer with retry-able abend : IGNORE: Performs the default SMS action. This is the default if the parameter is not defined. With the addition of the following two new GLOBAL parameters a user can define the z/os nodes from which will accept

11 5 incoming Transfer Schedule requests or Transfer Management requests: ALLOW_TRANSFER_REQUESTS={YES NO NODE} Defines whether Transfer Schedule Requests initiated through TCP or SNA will be accepted. This parameter applies to the following MFT interfaces: Batch, Script, API, REXX and ISPF. This field applies only to transfers scheduled through SNA or TCP and does not apply to transfers scheduled through cross memory. This parameter does not apply to transfers scheduled by the MFT Command Center. The following values are accepted: YES NO NODE This is the default value and indicates that TCP and SNA Transfer requests will be accepted. Indicates that TCP and SNA Transfer requests will not be accepted. Only requests initiated on the same server and scheduled through cross memory will be accepted. Indicates that the NODE ALLOW_TRANSFER_REQUESTS parameter will define whether TCP or SNA requests will be accepted. If a NODE definition is not defined for an incoming Transfer schedule request, the request will be denied. ALLOW_MANAGE_REQUESTS={YES NO NODE} Defines whether Transfer Management Requests initiated through TCP or SNA will be accepted. This parameter applies to the following MFT interfaces: Batch, Script, API, REXX and ISPF. This field applies only to transfers managed through SNA or TCP and does not apply to transfers managed through cross memory. Management requests are typically ISPF or REXX Transfer inquiry. This parameter does not apply to

12 6 transfers managed by the MFT Command Center. The following values are accepted: YES NO NODE New Node Parameters This is the default value and indicates that TCP and SNA Transfer requests will be accepted. Indicates that TCP and SNA Transfer requests will not be accepted. Only requests initiated on the same server and scheduled through cross memory will be accepted. Indicates that the NODE ALLOW_TRANSFER_REQUESTS parameter will define whether TCP or SNA requests will be accepted. If a NODE definition is not defined for an incoming Transfer schedule request, the request will be denied. ALLOW_TRANSFER_REQUESTS ={YES NO LOGON} When the Global ALLOW_TRANSFER_REQUESTS parameter is set to NODE, this parameter defines whether Transfer Schedule Requests initiated through TCP or SNA will be accepted. This parameter applies to the following MFT interfaces: Batch, Script, API, REXX and ISPF. This field applies only to transfers scheduled through SNA or TCP and does not apply to transfers scheduled through cross memory. This parameter does not apply to transfers managed by the MFT Command Center. The following values are accepted: YES NO This is the default value and indicates that TCP and SNA Transfer requests will be accepted. Indicates that TCP and SNA Transfer requests will not be accepted. Only requests initiated on the same server and

13 7 LOGON scheduled through cross memory will be accepted. Indicates that requests will only be accepted when local credentials are included with the transfer schedule request. ALLOW_MANAGE_REQUESTS={YES NO NODE} Defines whether Transfer Management Requests initiated through TCP or SNA will be accepted. This parameter applies to the following MFT interfaces: Batch, Script, API, REXX and ISPF. This field applies only to transfers managed through SNA or TCP and does not apply to transfers managed through cross memory. Management requests are typically ISPF or REXX Transfer inquiry. This parameter does not apply to transfers managed by the MFT Command Center. The following values are accepted: YES This is the default value and indicates that TCP and SNA Manage requests will be accepted. NO Indicates that TCP and SNA Manage requests will not be accepted. Only requests initiated on the same server and scheduled through cross memory will be accepted. NODE Indicates that the NODE ALLOW_MANAGE_REQUESTS parameter will define whether TCP or SNA manage requests will be accepted. If a NODE definition is not defined for an incoming

14 8 Manage request, the request will be denied. INITHOLD ={ YES NO} Defined whether Initiator requests for this this Node definition should be held when the Node is enabled. The following values are accepted: YES This value indicates that Initiator requests for this Node will not be executed. The INITHOLD can be reset through the ISPF NODE panel, the FUSNODE INITREL REXX exec or the INITREL operator command NO This is the default value and indicates Initiator requests for this Node will be executed. Nodes can be placed in Initiator Hold through the ISPF NODE panel, the FUSNODE INITHOLD REXX exec or the INITHOLD operator command INITIATOR_ERROR_HOLD={0-9999} When set to a non-zero value, this parameter determines the number of consecutive Initiator remote errors that will cause the node to be placed in an INITHOLD state. Each time an Initiator fails with a Remote non-recoverable error, a count is incremented by one. When the count exceeds the value defined for this parameter, the node will be placed in an INITHOLD state. Every time a Successful Initiator request is performed with this Node, the counter is reset. The default value of 0 indicates that the Node will not be placed into an INITHOLD state due to remote errors. The INITHOLD can be reset through the ISPF NODE panel, the FUSNODE INITREL REXX exec or the INITREL operator command. RESPHOLD ={ YES NO}

15 Defined whether Responder requests for this this Node definition should be held when the Node is enabled. The following values are accepted: YES This value indicates that Responder requests for this Node will be rejected with a recoverable error. The RESPHOLD can be reset through the ISPF NODE panel, the FUSNODE RESPREL REXX exec or the RESPREL operator command NO This is the default value and indicates Responder requests for this Node will be accepted. Nodes can be placed in Responder Hold through the ISPF NODE panel, the FUSNODE RESPHOLD REXX exec or the RESPHOLD operator command TCPCONNECT_ADAPTER_IPADDR_IPV4 ={IPV4 Address} When MFT initiates a connection request, it can bind the connection to a particular IP Address. This parameter can be used to override the adapter IP Address that will be used in the TCP Bind. This parameter is allowed when the Node defined an IPV4 Address or an IP Name. If the connection is for an IPV4 address, it will use the IP Address defined by this parameter in the TCP Bind. If this parameter is not defined, the Global TCPCONNECT_IPADDR_IPV4 parameter specifies the adapter IP address that will be used in the TCP Bind. If this parameter is not defined and the Global TCPCONNECT_IPADDR_IPV4 parameter is not defined, TCP will bind to all adapters. TCPCONNECT_ADAPTER_IPADDR_IPV6 ={IPV4 Address} When MFT initiates a connection request, it can bind the connection to a particular IP Address. This parameter can be used to override the adapter IP Address that will be used in the TCP Bind. This parameter is allowed when the Node defined an IPV6 Address or an IP Name. If the connection is for an IPV6 address, it will use the IP Address defined by 9

16 10 this parameter in the TCP Bind. If this parameter is not defined, the Global TCPCONNECT_IPADDR_IPV6 parameter specifies the adapter IP address that will be used in the TCP Bind. If this parameter is not defined and the Global TCPCONNECT_IPADDR_IPV6 parameter is not defined, TCP will bind to all adapters. New Operator Commands ENCRYPT Displays the hardware encryption that MFT can use on this processor. MFT can use either AES128 or AES256, although AES 256 is suggested. F FUSION,ENCRYPT INITHOLD modifies the defined node definition to turn on the Initiator Hold flag. This indicates that Initiator requests to this node will not be dispatched. The nodename parameter is required. F FUSION,INITHOLD,nodneame INITREL modifies the defined node definition to reset the Initiator Hold flag. This indicates that Initiator requests to this node will be dispatched. The nodename parameter is required. F FUSION,INITREL,nodneame RESPHOLD modifies the defined node definition to turn on the Responder Hold flag. This indicates that Responder requests from this node will be rejected with a recoverable error. The nodename parameter is required. F FUSION,RESPHOLD,nodneame RESPREL modifies the defined node definition to reset the Responder Hold flag. This indicates that Responder requests from this node will be accepted. The nodename parameter is required. F FUSION,RESPREL,nodneame

17 TRCLASSREFRESH Refreshes the Transfer Class configuration file defined by the TRCLASS DD Statement. This command is automatically executed at startup. If you make a change to the configuration file after MFT Platform Server is started, then you must execute this command to refresh the CFALIAS configuration file F FUSION,TRCLASSREFRESH TRCLASSDISP Displays the Transfer Class definitions. You can display the transfer class definition by entering a transfer class, or you can display all transfer classes by not entering a Transfer Class F FUSION,TRCLASSDISP[,trclassname] To display all transfer class definitions: F FUSION,TRCLASSDISP To display transfer class definitions for transfer class SINGLETHREAD: F FUSION,TRCLASSDISP,SINGLETHREAD New File Name Token: DateUS MMDDYYYY Example New Scripting Symbolic Parameter: %IDCAMS1 - %IDCAMS40 These variables are used by the CALLIDCAMS Script function and are cleared by the CLEARIDCAMS Script function. When used by the CALLIDCAMS function, they define the exact data that is passed to the zos IDCAMS utility. Remember that when calling IDCAMS, column 1 should be blank. IT is suggested that IDCAMS data be defined in columns New Script Functions: CALLIDCAMS CALLIDCAMS 11

18 12 Calls the zos utility IDCAMS. This function will pass the parameter values defined by the %IDCAMS 1 - %IDCAMS40 variables to the zos IDCAMS utility. The output of the IDCAMS utility will be displayed in the scripting SYSTRACE DD statement. Special variable %RC will be set with the code returned by the IDCAMs utility. Ex. SET %IDCAMS1 = " /* COMMENT LINE 1 */" SET %IDCAMS2 = " LISTCAT ENT(S7T.MFTTCB.AUDIT) ALL" SET %IDCAMS3 = " /* COMMENT LINE 3 */" CALLIDCAMS SAY Return code from CALLIDCAMS=%RC CLEARIDCAMS CLEARIDCAMS Clears the contents of all %IDCAMS variables. This can be used if you need to execute CALLIDCAMS multiple times and pass different data to IDCAMS. Ex. CLEARIDCAMS TRNWAIT {ALL TransId1 TransId2 TransId10} TRNWAIT allows you to wait for transfers to complete. You can wait for 1 to 10 transfers to complete by entering one or more Transaction Ids. Optionally, you can wait for all transfers that have been queued by this script instance to complete by specifying ALL. As transfers are queued, the scripting program keeps track of up to 200 transfers. TRNWAIT ALL will wait for all transfers to compete. If all transfers are successful, script variable %TRNSTAT will be set to SUCCESS. If any transfers failed script variable %TRNSTAT will be set to FAILED. Note that when using the TRNWAIT parameter to track transfers scheduled by the script interface, you should use SNA or TCP to communicate with the started task. New Batch Interface Parameters: MAINTAINBDW={ Yes NO }

19 13 This parameter defines the whether RECFM=VB BDW (Block Descriptor Word) will be maintained when sending or receiving files. This parameter should only be specified when the file being transferred is in a RECFM=VB format. The BDW and the RDW (Record Descriptor Words) will be maintained when sending to a remote system, or receiving from a remote system. If the data being sent or received is not in the proper BDW/RDW format, the transfer will fail. MAINTAINRDW=[YES NO } This parameter defines the whether RECFM=VB RDW (Record Descriptor Word) will be maintained when sending or receiving files. This parameter should only be specified when the file being transferred is in a RECFM=VB format. The RDW will be maintained when sending to a remote system, or receiving from a remote system. If the data being sent or received is not in the proper RDW format, the transfer will fail. TRCLASSNAME This parameter defines the Transfer Class Name. Transfer Classes are used to limit the number of concurrent transfers. Transfer Classes are defined in the TRCLASS DD statement. Transfer classed defined by this parameter should match a defined transfer class. If the transfer class is not defined, it will use the default Transfer class that allows unlimited concurrent transfers. Transfer Class Names are case insensitive and will always be displayed as upper case. Updated Batch Interface Parameters: DATASAET_TYPE=LARGE LARGE should be defined for disk datasets with more than tracks per volume. The default values tell MFT Platform Server to use the file type of the source file. WAIT={ASYNC ASYNCWAIT}

20 14 The WAIT parameter allows the user to tell the job to WAIT for the file transfer to finish before proceeding. If the user specifies WAIT=YES in the parameters of a batch job then the batch job will not continue processing until the transfer is complete. If the transfer does not complete successfully then the step will end and a return code will indicate the reason for the failure. WAIT=YES should not be specified when multitasking (that is, when you are using a distribution list). ASYNC Used for Directory transfers. The job will wait until all transfers have been scheduled. However the job will not wait for transfers to be completed. ASYNCWAIT Used for directory transfers only. Transfers will be submitted asynchronously and the job will not complete until all transfers have completed. Note that a maximum of 500 transfers will be submitted asynchronously. If more 500 transfers are submitted as a result of the directory transfer, transfers over 500 will be submitted with WAIT=YES. Note: When using ASYNC or ASYNCWAIT on a directory Receive: : You should not receive multiple files to a PDS. The PDS can become corrupted if multiple transfers write to the PDS at the same time. You should use WAIT=YES when writing to a PDS. : When receiving multiple files to a LIBRARY, the library must exist. It cannot be created by the transfer. New section added to the Installation and Operations Guide TRCLASS (Transfer Class) Configuration section added to the Installation and Operations User

21 15 Guide which describes the MFT Platform Server TRCLASS configuration. See section 14. FUSPING JCL Updated The PINGJCL member found in the MFT.JCL library has been updated to reference the new parameter TCPIPJOBNAME (TJ)

22 16 Changes in Functionality This section lists changes in functionality since the last release of this product. Release We have increased the maximum amount of nodes displayed through the MFT Platform Server ISPF User Interface from 500 to 4000.

23 17 Deprecated and Removed Features This section describes deprecated features (if any), and lists features, if relevant, that may be useful alternatives to the deprecated features. Any use of a deprecated feature should be discontinued as it may be removed in a future release. You should avoid becoming dependent on deprecated features and become familiar with the suggested alternative features. This section also lists features that are removed (if any). Release Deprecated Features Removed Features No features are removed in this release. No features are removed in this release.

24 18 Compatibility and Migration This section describes any compatibility or migration issues in this release. Release No compatibility or migration issues for this release.

25 19 Hotfixes This section lists the previous hotfixes released that have been included in this version of the product. Previous Hot Fixes Included: Hot Fix Number CZ01963 Problem Descriptions resolved within Hot Fix PSZ-102 REXX FUSSCMD SUBMIT function returns "SUBMIT invalid" PSZ-103 Resolves a problem where an abend 002 is received when the SYNAD routine is entered. The transfer will now terminate with an error indicating that the SYNAD routine was entered. Hot Fix Number CZ01962 Problem Descriptions resolved within Hot Fix PSZ-102 REXX FUSSCMD SUBMIT function returns "SUBMIT invalid" MFCC-1268 Resolves a problem where the %TRN token was ignored on a PPA using Fusutil to rename a file to include the %TRN token. Hot Fix Number CZ01947 Problem Descriptions resolved within Hot Fix

26 20 PSZ-96 Resolves a problem where the remote userid was being translated to lower case when defined by the Initiator Process statements and remote user was the same as the submitting user. This issue was partially resolved by hotfix CZ01933 when using the SERVER parameter to initiate file transfer requests. This hotfix resolves this issue when using TCP or SNA to initiate file transfer requests. PSZ-96 Resolves a problem where TCP SndBuf and RcvBuf socket parameters were not being set correctly when an MFT Class of Service was defined. Hot Fix Number CZ01946 Problem Descriptions resolved within Hot Fix PSZ-93 Resolved problems with the Scripting TRNWAIT function. Added "TRNWAIT ALL" to allow you to wait on up to 200 transfers. PSZ-92 RUSER is truncated at 8 characters in _FAIL and _GOOD. Hot Fix Number CZ01933 Problem Descriptions resolved within Hot Fix PSZ-89 Resolved problem where the remote userid was being translated to lower case when defined by the Initiator Process statements and remote user was the same as the submitting user. PSZ-88 Resolved problem where message PGTM7281E was displayed when sending a file with Extended Attributes using a DSCB8. PSZ-87 Issue PSZ-73 was fixed in hotfix CZ01923 but the fix was left out of hotfix CZ01928: Fix problem where transfers received abend 013-E1 when transferring LBI tape files. PSZ-86 Resolves a problem when sending VSAM datasets without specifying allocation parameters. When hotfix CZ01923 is applied only on the sending side, the receiving side incorrectly calculates the space allocation.

27 21 PSZ-85 Resolves a problem writing RECFM=U when Checkpoint is turned off. Records are incorrectly padded with nulls. PSZ-83 Resolved issue where DISP=DNEW was not deleting VSAM files. PSZ-74 Resolved an issue where an ENQ was not issued on the GDG base when creating a GDG file. Hot Fix Number CZ01928 Problem Descriptions resolved within Hot Fix PSZ-86 Resolves a problem when sending VSAM datasets without specifying allocation parameters. When hotfix CZ01923 is applied only on the sending side, the receiving side incorrectly calculates the space allocation. PSZ-85 Resolves a problem writing RECFM=U when Checkpoint is turned off. Records are incorrectly padded with nulls. Hot Fix Number CZ01923 Problem Descriptions resolved within Hot Fix PSZ-80 Receive intermittent abend 0C4 in module FUSIONIO on EOV (End of Volume) processing when new tapes are mounted. PSZ-79 Receiving PGTF4684E out of space errors on transfer of VSAM KSDS datasets from the ISPF interface. PSZ-78 Transfer fails but still catalogs GDG generation when RDISP=(NEW,CATLG,DELETE) is specified PSZ-75 Resolved two issues with space allocation on VSAM files: 1. When sending a VSAM file, space used was calculated incorrectly. 2. When creating a VSAM file with kilo-byte or mega-byte allocation, the file is allocated with too much space.

28 22 PSZ-73 Fix problem where transfers received abend 013-E1 when transferring LBI tape files when CKPT restart is turned off. PSZ-72 Quotes are incorrectly removed from from the Remote command parameter. PSZ-71 Made changes to the FILE_EXPDT parameter(yyddd or CCYYDDD). : Allow the user to enter 000 for the DDD : When a 5 digit date (YYDDD) is entered, set CC to 20 PSZ-70 When initiating a file transfer and the Local file is not defined, the started task can receive an abend 282. PSZ-68 When initiating a directory send or directory receive, VSAM files were not transferred. Two new parameter values were added to the SUBDIR parameter. : SUBDIR=ALL Include Sequential, PDS and VSAM files : SUBDIR=SEQVSAM Include Sequential and VSAM files PSZ-66 When initiating a receive for a DBCS file and the XLATE table is defined as SOSI=NONE, an 0C4 or S378 exception can occur. PSZ-64 When MFT transfers a file with RECFM=VBS and LRECL>32760, the receiving file is created with LRECL=32760 and no informational message is generated indicating the change to the LRECL. PSZ-54 When Command Center collects Audit records from zos Platform servers, the Node Name is truncated to 8 characters. PSZ-53 When a transfer is executed with DISP=DNEW and the request fails because the target file is in use, the transfer is not retried and no message is displayed indicating the cause of the failure. PSZ-47 When checkpoint restart is turned on for RECFM=V/VB transfers, the blocksize is not filled to its maximum. This causes more space to be used and sometimes causes an x37 abend. PSZ-15 Message PGTE3840I Rename target DSN can be truncated. Hot Fix Number CZ01916 Problem Descriptions resolved within Hot Fix

29 23 PSZ-45: Added the following GLOBAL Parameter: TAPE_SECURITY_EXIT={ERROR IGNORE} Defines the processing when the SMS Tape Security Exit is invoked when a tape is mounted that has not expired: ERROR: Reject the tape mount. The transfer is terminated with an abend This error is considered a retry-able error. This is the default value. IGNORE: Performs the default SMS operation. Some tape management products will accept the tape mount. Others will take the SMS default and ask for a new tape mount. PSZ-44: Receive the following message when an error is detected on a UNIX or Window platform and the error message returned is longer than 240 bytes: PGT1004E TLV VARIABLE INVALID LENGTH Messages longer than 240 bytes will now be accepted and truncated to 240 bytes. PSZ-43: Resolve an 0C9 abend that can occur when the NODE BPS_SEND or BPS_RECV parameters are defined to limit the bandwidth used. This problem occurs intermittently when these parameters are set to a value greater than 20,000,000, although it is possible to receive this abend when the values are set lower. PSZ-42: When a Send transfer is initiated and the local file is not found, the transfer will terminate before starting the connection to the transfer partner. An Audit record will be written. Prior to this change, the transfer was initiated to the partner. Hot Fix Number CZ01903 Problem Descriptions resolved within Hot Fix PSZ-41: Platform transfers initiated by Command Center fail when using a Responder Profile on z/os PSZ-38: Resolves a 0E0 abend in module FUSASEND when Access Register 1 is corrupted by 3rd party software. PSZ-37: Resolves a problem when an error message is received from a transfer partner that exceeds 120 bytes, the message displayed is truncated at 120 bytes.

30 24 PSZ-35: Display a more descriptive message when abend is received. PSZ-34: Resolves problems with the following parameters when collected by MFT Command Center: Delimiter(LF) and Type (Text/Binary). PSZ-33: Resolves a problem where Active and Inactive transfers were incorrectly returned on the ISPF "Manage File Transfers" page when the Remote Transaction Number was entered. PSZ-32: Resolves a problem where message "PGT1002I" is displayed when initiating a request to a Windows Platform Server. PSZ-31: Resolved problem on the ISPF Transfer Audit detail page where the Compressed Byte count is displayed incorrectly when the compressed byte count exceeds 2GB. PSZ-25: Added support to the FUSUTIL utility to DELETE or RENAME migrated datasets. PSZ-22: Resolved a problem with managing a z/os Platform Server from Command Center when the z/os password has lower case characters. PSZ-16: Adds new Transfer parameter: CRLF=USSLF. This parameter allows you to send a z/os DSN to a z/os USS file and terminate the USS file records with an ASCII LF (0x0A). PSZ-13: Resolved a problem where message PGTM7247E was incorrectly issued when the local file name was too long. Hot Fix Number CZ01900 Problem Descriptions resolved within Hot Fix PSZ-8 : Added a new value to the batch SENDRECFMU parameter: NOBDW SENDRECFMU={YES NO NOBDW} Default=NO : When YES is specified for a SEND, the file will be opened using RECFM=U. Each block will be written as an individual record. The main usage of this parameter is to retain the RECFM=VB block and record structure when sending to a UNIX or Windows platform.

31 : When NOBDW is specified for a SEND, the file will be opened using RECFM=U. Each block will be written as an individual record. This parameter is the same as YES, except that the BDW is not sent. Note: This parameter should only be used when TYPE=BINARY is specified 25 Hot Fix Number CZ01874 Problem Descriptions resolved within Hot Fix Default for SUBGOOD and SUBFAIL incorrectly references token #(TR). The correct token is #(TID). 0C4 abend at OSISGLBL+ADC0 occurs when trying to display message PGTS1502I at startup XCOMJOB alias for member FUSXJOB was corrupted When queuing transfers through Cross memory and using the LOCAL_USER (LUSER) parameter, the authorization check is incorrectly performed against the user that submitted the request, sometimes resulting in an Authorization error. ISPF Local File Name was translated to upper case incorrectly. This caused problems when transmitting HFS files. Hot Fix Number CZ01871 Problem Descriptions resolved within Hot Fix Resolves a dynamic allocation error when VSAM MAXLRECL > Transfers will now fail if the VSAM MAXLRECL is > C4 abend received under following circumstances: : Transfer is using compression : Transfer starts sending compressed bytes : Transfer terminates with an error

32 26 Hot Fix Number CZ01869 Problem Descriptions resolved within Hot Fix Fixes a problem where PPA defined in DNI members enabled at startup only get executed for the first DNI member enabled. If you disable and enable the DNI member, PPA is executed. Resolves an 0C4 abend when the VSAM MAXLRECL is > Transfers will now fail if the VSAM MAXLRECL is > Hot Fix Number CZ01866 Problem Descriptions resolved within Hot Fix Resolves a loop that occurs under the following conditions: : Send a PDS or PDSE with a wildcard in the local file name : The Sender is not authorized to access the input dataset

33 27 Closed Issues The table in this section lists issues that were closed in the named releases. Release Closed in Release Issue # Summary

34 28 Known Issues This table in this section lists known issues in this release. Issue # PSZ-146 Summary Summary: MFT PS for z/os does not support VBS datasets containing logical records with a length greater than 32K. Workaround: Use a utility such as AMATERSE to pack the dataset into a format that can be transmitted by MFT PS for z/os. Transmit the file. Unpack the target file.