Application personnel should be made responsible for providing test data, and for evaluating, and approving application test results. (Obtaining test data can be a problem - early plans should be made to define and obtain test data.).

Involvement of applications to some degree in the test process can prove beneficial at OS/390 switchover and initial OS/390 production.

Operations personnel should do the operating during testing. This is a vital part of their training. Operations personnel should be pointing out

ease-of-use changes that can be made thereby improving OS/390 production jobstreams; that is, their feedback is important. They should also be preparing application ²Run Books² during this time.

Systems programmer personnel should only monitor system activity (for example, performance) and assist in problem resolution during tests; that is, they should not be running the tests.

Online applications should be stress and performance tested prior to production.

This type of testing involves bringing in (if on a weekend) as many users as possible to ²bang away² at the terminals with as many different transaction

types as possible. CPU-intensive batch, dump/restores, and other jobs that heavily load the system should be running during these tests, thereby better insuring good performance of online systems during peak system usage.

MVS Tools Testing

The tools selected for MVS operations (for example, tape manager, job scheduler, job preparation and report manager) should be used for the batch functional and parallel production tests in order to validate their installation and setup. If a job scheduler will be used in OS/390 production then use the same job scheduler during parallel testing.

DASD Requirements

Data migration during the testing phase creates a need for extra DASD. It is a far better scenario to overestimate your needs than struggle with insufficient DASD. Securing ample DASD can also be very helpful in reducing the time required for migration of databases. If the installation is growing in size it will generally not take long to make use of this capacity anyway.

Subsystem Storage Protect

It is recommended the implementation of SSP be delayed until after testing. The problem that can occur is that once implemented it can be difficult to identify the source of some problems and attribute them to testing old applications, to the SSP install or to a conversion issue.

32.5.4.3 Test Plan

Before any testing begins for any phase of testing the test group/team need to assemble and a test plan developed. Determinations need to be made about what actions will take place in each of the phases. Typical test plans turn out to be checklists that will be worked against. One team member will have the responsibility to sign off on each checklist item and signify whether the task was successfully completed or not. For those tasks that were not successfully completed this person would have the responsibility for the remedial plan. Each

508VSE to OS/390 Migration Workbook

Page 532
Image 532
IBM OS/390 manual Test Plan, MVS Tools Testing, Dasd Requirements, Subsystem Storage Protect

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.