IBM OS/390 manual Duration, Phase One, Phase Two

34.5 Duration

Due to the data sharing requirements, the availability requirements, and, in general, the dynamic environment of the business, it was decided the mass conversion method was the way to migrate to MVS. In the past years of rapid growth not much time was spent defining and enforcing systems management disciplines which resulted in uncertainty of what source code, phases, JCL and so on, were production and which were obsolete or test. Since these elements are the key indicators in determining the scope of a project like this it was decided to break the project into two phases. Phase one, the application inventory which through the use of software tools identified and helped segregate the elements that were used in production and the elements required for test. Phase two, which was basically the conversion of the programs and JCL, testing and switchover to MVS. As stated in earlier sections, the mass conversion method is the most common method to migrate to MVS. Also, the two phased approach is becoming more popular because of its many benefits, most importantly a much more accurate prediction of the actual cost of the project.

34.5.1.1 Phase One

About eight weeks was spent in this phase. First the MVS software required to run the tools was installed as a VM guest. This part can be eliminated by buying time on an existing MVS system to run the tools. Next, all of the VSE libraries required were imported to the MVS system and the tools run which resulted in a series of reports that showed exceptions (missing, unreferenced and so on). Representatives from systems support, operations and applications development departments reviewed the reports, made changes (move, delete, find elements) and resubmitted the new data to the MVS tools. This is an iterative process with the end result a fairly clean inventory.

34.5.1.2 Phase Two

This is comprised of multiple phases as described in earlier chapters. It took approximately thirteen months until switchover to MVS. This time was a couple of months longer than originally planned primarily for two reasons, inadequate testing in the final phases of testing and finding a weekend where the normal weekly four hour window could be increased to eight hours to accommodate the switchover to MVS.

34.6 Performance

As mentioned earlier VSE was run as multiple guests under VM/ESA. Once MVS was switched to production, it remained as a VM guest for a couple of months. After this MVS was run under an LPAR. VMPRF was installed on VM and was run daily to create summary history reports. The reports were not granular enough to break out CPU utilization by virtual machine, therefore, the numbers reflected the sum of the VSE and MVS guest while testing applications under MVS. There was a time when there was little or no activity on MVS while VSE production was running, mainly third shift. By comparing the third shift before switchover (VSE production) and third shift after switchover (MVS production) fairly comparable numbers could be obtained. One problem with this was that the time in the project when there was only VSE workload during third shift was when the 9121 was installed and after switchover the workload was on a 9672. The other variable was that there was no way to prove that there was an equal workload at the two times. However, using these rough comparisons and normalizing the CPU times using the LSPR ratios, the CPU utilization stayed

Chapter 34. Customer Migration Example 531