IBM OS/390 User Manual

Page of 673
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