The main challenge is the identification and classification of files for the migration. All files that will be used as input to a job after the switchover to OS/390 operations must be migrated. Files recreated by the first OS/390 production cycles do not need to be migrated, and are better off not being migrated (at least temporary files, cataloged or not).

The task of selecting files for the migration to OS/390 is easier for those files accessed by online applications. This is because they are in relatively small numbers (150 to 300), permanently allocated, often uniquely identified (for example through standard labels), and because their list is fairly stable over time. CICS tables list all those files, and more. The only challenge with online applications is to identify and eliminate obsolete CICS table entries.

The real selection challenge is with batch applications. The list of all files (separate data flows) accessed by batch applications is typically in the hundreds. These files are usually not monitored or kept current. Identification of their use is complicated by reuse of the same VSE file name or even disk space for completely separate data flows. As explained in the JCL conversion section above, it takes a global enterprise-wide view of the step/file cross references to:

∙

∙

∙

Truly understand the VSE data flows,

Separate and identify each of them,

Classify them according to their life cycle (permanent, handoff, backup, work),

∙Apply an appropriate OS/390 migration strategy to each one.

Device migration is the second file migration challenge. Many VSE installations tend to be tape (not disk) oriented. OS/390 should be disk and DFSMS oriented, not tape oriented. This means that:

∙

∙

VSE disk files are migrated to OS/390 disk files

Most VSE non-backup tape files are migrated to OS/390 disk files, with the exception of external (shipped) input or output tapes

∙VSE backup tape files created within application job streams may be

migrated to OS/390 tape files. But with DFSMS, they may be created under OS/390 on disk by the OS/390 job stream and copied to tape ²out-of-sync² with job execution by HSM in a technique called ²disk buffering² (see OS/390

standards).

It takes a prolonged simulated production test to assess the match of the new OS/390 JCL streams, HSM archival strategies and DFSMS constructs with the available disk space. Hardware configuration constraints and on-going VSE operations do not always allow getting a good feel for the performance of future OS/390 native operations.

The differences in device utilization strategies between VSE and OS/390 greatly influence the file migration. Those differences are defined by the OS/390 standards¢ decisions made while converting the JCL.

The VSE to OS/390 file migration is developed progressively over a period of three to five months, while performing the regression tests, and assuming that file identification and device migration are accounted for with JCL conversion, it represents only 5 to 10% of the total application conversion effort.

36VSE to OS/390 Migration Workbook

Page 59 Page 61
Page 60
Image 60
IBM manual VSE to OS/390 Migration Workbook
Page 59 Page 61

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.
Top Page Image Contents