IBM Support

Enhanced Customer Data Repository (ECuRep) - z/OS Help

General Page

Help page for ECuRep transfer of z(OS debug data


 

Using IBM PDUU for z/OS earlier than 1.13

For earlier releases, see the IBM z/OS Problem Documentation Upload Utility (IBM PDUU) page for directions to manually install and use this utility (MTFTPS module).

 

IBM PDUU for z/OS 1.13 and later releases

If the system is running z/OS 1.13, see the MVS Diagnosis: Tools and Service Aids manual (PDF,3.38MB) for directions on how to use this IBM PDUU utility, for example AMAPDUPL module (go to chapter 18).

 

IBM PDUU and compression

Be aware of that IBM PDUU uses an internal compression feature prior of transferring data to IBM. Use of extra file compression tools like AMATERSE is not necessary, nor recommended when using IBM PDUU.

 

IBM PDUU parallel sessions

Start with three or four parallel FTP sessions. Too many parallel FTP sessions can saturate the network link.
For further hints and tips, consult the MVS Diagnosis: Tools and Service Aids manual (PDF,3.38MB) (go to chapter 18).

 

IBM PDUU amount of work data sets

Use medium size work data sets.
If the work data sets are small in relationship to the input data set, you can end up with too many files on the IBM FTP sites.
For example, if you are sending a 100 GB z/OS stand-alone dump and make the work data set size 1 MB, you create 100,000 files on the IBM FTP site. This exceeds the IBM limit of 999 files.
This setting also causes much delay by starting and stopping the FTP sessions for each file.
For further hints and tips, consult the MVS Diagnosis: Tools and Service Aids manual (PDF,3.38MB) (go to chapter 18).

 

IBM PDUU encryption password

It is not recommended to use plain, unencrypted FTP transport method in IBM PDUU anymore with using password data encryption anymore. It is a manual and error-prone process to provide the password separately to IBM and also for IBMs SR to process the data.
The recommendation is to use IBM PDUU with HTTPS transport encryption without password data encryption.
Refer to the links provided in section "IBM PDUU - HTTPS upload support"
(manual use of secure FTPS for PDUU without password encryption might also be possible to fulfill security guidelines, but without further guidance, because setting that up is individual based on client infrastructure)

If it is still needed temporarily, be aware of, that the password used for optional encryption is case-sensitive.
Accordingly, inform your IBM SR separately and in a secure way.
For further hints and tips, consult the MVS Diagnosis: Tools and Service Aids manual (PDF,3.38MB) (go to chapter 18).

 

IBM PDUU - IBM My Support case support

When using AMAPDUPL with a My Support Case number instead PMR number fails with message AMA756E :
Refer to IBM Technote, in order to get IBM My Support case support for IBM PDUU

IBM PDUU - HTTPS upload support

Support for new HTTPS transfer protocol
Refer to PDUU documentation and according to IBM Technote.


More hints and tips for using HTTPS upload by using IBM PDUU

  • Correct Certificates must be in Keyring
    Refer to our  Send Data - HTTPS page for the needed certificates and according download links
     
    You need to download one or more certificates and put them in your security product database (for instance, RACF)
    Normally, you would then connect it to the keyring used by the PDUU job.
    Or, if using CERTAUTH virtual keyring , that is HTTPS_KEYRING=*AUTH*/*)
    This setting means that you only need to get this cert into RACF, make sure it is TRUSTED.
    If the DIGTCERT and DIGTRING classes are RACLISTed on your system, refresh the classes and you can do so with command:                                                                                
    SETROPTS REFRESH RACLIST(DIGTRING,DIGTCERT)
     
  • TLS 1.2 and current ciphers must be configured
    If getting  '402 No SSL cipher specification' error, ensure that current TLS version and ciphers are used.
     
    AMAPDUPL using HTTPS ends up using the default CIPHERs for the secured connection; the default CIPHERS are 3538392F3233 (6 2-character cipher numbers)
    Configurable ciphers are listed in the 'z/OS Cryptographic Services System SSL Programming' manual.
     
    As Default ciphers are considered weak, try to add the following DD card to your AMAPDUPL step
    "
    //CEEOPTS DD *                         
     ENVAR(GSK_V3_CIPHER_SPECS=3D38392F3233,GSK_PROTOCOL_TLSV1_2=ON)
    "
    The above example ensures usage of TLS1.2 protocol and more importantly, adding a more secure cipher to cipher defaults so at least one of them ('3D') would be (currently) accepted by ECuRep HTTPS upload site (at time of publishing this).
    '35' (not accepted anymore by ECuRep) was simply replaced with '3D' (assumed as secure at date of publish)
    '3D' is cipher 'TLS_RSA_WITH_AES_256_CBC_SHA256'

IBM z/OS special Data handling

Notes for sending z/OS-related special dataset types:  
 
  1. SMF data
    To prevent problems with SMF data, which is mostly in SPANNED record format where the logical record length may be larger than the dataset’s blocksize, adhere to the following procedure:  

    • Due to the mostly large amount of data, select ONLY the NEEDED and USEFUL
    record types when creating the unloaded SMF data.
     
    • Use the TSO TRANSMIT command to convert your unloaded SMF data into the TSO XMIT format, for example : 
    TSO XMIT yournode.youruser DA('yoursmfdsn') OUTDATASET('yoursmfdsn.XMI')
     
    • Now TERSE the output dataset and name it: 'yoursmfdsn.XMI.TRS'
     
    • Transfer this TERSED file to ECuRep upload site and ensure to use the correct naming conventions
     
  2.  Other data with special record format (for example Fault Analyzer History file)
    Handle this data exactly as described under “SMF data”.
     
  3. GDG’s (Generation Data Group’s)
    When there is a need to transfer one (or more) GDG-format dataset(s):
     REMOVE or RENAME the GDG-typical qualifier GnnnnVnn  from the data set name, so that this data set name cannot anymore be identified as a GDG.

    Reason:
    when a tersed GDG dataset is turned back to its original format, MVS would encounter the GDG-typical qualifier and would try to allocate a GDG dataset as well – which fails because the GDG base is not available on the ECuRep MVS system.
    This would inhibit automatic processing of that dataset.
     
  4. Using DFSMSdss DUMP (ADRDSSU)
    When using DFSMSdss (ADRDSSU) to DUMP one or more datasets, be SURE to LOGICALLY dump your data set(s) – do NOT use PHYSICAL dump.

Related links

[{"Type":"MASTER","Line of Business":{"code":"","label":""},"Business Unit":{"code":"","label":""},"Product":{"code":"ECUREP","label":"ECuRep notice"},"ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]

Document Information

Modified date:
29 November 2021

UID

ibm10739575