Push to Client. RDz IDz ADFz Virtual User Group. Kelly McGraw

Transcription

1 RDz IDz ADFz Virtual User Group Push to Client Kelly McGraw October 18 th 20 th Online Web Conference Contact for additional information

2 Push to Client Personal Disclaimer This is not intended to be a deep dive and complete end to end coverage of the push to client feature. The intention is to keep it basic to give you a platform to start from and a general understanding of the process. General Advice The best advice and practice is to start small and build complexity into it, this advice comes from my support background and mindset. If things do not go as expected then we won t have to debug the world when you call us, this will save you time and frustration. Starting Point Considerations Ensure you have all the documentation in front of you or pointers to it: z/os Explorer Information Center: z/os Explorer Host Configuration Guide and Host Reference Guide: 01.ibm.com/support/docview.wss?uid=swg IDz Information Center Push to Client Documentation: 1

3 Push to Client What is push to client, should I bother? All the cool kids are doing it... Seriously though, this completely makes sense, especially for a large shop. Once your users connect they can then be pushed z/os connections, property groups, file mappings, database connections and more! You can basically push files and configurations they need to get going immediately saving startup time for your developers. Official statement: You can configure Developer for z Systems 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 developers have a consistent workspace environment. 2

4 Push to Client What you can distribute, push to clients Global configuration files: Database connections Eclipse preferences Remote system connections Menu Manager files Software Analyzer Configurations Snippets Installation configuration System configuration files: Remote index locations z/os file system mappings Property groups Default values Host-based projects My favorites File mappings and property groups because providing these common items will save repetitive work with commonly overlooked mistakes. 3

5 Push to Client Getting Started Getting Started - Implementing a push-to-client environment involves several tasks: some on the z/os system and some on a client workstation High level checklist / steps 1. Configure push-to-client on z/os, determine what you want to push and then configure the host accordingly. 2. Configure a master workspace with settings that you want to push out to other workspaces when they connect to the z/os system. 3. Export the workspace settings to the z/os system by using the Developer for z Systems configuration export wizard. 4. What the client sees after logging on to the primary system. 4

6 Push to Client Host Considerations Clarifying what owns who and where it s located huh? Although this is not new information it s good to repeat. The push to client host code is now with z/os Explorer, IDz only extends the z/os Explorer push to client, or hostbased client control, with support for project definitions. Supporting host documentation is mostly in the z/os Explorer host documents, refer to the z/os Explorer Host Reference Guide for information about preparing your system for push to client, chapter ibm.com/support/docview.wss?uid=swg

7 Push to Client Host Considerations Host setup and changes 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. Other z/os systems can be enabled for push-to-client as non-primary systems. Nonprimary systems define only system configurations, which apply only to the nonprimary system itself. System configurations are property groups, default values, file mappings, remote index search, and host-based projects. I recommend keeping it simple at first and keep things on one system, but you can use a secondary system. My support DNA comes out here, if you have never done this before then I highly recommend starting with one system first before adding additional layers to debug incase it goes unexpectantly. 6

8 Push to Client Host Considerations Host setup and changes 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 if you took the defaults. This file contains entries that specify configuration parameters, such as: >> /etc/zexpl 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 Where to find the main configuration file, keymapping.xml: indicated by setting pushtoclient.folder=/var/rdz/pushtoclient, 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. 7

9 Push to Client Host Considerations Host setup and changes continued Multiple developer groups, group-level control When enabling configuration or version control support for multiple developer groups, one additional team will be involved in managing push-to-client. Which team this is depends on the option chosen to identify the groups a developer belongs to. An LDAP administrator maintains group definitions that place each developer in none, one, or more FEL.PTC.* LDAP groups. A security administrator maintains access lists to FEL.PTC.* security profiles. A developer can be authorized to none, one, or more profiles. Support for multiple developer groups, each with their own client configuration and client update requirements, is enabled by assigning the desired value to the related directives (config.enabled and product.enabled) in pushtoclient.properties 8

10 Push to Client Product Updates product.enabled=true allows for product updates Note, we don't support update of versions like 9.1 to 9.5 or 9.5 to 14 but I think it is possible if you really wanted to. However if you get stuck we will just tell you to try it in a supported way. For product updates you need the following files: Response file Keymapping file Installation configuration file which defines the product offering IDs, a range of Developer for z Systems versions, and the name of the response file that installs the product update 9

11 Push to Client Product Updates Steps for product updates 1. Create your response file to do what you want it to; i.e. update or modify. 2. Create or update your installation configuration file to indicate the range of product versions 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: s/t_upd_inst_cfg_file.html 3. Ensure your keymappings.xml file is updated with the right pointers to your response file and installconfig files. You can update the keymappings.xml file manually. 10

12 Push to Client Master Workspace A client administrator is needed to create a master workspace with settings that you want to push out to other workspaces when they connect to the z/os system. Creating a master workspace for push to client configurations is no different from creating any other Developer for z Systems workspace. Tip: The master workspace should only be used for push to client setup and maintenance. Note: 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. See the following URL to see what can be included for distribution: oc/topics/tzdplanptc.html Database Connection Configuration File, Eclipse Preferences, Remote System Connections, Menu Manager Files, Software Analyzer Configurations, Snippets Configuration File, Installation Configuration Files, Remote Index Locations, z/os File System Mapping Configuration Files, Property Groups, Host-based Project Configuration Files 11

13 Push to Client - Exporting Exporting your global and system configuration files After you set up your workspace you can export your global and system configuration files using the export wizard. Only users who have authority to write files to the folder that contains the key mapping file on the remote system can export settings. 1. From the master workspace, connect to the primary system. Connect to the remote system to which you want to export configuration files. Connect only to one primary system during this process. 2. From the workspace menu bar, click File > Export. The Export window opens. 12

14 Push to Client - Exporting 4. In the Export window, click + to expand IBM z/os Explorer and select Configuration Files. *Note doc says 'expand Developer for z Systems' which is wrong. Error message with v14 if you are connected to multiple primary systems 13

15 Push to Client - Exporting Select the global configuration files to export 14

16 Push to Client - Exporting Select the system configuration files to export 15

17 Push to Client Accepting push to client files Connecting to the primary system for the first time will bind the workspace Note: 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. In this scenario there is just the one group 16

18 Push to Client Accepting push to client files Message that lets you know that you are binding your workspace 17

19 Push to Client Accepting push to client files Accepting the configuration files 18

20 Push to Client Accepting push to client files Final message to indicate completion of pushed files 19

21 Push to Client Accepting Product Update 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 version with a range of versions that are defined in the installation configuration file. If the installed version is in this range, the Developer for z Systems workbench shuts down and starts the IBM Installation Manager product by using a response file that is downloaded from the remote system. 20

22 Push to Client Other Hints A USER can reset their workspace by clearing case in preferences>remote Systems > Configuration Files> clear cache files Another reference written by my colleague: SAF-based group selection: opics/ptc_safgrpsel.html#ptc_safgrpsel z/os Explorer Host Configuration Guide (Optional) Other Customization Tasks P2C: cs/hostbasedpropgroup.html 21

23 Questions? Thank you very much for your time. Enjoy the conference 22

24 Notices and Disclaimers Copyright 2016 by International Business Machines Corporation (IBM). No part of this document may be reproduced or transmitted in any form without written permission from IBM. U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM. Information in these presentations (including information relating to products that have not yet been announced by IBM) has been reviewed for accuracy as of the date of initial publication and could include unintentional technical or typographical errors. IBM shall have no responsibility to update this information. THIS DOCUMENT IS DISTRIBUTED "AS IS" WITHOUT ANY WARRANTY, EITHER EXPRESS OR IMPLIED. IN NO EVENT SHALL IBM BE LIABLE FOR ANY DAMAGE ARISING FROM THE USE OF THIS INFORMATION, INCLUDING BUT NOT LIMITED TO, LOSS OF DATA, BUSINESS INTERRUPTION, LOSS OF PROFIT OR LOSS OF OPPORTUNITY. IBM products and services are warranted according to the terms and conditions of the agreements under which they are provided. Any statements regarding IBM's future direction, intent or product plans are subject to change or withdrawal without notice. Performance data contained herein was generally obtained in a controlled, isolated environments. Customer examples are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual performance, cost, savings or other results in other operating environments may vary. References in this document to IBM products, programs, or services does not imply that IBM intends to make such products, programs or services available in all countries in which IBM operates or does business. Workshops, sessions and associated materials may have been prepared by independent session speakers, and do not necessarily reflect the views of IBM. All materials and discussions are provided for informational purposes only, and are neither intended to, nor shall constitute legal or other guidance or advice to any individual participant or their specific situation. It is the customer s responsibility to insure its own compliance with legal requirements and to obtain advice of competent legal counsel as to the identification and interpretation of any relevant laws and regulatory requirements that may affect the customer s business and any actions the customer may need to take to comply with such laws. IBM does not provide legal advice or represent or warrant that its services or products will ensure that the customer is in compliance with any law 23