1. The document discusses provisioning, deploying, and managing IBM's Rational Development and Test Environment (RD&T) for System z in cloud environments.
2. Key steps include configuring Linux systems to run the zPDT emulator, installing z/OS software like the Application Distribution Controlled Distribution, and managing licensed access through USB tokens or a license server.
3. Using a pre-built ADCD distribution provides a complete turnkey z/OS development and test system, while customized z/OS installations can also be deployed through RD&T.
SOCRadar Research Team: Latest Activities of IntelBroker
Flexible DevOps Deployment of Enterprise Test Environments in the Cloud
1. DEZ-1838: Flexible DevOps Deployment of
Enterprise Test Environments in the Cloud
John Gates
RD&T Chief Architect
2. Please Note:
1
• IBM’s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM’s sole
discretion.
• Information regarding potential future products is intended to outline our general product direction and it should not be relied on in
making a purchasing decision.
• The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any
material, code or functionality. Information about potential future products may not be incorporated into any contract.
• The development, release, and timing of any future features or functionality described for our products remains at our sole discretion.
• Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual
throughput or performance that any user will experience will vary depending upon many factors, including considerations such as the
amount of multiprogramming in the user’s job stream, the I/O configuration, the storage configuration, and the workload processed.
Therefore, no assurance can be given that an individual user will achieve results similar to those stated here.
5. RD&T adds mainframe development & test capacity in a cost
effective, flexible way
• Develop and test z/OS applications
anywhere, anytime
• Free up mainframe developmentMIPS
for productionworkload
• Eliminate costly delays by reducing burden
on existing IT operations staff
• With RD&T 9.1, exploit z/OS 2.1, CICS 5.2,
IMS 13, COBOL5.1, plus use Rational
Integration Tester z/OS components to
minimize subsystem dependencies during
testing
• RD&T as part of Cloud Managed DevOps:
Reduce time to value and minimize ongoing
administration and capital expense with
cloud deployment
What’s
New
Affordable off host development
and test environment
IMS DB2
CICS
WAS MQ
z/OS
COBOL, PL/I, C++, Java,
EGL, Batch, Assembler,
X86 PC or HX5 Blade
running Linux
IBM SoftLayer Infrastructure
RD&T
RTC RDz RIT
Rational Development
and Test Environment
for System z (RD&T)
6. Characteristics of RD&T
• Highly capable – supports most of the z13 System z hardware instruction set
– Some exceptions in the areas of z/OS IO and supportfor some of the z13 add on co-processors
• Exceptionally stable – developed and tested as traditional z13 hardware = near 0 defects
• Performs well in controlled environments
• Architecturally limited to support for 8 CP cores, however….
– Optimized for 3-4 CPs
– Exploits additional linux CP cores forIO subsystem,IO devices,some co-processors
– Note CP cores >3 are only licensed foruse with RD&T Parallel Sysplex Version
• Designed for use by a small number of users, since it provides a fraction of the compute
power of a fully configured z13
• Works best with homogeneous workloads
• CPU intensive workloads like Java are less predictable
• Programs implemented with traditional mainframe languages like COBOL, PL/I, and ASM
perform very well
7. Current state of Provision, Deploy, Manage for RD&T
• Provision, Deployment, and Management of RDT resources is mostly a manual exercise.
• Most of what we do today is a series of steps that are:
– Repeatable
– Refined
– Wellunderstood,at least forthe mainline paths
• Some of this could be automated.
• Some of this cannot be automated, (at least by today’s standards.)
• Much of RDT Provision, Deploy, and Manage is not “Rocket Science”, but it does require a
fair amount of rigor to be successful.
• While there are common components to every RDT deployment, there are also unique
customer requirements that must be satisfied. These require a variety of skills to address.
These skills are not generally available to application programmers.
• Additional deploy environments such as Cloud, bring additional challenges.
8. Common tasks - where to go for help?
• Many products – IBM and vendor - L1, L2 Support
• Complex subsystem interactions - CICS, IMS, DB2, WebSphere, MQ, etc… - Doc, Web,
System Programmers, DBAs
• Multiple compile/ run environments – C/C++, COBOL, PL1, ASM – Doc, Web, System
Programmers
• Multiple tools – RDz, FA, FM, APA, CICS Explorer - Doc, Web, System Programmers
• Complex network requirements – Network Administrators
• Complex security requirements – Security Administrators
• Complex regulatory requirements – Business Controls
• IO configuration – L1, L2 Support, hardware engineers
• Co-processor support - L1, L2 Support, hardware engineers
Bottom line – There is no one person that has all of this information.
The folks that do have the information may be reluctant to share. 7
9. How to make the Provision, Deploy, Manage process for
RD&T easier?
• The basic problem:
– We have very intelligent developers that can access a z/OS image(s) with no problems and love the idea
of their very own RD&T development and test solution
– Those developers really don’t know anything about how to setup a z/OS system for development and test
– The system programmers and operations know how to build a z/OS system, but…..
• Developers don’t have access to the system programmers
• Operations doesn’t want to support another “n” number of systems
• How then to create a z/OS system?
– We can build up from the ADCD
– We can build down from existing z/OS systems
– But…..
…..this still requires z/OS system knowledge
• How to make this system available across n systems and platforms?
• How to manage n deployed systemsand platforms?
– Are we really talking about n systems, or 1 system n times?
10. • Provision a
z/OS system
• ADCD -
build up
• Existing
system –
build down
• Make the
z/OS system
portable
The RD&T process
9
Provision Deploy Manage
• Deploythe
z/OS system
across 1 or
more RD&T
system
instances
• Configure
access to
the deployed
z/OS system
on each
RD&T
system
instance
• Manage the
deployed
RD&T
system
instance(s)
• Access
z/OS host
development
and test
resources
• Monitor
system
resources
• Configure a
base linux
image
• Install linux
(RHEL,
SLES)
• Add the
RD&T
System z
architecture
emulator
Configure
12. Linux
11
RD&T Product Structure
ZPDT (emulator)
z/OS
USB “token”
or server connection
TCP/IP
TCP/IP
Running z/OS within RD&T
Device Map defines zPDT system
DASD volumes are Linux files
TCP/IP can talk to Linux or to the
outside network
USB Token or server supplies
license to run zPDT
Optional connection to Rational
token server (FlexLM)
Dev Map
FlexLM Server
(Rational Tokens)
13. RD&T required components
• A base linux system
– RHEL or SLES at the required levels
• A 3270E emulator, (usually provided by the linux distribution)
• The 1091 USB hardware device
• A RD&T license file to be applied to the USB hardware device
• The RD&T installer
• z/OS software
– ADCD distribution (1.13, 2.1)
– User supplied and license compliant z/OS distribution
• License server (optional)
14. Optional - Using a license server
• RD&T License Server – Network-based, centralized license management system
– Easily IPL machines on hardware with limited/ restricted USB access (e.g., System x
Blades in a blade center)
– Eliminates the requirement for USB hardware device to be physically plugged into every
RD&T machine
– Eases management and provisioning of multiple RD&T instances
• USB Hardware Device
– Allows multiple RD&T instances licensed from a single USB hardware device
– Supports up to 33 RD&T servers (3 CPs each) per USB hardware device
RD&T
License Server
RD&T
(Dept server)
RD&T
(Blade server)
ISPF user
ISPF user
ISPF user
RDz user
RDz user
RDz user
RD&T
(Dept server)
ISPF user
RDz user
RDz user
RD&T
(Laptop) ISPF user
RD&T
License Server
RD&T
(Dept server)
RD&T
(Blade server)
ISPF user
ISPF user
ISPF user
RDz user
RDz user
RDz user
RD&T
(Dept server)
ISPF user
RDz user
RDz user
RD&T
(Laptop) ISPF user
15. RD&T v.9.1 hardware requirements – typical configuration
• Each RD&T Instance
– CPU
• Quad core 3rd
gen Intel i7 or equivalent running at 2.8 Ghz or better
– Memory:
• At least 16 GB RAM (32 GB is better)
– Disk devices:
• 60 GB base z/OS
• 100-200additional GB subsystems and data
• SSD, Flash, Hybrid, DAS (7200 RPM or better,) 10/15K SAS,NAS (Commercial,with speed and
striped,fast disks), SAN
– Networking:
• Ethernet – 1GB / 16 GB
– USB
• USB3 is best,USB2 works
– Display adapter
• In general, bigger, faster, more, is better. The more resources allocated, the better
RD&T will perform.
16. Configuration steps for each RD&T compliant machine
• Obtain Linux machine with capabilities as specified on previous chart.
• Install and configure compliant linux version.
• Configure linux network access
• Using RD&T Install Manager disk, install zPDT System z architecture emulator.
• Alter linux files
• Obtain hardware usb device
– Obtain license file
– Apply license file to hardware usb device
• Plug hardware usb device into RD&T compliant machine or license server
• Configure access to license server(s) if required
• Note the above steps are altered slightly if more than one RD&T instance
is deployed on a single RD&T compliant machine
18. Use a pre-build, pre-configured z/OS system
• Application Distribution Controlled Distribution (ADCD)
– z/OS 1.13,2.1 supplied with RD&T 9.1
– z/OS 2.1 Requires decryption
• Includes
– z/OS and all z/OS facilities
– Subsystems – CICS,IMS, DB2,IMS, WebSphere
– Compilers – C/ C++, PL1,ASM, COBOL,FORTRAN,Java
– Tools – RDz, RTC,Debug Tool,Fault Analyzer, File Manager, others.
• ADCD is a complete, turn key development and test system.
– Particularly useful for POC activities
– Quick setup
– Easy to use
19. Application Development Controlled Distribution (ADCD) for z/OS 2.1
• z/OS V2.1, including sub-features
– Encryption Facility
– IBM HTTP Server
– DITTO/ESA
– IBM z/OS ManagementFacility
• IBM PD Tools
– Tools Base for z/OS
– IBM Debug Tool 13.1
– IBM File Manager 13.1**
– IBM Fault Analyzer 13.1**
• CICS Tools
– InterdependencyAnalyzer for CICS for z/OS 5.1, 5.2**
– CICS DeploymentAssistant5.1,5.2
• Rational Developer for System z 9.1
– Code Coverage
– Integrated Debugger
• Rational Team Concert5.0
– Build Agent
– ISPF Client
• Compilers
– IBM Compiler for REXX 1.4
– IBM Enterprise PL/I4.4
• Compilers
- IBM COBOL 5.1
- IBM Rational COBOL Runtime 6.0.1 (EGL)
- XL C++ 2.1
- XML Toolkit for z/OS 1.1
- IBM Java SDK for z/OS 6.0, 6.0.1, 7.0, 7.1
- VS FORTRAN 2.6
• Tivoli
- Tivoli System Automation for z/OS 3.5
- Tivoli NetView 6.1
- Tivoli Workload Scheduler for z/OS 9.2
• Subsystem Support
- WebSphere Application Server for z/OS
- WAS 8.0, 8.5
- Liberty Profile
- DB2 for z/OS
- DB2 for z/OS 10, 11
- DB2 Utility Suite for z/OS
- DB2 Administration Tool for z/OS
- DB2 Object Comparison Tool for z/OS
- DB2 for z/OS QMF
- IMS
- IMS 11, 12, 13
- IMS Utilities 12
- IMS Database Control Suite for z/OS 12
- CICS Transaction Server
- CICS 4.2, 5.1, 5.2
- CICS/VSAM Recovery 5.1, 5.2
- CICS Transaction Gateway 9.0
- WebSphere MQ for z/OS 7.1
20. Use your own z/OS system
• RD&T system is a “real” z/OS system
– IODF
– Ipl volumes
– SYSRES
– System datasets - Sys1.iplparm,Parmlib, Proclib,etc
• If you choose to move an existing system to RD&T, you must:
– Move a properlyconfigured system
– Ensure you move it all
– Make sure your catalog is intact
– Make sure your devices and device numbers are compatible
– Make sure your system will “fit”
• Consider this approach if your test environment has unique requirements
– Large amounts of data
– Complexconfigurationand setup
– Multiple subsystem interactions
21. Add content to your properly configured system
• Create work volumes
– Required for all implementations
• Add content using the DASD migration facility
– Provides a complete, volume copy of an existing CKD device.
– Useful when full volumes are required.
• Add content usingADRDSSU Dump – Restore
– Fast, well understood method for copying selected z/OS datasets and
content.
• Add content using FTP/ SFTP/ SMB
– Ubiquitous file mover technologies implemented on most every platform.
• Make sure to update your Device Map
22. Create new z/OS work volumes using ALCCKD
• Allocate the volume using the zPDT utility:
$ alcckd /z/USER01 -d3390-1
• Update the devmap to include the new volume. (Assume address AA0 for this example.)
[manager]
name awsckd 0001
device AA0 3390 3990 /z/WORK01
• Restart zPDT with the updated devmap.
• IPL z/OS with the new volume present. z/OS will detect an uninitialized volume and vary it offline.
• Create and run an ICKDSF job to initialize the volume:
//INITVOL JOB 1,IBMUSER,MSGCLASS=X
// EXEC PGM=ICKDSF,REGION=1M
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
INIT UNIT(AA0) NOVERIFY VOLID(WORK01) VTOC(0,1,14)
/*
• Vary the new volume online and begin using it:
VARY AA0,ONLINE (on the z/OS console)
23. Create new volumes using the DASD migration utility
• z/OS Data migration utility
– Allows easy migration of 3380 and
3390 volumes to the RD&T system
– Consists of a client / server application
• Linux client program “hckd2ckd” loaded
on any supported Linux system
• z/OS server program “zosserv” loaded
on z/OS system and given authorization
to access full volumes
– Operation
• Once the z/OS server program is
installed and running, the Linux client
can perform full volume copies of any
3380 or 3390 volume the server can
access. Ensure the system is stable,
with z/OS not writing to the disk.
• After successful transfer, the output file
is a valid RD&T CKD volume ready for
use.
24. Selected Copies Using ADRDSSU Dump/
Restore
• Use the z/OS system utility, ADRDSSU
to migrate data from an existing system
to an RD&T system
– Allocate space for new volumes
– Create source dump
– Send dump to RD&T instance linux
machine
– Receive dump
25. Things to watch out for when moving “pieces” of a z/OS system
• It is possible to move a subset of data, but there are things to watch out
for
– Make sure to move all parts including all metadata.
• VSAM/ DB2 are hard to deal with because of this.
– Watch out for Catalog changes/ updates
– Security definitions may differ
– Additional SMS definitions may be required
– Atomic transactions may require additional data/ transactions be moved
– Watch out for hardcoded values and system dependencies
– There may be IODF changes required
– Vendor products
24
26. Device Map
• A linux text file
– Contains information that maps linux resources to z/OS resources
• System stanza – memory, processors, 3270 attachment
• Manager stanza: awsckd – 3380, 3390 DASD devices
• Manager stanza: aws3274 - local, channel-attached, non-SNA 3270 sessions
• Manager stanza: awsosa – network attachment through OSA-Express
• Many others
– Makes the “Connection” between linux and z/OS
• Must be updated each time a device is added / deleted from an RD&T
instance.
• Each RD&T instance has a unique, corresponding Device Map.
• Best practice is to store Device Map with volumes to be deployed to an
RD&T instance.
28. RD&T Runs anywhere
• On Native Hardware
– Linux RHEL or SLES
• On Virtualized Hardware
– On VMware, KVM, Xen, and zBX Model 003
• In your private cloud
• On our private cloud
– SoftLayer bare metal servers
29. License considerations for deploy
• Each RD&T instance must have access to a USB hardware device with a
properly configured license file applied.
– Can be accessed locally
– Can be accessed through license server(s)
• RD&T instance must provide constant access to USB hardware device
• Licenses are allocated to individual RD&T instances and may not be shared
• License server provides limited ability to restrict access, however…
– Should deploy firewall or VPN, especially in Cloud environments
• More than one license server is supported for failover.
– Duplicate USB hardware devices are required.
– Coordination of license files is required.
31. Network consideration for deploy
• Each RD&T instance must have access to linux and the host OS configured
• There are choices
– Flow linux and host OS IP packets over the same ip@
• Requires linux static routes and IPTABLES updates
• May not share ports
• Relies on statically configured tunnel address, identical for all RD&T instances
– Flow linux and host OS IP packets over different ip@
• Use DHCP for linux
• z/OS does not support DHCP
– Manually configure IP@ using linux utilities – listVtoc, pdsUtil
– Require ipl to change addresses using client scripts and OBEYFILE commands
• z/OS supports IPv6 link local addresses which require no additional
configuration
35. Virtualization Support
• Support for VMware, KVM, Xen, zBX Model 003
• RD&T instances may be virtualized, HOWEVER…..
• Resources may not be overcommitted
– Paging is the enemy
– Physical system must have at least as much processor and memory as defined for use
by the virtual machine
– Additional workloads running on the same VMware or zBX blade should be carefully
evaluated to ensure that neither RD&T nor the other work will be impacted.
– Over commitment of resources and running in untested environments can lead to errors
including poor performance, missed I/O interrupts, and excessive paging.
36. Virtualization Support – (cont.)
–zPDT emulator will not allow a devmap to be used that specifies
more processors than are available on the host machine.
• The emulator will allow you to specify all available processors. This will cause issues.
• This does not prevent you from defining multiple VMs on the same hardware that use
the same physical machine resources. DO NOT DO THIS!!! Remember, paging is the
enemy, as is over commitment of physical machine resources, especially cpu.
• Must be especially careful when using z/VM to host a parallel sysplex.
–Virtualized linux images cannot span physical hardware
• This is not a generalized “cloud” solution
37. RD&T In the Cloud
• Cloud considerations
– Most virtual environments have pre-defined and layered network infrastructure. This assumes
machines will use DHCP to acquire IP address at runtime.
• z/OS does not supportDHCP
• Considerbuilding a System z Image that will only use tunnel network with Linux.
• Use IPTABLEson Linux to route specificports to z/OS using tunnel network.
• Master console
– Cloud environments may or may not provide direct access to a Linux console.In case there is no
direct access to master console.
• Use another system on the cloud such as Windows machine to have master consoles projected
to it.
• Use VNC on Linux to IPL the system and then use master console recoveryevery time one
needs to access the master console.This may not work if there are serious issues with the
machine.
• For stable systems directthe master console to script base 3270.
38. Allocating RD&T licenses on Cloud
• License server
– Hardware based license requires a physical machine on an accessible network to serve license and
regular heartbeat.
• SoftLayer can provision bare metal servers that can be very reliable license servers for RD&T cloud
instances hosted on SoftLayer.
• License server may also be hosted on premises and connected via VPN to Softlayer
• Limit the machine authorized
to checkout licenses
• Use Linux IPTABLES rules.
• Use third party software to limit
access to authorized machines or
IP’s
• Use RD&T feature.
• Use cloud solutions such as private
network to limit access to license
server
RD&T Virtual
Environment
RD&T Virtual
Environment
RD&T Virtual
Environment
RD&T Virtual
Environment
RD&T Virtual
Environment
RD&T Virtual
Environment
RD&T Physical
License Server
Physical Machine
scalable
IPRulesto
filter
connections
Cloud
Licenses and
heartbeat
39. RD&T on SoftLayer
• Implementing RD&T on SoftLayerrequires following
considerations
– License server
• SoftLayer can provide bare metal servers and hardware USB
devices and licenses for them.
– RD&T instances
• RD&T instances can be provisioned in a bare metal server or
a server running VMWare ESX Server software.
• ESX servers can provide more flexibility, and images on this
server should translate to better ROI as compared to bare
metal.
– Security and integration with company infrastructure
• Deploy SoftLayer assets on a SoftLayer VLAN environment.
• Use Vyatta Internet Gateway appliance (available on
SoftLayer) to gateway the VLAN and integrate SoftLayer
deployed assets with company infrastructure.
– Use VPN and NAT to control access to SoftLayer assets.
– Seamless LAN type access can be configured to
SoftLayer deployed systems.
Internet
Vyatta Gateway
License
Server
Gateway
Company network
RD&T
RD&T RD&T
RD&TRD&T
ESX Server
VLAN
40. Distributing RD&T systems
• Volume Files
– May be compressed using PKZIP
– Versioning is a good idea
– May be stored in SCM
• Should include Device Map update with each volume update
• CKD devices as linux files consume the same amount of storage as “real”
CKD devices
– ie. a 3390-3 CKD “real” device consumes 2.83 GB of real storage. The same device creates a 2.83
GB linux file
• Large number of volumes potentially creates a large amount of data to
deploy on each RD&T instance
– RD&T supports up to 1024 devices
– 4 digit device numbers are supported
– If you have a large number of volumes, ensure you have network bandwidth to deploythem
39
42. Management actions
• Actions which may be scripted from linux
– Start the emulator
– Ipl z/OS
– Stop the emulator
• Actions which must be taken in z/OS
– Quiesce z/OS
43. Service and support for RD&T
• RD&T provisioned systems include SMPE
– All products shipped with ADCD include DLIBs
– PTFs may be applied
• When updating multiple RD&T instances
– Apply service on Master system
– Create new linux file for modifiedvolumes
– Versionmodified volumes and make available to RD&T instance owners
• Apply critical RD&T linux file volumes
– Quiesce system,replace affected file volumes
– Re-ipl system to pick up changes
• Apply non-critical RD&T linux file volumes
– Vary volume offline
– Update volume
– Vary volume online 42
44. Managing multiple RD&T instances
• Commands targeted against an RD&T instance must be issued on the
host linux instance
– This means the more RD&T instances you have, the more complex the
management problem becomes.
– What if there were a easier way…..
43
46. What about data sharing between RD&T instances?
• Parallel Sysplex
– Must run under zVM
– Coupling Facility support
– Restricted to single RD&T instance
– Available only with RD&T Parallel Sysplex Edition
• Basic Sysplex
– Emulated CTC support
– Emulated STP support
– GRS ring only
– Available with RD&T
• Linux group controller
• Third party replication
45
48. • Provision a
z/OS system
• Create one
system that
serves the
majority of
your users
• Don’t over-
complicate
things
• Compress for
deploy
The RD&T process- Recap
47
Provision Deploy Manage
• Deploy the
z/OS system
across 1 or
more RD&T
system
instances
• Make common
system image
available
• Ensure
minimal
custom
configuration
• Consider using
IPv6
• Manage the
deployed
RD&T system
instance(s)
• Mind system
resources,
especially
paging
• Use linux tools
and monitors
• Apply z/OS
service to
master system
only – service
updates to
others are via
linux files
• Configure a
standard set of
hardware
capabilities
• More, bigger,
faster is better
– configure as
much as you
can afford
• Use a license
server
Configure
49. RD&T documentation
• RD&T V.9.1 Documentation
• IBM Rational Developmentand Test Environment for System z USB Hardware Device Quick Start
Guide (GI11-9147-05)
• IBM Rational Developmentand Test Environment for System z Quick Start Guide (GI13-1802-03)
• IBM Rational Developmentand Test Environment for System z Installation and Sample Configuration
Guide (SC14-7281-05)
• IBM Rational Developmentand Test Environment for System z Activation Guide (SC27-6630-00)
• System z Personal Development Tool Redbook
• Basic instructions for installation/ configuration of Linux, zPDT, and starter z/OS system
• System z PersonalDevelopmentTool:Guide and Reference(SG24-8205-00)
• Configuring z/OS with IBM Rational Development and Test Environment for System z - z/OS
1.13 (SC14-7281-04)
50. RD&T Resources on the Web
• Rational System z Developmentand TestHub
• http://ibm.co/rationalsystemzdevtest
• RD&T SupportForum
• http://www.ibm.com/developerworks/forums/forum.jspa?forumID=2283
• RD&T on ibm.com
• http://www-01.ibm.com/software/rational/products/devtest/systemz/
• IBM System z zEnterprise BladeCenterExtension (zBX)
• http://www-03.ibm.com/systems/z/hardware/zenterprise/zbx.html
52. Notices and Disclaimers Con’t.
51
Information concerning non-IBMproducts was obtained from the suppliers ofthose products,their published announcements or other publiclyavailable sources. IBM has not
tested those products in connection with this publication and cannotconfirm the accuracy of performance,compatibilityor any other claims related to non-IBM products.
Questions on the capabilities ofnon-IBM products should be addressed to the suppliers ofthose products.IBM does notwarrantthe quality of any third-party products,or the
ability of any such third-party products to interoperate with IBM’s products. IBM EXPRESSLY DISCLAIMS ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDINGBUT
NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
The provision of the information contained h erein is notintended to, and does not, grantany right or license under anyIBM patents,copyrights,trademarks or other intellectual
property right.
IBM, the IBM logo,ibm.com,Aspera®,Bluemix,Blueworks Live,CICS, Clearcase,Cognos®,DOORS®,Emptoris®,Enterprise DocumentManagementSystem™,FASP®,
FileNet®,Global Business Services ®,Global Technology Services ®, IBM ExperienceOne™,IBM SmartCloud®,IBM Social Business®,Information on Demand,ILOG,
Maximo®, MQIntegrator®, MQSeries®,Netcool®, OMEGAMON, OpenPower,PureAnalytics™, PureApplication®,pureCluster™,PureCoverage®, PureData®,
PureExperience®,PureFlex®, pureQuery®, pureScale®,PureSystems®,QRadar®,Rational®,Rhapsody®,Smarter Commerce®,SoDA,SPSS, Sterling Commerce®,
StoredIQ, Tealeaf®,Tivoli®, Trusteer®,Unica®,urban{code}®,Watson,WebSphere®,Worklight®,X-Force® and System z® Z/OS, are trademarks ofInternational Business
Machines Corporation,registered in manyjurisdictions worldwide.Other product and service names mightbe trademarks ofIBM or other companies.A current listof IBM
trademarks is available on the Web at "Copyright and trademark information"at: www.ibm.com/legal/copytrade.shtml.
53. Thank You
Your Feedback is Important!
Access the InterConnect 2016 Conference Attendee
Portal to complete your session surveys from your
smartphone,
laptop or conference kiosk.