|
|
|
|
|
We strongly recommend that you do not define every report recipient in the organization at this point. If you have chosen a pilot application according to the recommendations supplied, then you should have about thirty recipients to define in the tree. As you progress to other applications, the tree will grow naturally.
Utilities for Automatically Creating Recipient Information
There are supplied utilities that can assist you in automating the definition process. The utilities selected for use will depend on which format you prefer for the tree and the recipient names. You can use any of the supplied utilities to automatically create recipient information in the tree. The supplied utilities are found in the IOA SAMPEXIT library. They are described below:
Utility CTDBLDJB
This utility is designed to either build the user tree from scratch, or to add users to an existing tree. The input to this utility is a file containing information about the recipients you want to insert in the tree. The utility can extract details from the file and insert recipient information such as Recipient Name, Parent, Synonyms, and Address into any defined levels of the recipient tree. The input to this utility could be a security report, such as an RACF report, that contains user IDs and group information that you want to define in the recipient tree.
Note: The DOCBLDTR member in the IOA DOC library contains a JCL sample for building a Control-D user tree.
Utility UADSTREE
This utility can be used to create a recipient tree from scratch. The input to this utility is dataset SYS1.UADS. This dataset contains the information about all TSO users. Each user ID is inserted as a recipient name into one specific level of the tree, and all recipients have the same parent.
Note: The CTDUADST member in the IOA SAMPEXIT library contains a program and job skeleton used by ICE to create the job for building a default Control-D user tree. You can customize the CTDUAST member using ICE, the same way as you would when customizing a sample exit from the IOA SAMPEXIT library.
During this phase, you will insert the basic recipient information for each of your identified recipients. It is recommended that, if possible, you use job titles rather than specific user names when supplying the address information in the tree definition. This will minimize the maintenance required if a user changes jobs, and so on.
If users currently have their names on reports, you should continue this practice under Control-D by specifying the user name in the address information. Do not try to force changes on the users. For each identified recipient of your pilot application, you should now define the following information in the appropriate levels of the recipient tree:
Below is an example of a definition in the Recipient Tree Definition screen:
Figure 5 Recipient Tree Definition Screen
------------------------ CONTROL-D RECIPIENT DEFINITION -------------------(T.S)
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
RECIPIENT BR11 RECIPIENT LEVEL 25 PARENT OPSADMIN PARENT LEVEL 10
DESC THIS IS THE BRANCH MANAGER IN MIAMI
DESC
==========================================================================
SYNONYM
AUTHORIZE $SYSDATA
ADDRESS MRS. ROBINSON
ADDRESS BRANCH MANAGER
ADDRESS BRANCH 11
ADDRESS 110 GLENDALE DRIVE
ADDRESS MIAMI
ADDRESS MI40 4PP
ADDRESS
===========================================================================
INDEX USER BANNER Y REPORT BANNER Y
DEF DEST
=========================================================================
P C P A R A M E T E R S
AUTHORIZED N
======= >>>>>>>>>>>> END OF RECIPIENT DEFINITION PARAMETERS <<<<<<<<<<<< ==
FILL IN RECIPIENT DEFINITION. 14.23.26
Insert the Administration Recipients
We recommend that you define the following administration recipients at the appropriate levels in the recipient tree:
Table 15 Recommended Administration Recipients
Lvl |
Title |
Instruction |
|---|---|---|
10 |
OPERATIONS |
Insert recipient OPSADMIN. You should insert only one recipient on the highest level of the tree. By default, this recipient will have authorization to see all reports handled by Control-D. (This can be limited, if required.) |
90 |
CD-CONTROL |
Insert recipient CDADMIN. This may be a recipient who needs access to certain distribution reports. |
95 |
OP-USER |
Insert recipient NULL. This recipient can be used as a destination for reports and/or pages that should be identified but never printed (such as application separator pages that are no longer required). Insert recipient PRODCNTL. This recipient can be made the recipient of all MSGCLASS output, so that it can be viewed online and archived if required. Insert recipient UNIDENT. This recipient will receive every page in a report that was not specifically identified according to the user-defined report decollating instructions. |
You can insert other administration-type recipients to suit your particular company’s operating methods. Whenever any changes are made to the tree, it should be reloaded to make the changes effective. The implementation hints chapter of the Control-D and Control-V User Guide includes a discussion about defining the levels of the organization, providing guidance to assist you when changes are made.
For information about reloading the recipient tree, see the Control-D and Control-V User Guide.
Note: You should by now have inserted your basic recipient information in the tree.You should by now have inserted your basic recipient information in the tree.
Please go to the summary at the end of this phase.
Parent Topic |