5.6.4.3 Moving a VSAM Catalog to a Different DASD Type

VSE/VSAM provided no facility for moving a catalog to a different device type or volume serial number. OS/390 VSAM provides this facility for ICF catalogs via the AMS REPRO and EXPORT/IMPORT commands. Using the REPRO function, you may specify the old catalog as the input and the new catalog as output. The new catalog must already have been defined but it may be a different DASD device type and it must be a different volume serial number. Moving the catalog does not move the data sets that exist on the old catalog volume.

REPRO has two options, MERGECAT and NOMERGECAT. MERGECAT will transfer entries from one catalog to another, deleting the entries from the source catalog. If there is a failure during MERGECAT, the target catalog contains the only valid entries for some of your data sets. For this reason, do not delete the target catalog simply because the MERGECAT failed. If the failure was caused by errors external to catalog management and access method services, simply rerun the REPRO MERGECAT job.

NOMERGECAT will transfer entries to the target catalog but not delete them from the source catalog. Therefore, data set entries will exist in both catalogs. If there is a failure during the process, you cannot simply resubmit the job because REPRO NOMERGECAT copies the source catalog into an empty target catalog. During the REPRO process, catalog pointers in VSAM VVR entries will be changed to point to the target catalog. Before you restart the REPRO NOMERGECAT, steps must be taken to remove the duplicate data set entries that are now in the source catalog and change the VSAM VVR pointers back to the source catalog. After a REPRO is run, the target catalog is meant to be used as the active catalog.

You could also use EXPORT/IMPORT to move an ICF catalog to another device but you cannot change the catalog name during the process. You can use EXPORT/IMPORT or REPRO to move data sets. Before using REPRO on ICF catalogs, you should refer to Managing Catalogs, SC26-4914, chapter 4 and DFSMS/MVS Access Methods Services for ICF SC26-4906 for further details.

5.6.5 VSAM Functional Differences

5.6.5.1 Areas of Consideration

The following list summarizes VSE/VSAM functions that are either not supported by OS/390 VSAM or are implemented in a significantly different fashion. Each item is discussed in the text following this list.

FBA DASD (a general change, not specific to VSAM)

Catalog structures

NOIMBED option

Shared volume ownership

AMS commands

CANCEL command

DELETE IGNOREERROR

SYNCHK parameter

XXL KSDS (new in VSE/ESA 2.3, greater than 4GB KSDS)

COMPRESS (new in VSE/ESA 2.2, VSAM record compression)

VSAM CISIZES and blocksizes

Chapter 5. Disk and Tape Storage Considerations 119

Page 143
Image 143
IBM OS/390 manual Vsam Functional Differences, Moving a Vsam Catalog to a Different Dasd Type, Areas of Consideration

OS/390 specifications

IBM OS/390, a versatile operating system, was a cornerstone in enterprise environments and played a pivotal role in mainframe computing. Released in the mid-1990s, OS/390 combined the strengths of IBM's MVS (Multiple Virtual Storage) with new features and enhancements, targeting scalability, reliability, and performance in demanding business applications.

One of the key features of OS/390 was its robust support for multiple users and processes. The system allowed thousands of concurrent users to access applications and data, ensuring high availability and minimizing downtime—a critical requirement for many large organizations. This scalability was supported through various enhancements in memory management and processor scheduling, enabling optimal resource allocation across diverse workloads.

OS/390 was known for its superior workload management capabilities. The Workload Manager (WLM) component allowed administrators to define service policies, specifying how system resources would be allocated according to the priority of tasks. This ensured that critical business processes received the necessary resources while less critical tasks were managed more flexibly.

Another significant characteristic of OS/390 was its commitment to security. The operating system provided comprehensive security features, including user authentication, data encryption, and auditing capabilities. This focus on security was vital for organizations handling sensitive data, ensuring compliance with regulations and safeguarding against unauthorized access.

OS/390 also supported advanced technologies that facilitated integration and development. The system included features like the IBM CICS (Customer Information Control System) for transaction processing and IMS (Information Management System) for database management. These technologies allowed organizations to build robust, high-performance applications tailored to specific business needs.

The ease of network integration was another strength of OS/390. With the advent of the Internet and global connectivity, OS/390 systems could easily interface with various network protocols, enabling businesses to operate in a connected world. This inclusion paved the way for many organizations to expand their capabilities and offer new services, driving digital transformation.

In conclusion, IBM OS/390 represented a significant advancement in mainframe technology, combining scalability, security, and robust workload management. Its rich feature set and support for critical enterprise applications solidified its role as a vital component of many organizations' IT infrastructures, ensuring they could meet their operational challenges head-on while supporting future growth. As technology continues to evolve, the legacy of OS/390 remains influential in the realm of computing.