Distribution of updates by using push-to-client

Push-to-client overview

Implementing a push-to-client environment involves several tasks: some on the z/OS system and some on a client workstation. The following is an overview of how to implement a push-to-client environment. It defines some of the terms and resources that are used in this environment. The details for implementing push-to-client are described in subtopics.

1. Configure push-to-client on z/OS.

   Each remote system from which you intend to distribute product updates and configurations must be set up to support push-to-client.

   1. One z/OS system must be defined as the primary system. The primary system is the controlling system in a push-to-client environment. Only one z/OS system can be defined as primary. The primary system stores global configuration files, which apply to all systems in the push-to-client environment, and system configuration files, which apply only to the primary system itself. The global configurations are product updates, database connections, Eclipse preferences, Menu Manager files, and remote system connections.
   2. Other z/OS systems can be enabled for push-to-client as non-primary systems. Non-primary systems define only system configurations, which apply only to the non-primary system itself. System configurations are host-based projects, property groups, default values, file mappings, and remote index search.
   The starting point for configuring push-to-client on a z/OS system is a root file that is called pushtoclient.properties, which is in the /etc/zexpl/ directory on the z/OS system. This file contains entries that specify configuration parameters, such as:

   • Whether the function is enabled for product updates: indicated by setting product.enabled=true.
   • Whether the function is enabled for configuration updates: indicated by setting config.enabled=true.
   • Whether the current system is the primary system, that is, the system that controls the push-to-client feature: indicated by specifying primary.system=true|false.
   • Where to find the main configuration file, keymapping.xml: indicated by setting pushtoclient.folder=/var/zexpl/pushtoclient, the default location. The key mapping file contains pointers to a set of files that contain the application-related settings. These pointers are created from a Developer for z/OS client as part of the configuration file export process, described in step 4.
   • Whether group-level control of product and configuration updates is enabled: indicated by setting an access control attribute for certain configuration parameters in the pushtoclient.properties file. This feature allows a system administrator to create client groups and provide updates that are specific to each group. For example, to enable group control of configuration updates through RACF®, specify config.enabled=saf. To enable group control of configuration updates through LDAP, specify config.enabled=ldap. In the directory identified by the setting of pushtoclient.folder=/var/zexpl/pushtoclient, you must also create a folder named grouping. In the grouping folder, you must create a folder for each RACF or LDAP security group that is defined for use. The folder name must match the name of the security group exactly.

   For information about setting up LDAP access groups and SAF-based access groups, see Push-to-client considerations in the Host Configuration Reference.

2. Configure a model workspace with settings that you want to push out to other workspaces when access groups, see Push-to-client considerations in the Host Configuration Reference.
3. Configure a model workspace with settings that you want to push out to other workspaces when they connect to the z/OS system.

   After the remote system is set up, you can begin configuring the Developer for z/OS settings you want to push out to the rest of the organization. For most settings, such as Eclipse preferences, remote system connections, property groups, and file system mappings, this task is accomplished by updating the settings locally on a client. Some settings, such as product updates, host-based projects, and default values, must be configured manually on the z/OS system.

   If group-level control of updates is enabled for the push-to-client servers, then the model workspace is bound to a particular group when you export configurations to the server. Binding a workspace to a group means that the workspace defines configuration and preferences settings for that group only. Therefore, you need to define one model workspace for each push-to-client group defined on the servers.

4. Export the workspace settings to the z/OS system by using the Developer for z/OS configuration export wizard.

   The export wizard uploads the local configuration files (Eclipse preferences, remote system connections, property groups, and file system mappings) from the model workspace to the z/OS system. Only users who have authority to write files to the folder that contains the key mapping file on the remote system can export settings. After the settings are exported, users who connect to the z/OS system are prompted to update their workspaces with these settings.

For information about configuring and exporting the Developer for z/OS settings you want to push out to client workstations, see the remaining topics that are linked to in the following section.

Creating and distributing updates

The Developer for z/OS push-to-client function can distribute the following types of updates:

• Product installation updates. Developer for z/OS provides tools for system administrators to create product installation updates and prompt client workstations to install the updates when they connect to a remote system. This type of update supports only modification-level updates. You can use push-to-client to update clients from version 8.5 to version 8.5.1, for example, but not from version 8.5 to version 9.0 and not from version 9.0 to version 9.1. For more information about distributing product updates, see Distributing product updates.
• Product configuration updates. Developer for z/OS provides tools for system administrators to define remote system connections, define configuration files, and set client workstation preferences from a central location. These connection definitions, configuration files, and preferences can be distributed to individual client workstations automatically when they connect to a remote system. For more information about distributing configuration updates, see Creating and distributing configuration files.