the third job in the sequence is missing due to being treated as a temporary data set.

The management of transition files is very different between VSE and OS/390. In OS/390 there are only a couple of possibilities. In VSE it depends on the type of organization, the products used and the traditions followed.

These problems dont show up until the applications are tested together. This is the right time for these to surface. If these all occurred during parallel testing it would take a very long time to complete.

32.5.7.1 Data Migration in System Testing

The system test phase may or may not require that more data is available but frequently requires that more accurate data is needed. An example is working with databases that are two or three months old. In some cases these applications will not run because they have been written to work only on recent data. Recent data may be required. Another hurdle can be that these applications have dependencies on batch data feeds to them.

32.5.8 Parallel/Production Simulation Testing

Parallel testing is more representative of what the system will be like in OS/390. In parallel testing you start with a day, typically a Sunday, and then do one day at a time. The data from each day is scrutinized. Here the end user community will get involved in testing. Output reports are reviewed and verified that they are what they should be. This depth of review and comparison also requires that in parallel testing you start to synchronize the data between systems.

At this point your network should provide access to this environment from any terminal. This is an important consideration in allowing quantities of end users on the system who should not be restricted to a small number of terminals with access to MVS.

Parallel (batch) production tests will include all jobs executed for a period-end day. Duplicating VSE execution will not always be possible, due to the integration between online and batch applications and some side effects of job execution date.

The final phase of parallel testing is ensuring the output is the same from both systems, where actual production is compared to the test output. In this phase there are two systems running in parallel. Monday is run on the OS/390 system and compared to Mondays output and reports from the VSE production system. For week ending, month ending and year ending scenarios that actual date change becomes the test.

32.5.8.1 Data Migration in Parallel Testing

In parallel testing the data in the systems needs to be synchronized as you will be comparing production runs under VSE with test runs under OS/390. Typically by this time you have done switchover rehearsals a couple times. Now just before parallel testing begins you will synchronize the data for a particular day, for example, Monday or Tuesday.

514VSE to OS/390 Migration Workbook

Page 538
Image 538
IBM OS/390 Parallel/Production Simulation Testing, Data Migration in System Testing, Data Migration in Parallel Testing

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.