![Agenda ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
What's hot
What's hot (18)
Viewers also liked
Similar to (2011 10) rug - san ramon - autonomics and modernization
Similar to (2011 10) rug - san ramon - autonomics and modernization (20)
Recently uploaded
Recently uploaded (20)
(2011 10) rug - san ramon - autonomics and modernization
- 1. IMS Tools Autonomics and Modernization Christopher Holtz IMS Tools Modernization Architect
- 4. When problems do occur, the impact can be extensive Internet Extranet Intranet Load Balancer Internet Servers E-commerce Applications Databases Databases Mainframe Enterprise Server Applications ERP Messaging Middleware IT Operations DB Specialist Business Analyst Business Executive The database server is in trouble. I’ll create an incident as soon as I can and work on it. I hope no one is affected. Why am I having these database events? Everything seems ok. Why are these application transactions taking so long? We are behind in order processing. Why? Help Desk So many calls, so many incidents. I don’t know what to tell customers. Executives are upset with orders not being processed. I need to tell them why. IT Manager
- 6. IMS Tools Vision Putting information to work Sensors Policies Automation Modernization
- 7. IMS Tools Vision Putting information to work Sensor data Policies Automation Modernization Sensors Gather database statistics at regular intervals for your environment – e.g. space utilization, fragmentation, and optimization
- 8. IMS Tools Vision Putting information to work Sensors Policies Automation Modernization Policies User-defined policies and thresholds to determine when exceptions should be triggered and notifications should be sent
- 9. IMS Tools Vision Putting information to work Sensors Policies Automation Modernization Recommending and taking corrective actions based on the exceptions that are raised when thresholds are reached Automation
- 10. IMS Tools Vision Putting information to work Sensors Policies Automation Modernization Performing all of these actions from a rich, web-based user interface that is easy to install and access Modernization
- 20. Autonomics Director Configuration Sensors Sensors MVS1 MVS2 MVS3 MVS4 Sensors Sensors AD Master Server AD Failover Server AD Active Server AD Active Server ITKB Server
- 21. Autonomics Director Process Flow Internal Reader Customization Recommendations Autonomics Director Master Server ITKB Repository Server Tools Input Repository AD Repository Sensor Data Repository Policy Repository DBDLIBs DBRC RECONs Policy/Sensor Evaluation Services Scheduler Services Auto Discovery Router Services Monitor Services DB Sensor IC PC DB Sensor JCL Lib(s) USDB1 HDAM Sensor=8 hrs Eval =8 hrs USDB2 DEDB Sensor=12 hrs Eval =12 hrs User Interface Services
- 25. Recommendations
- 26. Recommendations
- 27. Recommendations
- 28. IBM Tools Modernization Introducing the IBM Tools Administration Console
- 31. Overview of IMS Resources with Drill-down Resource status, errors, and recommendations can be aggregated with an ability to drill down
- 32. Holistic View of IMS Resources … from Sensors … from Auto Discovery … from Autonomics Director … from Various HP Tools
- 33. Prepare the next generation of IMS DBAs Integrated help educates new and experienced DBAs on database concepts and how to interpret charts
Editor's Notes
- IBM IOD 2011 10/20/11 Prensenter name here.ppt
- AD supports sysplex not only for redundancy purposes intended to eliminate of Single-Point-Of-Failure within autonomics, but also for distribution of workload required to support autonomics itself – execution of DB Sensors. The Master AD server is the hub of the autonomics environment. Everything is initiated from the master server, including ITKB interactions, decisions to gather sensor data, policy evaluations, and user interactions. The Master AD server communicates with other active AD servers in the same AD group to dispatch initiation of DB Sensors. The dispatch to active servers is based on availability/capacity within the sysplex based upon an MVS Workload Manager routing interface. The use of WLM is optional, and in lieu the user can select a round-robin algorithm for balanced workload distribution of DB Sensors. Sensors can be automatically scheduled by the AD Server or initiated manually or through an existing job scheduler sub-system. In any case, the Sensors communicate their completion and collection of new sensor data to the Master AD Server. Should the Master AD Server terminate for any reason, one of the other Active AD Servers takes over as the Master. A special type of Failover AD Server may be used instead of Active AD servers if workload distribution is not desired. The Failover Server only becomes the Master AD Server if it determines that the Master terminated and no other Active Servers are available.
- During customization of AD the customer provides libraries and scheduling options for AD execution: DBRC RECON datasets are used during DB discovery for DBRC group info, HALDB partition info, and DEDB area info. DBD library provides a list of databases and attributes for definition to AD DB Sensor JCL library for selection of automatic scheduling of DB Sensor jobstreams Customers can create a schedule to indicate when are the peak periods in their workload activity. AD will not schedule any sensor data collection against the DBs during the identified peak periods. Customers select which databases from the environment they would like monitored by AD. AD’s auto-discovery helps the user select the databases and database groups defined in DBD library and RECON, respectively. Other options specified by the user include the frequency of Sensor data collection and frequency of policy evaluation for said database. Customization information is retained in the ITKB repositories for persistence. AD maintains a list of monitored DBs and their monitoring requirements in memory of AD server. On a periodic interval known as the “sweep interval” (user controlled) AD analyzes the monitor list for actions that need to be performed such as sensor data collection and/or policy evaluation and creates time-stamped action objects to represent these actions. On a periodic interval known as the “cycle interval” (user controlled) AD analyzes the action object queue and dispatches processes to carry out the actions. Actions may include schedule sensor data collection or policy evaluation. Submission of Sensor Data Collection accesses customer identified Sensor JCL, performs limited DB/partition/area name substitution and submits the jobstream to the internal reader for execution. When Sensor Data Collection job completes it notifies the Master AD address space that new sensor data is collected, allowing subsequent policy evaluation to be performed. Policy evaluation takes place and the results are stored in an ITKB repository. The customer can access theses results via the AD user dialog.
- IBM IOD 2011 10/20/11 Prensenter name here.ppt 10/20/11 21:30
- Today we have 40+ tools around IMS running on z. The only real interface we have available to us is ISPF. We need to get into the rich client (browser and eclipse) space. Once we get out to browsers or eclipse we can then utilize graphs, graphics, widgets, frames, buttons, etc. whatever makes the most intuitive sense for the end user. And perhaps more importantly there is no longer a strict 1 to 1 relationship between interfaces and tools. A single UI screen could interact with several tools, compile information, and present it as a dynamically configured dashboard. More so, it could get some information from an IMS Tool and cross reference it with information from other another system, product or even the general internet…but how do we do it? There have been many solutions that attempt to leverage the ISPF VTAM path by basically doing screen scraping of the underlying data streams (IBM HATS is a good example)…but it doesn’t give us real access to the tools, only to their ISPF interfaces, which are naturally quite limited in the type of data they present. DAI is our main solution on z. It’s an SMP installable gateway allowing direct TCP access to our tools (DAI also handles setting up and hosting tools that are typically invoked through JCL or hosted in TSO). From a eclipse client installed right on the end users machine this is enough, but if we are going to go further and also support browser-based interfaces we naturally need a web server (specifically an application server) that acts as a middle man between the dumb browser (running anywhere in the world, perhaps even your iphone) and DAI. With DAI having GAed in February this is where we are today. The next step is to begin leveraging those rich client interfaces and the now accessible functionality provided by our tool suite to build a modern interface -- not to just our 40+ individual tools, but to IMS management and administration as a whole.
- IBM IOD 2011 10/20/11 Prensenter name here.ppt 10/20/11 21:30