Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

System and method to convert mainframe CKD format data to FB format data in storage backend

IP.com Disclosure Number: IPCOM000248229D
Publication Date: 2016-Nov-10
Document File: 3 page(s) / 45K

Publishing Venue

The IP.com Prior Art Database

Abstract

Applications running on mainframe or mainframe virtual Linux may have a need to run in open platform to save the mainframe MIPs (million instruction per second) . Applications running on mainframe virtual Linux is relatively easy to be ported to run in open system but the underline data migration to open is not that easy. The data migration is usually done by a host reading data from mainframe to open system by handling the CKD (counter key data)/FB(fixed block) conversion in the host, which is time consuming and also a waste of mainframe MIPs. The core idea of this publication is to convert the back end CKD Data (mainframe format) to a FB (open fixed block format) within the storage controller so that it can be accessed by open system immediately without host invention.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 3

System and method to convert mainframe CKD format data to FB format data in storage backend

Applications running on mainframe or mainframe virtual Linux may have a need to run in open platform to save the mainframe MIPs . Applications running on mainframe virtual Linux is relatively easy to be ported to run in open system but the underline data migration to open is not that easy. The data migration is usually done by a host reading data from mainframe to open system by handling the CKD/FB conversion in the host, which is time consuming and also a waste of mainframe MIPs.

The core idea from this publication is to convert the back end CKD Data (mainframe format) to a FB (open fixed block format) within the storage controller so that it can be accessed by open system immediately without host invention.

Mainframe virtual Linux attaching to CKD volumes have a device driver layer to access the CKD volumes. It has metadata to map application data to dataset so that we could have direct access to mainframe data sets. For applications that access logical volumes in a raw format. The data area of the CKD records can be extracted using CKD metadata and by copied to another FB volumes to be accessed by open host. For applications that access volumes in file format, the mainframe virtual Linux file level metadata and CKD metadata can be combined/utilized to get rid of count and key fields for each record, pack together data area and copy it to another file in a open formatted FB volume to be accessed by open systems.

Raw format conversion:
mainframe virtual Linux application access CKD volumes via device driver, the device driver has metadata to map application data to dataset (E.g. LBA(logical block address) 0-100 maps to records R0-R3). We can extract data area of the CKD records and then copy the extracted data to another FB volume between LBA 0 and 100 so that open system application attaching to the FB volume is able to read the exact same data viaLBA 0-100.

Raw format conversion step by step:


Step 1: Create a FB volume in the storage backend to save the data for CKD volume
Step 2: Device driver sends a range of blocks and its related CKD records to storage
Step 3: Storage microcode reads CKD tracks into ca...