HP 3000 Manuals HP 3000 Manuals
Detecting Incompatibilities (Continued)
Detecting Incompatibilities (Continued)
Analyzing the Reports.
Once potential incompatabilities are listed, use the information to play
your migration strategy and identify any changes that you need to make in
your applications.
Look in Appendix D for information listed under "Undetected
Incompatibilities" and under "Incompatibilities", which lists the
incompatibilities detected by the MPT, OCA and RTM. While this list of
possible incompatibilities appears long, most files (either program, SL,
job stream, or UDC files) contain only a few, if any, of these. Also
included is the cause of the incompatibility and any correction for the
problem.
Potential incompatibilities reported by MPT and OCA can fall into one of
four categories. These categories relate to whether the event was
executed while RTM was in effect and if the event detected by MPT or by
OCA is a real incompatibility.
* An incompatible event did not execute while RTM was enabled.
* A compatible event did not execute while RTM was enabled.
* An incompatible event executed, and was detected and logged by
RTM.
* A compatible event executed, and was detected but not logged by
RTM.
Consider the example where OCA detects a COMMAND intrinsic call, event
200, but is unable to determine if the command executed in the call is
incompatible. RTM reports on the call only if it is executed with an
incompatible command. Since a different command may be executed at
different times by the same COMMAND intrinsic call, what is compatible at
one time may not be compatible at another.
Thus, the fact that OCA detected a possible incompatibility with the
COMMAND intrinsic, event 200, and that RTM did not detect a problem with
the COMMAND intrinsic, events 201 through 218, does not necessarily mean
that the COMMAND call detected by OCA is not problematic with respect to
events 201 through 218.
Careful inspection of the code in question may be necessary to resolve
all potential incompatibilities. When analyzing the reports generated by
MPT, OCA, and RTM, take into account the limitations of each tool in
detecting incompatibilities.
Your migration strategy should be influenced by the number and complexity
of the changes you need to make to your application to have it function
properly on MPE/iX-based systems. Also, you should note the changes
which are necessary to run in CM or NM, as this, too, influences your
migration strategy. A thorough understanding of the application may be
necessary to assess the impact of the incompatibility. Once all
necessary changes are identified, and the migration plan is developed,
you can estimate the resources needed to complete your migration.
Severity of Incompatibilities.
Once you have determined what potential incompatibilities exist in your
application, you need to determine how your application depends on the
item in question. In some cases, what is flagged as an incompatibility
may not cause your application to run incorrectly but it is something
that you should investigate to determine the impact on your application.
To determine accurately what, if any, modifications your application will
require to run on the 900 Series HP 3000, you have to decide whether the
application will be run in CM or NM. Additionally, you need to know
whether it needs to call NM or CM procedures.
The most severe incompatibilities include the use of Privileged Mode,
uncallable routines, or undocumented entry points. Resolution of these
potential incompatibilities will require a detailed study of the
application in question.
Application Characteristics.
Your application may include more than just the program file. A complete
application may consist of programs, SLs, data files, job streams, and
UDCs. The application may have other characteristics that will affect
your migration strategy such as:
* The Hewlett-Packard languages used by the application.
* The number of lines of code in each program in the application.
* If the source code is available for all the programs in the
application.
* Whether or not the application relies on Hewlett-Packard or third
party software.
* The MPE V/E features that the application uses.
* How the application uses MPE intrinsics.
* How the application accesses data.
* Whether or not the application encounters storage or performance
limits.
* Whether or not the application interfaces with another
application.
* What related applications are being migrated.
* What the application's MPE/iX disk space requirements are when
migrated to an MPE/iX-based system.
Migration Goals.
After analyzing the incompatibilities and characteristics of the
application, you need to establish migration goals. These goals should
define the intended mode of operation for the application, and what data
alignment is expected by the application.
You may also want to identify interim goals. For instance, if you have
an application that you ultimately want to migrate to NM, but it shares
data with another application which will not be migrated for some time,
an interim migration goal might be CM or mixed mode, until the second
application can be migrated to NM.
To accurately determine the goals for migrating the application you need
to consider the following:
* What languages are available in the desired mode?
* Is the source code available for making changes and recompiling?
* What incompatibilities need to be resolved?
* Does going to NM increase the number of incompatibilities?
* What mode do dependencies work in?
* What data format is required?
* Is all required Hewlett-Packard or third party software (or
equivalent) available for use on the MPE/iX-based system?
* Do you need to share files with MPE V/E systems in a network?
* Will source and program files be sharable across both MPE
V/E-based machines and MPE/iX-based machines?
Time and Resources.
Once you have established the migration goals, you will need to determine
what time and resources you need to commit to completing those goals.
Time and resource requirements needed may be influenced by the following
factors:
* The number of lines of code in the application.
* Availability of source code.
* Tools used in software development.
* Activities needed to properly exercise all code paths for RTM.
* The needs of the application user group.
* The length of time both machines will be available to complete
parallel testing.
Planning the Migration
Now that the analysis is complete, and you have developed a strategy for
migrating your application, it is time to develop the migration plan.
Your complete migration plan should include:
* Purpose and scope
* Project identification
* Migration strategy
* Migration schedule
* Resource requirements
* Documentation and training requirements
* Detailed application analysis
* Test plan
Purpose and Scope.
The scope should include all areas addressed by the plan. The purpose is
a statement of how you will use the migration plan.
Project Identification.
Project identification includes both customer and application
identification. Application identification is a brief description of the
application covered by this migration plan.
Migration Strategy.
The migration strategy includes a statement about:
* migration goals.
* target state.
* major milestones.
* project completion criteria.
* project team members.
* support staff.
* your Hewlett-Packard support team.
If the application has no incompatibilities, you may be a ble to move the
application directly to NM. If however, your application has some
incompatibilities, then your migration strategy will be slightly more
complex. You may need diferent migration strategies for different
applications. Hewlett-Packard gives you flexibility; you decide which
migration options to choose for your applications.
A migration goal is a statement describing the functionality and
performance expectations, as well as a timeframe for completion.
The target state describes the operating mode and options for all
programs and databases that make up the application. The target state
should also specify which portions of the application will be in CM, NM,
or mixed mode with Switch stubs. Major milestones list each major step
involved in reaching the target state. These milestones will be the
basis for the migration schedule.
Project completion criteria lists the specific criteria for project
completion.
The migration strategy should also list the project team members, support
staff, and Hewlett-Packard personnel involved.
Migration Schedule.
The migration schedule should represent milestones and durations. For
example, a graph where the vertical axis lists milestones and the
horizontal axis lists dates pertaining to duration and completion.
Your milestones should include: detailed analysis, migration plan,
software preparation, installation, CM testing, recompilation to NM,
database conversions, NM testing, and project completion. Include
intermediate milestones.
Resource Requirements.
Resource requirements should list the hardware and software requirements
for completing migration. Hardware requirements list the 900 Series,
disk drives, tape drives, printers, terminals, and any other hardware
needed for migration. Software requirements list MPE/iX with version
number, compilers, subsystems, tools, database management systems, and
any other software needed for this project.
Documentation and Training Requirements.
Documentation and training requirements should list the training and
documentation needs for all personnel involved in the migration project.
Under documentation needs, list migration guides and reference manuals.
Indicate how many copies of each are needed and when they are needed. Be
sure to plan time for individuals to read and study the documentation.
Other documentation considerations include updating in-house
documentation that needs to be changed due to migration.
Under training needs, list all training courses, dates, and who will
attend.
Detailed Application Analysis.
This is the seventh section of your migration plan. A detailed analysis
of every application being migrated includes:
* application organization.
* languages used.
* number of lines of code.
* system dependencies.
* user interfaces.
* networking.
* database access.
* third party software.
* contributed library dependencies.
* known incompatibilities.
* potential problem areas.
* list of intrinsics and external references.
A procedure flowchart or call map can be very useful in describing the
application. Reports from the Migration Toolset (MPT, OCA, and RTM)
should be included here.
Test Plan.
This is the eighth and last section of your migration plan. The test
plan should include the test data and procedures that will be used at
each stage of the migration.
A complete test plan ensures that most problems are avoided before the
application is in full use and should ensure that any change made to the
application is thoroughly tested.