Data Migration and Masking

There are a number of approaches you can take to setup your PopUp with compliant data. You may wish to migrate applications and data to the PopUp, and/or mask the data in-place or during migration. All of these are possible with PopUp Mainframe. The various approaches are described below.

Data Migration from LPAR to PopUp

To populate your PopUp with applications and data, it is necessary to copy application libraries and associated data from your physical mainframe to your PopUp.

There are a number of ways to do this including IBM Migration Utility, Connect:Direct, and FTP / FTPS. The choice will largely be dependant on the tools available and the amount of data to transfer. We recommend using IBM Migration Utility, for a simple and repeatable process (a hybrid approach may also be appropriate).

Where an entire z/OS LPAR is being migrated, a common approach is to create FlashCopy copies of the source volumes and use the IBM Migration Utility to transfer the copied volumes to the target environment. This enables large-scale migrations to be performed from a consistent point-in-time image.


Data transfer process using IBM Migration Utility

The transfer process requires a few setup activities before the data is moved. It is summarized below.

A. Setup

  1. Determine which data on the physical mainframe needs to be transferred to the PopUp.
  2. Install the IBM Migration Utility.
  3. Allocate one or more dedicated “Transport Volumes” on your physical mainframe.
  4. Install PopUp Auto Migration & Data Corraling tool (optional).

B. Transferring the Data

  1. Corral all required data to these transport volumes, typically using the PopUp Auto Migration & Data Corraling tool.
  2. Initiate the data transfer via Linux server.
  3. De-corral the data on the PopUp.
  4. Repeat steps 5-7 until all data is transferred.

The steps are described in detail below.


A. Setup

1. Determine the scope of the Migration "Project"

Before starting a migration, a good understanding of the applications and the scope of the work is needed.

Documenting all application libraries and any data requirements will form the basis of a swift and successful data migration.


2. Install IBM Migration Server Utility on Physical Mainframe

To install the IBM Migration Server Utility:

  • A transfer file, ZOSSERV.XMIT , is shipped with the PopUp and should be transferred to your mainframe in binary mode. The file should be uploaded, typically using 3270 file transfer, with the following attributes RECFM=FB, LRECL=80, BLKSIZE=3120.
  • Allocate a load library e.g. ABCD01.MIGSERV.LOAD with attributes LRECL=0,BLKSIZE=32760,RECFM=U.
  • In TSO/ISPF option 6 enter the command: RECEIVE INDATASET('ABCD01.XMIT’) and when prompted enter DATASET(‘ABCD01.MIGSERV.LOAD’)
  • The load module in ABCD01.MIGSERV.LOAD is ZPDTMSRV. This needs to be moved into an APF Authorised library OR the library itself needs to be added temporarily or permanently to the APF Authorised list.
  • A job will need to be created to run ZPDTMSRV. The job will start ZPDTMSRV as a long running job but this program will automatically end if there has been no volume transfer activity for 10 minutes.

Typical JCL:

//MIGSERV JOB 0,'ZDNT MIG',CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID,
//     TIME=1440 
//*                                                         
//MIGRATE  EXEC PGM=ZPDTMSRV,REGION=0M,PARM=3990             
//STEPLIB  DD DISP=SHR,DSN=an.apf.auth.LOADLIB           
//SYSPRINT DD SYSOUT=*                                       
//SYSUDUMP DD SYSOUT=*                                       
//SYSTCPD  DD DISP=SHR,DSN=SYS1.Z23B.TCPPARMS(PROF2)        
//

Typically, the Migration Utility, ZPDTMSRV , listens on port 3990 (PARM=3990 , above). Multiple jobs can run in parallel, however, depending on the throughput required.


3. Allocate dedicated DASD (Transport Volumes) for use by IBM Migration Utility

The IBM Migration Utility transfers whole volumes at a time. An efficient migration method is to gather copies of libraries, data and other objects onto the smallest volume necessary to accommodate them.

The volume should be non-SMS in order to allow datasets to retain their original names (while being non-catalogued) and to prevent SMS overruling the volume in JCL.

A mostly empty volume will take the same time to migrate as a mostly full volume of the same size. Therefore, it is sensible to assign differently sized volumes for large or small requirements.

Ideally, make a variety of Volume sizes available:

  • Large - 200+ GB
  • Medium - 30 to 50 GB
  • Small - 3 GB


4. Install Auto Migration & Data Corraling Solution

If you wish to make use of the PopUp Auto Migration & Data Corraling tool, this should be installed on your mainframe. The libraries can be found on the PopUp UTILC volume.

A simple use case is provided to smoke test the operation.

If you intend to use the Auto Migration tool, it is advised to have 2 transport volumes per migration server to enable data to be corralled at the same time as the previous volume is being transferred. It is also advisable to have 2 migration server instances available, so two sets of volumes can be transferred at the same time.

i.e.

  • 2 Migration Servers (ports 3990 and 3991)
  • 4 x 50 GB volumes

The volumes will need to be assigned exclusively for migration server use and the userid used to execute the Auto Migration program will need specific (RACF) access to manipulate data on these volumes.


B. Transferring the Data

Once the pre-requisites are in place, you can begin the data transfer.

5. Corral data with the PopUp Auto Migration & Data Corraling tool

The IBM Migration Server Utility method of file transfer to a PopUp requires all necessary files to be bundled up into one or more transport volumes. The PopUp Auto Migration & Data Corraling tool helps to standardize this.

The tool takes a list of datasets, interrogates each and then determines how best to copy to the Transport volume.

The following derivatives are covered:

  1. VSAM datasets
  2. Sequential files
  3. PDS libraries
  4. PDSE libraries

The process uses LISTCAT and LISTDSI to determine which of the following methods to generate:

  1. IEBCOPY
  2. IEBGENER
  3. IDCAMS Export / Import

Further methods can be added as required.

The process can be used to execute various scenarios including initial transfer of application libraries, initial load of application data, refreshing application data and upgrading software.

The tool also creates jobs to de-corral the datasets once the volumes have been transferred.

The jobs can be executed manually, via a suitable mainframe scheduling application or via the provided Auto Migration tool.


6. Initiate the data transfer

Volume migration requests are instigated by entering a line command in the ZD&T Linux. Once the Migration Server Utility job is running, a command is entered, as below:

hckd2ckd 123.123.123.1:3990 /z/ibmsys1/dasd/trn001 -v TRN001

where the arguments are IP address of the source mainframe, the path of the Linux volume file and the VolSer of the required volume.

Note: PopUp's Auto Migration Utility will handle requests to the Migration Server Utility where autonomous operation is preferred.

Security

IBM documentation refers to ZPDTMSRV requiring the userid to have read access on the volumes to be migrated, via the DASDVOL class. If you are not using RACF, you will need to verify that ZPDTMSRV works in your setup e.g. via IBM’s SAF (Security Authorization Facility).

The above job could be run from a mainframe scheduler using a functional userid with e.g. storage management privileges, but submitted by a mainframe user who doesn’t themselves have those privileges.


7. De-Corral the data on the PopUp

Once the volumes have been transferred to the PopUp, datasets should be de-corralled.

The corraling process (as outlined above) will have created the necessary jobs to do this.

The jobs can be submitted individually or under control of the Auto Migration tool.


8. Repeat as needed

Repeat steps 5-7 as needed until all data is transferred. These steps can be performed on an ongoing basis.


Data Masking

The Challenge

With data breach incidents regularly making the news and increasing pressure from regulatory bodies and consumers alike, organisations must protect sensitive data across the enterprise. Contending with insider and outsider threats while staying compliant with mandates such as HIPAA, PCI, and GDPR is no easy task — especially as teams simultaneously try to make their organizations more agile.

The Solution

PopUp Mainframe, in collaboration with 3rd party vendors, offers masking services to idenfity and obfuscate PII (Personally Identifiable Information) data before it leaves the PROD zone to make it available for general usage, e.g. development and testing. All types of z/OS data can be masked, including VSAM, variable length files, Db2 and IMS.

PopUp integrates fully with:


Page last revised on: 2026-06-02