Workspace binding

Even though a developer can be part of multiple groups simultaneously, the developer’s active workspace cannot. The active workspace must be bound to a specific configuration group (which can be the default group) and a specific product group (which can be the default group) to receive configuration or product updates. Once the bind is done, it cannot be undone. A new workspace must be created if a new group binding is required.

When a workspace that has no configuration group binding connects to the host, and config.enabledindicates the push-to-client function is active, z/OS® Explorer queries all configuration groups to determine to which groups the user belongs to and prompts the user to select a group. Upon successive connections, only the selected group is queried to see if the group membership is still valid.

When a workspace that has no product group binding connects to the host, and product.enabled indicates the push-to-client function is active, z/OS Explorer queries all product groups to determine to which groups the user belongs to and prompts the user to select a group. Upon successive connections, only the selected group is queried to see if the group membership is still valid.

The reject.*.updates directives can work with and without group definitions. If groups are used for reject.*.updates, then the group-binding of the related *.enabled directive is used. When an update is present, z/OS Explorer determines if the user is allowed to reject the update, and acts accordingly.

FEK.PTC.REJECT.*.UPDATES.sysname is used only for rejecting updates by workspaces bound to the default group. Workspaces bound to a group require you to be on the access list for FEK.PTC.REJECT.*.UPDATES.sysname.groupname to reject updates.