Prerequisites

Learn about hardware and software requirements for ZD&T Enterprise Edition.

For a complete list of ZD&T hardware and software requirements, you can generate the report from Software Product Compatibility Reports. Hardware and software requirements are also documented in the zPDT® Guide and Reference.

z/OS system requirements

If you want to extract volumes from z/OS® systems, the following requirements are needed.

Required
  • An SSH server must be running and accessible by the system to run Enterprise Edition.
  • The FTP or SFTP client must be able to connect to the Enterprise Edition storage server.
  • To use SFTP, Java™ 1.6 or later versions must be installed, and the PATH needs to be pointed to the bin directory of the Java installation.
  • Make sure to grant access to each volume or data set that is extracted. For more information, see Creating components from IBM Z® mainframe volumes and Creating components from IBM Z mainframe data sets.
  • Make sure to grant READ access to DFDSS program ADRDSSU.
Optional
  • Configure zEnterprise® Data Compression (zEDC) if it is available. Grant READ access to the resource FPZ.ACCELERATOR.COMPRESSION in SAF class FACILITY to the user ID that is used in the Enterprise Edition.
  • Grant READ access to resource STGADMIN.ADR.DUMP.CNCURRNT in SAF class FACILITY.

Storage server requirements

To install and run ZD&T Enterprise Edition, a storage server to host the Enterprise Edition artifacts, such as z system volumes, data sets, Enterprise Edition metadata, must be set up. To transfer volumes images files from the storage server or to the storage server, you can choose FTP or SFTP as the transferring method.

  • Disk space
    • Sufficient space is needed to hold numerous and potentially large files for extracted IBM® Z volumes.
    • 150 GB of disk space is needed for ADCD z/OS V2.4 distribution.
  • Software requirements
    • A running FTP or SFTP server
  • FTP server
    • Enable passive mode by configuring PASV_ENABLED=YES in the vsftpd.conf.
    • Set SElinux to Permissive or Disabled mode.
    • Open firewall ports for FTP command and data channels.
  • SFTP server
    • Open the firewall port for SFTP command.

Linux target environments requirements

To automatically deploy images to a Linux® target environment, the following requirements are needed.
  • If you choose to install the required Linux packages during the deployment, the software repository needs to be available and accessible by the target environments.
    • A Red Hat® software repository for 'yum' needs to be available and accessible by the target environments.
    • An Ubuntu software repository for 'apt-get' need to be available and accessible by the target environments.
  • An SSH server must be running on the target environments and accessible by the system to run Enterprise Edition.
  • The command ftp client must reside on the target environments.
  • The root permission is needed for the users who are responsible for deployment.
  • An extra 100 M of disk space is needed for the folder /root in the target environment, as the loadparm.txt that is generated for a script to modify z/OS parameters might cause space problem.
Note: ZD&T Hardware-Based and Software-Based License Server installation options open the ports 1947, 3270, 9451 and 9450 to communicate between License server and Terminal emulator. You need to remove any restriction that might prevent the installer from opening the ports cannot be on your Linux machine. To deactivate any firewall that is active, or ask your network administrator to deactivate the firewall. For more information about the opened ports, see Firewall ports list.
  • Accessing to software repository to run YUM or apt-get commands

    Make sure that you have access to software repository to run YUM commands on RHEL machine, or run apt-get commands on Ubuntu machine. ZD&T installer will install all required packages. However, if you don't want ZD&T installer to install the required packages that are listed below, you need to install the packages before you start ZD&T installer.

    • YUM commands on RHEL operating system
      yum -y install iptables
      yum -y install ftp
      yum -y install libstdc++.i686
      yum -y install perl 
      yum -y install zip 
      yum -y install unzip 
      yum -y install gzip 
      yum -y install bc
    • apt-get commands on UBUNTU operating system
      apt-get -y install iptables
      dpkg --add-architecture i386
      apt-get -y update
      apt-get -y install libc6:i386 libncurses5:i386 libstdc++6:i386 lib32z1 lib32stdc++6
      apt-get -y install ftp
      apt-get -y install perl
      apt-get -y install zip 
      apt-get -y install unzip
      apt-get -y install gzip
      apt-get -y install bc
      apt-get -y install libasound2
      apt-get -f install
    Note: The 'nc' command is not available by default on the RHEL 7.4 and 7.5. As the 'nc' command is required to pass the validation before you start a deployment to the target environment, the missing command 'nc' might cause the failure of the connection. To install the command, run the following command.
    yum -y install nc
  • Users and group settings
    Before you deploy images, make sure to create a new group 'zpdt' in the target environment if the group does not exist.
    • If you use the root user ID to deploy images, create a user ID 'ibmsys1' if the user ID does not exist, and assign the user ID 'ibmsys1' to the group 'zpdt'.
    • If you use a non-root user ID to deploy images, assign the user ID to the group 'zpdt'.
  • Sudo access configuration

    The term sudo stands for super user do. Sudoers is the configuration file with the corresponding operating system sudo settings. This file is typically at /etc/sudoers. For more information about the specific sudoers file format, see Sudoers Manual.

    The following code shows an example of a sudoers entry.
     ibmsys1 ALL = (root) NOPASSWD: ALL

    In the code example, user ibmsys1 can access any shell script file on any host in any location as the root user without providing an identification password.

    During the deployment, Enterprise Edition runs several scripts that require the root access. For the security reasons, Enterprise Edition also changes the ownership of the scripts to the root user ID. The user ID that is used for the deployment needs to have the permission to run the scripts and change the ownership of the scripts. The scripts list is shown as below.
    [deployment directory]/zdt/zdtInstall/zdt_install_product_byRoot.sh
    [deployment directory]/zdt/zdtInstall/zdt_modify_files_byRoot.sh
    [deployment directory]/zdt/zdtInstall/zdt_install_dependencies_byRoot.sh (optional)
    [deployment directory]/zdt/zdtInstall/zdt_config_user_byRoot.sh (optional)
    [deployment directory]/zdt/zdtInstall/zdt_config_network_byRoot.sh (optional)
    [deployment directory]/zdt/zdtInstall/zdt_cleanup_byRoot.sh (optional)

    The deployment directory is an optional input value that can be specified from web user interface or REST API. By default, the deployment directory is /home/ibmsys1 if you log in as the root user, and /home/[userid] if you log in as a non-root user.

    The following code shows an example of the sudoers entry. The user ID that is used is ibmsys1, and the deployment directory is /home/ibmsys1.
    ibmsys1 ALL=(root) NOPASSWD: /bin/chown root /home/ibmsys1/zdt/zdtInstall/zdt_modify_files_byRoot.sh,
    /home/ibmsys1/zdt/zdtInstall/zdt_modify_files_byRoot.sh,
    /home/ibmsys1/zdt/zdtInstall/zdt_install_dependencies_byRoot.sh, 
    /home/ibmsys1/zdt/zdtInstall/zdt_config_user_byRoot.sh, 
    /home/ibmsys1/zdt/zdtInstall/zdt_install_product_byRoot.sh, 
    /home/ibmsys1/zdt/zdtInstall/zdt_config_network_byRoot.sh, 
    /home/ibmsys1/zdt/zdtInstall/zdt_cleanup_byRoot.sh

    If you use other privilege management tools other than sudo, you also need to do the configuration.

  • Network configuration

    To make other systems communicate with your emulated z/OS, you need to configure the emulated environment to ensure that the emulated environment can be accessible. The only requirement is to route a port number to port 22 on the emulated z/OS. The port number to be routed is the one that you will specify when you configure the source system on the ZD&T web server.

    To configure the network, complete the following steps:
    1. Back up the current iptables rules.
    2. Run the following commands. For example,
      iptables --table nat --append POSTROUTING --out-interface eth1 -j MASQUERADE
      iptables --table filter --append FORWARD --in-interface tap0 -j ACCEPT
      iptables --table filter -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
      iptables -A PREROUTING --table  nat -i eth1 -p tcp --dport 2022 -j DNAT --to 10.1.1.2:22
      iptables -A FORWARD -p tcp -d 10.1.1.2 --dport 2022 -j ACCEPT
    3. Run the command echo 1 > /proc/sys/net/ipv4/ip_forward.
    Note:
    • eth1 is an example of the network interface name. To find available network interfaces, run the command ifconfig, ip -o address show, and so on.
    • 2022 is the port number that will be routed to port 22.
    • 10.1.1.2 is the IP address of network interface tap0, which can be found by running the command find_io.

OpenStack Cloud target environments requirements

Make sure that the default security group of the OpenStack Cloud contains the rules that enable all the required ports of a target environment. For more information, see Firewall ports list.

Docker target environments requirements

In a normal Docker setup, a container image is pushed to a remotely accessible Docker registry. Then, the container image can be pulled by instances that need to run the image by using the Docker command-line utilities such as docker pull or docker run.

ZD&T Enterprise Edition 13.0 provides a container image that is named wazi-sandbox to run an emulated z/OS environment in a container. To use the container image, complete the following steps.
  1. Use HTTPS that is protected by using the TLS cryptographic protocol to communicate to the Docker daemon.
  2. Load the image directly to the local Docker image registry of the system that is running the container.
  3. Create the container from the image in privileged mode with a small set of port bindings. A Docker volume that contains all the persistence data such as volumes will be run on the emulator.
When the wazi-sandbox container is started, ZD&T Enterprise Edition can use the function ZD&T Instance Controller that is provided by the container to configure the emulator, acquire the ZD&T image, start the emulator, and finally perform the IPL of z/OS.

To complete the task, the following initial setup needs to be done before you create a deployment.

  • Configuring the Docker daemon for HTTPS communication

    To configure the Docker daemon for HTTPS communication, refer to the instructions in the Protect the Docker daemon socket.

    After the Docker daemon is configured for HTTPS communication by using the TLS cryptographic protocol, save the files for the CA certificate (ca.pem), server certificate (cert.pem), and client certificate (key.pem).

  • Planning the port mapping for Docker containers

    Each Docker environment supports a maximum of five containers. In a Docker environment, each container runs their own emulated z/OS instances and will be allocated 100 ports for clients to access services on each of those emulated z/OS instances. The entire set of ports for all the containers (up to a maximum of five) must be contiguous and specified in intervals of one hundred. The ephemeral port range is recommended.

    For each container, the following port mapping is in place:
    • xxy00 maps to port 3270 in the container
    • xxy21 maps to port 21 (FTP) in the container
    • xxy22 maps to port 22 (SSH) in the container
    • xxy23 maps to port 23 (Telnet) in the container
    • xxy99 maps to port 8443 (ZD&T Instance controller) in the container

    Where xx is the number in the thousands and y is the number in the hundreds.

    For example, if you plan to use 40000 as the start port and provision two Docker containers, the first container that is provisioned will use ports 40000 - 40099 and the second container that is provisioned will use ports 40100 - 40199.

    The first provision to a container has the ports 40000 - 40099 from the hosting system that is allocated to it and has the following port mappings:
    • 40000 → 3270
    • 40021 → 21
    • 40022 → 22
    • 40023 → 23
    • 40099 → 8443

    The second container will have the following port mappings:

    • 40100 → 3270
    • 40121 → 21
    • 40122 → 22
    • 40123 → 23
    • 40199 → 8443

Db2 extraction requirements

Db2® table extraction uses the following standard Db2 utilities and functions.
  • Db2 REXX Language Support (DSNREXX).
  • Stored Procedure DSNWZP for using the Db2 Admin Tool.
  • Stored Procedure DSNUTILU for running Db2 online utilities.
To extract data from a Db2 table, you must ensure that all these utilities are available on the source system. DSNUTILU and DSNWZP also require z/OS Workload Manager (WLM) application environments. To define these utilities, you can use the following Db2 installation jobs that are typically run during the Db2 installation.
DSNTIJTM
This job can be used to bind DSNREXX.
DSNTIJRT
This job can be used to define the Db2 routines DSNUTILU and DSNWZP.
DSNTIJRW
This job can be used to define and optionally activate Workload Manager application environments that are needed for DSNUTILU, DSNWZP, and other Db2 WLM environments.
  • User Access
    To use the user ID that is specified on the source system to extract Db2 data, you must ensure that the user ID has the following access.
    • Read access to the Db2 catalog tables.
    • Read access to the tables that are selected for an extraction.
    • Unload access to the tables that are selected for an extraction.
    • Authority to stop Db2 UNLOAD utilities.
    • If you need to use the Db2 Admin Tool, the user ID that runs the extraction must have the Db2 or RACF® access to run the DDL Generation Plan, for example, ADB2GEN.
  • System Libraries

    REXX.SEAGALT or REXX.SEAGLPA must be in the system search order, that is, Linklist or LPA.

  • Db2 Admin Tool

    To obtain the source database DDL, the Db2 Admin Tool must be installed and available. If the Db2 Admin Tool is not available, you must supply and verify all DDL source. The database DDL that is created on the target system must be compatible to Db2 supplied sample DSNTEP2.

Restriction:

ADCD z/OS V2R4 May Edition of 2020 is distributed with Db2 V12 at Function Level 506 (V12R1M506). Beginning at Function Level 504, applications that are bound at this function level or higher no longer support segmented (non-UTS) and partitioned (non-UTS) tablespaces. If Db2 table extraction is performed from a source system where tablespaces are deprecated types, where Db2 Admin Tool is used to create DDL for the component, and where Db2 and Db2 Admin Tools are not at levels to support Function Level 504 or higher, the deployment of the Db2 component might fail when Db2 objects are created.