Data sharing at KBC

1
Data sharing at KBC

• GSE IMS/DB2
• 28/03/2002

2
Availability in 1998

• Bankoffice
• Working day 9u 16u
• Saturday 9u 12u
• Batch work
• Working day 17u 24u
• ATM Homebanking
• Daily 7u 24u
• Customer satisfaction ???
• Commercial opportunity !?

3
Availability target

• Management target
• 24h/7d availability for ATM
• Technical target
• Maximum availability for ATM

4
Avalability defects

• Planned system outages
• Software maintenance system
• SW upgrades, fixes, IPL,backups, ..
• Hardware maintenance
• Unplanned defects
• HW defects
• SW abends
• Application outages
• Software maintenance
• Database reorganisation

5
Approach

• Cope with planned outages
• Tackle unplanned defects
• What about application outages ?
• Lets bundle them !

6
WWW Where Were We?
branch
HQ
ATM
VTAM
IMSa
DB2a
db
ts
7
Availability in 1999

• Architectural single points of failure
• CPU
• OS/390
• IMS
• DB2
• Strong link between ATM and Office applications
  data
• Go and multiply thyself

8
Multiply thyself
branch
ATM
HQ
Mvsa
Mvsb
IMSa
DB2a
IMS2
DB22
IMS1
DB21
9
IMS/DB2 data sharing
branch
ATM
HQ
Mvsa
Mvsb
IMSa
DB2a
IMS2
DB22
IMS1
DB21
db
ts
CF
10
Shared data

• Sharing IMS databases
• IMS parallel sysplex data sharing
• Sharing DB2 tables
• DB2 parallel sysplex data sharing

11
Data sharing implementation

• Inventarise current environment (1Q/1998)
• check SW/HW requirements
• monitor locking/deadlock stats
• usermods, exits
• system affinities
• Describe architecture
• scope of project
• define configuration HW, SW, Network..
• define migation strategy
• Set up time planning
• Naming conventions
• Review system parameters/pools ims, db2, irlm
• Define CF structures

12
Data sharing implementation

• Review operational procedures
• startup/shutdown
• system failure
• data recovery / reorg
• disaster recovery planning
• monitoring tuning
• ..
• Test environment
• 1Q/1998
• IVP
• operational procedures
• third party products
• fall back

13
Data sharing implementation

• Acceptance environment
• Stress testing (3Q/1998)
• data sharing overhead
• locking conflicts
• Development environment
• Production environment
• 2Q/2000

14
IMS access

• Sharing IMS databases
• IMS parallel sysplex data sharing
• Sharing DB2 tables
• DB2 parallel sysplex data sharing
• Transparent access to IMS ???

15
IMS/DB2 data sharing
branch
ATM
HQ
Mvsa
Mvsb
IMSa
DB2a
IMS2
DB22
IMS1
DB21
db
ts
CF
16
IMS access VGRN
branch
ATM
HQ
Mvsa
Mvsb
VTAM GRN
VTAM
IMSa
DB2a
IMS2
DB22
IMS1
DB21
db
ts
CF
17
IMS message Queues

• Sharing IMS databases
• IMS parallel sysplex data sharing
• Sharing DB2 tables
• DB2 parallel sysplex data sharing
• Transparent access to IMS
• Vtam Generic Resource Names
• Sharing IMS message queues
• IMS shared message queues !?
• too much new technology, too less time

18
Whats new?

• Sharing IMS databases
• IMS parallel sysplex data sharing
• Sharing DB2 tables
• DB2 parallel sysplex data sharing
• Transparent access to IMS
• Vtam Generic Resource Names
• Sharing IMS message queues
• IMS shared message queues !?
• Oops too much new technology, too less time

19
Switch connections

• No IMS message queue sharing
• We need to switch the terminal CONNECTIONS !

20
Switch connections
Mvsa
VTAM GRN
IMS1
DB21
21
Switch connections
Mvsa
VTAM GRN
IMS1
DB21
22
Switch connections
Mvsa
VTAM GRN
IMS2
DB22
IMS1
DB21
23
Switch connections
Mvsa
VTAM GRN
IMS2
DB22
IMS1
DB21
24
Switch connections
Mvsa
VTAM GRN
IMS2
DB22
IMS1
DB21
25
Switch connections
Reconnect
Mvsa
VTAM GRN
IMS2
DB22
IMS1
DB21
26
Switch connections
Mvsa
VTAM GRN
IMS2
DB22
IMS1
DB21
27
Switch connections
Mvsa
VTAM GRN
IMS2
DB22
IMS1
DB21
28
Switch connections
Mvsa
VTAM GRN
IMS2
DB22
IMS1
DB21
29
Switch connections
Mvsa
VTAM GRN
IMS2
DB22
30
Switch procedure

• Switch procedure copes with
• Operator interface
• ATM interface
• VGRN configuration
• Status critical IMS transactions
• Status IMS message queue
• Switch external links
• DEP
• Banksys, NBB, ..
• Follow-up ATMs
• Force , Fall back

31
Wrap-up
branch
HQ
ATM
Mvsa
Mvsb
VTAM GRN
VTAM
IMSa
DB2a
IMS2
DB22
IMS1
DB21
db
ts
CF
32
WaW Where are We?

• IMS data sharing
• DB2 data sharing
• VTAM Generic Resource Names
• Switch procedure
• IMS Concurrent Image Copy
• DB2 COPY sharelevel change
• IMS database analysers
• Operational procedures
• Application review
• Data sharing best pratices
• Review most critical/volume applications

33
Availablility

• System availability
• 24h/7d
• for planned outages
• Application availability
• 1 outage window / (2) month(s)
• Saturday 22h-7h

34
EUR

• IMS data sharing 45 mw
• DB2 data sharing 35 mw
• VTAM GRN 2 mw
• Switch 110 mw
• IMS/DB2 data backup/reorg 35 mw
• Operational procedures 20 mw

35
Extention KBC Online
HQ
branch
ATM
KBC Online
Mvsa
Mvsb
VTAM GRN
VTAM
IMSa
DB2a
IMS2
DB22
IMS1
DB21
db
ts
CF
36
Extention Isabel
Isabel
branch
HQ
ATM
KBC Online
VTAM GRN
TCP/IP-MQS
Mvsa
Mvsb
VTAM
IMSa
DB2a
IMS2
DB22
IMS1
DB21
db
ts
CF
37
Next implementation ?

• Head office
• Branch offices
• Other (external) links

38
But..

• IMS terminal affinities
• Response, conversation mode
• SLUP, ISC, APPC, OTMA,
• Remaining input/output messages
• Switch procedure gets very complicated
• Not covered
• Unplanned outages (HW defects, SW abends)
• Load balancing
• WWW-connections TCP/IP, ICON, OTMA

39
Future planning

• MQ Series V5.3 2Q/2003
• Persistent messages
• MQ shared queues 2Q/2003
• IMS V8 4Q/2003
• Sharing sync. OTMA messages
• IMS shared message queues 2Q/2004
• Maximum transparent availability
• Planned outages
• Unplanned defects

40
Future planning
Virtual I/P adresses
TCP/IP
TCP/IP
icon
mqs
icon
mqs
mqs
icon
otma ims
db2
otma ims
db2
otma ims
db2
Shared queues
db
ts
41
Performance topics

• In general, an application designed for high
  concurrency in a single IMS/DB2 also works well
  in a shared environment.
• Conversely, an application with contention
  problems in a single IMS/DB2 is in a worse
  situation in the shared environment.

42
Performance topics

• Performance overhead
• theory
• CPU 15
• elapsed 0.1 sec
• stress test
• CPU ----
• elapsed 0.15 sec
• production
• CPU ----
• elapsed ----

43
Performance topics

• Whats the real overhead ?
• applications keep on changing .
• volumes keep on growing .
• Example IMS logging application
• Logging of input/output messsages
• Partitoned tablespace
• Lockpart yes
• Member cluster
• Trackmod no
• 1 partitioned Index
• 1 member 1000 ISRT/sec
• 2 members 500 ISRT/sec

44
DB2 design guidelines

• Control global locking rate
• Use TYPE 2 indices
• Use LOCKSIZE PAGE
• Consider UR isolation for Query
• Use CS isolation for all other applications
• Consider CURRENTDATA(NO) for all CS applications
• Bind with RELEASE(DEALLOCATE)
• Commit frequently

45
DB2 design guidelines

• Control global lock contention rate
• Tune to reduce elapsed time of unit of work
• Delay updates until just before commit
• Consistent order of Table references/updates
• Carefully consider LOCKSIZE ROW
• Increase PCTFREE
• Commit frequently

46
IMS design guidelines

• Small databases with few records
• can lead to an inability to share
• one record per block
• Ascending or descending keys
• control segment hot spot
• contention between updaters
• Size of database record
• HIDAM Root segments with pointers
• PTRNOTWIN
• ISRT into empty HIDAM
• scattered roots before mass ISRT

47
IMS design guidelines

• Minimize access to space bit map
• frequent reorganizations
• General tuning at Block or CI level
• reduce size of block/CI
• increase amount of free space
• Lowering the share level of a database when
  possible
• Consider not sharing some databases

48
IMS database access

• PSB options
• do not specify update PROCOPT if you only need
  read
• PROCOPTGOx
• give it a consideration
• PROCOPTE
• only effective within 1 subsystem
• Use of multiple PCBs
• Avoidance of long locks
• Dealing with unavailable data
• retained lock results in U3303
• unless INIT STATUS GROUPx