Mainframe Performance Guidelines

Mainframe Practice - BFSI Mainframe Performance Guidelines.
doc
Mainframe
Performance Guidelines
Prepared By :
Mainframe Practice - BFSI
Wipro Technologies Confidential 05/02/2008 Page 1 of 23

Mainframe Practice - BFSI Mainframe Performance Guidelines.doc
Document Control
Version History
Changed
Version Date Nature of amendment
by
Mainframe
0.1 13 Sep 2007 Initial Draft
practices

Table of Contents
1 INTRODUCTION...........................................................................................................................4
1.1 OBJECTIVE .................................................................................................................................4
1.2 SCOPE ........................................................................................................................................4
2 COBOL GUIDELINES...................................................................................................................5
2.1 GENERAL GUIDELINES ................................................................................................................5
2.2 PERFORMANCE GUIDELINES ........................................................................................................5
3 CICS PERFORMANCE GUIDELINES....................................................................................... 10
3.1 GENERAL GUIDELINES .............................................................................................................. 10
3.2 PERFORMANCE GUIDELINES...................................................................................................... 11
4 DB2 GUIDELINES ....................................................................................................................... 14
4.2 PERFORMANCE GUIDELINES...................................................................................................... 15
5 IMS GUIDELINES ....................................................................................................................... 20
5.2 PERFORMANCE GUIDELINES ...................................................................................................... 21
6 JCL GUIDELINES ....................................................................................................................... 22
6.2 PERFORMANCE GUIDELINES ...................................................................................................... 23

1 Introduction
1.1 Objective
There is no comprehensive document on performance guidelines. The intention of this
document is to list down a comprehensive set of guidelines that could be adopted by
various accounts with minimal customization. This will ensure consistency across the
vertical. In the absence of any client specific guidelines, the guidelines described in this
document could be implemented as it is. In cases, where client specific guidelines are
present, the guidelines described in this document could be implemented based on client
consent.
This document is prepared by BFSI Mainframe Practice.
1.2 Scope
The scope of this document is to outline performance standards for COBOL, CICS, JCL,
DB2 and IMS. The document also mentions a set of good practices / guidelines, which
are effective in enhancing an application program’s performance and efficiency.
In the current version of the document, following are in scope:
• COBOL
• CICS
• IMS/DB
• JCL/PROC
• DB2
Also, following are not in scope of this document:
• IMS/DC
• Assembler
• REXX
• PLI

2 COBOL Guidelines
2.1 General guidelines
• Use the ‘=’ sign rather than EQUAL in IF-statement.
• In a paragraph, only one functionality should be coded.
• Structured approach should be followed for coding the program.
• In use of relational operators, at least one blank character should precede and follow
the operator.
• Variable names or verbs should not be broken when continuing a statement.
• Use consistently Either ZEROS or ZERO and not both of them.
• Use the reserve words SPACE(S) in VALUE clauses instead of ‘ ‘.
• Use the reserve words ZERO(S) in VALUE clauses instead of 0
2.2 Performance guidelines
• Linear Search (SEARCH) is fast if the amounts of search operations are lesser,
Binary search (SEARCH ALL) is used if the amounts of search operations are more.
• For efficiency, put frequently accessed items at the beginning of the TABLE for
sequential searches
• Comparison using Equals (=) is faster than comparison using NOT EQUALS (^=)
• In Evaluate statement, put the conditions that are most likely to occur as the first
condition.
• Usage of performs: PERFORM Paragraph compiler converts up to 6 machine
instructions and PERFORMs with VARYING will require many more machine
instructions. It will be a problem if the code is executed millions of times.
Maintainability with speed need to be considered while using them.
• QSAM: Large block size should be used by using block contains clause in File
Section. Best practice is to allow system to decide the optimal block size by
specifying “Block Contains 0 “clause for creating any new files and omitting BLKSIZE
option in JCL. This should significantly improve file processing time (Both CPU time
and elapsed time)
• Increasing the number of I/O buffers for heavy I/O jobs can improve both the CPU
and elapsed time performance, at the expense of using more storage. This can be
accomplished by using the BUFNO sub parameter of the DCB parameter in the JCL
or by using the RESERVE clause of the SELECT statement in the FILE-CONTROL
paragraph
• When writing to variable-length blocked sequential files, use the APPLY WRITE-
ONLY clause for the file or use the AWO compiler option. This reduces the number of
calls to Data Management Services to handle the I/Os.
• When using VSAM files, increase the number of data buffers (BUFND) for sequential
access or index buffers (BUFNI) for random access. Also, select a control interval
size (CISZ) that is appropriate for the application. A smaller CISZ results in faster

retrieval for random processing at the expense of inserts whereas a larger CISZ is
more efficient for sequential processing. In general, using large CI and buffer space
VSAM parameters may help to improve the performance of the application.
• For VSAM; ACCESS IS DYNAMIC is optimal when reading one record in a random
order and then reading several subsequent records sequentially. VSAM may pre
fetch multiple tracks of data when using ACCESS IS DYNAMIC.
• In general, sequential access is the most efficient, dynamic access the next, and
random access is the least efficient. However, for relative record VSAM
(ORGANIZATION IS RELATIVE), using ACCESS IS DYNAMIC when reading each
record in a random order can be slower than using ACCESS IS RANDOM,
• Random access results in an increase in I/O activity because VSAM must access the
index for each request. If you use alternate indexes, it is more efficient to use the
Access Method Services to build them than to use the AIXBLD run-time option. Avoid
using multiple alternate indexes when possible since updates will have to be applied
through the primary paths and reflected through the multiple alternate paths.
• To get the best performance from arithmetic statements always use the simplest
forms. Use simple two-operand arithmetic statements wherever possible.
• Use Proper USAGE clause for the numeric items, like for counters use COMP, for
arithmetic calculations use COMP-3, this will be used for optimization – both speed
and storage...
• Use COMP or COMP-3 declarations when handling files, this helps save space.
• Use SYNCHRONIZED clause which is used to optimize the speed of processing, but
it does so at the expense of storage. When using binary (COMP) data items, the use
of the SYNCHRONIZED clause specifies that the binary data items will be properly
aligned on half word, full word, or double word boundaries. This may enhance the
performance of certain operations on some machines. Additionally, using signed data
items with eight or fewer digits produces the best code for binary items.
• The following shows the performance considerations (from most efficient to least
efficient) for the number of digits of precision for signed binary data items (using
PICTURE S9(n) COMP):
n is from 1 to 8
For n from 1 to 4, arithmetic is done in half word instructions where possible

For n from 5 to 8, arithmetic is done in full word instructions where possible
n is from 10 to 17
Arithmetic is done in double word format
n is 9
Full word values are converted to double word format and then double word
arithmetic is used (this is SLOWER than any of the above)
n is 18
Double word values are converted to a higher precision format and then
arithmetic is done using this higher precision (this is the SLOWEST of all for
binary data items)
Note: Using 9 digits is slower than using 10 digits.
• STRING/UNSTRING should be used with care. A character by character MOVE loop

is more efficient.

• Main program not COBOL: If the first program in the application is not COBOL, there
can be a significant degradation if COBOL is repeatedly called since the COBOL
environment must be initialized and terminated each time a COBOL main program is
invoked. This overhead can be reduced by using run time options like LIBKEEP,
RTEREUS etc.
• Use Dynamic calls wherever feasible.
• Avoid using USAGE DISPLAY data items for computations (especially in areas that
are heavily used for computations). When a USAGE DISPLAY data item is used,
additional overhead is required to convert the data item to the proper type both
before and after the computation. In some cases, this conversion is done by a call to
a library routine, which can be expensive compared to using the proper data type that
does not require any conversion
• When using PACKED-DECIMAL (COMP-3) data items in computations, use 15 or
fewer digits in the PICTURE specification to avoid the use of library routines for
multiplication and division. A call to the library routine is very expensive when
compared to doing the calculation in-line. Additionally, using a signed data item with
an odd number of digits produces more efficient code since this uses an integral
multiple of bytes in storage for the data item.
• For PACKED-DECIMAL : Using an odd number of digits is 6% faster than using the
next lower even number of digits using the fewest odd number of digits as possible
may result in an additional 5% to 15% savings compared to using the next larger
number of odd digits
• Plan the use of fixed-point and floating-point data types. Performance of an
application can be enhanced by carefully determining when to use fixed-point and
floating-point data.
• When conversions are necessary, binary (COMP) and packed decimal (COMP-3)
data with nine or fewer digits require the least amount of overhead when being
converted to or from floating-point (COMP-1 or COMP-2) data.
• When using fixed-point exponentiations with large exponents, the calculation can be
done more efficiently by using operands that force the exponentiation to be evaluated
in floating point.
• Forcing an exponentiation to be done in floating point is 98% faster than doing it in
fixed point.
• Using indexes to address a table is more efficient than using subscripts since the
index already contains the displacement from the start of the table and does not have
to be calculated at run time. Subscripts, on the other hand, contain an occurrence
number that must be converted to a displacement value at run time before it can be
used.
• When using subscripts to address a table, use a binary (COMP) signed data item
with eight or fewer digits (for example, using PICTURE S9 (07) COMP for the data
item). This will allow full word arithmetic to be used during the calculations.
Additionally, in some cases, using four or fewer digits for the data item may also offer
some added reduction in CPU time since half word arithmetic can be used.
• When using OCCURS DEPENDING ON (ODO) data items, ensure that the ODO
objects are binary (COMP) to avoid unnecessary conversions each time the variable-
length items are referenced.
Some performance degradation is expected when using ODO data items
since special code must be executed every time a variable length data item is
referenced. This code determines the current size of the item every time the item is
referenced. It also determines the location of variably-located data items. Because
this special code is out of line, it may inhibit some optimizations. Furthermore, code
to manipulate variable-length data items is substantially less efficient than that for
fixed-length data items. For example, the code to compare or move a variable length
data item may involve calling a library routine and is significantly slower than the
equivalent code for fixed-length data items. If you do use variable-length data items,

copying them into fixed-length data items prior to a period of high-frequency use can
reduce some of this overhead.
• When using tables, evaluate the need to verify subscripts to determine if the
subscript is out of bounds. Using the SSRANGE option (to catch the errors) causes
the compiler to generate special code at each subscript reference. However, if
subscripts need to be checked at only few places in the application to ensure that
they are valid, then coding your own checks can improve the performance when
compared to using the SSRANGE compiler option.
• No optimization is done on arithmetic statements if the ON SIZE ERROR phrase is

used. For this reason, it is recommended that this phrase should not be used, if high
performance is required.
• The ROUNDED phrase impacts performance, but it is generally faster to use

ROUNDED than try to round the result using your own routine.
• Do not use COMPUTE statements except for performing calculations involving

floating-point data. In this case, COMPUTE is the most efficient statement.
• Do not use arithmetic expressions in conditional statements, rather compute the

values in a variable and then use in computational statement.
Example:
write:
MOVE VAR-1 TO TEMP

ADD VAR-2 TO TEMP
IF TEMP < VAR-3
:
END-IF
rather than:
IF VAR-1 + VAR-2 < VAR-3
• Use Continue instead of Next Sentence. Next sentence adds run time overheads as
the control needs to be passed to the next COBOL sentence (COBOL statement after
a period is found) whereas Continue means execute the next logical instruction.
.
• Do not use the CORRESPONDING option of the MOVE verb. Also do not use
STRING and UNSTRING verbs.
• Avoid using group moves where ever possible.
• Avoid COBOL SORT, use SYNCSORT instead. COBOL SORT is only advisable
when the input file needs to be sorted and outputted in vertical slices of the file.
For e.g. - Input file is 300 byte and the output should be - Sort the file on column 1,
length 5, and the output files are - file1 - column 1-50, file2 - column 51-100, file3 -
column 101-150... file6 column - 251-300.

• For file processing, SORT the file on key value and built logic in the program to avoid
DB access for repetitive keys (current-key = previous-key)
• Define and populate and SORT Arrays in Working Storage for tables that have small
volume to data to reduce DB I/O.
• Avoid unnecessary / repetitive DISPLAY statements in the program.
• Avoid GO TO Statements
• Access to tables defined with OCCURS...DEPENDING is less efficient than access to

tables of fixed size, and so should be avoided where high performance is needed.
• Comparisons using EQUALS (=) or NOT EQUAL are faster than comparisons using
GREATER (>) or LESS (<).
• Do not use complex expressions or items defined in the Linkage Section as

conditions in an EVALUATE statement; instead, include statements to calculate the
value in an item defined in the Working-Storage Section and use that item in the
EVALUATE statement.
• In IF statements, conditions within combined conditions are evaluated in the order

that they occur. Therefore, you should put the conditions that are most likely to
produce a false result before others.
Example:
Here's an example to illustrate this. In the example we are checking a VSAM status code.
The most likely value is 00 (Executed without any errors), the later is more efficient.
IF WS-STATUS = '97' OR '96' OR '95' OR '00'

DISPLAY WS-STATUS
END-IF
IF WS-STATUS = '00' OR '97' OR '96' OR '97'

DISPLAY WS-STATUS
END-IF
• Watch compiler options. Some compiler options can result in longer running
times. For example SSR, which checks for subscripts going out of range actually
adds extra code to your program to check subscripts. SSR would be acceptable
in a test environment, but may not be appropriate in the production environment.
• If at all possible, avoid doing a sort within a COBOL program. COBOL sorts are
very inefficient. If you must do a sort in a COBOL program, specifying the
FASTSRT compiler option may speed up the sorting process.
• When calling a subprogram with USING, try to specify as few parameters as

possible. Each parameter passed requires an individual BLL cell to be allocated
in the called program and may require additional registers to be used.

3 CICS Performance Guidelines

3.1 General Guidelines
• Minimize the number of interactions between a CICS transaction program and a file
system such as the SFS server or the database product.
• CICS/DB2 programs coded in COBOL application programs should use command-level

CICS rather than macro.
• Efficiency can be improved by using auxiliary trace to review your application programs. It
can identify many common coding problems, such as:
ü Unnecessary code
ü Too many or too large EXEC CICS GETMAIN commands
ü Failure to release storage when it is no longer needed
ü Failure to unlock records held for exclusive control that are no longer needed
ü Unintended logic loops.
• Many programmers check for the presence of a COMMAREA by simply checking to see
if EIBCALEN is greater than zero and, if true, moving the LINKAGE SECTION item
DFHCOMMAREA into a WORKING STORAGE area. This technique may seem proper
on the surface, but it is not. CICS has no knowledge of the length of the LINKAGE
SECTION item DFHCOMMAREA. The length and layout of this item are set at compile
time. At execution time, the actual length passed from the invoking program is provided in
the EIB item EIBCALEN. It is the called program's responsibility to insure that EIBCALEN
matches the compile time length of DFHCOMMAREA. Failure to verify that EIBCALEN
matches the length of the DFHCOMMAREA passed can lead to ASRA / 0C4 ABENDs,
storage overlays, or invalid data being moved into the working storage area of a program.
• When working with VSAM datasets, you can avoid deadlocks by following these rules:
ü An application must end all browses on a file by means of ENDBR commands
(thereby releasing the VSAM lock) before issuing a READ UPDATE, WRITE, or
DELETE (without RIDFLD) to the file.
ü All applications that update multiple resources should do so in the same order.
For example, if a transaction is updating multiple records in a dataset, it can do
so in ascending key order. A transaction that is accessing more than one file
should do so in the same predefined sequence of files.
ü An application that issues a READ UPDATE command should follow it with a
REWRITE, DELETE (without RIDFLD), or UNLOCK to release the position
before doing anything else to the file.
ü A sequence of WRITE MASSINSERT requests must terminate with the UNLOCK
command to release the position. No other operation should be performed before
the UNLOCK command has been issued.
• Hold resources only as long as required, rather than waiting until the task is terminated to
let CICS release them for you. Resource contention is always a big performance
problem. Transactions which do not release resources can hold up the processing of
other transactions. The transactions which are held up are also holding resources which
may be needed by other transactions. Eventually the whole system can grind to a halt.

3.2 Performance Guidelines
• Use CALL statement instead of LINK or XCTL because execution overhead is least for a
CALL, as no CICS services are invoked; for example, the working storage of the program
being called is not copied.
• If the invoking program does not need to have control returned to it after the invoked
program is processed, it should use an XCTL command. Both processor and storage
requirements are much greater for a LINK command than for an XCTL command.
• For VSAM data sets, processor overhead can be minimised by:
ü Use the MASSINSERT option if you are adding many records in sequence. This
improves performance by minimizing processor overheads and therefore
improves the response times.
ü Use skip sequential processing if you are reading many records in sequence
whose keys are relatively close together but not necessarily adjacent. (Skip
sequential processing begins with a start browse (STARTBR command).) Each
record is retrieved with an READNEXT command, but the key feedback area
pointed to, by RIDFLD is supplied with the key of the next requested record
before the READNEXT command is issued.
ü CICS internally optimizes a generic DELETE.
• Select the appropriate storage class as given below:
ü EXEC CICS GETMAIN
GETMAIN storage is allocated with a mechanism that is similar to operating system

malloc and free routines, and comes from the process data segment. CICS imposes a
limit, configurable in the Region Definitions (RD), on the amount of this type of storage
that is given to a transaction program. This class of storage is reclaimed by CICS if the
transaction program abends or terminates without releasing it.
ü EXEC CICS GETMAIN SHARED
GETMAIN SHARED is allocated from storage that is shared between all CICS tasks.
The total available is configured in the region database. GETMAIN SHARED remains
allocated until explicitly freed by a transaction program.
• The CICS programs should follow the technique of Pseudo-conversational and Re-
entrant
• Use RETURN IMMEDIATE instead of START
Sometimes it is needed to execute a sequence of particular tasks in succession.

In earlier releases of CICS, this was normally done using the START command.
CICS/ESA introduced a new option on the RETURN command, RETURN

IMMEDIATE, which also allows you to do this. With RETURN IMMEDIATE, CICS
initiates a task to execute the transaction named in the TRANSID option
immediately, before honouring any other waiting requests for a task at that
terminal and without accepting input from the terminal. The old task can even
pass data to the new one. The new task accesses this data with a RECEIVE, as
if the user had initiated the task with unsolicited input, but no input/output occurs.
• The advantages of using the RETURN IMMEDIATE command versus the START
commands are :
ü The next transaction is initiated immediately, regardless of any other transaction

which may be queued to start for that terminal. If a START is used and a pending
message or another started transaction is queued for the terminal, it will interrupt
the flow of tasks.
ü The transition from TRNA to TRNB is much faster.
ü When using START commands, there is a period of time between TRNA and
TRNB when the terminal operator may hit the keyboard and prevent TRNB from
being initiated. There is no exposure to this type of problem using RETURN
IMMEDIATE commands.
ü STARTed transactions can not participate in dynamic routing. Once the START
is issued, the transaction must run in the predetermined region.
ü Transactions initiated via RETURN IMMEDIATE can participate in dynamic
routing, making the move to parallel systems easier.
ü One thing to be aware of when changing from START to RETURN IMMEDIATE
in an existing application is that the method for transferring data between
transactions is different between the two methods. STARTed transactions must
RETREIVE the data, while those invoked by RETURN IMMEDIATE may access
any data passed via the COMMAREA.
• VSAM: Use LISTCAT to analyze your files regularly. REORG your files frequently.
ü Make note of splits, CISIZEs, FREESPACE, and dataset extents.
ü Avoid CA splits, which can cause excessive arm movement on the DASD device,
increase response time, and may use additional OSCOR. If CA splits occur often,
increase CA FREESPACE.
ü Avoid multiple extents (fragmentation), which may also cause excessive arm
movement and increase response time. Increase primary allocation parameter to
get the file into a single extent, if possible.
ü Alter % of CA/CI FREESPACE to avoid CA/CI splits.
ü For random insertion use more CI FREESPACE.
ü For non-random insertion use more CA FREESPACE.
ü If not inserting records online, use zero FREESPACE. If inserting online, allow
enough FREESPACE to avoid splits.
ü Allocate space by CYLINDERS rather than by RECORDS. Allocating space by
RECORDS can cause a CA to be smaller than 1 cylinder.
ü Always specify CISIZE for the DATA component of a VSAM dataset. The
recommended data CISIZE is 4096 (4K). IDCAMS will probably pick a larger size
than is optimum for our online system if you let the DATA component CISIZE
default.
ü Let IDCAMS pick the INDEX CISIZE for you; that is, let the INDEX CISIZE
default. IDCAMS does a good job of picking the best CISIZE for INDEX
components. If you prefer to specify your own INDEX CISIZE, 1K is preferred
because CNS has a large number of 1K buffers specified in the CICS LSR pool.
ü Buffer space is wasted if CISIZEs are chosen which do not have matching buffer
sizes in the CICS LSR pool. The only available buffer sizes in the LSR pool at
CNS are 512, 1K, 2K, 4K, 8K, 12K, 20K, and 32K. A dataset with a CISIZE other

than one of these will use the next larger buffer size, thus wasting the unused
space in the buffer.
ü All alternate index datasets should be defined with the UPGRADE option to force
VSAM to maintain all pointers to new records and keys.
ü SHAREOPTIONS (2, 3) is recommended for dataset integrity purposes. There
are absolutely no data integrity guarantees when using SHAREOPTIONS (3, 3) -
neither READ integrity nor WRITE integrity. Datasets can become corrupted and
data can be lost. If you still choose to bet your data on the use of this option, in
spite of the warnings, do so at your own risk (and keep your resume updated).
ü Use NOWRITECHECK when defining VSAM files.
ü Use SPEED when defining KSDS datasets and RECOVERY when defining
ESDS datasets.
ü Avoid MASSINSERT if possible. If MASSINSERT is used, request that the file
NOT be placed in the CICS LSR pool.
ü AIX paths should be READ ONLY. Perform all updates, insertions, and deletions
against a base cluster. Updating via an alternate index is not allowed in CICS at
CNS.
ü When requesting CICS table definitions for AIX paths, be sure to identify them as
such in the memo. There is a parameter in the FCT which associates a path with
its base cluster and should be defined properly to insure data integrity.

4 DB2 Guidelines
4.1 General Guidelines
• Filtering non qualifying rows as soon as possible reduces the CPU consumption of SQL.
Include the predicates in the SQL and not in the application logic. It also applies to the
processing inside DB2. Exploit stage 1 predicates as much as possible.
• Code the most restrictive predicate first: While coding predicates in select statement,
place the predicate that will eliminate the greatest number of rows first.
• Use indexes wherever possible, DB2 usually performs more efficiently when it can satisfy
a request using an existing index rather than no index
• If a table has only multicolumn indexes, try to specify the high-level column in the
WHERE clause the query. This results in an index scan with at least one matching
column.
• Use ORDER BY only when sequence is important: Code the ORDER BY clause when
the sequence of rows being returned is important. Order only those columns that are
absolutely necessary in order to improve efficiency.
• Use BETWEEN rather than <= and >= : BETWEEN allows the optimizer to select a more
efficient access path.
• Use IN instead of LIKE: If you know that only a certain number of occurrences exist,
using IN with the specific list is more efficient than using LIKE. The functionality of LIKE
can be imitated using a range of values. For example, for retrieving all employees with a
last name starting with "M," use BETWEEN 'maaaaaaaaaaaaaaa' and
'mzzzzzzzzzzzzzzz' instead of LIKE 'm%'
• Avoid using % or _ at the beginning as it prevents DB2 from using a matching index.
Instead use it at the end.
• Use Joins instead of Subqueries. Joins will give the DB2 optimizer more options for data
access than a subquery.
• As a general rule, use the LOCK TABLE only after discussing its implications with DBA
staff. LOCK TABLE can significantly decrease an applications processing time by
eliminating page locks, but will also make the tablespace unavailable to any other
access. It locks ALL tables in a Tablespace. The locks are held until a COMMIT or
DEALLOCATE, and all users are locked out of the tablespace.
• Always specify leading characters when using LIKE
• Search criteria should be specified for all tables in a join
• Always avoid correlated sub-query as they affect the performance.

• Before embedding SQL in an application program, test it using SPUFI. This reduces the
amount of program testing by ensuring that all SQL code is syntactically correct and
efficient before it is placed in an application program.
4.2 Performance Guidelines
• Design all SQL statements to take advantage of indexes.
• Indexes are used in a WHERE clause with the following predicate types:
ü column = value
ü column is null
ü column > value
ü column < value
ü column >= value
ü column <= value
ü column BETWEEN value1 and value2
ü column LIKE 'char%'
ü column IN list
• Indexes are NOT used in WHERE clauses with the following predicate types:
ü column not null
ü column not BETWEEN value1 and value2
ü column LIKE '%char'
ü column LIKE '_char'
ü column LIKE host variable
ü column not IN list
• Use EXPLAIN utility to determine if indexes are being used in the SQL statement.
• When using ORDER BY, GROUP BY, DISTINCT, and UNION, it is best to use only
indexed columns.
• Locks should be row-level and not table or table space level.
• Avoid allowing an isolation parameter of UR.
• Tablespaces should be defined as Partitioned.
• Clustered Indexes should be used for search operations.
• Columns used in joins should be of the same data type, length, and name.
• Code predicates to limit the result to only the rows required
• Avoid generic queries which do not have a WHERE clause
• Minimize number of columns selected/updated
• Avoid SELECT *
• Include as many matching predicates as possible to limit the number of rows that need to
be processed. Do not have filtering in the application as it will consume more resources
to pass a row to the application than to verify in DB2 that the row does not qualify your
search criteria.

• Use a singleton select for queries that return only one row
• When comparing Column values to Host Variables use the same Data type, Length
• Use EXISTS to test for a condition and return TRUE/FALSE instead of returning rows
• When building the SQL create the most restrictive predicate first i.e., predicate which will
eliminate the greatest number of rows
A further level of optimization is the stage at which predicates are applied. DB2
has two logical levels at which predicates are applied:
ü Stage 1, which is the most efficient level that can make optimal use of the
indexes.
ü Stage 2, which needs to obtain the information from stage 1, causes additional
CPU consumption. If your SQL contains only stage 2 predicates on an indexed
column, you can use that index-only in a nonmatching index scan, without index
screening, which might be a very inefficient access path.
• Rebind your applications over time as the data changes. Rebinding will generally improve
the overall performance of your applications because the access paths will be better
designed based on an accurate view of the data.
• Let SQL do the work instead of the program. For example, code an SQL join instead of
two cursors using program logic to join.
• Retrieve only the columns required, never more

Limit the columns being retrieved to those which the application actually needs. The CPU
cost of passing the column from DB2 to the application is not the only consideration.
Retrieving the additional columns that the application does not need can make the
difference between an index-only access path and an additional access to the data
pages.
• Issue data modification statements (INSERT, UPDATE, DELETE) as close as possible to

the COMMIT statement, if possible
• Be sure to build a COMMIT strategy into every batch program that changes data. Failing
to COMMIT can cause locking problems.
• Include OPTIMIZE FOR n ROWS and FETCH FIRST n ROWS ONLY. These clauses,
placed at the end of a SELECT statement, are optimal when the whole result set isn't
needed.
• If you intend to update fetched data, you should specify FOR UPDATE clause in
the SELECT statement of the cursor definition. It decreases the possibility of deadlock
and save the cost to perform lock conversions
• Use Compound SQL and Stored procedures for better performance and will minimize
data transmission.
Following are the guidelines for database design:
• Unique index should be created for each primary key

• Indexes should be created for foreign keys.
• Use partitioned table spaces when the amount of data to be stored is very large and to
improve recoverability.
• Use a simple table space only when the data needs to be mixed from different tables on
one page.
• To improve performance, assign frequently accessed DB2 objects to different storage

groups on different devices.
• Length of fields like transaction number , account number etc which forms nerve of an
application should always be defined with more data length e.g. define account number
as PIC X(9) instead of PIC X(5).
• Use partitioned tablespaces for tables over 1 million rows. With partitioned tablespaces
you have the capability to take image copies of (and in release 2.3, reorganize) one or
more partitions simultaneously (or one at a time while the other partitions are available
for other processing).
• Use PCTFREE and FREEPAGE for tables with high levels of updates and/or inserts.
Bachman will calculate appropriate values based on growth statistics.
• The SEGSIZE (n) for segmented tablespaces must be multiple of 4 such that 4 <= n <=
64. Unless a tablespace contains fewer than 64 pages, define segment size as
SEGSIZE 64. With fewer than 64 pages, define SEGSIZE as an even multiple of 4 as
close to the actual number of pages as possible.
• Assign one table per tablespace.
• Create tablespaces explicitly rather than implicitly (tablespaces are created implicitly by
creating a table without naming the tablespace that will contain the table).
• All tablespaces should be segmented, even simple (one-table) tablespaces. The

headers kept in segmented tablespaces provide for more efficient space management
and better performance.
• USE WITH HOLD option with CURSOR, if the cursor needs to be used after the
COMMIT.
The COMMIT process closes all open cursors unless they are declared with the
WITH HOLD option. These cursors must then be reopened and repositioned after each
COMMIT in the batch application. To reduce the complexity of your application logic and
to save the execution cost of cursor repositioning, you should use the WITH HOLD option
for cursors declared in your batch applications.
• Control COMMIT Frequency

There is a trade-off between commit frequency and performance. Commit

increases CPU consumption and may increase I/O elapsed time due to cursor
repositioning overhead unless cursors are declared with the WITH HOLD option. The
desired commit frequency can be stored in a DB2 table. This value can then be used in
the application program to determine when to commit. The commit frequency can be
specified differently for different periods of the day, for example, with low values during
the online shifts and a high value during the night period.
• Specify CLOSE NO for frequently used tables to prevent the automatic closing of all
datasets in the tablespace when there are no current users. Only specify CLOSE YES
for tables that are rarely used.
• Set PCTFREE and FREEPAGE to 0 for tables which will have read-only access (such
as Information Center tables).
• Always specify primary and secondary (PRIQTY and SECQTY) quantities since the
default values will usually be too small. These values are in units of 'K' (1024) bytes.
Values should be an even multiple of 48K for 3390 devices.
• Specify LOCKSIZE ANY on all tables, with the exception of read-only tables. This allows
DB2 to set locking at the most efficient level.
• Only use VARCHAR when the length of the column varies by more than 20 bytes.
Otherwise the additional overhead will out-weigh the potential space savings.
• Keep in mind that the LONG VARCHAR data type has the following disadvantages: 1) it
cannot be used in any character string comparison operations, 2) it cannot be used in
WHERE, HAVING, GROUP BY, and ORDER BY statements, and 3) it cannot be used
as an index.
• Avoid LONG VARCHAR if at all possible. It should only be used in cases where long
strings of free-form text are stored (such as notes).
• Primary keys must have unique indexes.
• Specify CLOSE NO when creating an index to improve performance.
• Always specify primary and secondary (PRIQTY and SECQTY) quantities since the
default values will usually be too small. These values are in units of "K" (1024) bytes.
Values should be an even multiple of 48K for 3390 devices.
• Good candidates for indexes:

ü Columns frequently referenced by SELECT, JOIN, GROUP BY, or ORDER BY
ü Columns frequently checked for EXISTENCE of certain values using WHERE
clause.
ü Columns considered as keys

• Bad candidates for indexes:

ü Columns that are frequently updated
ü Columns with low cardinality (cardinality is the number of different values within
the table for one column or set of columns)
ü Columns with more than 40 bytes (because they build indexes with multiple
levels)
ü Columns defined as VARCHAR
• Always include WITH CHECK OPTION when creating views which will be used in
updating. This causes an automatic edit against the WHERE clause when updating
through a view to prevent inadvertent inserts/updates outside of the clause.
• Do not use the LARGE Parameter. Instead use the DSSIZE parameter for large
tablespaces.
• Create indexes for columns used frequently in ORDER BY, GROUP BY, SELECT
DISTINCT, JOIN
• Execute RUNSTATS utility after a database has been modified

5 IMS Guidelines
§ Reduce the number of I/O IWAITS:
Ø Use XDFLD name in SSA when PCB has PROCSEQ.

Ø Do not use PROCOPT=GOT, use PROCOPT=GON.
• Reduce lock contention. Use the minimum PROCOPT needed for processing.
• Use Two PCBs If Little Updating: If an application does relatively little updating of a
shared database, one could replace a single update PCB with a read or read-only
PCB and another update PCB. The majority of application processing could reside
with the read PCB and when an update is required, the data could be re-read and
then updated via the update PROCOPT PCB.
• Use PROCOPT Effectively: The best way to reduce the overhead of lock contention
is simply to take less locks. A share lock does not cause contention between sharing
users; only update locks cause contention hence using correct values for PROCOPT
is essential.
PROCOPT=G causes share locks to be acquired in the Coupling Facility, while

PROCOPT=R,I,D or A causes exclusive locks to be taken in the Coupling Facility. If
operation is read-only then use PROCOPT=G, or PROCOPT=GON instead of
PROCOPT=A. This reduces the amount of locking that IMS performs.
The read-only program can then recover from the error. PROCOPT=GON will use no
locks. PROCOPT=GOT will temporarily invoke locking if bad pointers are
encountered.
PROCOPT=E: IMS programs can obtain exclusive access to an IMS database with
the IMS PCB option, PROCOPT=E.

• For best performance in the IMS environment, use the RENT compiler option. It
causes COBOL to generate re-entrant code. You can then run your application
programs in either pre-loaded mode (the programs are always resident in storage) or
non-preloaded mode, without having to recompile with different options.
• Reduce the Number of DL/I Calls: Locking rates and contention are directly related to
the volume of concurrent, conflicting DL/I requests for shared resources, so one way
to provide a solution to locking problems is to reduce the number of DL/I calls.
• The use of path calls can retrieve more than one database segment per call.
Ø Use Command codes effectively in qualified SSA are:
C Use the complete concatenation key to search a segment

D Path call
F Get the first occurrence of the segment under its parent
L Get the last occurrence of the segment under its parent
N Specifies that this segment is not to be replaced when segments are
replaced after a get hold call
P Set parentage at this level
Q Enqueue the segment so no one else can change it until you are finished
with it
U Limit the search for this segment on which position is to be established
V Hold position on this segment
- Place holder where a command field is provided but not required.
Ø Programs should be designed to avoid issuing multiple calls for the same
segment during a single execution.
Ø If possible, an attempt should be made to eliminate redundant or non productive

calls that result in GE, GB, or II status codes except where these status codes
represent exceptional conditions.
Ø In order to reduce the large number of unneeded segments retrieved via

unqualified GN calls, fully qualified GU calls should be used.
Ø Use single segment input messages.
Ø Send single segment output messages.

6 JCL Guidelines
• Stepnames and dataset names must be meaningful.
• Comments should be mentioned for each step.
• Each qualifier of a dataset name except the filename should be a symbolic parameter
so that it becomes flexible to override them in exec JCL. Note that filename shouldn’t
be made symbolic parameter. Otherwise, the same filename might have different
names (with different overrides) which is highly undesirable.
• There should not be any ‘SYSIN DD *’ statements. Place all the sort SYSIN cards
and other SYSIN cards required by program in a standard control card.
• There should not be any ‘SYSOUT DD *’ statements in the PROC. Instead, define
symbolic parameter for sysout destination at step level and override it in exec JCL to
‘*’, if required.
• While creating a new version, use the standard model DCB for the application. If the
application doesn’t have one, standardize it and use it across all the PROCs that
create GDGs.
• Have a common set of step libraries for all the steps of a PROC. Generalize these
libraries using symbolic parameters so that you can override them in your exec JCL.
Example:
//STEPLIB DD DISP=SHR,DSN=&STEP1
// DD DISP=SHR,DSN=&STEP2
// DD DISP=SHR,DSN=&STEP3
// DD DISP=SHR,DSN=SYS1.SCEERUN ß Load library required

to run COBOL programs
You may have the above STEPLIB as a common to all steps. It has 3 libraries,
which are defined as symbolic parameters: STEP1/STEP2/STEP3. Define
defaults for these symbolic parameters in the PROC. These can be overridden in
your run JCL, if required. The advantage of having common STEPLIB is that you
need not override STEPLIB of each step in your run JCL. It’s enough if you just
override the 3 symbolic parameters. If you want any step’s library different from
others, then you can achieve it through step override.

• There are times to produce the hard copies of datasets by printing them on to a
printer and also at times may need to transmit some datasets (such as those which
contains some reports) to a set of business people. It’s a good practice to check if a
dataset is empty before doing such operations.
• Test the PROC properly with the standard tools available (or with TYPRUN=SCAN)
and then only baseline it.
• The processing of VSAM files in batch and on-line environments (either sequential or
random access) can typically be greatly enhanced by proper specification of the
number of index buffers (BUFNI) and the number of data buffers (BUFND.
• Processing of large sequential files can be greatly enhanced by increasing the

number of Buffers allocated to the file.
• Omit the BLKSIZE parameter when possible to allow the system to calculate the
most effective block-size for the type of unit being used.
• Allow at least three times the file size for sort work space allocations, with a minimum
of three sort work DDs. For very large files, always code the sorted data sets to be
catalogued. The size of the sort work space allocations, if too small, may cause
detrimental performance of the sort.
• Usage of SYNCSORT is recommended over other similar utilities, since it takes less
CPU time and better resource utilization.
• Use RLSE parameter while dataset allocation, which frees the unused space
• Use DISP=SHR instead of DISP=OLD whenever possible to avoid exclusive control

of the datasets
• Use the appropriate CLASS, REGION and TIME parameter for better performance
• Use TYPRUN=SCAN and check for JCL syntax, before submitting the actual
processing (some installations have JEM, JSCAN, JJ etc editor comment for syntax
checking). Before releasing to Production, make sure such statements are removed.
• Using RECFM=FB instead of RECFM=F reduces input/output operations and leads

to better performance.

Mainframe Performance Guidelines

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Mainframe Performance Guidelines

Diunggah oleh

Hak Cipta:

Format Tersedia

Mainframe Practice - BFSI Mainframe Performance Guidelines.

Mainframe Practice - BFSI

Wipro Technologies Confidential 05/02/2008 Page 1 of 23

Wipro Technologies Confidential 05/02/2008 Page 2 of 23

Wipro Technologies Confidential 05/02/2008 Page 3 of 23

This document is prepared by BFSI Mainframe Practice.

In the current version of the document, following are in scope:

Also, following are not in scope of this document:

Wipro Technologies Confidential 05/02/2008 Page 4 of 23

• Use the ‘=’ sign rather than EQUAL in IF-statement.

• In a paragraph, only one functionality should be coded.

• Structured approach should be followed for coding the program.

• Variable names or verbs should not be broken when continuing a statement.

• Use consistently Either ZEROS or ZERO and not both of them.

• Use the reserve words SPACE(S) in VALUE clauses instead of ‘ ‘.

• Use the reserve words ZERO(S) in VALUE clauses instead of 0

2.2 Performance guidelines

Wipro Technologies Confidential 05/02/2008 Page 5 of 23

For n from 1 to 4, arithmetic is done in half word instructions where possible

Arithmetic is done in double word format

Note: Using 9 digits is slower than using 10 digits.

• STRING/UNSTRING should be used with care. A character by character MOVE loop

Wipro Technologies Confidential 05/02/2008 Page 6 of 23

Wipro Technologies Confidential 05/02/2008 Page 7 of 23

• No optimization is done on arithmetic statements if the ON SIZE ERROR phrase is

• The ROUNDED phrase impacts performance, but it is generally faster to use

• Do not use COMPUTE statements except for performing calculations involving

• Do not use arithmetic expressions in conditional statements, rather compute the

MOVE VAR-1 TO TEMP

IF VAR-1 + VAR-2 < VAR-3

• Avoid using group moves where ever possible.

Wipro Technologies Confidential 05/02/2008 Page 8 of 23

• Avoid unnecessary / repetitive DISPLAY statements in the program.

• Access to tables defined with OCCURS...DEPENDING is less efficient than access to

• Do not use complex expressions or items defined in the Linkage Section as

• In IF statements, conditions within combined conditions are evaluated in the order

IF WS-STATUS = '97' OR '96' OR '95' OR '00'

IF WS-STATUS = '00' OR '97' OR '96' OR '97'

• When calling a subprogram with USING, try to specify as few parameters as

Wipro Technologies Confidential 05/02/2008 Page 9 of 23

3 CICS Performance Guidelines

• CICS/DB2 programs coded in COBOL application programs should use command-level

Wipro Technologies Confidential 05/02/2008 Page 10 of 23

3.2 Performance Guidelines

• For VSAM data sets, processor overhead can be minimised by:

ü CICS internally optimizes a generic DELETE.

• Select the appropriate storage class as given below:

ü EXEC CICS GETMAIN

GETMAIN storage is allocated with a mechanism that is similar to operating system

ü EXEC CICS GETMAIN SHARED

• Use RETURN IMMEDIATE instead of START

Sometimes it is needed to execute a sequence of particular tasks in succession.

Wipro Technologies Confidential 05/02/2008 Page 11 of 23

ü The next transaction is initiated immediately, regardless of any other transaction

Wipro Technologies Confidential 05/02/2008 Page 12 of 23

Wipro Technologies Confidential 05/02/2008 Page 13 of 23

• Always specify leading characters when using LIKE

• Search criteria should be specified for all tables in a join

• Always avoid correlated sub-query as they affect the performance.

Wipro Technologies Confidential 05/02/2008 Page 14 of 23

4.2 Performance Guidelines

• Design all SQL statements to take advantage of indexes.

• Locks should be row-level and not table or table space level.