Important! CA Workload Automation SE r11.1 provided cross-platform job definition through the XPJOB command. In CA Workload Automation SE r11.3, the new AGJOB command further enhances cross-platform job definition. Jobs defined using the XPJOB command, or the equivalent DB.10 panel, cannot be transported to a pre-r11.1 level. Jobs defined using the AGJOB command, or the equivalent DB.11 panel, cannot be transported to a pre-r11.3 level.
Starting with CA Workload Automation SE r11, data set DSNBRs could exceed one million. As a result, some massaging of the CA Workload Automation SE commands may need to be done if transporting jobs from an r11 release to a pre-r11 release of CA Workload Automation SE. If this action must occur, scan the data being used to import the jobs to the pre-r11 release and ensure that data set DSNBRs, if coded, are of the format DSnnnnnn (six numbers instead of eight numbers)
Occasionally, you may want or need to transfer work from one CA Workload Automation SE database to another. One reason for doing this might be to better balance the workload across multiple data centers. Another reason might be to move test applications into a production database from a test database. Certainly, other reasons exist for transferring information between databases.
The effort required to redefine manually the workload into another database, even with online preformatted panels, can be sizeable. The amount of time typically available for this activity is limited. In most cases, a weekend or after-hours is selected; whenever production is relatively inactive. When the database move is done manually, the accuracy is suspect, particularly when it is done hurriedly.
CA Workload Automation SE provides database transportability programs that, in batch mode and with the Batch Terminal Interface (BTI) facility, provide assistance in transfers of workload definitions.
The transportability process uses standard CA Workload Automation SE inquiry, Batch Terminal Interface (BTI) and Database Maintenance (DBM) facilities to assist the user in relocating workload definitions from one CA Workload Automation SE database to another or making mass changes. This process assumes that the workload to be moved or changed is in good running condition at the original (sending) site; that is, it is properly defined in the original site's database and presumably being run (or ready to be run) there on a regular basis.
Moving workload definitions from one database to another is a labor-intensive process. The impact on both of the databases can be major. Certainly, the impact on any two (or more) data centers involved in such a move is major. The movement of the following and some other related items are beyond the realm of the functions performed by the database transportability process:
This transportability process is only intended to simplify the CA Workload Automation SE database portion of the total effort required. Some of the data sets and control reports generated by this process can be of direct assistance, however, in moving other items such as PROCLIBs.
The workload is placed in the new (receiving) database through various ADD commands of the standard DBM functions. Therefore, the database that is to receive the definitions of jobs and networks, can initially be empty or may contain definitions of other work. When other work already exists in the database, the incoming work is effectively merged into the database. The user should be sure that the incoming work does not create any conflicts with preexisting work. The incoming work should have unique names for the following:
and other items. Adding the work through DBM ensures that duplications do not occur.
This process does not actually add the work to the database. It simply creates data sets with which the user may perform necessary functions. Some of the data sets contain standard BTI commands for performing DBM functions. Other data sets are for handling CA Librarian, [assign the PANVLT for your book], and PROCLIB members. (Movement of JCL can be suppressed if the user wants to do that external to this process.)
These command data sets can be used anytime after the user has reviewed, has altered, or both the commands to accomplish the desired results. The data sets can then be used whenever and wherever they are needed. The data sets must be generated using the original site database, wherever it is located. Once created, the data sets can be sent to whatever location needs them. Copies of the control reports that correspond to the data sets could also be of value at the new site.
The user may find it helpful as a planning aid to run these jobs, multiple times if necessary, just to get the reports that are produced. These reports provide an excellent inventory organized into meaningful groups. That is, cataloged procedures are listed on one report, DBM work on other separate reports, and so forth.
The process could be repeated as many times as necessary to get the correct results without making any updates to any database. Once the user is satisfied that everything has been properly considered and provided for, the process can then be run to create the desired command data sets.
|
Copyright © 2015 CA Technologies.
All rights reserved.
|
|