CA-7 to TWS/OPC Conversion at SIGNAL IDUNA with the Support of XINFO

The migration affected 8000 jobs and was staged step-by-step over a six-month period using tools written in REXX by the author that did 90% of the conversion work.

Information is a prerequisite for all conversions. Any substantial conversion project will begin with an analysis of the current status. In the case concerned this will usually involve long-running CA-7 Batch-Terminal reports to dump all information from the database. This raw information will have to be collated into lists associating relevant details from various lists together to make them compact and easily readable.

It is not just a matter of documenting job attributes and their dependencies but also has to answer essential questions regarding the total conversion effort:

• Which Jobs are obsolete? Experts reckon that 15 -20% of the effort can be saved by identifying those jobs which have never run, not run since date ……, have no JCL attached although executable.

• Scheduling Information – many jobs have schedules but the actual total of distinct schedules within a data center will usually be relatively small. A maschine translation of schedules often produces difficult-to-read schedules in the target system.

• JCL constructs – the definitions within the JSS are usually only a small part of the effort involved – JCL which is dependent on the JSS and which uses JSS utility programs will need special handling and care, even if the JCL conversion can be partly automated.

This can be seen as affecting three areas:

1. The Migration process

2. CA-7 Features not available in TWS/OPC

3. Monitoring definitions and enforcement of standards

In the following we’ll look at these aspects separately.

XINFO produces graphic diagrams illustrating the job streams as planned in the scheduling system. During the migration these XINFO outputs can be used as a ready method to quickly gauge the quality of the conversion. No one can read and absorb all the information on a long written list but one look at the conversion result in graphic form will quickly show if something has been overlooked or not.

A gradual transition in the way we did it poses the problems of identifying conversion packages and residual dependencies. By this we mean identifying groups of jobs which are relatively well integrated with few outside dependencies between jobs already converted and those which have not yet been converted.

Note that XINFO delivers flowcharts based on the databases of all widely installed scheduling systems on MVS (TWS/OPC, Control-M, ZEKE, CA-7, CA-Scheduler, CA-Jobtrac, BAGJAS, APM/HS-5000).

• In the particular case in hand there are a number of features in CA-7 which the user would surely miss in OPC if no alternative can be found to fill the gap. For example:
  LDSN CA-7 keeps information on JOB/DSN relationships and DSN attributes. OPC does not. If you depend on this information you’ll need an alternative.

• LJCL CA-7 supports a direct relationship between JOB and JCL-Member. OPC does not keep a pointer to the source JCL library of an individual job. To know which library contains the JCL of a particular job will require another source of information.

• LPRRN, LRLOG When did that job last run? How often did it run last night? Other questions currently not directly answered by OPC.

These are just some of the questions left open. One can philosophise for a long time on the subject of whether the information belongs in a JSS or not, but the long and the short of it is: operations will need access to the information during and after conversion.

XINFO provides the above data and closes the gap between CA-7 and OPC.

Both systems and development often need valid and current information about jobstreams and their schedules.

This you can conveniently facilitate in CA-7 by just allowing them access to the “Lxxxx” commands of CA-7.

However, in OPC the list functions are embedded deeply and cannot be easily made available to a group which may only view but not update the database.

Once again XINFO makes the JSS structures of OPC available for browsing only – the user is not online to the JSS.

You’ll agree that answering the question “Where are we?” based on the migration road-map will be easy by comparing the two JSSs within XINFO.

Almost always a conversion means changing or rectifying standard naming conventions.
Here again XINFO allows selection based on almost any field in any table and comparison of output will quickly show up variances.

The functional validity of the conversion can also be verified as shown below on the attached query example that shows a job referring back to a predecessor which has not been converted. XINFO exposes the logical gap. The JSC (Job Scheduling System) will accept the definition of a predecessor which is not present in the database. Direct comparison and verification of the predecessor is made more difficult by the fact that OPC generally uses the Application name and Operation-Number to identify a predecessor rather than simply the jobname, as in CA-7.

The lists we create using our tools could be largely created using XINFO . You can make your own definitions in XINFO for any combination of available attributes by selecting and joining any of the tables. These queries can be built, tested and, if you want, permanently stored in the system.

Thus you could generate the following in XINFO:

• Job triggers

• Job dependencies Scheduling information

• Virtual or logical resources as used by jobs

• JCL affected by JSS constructs and utilities

• Obsolete jobs

• List of all jobs with selected attributes

These lists come tantalizingly close to what you need to automate the conversion anyway. What is currently missing is a list from XINFO which lists all jobs in a trigger chain and follows the chain down while taking account of the SCHID logic (just the way CA-7 FSTRUC does it). This logic is already there – after all the graphic flowcharts are based on exactly this. What we need is for it to be delivered as a DB2 table of relationships.

The remaining step would be to output the relationships in a format suitable to do a batch update in the target system. (but maybe we should be happy that there is still some work left for us external consultants!)

There is an ancient myth which still prevails in our industry: “The next conversion will be the last one!”

You remember Y2K, EURO etc.? Apart from those conversions what others did you have in all the years before them?

The next conversion is probably in sight or just around the corner. I don’t know what your next big conversion will be, but this I do know: whatever it is, it’ll involve finding out about current jobs, programs, databases, files and their oh-so-complex relationships and then modifying them.
But without disrupting production!

Any questions? xinfo@Horizont-it.com