Decollation Without the Recipient Tree

If the number of potential recipients is very high or the names of the recipients change frequently, it may be desirable to not define all recipients in the Recipient Tree because:

• Defining and maintaining recipients in the tree can become a time-consuming task.
• The time required to load and search a very large tree can degrade the performance of some Control-V components.

By default, report pages of users who are not found in the Recipient Tree are sent to a "default recipient." This default is not appropriate if user names are intentionally not defined in the Recipient Tree. Therefore, alternative methods are required which:

• Decollate report pages to an extracted recipient name even if the name is not in the tree. A method to do this is described in 1.
• Enable report pages to be viewed by an online user even if the user is not defined in the tree. Methods to do this are described in 2.

Note: Certain recipients must not be omitted from the Recipient Tree. Recipients whose entries include special information (for example, recipient's address, synonyms, Control-D/WebAccess Server authorization, $SYSDATA access, special default destination) must be defined in the Recipient Tree.

To enable report decollation and viewing without defining all users in the Recipient Tree, follow these instructions:

1. In the report decollation mission definition, specify the value A in the T (type code) parameter of the DO USER statement. When the T parameter is set to A, a recipient name is accepted even if it is not in the Recipient Tree. For more information about the T parameter, see DO USER: Decollating Parameter (decollating mission).
2. Provide a mechanism which enables online users who are not defined in the Recipient Tree to access reports they are authorized to access. The most efficient mechanism depends on whether meaningful pseudo-recipients can be defined, which security products are used at the site, and whether or not information about recipients is maintained in other files or databases. The following items describe such mechanisms:
   1. Specify pseudo-recipients in the tree that represent groups of actual recipients (that is, a small number of pseudo-recipients can "receive" reports on behalf of a large number of undefined actual recipients).

      This mechanism can be used when each pseudo-recipient name can be a prefix formed by the first characters of the names of actual recipients followed by an asterisk (*). The AUTHORIZE fields for each pseudo-recipient should contain the name, prefix or mask of online users authorized to access reports of the actual recipients.

      For example: If the Recipient Tree contains an entry with a RECIPIENT field set to CLERK*, an AUTHORIZE field set to X123, and a second AUTHORIZE field set to Y??5???, then reports belonging to all recipients whose names start with CLERK can be accessed by users X123, YAA5, YZZ5123, and others whose names match the mask Y??5???.

   2. Use your site’s security product (RACF, Top Secret, CA-ACF2/SAF) to determine which reports can be displayed in the user report list for the current online user. This mechanism is especially useful when the reports for all online users can be allocated to a relatively small number of report access categories and/or the names of the users cannot be properly grouped by a user ID prefix.

      Specify the required information by authorizing online users to access entity

      $$REPLST.qname.recname

      where recname is the name of a recipient whose reports are available to the appropriate users. Set the DUSERLST parameter to NO and the DREPLST parameter to YES in the CTDSECP member in the SECSRC library. Then, recompile the CTDSE04 security module using the appropriate job (CTDSRAC1, CTDSACF1, and so on).

      This method does not check the AUTHORIZE field. However, it may cause significant overhead in the User Reports List screen (Screen U) because all recipients whose reports appear in Control-D Active or Permanent or History User List files are checked via the security product. Performance can be improved by implementing method C in addition to or instead of method B.

   3. Use function USERLIST of User Exit CTDX004 to create a list of recipients available for each online user. This mechanism is especially useful when up-to-date user ID information is maintained in other files or databases at the site.

      Sample Exit CTDX004U in the SAMPEXIT library shows how to build such a list of recipients. Exit CTDX004U creates a list by checking the AUTHORIZE field in the Recipient Tree and adding the name of the current online user to the list. This exit can be modified for extracting a list of recipients from a site database or for building the list based on various rules.

      The list of recipients can contain prefixes (such as XX*), but usage of short prefixes can cause significant overhead since they are expanded by scanning the User Report List files. Sample Exit CTDX004U is useful for implementing simple rules such as ‘each online user can access the reports of the recipient with the same name.’