Hypothetical Case Study—Migrating from Tivoli NetView › The Migration Plan › Identify the NetView REXX Procedures that Need Migrating

Identify the NetView REXX Procedures that Need Migrating

The team must run every NetView REXX procedure considered for migration through an analysis program and investigate any potential incompatibilities. NetView REXX procedures not requiring any changes must also be verified in the CA NetMaster NetView Emulation environment.

With a large number of procedures, the effort required to do this can quickly increase. It is less work and far simpler to sort the NetView REXX procedures before you commence any migration steps.

Firstly, the team must identify the procedures that need to be migrated. They then use the REXX Analyzer to produce a report that guides them through the work of updating the procedures. If they did not do a good job of sorting and they analyzed a lot of unneeded procedures, the report will be longer and more complicated than it has to be.

Typical Tivoli NetView sites have a mixture of useful and non-useful procedures. Black Lion Telecom has been using Tivoli NetView NCCF for many years, and has accumulated a large number of NetView REXX procedures, both distributed and developed in-house. Their DSICLD ddname points to a concatenation of procedure data sets of varied histories.

New staff members have incorrectly placed testing procedures in production data sets. Procedure naming conventions have changed over time. Procedure data sets for older versions of Tivoli NetView are concatenated at the bottom.

The migration team decides to start with only essential procedures. It is careful to not touch the production environment. It takes the following actions:

• The systems programmers prepare a single PDS, BLTNET.NETVIEW.PRODREXX, for input to the REXX Analyzer. Initially they copy all members from all concatenated DSICLD data sets to it.
• They leave the production DSICLD data sets untouched—these are still being used by production Tivoli NetView and will not be changed in any way.
• The Tivoli NetView programmers examine all of the members of BLTNET.NETVIEW.PRODREXX, and identify and delete the members that they do not need to migrate. These include the following procedures:
  • Procedures that are not REXX, including many old Tivoli NetView CLISTs
  • Testing procedures
  • One-off procedures for transient problems that have been fixed
  • Unrecognized procedures with no known authors
  • Multiple nearly identical copies of the same procedures with different names
  • Procedures with the same names that exist in different DSICLD concatenation levels where only the highest level copy is examined

Altogether, the team identifies 200 NetView REXX procedures that need to be migrated.