IMS Parallel Sysplex Best Practices

21
IBM Software Group © 2009 IBM Corporation IMS Parallel Sysplex Best Practices Dave Viguers IMS Performance [email protected] IMS User Group March 30,2010

Transcript of IMS Parallel Sysplex Best Practices

Page 1: IMS Parallel Sysplex Best Practices

IBM Software Group

© 2009 IBM Corporation

IMS Parallel Sysplex Best Practices

Dave Viguers

IMS Performance

[email protected]

IMS User Group

March 30,2010

Page 2: IMS Parallel Sysplex Best Practices

2

Session description

This session will deal with what are considered to be best practices for

running IMS in a parallel sysplex environment. All aspects of IMS will be

discussed including DBRC, IMS database and data sharing, Shared

queues, RRS, and other sysplex functions used by IMS.

Page 3: IMS Parallel Sysplex Best Practices

3

Presenter disclaimer

• The best practices discussed in this session have been contributed and reviewed by many people with IMS skills, both IBM and customers, HOWEVER there are always situations where these recommendations may not be the best for your particular environment. Always keep in mind that these are guidelines and not absolutes.

• There are many other best practices in addition to the ones covered in this session. This session will deal primarily with parallel sysplex.

Page 4: IMS Parallel Sysplex Best Practices

4

DBRC considerations

• Allocate each RECON data set with different sizes• The spare should be the largest

• Convert the hardware RESERVE to GRS enqueue• Eliminate any problem should a RECON be moved to a different volume

• Place each RECON on a separate volume along with catalog• May not be necessary if convert is done however• Avoid what might happen if the conversion list got modified or deleted

• Implement Recon Loss Notification• Prevent delays at some critical time

• Consider Parallel Recon Access.• Can reduce contention and improve thruput for large requests• But uses Transactional VSAM

• Requires careful planning and tuning

Page 5: IMS Parallel Sysplex Best Practices

5

Databases

• Consider Fast Path MADS for critical databases• Up to 7 copies on separate volumes on separate controllers possible

• Fast Path Data Entry Databases• Even without MADS• Multiple AREAS to limit unavailable data• Reduced recovery time

• HALDB• Multiple partitions to limit unavailable data• Reduced recovery time

• Review internal database definitions• RAP’s, RAA, Randomizing routines, Pointer options

• Too much to discuss here

Page 6: IMS Parallel Sysplex Best Practices

6

Database Cache Structures

• VSAM – directory only structure• Make large enough to avoid directory reclaims• Use CFSIZER tool on the web

• OSAM – directory only structure• Avoid directory reclaims also

• OSAM – with data caching• Use selectively if at all• Product publications and redbooks for options and considerations

• FP VSO structures• Preload and non preload• May improve access times which can reduce transaction time

Page 7: IMS Parallel Sysplex Best Practices

7

Cache structure considerations

• Duplex FP VSO structures• IMS duplexing performs best• Avoid loss of structure causing recovery being needed

• Specify INITSIZE and SIZE for all cache structures• Allows size to be adjusted if necessary

• Specify MINSIZE equal to INITSIZE if using AUTOALTER

• Monitor the structures to insure no directory reclaims• Look for CASTOUTS in the RMF CF structure activity report

Page 8: IMS Parallel Sysplex Best Practices

8

IRLM (1)

• Set MAXUSRS no larger than necessary• Maximum IRLM’s expected in data sharing group• Minimize size of each lock table entry

• 2, 4, or 8 bytes depending on setting• 1-7 = 2 bytes, 8-23=4 bytes, 24+ = 8 bytes

• Maximizes hash table size which keeps false contention low

• Set DEADLOK value low• 1 second or less for production

• IRLMNM• Consider making the same for all IRLM’s• Allows IMS to connect to any IRLM on any LPAR

• Do not specify LOCKTABL in IRLM procedure• Use CFNAMES in DFSVSMxx

Page 9: IMS Parallel Sysplex Best Practices

9

IRLM (2)

• SCOPE NODISCON if running batch datasharing jobs• If online IMS not active then avoids structure connect/disconnect

• PC=YES• Only value used with IRLM 2.2

• Avoid LTE= value• Default is ½ the structure size for hash entries• Might give undesired results if structure size altered

• Set LOCK structure size to power of 2• IRLM will adjust LTE’s down to power of 2 after dividing structure in half

• Specify MINSIZE, INITSIZE, and SIZE• Allow for possible ALTER

• Carefully consider system managed duplexing• Only use if necessary for availability

Page 10: IMS Parallel Sysplex Best Practices

10

MISCELLANEOUS DB related

• DFSVSMXX• Use same member if clones

• Avoids oversights if multiple members and changes being made• New member could be used to verify changes

• FDBR• Be sure it runs on separate LPAR• Preferably also a separate physical machine

• FDBR PSB pool sizes the same or larger than active IMS

• Set LOCKTIME with IRLM command or DFSVSMxx• Default of 300 seconds is too high• Monitor for DXR162I – Long lock timeout

Page 11: IMS Parallel Sysplex Best Practices

11

Applications

• Review PROCOPT settings• Many applications use A when only G is needed• Avoid lock contention when possible

• Watch for ‘CONTROL’ type databases • Avoid single segment updates by parallel applications

• Avoid calls outside of IMS• Especially when holding locks

• Could be IMS or DB2• Like APPC, MQ, Sync callout

Page 12: IMS Parallel Sysplex Best Practices

12

Shared Queues

• Automate CQS System Checkpoints• SYSCHKPT value can not be changed dynamically• SYSCHKPT value is for each CQS

• A failing CQS must read records created by all CQS’s• Using DS8000 DASD, CQS can read about 56,000 records per second

• Automate CQS Structure Checkpoints• No IMS defined way to cause these• Affects structure recovery time if necessary

• Stagger EMH and FF structure checkpoints if using both• Minimize delays

• Place SRDS’s on separate volumes and paths if possible• Avoid single point of failure

• Use MSGBASED processing for CFRM CDS• Minimize time to quiesce and resume at checkpoint

Page 13: IMS Parallel Sysplex Best Practices

13

Shared Queues Structures

• Specify both SIZE and INITSIZE• Facilitate structure alter

• Allocate Overflow structure larger than primary• In case one or two queue names filling the primary

• Specify correct OBJAVGSZ• Determines entry to element ratio• CQS monitors only elements for overflow• 1:1 if in doubt

• Use AUTOALTER • XES can dynamically adjust ratio• Specify MINSIZE to prevent XES from reducing size

Page 14: IMS Parallel Sysplex Best Practices

14

CQS and the MVS logger (1)

• Use external CF’s to avoid use of Staging Data Sets• Might need staging for D.R. however

• If using staging data sets allocate enough space• Much larger than structure • Either one reaching threshold causes offload

• Set structure size and full threshold carefully• Try to allow time to react if offload should fail

• Set offload data set size large• Reduce allocations for new data sets• Takes longer than just offloading to existing

• Set LOWOFFLOAD value to 0• For CQS logging it makes no sense to do otherwise

Page 15: IMS Parallel Sysplex Best Practices

15

CQS and the MVS logger (2)

• Set HIGHLOWOFFLOAD value to 50 – 60%• You never want to reach full • Some time should offload fail

• Set MAXBUFSIZE to 65276• Largest size to use 256 byte elements• Minimize wasted space

• Specify ALLOWAUTOALT(NO) for logger str.• Logger monitors and will alter if necessary

• Use separate structures for FF and FP logstreams• Different characteristics

• Use IXGRPT to monitor• Redbook on MVS Logger (SG24-6898)

Page 16: IMS Parallel Sysplex Best Practices

16

SMQ false scheduling

• Use PWFI and dedicated regions for high volume transactions• Avoids scheduling – real and false• IMS algorithm tends to keep more transactions local

• Use PARLIM of 2 or more if possible• Avoids local false schedules in V10 and below• V11 enhanced to handle 0 and 1 better

• CFCC 16• z/10• Notify change to reduce global false schedules

Page 17: IMS Parallel Sysplex Best Practices

17

RRS

• Disable RRS archive logstream• SETRRS ARCHIVELOGGING,DISABLE

• z/OS 1.10 otherwise shut down and delete archive log

• Use commit mode 0• Avoids RRS cascaded transaction support

• Allocate RRS Delayed structure to avoid offload• UOW’s are deleted when no longer needed• Use IXGRPT to monitor

Page 18: IMS Parallel Sysplex Best Practices

18

IMS Connectivity

• Set HWSHWS00 as non-swappable in PPT• If not then response times could vary widely

• Specify to IMS connect a DATASTORE for each IMS• Allow for routing to multiple IMS subsystems• Workload balancing and availability

• Set TCPNODELAY=ENABLE and NODELAYACK for TCP/IP• Minimize delays with TCP/IP

• Use VTAM generic resources for SNA • Workload balancing and availability

• Use IMS RM with STM • End user availability especially with conversations

• Exercise care with DRA (DFSPZPxx) resources• Adding new connections can have multiplication effect

Page 19: IMS Parallel Sysplex Best Practices

19

Miscellaneous

• Be aware of CF microcode updates• Use CFSIZER web tool prior to any upgrades• Usable structure size may be impacted

• DASD mirroring• Both synchronous and asynchronous can impact response times• WADS tend to be especially critical• RRS and CQS logger staging data sets also

• Workload Manager with IMS• Keep simple – avoid going lower than IMS transaction class• Set server address spaces high

• IRLM, DBRC, CTL, DL/I, CQS

Page 20: IMS Parallel Sysplex Best Practices

20

Summary

• Tried to hit the main best practices• Health checks good for looking at YOUR

environment

• Primarily sysplex related• Redbook due out soon with more details

• Many more for specific components• IEFUTL to prevent S322 & S522•And related U0113

• IEFUSO to prevent S722• And many more

Page 21: IMS Parallel Sysplex Best Practices

21

Dave Viguers

Dave Viguers

IBM

[email protected]