1. IMS Sysplex Manager Functional Overview
Bob Magid
CTP Summit 2017

2. Data Sharing Management
Agenda
Product Highlights
Data Sharing Management
SQ transaction affinity routing
SQ buffer overflow protection
IRLM long lock report
CSL RM structure management
Other Product Functions
First, I will go over the product highlights. I will do a quick overview of all the functions and features that this product offers.
Next, I will go over in details the Data Sharing Management functions, which is the main focus of this presentation. This includes the discussion of the SQ transaction affinity routing feature, the IRLM real-time and long lock report and the Common Service Layer Resource Manager structure management function.
Last, I will talk about some other product use scenarios, but probably will not have time to go into them in depth. The material are all there for your own reference.
So let’s get started!

3. IMS Sysplex Manager Highlights
Real-time management of the IMS Sysplex Environment
Single system image thru local and aggregate view of data
Simplified User Interface (TSO/ISPF)
Structured displays of IMS resources and CF structures
Global Type-1 command, OM Type-2 and IMS SPOC
Basic z/OS performance information and SVC dump capture
Statistics for CSL (OM, RM and SCI), IRLM and CQS
Dashboard with key system indicators and threshold monitoring
Intercept System exceptions and generate Console alerts
Produce real-time IRLM Long Lock Report
Browse, delete and recover messages on Shared Queues
Delete RM resource structure entries
Assign affinity for transactions in Shared Queues environment
Protect against buffer overflow in Shared Queues environment
Support IMS DB/TM, DBCTL, and DCCTL for IMS v13 and later
First off, let’s review the product highlights:
IMS SM is a real-time management tool. Designed specifically for IMS in a Sysplex Environment.
SM gives you single point of control of all your IMS subsystems by providing you a single system image thru local and aggregate view of data. This is particular helpful when you have cloned IMS systems where they share common workload and resources and want to view them together as 1 system.
The product has the ISPF/TSO interface that you are familiar with. This helps reduce the complexity of installing, customizing and using the tool
It provides Structured displays of IMS related address spaces, resources definition and status and CF structures thru scrollable ISPF tables
Besides type-2 commands, SM also allows you to issue type-1 (classic /command) to 1 or more IMS systems at the same time.
SM has some basic z/OS performance data for your IMS address spaces to give you a quick view resource utilization from z/OS perspective
SM shows internal statistics regarding the CSL (Common Service Layer) components OM, RM and SCI to help you understand what’s going on inside these components
SM provides a customizable dashboard with key system indicators and threshold monitoring
As far as management capabilities:
SM can capture system exceptions thru IMS log records and generate alerts by issuing WTOs to the z/OS console, so that you can build automation to respond to them automatically
SM provides automatic IRLM Long Lock Report as they occur. Report is issued to z/OS console via WTOs, recorded to SM history log for after-the-fact reviewing.
SM allows you to check SQ destination queue depth, browse and delete messages and give you extensive CQS data to help you optimize your SQ environment
SM lets your view the content of RM resource structure and delete entries when needed. This is a unique feature in that there’s no other tool on the market that does this.
Most recently, we added a feature that lets you easily assign affinity to transactions in SQ environment
SM can run on any IMS flavor, whether it’s online IMS DB/TM or DBCTL or DCCTL. SM requires IMS V9 or later.

4. IMS Sysplex Manager Sample Configuration
MVS1
MVS4
MVS3
MVS2
IMS1
IMS2
SCI1
RM1
OM1
SCI2
RM2
OM2
IMSSM DC
CQS1
CQS2
IMS Connect
IMS Connect
IMSSM UIS
This is a sample configuration of Sysplex Manager.
Here we have a 4-way Sysplex. IMS1 and IMS2 are installed on MVS1 and MVS2.
The blue boxed labeled IMS SM DC are the product’s DATA COLLECTOR component. The DC interacts with IMS control region to gather IMS data. If you are running SQ, then DC will interact with CQS to manage SQ. And if you are running IMSplex mode, the DC will communicate with RM, OM and SCI as well
The orange boxes labeled IMSSM UIS are the product’s UI server component. The UI server works as a hub of receiving requests from the TSO users, figures out which DC will best serve the requests, forward the requests to the DC, receives output from the DC and returns them back to the TSO users. The UI server also weed out duplicate data and aggregate data when needed. You need only 1 UI server in the entire Sysplex, but here we have 2 for redundancy.
The TSO users you see down below, there can be as many of them as you want. They can log on from anywhere in the Sysplex to access SM services.
FDR1
FDR2

5. IMS Data Sharing Shared Queues SQ transaction affinity routing
SQ buffer overflow protection
Shared Databases
IRLM real-time and long lock report
Shared Resources
CSL RM structure management
So in today’s topic of improving data sharing management, I would like to focus on the following IMS features and show you how IMS Sysplex Manager can help you further customize or manage them.
When we talk about IMS data sharing, we are not just talk about shared databases, but also shared message queues and other shared resources.
Shared Queues - introduced in Version 6
Allows multiple IMS subsystems share one set of message queues
Since the queues are available to all the IMS systems, any IMS system may process a transaction. For SQ, SM has the transaction affinity routing feature to help you fine tune your SQ environment.
Shared Databases - introduced in Version 5 and has had many enhancements
Allows multiple IMS subsystems to access and update the same IMS databases with full READ and WRITE integrity using IRLM as the lock manager. For this, SM provides real-time IRLM lock information as well as real-time long lock report to help you detect and resolve database lock bottleneck.
Shared Resources, in particular, the Sysplex Terminal Management feature– new in Version 8
Sysplex terminal management (STM) consists of
Resource type consistency: Guaranteeing that the same message destination resource name (transaction, lterm, msnames, APPC descriptor name) is not used to define different resource types by different IMS systems. For example, don’t allow resource name to be defined as a transaction on one IMS and an LTERM on another IMS)
Resource name uniqueness: Guaranteeing that the same resource is not active on multiple IMSs at the same time. For example, do not allow USERA to be signed on to both IMS1 and IMS2.
Resource status recovery: Restoring sysplex terminal and user status following a logoff/logon, signoff/signon, or IMS restart.
In support of this feature, SM lets you DELETE RM structure entries to do cleanup when needed without scratching CF structure and restarting IMS.
Now let’s go into details about each of these features.

6. Shared Queue Transaction Affinity Routing
Now, let’s delve in more details about the Affinity routing feature to see how it can help you improve Data Sharing among your IMS systems.

7. Shared Message Queues Transaction Affinity
IMS Shared Message Queues provides
Enhanced scalability, throughput, and response time
Enhanced availability through redundancy
IMS Shared Message Queues creates
Additional components to manage (CQS, structures, logstreams…)
Additional operational complexity
Possible false scheduling
Possible resource contention
As you know, IMS SQ provides enhanced scalability, throughput and response time for your transactions. It also enhance availability through redundancy because now you have multiple IMS systems access common message queues. If IMS or MVS fails, you still have other process transactions.
But on the other flip side, all these advantages bring new challenges. IMS SQ creates additional components to manage such as Common Queue Server address space, CF structures… Operational complexity is another challenge because you have to deal with more components spread across the Sysplex. Another side effect of going SQ is possible false scheduling. This is a phenomenon where member IMS systems all schedules resource for an inbound message but eventually only 1 IMS gets it. And finally, possible resource contention may occur such as lock contention when parallelism in processing is introduced.

8. Transaction Affinity Highlights
Finer control of transaction scheduling
Non-invasive to existing definition and operation
No omission of transaction definitions in sysgen
No stopping of transactions
No re-classing of dependent regions
No operational impact for loss of a system
User defined affinity to route transaction messages
Any IMS in the shared queues group
Any subset of IMS systems
Equal or weighted distribution
A number of IMS customers have hesitated when deciding to move to SQ environment because lack of effective tool to control transaction affinity. Although IMS provides a some methods of managing affinity such as local affinity via an exit, or using dependent region classing or stopping the transactions where they should not run… all these methods are too manual and complex operationally.
Recognizing our customer’s need, we have designed a solution with these problems in minds. Here are the highlights:
Finer control of transaction scheduling – down to individual transaction level
Non-invasive to existing definition and operation
No need to omit transaction definitions in SYSGEN
No need to stop transactions
No need to use any special classing scheme for dependent regions
No operational impact for loss of a system
The users has total flexibility in control how to route tran messages:
Msg can be routed to any IMS in the SQ group
Or just to a subset of IMS systems
With equal or weighted distribution

9. Transaction Affinity Implementation
User affinity definitions created in IMS Proclib
Definitions “copied” to CQS list structure
IMS initialization
Shared by all IMS systems
Persistent across IMS restarts
Synchronized affinity definitions across Sysplex
Seamless operations
Local informs/registration issued for transactions with affinity
Backup IMS system destination for planned and unplanned outages
Option to reject transaction if destination IMS systems not available
Ability to tweaking affinity definitions dynamically
Now, let’s look into the actual implementation of this feature.
First, the users create affinity definitions in a IMS PROCLIB member. The definitions are then “copied” to a CQS list structure at IMS initialization. Once the structure is populated, all subsequent IMS systems will share this same structure. The structure content is persistent across IMS restarts. Since all IMS reads definitions from the same structure, affinity definitions are synchronized across the Sysplex.
Once initialized successfully, operations are seamless.
Local informs/registration are automatically issued for transactions with affinity, no IMS commands needed to be issued by the users.
Backup IMS system destination can be specified to planned and unplanned outages
If both primary and backup IMS systems are not available, the transaction can be rejected with a message for network messages or a feedback code for applications
And in April, we released an SPE that allow users to change or add affinity definitions dynamically without restarting IMS or CQS.

10. Transaction Affinity Implementation
Sample Proclib Definitions
OPTIONS(STRUCTURE(GJESMAFN),STATUS(ENABLED), PGMREJECT(ABEND(U3303)),NETREJECT(2175))
SYSTEM(TARG(IMSGRP01),IMS(IMS1),STATUS(ENABLED))
SYSTEM(TARG(IMSGRP02),IMS(IMS2),STATUS(ENABLED))
SYSTEM(TARG(IMSGRP03),IMS(IMS3),STATUS(DISABLED))
SYSTEM(TARG(IMSGRP1A),IMS(IMS1,IMSA,IMS1),STATUS(ENABLED))
AFFINITY(TYPE(TRANSACT),TARG(IMSGRP1A,IMSGRP02),DISP(REJECT), DEST(NAME(APOL12)),STATUS(ENABLED))
AFFINITY(TYPE(TRANSACT),TARG(IMSGRP02,IMSGRP01),DISP(REJECT), DEST(NAME(JAVC%NV*)),STATUS(ENABLED))
AFFINITY(TYPE(TRANSACT),TARG(IMSGRP1A),DISP(QUEUE), DEST(NAME(TRAN%%C,TRANAB*)),STATUS(DISABLED))
AFFINITY(TYPE(TRANSACT),TARG(IMSGRP01), DEST(NAME(%%F3,%%F4)))
AFFINITY(TYPE(TRANSACT),TARG(IMSGRP1A),DEST(CLASS(1,2,3)))
Let’s go a little more details into the PROCLIB statements that are used to define affinity.
There are 3 statements: OPTIONS, SYSTEM and AFFINITY.
The OPTIONS is used to specify the global list structure name that houses all affinity defintions, the overall status of routing and the option to reject message if no IMS is available to process the message
The SYSTEM statement is used to assign a name to a single or to a group of IMS systems and its status. Notice you can skew message distribution by repeating the IMSid when defining the group.
Lastly, the AFFINITY statement is to connect the transaction with a routing group, the disposition of the message when both primary and backup routing group are not available and its status.
The destination name can be a absolute tran name, or wildcarded names or a transaction class.

11. Reducing False Scheduling Overhead
Example
Three systems in group IMSA, IMSB, and IMSC
Transaction TRAN1 causes false scheduling
Balanced affinity definition
Arriving TRAN1 messages rotated to each
SYSTEM(TARG(SYSTEM1),IMS(IMSA,IMSB,IMSC))
AFFINITY(DEST(TRAN1),TARG(SYSTEM1))
Weighted affinity definition
50% of TRAN1 messages routed to IMSA
SYSTEM(TARG(SYSTEM1),IMS(IMSA,IMSA,IMSB,IMSC))
Let’s look at an sample configuration.
Let’s say we have a 3 systems in the routing group: IMSA, IMSB and IMSC. It’s been determined that TRAN1 causes false scheduling (by the way, you can check for false scheduling by analyzing DLRFALSE bit in the 07 record indicates this (V10 and above)). Our goal is to have balanced affinity definition, meaning arriving TRAN1 messages are rotated to each IMS equally.
First, we have the SYSTEM statement, define a target named SYSTEM1, which includes 3 IMSs A, B and C
Then, we have the AFFINITY statement, with destination is TRAN1, and associate it with target SYSTEM1 and that’s it.
Now, let’s say instead of equal distribution, we want a weighted distribution such that 50% of TRAN1 messages will be routed to IMSA
In That case, you would need to change the SYSTEM statement so that the IMS clause would have IMSA, IMSA, then IMSB and IMSC. By specifying IMSA twice, you have caused TRAN1 messages to be routed to IMSA half of the time.

12. Reducing Database Lock Contention
Example
Three systems in data sharing group IMSA, IMSB, and IMSC
Transaction TRAN2 causes contention
Affinity definition
Arriving TRAN2 messages limited rotation to subset
IMSC only used if IMSA and IMSB are unavailable
SYSTEM(TARG(SYS1),IMS(IMSA,IMSB))
SYSTEM(TARG(SYS2),IMS(IMSC))
AFFINITY(DEST(TRAN2),TARG(SYS1,SYS2))
Let’s look at this example.
Again, we have 3 systems in a data sharing group (IMSA, B and C)
Suppose that transaction TRAN2 is known causing contention
Our goal is to define affinity for TRAN2 so that arriving TRAN2 messages has limited rotation to a subset of IMS systems. Also, IMSC is only used if IMS A and B are unavailable.
To achieve that goal, we have to following statements:
First SYSTEM statement defines a target routing group named SYS1 with IMSA and IMSB in it
Second SYSTEM statement defines a target routing group named SYS2 with only IMSC in it
The AFFINITY statement connects TRAN2 with primary target of SYS1 and backup target of SYS2. In other words, under normal operation, TRAN2 will only be routed to IMSA and B. It’s only routed to IMSC when both IMSA and IMSB are unavailable.

13. SQ buffer overflow protection
Ok, so that concludes the discussion on our transaction affinity routing feature.
Let’s move on to the ‘Managing IRLM locks’ topic.

14. SQ overflow protection
What does it do?
Protect IMS control region from x78 abends (out of storage) caused by run-away/looping applications
Features
Inactive mode – turn off overflow protection feature (default)
Report mode – help customers study local buffer usage
Enforce mode – automatic actions against incoming messages to avoid local buffer out of storage condition
What does it NOT do?
Overflow protection against SQ structure overflow
There are 3 run modes available
Inactive mode – this is the default, which means the feature is inactive by default. We don’t want to have the feature active unless the customers understand how it works and set it up correctly
Second mode is report mode – this is a great way to learn about local buffer usage at your installation. We output informational messages about buffer utilization at your pre-defined interval. So you can run in report mode for a few weeks during your peek hours for example to help you adjust your IMS buffers parameters
Once you understand your buffer usage pattern, you can go into Enforce mode and set your protection preference. In Enforce mode, you set thresholds as a percentage of overall buffer pool and warning messages or actions will be taken against the largest buffer users when those thresholds are exceeded.
So, what doesn’t this tool do? At the moment, this tool doesn’t provide SQ structure usage tracking or prevent structure overflow.

15. Implementation Details
Exploit Queue Space Notification Exit DFSQSSP0
SM exit does not interfere with dynamic buffer expansion/compressions by IMS
Terminates unit of work as follows:
‘A7’ status code if message is from application
DFS0777I if message from LU 6.2 conversation
DFS1289I if message is from OTMA
Requirements
IMS QBUFMAX parameter must be set for Enforce mode
Require IMS Tools Generic Exits common code to allow co-existence of multiple DFSQSSP0 exits
Ok, let’s look at the implementation details for this feature.
We use the IMS Queue Space Notification exit DFSQSSP0 to keep track of buffer usage and ask IMS to terminate UOW when needed. We don’t interfere with how IMS does its dynamic buffer expansion or compressions.
When we determine that buffer usage has entered the critical threshold, we will communicate with IMS via the exit that we want IMS to fail the UOW. Depending on the type of the UOW, IMS will terminate UOW in the following ways:
‘A7’ status code if message is from application
DFS0777I if message from LU 6.2 conversation
DFS1289I if message is from OTMA
Ok, so what are the requirements for activating this feature?
First, you must set the QBUFMAX IMS parameter in your IMS control region. This is the absolute max # of buffers IMS will allocate for local buffers. You can use the Report mode to fine tune this number.
The second requirement is you must install our Generic Exits common code. This is a free component that comes with various IMS Tools to provide co-existence support for a # of IMS exits, in this case DFSQSSP0 exit.

16. Implementation Details (Continued)
Proclib member control parameters:
LBUFMODE= INACTIVE| REPORT|ENFORCE
specifies requested run mode
LBUFREPT=(InitialValue,BufferPctIncrement,BufferNoIncrement,TimeInterval
specifies REPORT mode parameters
LBUFWARN=(InitialValue,BufferPctIncrement,BufferNoIncrement,TimeInterva
specifies ENFORCE mode parameters for WARNING mode
LBUFACTN=(InitialValue,BufferPctIncrement,BufferNoIncrement,TimeInterval
specifies ENFORCE mode parameters for ACTION mode
LBUFCRIT=(InitialValue,BufferPctIncrement,BufferNoIncrement,TimeInterval)
specifies ENFORCE mode parameters for CRITICAL mode
LBUFLBUA= ###
specifies no of buffers a caller must hold to be considered a large user in action mode. The exit will take actions against large user’s only.
LBUFLBUC= ####
specifies no of buffers a caller must hold to be considered a large user in critical mode. The exit will take actions against large user’s only.
The users define the overflow settings using these control parameters in an IMS proclib member. There are 7 parms, so let’s quickly go thru them.
LBUFMODE can be inactive/report/or enforce to control the run mode
LBUFREPT is used when you are in report mode and it controls how report messages will come out
LBUFWARN,LBUFACTN, and LBUFCIT are pertaining to the Enforce Run mode. You use these parms to define your warning, action and critical thresholds
LBUFLBUA and LBUFLBUC are the # of buffers a UOW must hold to be considered a large buffer users. When the usage reaches Action or Critical level, actions will be taken against the large buffer users.

17. Sample Messages Report Mode (2 minutes interval reporting)
JOB GJE9010I DFSQSSP0 REPORT MODE: BUF 11 PCT IMS1
JOB GJE9010I DFSQSSP0 REPORT MODE: BUF 15 PCT IMS1
JOB GJE9010I DFSQSSP0 REPORT MODE: BUF 18 PCT IMS1
Large buffer users (periodic messages):
JOB GJE9050I DFSQSSP0 LARGE USER: BUF FOR BMP255 IMS1
JOB GJE9050I DFSQSSP0 LARGE USER: BUF FOR BMP255 IMS1
Warning Level
JOB GJE9020I DFSQSSP0 WARNING MODE: BUF 13 PCT IMS1
JOB GJE9020I DFSQSSP0 WARNING MODE: BUF 14 PCT IMS1
JOB GJE9020I DFSQSSP0 WARNING MODE: BUF 14 PCT IMS1
Action Level
JOB GJE9030I DFSQSSP0 ACTION MODE: BUF 76 PCT IMS1
JOB GJE9030I DFSQSSP0 ACTION MODE: BUF 79 PCT IMS1
Critical Level
JOB GJE9040I DFSQSSP0 CRITICAL MODE: BUF 90 PCT IMS1
JOB GJE9040I DFSQSSP0 CRITICAL MODE: BUF 90 PCT IMS1
Here are the samples messages that SM puts out depending out which run mode you are in.

18. Managing IRLM locks
Ok, so that concludes the discussion on our transaction affinity routing feature.
Let’s move on to the ‘Managing IRLM locks’ topic.

19. Data Sharing Long Locks
DB Lockouts by applications holding IRLM locks for an inordinate amount of time
Could go unrecognized until it becomes critical
Lack of supported tools to assist in recognition and identification of problem
Manual intervention required to resolve
Exception processing for Long Locks
Automatic real-time recognition when IRLM detects
Information consolidated, analyzed for top blocker, and presented
Information recorded in exceptions file and sent to z/OS console
Messages can be sent to z/OS console using user exit so that automated operations can resolve
Problem quickly resolved without manual intervention
In this scenario, we are talking about long locks.
The Problem:
DB access can be locked out when applications hold IRLM locks for an inordinate amount of time
The problem can go unrecognized until it becomes critical when user complain about performance or thru put issue
There is a lack of tools to assist in recognition and identification of long locks problem
And in order to resolve the situation, manual intervention is usually required
To help customers in this area:
Sysplex Manager provides automatic long locks detections as they occurred
We analyze the information and present top-blocker info such as what resource is being held, who holds it so that you can determine what can be done to free up the situation
The information is recorded in an exception file for after the fact reviewing
The message is also sent to the z/OS console so that you can have automatic operation tool take action and resolve the issue without manual intervention

20. Data Sharing Long Lock Exceptions
Here you can see the output of this function.
You can see that messages are issued to z/OS console to show that a long lock situation has been detected .
In this case, you see that we have identify the top blocker causing the problem. It’s an BMP named BMP21.

21. Data Sharing Long Lock Exceptions
In this slide you can see that we have created some automation on our test system that looks for the top blockers
In this case we stop the region causing the problem and therefore allowing the work that wait behind that lock to go on.

22. Aggregated IRLM Statistics
Managing the well being of IRLM(s)
Deadlocks, false contentions, storage utilization?
Multiple IRLMs to check
Information gathered from IRLMs across Sysplex
Aggregated into single system image
Drill down for information from individual IRLMs
In order to manage the well-being of IRLM, there are some data that you need to pay attention to such as
The Problem:
Deadlocks – a high deadlock rate might indicate scheduling or application logic problem
False contentions – high number indicates that your lock structure is too small
Storage utilization – high CF storage means your application is holding large # of locks, therefore the application should commit changes more often
Again, you may have multiple instances of IRLM to monitor
The Solution:
SM gather data around the Sysplex and aggregate them to let you view them as a single system image
Similar to the RM statistics we looked a few slide back, you can see a break-down of the aggregate data when you drill down

23. Aggregated IRLM Statistics
This is the aggregated view for IRLM statistics, which means these numbers are the summation of all numbers from all IRLMs to provide single system image view of the data

24. Aggregated IRLM Statistics
The most important numbers on this are
False contention: if high, the lock structure may be too small
Local deadlocks : if high, pay attention to scheduling or application logic

25. Managing CSL RM Structure
Now moving on the last topic about improving data sharing management ‘Managing the Common Service Lay RM structure’

26. Managing CSL RM Structure
Common Service Layer RM Structure Content
Holds global status of IMS Resources in IMSPlex
Determines IMSPlex wide status of Trans, LTERMs, Users
No capability to view content
No capability to alter/delete inconsistently defined resources
Resource Management Structure display
Real-time display of structure content
Selectable via resource type and name filtering
Global status info to aid delete decision
Capability to delete selected resource definitions (multiple delete, delete by resource type or by owner)
Eliminates need to scratch and reallocate resource structure
The Problem:
The CSL RM structure is used by IMS to hold global status of IMS Resources in the Plex
The content of this structure determines the IMSplex wide status of Transactions, Lterms, and users
IMS doesn’t provide any command for you to display the content of this structure
IMS doesn’t provide any capability for you to delete or alter the entries in this structure. Therefore, if you define something incorrectly, you need to scratch and reallocate the whole structure to recover from the situation, which will impact the availability of your IMS system.
The Solution:
SM allows you to view the content of the structure in real-time
You can filter the result by name or resource type
You can delete entries from the structure, therefore eliminates the need to scratch and reallocate the resource structure and preserve the availability of your IMS systems

27. IMS Resource Structure Content
Here is the menu for the Resource Structure Management
You can select resource type you want to look at, or you can select option 11 which will show everything currently exist in the structure
We will select option 11 here.

28. IMS Resource Structure Content
And here’s is the result.
What we see here a list of transactions.
We show the Resource name, type, the version which is internal info that IMS uses to manipulate the content of the structure.
And if there’s an owner to the resource, we will show it too
To delete an entry, place a ‘d’ on the Cmd input field and hit Enter

29. IMS Resource Structure Content
Like any good ISPF panel with manipulation capability, we show a confirmation window to make sure this is the action want to take. You can turn it off and you will not be asked again next time
Hit Enter here to delete the entry.

30. IMS Resource Structure Content
And as you can see in the Prompt column, a Deleted message is displayed to inform you that the entry has been successful deleted from the structure.

31. Other Product Use Scenarios
And that concludes our discussion on improving data sharing management. Now let’s take a quick look at other functions that Sysplex Manager tool has to offer.

32. Scenario 1 – Taking Inventory and Capture Diagnostics
Many address spaces – IMS Control Region, IMS DLI/SAS, IMS DBRC, IRLM, CQS, RM, OM, SCI, etc..
How do you identify related IMS components across the Sysplex?
What is the status of these components?
What version of IMS components are involved?
How much resource are they using from z/OS perspective?
How do you collect diagnostic data to debug sysplex problem?
IMS Sysplex Manager structured TSO/ISPF interface
Guided display of IMS components
Provides component id, task or job name, version, status and basic z/OS information such as CPU time and EXCP counts
Drill-down to detailed component information
Easily capture console dumps for IMS components across the plex
Check DBRC RECON datasets placement and VSAM stats
The Problem:
Today’s IMS environment can get quite complex. Many new address spaces have been added over the years.
Besides the traditional IMS control region, DLI/SAS, DBRC … you may also have IRLM for data sharing, CQS for shared message queue and the CSL address spaces for IMSplex
It’s difficult sometime to identify all these components as far as where they reside across your Sysplex and the status of them to make sure the component required to be up are currently up and also what are the versioning of those.
The Solution:
SM gives a guided display of all related IMS components across z/OS images
Provides component id, task or job name, version, status and basic z/OS information such as CPU time and EXCP counts
Ability to drill-down to detailed component information

33. Component List This is a sample of the Component List display.
We show all the various IMS address spaces on this system… It shows a couple of IMSes, it shows the version, we shows the OS-system / z/OS system on which these IMSes reside, we show the job name or started task name, for CR, we should the related DBRC, DLI and IRLM
You can see the CQS there with the version
We show RM, OM, SCI and the versions associating with these pieces.

34. Component List (cont) This is the display after we scroll to the Right
We have indicators whether the IMS is using SMQ and Data Sharing
We also have some z/OS performance data for the components
And what we do now is selecting IMS1 by placing an ‘s’ in the cmd input field and hit enter and we go to the next slide

35. Capture Console Dumps This is the display after we scroll to the Right
We have indicators whether the IMS is using SMQ and Data Sharing
We also have some z/OS performance data for the components
And what we do now is selecting IMS1 by placing an ‘s’ in the cmd input field and hit enter and we go to the next slide

36. Capture IMS CF structures Dump
This is the display after we scroll to the Right
We have indicators whether the IMS is using SMQ and Data Sharing
We also have some z/OS performance data for the components
And what we do now is selecting IMS1 by placing an ‘s’ in the cmd input field and hit enter and we go to the next slide

37. z/OS perspective for IMS address spaces
To continue on the component data theme, let’s look at the z/OS information for IMS address space option
Here you can see more detailed z/OS information for various IMS address spaces , all in one place
We show Jobname, ASID #, priority, TCB time….

38. Scenario 2 – Managing IMS System Parameters
Many system run-time parameters
Sources: DFSPBxxx, overrides via Control Region PARM=
Which ones are being used?
Are the parameters the same across the Sysplex?
System parameter display
Real-time scrollable display of “resolved” values
Parameter values across all IMS systems for easy comparison
New – System Parameter Tutor for instant description
One of the options on the menu we just looked at is the ability to look at run-time parameters.
The Problem:
There are a lot of different sources for run-time parameters, we have the DFSPB member but they can be overridden at execution time.
It’s difficult some time to see which ones are actually in used and are they the same across your multiple images in the Sysplex.
The Solution:
Another thing that Sysplex Manager do is give you a display these run-time parameters which has the resolved values, the values that are actually at execution time
We allow you to look them across multiple IMSes in the Sysplex so that you can compare them
We even analyze the data and show you only parameters that have different values

39. IMS System Parameters Here is a display of these parameters.
First let’s explore some of the fixed fields on the panel that you will see over and over again.
On the top left corners are 3 fields: IMSplex, SM server and Route.
The IMSplex field has the Plex name that associates this environment. That includes all the IMSes, the OM,RM, SCI that we looked at earlier.
The SM server as indicated earlier, you can have multiple SM servers, this one shows which server you are communicating with at this time.
The Route field is used to direct requests to one or more specific components, in this case we have a Route field of * , that tells SM to go out and retrieve data for all the IMSes
What you see on this panel is data from 2 IMSes, IMS1 and IMS2 and this info has been sorted. Most of the panels has sort capability, where you can sort on any column on the display.
In this case the info has been sorted by the Keyword parm which allows you to look at all the parms across IMS systems. This is a good way to make sure your system parms are consistent or to look for potential problems caused by these parms not being defined the same.

40. IMS System Parameters
To take a step further, we analyze the data in the table and show you only parms that have unequal values
To get there, from the Option drop-down menu, select option 4.

41. IMS System Parameters – Showing Unequal Parms
And here it is, a list of parms that have unequal values

42. IMS System Parameters – Tutor
And here it is, a list of parms that have unequal values

43. Contact Information
Name