Call Us: +1 (925) 954-9649

Menu...

Tasks

Task 01 – Project Management

The objective of this task is to establish a framework for project communications, monitoring, reporting, and procedural and contractual activities.  A Project Manager and a Technical Leader are assigned the responsibilities for administration and technical direction of the conversion efforts.

Project management activities consist of:

  • Evaluating the progress made against work plans and schedules
  • Conducting regular progress review meetings
  • Providing liaison and coordination between all personnel involved

Task 02 – Project Planning

The objective of this task is to plan the migration from VSE to z/OS, starting with application conversion: all other migration activities can be planned in relation to the application conversion.  The project plans include:

  • Overall project plan
  • z/OS education plan
  • In-house developed application conversion plan
  • Software ([IBM and] non-IBM) installation plan
  • Automated operations set-up plan
  • Online application test plan
  • Batch application test plan
  • Switchover plan

Task 03 – Project Orientation

The objective of this task is to provide project orientation (i.e. education) to the conversion team and all personnel involved regarding the conversion approach and the project plans.  Project orientation sessions are scheduled:

  • At project start
  • Before the start of application regression tests
  • Before switchover

During those sessions, the Project Manager and conversion consultants provide the Customer team with instructions and guidelines for planning, organizing, and implementing the activities to come.

Task 04 – Project Tools and System Resources

The objective of this task is to provide the hardware and software tools and z/OS system resources used for the conversion, including:

  • Automated conversion software for:
    • Application inventory transfer and verification
    • Code conversion: COBOL, Assembler, PL/1, RPG II, Easytrieve, DYLACORE, QUICKJOB, etc.
    • Compilation/linkedit of the converted code
    • JCL conversion: VSE JCL interpretation, integration, file classification, z/OS JCL generation
    • File migration: disk file migration, tape file migration
  • z/OS hardware and software resources for application inventory, mass conversion, regression testing, and post-switchover z/OS operations with both local and remote access
  • Furnished office space with long distance telephone if/when working onsite
  • PC access to z/OS resources, LAN and Internet

Task 05 – Application Inventory

The objective of this repetitive task is to identify and collect the conversion inventory, transfer it to the z/OS system, and verify that it is complete and consistent.  The conversion inventory includes:

  • Source code: programs, sub-programs, macros, copy or include books, and FCB
  • JCL: VSE and POWER JCL streams, standard labels, SLI and other JCL include books
  • Additional information such as: job scheduling, CICS tables, VSE catalogs and VTOC listings

Only the version of source code or JCL currently used in production under VSE is supplied to the conversion.  Duplicate or obsolete versions are eliminated (moved away) from the VSE production libraries.  VSE executable code (phases) is discarded: new z/OS executable code (load-modules) will be generated from the converted source code.  Lost source code is either retrieved or rewritten: it is then regression tested and installed in production under VSE before being transferred to the z/OS system for conversion.

The device, content, and format of the files used to transfer the conversion inventory from the VSE to the z/OS system is defined.  An automated application transfer procedure (VSE JCL streams and z/OS JCL streams) is developed.  The conversion inventory is collected from the VSE production libraries, copied to transfer files and downloaded into the conversion libraries on the z/OS system.

An inventory validation procedure is developed and executed on the z/OS system, against the conversion libraries.  It produces several lists of exceptions, including:

  • Elements missing from the supply
  • Elements supplied but un-referenced by any other elements

Those exceptions are reviewed and addressed by VSE production support personnel.  There should be no missing elements in the supply of the conversion inventory by the middle of the specifications phase.

The conversion inventory is mass collected/transferred/verified/converted every two to three weeks from project start to switchover, in order to automatically take into account the VSE application changes.  Because it will be repeated many times, this mass processing procedure must be automated to reduce or eliminate the manual effort and to ensure repeatable, reliable and improving quality from a capture to the next one (less or no missing elements).

The application inventory is collected for a final mass conversion a few weeks before switchover.  Between this final mass conversion and the switchover, several captures are scheduled to identify (source compare) and carry over the last VSE application changes.  But the changed elements are converted (or their changes) are duplicated one at a time, to eliminate the risk for massive last minute regression with the automated conversion.

Task 06 – z/OS Standards and Naming Conventions

The objective of this task is to define a set of z/OS standards and naming conventions for the converted applications.

It is recommended to define the new z/OS standards and operating procedures first, at least at a high level, before defining new JCL-referenced names.  This is because naming conventions can facilitate or impair the implementation of z/OS system components (such as DFSMS) and other automated operations products.  It is recommended to understand how a production item will be stored, used, and managed under z/OS before giving it a name.

Because new z/OS JCL streams will be generated, new rules are developed to define the structure of those streams, and how repetitive JCL statements will be regrouped into procedures or includes, in order to facilitate future JCL maintenance.  For example, a dedicated JCL procedure may be used for each highly repetitive utility steps, (SORT, IDCAMS, etc.), and compiler or debug related DD statements (SYSOUT, SYSUDUMP, etc.) may be regrouped into a single JCL include.  The storage and management of control cards and their reference from the JCL is another set of rules associated with the structure of JCL streams, as is the usage of execution parameters and their transfer from production control clerk to executing program through job scheduler and JCL symbolic parameters.  It is recommended to not redefine the division of batch applications into job streams, because this would impact the job scheduling rules and confuse operations personnel

As part of the z/OS migration, the usage of utility steps can be redefined.  It is typical to find half a dozen ways of performing the same file copy in the VSE JCL.  It is generally recommended that only one or two ways may be needed and retained in the z/OS JCL.  The same standardization applies to other file utility steps, such as external sorts and backups.  Database application steps and database utility steps are also standardized, and some of the associated JCL may be isolated in JCL includes or procedures for easier maintenance.  Service steps of all kinds may be inserted automatically, for example to delete catalogued temporary files.

System managed storage is very strongly recommended when it comes to file management under z/OS.  One of the great combined advantages of DFSMS and DFP is that they allow drastically simplifying DD statements, which makes JCL very easy to read or maintain, and configuration independent.  Typical z/OS migration standards include the elimination of VOLSER, RECL, BLKSIZE, RECFM, ORG, DSCB, SPACE, and UNIT attributes (to the exception of RECL in IDCAMS/REPRO output and UNIT for tape file output).

Many VSE sites tend to be too much tape oriented.  The z/OS migration is an excellent opportunity to migrate from tape intensive to disk intensive operations, eliminating many manual interventions (for tape volume mounts) and boosting job throughput as a result.  DFSMS’ automated free space release and HSM’s archival features can be combined to implement disk space “buffering” techniques, in which files that will end up on tape are created on disk by the executing job.  The copy of the file to tape, as well as the accumulation of many files on the same tape volume is left to HSM.  It takes place after the job execution is completed.  Once again, the effect is a drastic reduction of manual intervention for tape mounts, as well as an acceleration of the job throughput.  Such file and device management policies are part of the standards and operations procedures definition in an z/OS migration.  They have an enormous effect on the structure and content of JCL streams.

New names must be defined under z/OS for all items referenced in the new z/OS JCL, including: data sets, jobs, procedures, includes, steps, execution parameters, libraries of any kind (from source or executable code to procedures and parameters), and library members for control cards.  This is because many of the VSE names are syntactically incorrect under z/OS.  But the conversion of in-house developed applications doesn’t require changing any of the names associated with the source code.  In fact, it is recommended to leave the program, entry-point, copybook, code-include, and DD names unchanged to avoid confusing application support personnel.

Task 07 – Conversion Specifications

The objective of this task is to develop and document the conversion specifications by analyzing the VSE source material, designing z/OS target material that complies with the selected z/OS production standards, and designing the conversion paths (program translation, JCL conversion, and file migration).

The analysis of the VSE material is both qualitative and quantitative.  Qualitative analysis consists of listing the types of syntax that are being used in VSE, and defining the types of replacement syntax that will be used in z/OS.  Quantitative analysis consists of determining the number of times that each type of syntax occurs within the VSE material.

Quantitative analysis is performed with scan utilities.  It is essential in determining the conversion approach to be used.  While conversion issues occurring over many times are addressed with automated solutions (if technically possible), low occurrence conversion issues may be addressed with manual positioning of the VSE material (when possible) or even manual modification of the z/OS version.

For project organization and planning, the effort is divided per type of application item (JCL, code and files), per type of application (batch or online), and per language (COBOL, Assembler, RPG II, etc.).  The design of the z/OS target material complies with the selected standards and operations procedures for the z/OS target production.

The conversion specifications may be documented in a Conversion Specifications Document that becomes the guideline for custom-modifying the conversion software and developing or custom-modifying additional conversion software.

Task 08 – Conversion Tool Customization and Development

The objective of this task is to adapt the conversion software or develop additional conversion software to be able to convert automatically all or most of the VSE material to z/OS, and deliver z/OS material that complies with the selected z/OS standards and operations procedures.

The custom modification of the automated conversion process follows the specifications documented in the conversion specifications developed above.  It is implemented through positioning of conversion software options, design and coding of exit routines, design and coding of ad-hoc pre- or post-processors, which are then added to the automated conversion process.

Similarly to the definition of specifications, the effort can be divided for better project planning and organization per type of application item, between batch and online and per language.

The customization is validated by converting representative samples of VSE programs and JCL, and verifying that the local VSE syntax has been replaced by the appropriate z/OS syntax.

Task 09 – Automated Mass Conversions

The objective of this task is to automatically mass convert the inventory of production source code and JCL to z/OS, to deliver functionally equivalent z/OS material (source code, load modules, run JCL, and JCL procedures), and to generate VSE to z/OS file migration JCL procedures.

Automated mass conversions include the following steps:

  • Program Conversion: Generates z/OS source code and extracts some information required for VSE JCL conversion, such as: files opened, their device types, assignments, block-sizes, and open mode (input, output, etc.); entry-points; referenced macros, copybooks, includes or sub-programs;
  • Compilation/Link-Edit: Starts from the z/OS version of the source code to generate z/OS executable code (load-modules);
  • VSE JCL Conversion: Job by job, uses the file information extracted during program conversion and associated data such as VSE disk and tape catalog data to generate individual job stream flow charts;
  • Integration: Consolidates the job stream flow charts enterprise-wide to separate the application data flows (several independent data flows may use the same VSE label and even the same VSE disk space, but they become separate data sets z/OS);
  • File classification: Based on data flows patterns and other functional attributes (organization, record length, etc.) classifies files according to their life cycle: work, catalogued temporary, handoff, backup, transmit, master sequential, master VSAM, etc.
  • z/OS JCL Generation: Generates JCL includes, JCL procedures and inline JCL streams according to standards defined for the new z/OS environment;
  • File Migration: Combines VSE data file attributes (record length, label, etc.) collected during VSE JCL conversion with z/OS data file attributes determined during z/OS JCL generation, to generate VSE and z/OS JCL streams used to migrate VSE files to z/OS.

Each step produces a number of errors and warning messages, which are systematically reviewed using specific statistical analysis tools.

Every three to four weeks, the mass conversion starts from a fresh copy of the entire conversion inventory, in order to take into account the last VSE maintenance modifications.  Between two supplies, additional mass conversions may be executed from the same supply, in whole or in part, in order to take advantage of the latest custom modification improvements.

The first mass conversion is a pilot conversion before custom modification of the mass conversion software.  It is used for analysis, rather than for generating z/OS application material.  The following mass conversions are trial mass conversions, which deliver z/OS test application material with an increasing quality, as project and conversion software customization progress.

The final and actual mass conversion starts after z/OS regression tests have been successfully completed.  It delivers the actual z/OS production material.  The actual conversion is scheduled several weeks before switchover in order to avoid any major last minute regression.

A special one-time translation of all applications development source code takes place four to five weeks before switchover.  It doesn’t include any program compilation or JCL generation.

Task 10 – VSE Positioning

The objective of this task is to implement the VSE positioning, that is, modify the VSE code to eliminate VSE TO z/OS conversion requirements that cannot be automated.

Conversion consultants may apply the positioning which doesn’t impact the logic of the code, while the positioning which impacts the logic of the code (misplaced stop runs, access to file buffers before open or after close, etc.) is best left to application support personnel familiar with the code.

In any case, the positioned VSE code is then regression tested under VSE by application support personnel and rolled back into production under VSE.  It is later on collected again for conversion, together with the rest of the application inventory.

Task 11 – Manual Conversion

The objective of this task is to complete the automated conversion process by applying manual modifications to the z/OS version of the code, when fully automating the conversion is too complex or is not cost effective, and when VSE positioning is also impossible.

Manual conversion activities may be required for the conversion of VSE-dependent Assembler programs, part of the COBOL to COBOL for z/OS conversion, and a few low occurrence JCL conversion issues.

Manually converted elements are converted automatically once to take into account all the conversion requirements that can be automated.  Then they are set apart from the automated conversion process.  They are repetitively supplied with the rest of the application inventory for mass conversion.  But instead of being re-converted each time, they are only source compared (source compare utility program) to the version manually modified, in order to identify the latest VSE version changes, if any, and duplicate them manually to the z/OS version.

Because such activity is in contradiction with the mass, automated and repetitive conversion approach, it is kept to a minimum number of application items that cannot be converted entirely automatically, and for which the unresolved conversion requirement cannot be addressed through VSE positioning.

Task 12 – Application Interfaces

The objective of this task is to identify all interfaces between the converted VSE applications and outside applications, and to adapt (convert) those interfaces.

Such interfaces include data entry applications, links with other computers (RJE, NJE, electronic file transfer, client/server links with PC or LAN systems), input or output tapes received from or sent to external organizations, and purchased VSE applications not converted but replaced by their purchased z/OS version.

Task 13 – Operations and System Products Setup

The objective of this task is to populate the z/OS job scheduler, report/output manager, and tape manager with job scheduling instructions, report/output management instructions, and catalogued data coming from VSE.

If a report manager was used under VSE, the VSE report manager rules are migrated to the z/OS report manager.  During JCL conversion, the JCL-managed reports are retrieved and identified with unique report-ids.  Their attributes (form number, number of copies, FCB, remote destination, output class, etc.) are collected into a file used to load the z/OS report manager.  The z/OS JCL is generated free of report management attributes but containing the report-ids instead.

VSE job scheduling rules are migrated to the z/OS job scheduler, either from the VSE job scheduler (if applicable) or from the operations manual. Active VSE tape files are the files that will be read after switchover by the generated z/OS JCL.  Inactive VSE tape files are all the other files cataloged to the VSE tape manager.

Once identified through JCL conversion, active tape files are either:

  • Copied with reformatting (new z/OS dataset name and attributes) during switchover, if time allows, to an z/OS tape volume, and catalogued to the z/OS catalog and z/OS tape manager, or
  • Catalogued with a “marking” (for example by using a dedicated generic UNIT name like “VSETAPE”) to the z/OS catalog and z/OS tape manager. A job service step is inserted at the start of each job to identify marked input tape file, if any, to modify the z/OS JCL so that it can read the VSE-created file with its old VSE attributes and name. It takes only a few z/OS production cycles for all VSE-created tape files to become obsolete and be replaced by a new z/OS-created version. Most VSE-created tape files have disappeared within a month after switchover, after daily, weekly, biweekly and monthly jobs have red the last VSE-created version of the file.

The list of inactive tape files (files not connected to the JCL converted to z/OS) is manually reviewed to identify, long before switchover, the legal archive, and other files that do need to be migrated to z/OS.  Those files can be copied to z/OS tapes during the weeks and days before switchover, or left on VSE tapes and catalogued as is to the z/OS catalog.

The large number of inactive and non-critical or obsolete tape files is not migrated.  They are either eliminated, or the VSE volumes are set aside together with a last copy of the VSE tape file catalog at switchover time.

Any automated operations product, which will be used for actual production after switchover, must be installed, loaded with used in production mode during regression testing, not for sample unit testing, but starting with full-size application functional testing and definitely throughout simulated production testing (see regression testing below).

Designing implementation standards for an z/OS job scheduler or report manager, and loading them with job scheduling or report management instructions, is best performed with the on-site assistance of a specialist acting as a mentor and a tutor.  Such specialist may either be provided by the vendor (part of the product licensing agreement) or hired outside for a couple of months.

Task 14 – Online Application Regression Testing

The objective of this task is to verify that the converted online applications are functionally equivalent to their VSE version, i.e. that they run exactly as they did under VSE and produce the same results.

Regression testing for online applications typically starts a few weeks before regression testing for batch applications.  This is because there is no JCL to convert for online applications.  JCL conversion requires more time than program or map conversion.

Prior to this task, an online test plan, and possibly detailed tests scripts, have been developed with and presented to the tests team, together with organizational instructions, during a pre-test orientation session (see “Task 02 – Project Planning”).

Full size copies of VSE production files are migrated to z/OS (as generally recommended, starting from Application Acceptance Test or User Acceptance Test), using procedures (VSE and z/OS JCL streams) developed from the CICS FCT table (after that table is purged from obsolete entries).  Those procedures are a first step towards what will later become the switchover file migration procedures.

Then, initialization tests are performed to verify that online applications (tables, transaction programs, screens, and files) have been properly defined to CICS.  Transactions are started to verify that the screens come up as expected.  Initialization test scripts identify the minimum input required to get from a screen to the next one.  At this level of testing, results and file updates are not verified.

The testing continues with thorough sample unit testing of 30 to 50 representative transactions.  The idea is to use limited resources (small test team and DASD) to verify that the conversion specifications and the automated conversion process generate sound z/OS application material (programs, screens and files), which execute without abnormal ending.  Results and file updates are verified.  The conversion specifications and automated conversion process usually need some adjustment before full-size resource-consuming functional testing can start.

Online application tests continue with full-size application functional testing involving a joint effort of the conversion team, applications support staff and selected end-users.  User exceptions are filtered and corrected by applications support.  Test exceptions created by improper conversion are identified and passed over to the conversion team for resolution.  Temporary manual bypass corrections are applied to the z/OS application, in order to quickly resume testing.  But each conversion error is also fully analyzed (qualitative and quantitative analysis).  A permanent and global (all occurrences) solution is developed by refining the custom modification of the conversion software or by developing additional conversion software. Additional mass or partial conversions generate new and correct z/OS application material.  Per design, the test of online transactions often requires the execution of batch jobs.  Both batch and online tests are integrated at this point.

A full-size network connection test is highly recommended a few weeks before switchover, although not always technically possible.

A performance test is also highly recommended, although online applications running under native z/OS usually run faster than the same application running under VM/VSE.  Fine-tuning online applications performance is often not possible until after the full production switchover to z/OS.

Task 15 – Batch Application Regression Testing

The objective of this task is to verify that the converted batch applications are functionally equivalent to their VSE version, i.e. that they run exactly as they did under VSE and produce the same results.

Prior to this task, a batch test plan has been developed with and presented to the tests team, together with organizational instructions, during a pre-test orientation session (see “Task 02 – Project Planning”).

Full size copies of VSE production files are migrated to z/OS (as generally recommended, starting from Application Acceptance Test or User Acceptance Test), using procedures (VSE and z/OS JCL streams) that will later become the switchover file migration procedures.

Batch application tests start with sample unit testing of 30 to 50 representative daily jobs.  The idea is to use limited resources (small test team and DASD) to verify that the conversion specifications and the automated conversion process generate sound z/OS application material (JCL, code and files), which execute without JCL error, ABEND or abnormal return codes.  Report contents and file updates are not verified at this stage.  The conversion specifications and automated conversion process usually need some adjustment before full-size resource-consuming functional testing can start.

Batch application tests continue with full-size application functional testing involving a joint effort of the conversion team, production control and applications support staff. User exceptions are filtered and corrected by the production control or applications support.  Test exceptions created by improper conversion are identified and passed over to the conversion team for resolution.  Temporary manual bypass corrections are applied to the z/OS application, in order to quickly resume testing.  But each conversion error is also fully analyzed (qualitative and quantitative analysis).  A permanent and global (all occurrences) solution is developed by refining the custom modification of the conversion software, or by developing additional conversion software. Additional mass or partial conversions generate new and correct z/OS application material.  Per design, the test of batch applications often requires the execution of online transactions.  Both batch and online tests are integrated at this point.

The switchover is rehearsed at the end of application functional tests.  It usually cannot exactly replicate the actual switchover, because there is no interruption of VSE operations.  But it includes as many of the actual switchover tasks as possible, especially for file and database migration.

The switchover rehearsal initiates simulated production tests, which include all jobs executed for a normal day, as identified in the VSE job scheduling documentation.  Duplicating VSE execution is usually not possible, due to some side effects of the job execution date, and the difficulty to capture all CICS transaction activity and external file inputs.  But to the difference of application testing, in which one system is tested at a time, this testing includes all systems, one day at a time.

It is critical to use for each test implementation task (scheduling, set-up, submission, execution control, result review and validation, debug) the exact same personnel who will be responsible for that task under z/OS after switchover.  Testing is not only to identify and correct conversion created regressions.  It is the only way to train and prepare the staff for z/OS operations.

There is often no better solution for result validation than to perform it manually, using application support personnel’s understanding of what is expected.  Automated file and report comparisons require running the exact same job under VSE and z/OS.  It is fairly easy on a small scale, but it often proves too complex and too time-consuming to implement on an enterprise-wide scale.

Task 16 – z/OS Switchover

The objective of this task is to switch the operations from VSE to z/OS over a few hours, and to run normal weekend operations under z/OS.

Preparing for switchover takes about a month.  A detailed and timed switchover plan is developed.  Final switchover file migration and backup procedures (VSE and z/OS JCL streams) are developed, starting from similar procedures used during testing.  The z/OS environment (catalogs, tape manager, disk space) is cleaned up from any trace of testing.  A final supply of programs and JCL is compared to the supply used for the final mass conversion.  Modified VSE elements are identified and converted to z/OS (or the VSE changes are manually applied to the z/OS version) to bring the z/OS applications to current VSE production level.

Switchover weekend activities include terminating VSE operations, backing up the VSE and z/OS environments, switching the network, executing file migration and cataloging procedures, starting z/OS operations with CICS transactions and jobs according to normal weekend schedule, and supporting z/OS operations through review and resolution of exceptions. On Sunday, the switchover is validated (stay under z/OS) or VSE fallback procedures are implemented (return to VSE in case of unexpected difficulties).

Task 17 – Post-Switchover Support

The objective of this task is to assist initial z/OS operations with conversion-related issues.  The conversion team works with the operations team to analyze and resolve any operations exception created by the conversion of programs and JCL, or by the file migration.  In particular, the conversion team systematically verifies if the exception is isolated, or if similar cases can be identified and corrected before they create new operations exceptions.  Initial z/OS operations typically require 24-hour on-site assistance during the first week.  It tapers down to 12-hour on-site plus 12-hour on call during the second week, and 8-hour on-site plus 16-hour on call during the third week.  The need for operations assistance by the conversion team ends three to five weeks after switchover.