Planning the Conversion

To assist the smooth running of the conversion process, BMC Software recommends that you carry out a number of steps before starting the conversion itself. These steps are set out in this appendix.

This appendix outlines the key Business Integrated Scheduling (BIS) functions and environmental metrics required to determine the initial level of effort associated with the migration of business processing to Control-M.

1: Organize the Conversion Team

Identify those who will be involved in the conversion process. They should participate in planning the conversion and implementing the steps in this appendix before beginning the conversion.

Include in this list those who support the current environment and who require training or retraining and/or mentoring, such as operators, production control administrators, product administrators, production analysts, application support and programming personnel, security administrators, data storage (SMS) administrators, and so on.
Verify that the conversion team has sufficient knowledge of the following:
- the features and operation of
  - CA-7
  - Control-M
  - the conversion utilities
- your existing scheduling information and its operation procedures
- your site rules on data set organization, naming conventions, and so on
- your expectations from the conversion project
Identify the exact release or version number of CA-7 that you are currently using.
Identify the operating system and platforms to be supported by Control-M in the target environment. In relation to each platform, identify the release level, number of systems, and physical location.

2: Analyze Your Hardware and Software

Consider the configuration of the system currently in use at your site, and whether you are making the best use of your hardware resources.

Obtain sufficient information to respond to the issues raised in this section. Record the answers carefully, because they will be of importance during and after the conversion to Control-M.

What resources, such as tape drives, do you use at your site?
What MVS images, that is, CPUs, LPARs, and Sysplexes, will be available to Control-M when running production jobs?
How are your MVS images connected? Is the connection by
- coupling facility
- shared spool
- NJE
- some other method
Are the systems managed separately or collectively? Is there job flow between systems?
Do you currently have multi-system dependencies, either on the same platform type, or using different platforms? If so,
- how many?
- how are they managed?
If your site Storage Facility Manager (SMS) limits the amount of space that a job can allocate to any given file, then depending on the number of schedules/jobs that must be converted (see 5: Generic Discovery Questionnaire), your Storage Administrator might be required to lift the restrictions on space allocations required by the conversion to avoid Sx37-type space abends.

3: Consider Current Practices

Consider the current practices at your site. The relevant issues include at least the questions set out in this section. Do not hesitate to ask others for information they may be able to provide. Take all software and hardware platforms into account when answering. Record the answers carefully, because they will be of importance during and after the conversion to Control-M.

How is production scheduling currently handled on your computers?
Who currently uses your system?
- Is there a single production department or are there several?
- Who are the end users of the system?
Consider the typical application flows at your site. The following are useful questions to ask:
- Which are the three key applications, in terms of size, complexity, or value to your business?
- How are those applications scheduled?
- How are their internal dependencies managed?
- Are there currently any performance bottlenecks or constraints in scheduling implementation?
List any products you use to support production scheduling, such as console automation, job restart products, and so on.
- What function does each such product perform?
- Will Control-M replace that function?
If you think that Control-M will not make some product redundant, obtain as much information as possible about that product, to enable you to decide how the product will interface with Control-M.
List all your applications, interfaces, user or system exits, reports, and similar material, that
- operators, system programmers, and other third parties have customized, and
- form part of the implementation of your current production scheduling
Include interfaces used to submit jobs from an internal front-end process, as well as any interface used to issue commands and/or perform tasks using batch utility programs.

Consider whether you can use Control-M to implement these functions and/or features.
Do you manually schedule any jobs or their logical successors on demand, instead of allowing the system to schedule jobs? If you do,
- list each job and record the way you deal with it
- consider whether Control-M can be used to schedule these jobs automatically
Do your jobs run automatically, on rigid scheduling, or do you frequently modify job schedules and/or dependencies to meet needs as they arise?
Consider your job concurrency requirements, and the way you meet those requirements. Examples of questions to ask are the following:
- Do you use job triggering, so that the completion of one job causes another job to be submitted or ordered?
- Do you use job dependencies, meaning that one job (the "waiting job") does not start until another has finished, even though the waiting job is submitted or ordered in some other way?
- Do you use negative job dependencies, meaning that if a job fails, another job starts?
How do you manage such resources as tape drives?
Consider the following questions about the jobs your systems currently perform:
- How many jobs do you currently have defined?
- How many jobs are run on a daily, weekly, or monthly basis?
- How many jobs run on peak days, for example, end of year processing?
- How many jobs run "on request", that is, demand jobs (see Question 6)?
- Are your existing job definitions satisfactory in every respect?
- Do you use all your existing job definitions, or are many now obsolete?
- How many jobs use JCL automation features? Identify the type of automation used.
- How many jobs are scheduled using data set triggering?
- How many jobs require manual intervention prior to submission?
How many jobs use JCL automation features? Identify the type of automation used.
How many jobs are scheduled using data set triggering?
How many jobs require manual intervention prior to submission?

Table 5 lists additional metrics to be considered for current practices.

Table 5 CA-7 discovery questionnaire

Metric	Response / Notes
Identify the number of CA-7 environments that require conversion to BMC Control-M.	For each: List the version of CA-7. Identify the environment that it supports in the organization (IE- Mainframe LPARS SYSA, PROD, TEST, and so on)
Identify any ancillary tools used in conjunction with CA-7.	This includes: CA-11. CA-DRIVER. Connectivity through CA-UNICENTER (UWCC). CA-7 Distributed Systems Agents, and so on
For each CA-7 environment list the number of defined jobs / tasks. Use the 'LJOB,JOB=*' command	Where relevant identify the number of mainframe and distributed systems job schedules.
For each CA-7 environment list the number of defined schedules. Use the 'LSCHED,JOB=*' command	Where relevant identify the number of mainframe and distributed systems job schedules.
List the approximate number of jobs submitted each day by each CA-7 environment.	Where relevant identify the number of mainframe and distributed systems job schedules.
Identify if any JCL override variables (IE - #JI / #JO) are used.	If so - identify the approximate number of jobs that make use of these variables.
List the type and number of external events tracked by CA-7 that triggers or otherwise serves as a prerequisite 'event' for the managed workload.	This includes but is not limited to: Dataset / File Activity System / Application Messages End User Submitted Jobs JCL / Script resident utility programs. Application code resident API calls.
Identify, if any the use of CA-7 external communicator steps that are imbedded in Production or User Submitted JCL or that are called from locally developed applications.	This includes but is not limited to: U7SVC CA7BTI SASSTRLR CAL2X2WB
Identify any integration points between CA-7 and other applications. For each integration requirement identify the name and version of the external item.	This includes, but is not limited to: Packaged business applications. ERP / CRM Reporting Change / Problem Management Security Locally developed application(s)
Identify any customization that has been locally applied to CA-7 or CA-11 that alter and/or extend their capabilities.	This includes EXIT code modifications, site specific vendor supplied code 'zaps', locally developed automation processes.
Identify the number of Administrators / Operators / Schedulers and Business Owners that will use BMC Control-M and require formal product education.	Administrators: Schedulers / Operators: Business / Application Owners:

4: Read the Conversion Guide

Read through this conversion guide. While doing so, consider the following points.

Identify any "special" situations. These can arise where
- the conversion will not be performed automatically
- your existing system is otherwise incompatible with Control-M, for example, where calendar generation may serve as a substitute for some scheduling parameters
Are the proposed solutions acceptable in all cases? If not, identify alternative solutions, such as the use of the supplied user exits.
Is there any aspect of the way you use CA-7 that may not be reflected in the reports and parameter files used by the conversion program?
Prepare the names to be used for libraries, table names, job names, conditions, resources, and so on, in the output of the conversion, in order to reflect the way you want the Control-M environment to appear to users.
Consider whether at this stage you are converting the entire production environment, or just one application? If you are only converting one application, determine
- how typical it is of the work done at your site
- what are the principal differences between this application and other applications

Consider whether you can yet identify any other pitfalls ahead, and if so, how to avoid the problems they appear to present.

5: Generic Discovery Questionnaire

Use the questionnaire in Table 6 to aid in the collection of information.

Table 6 Generic discovery questionnaire

Metric	Responses / Notes
Identify the current scheduling tool(s) and processes that require conversion to BMC Control-M.	For each: List the name of the tool. List the version of the tool. Identify the environment that it supports in your organization (IE- 'x' UNIX servers / 'x' Mainframe LPARS…)
Identify any ancillary tools used in conjunction with the scheduling tool.	This includes RERUN / RESTART components, Platform or Application Agents/Adaptors and Graphic User Interface (GUI) components.
List the number of job / tasks defined for each tool that requires conversion.
List the approximate number of jobs submitted each day by each instance of the scheduling tool.
Identify if any script / JCL variables are used with the current scheduling tool.	If so - identify the approximate number of jobs that make use of the job scheduler specific variables.
List the type and number of external events tracked by the scheduling tool that triggers or otherwise effects managed workload.	This includes but is not limited to: Dataset / File Activity System / Application Messages End User Submitted Jobs JCL / Script resident utility programs Application code resident API calls
Identify any external integration points between the current scheduling tool and other applications. For each integration requirement identify the name and version of the external item.	This includes but is not limited to: Packaged business applications ERP / CRM Reporting Change / Problem Management Security Locally developed application
Identify any customization that has been locally applied to the current tools that alter and/or extend their capabilities.	This includes EXIT code modifications, site specific vendor supplied code 'zaps', locally developed automation processes.
Identify the number of Administrators / Operators / Schedulers and Business Owners that will use BMC Control-M and require formal product education.	Administrators: Schedulers / Operators: Business / Application Owners: