CA IDMS Deadlock Analysis

World®
’16
CA IDMS™ Deadlock Analysis
John Siraco, Director, Software Engineering
CA Technologies
MFX71E
MAINFRAME AND WORKLOAD AUTOMATION

2 © 2016 CA. ALL RIGHTS RESERVED.@CAWORLD #CAWORLD
Abstract
This session provides an explanation of the locking
process and the potential deadlock situations that may
happen. The material presents the messages generated
when a deadlock occurs and their use in identifying the
underlying cause of the deadlock scenario. Finally some
general application design recommendations are
discussed to minimize the occurrences of deadlocks. The
last three sections relate to CPU savings options (zIIP),
Multitasking, and the use of Parallel Sysplex options.
John Siraco
CA Technologies
Director, Software
Engineering

Agenda
LOCKING FUNDAMENTALS
DEADLOCK SCENARIOS
QUESTIONS AND ANSWERS
LOCKING ERROR MESSAGES
DEADLOCK ANALYSIS
GENERAL RECOMMENDATIONS
1
2
3
4
5
6

Locking Fundamentals
§ Our database contains a record type named PRODUCT which
contains a field name PROD-QUANTITY
§ PROD-QUANTITY represents the quantity of this product that
is in inventory and available to be shipped
Why do we need locking?
PRODUCT
PROD-QUANTITY = 2

§ Two run-units simultaneously access this occurrence of the
PRODUCT record with the intent of allocating 2 units of the
product for shipment to a customer.
§ Each run-unit sees that 2 units are available and each proceed
to update the record occurrence
PRODUCT
PROD-QUANTITY
= 2
Run
unit 1
Run
unit 2OBTAIN OBTAIN

§ Without locking, each run-unit thinks it has allocated 2 units
of the product for shipment to its associated customer but
only a total of 2 units exist
§ The PROD-QUANTITY field is set to zero although 2 units more
than available were allocated for shipment
PRODUCT
PROD-QUANTITY
= 0
Run
unit 1
Run
unit 2
MODIF
Y
MODIF
Y
Ships 2
units
Ships 2
units

§ CA IDMS maintains two basic types of record locks
– SHARED locks
§ Also known as RETRIEVAL locks
§ Multiple run-units can read a record occurrence and each can hold a
SHARED lock on that occurrence
§ No run-unit may acquire a SHARED lock on a record occurrence on which
another run-unit has an EXCLUSIVE lock
Types of Record Locks

§ EXCLUSIVE locks
– Also known as UPDATE locks
– Only one run unit can concurrently hold an EXCLUSIVE lock on a record
occurrence
– No run-unit may acquire an EXCLUSIVE lock on a record occurrence on
which another run-unit has a SHARED lock
Types of Record Locks

§ Locking contention occurs in the following scenario
– Run-unit 1 reads the PRODUCT record causing a SHARED lock to be set
– Run-unit 1 then modifies the PRODUCT record causing its SHARED lock
to be upgraded to an EXCLUSIVE lock
Locking Contentions

– Before run-unit 1 issues a FINISH or COMMIT run-unit 2 attempts to
read the PRODUCT record occurrence which tries to establish a
SHARED lock on the occurrence. This causes run-unit 2 to go into a
wait until it can get the SHARED lock.
Locking Contentions
PRODUCT
PROD-QUANTITY = 0
Run
unit 1
Run
unit 2
MODIFY OBTAIN
Holds EX
lock
Waits on
SH lock

§ When run-unit 1 issues a FINISH or COMMIT it will release its
EXCLUSIVE lock on the record occurrence
§ Run-unit 2 can then acquire the SHARED lock and its OBTAIN
command can be completed
§ Run-unit 2 sees the contents of the record as they were set by
run-unit 1’s MODIFY command
Locking Contentions

Deadlock Scenarios
§ Based on the sequence in which run-units access database
records it is possible that two or more run-units each hold
locks on record occurrences required by the other run-unit
§ When this occurs a deadly embrace or deadlock occurs and
one of the run-units must be abended

Deadlock Scenarios (cont.)
§ A deadlock occurs in our example with the following sequence
of events
– Run-unit 1 issues an OBTAIN against a PRODUCT occurrence causing a
SHARED lock to be set
– Run-unit 2 issues an OBTAIN against the same PRODUCT occurrence
causing another SHARED lock to be set on the record

– Run-unit 1 issues a MODIFY against the record occurrence and goes
into a wait until run-unit 2 releases its SHARED lock
– Run-unit 2 issues a MODIFY against the same occurrence and goes into
a wait until run-unit 1 releases its SHARED lock
– A deadlock condition exists between run-units 1 and 2 and must be
resolved by abending one of the run-units

PRODUCT
PROD-QUANTITY
= 2
Run
unit 1
Run
unit 2OBTAIN
Holds SHARED
lock
OBTAIN
Holds SHARED
lock
MODIFY
Waits for
EXCLUSIVE
lock
MODIFY
Waits for
EXCLUSIVE
lock

§ Deadlocks can occur between multiple run-units and involve
multiple record types, record occurrences, or other resources
Record A Record B
Run
unit
1
Run
unit
2
Holds lockHolds lock
Waits for
lock
Waits for
lock

Locking Error Messages
§ When a deadlock condition occurs, a cluster of messages will
be written to the CV’s log
§ One DC001000 for each task involved in the locking
contention

Locking Error Messages (con’t)
§ Optionally DC001001 messages can be generated providing
additional information about the locking contention
– Generated when DEADLOCK_DETAILS=ON specified in the CV’s
SYSIDMS file
– Two lines per task
§ One line containing headers
§ Second line containing the actual data
§ A DC001002 message indicating the task that was aborted as
part of the deadlock resolution

Locking Error Messages (cont.)
DC001000 T:852690 APPC P:APXPO031 C:DEAD WAITING ON R:LTXNLOCK 00042009 00397442
DC001001 Txn/RU ID RU NAME SUBSC User ID FE - ID1 FE - ID2 FE - ID3 FE Tskcd
DC001001 451537594 APXPO031 APXSS100 ****
DC001000 T:852711 ADS2 P:APXD1476 C:DEAD WAITING ON R:LTXNLOCK 00052008 008BDB94
DC001001 Txn/RU ID RU NAME SUBSC User ID FE - ID1 FE - ID2 FE - ID3 FE Tskcd
DC001001 451537611 APXD1476 APXSS100 C087415
DC001002 T:852711 ADS2 P:APXD1476 C:DEAD DEADLOCKED ON R:LTXNLOCK 00052008 008BDB94
One group
per task
Abending task

§ Each DC001000 message represents a task that is a participant
in the deadlock and is waiting for a resource
§ The first 4 fields of the message provide:
– The task id of the waiting task
– The task code that invoked the task
– The program name that is being executed
– The status of the task

§ The last field following the literal ‘R:’ provides the resource
upon which the task is waiting
R: <Type><wwwwxxyy zzzzzzzz>
Type - LTXNLOCK Local transaction lock
GTXNLOCK Global transaction lock
PAGELOCK PAGELOCK
<wwwwxxyy zzzzzzzz>
<wwww> Page group
<xx> Code identifying the value in <zzzzzzzz>
‘00’ <zzzzzzzz> contains a dbkey (Record lock)
‘20’ <zzzzzzzz> contains a page number (Space Management lock)
‘80’ <zzzzzzzz> contains an area’s low page (Area lock)
‘C0’ <zzzzzzzz> contains an area’s low page (Transient lock)
‘01’ <zzzzzzzz> contains a page number (Page lock)
<yy> Dbkey radix

§ A DC001001 message provides further information to assist in
the description of the task described in the preceding
DC001000 message
– Transaction id
– Program name found in the SUBSCHEMA-CONTROL when the run-unit was
bound
– Subschema to which the run-unit is bound

§ One DC001001 message will be displayed for each run-unit
associated with the waiting task
§ A DC001002 message is generated to identify the task that
was aborted to resolve the deadlock
§ The contents of a DC001002 is the same as the associated
DC001000 but the specified resource can be interpreted as
the resource that was the final item completing the deadlock
scenario

Deadlock Analysis
§ It is extremely rare that the resolution of deadlocks can occur
by changing any system-level definitions within a CV
§ However if a CV is experiencing excessive deadlocks the CV’s
SYSGEN should be examined for the following statements
DEADLOCK DETECTION INTERVAL IS 1
TICKER INTERVAL IS 1
§ Specifying a value of ‘1’ for each of these options will ensure
that CA IDMS will search for and resolve deadlock conditions
as soon as possible

Deadlock Analysis (cont.)
§ In any environment that permits concurrent updating of the
database it is to be expected that deadlocks will occur
§ As transaction volume increases so does the likelihood that
points of contention will occur
§ Deadlock conditions are almost always the result of the
database design and timing issues associated with the way
the application navigates the database
§ Resolution will usually require database design and/or
application changes to reduce the point of contention

§ Start your deadlock analysis by scanning the DC001000 and
DC001002 messages looking for repeating values
§ If a single dbkey is present in a large percentage of the
deadlocks you have probably located a major point of
contention within the environment
§ The DC001000/DC001002 messages do not tell you the type
of record represented by the dbkey

§ Use the PRINT PAGE utility to print the specified page and to
identify the type of record involved
§ The DC001000 and DC001001 messages contain the program
and run-unit names that were processing the database at the
point of the deadlock

§ The following innocent looking code can result in serious
deadlock conditions which would be reflected by a repeating
dbkey in the associated deadlock messages
OBTAIN CALC ORDER-CTRL.
PERFORM IDMS-STATUS.
MOVE NEXT-ORD-NUM TO ORDER-NUMBER.
ADD +1 TO NEXT-ORD-NUM.
MODIFY ORDER-CTRL.

§ The ORDER-CTRL record is what is known as a One-Of–A-Kind
(OOAK) record
§ Every time that an order is added to the database it is
necessary to read the single ORDER-CTRL record to get the
next order number to be assigned and to modify the record

§ Large numbers of transactions concurrently adding orders can
generate excessive deadlock occurrences
§ One possible resolution would be to develop an alternate
method to generate an order number
§ Another option would be to single-thread this code using
ENQUEUE/DEQUEUE commands

§ The problem code in our example could be single-threaded as
seen below
ENQUEUE WAIT CTRL-LOCK LENGTH 8.
OBTAIN CALC ORDER-CTRL.
MOVE NEXT-ORD-NUM TO ORDER-NUMBER.
ADD +1 TO NEXT-ORD-NUM.
MODIFY ORDER-CTRL.
DEQUEUE CTRL-LOCK LENGTH 8.

§ In some scenarios the repeating resource may not represent a
dbkey but a page number
§ If the value of the <xx> portion of the DC001000 message is
x’20’ there is a contention attempting to manipulate the
amount of free space on the specified database page
§ Use the PAGE PRINT utility to list the specified page(s) to
determine the type of records that reside on the page
§ Use this information to identify the associated logic in the
programs specified on the DC001000 and DC001001 messages

§ Common causes of this type of lock contention are the
following
– Large volumes of records written to a single DC Queue using a PUT
QUEUE command
– Large numbers of records defined as DIRECT are added to an area
always using -1 as the suggested dbkey
– Many records always added to the same location within an index
§ Single-threading these functions or finding alternative
database structures is required to resolve these types of
contentions

§ If the value of the <xx> component of the DC001000 message
is an x’80’ you have contention on the usage mode of a
database area
§ Use the page group and page number to identify the area that
is involved
§ Inspect the programs specified on the DC001000 messages to
determine how they ready the area

§ The common problem in these cases is programs that attempt
to ready an area in a PROTECTED or EXCLUSIVE mode in an
environment where concurrent processing is occurring
§ Modify the affected programs to used a SHARED version of
the READY verb

§ In some scenarios the repeating value within the DC001000
and DC001001 may be a program or run-unit names
§ This is typically an indication that there is program logic within
these programs that causes contention in the sequence in
which various records are accessed
§ Identify the records and page numbers associated with the
DC001000 and DC001001 messages and use PRINT PAGE to
identify the types of records involved

§ Identify the most common sequence of DML commands
within each specified program and look for those points
where the various program logic intersects on the record
indicated on the deadlock messages
§ These types of scenarios are best addressed by application
staff that is familiar with the logic of the programs involved in
the deadlock

§ Resolution of these types of deadlocks depends on the
offending logic discovered and the requirements of the
application
§ These types of deadlocks tend to be sporadic and usually do
not generate large numbers of concurrent deadlock
occurrences

§ JREPORT 008 (Journal Detail Report) can be a useful resource
to assist in determining the sequence of DML commands in
these types of deadlocks
§ Limit your JREPORT 008 execution to those transaction
numbers listed on the associated DC001001 to minimize the
generated output
§ The report will show the DML commands and their affected
database records in the sequence they occur
– This will show you how the deadlock occurred

General Recommendations
§ Each deadlock scenario represents a unique set of conditions
but there are a number of considerations that should be
observed to minimize their occurrence
§ Avoid running batch updates during online windows
– Exclusive record locks are not released until IDMS is explicitly told to do
so through FINISH or COMMIT verbs
– Batch update run-units should include frequent COMMIT verbs to
periodically release locks
§ Minimize the amount of work performed by a single online
transaction

General Recommendations (cont.)
§ Avoid creating database ‘hotspots’
– Locate and eliminate single locations within the database that multiple
transactions must update concurrently
§ OOAK records
§ DIRECT records stored using a suggested dbkey of -1
§ A DC queue
§ Index structure where the same or very similar key value is always inserted

§ Avoid retaining resources across transactions or interactions
with a terminal operator
– Longterm locks can be held across transactions and can lock a dbkey
for long periods of time
§ Their usage should be used only when absolutely necessary
– Don’t use conversational tasks that keep update run-units open while
waiting for the terminal operator’s response

§ Stress test changes prior to production implementation
– Any modification that changes the sequence or volume of updates to
database records should be stress tested at the largest expected
volume of concurrent transactions
– Use a third party product for your stress test such a TPNS from IBM

Section Summary
§ Deadlock analysis is more of an art than a science which
requires the participation of a site’s application staff and not
just the Database Administrator
§ Although the DBA may do the initial analysis of the deadlock
messages generated by CA IDMS it will usually require the
application developer’s specialized knowledge of the
application code to interpret, identify, and correct any
underlying problems

CPU Savings Options with zIIP

Section Overview
§ A major enhancement introduced on Release 17 was the
ability of CA IDMS™ to exploit the IBM zIIP specialty engine on
the z System. Enhancements made on the currently
supported releases of IDMS, versions 18.5 and 19.0, have
significantly increased the amount of CPU cycles offloaded to
the zIIP specialty engines

Section Topics
§ Terms and definitions
§ Benefits
§ Operational considerations
§ zIIP exploitation
§ Implementing via CA IDMS startup parameters
§ Architecture changes
§ Eligibility and requirements
§ Evaluating benefit without a physical zIIP engine
§ Real World example of benefit offloading cycles

Terms and Definitions
§ Enclave
– An enclave is a representation
of a business transaction or
unit of work
§ TCO
– Total cost of ownership
§ White Space
– CP CPU cycles made available
by moving processing to a zIIP
processor
§ zIIP
– IBM System z Integrated
Information Processor
§ CP or GP
– General Purpose Processor
§ TCB
– Operating System Task Control
Block
§ SRB
– Operating System Service
Control Block

Benefits
§ Cost/benefit tradeoff
– Sites with zIIP capacity
– Sites nearing CP capacity
§ Cost to add a zIIP versus cost to add a CP
– Hardware (zIIP is less)
– Software licensing fees (zIIP is none)
§ Benefit of zIIP versus CP
– Depends on how much workload can be offloaded to zIIP

Benefits
§ Testing has shown benefits for all CA IDMS workloads and
environments
– CICS, CA ADS™, DC COBOL, CA IDMS™ Server, etc
– As well as varying mixtures of the above workloads and environment
– Best configuration, most CPU cycles offloaded, will be when an IDMS
system is used as a backend
§ CICS transactions, Server or Distributed transactions, Batch to CV work (CV
side only)

zIIP Exploitation
§ Why zIIPs?
– Less expensive than general purpose
processors
– No software charges for zIIP capacity
– Offloading cycles to zIIP frees cycles on
CP for additional work
§ Defer processor upgrades
§ Increase throughput
General
Purpose
Processor
near
100%
busy
General
Purpose
Processor
zIIP
Increase White Space on CPs

CA IDMS zIIP Exploitation
§ 100% CA IDMS system support
code is zIIP eligible
– Executes in SRB mode zIIPCP
CA IDMS Workload
TCB
mode
SRB
mode

Implementing via CA IDMS Startup Parameters
§ Controlled by startup
parameter
– Startup parameters
§ zIIP=Y
– Use the zIIP feature
§ zIIP=N
– Do not use the zIIP feature
– Default if zIIP parameter is
omitted
§ Impact on Existing Dialogs
and Programs: None!
– All existing dialogs, programs
of any language, will run in an
environment containing zIIP
processors without change or
impact
§ Other than an overall
reduction in CP CPU usage

Eligibility and Requirements
§ Loading of nucleus module, line drivers, service drivers,
RHDCUXIT, DB procedures must be from authorized libraries
§ Additional authorized libraries
§ Detailed messages for errors
IDMS DC016106 ZIIP=N forced. Module aaaaaaaa was loaded
from an unauthorized library
DDN=dddddddd VOLSER=vvvvvv DSN=dsname
§ Linklist and LPA assumed authorized unless coded in JCL

Eligibility and Requirements (con’t)
§ Rules for load module residence for zIIP
– Load module executed to start CA IDMS CV must reside in in an
authorized library
– CA IDMS nucleus modules must be loaded from an authorized library
– IBM LE library must be authorized and in the CDMSLIB concatenation
– z/OS Callable Services library must be in linklist or authorized and
included in STEPLIB
– DB procedures must reside in an authorized library

Eligibility and Requirements (con’t)
§ Individual nucleus members in a load library do not have to be
authorized
– Not every load library in CA IDMS startup STEPLIB/CDMSLIB needs to
be authorized
§ To ensure all nucleus modules are loaded from an authorized
library
– Authorize the SMP/E target load library or
– Maintain two separate but identical SMP/E target zones or
– Manually copy all modules in the SMP/E target load library to an
authorized library

Informational Messages
§ If zIIP processors are present and zIIP=NO is specified or taken
as the default
– Displayed on the JES log very early in the startup process
+IDMS DC016105 02 zIIP processors detected. You should consider using ZIIP=Y

Unitasking or Multitasking
§ zIIP feature works with both Unitasking and Multitasking
§ Unitasking
– 1 Enclave started for the single TCB (SCA) to be used
§ Multitasking
– 1 Enclave started for each TCB (SCA) to be used
§ Doesn’t depend upon the number of zIIPs installed
§ If 6 subtasks are started for multitasking and only 1 zIIP engine is available
on the machine, 6 enclaves are started

Architecture Changes
§ Majority of changes limited to the operating system
dependent module RHDCOESA
§ Routines to switch between TCB mode and SRB mode
– SRB mode required to run on a zIIP
– Limitations on what can run on a zIIP (in SRB mode)
§ Can’t do I/O or SVC functions for example
§ No “user mode” code
– CA ADS, COBOL, User written exits, DB procedures, etc
§ IDMSCOMP, IDMSDCOM, and Presspack do not swap and will run in SRB mode

Architecture Changes (con’t)
§ Most of the CA IDMS system code is eligible to run in SRB
mode and does
– Code which is not eligible to run in SRB mode calls routines in the
operating system dependent module and requests change to TCB
mode
– Requests a swap back to SRB mode once TCB mode work is complete
§ When “user mode” code is being executed
– The CA IDMS system ensures the user mode code is run in TCB mode
– When “user mode” code returns to System mode the
CA IDMS system will swap back to SRB mode

Evaluating Benefit Without a Physical zIIP Engine
§ Not recommended
– This is a change from earlier recommendations
– If you turn zIIP on (zIIP=Y JCL startup parm) and you do not have a zIIP
engine
§ IDMS will still attempt to swap from TCB mode to SRB mode and back
§ The results in additional CPU cycles to handle the swapping with no benefit

Evaluating Benefit Without a Physical zIIP Engine (con’t)
§ Best to estimate
– When IDMS is a Backend for a CICS Front-End
§ No online User programs like Cobol, ADS, etc
– Some sites have reported offloads of CPU cycles in the 70 to 90+ % range
§ Online User programs like Cobol, ADS, etc
– Will see a lower offload of CPU cycles due to swapping
– Still beneficial since all IDMS System Support CPU cycles are eligible for zIIP
offload
– Issue DCMT D STAT SYS
§ Look at Total SYSTEM CPU time

Real World example of benefit offloading cycles

Real World example of benefit offloading cycles (con’t)
R17.0 R18.0 RO63129
TCB as % of all CPU 25 50 02
SRB as % of all CPU 75 50 98
% of all CPU sent to zIIP 25 50 98
% of sent zIIP run on zIIP 88 100 100
Swaps/task 1 .5 1.4
TCB (charged) cpu/task 0.0006048 0.0003516 0.0000115

Real World example of benefit offloading cycles (con’t)
§ All production V17 CVs April 2009
§ $125K / year reduced software costs on V17
§ Multitasking works well with zIIPs
§ All production V18 CVs scheduled February 2012
§ $100K / year additional reduced software costs estimated
running V18

Section Summary
§ Terms and definitions
§ Benefits
§ Operational considerations
§ zIIP exploitation
§ Implementing via CA IDMS startup parameters
§ Architecture changes
§ Eligibility and requirements
§ Evaluating benefit without a physical zIIP engine
§ Real World example of benefit offloading cycles

Multi-Tasking in CA IDMS

Section Overview
§ This session focus is the CA IDMS Multitasking feature
available for MVS and MVS-like operating systems. Topics
covered include use, monitoring, and tuning.

Section Topics
§ What is Multitasking?
§ Considerations
§ Monitoring
§ Benefits and costs

What is Multitasking
§ Dispatching in a Unitasking system
§ Dispatching in a Multitasking system
§ Subtasks
§ Modes
§ RHDCMODE
§ CA IDMS components in MPMODE ANY

What is Multitasking (con’t)
§ Dispatching in a Unitasking system
CPU 0
TASK 3
#WAIT
TASK 1
TASK 2
#WAIT
CPU 1 CPU 2 CPU 3 CPU 4

§ Dispatching in a Multitasking system
TASK 6 #WAIT
TASK 7
TASK 3
TASK 10
TASK 8
#WAIT
TASK 1 TASK 2
#WAIT
TASK 4
#WAIT
TASK 9
TASK 5
#WAIT
CPU 0 CPU 1 CPU 2 CPU 3 CPU 4

§ Modes
– ANY
– DC
– DB
– USER
– LOADER
– DRIVER
– CALLER
§ RHDCMODE (Mode
Manager)
§ Multitasking is:
– Not CPU driven
– Driven by number of tasks
queued for System Services
(Queue Depth)

§ CA IDMS system components running in MPMODE=ANY
– Dispatcher
– Task-local functions
– Storage manager
– Scratch manager
– Database engine
– Security engine

Considerations
§ Application Programming
concerns
– Shared Storage
§ System Exits (RHDCUXIT)
§ Database Procedures
§ Considerations for the DBA
– Program definition statement
§ MPMODE is (ANY or SYSTEM)
§ Protect vs NoProtect
§ Program pool sizes
– Affinity (Subtask)
– Invoking
§ Freeform JCL parameter
– MT=Y,SUBT=n

Benefits and Costs
§ Increased throughput and a reduction in response time
§ The cost is a CPU increase that will vary from site to site
– Higher level of concurrence
– Handling of Multiple subtasks
– RHDCMODE

Section Summary
§ What is Multitasking?
§ Considerations
§ Monitoring
§ Benefits and costs

Parallel Sysplex Options

Section Overview
§ This section discusses the Parallel Sysplex features available
with CA IDMS. These features include Shared Cache, Data
Sharing, Dynamic Run unit routing, and CV cloning

Section Topics
§ Shared Cache
§ Data Sharing
§ Dynamic Database Session Routing
§ CV Cloning

Shared Cache Definition
§ Large, high-speed buffer in a Coupling Facility
§ Contains database pages from files assigned to the cache and
accessed by the CVs running in a Sysplex
§ Cornerstone of the Coupling Facility features
§ Used by Advantage™ CA IDMS®/DB Data Sharing to allow
multiple central versions to simultaneously update the same
physical database

Shared Cache Implementation
§ Define shared cache to the Coupling Facility
STRUCTURE NAME(IDMSSUPPCACHE002) SIZE(5120) PREFLIST(COUPLET1)

Shared Cache Implementation (con’t)
§ DMCL Definition
ALTER
DMCL R170DMCL
INCLUDE SEGMENT DBCR
DEFAULT SHARED CACHE IDMSSUPPCACHE002

Shared Cache Implementation (con’t)
§ DMCT VARY commands
DCMT VARY SEGMENT NAME SHARED CACHE NAME/NO
DCMT VARY FILE NAME SHARED CACHE NAME/NO
DCMT VARY AREA NAME SHARED CACHE NAME/NO
DCMT Vary SHAred CAche cache-name ON/OFf

Shared Cache Tuning and Monitoring
§ Tuning
– Increase shared cache size
– Define additional shared cache
§ Monitoring
– DCMT
– Advantage CA IDMS Database Performance Monitor Option
– SREPORTS

Data Sharing Definition
§ A data sharing group
– Named collection of Advantage CA IDMS/DB systems within a sysplex
– Each Advantage CA IDMS/DB system associated with a data sharing
group is referred to as a member of that group
§ Data sharing and data sharing groups are the mechanisms
that allow files to be open in update mode by all designated
central versions
§ Actual file data is maintained in the shared cache discussed
earlier

Data Sharing Implementation
§ Each data sharing group requires the definition of a list
structure and a lock structure in the Coupling Facility
§ One or more cache structures must be defined if the data
sharing group is to share update access to data
§ Definition in DMCL
– Default data sharing attribute
– Segment or file data sharing attribute

Data Sharing Implementation (con’t)
§ Actual list and lock structure definitions:
– STRUCTURE NAME(CAIDMSSUPPGRP1LI) SIZE(4096)
PREFLIST(COUPLET1)
– STRUCTURE NAME(CAIDMSSUPPGRP1LK) SIZE(5120)
PREFLIST(COUPLET1)
– Sizes are in K bytes

§ DMCL definition:
ALTER
DMCL R170DMCL
DATA SHARING DEFAULT SHARED CACHE IDMSSUPPCACHE002
LOCK ENTRIES 100000 MEMBERS 5
ON CONNECTIVITY LOSS NOABEND
INCLUDE SEGMENT DBCR
DATA SHARING YES
DEFAULT SHARED CACHE IDMSSUPPCACHE002

§ Each member of the data sharing group requires SYSIDMS
definition with:
– DSGROUP
– DCNAME
//SYSIDMS DD *
DSGROUP=SUPPGRP1
DCNAME=TECHD120

Data Sharing
§ System Managed Rebuild
– For planned reconfigurations of the Coupling Facility
§ System Managed Duplex Rebuild
– Provides Coupling Facility failure recovery capability
§ Monitoring
– DCMT commands
– Advantage CA IDMS Performance Monitor
– JREPORTS

Coupling Facility Structures
§ Advantage CA IDMS Visual DBA
– Modeling tool
– Uses CV’s DMCL definition
– Generates Coupling Facility-ready syntax for:
§ Cache, List, and Lock structures

Data Sharing Benefits
§ 24X7 processing
– Fault Tolerance
– System Maintenance
§ Scalability
– Additional CVs have update access to files
§ Workload balancing
– Additional update CVs can be started and stopped as needs change;
work may be processed by any CV defined in the data sharing group
§ Easy to implement and use

Dynamic Database Session - Routing Definition
§ Provides Workload balancing between Advantage CA IDMS/DB
systems running in the Sysplex.
§ Workload balancing is dynamic and based on actual system
load

Dynamic Database Session - Routing Implementation
§ DBGROUPs
§ Backend Definitions
– Add DBGROUP statement(s) to Database Name Table
– Use “CREATE DBGROUP” statements to assign the Backend(s) to a
DBGROUP(S)
CREATE DBGROUP R170DBTB.SPGROUP1 ENABLED

§ DBGROUPs
§ Frontend Definitions
– You must define the DBGROUP as a node within the SYSGEN
ADD NODE SPGROUP1 GROUP DEFAULT NODE TECHD120
– You can optionally map a DBNAME to a group by using the VIA “GROUP
NAME” parameter of the Resource Table statement within SYSGEN
MODIFY RESOURCE TABLE
DBNAME IS DBCR VIA SPGROUP1

§ Coupling Facility considerations
– Define a Coupling Facility structure for
each DBGroup defined to Advantage
CA IDMS/DB
– Prefix DBGroup name with "CAIDMS”
– Size is in K bytes
– Example:
STRUCTURE NAME(CAIDMSSPGROUP1) SIZE(512
PREFLIST(COUPLET1)

§ Work will be dynamically routed when one or both of the
following are true:
– The DBNODE used is defined as a group via the NODE statement of
SYSGEN
– The DBNAME used is defined in the Resource Table as a Group
§ The DBNAME and/or the DBNODE are set by
– The application
– Via a DCUF SET command
– Via EXIT23

TITLE 'EXIT 23 - PRE BIND EXIT‘
XIT23 #MOPT ENV=SYS,AMODE=31,RMODE=ANY
XIT23 CSECT
XIT23EP1 #START MPMODE=ANY
USING CSA,R10
L R2,4(,R1) 40 BYTE DATA AREA
USING PARMAREA,R2
CLC PSSCNAME(4),=CL4'DBCR' IS THIS FOR DBCR
BNE RETURN NO! JUST EXIT
MVC PDBNODE,=CL8'SPGROUP1' OVERRIDE DBNODE
*** MVC PDBNAME,=CL8'DBCR ' or OVERRIDE DBNAME
RETURN #RTN RETURN TO CALLER
LTORG

COPY #CSADS
PARMAREA DSECT
PSSCNAME DS CL8 SSC NAME
PDBNODE DS CL8 DATABASE NODE
PDBNAME DS CL8 DATABASE NAME
PDICNOD DS CL8 DICTIONARY NODE
PDICNAM DS CL8 DICTIONARY NAME
END

§ Monitoring
– DCMT commands
– LOOK
– Advantage CA IDMS Performance Monitor’s Interval Component (online
and Batch)

Dynamic Database Session – Routing Benefits
§ 24X7 processing
– Fault Tolerance
§ Scalability
– Additional CVs have update access to files when used with data sharing
§ Dynamic workload balancing
– Additional CVs can be started and stopped as needs change; work is
routed to other CVs defined in the DBGroup
§ Easy to implement and use

CV Cloning Definition
§ Allows you to start multiple CVs that are copies (clones) of an
existing Advantage CA IDMS/DB system
§ System definition and files
– Same physical entities as the system being cloned with a few exceptions

CV Cloning Naming Conventions
§ CV Number, DC System Number, VTAM APPLID, and System
Node Name for a CV must conform to specific naming
conventions
§ By adhering to these naming conventions,
Advantage CA IDMS/DB can implement clones without
generating multiple physical copies of a system definition

CV Cloning Naming Conventions (con’t)
§ DC system number must match CV number
§ Must be in range of 0 through 255
§ All VTAM Applids must follow the convention of xxxxxnnn
– xxxxx can be any five characters
– nnn is the sysgenned CV number and is overlaid at runtime with the
number determined during start up of the cloned CV

CV Cloning Naming Conventions (con’t)
§ Advantage CA IDMS/DB system node names must follow the
convention of yyyyynnn
– where the first five characters (i.e., yyyyy) can be any characters you
need to make the name unique within your environment
– nnn is the number specified for the CV at system generation
SYSGEN 17.0 ONLINE PAGE 1 LINE 1 DICT=SYSTEM
ADD SYSTEM 120
SYSTEM ID IS TECHD120
CVNUMBER IS 120
ADD LINE VTAM
APPLICATION ID IS A31II120

CV Cloning
§ Special File Requirements
– Each cloned CV requires its own copy of the following files:
DDLDCLOG, DDLDCSCR, DDLDCQUE, All Journals

CV Cloning (con’t)
§ Use the “CLON=“ and “CLONES= “ parameter in the JCL parm
for the IDMS system startup.
//R170DC99 EXEC PGM=IDMSDC99,REGION=0K,TIME=1440,
// PARM='S=110,CLON=Y,CLONES=9”
§ When used in a data sharing group, a clone may have update
access to all database files

Cloning Benefits
§ 24X7 processing
– Fault Tolerance
§ Scalability
– Additional CVs have update access to files when used with data sharing
§ Dynamic workload balancing
– Additional CVs can be started and stopped as needs change; work is
routed to other CVs defined in the DBGroup
§ Easy way to add additional CVs
§ No additional system definitions for the DBA to maintain

Section Summary
§ Shared Cache
§ Data Sharing
§ Dynamic Database Session Routing
§ CV Cloning

Recommended Sessions
SESSION # TITLE DATE/TIME
MFX100S Strategy and Vision for CA IDMS 11/16/2016 at 12:45 pm
MFX101S Legacy is not a Dirty Word 11/16/2016 at 1:45 pm
MFX102S CA IDMS 19.0 Web Services for Modernization 11/16/2016 at 3:00 pm
MFX103S CA IDMS 19.0 SQL Enhancements for Modernization 11/16/2016 at 3:30 pm
MFX104S Java Access to CA IDMS Data at BT (British Telecom) 11/16/2016 at 4:45 pm
MFX105S
Implementation and Use of Generic VTAM Resources
with Parallel SYSPLEX Features (CA and CAXIA)
11/17/2016 at 12:45 pm
MFX106S CA IDMS Buffer Tuning 11/17/2016 at 1:45 pm
MFX107S M3A Services Monitor, Measure, Manage and Alert 11/17/2016 at 3:00 pm
MFX108S Birds of a Feather/Stump the Techie! 11/17/2016 at 3:45 pm

Must See Demos
Demo Name
Product X
Theater # location
Demo Name
Services Y
Theater # location
Demo Name
Solution Y
Theater # location
Demo Name
Product X
Theater # location

Questions?

Thank you.
Stay connected at communities.ca.com

This presentation was based on current information and resource allocations as of May 2016 and is subject to change or withdrawal by CA at any time without notice.
Notwithstanding anything in this presentation to the contrary, this presentation shall not serve to (i) affect the rights and/or obligations of CA or its licensees under any
existing or future written license agreement or services agreement relating to any CA software product; or (ii) amend any product documentation or specifications for any
CA software product. The development, release and timing of any features or functionality described
in this presentation remain at CA’s sole discretion. Notwithstanding anything in this presentation to the contrary, upon the general availability of any future CA product
release referenced in this presentation, CA will make such release available (i)
for sale to new licensees of such product; and (ii) to existing licensees of such product on a when and if-available basis as part of CA maintenance and support, and in the
form of a regularly scheduled major product release. Such releases may be made available to current licensees of such product who are current subscribers to CA
maintenance and support on a when and
if-available basis. In the event of a conflict between the terms of this paragraph and any other information contained in this presentation, the terms of this paragraph shall
govern.
Certain information in this presentation may outline CA’s general product direction. All information in this presentation is for your informational purposes only and may
not be incorporated into any contract. CA assumes no responsibility for the accuracy or completeness of the information. To the extent permitted by applicable law, CA
provides this presentation “as is” without warranty of any kind, including without limitation, any implied warranties or merchantability, fitness for a particular purpose, or
non-infringement. In no event will CA be liable for any loss or damage, direct or indirect, from the use of this document, including, without limitation, lost profits, lost
investment, business interruption, goodwill, or lost data, even if CA is expressly advised in advance of the possibility of such damages. CA confidential and proprietary. No
unauthorized copying or distribution permitted.
FOR INFORMATION PURPOSES ONLY
Terms of this Presentation

CA IDMS Deadlock Analysis

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie CA IDMS Deadlock Analysis

Ähnlich wie CA IDMS Deadlock Analysis (20)

Mehr von CA Technologies

Mehr von CA Technologies (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

CA IDMS Deadlock Analysis