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, Eclipse preferences, 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 file mappings.
   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 IBM Explorer for z/OS client as part of the configuration file export process, described in step 3.
   • 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 product and configuration updates that are specific to each group. For example, to enable group control of product updates through RACF®, specify product.enabled=saf. To enable group control of product updates through LDAP, specify product.enabled=ldap.

   For information about preparing z/OS systems for push-to-client configuration, see (Optional) pushtoclient.properties, the host-based client control(Optional) pushtoclient.properties, the host-based client control in the Host Configuration Guide (SC27-8437).

   For information about setting up LDAP access groups and SAF-based access groups, see these topics:

   • Push-to-client developer groupsPush-to-client developer groups in the Host Configuration Reference Guide (SC27-8438)
   • Push-to-client considerationsPush-to-client considerations in the Host Configuration Reference Guide (SC27-8438)
2. Configure a master 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 IBM Explorer 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, and file system mappings, this task is accomplished by updating the settings locally on a client. Some settings, such as product updates, must be configured manually on the z/OS system.

   If group-level control of product and configuration updates is enabled for the push-to-client servers, then the master 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 master workspace for each push-to-client group defined on the servers.

3. Export the workspace settings to the z/OS system by using the IBM Explorer for z/OS configuration export wizard.

   The export wizard uploads the local configuration files (Eclipse preferences, remote system connections, and file system mappings) from the master 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 IBM Explorer 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 IBM Explorer for z/OS push-to-client function can distribute the following types of updates:¹

• Product installation updates. IBM Explorer 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 2.1 to version 2.1.1, for example, but not from version 2.1 to version 3.0 and not from version 3.0 to version 3.1..
• Product configuration updates. IBM Explorer 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.