Preparing for Production

This chapter includes the following topics:

Introduction

Now that you have gone through the tutorial in the preceding chapters, you are now ready to implement Control-D in production. If you have not performed the exercises in the previous chapters, please do so now before proceeding.

This chapter provides suggestions and recommendations for implementing Control-D in your production environment.

For more information about Control-D options, refer to:

Building the Recipient Tree

The Recipient Tree is a list of all possible report recipients. The tree can be organized in many ways. The simplest design is a non-hierarchical list of all users that is primarily used during early stages of Control-D implementation. However, the benefits of Control-D can be maximized by using a hierarchical Recipient Tree.

Experience working with Control-D implementation suggests that you should not try to define the "best tree" before you implementing Control-D. Instead, you must first implement a basic hierarchical tree following the guidelines in Chapter 7 of the Control-D and Control-V User Guide. You can modify the tree structure and contents as you become more familiar with different options of the product, and as you gain a greater understanding of the implications of tree changes in your report distribution environment.

In general, if you find that you are spending too much time designing the "best tree," simply choose one of the alternatives you have been considering and modify it by trial and error until it fits your environment. You see results much faster this way.

Two of the supplied utilities can help you define the basic recipient tree required for starting implementation of Control-D.

Table 4 Recipient Tree Utilities

Utility

Description

CTDUADS

Creates a recipient entry for each user (TSO-user) defined in the CTD JCL Library.

CRETREE

Creates a recipient entry for each user name that appears in a specified line and column range within a given report (similar to the USER = * option in the report decollating mission).

The IOA SAMPLE library contains an example of each utility with detailed information.

Defining New Reports for Decollation

Define decollating parameters for a new report as follows.

Begin

  1. Produce the report on spool (preferably by a test job) to a class that is not printed. Note the class used.

  2. Obtain all distribution requirements for the new report.

    • If the report is to be distributed in its entirety to one or more recipients, no additional information is required.

    • If different pages of the report are to be distributed to different users, determine an identifying character string that is unique to specific users (usually the report header and/or title), and note the identifying string and the string's position in the report (line and column range). Methods for determining exact string position appear below. It is also possible to identify a larger range of lines and columns in which the string will appear.

  3. Determine the exact position of a recipient name, or any other string within a report, using one of the following methods:

    • View the report online using any spool display facility installed at your data center (FLASHER, SDSF, and so on). The exact column range in which a string appears can be determined with the aid of the COLS command (or equivalent).

    • Activate a job decollating mission with no separation criteria specified. Assign the entire report to one recipient. View the report in the Control-D Online Viewing facility (Option U).

  4. After the required information has been gathered, enter the Report Decollating Definition screen (Option R). Update report identifying information (if required for this report) and distribution information, as described in the Walkthrough.

  5. Save the updated report decollating mission and manually order it. View the results of the test in the Active User Report List screen (Option U). If the results are as expected, add any additional parameters that are needed (such as DO PRINT, DO BACKUP, and so on), and the report is ready for production. If the results are not as expected, determine which parameter was specified incorrectly (for example, wrong column for identifying string, and so on), correct it, and order the report decollating mission again.

  6. When the report decollating mission is ready for production, set it up for automatic ordering. For further information refer to Setting Up Automatic Orders of Missions.

Defining Additional Backup/Restore Missions

When Control-D is installed, a number of commonly-used backup and restore missions are supplied. Following is a list of these missions:

Table 5 Commonly Used Backup and Restore Missions

Mission

Name

Description

Backup Missions

 

BKP0007D

Backup reports for 7 days (one week).

BKP0031D

Backup reports for 31 days (one month).

BKP0180D

Backup reports for 180 days (half of a year).

BKP0365D

Backup reports for 365 days (one year).

Restore Missions

RST0060M

Restore reports every 60 minutes.

RSTADHOC

Restore reports by manual request.

In most cases, the supplied missions meet the requirements of your data center.

If you want to define additional backup and/or restore missions, use the CLIST CTDCRMIS. This CLIST accepts essential information concerning the requested mission and builds all required components for the mission. The required components built by the CLIST are:

  • Backup or restore mission definition in the BKPMIS or RSTMIS libraries. This definition contains identifying information, scheduling criteria, number of days to keep (for backup missions), run interval (for restore missions), and so on.

  • JCL skeleton in the Control-D SKL library. This skeleton is used to build backup and restore jobs in conjunction with the backup and restore utility for a site (specified during the installation process).

After activating the CLIST, all required components are created, and the mission can be activated.

To set up the mission for automatic ordering, see Setting Up Automatic Orders of Missions.

While processing a backup and/or a restore mission, Control-D creates the JCL required for the backup or restore job. The skeleton of the JCL resides in the Control-D SKL library. The JCL created for each backup or restore mission is stored in the Control-D JOB library. It is important to compress the Control-D JOB library periodically, preferably daily.

Setting Up Automatic Orders of Missions

All missions in Control-D can be ordered manually or automatically. In the Walkthrough, you ordered certain missions manually. Other missions (printing, backup and restore) were ordered automatically. Here are a number of suggestions about how to order missions automatically.

The Control-D New Day Procedure (CTDNDAY) orders missions automatically every time it executes (once a day – the exact time is defined during the installation process). The New Day Procedure executes at the beginning of your working day. Therefore, all required missions can be ordered by CTDNDAY for the coming working day.

CTDNDAY orders for each mission type are contained in members found in the Control-D PARM library. These members are:

Table 6 CTDNDAY Mission Lists

Member

Description

PRTLIST

List of all printing missions to be ordered.

BKPLIST

List of all backup missions to be ordered.

RSTLIST

List of all restore missions to be ordered.

REPLIST

List of all (non-Generic) report decollating missions to be ordered.

GENLIST

List of all generic report decollating missions to be ordered.

Update these members to include any new missions to be ordered.

Missions can be ordered independently (not by CTDNDAY) by using a batch job. Reserve the batch method for special circumstances, such as ordering report decollating missions automatically, at a different time than the time when CTDNDAY executes. As a general rule, order all generic decollating missions by the CTDNDAY procedure. For detailed information about ordering missions, see the Control-D and Control-V User Guide.

Control-M Users

If your data center uses the Control-M Production Control System, order report decollating missions automatically while ordering the associated job in Control-M. This option is implemented by Control-M parameter D-CAT (defined in Screen 2 of the Control-M Online facility, but prior to version 5.1.4 called CATEGORY). For more information about this option, see the Control-D and Control-V chapter of the INCONTROL for z/OS Administrator Guide and the parameters chapter of the Control-M for z/OS User Guide.

Control-D Utilities

There are many utilities available in Control-D. The following pages explain utilities that are recommended for use from the first day of running Control-D. All Control-D utilities (including the utilities mentioned here) are documented in the INCONTROL for z/OS Utilities Guide.

Deleting a Disk Copy of Unneeded Reports

Once a report is no longer needed for online viewing (or printing), it can be deleted from disk. The utility that performs this task is CTDDELRP.

CTDDELRP performs the following tasks:

  • Deletes from the active User Report list all reports that meet the criteria specified to CTDDELRP.

  • Deletes the CDAM datasets for the reports.

  • Updates the History User Report list to indicate which reports were backed up. The backup mission writes the reports to tape (or cartridge) but does not delete the reports from disk. To eliminate unnecessary restores of reports that still reside on disk, reports remain in the active User Report list until they are deleted from disk by CTDDELRP. After reports are deleted from disk, restore requests are allowed for the backed up reports.

The Control-D JCL library contains member CTDDELRP. The supplied utility deletes all reports that have been printed and/or backed up (if requested) without waiting additional days. You can change the DAYS parameter to a different value. (For example, a value of 1 saves all reports on disk for 1 day after the day of creation.)

It is recommended that you run this utility once a day, preferably after all backups have finished executing.

However, for test purposes, it is desirable to run this utility more than once a day. After decollating a test report, it is frequently required to delete the report produced from disk. Sample JCL CTDDELR1 in the Control-D JCL library performs this task.

Additional parameters are optional. It is recommended that you review them.

Deleting Expired Backed-Up Reports

After the retention period for backed up reports has expired, delete the reports and release the tape (cartridge) on which they reside. Control-D utility CTDCLHST (clear history) deletes expired backed up reports.

Utility CTDCLHST performs the following tasks:

  • Deletes entries of expired reports from the History User Report file.

  • Produces a list of all tape (cartridge) volume serial numbers that are no longer needed. Under HSM, an HSM DELETE command is performed for each of the deleted reports.

There is no need to specify parameters for this utility. Just submit the example from the Control-D JCL library.

It is recommended that you run this utility once a day, or at least once a week.

Printing Considerations

Defining Additional Printing Missions

When installing Control-D, a printing mission named STD was supplied. This printing mission is intended to print all standard form reports of your data center.

Define a printing mission for each printing form in your data center. Make the printing mission name the same as the form name that is printed. This relates the physical form to the printing mission.

All parameters for defining new printing missions and printing recommendations are documented in the Control-D and Control-V User Guide.

Bundling Reports

Control-D printing missions bundle reports in one of two ways: one-chunk and multi-chunk method.

One-Chunk Method

The entire bundle is sent to the spool for printing at one time.

Activate this method by setting the value of CHUNKSIZE to 0 in the printing mission definition. If CHUNKSIZE is not specified, it defaults to the value specified during the installation process (in the PRINTER parameter).

Use this method to print reports that contain identical printing characteristics.

Multi-Chunk Method

Control-D creates a new chunk each time the number of lines specified in the chunksize parameter is exceeded, or when printing characteristics or the reports change, whichever comes first (unless chunksize is set to "0" as described in the one-chunk method above). Chunksize can be specified in the printing mission definition. If chunksize is not specified, it defaults to the value specified during the installation process. For the multi-chunk method, the value specified for chunksize must be greater than 1. The recommended value is 10000.

There are two major advantages of multi-chunk processing:

  • It prints reports with different printing characteristics in the same bundle.

  • Since the size of the chunk is controlled, overloading the spool with too much output is prevented.

If you want additional information on how to use the multi-chunk method, refer to the Control-D and Control-V chapter of the INCONTROL for z/OS Administrator Guide.

Define each printing mission using one of the two methods described above.

XEROX (DJDE) Printers

Control-D supplies enhanced XEROX printer support. During Control-D installation, there are a number of tasks to be performed that are explained in the Control-D chapter of the INCONTROL for z/OS Installation Guide: Installing.

If you print on XEROX printers, read "Printing Using XEROX LCDS (DJDE) Parameters" in the Control-D and Control-V chapter of the INCONTROL for z/OS Administrator Guide.

AFP Printers

Control-D supplies enhanced Advanced Function Printing (AFP) printer support. During Control-D installation, there are a number of tasks to be performed that are explained in the Control-D chapter of the INCONTROL for z/OS Installation Guide: Installing.

If you intend to print on AFP printers, read the following the following documents:

Tailoring the Banners

Bundles printed by Control-D are preceded by a header banner page, and each group of reports (or parts of reports) belonging to a specific user is separated by a banner page. Each report within the group of reports for a specific user is also separated by a banner page.

Banners are printed by printing missions and by the immediate print option.

A sample BANNERS library is supplied as part of the Control-D installation. The banners printed in Part 1 are from the sample banners. Each type of banner is defined in a regular PDS member. The supplied banners are:

Table 7 Supplied Banners

Name

Description

$$BNDLST

Start of bundle banner.

$$BNDLEN

End of bundle banner.

$$USERST

Start of a user (recipient) reports banner.

$$USEREN

End of a user (recipient) reports banner.

$$REPSTA

Start of report banner.

$$REPEND

End of report banner.

$$UINDXH

Header of reports index.

$$UINDXV

Format of each index line.

$$ONLSTA

Start banner of immediate print requests.

$$ONLEND

End banner of immediate print requests.

Banners are optional and do not have to be printed. To delete a banner, simply rename the member for the specific banner type. For example, to delete the start of report banner and end of report banner, rename the following two members $$REPSTA and $$REPEND in the BANNERS library.

The supplied banners are samples that can easily be modified. Since the banners are regular PDS members, you can edit and change their format. Additional options, such as enlarging characters of the user address on the banner at the beginning of the user bundle, are explained in the Control-D chapter of the INCONTROL for z/OS Installation Guide: Installing.