IBM. Client Configuration Guide. IBM Explorer for z/os. Version 3 Release 1 SC

IBM Explorer for z/os IBM Client Configuration Guide Version 3 Release 1 SC27-8435-01

IBM Explorer for z/os IBM Client Configuration Guide Version 3 Release 1 SC27-8435-01

Note Before using this information, be sure to read the general information under Notices on page 59. Third edition (September, 2017) This edition applies to IBM Explorer for z/os Version 3.1.1 (program number 5655-EX1) and to all subsequent releases and modifications until otherwise indicated in new editions. Copyright IBM Corporation 2018. US Goernment Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

Contents Tables............... About this document........ ii Who should read this book......... ii Chapter 1. Client configuration oeriew 1 Chapter 2. Value Unit client licensing considerations............ 3 Chapter 3. Planning a push-to-client enironment............. 5 Chapter 4. Distribution of updates by using push-to-client......... 7 Distributing product updates......... 9 Updating the installation configuration file... 10 Updating the key mapping file....... 13 Properties in pushtoclient.properties that affect product updates............ 14 How reject.product.updates affects installedversion and forcedupgradeversion.. 14 Creating and distributing configuration files... 15 Creating a master workspace for push-to-client configuration............. 16 Defining connections, configuration files, and preferences for push-to-client configuration... 17 Exporting push-to-client configuration files... 27 Resetting workspace configuration files.... 29 Key mapping file........... 31 Chapter 5. Configuring indiidual workbench settings......... 33 Updating workspace configurations and preferences 33 Setting preferences for z/os tools....... 35 Setting preferences for client certificate authentication............ 35 Setting preferences for configuration updates.. 37 Setting preferences for MVS Files subsystems.. 37 Setting preferences for Remote z/os Search.. 39 Tracing............... 40 z/os Solutions preferences........ 41 Chapter 6. Configuring non-rse system connections......... 43 Configuring a z/os FTP system connection... 43 Configuring a proxy serer......... 45 Configuring a z/osmf system connection.... 46 Defining connection credentials........ 47 Connecting to a system that is already defined.. 48 Connecting to a system from the Host Connections iew........... 49 Connecting to a system by using Signon.... 49 Connecting to a system from the connection status bar.............. 50 Connecting automatically at startup...... 51 Using shared connections.......... 52 Updating a system connection........ 53 Exporting connections........... 53 Remoing a default setting from a category or connection............... 54 Deleting a system connection........ 55 Disconnecting from a system........ 56 Appendix. Accessibility features for z/os Explorer............ 57 Notices.............. 59 Copyright license.......... 63 Trademark acknowledgments..... 65 Index............... 67 Copyright IBM Corp. 2018 iii

i IBM Explorer for z/os: Client Configuration Guide

Tables 1. Relationship between installedversion and reject.product.updates........ 15 2. Relationship between forcedupgradeversion and reject.product.updates....... 15 3. Global configuration files........ 18 4. System configuration files........ 19 5. Examples of wildcard patterns in data set mappings............. 25 Copyright IBM Corp. 2018

i IBM Explorer for z/os: Client Configuration Guide

About this document Who should read this book This document discusses the configuration of IBM Explorer for z/os. It includes instructions on how to configure push-to-client, how to configure indiidual workbench settings and how to configure non-rse system connections. The following names are used in this manual: IBM Explorer for z/os is called z/os Explorer. Remote System Explorer is called RSE. z/os UNIX System Serices is called z/os UNIX. IBM Deeloper for z Systems (preiously known as Rational Deeloper for z Systems) is called IDz. This document is part of a set of documents that describe the installation and configuration of z/os Explorer client. For the installation of z/os Explorer client, see IBM Explorer for z/os Client Installation Guide (SC27-8434). This document is intended for programmers who are configuring IBM Explorer for z/os client Version 3.0. It describes how to configure push-to-client, indiidual workbench settings, and non-rse system connections. Copyright IBM Corp. 2018 ii

iii IBM Explorer for z/os: Client Configuration Guide

Chapter 1. Client configuration oeriew System administrators can configure system and global settings and distribute these settings throughout the deelopment organization. Indiidual deelopers can configure the local workbench client. Configuring and distributing system and global settings Chapter 3, Planning a push-to-client enironment, on page 5 Chapter 4, Distribution of updates by using push-to-client, on page 7 Distributing product updates on page 9 Creating and distributing configuration files on page 15 Exporting push-to-client configuration files on page 27 Configuring indiidual workbench settings 1 Updating workspace configurations and preferences on page 33 Setting preferences for z/os tools on page 35 1. For IDz users, bidirectional languages and enabling firewall are also supported. For more information, search for Supporting bidirectional languages and Enabling firewall support in IDz KC. Copyright IBM Corp. 2018 1

2 IBM Explorer for z/os: Client Configuration Guide

Chapter 2. Value Unit client licensing considerations z/os Explorer client enables Value Unit (VU) client licensing for licensed products that are installed with z/os Explorer ersion 3.0.1 and later. z/os Explorer VU generates a Uniersally Unique Identifier (UUID) to support licensed clients that are installed with z/os Explorer. When VU licensed client images are centrally created and distributed to multiple client machines or machine images, a new UUID needs to be generated on each machine or machine image. The UUID is required to maintain the correct licensed client count. To generate a UUID for each client image distributed in this manner, specify the -DUUID.reset=true option in the eclipse.ini file. After a new UUID is generated in the client, remoe the -DUUID.reset=true option in the eclipse.ini file. Copyright IBM Corp. 2018 3

4 IBM Explorer for z/os: Client Configuration Guide

Chapter 3. Planning a push-to-client enironment The IBM Explorer for z/os product offers the push-to-client feature for administering and sharing connections, preferences, properties, and configurations so that deelopers hae a consistent and centralized deelopment enironment. You can take either of two approaches to creating a deelopment enironment with the IBM Explorer for z/os product: You can allow a decentralized enironment in which deelopers create their own connections to remote systems; set preferences for their workspaces; and manage other aspects of the enironment. You can centralize and automate the creation and distribution of connections, preferences, properties, and configurations so that deelopers workspaces are consistent across the site and settings are downloaded to workspaces automatically when deelopers connect to a remote system. The push-to-client feature proides the tools that you need to create a centralized and automated deelopment enironment. By using the push-to-client feature, you can distribute the following configuration files: Global configuration files 2 : Eclipse preferences Remote system connections Installation configuration System configuration files 3 z/os file system mappings In a push-to-client enironment, these configuration files are stored on a remote system. When a workspace connects to the remote system, the configuration files are downloaded to the workspace. In this way, you can define a set of Eclipse preferences, for example, that is automatically downloaded when a connection is made. If you update the configurations between connections, deelopers are prompted to update their workspaces when they connect. In a decentralized enironment, deelopers still hae the opportunity to share configurations by exporting them from one workspace and importing them into another workspace. For more information about the push-to-client feature and about migrating configurations from one workspace to another, see the related topics. Related concepts: 2. For IDz users, global configuration files also include the settings of Database connections, Software Analyzer Configurations, Menu Manager files, and Snippets. For more information about theses settings, search for Defining connections, configuration files, and preferences for push-to-client configuration in IDz KC. 3. For IDz users, system configuration files also include the settings of Property groups, Host-based projects, Remote index locations and Default alues. For more information about these settings, search for Defining connections, configuration files, and preferences for push-to-client configuration in IDz KC. Copyright IBM Corp. 2018 5

Chapter 4, Distribution of updates by using push-to-client, on page 7 You can configure IBM Explorer for z/os to automatically distribute product updates and updates to configuration files, preference settings, and remote system connections when client workstations connect to a remote system. This feature is called push-to-client. By using it, you can store workspace configurations in a central location and push them to client workstations so that your deelopers hae a consistent workspace enironment. 6 IBM Explorer for z/os: Client Configuration Guide

Chapter 4. Distribution of updates by using push-to-client You can configure IBM Explorer for z/os to automatically distribute product updates and updates to configuration files, preference settings, and remote system connections when client workstations connect to a remote system. This feature is called push-to-client. By using it, you can store workspace configurations in a central location and push them to client workstations so that your deelopers hae a consistent workspace enironment. Push-to-client oeriew Implementing a push-to-client enironment inoles seeral tasks: some on the z/os system and some on a client workstation. The following is an oeriew of how to implement a push-to-client enironment. It defines some of the terms and resources that are used in this enironment. 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. a. One z/os system must be defined as the primary system. The primary system is the controlling system in a push-to-client enironment. 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 enironment, and system configuration files, which apply only to the primary system itself. The global configurations are product updates, Eclipse preferences, and remote system connections. b. 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=/ar/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 on page 8. Whether group-leel 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 proide product Copyright IBM Corp. 2018 7

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 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 deeloper groups in the Host Configuration Reference Guide (SC27-8438) Push-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-leel control of product and configuration updates is enabled for the push-to-client serers, then the master workspace is bound to a particular group when you export configurations to the serer. 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 serers. 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 hae 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: 4 Product installation updates. IBM Explorer for z/os proides 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-leel updates. You can use push-to-client to update clients from ersion 2.1 to ersion 2.1.1, for example, 4. For more information about the push-to-client function, search for Soling problems with push-to-client configuration and implementation in IDz KC. 8 IBM Explorer for z/os: Client Configuration Guide

Distributing product updates but not from ersion 2.1 to ersion 3.0 and not from ersion 3.0 to ersion 3.1. For more information about distributing product updates, see Distributing product updates. Product configuration updates. IBM Explorer for z/os proides 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 indiidual client workstations automatically when they connect to a remote system. For more information about distributing configuration updates, see Creating and distributing configuration files on page 15. The IBM Explorer for z/os push-to-client feature proides tools for system administrators to create product installation updates and prompt client workstations to install the updates when they connect to a remote system. Before you begin This type of update supports only modification-leel updates. You can use push-to-client to update clients from ersion 3.1 to ersion 3.1.1, for example, but not from ersion 3.1 to ersion 4.0 and not from ersion 4.0 to ersion 4.1. You can distribute product updates after the IBM Explorer for z/os serers are installed and configured on a remote system. To complete the push-to-client tasks, the IBM Explorer for z/os pushtoclient.properties file must be configured to distribute product updates. For information about push-to-client configuration, see (Optional) pushtoclient.properties, the host-based client control in the Host Configuration Guide (SC27-8437). While you complete these tasks, you might need to create or update the following files. These procedures explain how to update the files. An IBM Installation Manager response file. For instructions for creating a response file, see Silent installation in the Client Installation Guide (SC27-8434). An IBM Installation Manager product actiation kit file. If the product update requires a product actiation kit, you can place the kit in a network location and refer to the location from the response file. A key mapping file. This file defines the location of other files, such as installation response files and configuration files, that are distributed automatically to client workstations. The key mapping file is called keymapping.xml. Its default location on the z/os system is /ar/zexpl/pushtoclient. An installation configuration file. This file defines the product offering IDs, a range of IBM Explorer for z/os ersions, and the name of the response file that installs the product update. The push-to-client feature scans the installation configuration file for an applicable product offering ID and installed ersion. If found, it starts Installation Manager with the specified response file. The installation configuration file is called installconfig.xml and is in the path indicated by the <fileid>com.ibm.ftt.resources.zos.install.configuration</ fileid> tag of the key mapping file. A push-to-client properties file, called pushtoclient.properties. This file defines the location of the key mapping file. The default location of the pushtoclient.properties file on the z/os system is /etc/zexpl/. For more information about the pushtoclient.properties file, see (Optional) pushtoclient.properties, the host-based client control. Chapter 4. Distribution of updates by using push-to-client 9

About this task When a client workstation connects to a remote system that is configured to distribute product updates, the push-to-client feature compares the client product ersion with a range of ersions that are defined in the installation configuration file. If the installed ersion is in this range, the IBM Explorer for z/os workbench shuts down and starts the IBM Installation Manager product by using a response file that is downloaded from the remote system. Procedure To create and distribute product updates: 1. Create an IBM Installation Manager response file for the product installation that you want to distribute. For instructions for creating a response file, see Silent installation. Important: If user authentication is required to access the code repository for the update, then users must sae their user IDs and passwords in IBM Installation Manager. 2. Create or update the installation configuration file to indicate the range of product ersions that triggers an update and the response file for installing the update. For instructions for creating or updating the installation configuration file, see Updating the installation configuration file. 3. Update the key mapping file to point to the installation configuration file and the response file. For instructions for updating the key mapping file, see Updating the key mapping file on page 13. Related concepts: Chapter 4, Distribution of updates by using push-to-client, on page 7 You can configure IBM Explorer for z/os to automatically distribute product updates and updates to configuration files, preference settings, and remote system connections when client workstations connect to a remote system. This feature is called push-to-client. By using it, you can store workspace configurations in a central location and push them to client workstations so that your deelopers hae a consistent workspace enironment. Related tasks: Installing client updates Related reference: How reject.product.updates affects installedversion and forcedupgradeversion on page 14 The behaior that is triggered by the installedversion and forcedupgradeversion attributes is affected by the reject.product.updates parameter of the pushtoclient.properties file. Properties in pushtoclient.properties that affect product updates on page 14 Seeral properties that are specified in the pushtoclient.properties file work together to determine how product updates are deliered by the push-to-client feature. Updating the installation configuration file Create or update the installation configuration file. 10 IBM Explorer for z/os: Client Configuration Guide

About this task This type of update supports only modification-leel updates. You can use push-to-client to update clients from ersion 3.1 to ersion 3.1.1, for example, but not from ersion 3.1 to ersion 4.0 and not from ersion 4.0 to ersion 4.1. Procedure 1. Create or edit the installconfig.xml file. If this file exists, you can add entries for the installation to this file. If the file does not exist, you can copy the sample installation configuration file that is shown at the end of this procedure, modify it for your installation, and sae it to the z/os serer. The installation configuration file is a UTF-8 encoded XML file. 2. Include the <installedoffering> tag to identify the offering ID of the product you want to distribute updates for. The <installedoffering> tag has the following syntax: <installedoffering id="installedofferingid"> You can specify an offering ID for any product that is installed in the same package group as the IBM Explorer for z/os product. The offering ID is stored in the <offering> tag of the response file. The following is an example of the <offering> tag: <offering id= com.ibm.zos.explorer.30 ersion= 3.0.0.20151002_1738 profile= IBM Software Deliery Platform features= listofinstalledfeatures /> Specify the alue in the id attribute of the <offering> tag for the id attribute in <installedoffering id="installedofferingid">. 3. Include an <install> tag with one of the following attributes to specify a range of product ersions to be updated and the name of the response file to install the product update. Only one of the following attributes can be defined for each installed offering ID in the installation configuration file. If both attributes are specified, the installedversion attribute takes precedence oer the forcedupgradeversion attribute. Important: The behaior that is triggered by the installedversion and forcedupgradeversion attributes is further defined by the reject.product.updates parameter of the pushtoclient.properties file. For more information about how these attributes are affected by the reject.product.updates parameter, see the related topics. An installedversion attribute. If the ersion currently installed on a client workstation is within the installedversion range, a confirmation window opens and the client can accept or refuse the update. When the update is accepted, Installation Manager starts with the response file specified in the responsefile attribute to update the client. <install installedversion="[minimumversioninclusie, maximumversioninclusie] (minimumversionexclusie, maximumversionexclusie)" responsefile="filename"> A forcedupgradeversion attribute. If the ersion currently installed on a client workstation is within the forcedupgradeversion range, a confirmation window opens, but the client cannot reject the update. If the ersion is outside of the range, the client is not prompted with a confirmation window and cannot be updated. <install forcedupgradeversion="[minimumversioninclusie,maximumversioninclusie] (minimumversionexclusie, maximumversionexclusie)" responsefile="filename"> You can specify the alue for installedversion and forcedupgradeversion as an inclusie, exclusie, or mixed range: To specify a range of product ersions that includes the minimum and maximum ersions, use square brackets. For example, Chapter 4. Distribution of updates by using push-to-client 11

installedversion="[3.0.1, 3.0.2]" prompts an installation update for product ersions 3.0.1, 3.0.2, and all ersions between this range. To specify a range of product ersions that excludes the minimum and maximum ersions, use parentheses. For example, installedversion="(3.0.1, 3.0.2)" prompts an installation update for product ersions greater than 3.0.1 but less than 3.0.2. You can mix brackets and parentheses to specify a range that includes one end of the range but excludes the other: For example, installedversion="(3.0.1, 3.0.2]" prompts an installation update for product ersions greater than 3.0.1 but less than or equal to 3.0.2. For example, installedversion="[3.0.1, 3.0.2)" prompts an installation update for product ersions greater than or equal to 3.0.1 but less than 3.0.2. For either of these attributes, the ersion numbers must include at least the major ersion number. It can include minor ersion, micro ersion, and qualifier: major[.minor[.micro[.qualifier]]] The following examples show alid ersion numbers for the installedversion and forcedupgradeversion attributes: 3 3.0 3.0.0 3.0.0.201510140202 4. Place the installation configuration file and the response file on the z/os serer and point to that location in the key mapping file. Example The installation configuration file is a UTF-8 encoded XML file. It contains one or more sets of <installedoffering> tags that define a target product offering ID and one or more pairs of installed ersion ranges and response file names. The push-to-client feature processes the following sample installation configuration file as follows: Scans the file until it finds a product offering ID that matches the ID of any product that is installed in the same package group as the currently running IBM Explorer for z/os ersion. For example, if a client is running the IBM Explorer for z/os product in the same package group as the Rational Team Concert product, then the matching offering ID can be either com.ibm.team.install.rtc.client.eclipse or com.ibm.zos.explorer.30 If the current product ersion of the matching offering ID falls within the range that is proided in any of the pairs of <installedversion> and <responsefile> attributes, Installation Manager starts by using the response file. If the Rational Team Concert ersion, for example, is greater than or equal to 3.0.0 and less than 3.0.1, Installation Manager starts by using the response file update_rtc_from_600_to_601.xml. <?xml ersion="1.0" encoding="utf-8"?> <installconfig> <installedoffering id="com.ibm.zos.explorer.31"> <install installedversion="[3.0.1, 3.0.2)" responsefile="update_zxpl_from_301_to_302.xml"> </install> <install installedversion="[3.1.0, 3.1.1)" 12 IBM Explorer for z/os: Client Configuration Guide

responsefile="update_zxpl_from_310_to_311.xml"> </install> </installedoffering> <installedoffering id="com.ibm.team.install.rtc.client.eclipse"> <install installedversion="[6.0.0, 6.0.1)" responsefile="update_rtc_from_600_to_601.xml"> </install> </installedoffering> </installconfig> Updating the key mapping file You can update the key mapping file by using the export wizard or by editing it manually. About this task For instructions for using the export wizard, see Exporting push-to-client configuration files on page 27. Procedure To update the key mapping file by editing it manually, do these steps: 1. The Export operation creates a default keymapping.xml file and uploads it to the location indicated by the pushtoclient.folder property of the pushtoclient.properties file. The default keymapping.xml file includes entries for the product update. You can add entries for the product update to this file. The key mapping file is a UTF-8 encoded XML file. 2. Include one set of <location> tags for each installation configuration file and each response file you want to point to. 3. Specify the following alues for the tags: <fileid> Specify com.ibm.ftt.resources.zos.install.configuration for the installation configuration file and com.ibm.ftt.resources.zos.install.response for the response file. <containerpath> Specify the location of the installation configuration file or response file on the z/os serer. <filemask> Specify the name of the installation configuration file or response file. <encoding> Specify the encoding of the installation configuration file or response file. 4. Sae the key mapping file to the location indicated by the pushtoclient.folder property of the pushtoclient.properties file. Example The key mapping file is a UTF-8 encoded XML file that stores the names, locations, and character encodings of configuration files that are used in a IBM Explorer for z/os push-to-client configuration enironment. In the following sample key mapping file, the administrator placed installconfig.xml in the /ar/zexpl/pushtoclient/install directory and the response files in the /ar/zexpl/pushtoclient/install/responsefiles directory of the z/os serer. Chapter 4. Distribution of updates by using push-to-client 13

<?xml ersion="1.0" encoding="utf-8"?> <configuration-system> <location-list> <location> <fileid>com.ibm.ftt.resources.zos.install.configuration</fileid> <containerpath>/ar/zexpl/pushtoclient/install</containerpath> <filemask>installconfig.xml</filemask> <encoding>utf-8</encoding> </location> <location> <fileid>com.ibm.ftt.resources.zos.install.response</fileid> <containerpath>/ar/zexpl/pushtoclient/install/responsefiles</containerpath> <filemask>update_*.xml</filemask> <encoding>utf-8</encoding> </location> </location-list> </configuration-system> Properties in pushtoclient.properties that affect product updates Seeral properties that are specified in the pushtoclient.properties file work together to determine how product updates are deliered by the push-to-client feature. product.enabled Indicates whether push-to-client is used to delier product updates. Valid alues are TRUE, FALSE, SAF, and LDAP: TRUE - product updates are enabled for all users. FALSE - product updates are disabled. SAF - product updates are enabled based on permission to security profiles. LDAP - product updates are enabled based on membership in LDAP groups. For information about setting up LDAP access groups and SAF-based access groups, see these topics: Push-to-client deeloper groups in the Host Configuration Reference Guide (SC27-8438) Push-to-client considerations in the Host Configuration Reference Guide (SC27-8438) reject.product.updates Indicates whether clients are allowed to reject product updates that are deliered by the push-to-client feature. The default is FALSE. accept.product.license Indicates whether the product license is automatically accepted during updates that are initiated by push-to-client. If this property is set to FALSE, push-to-client does not attempt to distribute any product updates. If it is true, push-to-client attempts to delier product updates and adds the -acceptlicense argument to the Installation Manager inocation. The default is FALSE. How reject.product.updates affects installedversion and forcedupgradeversion The behaior that is triggered by the installedversion and forcedupgradeversion attributes is affected by the reject.product.updates parameter of the pushtoclient.properties file. 14 IBM Explorer for z/os: Client Configuration Guide

Relationship between installedversion and reject.product.updates The following table shows the relationship between the installedversion attribute of the installation configuration file and the reject.product.updates parameter of the pushtoclient.properties file. Table 1. Relationship between installedversion and reject.product.updates If the client ersion is out of range of installedversion If the client ersion is in range of installedversion reject.product.updates=false The client is not prompted and cannot install the product update. The client is prompted but cannot reject the updates. reject.product.updates=true The client is not prompted and cannot install the product update. The client is prompted and can reject the updates. Relationship between forcedupgradeversion and reject.product.updates The following table shows the relationship between the forcedupgradeversion attribute of the installation configuration file and the reject.product.updates parameter of the pushtoclient.properties file. Table 2. Relationship between forcedupgradeversion and reject.product.updates If the client is out of range of forcedupgradeversion If the client is in range of forcedupgradeversion reject.product.updates=false The client is not prompted and not updated to the specified ersion. The client is prompted and cannot reject the updates. reject.product.updates=true The client is not prompted and not updated to the specified ersion. The client is prompted and cannot reject the updates. Related tasks: Distributing product updates on page 9 The IBM Explorer for z/os push-to-client feature proides tools for system administrators to create product installation updates and prompt client workstations to install the updates when they connect to a remote system. Creating and distributing configuration files The push-to-client feature proides 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 indiidual client workstations automatically when they connect to a remote system. Product updates can also be pushed to client workstations when they connect to a remote system. Before you begin To create and distribute remote connection definitions, configuration files, and preferences from a central location, the serer must be configured to enable push-to-client updates. For information about configuring push-to-client updates, see (Optional) pushtoclient.properties, the host-based client control. Chapter 4. Distribution of updates by using push-to-client 15

About this task When a user connects to the primary remote system or to another remote system for which system configuration files are defined, the configuration files that are stored on that system are compared to the configuration files on the workstation. If updates are aailable, users are prompted to install them. By using the push-to-client feature, you can distribute the following configuration files: Global configuration files 5 : Eclipse preferences Remote system connections Installation configuration System configuration files 6 z/os file system mappings Procedure To create and distribute configuration files, do these steps. Each of these steps links to more information about completing the step. 1. Create a workspace that seres as the master workspace for the configurations and preferences to be distributed. 2. From the master workspace, create connections to the primary remote system from which you intend to distribute global and system configurations and to each remote system from which you intend to distribute system configurations. 3. Configure remote system connections, configuration files, and preferences in the master workspace. 4. Export the configuration files that are to be distributed to other client workspaces. Related concepts: Chapter 4, Distribution of updates by using push-to-client, on page 7 You can configure IBM Explorer for z/os to automatically distribute product updates and updates to configuration files, preference settings, and remote system connections when client workstations connect to a remote system. This feature is called push-to-client. By using it, you can store workspace configurations in a central location and push them to client workstations so that your deelopers hae a consistent workspace enironment. Creating a master workspace for push-to-client configuration A master workspace is a IBM Explorer for z/os workspace from which you create the remote system connections, configuration files, and preference settings to be distributed to other client workstations. 5. For IDz users, global configuration files also include the settings of Database connections, Software Analyzer Configurations, Menu Manager files, and Snippets. For more information about theses settings, search for Defining connections, configuration files, and preferences for push-to-client configuration in IDz KC. 6. For IDz users, system configuration files also include the settings of Property groups, Host-based projects, Remote index locations and Default alues. For more information about these settings, search for Defining connections, configuration files, and preferences for push-to-client configuration in IDz KC. 16 IBM Explorer for z/os: Client Configuration Guide

About this task Creating a master workspace for push-to-client configurations is no different from creating any other IBM Explorer for z/os workspace. It is good practice to dedicate a workspace to configuration so that other deelopment actiities do not alter the remote system connections, configuration files, and preference settings that are intended for general distribution. The purpose of using a master workspace is for the workspace owner (or push-to-client administrator) to set up preferences, system connections, and configurations the way ordinary users must hae them in their workspaces. Set up the workspace by using the product user interface and then export those settings by using the IBM Explorer for z/os configuration export wizard. If group-leel control of product and configuration updates is enabled for the push-to-client serers, then the master workspace is bound to a particular group when you export configurations to the serer. 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 serers. Procedure For information about creating a workspace, see Switching workspaces. For information about group-leel control of configurations, see these topics: Push-to-client deeloper groups Push-to-client considerations Defining connections, configuration files, and preferences for push-to-client configuration To set up connections, configuration files, and preferences for distribution in a push-to-client enironment, define global and system configuration files. Global configuration files Global configuration files are managed on the primary remote system. The primary remote system is a z/os system that is defined during host installation and configuration as the controlling system for push-to-client configuration. Chapter 4. Distribution of updates by using push-to-client 17

Table 3. Global configuration files. The global configuration files include these settings. File Type Description More Information Eclipse Preferences Remote System Connections Installation Configuration Files These configuration files are exported from the settings in the Window > Preferences user interface of a workspace that is connected to the primary remote system. The push-to-client feature uses the base Eclipse export mechanism for preferences, which saes only changes to default alues. Eclipse also exports different preferences to arious discrete.pref files. The result is that the push-to-client feature exports and distributes only those Eclipse preference files that contain nondefault alues. These configuration files are exported from the Remote Systems iew of a workspace that is connected to the primary remote system. They include all remote system connections that are defined in this iew. These configuration files are created manually. The define product updates to be installed on a client workstation when it connects to a remote system. Eclipse Preferences z/os Preferences Creating a connection to a z/os system on page 19 Distributing product updates on page 9 System configuration files System configuration files are managed on the primary remote system and on other remote systems to which users can connect. 18 IBM Explorer for z/os: Client Configuration Guide

Table 4. System configuration files. The system configuration files include the following setting. File Type Description More Information z/os File System Mapping Configuration Files These configuration files are exported from the z/os File System Mapping iew of a workspace that is connected to the primary remote system. They include all z/os file system mappings that are defined for each remote system that is defined in the Remote Systems iew. The push-to-client feature can export the following types of z/os file system mapping configuration files: MVS Files - System Mapping files are defined for a remote system. MVS Files - Resource Mapping files are defined for specific data sets on a remote system. Mapping data sets and partitioned data set members on page 23 Creating a connection to a z/os system Before you can connect to a remote system from the IBM Explorer for z/os client, you must define a connection for it and specify connection properties. About this task Restriction: Define only one connection to a particular remote system in each workspace. If you define multiple connections to a single remote system, and your site uses the push-to-client function to distribute updates to remote system connections, then all connections to the remote system are updated. The IBM Explorer for z/os product does not support different configurations of the same remote system in a single workspace. Procedure 1. In the Remote Systems iew, expand New Connection and double-click z/os. 2. In the New Connection window, select a profile name from the list. Tip: If you are creating a connection for the first time, you are prompted to create a profile before you can create the new connection. After you create the connection, you can share this profile to allow other users to hae this connection in their Remote Systems iew. 3. Enter the following alues in the fields on this window. Host name The TCP/IP address of the remote system. Connection name The short name to call the system. For example, MYSYSTEM. Description A description of the connection. Chapter 4. Distribution of updates by using push-to-client 19

Verify host name Select this check box to erify that the host name is alid before you connect. 4. To define the connection with default alues for the MVS Files, z/os UNIX Files, and z/os UNIX Shells subsystems, click Finish. To set properties for these subsystems, click Next. The wizard opens a properties window for each subsystem. These pages display the properties of the underlying serices that are used by each subsystem. For more information about the properties you can set for a subsystem, see the related topics. Results The Remote Systems iew displays the short name of the new connection with fie nodes under the connection name: z/os UNIX Files is the z/os UNIX file subsystem. This node contains two folders: My home and Root. You can create more z/os UNIX file folders by adding new filters to this node. z/os UNIX Shells is a command subsystem. When you open a z/os UNIX command shell, its name is displayed under this node. MVS Files is the MVS file subsystem. This node contains three folders: My Data Sets displays MVS files that match the filter userid.* in which userid is the user ID with which you connected to the remote system. You can create more MVS file folders by adding filters to this node. You can change the sort order of data sets by using the MVS Files preference page. Retrieed Data Sets displays data set names searched for and added by using the Retriee Data Sets action or by allocating a data set. My Search Queries displays search queries that you ran and saed in the Remote z/os Search iew. TSO Commands is a command subsystem. When you open a TSO command shell, its name is displayed under this node. JES is the JES subsystem. This node contains two folders: My Jobs displays jobs that are submitted under the user ID with which you connected to the remote system. You can create more job folders by adding new filters to this node. Retrieed Jobs displays jobs searched for and added by using the Retriee Job action. What to do next Connecting to a remote system. After you connect to the remote system, you can control the contents that are displayed under JES, MVS Files, and z/os UNIX Files by defining filters for these subsystems. You can add search queries to the MVS Files folder by running and saing remote z/os searches. For instructions, see the related topics. Related information: Quick task: Creating a connection to a remote system Remote-to-local file mapping When you define a remote system, you map (associate) the lowest leel qualifier in each MVS data set name to a file name extension for the related workstation file. 20 IBM Explorer for z/os: Client Configuration Guide

IBM Explorer for z/os includes a set of defined remote-to-local file mappings. The **COBOL file mapping, for example, maps MVS files with a low-leel qualifier COBOL to workstation files with the.cbl file name extension. 7 Mapping A mapping indicates how IBM Explorer for z/os processes file transfers between z/os and the workstation; specifically, the mapping indicates whether file transfers are based on an exchange of text (in which case ASCII/EBCDIC conersions occur) or on an exchange of binary data. A mapping also helps you to know, at a glance, the general purpose of a particular file. If you use the same low-leel qualifier for seeral data sets, the same mappings affect file transfers for each of those data sets. Gien the mappings that are included in IBM Explorer for z/os, for example, you can transfer members of the partitioned data sets USER01.COBOL and USER01.TEST.COBOL to and from workstation-based files that hae the extension.cbl. 8 You can see remote-to-local file mappings in the z/os File System Mapping iew of the RSE perspectie perspectie. The following screen capture shows this iew. You can customize these mappings to match the naming conentions on your remote system either through the z/os File System Mapping iew or on the Mapping page of the Properties window. For more information about customizing these mappings, see Mapping data sets and partitioned data set members on page 23. For more information about the properties of file mappings, see the remaining sections of this topic. 7. For IDz users, you can define an alternatie logical NOT symbol in a file mapping definition. For more information, search for Specifying an alternatie logical NOT symbol in IDz KC. 8. In the workbench, a preference that is related to the z Systems LPEX Editor causes workstation-based files of a particular type to be treated in a particular way. In accordance with this preference, for example, a file of type.cbl is presented with the syntax highlighting that is appropriate to a COBOL source file. Howeer, when the editor processes a z/os-based data set, the mapping of a qualifier (like COBOL) to a file name extension (like.cbl) determines how the data set is processed. Chapter 4. Distribution of updates by using push-to-client 21

Workstation file extension The type of a file is indicated by its workstation file extension. In the mappings that are shown in the screen capture, a.cbl extension, for example, is considered to be a COBOL source file. Each file can hae only one file type. JCL with embedded COBOL source, for example, is not supported. The default workstation file extension for a new mapping is undefined. Transfer mode The transfer mode can be either text, indicating that a conersion between ASCII and EBCDIC occurs, or binary. The default transfer mode for a new mapping is text. Code page Each file can hae only one code page, but you can specify a group of files as haing the same code page. When you specify code pages, specify both a local and 22 IBM Explorer for z/os: Client Configuration Guide

a host code page and keep them consistent. The default host and local code pages for a new mapping are inherited from the system properties of the remote and local file systems. For a list of supported host code pages, see Supported host code pages on page 27. The aailability of local code pages is based on the text file encodings that are supported by the Eclipse text editor. Be sure to specify code pages to be consistent with the compiler settings of your files. Priority If a file matches more than one file mapping, the mapping with the highest priority is the one that applies. In the following example, a file named MYUSERID.SOURCE.COBOL matches both of these file mapping definitions. Because the **COBOL mapping has the higher priority, its properties are applied during a file transfer between the remote and local systems. It is transferred to the workstation with these file transfer properties:.cbl file extension, text transfer mode, inherited workstation code page. Mapping Criterion Workstation File Extension Transfer Mode Host Code Page **COBOL.cbl default (text) default (inherited) **COBOL* default (undefined) binary default (inherited) Local Code Page default (inherited) default (inherited) Priority 1 2 Related concepts: File encoding, code page conersion, and inheritance on page 25 When you copy a file between a remote system and the workstation, the file is conerted to a code page appropriate to its destination. File code pages are inherited from the system or folder that contains them. Related tasks: Mapping data sets and partitioned data set members A data set mapping associates the lowest leel qualifier in each MVS data set to a file name extension that is used for the related workstation-based file. One mapping, for example, associates the z/os-based qualifier COBOL with the workstation-based file extension.cbl. Mapping data sets and partitioned data set members: A data set mapping associates the lowest leel qualifier in each MVS data set to a file name extension that is used for the related workstation-based file. One mapping, for example, associates the z/os-based qualifier COBOL with the workstation-based file extension.cbl. About this task The IBM Explorer for z/os product proides a set of default mappings, but you can create more mappings. Procedure To add a data set mapping: Chapter 4. Distribution of updates by using push-to-client 23