Application Tuning for CA Datacom Environments Part I

World®
’16
Application Tuning for CA
Datacom environments – Part I
Kevin Shuma, VP Product Management
CA Technologies
MFX67EA
MAINFRAME AND WORKLOAD AUTOMATION

2 © 2016 CA. ALL RIGHTS RESERVED.@CAWORLD #CAWORLD
Abstract
This is a two part session that describes the various techniques
used to tune a CA Datacom application for the best possible
performance. Included will be discussions on available
monitoring tools.
This session is primarily focused on the application developer
who is writing applications for the CA Datacom®/DB database.
Kevin Shuma
CA Technologies
VP, Product
Management

Agenda
THE APPLICATION ESTATE
THE APPLICATION ARCHITECTURE
WHY WOULD I NEED TO DO TUNING?
APPLICATION TUNING WITHOUT CHANGING THE APPLICATION
APPLICATION TUNING WITHOUT CHANGING THE APPLICATION
SUMMARY (FOR PART I)
1
2
3
4
5
6

The application estate
§ IT departments vary in size and scope
§ Application activity differs in each site
§ Application platforms vary
§ Programmer skills vary
§ So if everything is varying, what is consistent?
Understanding the typical CA Datacom application development environment

The “Real World” – Today’s Mainframe IT requirement
§ Reducing the TCO of the mainframe
– Doing more with less
– Every new "business benefit" application/change must be cost justified
§ Utilize existing staff and resourced to achieve this goal
The consistent theme

The “Real World” – Today’s environment
§ Major European retailer
– Datacom/Ideal/MetaCOBOL+ runs almost all mission critical systems
– 0.6 of a Datacom DBA (average 3 days per week)
– 6 mainframe developers
– Capped at 24 MSU’s (down from 37 MSUs in 2 years)
§ Financial institution
– Datacom/Ideal runs almost all mission critical applications
– 0.25 of a Technical Consultant (average 5 days per month)
– 3 mainframe developers
– Capped at 100 MIPS
Much smaller IT department – typically with very small DBA staffs

Where can we get the biggest bang for the buck
§ “From a product perspective, adding an enhancement that
improves the efficiency/productivity of application and
programmer can have a large positive impact on the business.
– Improvements to application performance results in
§ Improved productivity of end-users/operations staff
§ DevOps – The clue’s in the name!
§ Business growth. Employment.
§ Reduced Total Cost of Ownership (or perceived “overhead”) of the
mainframe”
Excerpt from a well-known CA Datacom consultant and DBA

Improving the efficiency/productivity of applications
§ Application Tuning includes
– Identifying and eliminating redundant/inefficient processing
– Eliminating unnecessary outages/resource conflicts
– Making full use of hardware/infrastructure changes
– Implementing enhancements that improve business productivity

The application architecture

The application architecture
§ RAAT – Record at a time
– Typically “very chatty” with the database
§ Many small requests and responses
– Batch does have GSETx commands for larger requests/responses
§ SAAT – Set at a time
– Typically “less chatty” with the database
§ Smaller number of requests with larger database processing requirements
– Used by Ideal, DQRY and SQL under the covers
Understanding the typical CA Datacom application environment - APIs

The application architecture (cont’d)
§ SQL – Standard Query Language
– Typically “less chatty” with the database
§ Smaller number of requests with larger database processing requirements
§ Request can include various data refinement processing
– Unique, Group by, Union, etc.
§ Uses SAAT at the data row retrieval method
§ All three APIs require a URT
Understanding the typical CA Datacom application environment - APIs

Batch address space
zOS
LPAR
• Start-up parameters
• Executing code
• Shared memory (buffers)
• Data spaces attached as needed
Database subsystem and PC Calls installed during CAS9 (CA Common Services) initiation
CXX
LXX
FXX
PXX
RXX
DD
0002
DDD
0015
SQL
0016
TTM
0017
CBS
0006
HEUR
1006
DST
1000
STA
1018
SNP
1019
DEL
1020
PRM
0004
ACCT
0005
HR
0001
OE
0010
DQ
0003
URT
User Program
Call DBNTRY
Call DBSQLE
User
DBIDs
Batch URT
• Needs to be loaded in the
address space (typical linked
with program)
• Provides the interface to the
MUF address space
• For RAAT/SAAT selects tables
to be accessed
• Can hold additional buffer area
for special GSETx commands
Interface
Batch Address SpaceMUF Address Space

CICS address space
zOS
LPAR
• Executing code
CXX
LXX
FXX
PXX
RXX
DD
0002
DDD
0015
SQL
0016
TTM
0017
CBS
0006
HEUR
1006
DST
1000
STA
1018
SNP
1019
DEL
1020
PRM
0004
ACCT
0005
HR
0001
OE
0010
DQ
0003
User Program
Call DBNTRY
Call DBSQLE
User
DBIDs
CICS Services
• Loads multi threaded interface to MUF
• Loads a pool of URTs for all CICS transactions
• For RAAT/SAAT selects tables to be accessed
• Default URT020 provided for SQL access
• Provides a set of CICS transactions to manage the
interface and URTs
URT URT
Interface
User Program
Call DBNTRY
Call DBSQLE
URT URT URT URT
Interface
CICS Address Space Batch Address SpaceMUF Address Space

Server address space
zOS
LPAR
• Executing code
CXX
LXX
FXX
PXX
RXX
DD
0002
DDD
0015
SQL
0016
TTM
0017
CBS
0006
HEUR
1006
DST
1000
STA
1018
SNP
1019
DEL
1020
PRM
0004
ACCT
0005
HR
0001
OE
0010
DQ
0003
User Program
Call DBNTRY
Call DBSQLE
User
DBIDs
Server
• Loads multi threaded interface to MUF
• Loads URT stub for basic support
• Provides a set of commands to manage the
interface
• Provides interactive SQL processor for
client ODBC/JDBC requests
URT URT
Interface
User Program
Call DBNTRY
Call DBSQLE
URT URT URT URT
Interface
CICS Address Space Batch Address SpaceMUF Address Space
Interface
URT
Interactive SQL
processor
ODBC/JDBC
Server client

Why would I need to do tuning?

Why would I need to do application tuning?
§ Back when they were written
– We were balancing CPU vs IO vs limited real storage
– DASD was expensive
– How much real storage did your mainframe have
§ How much does it have now?
– How much data did your application process
§ How much does it have now?
§ Bottom line
– The applications may not have changed but the environment surely has
My applications have not changed

Recent “game changer”
§ For zOS sites with zIIP processors
– 90%+ MUF CPU can be offloaded to zIIP
§ User application CPU cannot run on zIIP
– Per IBM license to use zIIP
§ Make use of opportunities to swap from application CPU
(expensive) to MUF CPU (inexpensive on zIIP)
IBM z Systems Integrated Information Processor (zIIP)

Application Tuning without changing the
application

Application Tuning without changing the application
§ Many application issues can be mitigated by adjusting the
database environment
§ Not every issue can be resolved this way
– In part II, we will discuss application specific corrections
§ This session will address ways to improve application
processing without changing the application code
What I spent a large part of my DBA career doing

As long as the geometry of the row does not change,
the applications will not need to be changed
§ Replacing physical IO with memory processing (DBA tuning)
– Increase the number of IXX, DXX and DATA buffers
– Consider using MRDF COVERED
§ Depending on processing a preload may help
– Change the data block size to 1/3 track or 1/2 track
§ Requires an adjustment of data buffer pools
– DATANO, DATANO2 or special DATA pools
§ Requires an outage (for now, coming soon TM24)
– If zIIP available
§ Implement compression using TA24

the applications will not need to be changed (cont’d)
§ Add keys to improve CBS/SQL efficiency
– Will add overhead on row adds and deletes
– Will only take affect without application change for SAAT or SQL
– Locate CBS or SQL requests that are building temp indexes
MUF EOJ, AUTOINFO,
AUTOCOLLECT,
ALL_INFO_REPORT
Accounting
Tables
MUF level CBS index statistics for totals Use accounting to capture specific jobs, transactions

the applications will not need to be changed (cont’d)
§ Remove unused keys (overhead on every add/delete)
– Will only take affect without application change for SAAT or SQL
– Locate keys that are not used
§ DST DIR_KEY (only shows stats since MUF startup)
SELECT DBID, TABLE_NAME, KEY_NAME, KEY_ID, NATIVE, MASTER, NIL, DIRECT,
KEY_LENGTH, CBS_IGNORE, USES_RAAT, USES_SAAT, USES_SQL
FROM SYSADM.DIR_KEY WHERE DBID > 19 AND DBID < 1000;

DBUTLTY tuning
§ Many batch application job streams include DBUTLTY jobs
– The faster DBUTLTY runs the faster the job stream completes
§ DBUTLTY functions like DEFRAG and OLREORG can
significantly improve performance of applications
Utility processing can affect application performance

DBUTLTY tuning (cont’d)
§ REGION=0M on JCL EXEC in z/OS
§ Large partition (50M) in z/VSE
§ Master list IXX/DXX/Data buffers (especially in z/VSE)
§ Half-track blocking for Data Areas
§ Area level controls
– Eliminate negative dependencies
– Sometimes appropriate, sometimes not

§ BLKSIZE=nnnnn for BACKUP/EXTRACT (z/VSE or non-SMS)
§ LOAD/RETIX parameters
– KBYTES=9999
– OPTIMIZE=YES
– OPTION1=‘(I)’ and review sort messages
– SORT=#indexentries (SORT=1 for z/VSE)
– SORTDFT (new in 14.0 – great if used wisely)

§ Replace most RETIX with DEFRAG
– DEFRAG is online activity and is often faster
– Use FIRSTKEY/LASTKEY on EXTRACT where appropriate
§ INIT IXX OLDEP=NO
§ DBIN1PR / SYSIN1ST to apply default/overrides
– New DEFAULT/FORCE options planned for 15.1
§ DBUTLTY tuning saved several elapsed hours from many jobs
– Simple changes 1hr+ saved from overall batch critical path

§ Stop performing unnecessary reorgs
– Truly random processing will not benefit from reorg
– New DATANE report shows Native Sequence Efficiency
– History database shows sequential activity
§ Reorg Options
– Traditional BACKUP SEQ=NATIVE + LOAD
§ Consider area-level controls if only a minority of areas need reorg
§ If reorganising whole database, use database-level BACKUP + INIT IXX +
database-level LOAD

§ Parallel REORG – still an outage required, but quicker
– Backup only option for quicker backups
§ OLREORG
– REFGROUP = nn
– REFGROUP=0
§ Currently planned for V15.1
– TM24
§ Consider partitioning where appropriate to minimize reorg effort

Changing the physical database structure
§ Split up data areas that have 2 or more heavily used tables
§ Split up large databases that have multiple tables
– URT option for DBID remapping
– Improves backup/load/reorg/recovery processing
– Multiple DBIDs = Multiple (smaller) indexes
§ Reduced levels of index
§ More opportunities to use MRDF covering
Requires an outage to implement

Changing the physical database structure (cont’d)
§ Split up large tables using table partitioning
– Existing applications run unchanged at logical (parent) level
– Better backup/load/reorg/recovery options with multiple areas
– More possibilities for MRDF covering
§ Busier partitions can be covered
– New options for application processing at partition (child) level
Requires an outage to implement

@CAWORLD #CAWORLD © 2016 CA. All RIGHTS RESERVED.31 @CAWORLD #CAWORLD © 2016 CA. All RIGHTS RESERVED.31
Mainframe and Workload Automation
For more information on Mainframe and Workload Automation,
please visit: http://cainc.to/9GQ2JI

Recommended Sessions
SESSION # TITLE DATE/TIME
MFX92S Strategy and Vision for CA Datacom and CA Ideal 11/16/2016 at 12:45 pm
MFX93S What’s new in CA Datacom 11/16/2016 at 1:45 pm
MFX94S Reducing TCO with Datacom Compression (Presspack) 11/16/2016 at 3:00 pm
MFX95SA Modernizing the CA Datacom data – SQL Access Part I 11/16/2016 at 3:45 pm
MFX95SB Modernizing the CA Datacom data – SQL Access Part II 11/16/2016 at 4:30 pm
MFX96S CA Datacom/AD Installation/Upgrade and Maintenance 11/17/2016 at 12:45 pm
MFX97S
CA Datacom/AD Report Utilization, and
information gather for Support
11/17/2016 at 1:45 pm
MFX98S
Using Sysview to monitor and measure your CA Datacom
environment – AD and DB
11/17/2016 at 3:00 pm
MFX99S Birds of a Feather/Stump the Techie! 11/17/2016 at 3:45 pm

Questions?

Thank you.
Stay connected at communities.ca.com

© 2016 CA. All rights reserved. All trademarks referenced herein belong to their respective companies.
The content provided in this CA World 2016 presentation is intended for informational purposes only and does not form any type of
warranty. The information provided by a CA partner and/or CA customer has not been reviewed for accuracy by CA.
For Informational Purposes Only
Terms of this Presentation

Application Tuning for CA Datacom Environments Part I

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (12)

Semelhante a Application Tuning for CA Datacom Environments Part I

Semelhante a Application Tuning for CA Datacom Environments Part I (20)

Mais de CA Technologies

Mais de CA Technologies (20)

Último

Último (20)

Application Tuning for CA Datacom Environments Part I