Setup steps

Setting up support for multiple developer groups requires some coordination between the z/OS® system programmer, the client administrator, and the administrator managing the selection criteria (LDAP or security administrator). In the following description of the work flow, the security administrator manages the selection criteria:
  1. The client administrator asks the security administrator for input about existing grouping setup for developers. Reusing the existing setup speeds up and simplifies push-to-client setup.
  2. The client administrator determines how he wants to structure the multiple group support, and who should be part of these push-to-client groups.
    Note:
    • There is always a default configuration set and a default product update scenario.
    • Push-to-client change sets can include delete, add, and overlay actions.
    • Push-to-client change sets can be empty.
    • A developer can be part of none, one, or multiple push-to-client groups.
    • The client administrator must be a member of each push-to-client group.
  3. The client administrator and the security administrator agree on the push-to-client group names to be used.
    Note: For additional information on group names, see Group name limitations.
  4. The client administrator creates the
    /var/zexpl/pushtoclient/grouping/<devgroup>
    directory for each push-to-client group.
    Note: The permission bits for this directory should be 775 (drwxrwxr-x).
  5. The security administrator does the required initial setup to define the push-to-client selection criteria profiles and adds the push-to-client groups to the access lists.
    Note:
    • The selection criteria structures must be defined with at least the client administrator on the access list before the client administrator can create the related push-to-client metadata.
    • For initial setup, only the client administrator should be on the access list for a push-to-client group. This to avoid z/OS Explorer clients receiving setups that are under construction.
  6. The z/OS system programmer activates multiple group support by adjusting pushtoclient.properties.
    Note: The *.enabled directives must be enabled before the client administrator can create the related push-to-client metadata.
  7. The client administrator creates the workspaces for each group and exports them to the host using the respective group names. The client administrator also creates the required response files to create group-specific product update scenarios.
  8. The security administrator adds the developers to the push-to-client groups, activating push-to-client for the developers.