DevOps Tricks: How to Migrate From a z/OS System to zD&T


DevOps—or development operations—is an approach to continuous software delivery through automation and collaboration. IBM z Systems Development and Test environment (zD&T) simplifies infrastructure requirements for mainframe development and testing by providing an identical mainframe-like environment that runs on Linux in x86 architecture. It’s possible to migrate z/OS from a host mainframe to zD&T or use Application Developers Controlled Distributions (ADCD) with zD&T. In this article, we will discuss how we migrated a z/OS system from host mainframe to zD&T.

The high-level steps in migrating a z/OS system to zD&T are:

  • Device map customization
  • Network customization between Linux and zD&T
  • Moving DASD volumes to zD&T

The z/OS system that we migrated from the host mainframe is a small monoplex. It’s spread over five mod-9 DASD volumes, one of which is SMS managed, and has a CICS region and a DB2 subsystem. In this article, we will refer to this system as the “host z/OS system,” or the “host z/OS.” The host z/OS system after migration to zD&T will be referred to as the “zD&T z/OS system,” or “zD&T z/OS.” When we had to make changes to PARMLIBs, VTAMLST or any other PARMS, we did so in the host z/OS system before moving the DASD volumes to zD&T.

Device Map Customization

A device map (devmap) is a text file used by zD&T to define devices and resources like RAM and CPU, available to z/OS that will be run. A devmap is similar to the Input Output Control Program input file, which can be used to build Input Output Configuration Data Sets for Power-on Reset of the mainframe. However, devmap has other details like RAM and CPU (including specialty engines) that are typically found in LPAR image profile in Hardware Management Console.

A z/OS system running on zD&T uses devmap and overrides definitions in Input Output Definition (IODF) data sets used for IPL. In devmap, it’s essential to match the device numbers of DASD, consoles, non-SNA terminals for time sharing option (TSO) logons and Open System Adapter-Express with what is specified in the current IODF used by the z/OS system for IPL.

In the host z/OS system, relevant master console definitions in CONSOLxx in PARMLIB are:


The host z/OS system uses 3390 mod-9 DASD devices with device address ranging from C100 to C104, where C100 is the system resident volume (SYSRES) and C101 is the IODF volume.

In the host z/OS system, definitions in VTAMLST for non-SNA terminals for TSO logon are:

EXLOCAL  LBUILD                                                

The host z/OS system uses OSA express in QDIO mode for TCPIP communication.

Corresponding TRLE definitions in VTAMLST are as follows:


The contents of LOADxx PARMLIB member in the host z/OS system are:

IODF     13 SYS1     ZOS      01                                     
INITSQA  0002M 0016M                                                 
IEASYM   (00,P0)                                                     
PARMLIB  SYS1.ZDT.PARMLIB                       
PARMLIB  SYS1.PARMLIB                           
PARMLIB  SYS1.IBM.PARMLIB                       
PARMLIB  USER.PARMLIB                           
SYSPARM  (P0,L)                                                      

To make the host z/OS system run on top of zD&T, no changes were made to CONSOLxx, LOADxx, non-SNA terminal definitions/TRLE definitions in VTAMLSTs or the IODF data set. We wanted to run zD&T under Linux User ID “ibmsys1.” Using this same User ID, we created devmap and defined the following for the host z/OS system to run under zD&T with three GB RAM and one CPU:

memory 3072m
processors 1
3270port 3270 # port number for non-SNA 3270 thru aws3274

name aws3274 0001 # non-SNA terminals for console & TSO logon
device 4100 3279 3274 mstcon        	# master console
device 4101 3279 3274 tso 		# for TSO logon

[manager] # define network adapter (OSA) for communication with Linux#
name awsosa 0024 --path=A0 --pathtype=OSD --tunnel_intf=y # QDIO mode
device 2400 osa osa
device 2401 osa osa
device 2402 osa osa

name awsckd 0002 # DASD definitions
device C100 3390 3390 /z/ibmsys1/z1090/disks/ZDTRS1
device C101 3390 3390 /z/ibmsys1/z1090/disks/ZDTSS1
device C102 3390 3390 /z/ibmsys1/z1090/disks/ZDTMS1
device C103 3390 3390 /z/ibmsys1/z1090/disks/ZDTOMV
device C104 3390 3390 /z/ibmsys1/z1090/disks/ZDTSMS

Mainframe OSA express console controller is typically used to get non-SNA terminals for consoles and TSO logon, whereas in zD&T, we can get non-SNA terminals with the help of the aws3274 device manager. In the above devmap definition, the port number in which the aws3274 manager should listen is mentioned in the [system] stanza by the “3270port statement,” which is 3270 (default).

Arunkumaar Ramachandran is a Senior IT Specialist at IBM India Software Labs. His areas of expertise include z/OS and z/VM. Arunkumaar can be reached at

Like what you just read? To receive technical tips and articles directly in your inbox twice per month, sign up for the EXTRA e-newsletter here.

comments powered by Disqus



2017 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

Modernizing Your Enterprise

IBM has business-value-driven solutions to improve application and employee productivity

Leveling the Playing Field

IBM Rational software advances mainframe development

The Agile Enterprise and Beyond

Proper tools can bring flexibility to application development

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
Mainframe News Sign Up Today! Past News Letters