Scheduling Conversion

    

 The Fear of Converting

 Let’s face it. There are better production control solutions out there. Better solutions functionally, better solutions strategically, better solutions financially. The primary obstacle that keeps most IT organizations from pursuing those better solutions is the “Fear of Converting”. The basis of almost any fear is the unknown, and the “Fear of Converting” is no different.

The First Unknown: The Existing Production Control Environment

The scope and depth of the production control environment is extensive and far-reaching. From scheduling administration to JCL dynamics, from security definitions to work load monitoring, from resource availability to predecessor relationships, it is very difficult to maintain a full and complete understanding of all the elements that make up the production control environment.

The Second Unknown: The Conflicts in Converting to the New Platform

With all the various functions and facilities that make up the production control environment, it’s no wonder that many of the production control products provide unique implementations for each. In some cases, the new product platform may provide reduced functionality for a particular function. In other cases, the product may not support the function at all.

The Third Unknown: The Solutions that Exist Under the New Platform

During most production control conversions, there is often more than one way to address a conversion conflict. Some products may provide multiple inherit solutions for a single function, while others may support user specific customization to address functional limitations. The more solutions that exist, the more important it is to understand each solution before converting to the new platform.

The Fourth Unknown: The End-State Architecture

Finally, it is extremely difficult to ascertain the actual end result of a product conversion. What will the architecture look like? Will the products function differently? How will this impact my operations? What changes will be required beyond the production control environment to support the conversion?

Typical Vendor-Supported Conversions

Most product’s vendor-supported conversions do very little to ease the “Fear of Conversion”. These types of conversions are usually performed with very little up-front analysis. It is often very difficult to determine what the actual conversion problems are until after the new product environment has been built.

A typical vendor-supported conversion consists of the client performing data collection via canned product reports. These reports are then shipped to the vendor. The vendor feeds the reports into their “one-size fits all” conversion routine, producing a set of control cards, which is then sent back to the client. Using these control cards, the client must then build the product database.

This is followed by an extensive review of the definitions, by the client, to assess the validity of the conversion, which often results in significant manual customization. Finally, if the resources are available, the client performs simulations, forecasts, and real-time validation of database definitions, verifying the product database will function correctly within their production environment. For the majority of vendor-supported conversions, in addition to the activities stated above, the client is often fully responsible for the identification, analysis, translation, and verification of all production control components outside the product databases. These may include batch utilities, JCL dynamics, JCL variables, and automation interfaces.

 The Conversion Methodology

Our Conversion Methodology is focused around eliminating the “unknowns” associated with conversion. Conversion Services provides the tools and comprehensive knowledge to ease the fears of conversion by identifying the components, conflicts, solutions, and architecture up-front, before a single component is translated. Here’s how:

Component Level Analysis of the Existing Production Control Environment

We have long been a leader in analyzing and optimizing production control environments, under a variety of product platforms. This experience and knowledge plays an integral part to the conversion process. The analysis tools we use provide detailed, component level interrogation, spanning from scheduling definitions, to JCL analysis, to automation interfaces. All components of the production control environment are analyzed, and placed into a relational database. The information is then presented using functional queries, providing the “big picture” of what is actually occurring within the production environment.

Identification of Conversion Conflicts

Identifying the problems before they occur is one of the major benefits of the Conversion Methodology. Based upon the origination and target product platforms, conflict queries, are applied to the analysis database to identify conversion conflicts. These queries identify the components that are affected by the conflict, and provide insight into the scope of the problem.

Simulate the End-State Architecture

Using the analysis data, model queries simulate what the end-state architecture will look like. Everything from naming standards, to schedule definition translation, to physical groupings, to JCL record modifications are simulated. Where conversion conflicts exist, models are used to demonstrate the results of various solutions, allowing the client to determine the best solution for their, environment prior to implementation.

Programmatically Generate End-State Components

With the model queries as input, the definitions and components to support the end-state environment are programmatically generated. Control cards to generate the scheduling database are dynamically created. In addition, programmatic updates can be done to non-database components, such as JCL and proclib members.

Advantages to Conversion Services Methodologies

There are several advantages that Conversion Services offers over other product conversion services. These include:

Conversion Services are available to-and-from a variety of scheduling platforms, including CA-Jobtrac™, CA-7™, IBM TME10/OPC™, and ASG Zeke™.

Last Update: June 3, 2011