mainframe performance guidelines

8/8/2019 Mainframe Performance Guidelines

http://slidepdf.com/reader/full/mainframe-performance-guidelines 1/23

Mainframe Practice - BFSI Mainframe Performance Guidelines.doc

Wipro Technologies Confidential 05/02/2008 of 23

Mainframe

Performance Guidelines

Prepared By :

Mainframe Practice - BFSI





Document Control

Version History

Version DateChangedby

Nature of amendment

0.1 13 Sep 2007Mainframepractices

Initial Draft





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.1 GENERAL GUIDELINES..............................................................................................................14

4.2 PERFORMANCE GUIDELINES......................................................................................................15

5 IMS GUIDELINES .......................................................................................................................20

5.1 GENERAL GUIDELINES ..............................................................................................................20

5.2 PERFORMANCE GUIDELINES ......................................................................................................21

6 JCL GUIDELINES .......................................................................................................................22

6.1 GENERAL GUIDELINES ..............................................................................................................22

6.2 PERFORMANCE GUIDELINES ......................................................................................................23





1 Introduction

1.1 Objective

There is no comprehensive document on performance guidelines. The intention of thisdocument is to list down a comprehensive set of guidelines that could be adopted byvarious accounts with minimal customization. This will ensure consistency across thevertical. In the absence of any client specific guidelines, the guidelines described in thisdocument could be implemented as it is. In cases, where client specific guidelines arepresent, the guidelines described in this document could be implemented based on clientconsent.

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, whichare 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 followthe 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 forsequential 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 firstcondition.

• Usage of performs: PERFORM Paragraph compiler converts up to 6 machineinstructions and PERFORMs with VARYING will require many more machineinstructions. 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 FileSection. Best practice is to allow system to decide the optimal block size byspecifying “Block Contains 0 “clause for creating any new files and omitting BLKSIZEoption in JCL. This should significantly improve file processing time (Both CPU timeand elapsed time)

• Increasing the number of I/O buffers for heavy I/O jobs can improve both the CPUand 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 JCLor by using the RESERVE clause of the SELECT statement in the FILE-CONTROLparagraph

• 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 ofcalls to Data Management Services to handle the I/Os.

• When using VSAM files, increase the number of data buffers (BUFND) for sequentialaccess or index buffers (BUFNI) for random access. Also, select a control intervalsize (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 ismore efficient for sequential processing. In general, using large CI and buffer spaceVSAM parameters may help to improve the performance of the application.

• For VSAM; ACCESS IS DYNAMIC is optimal when reading one record in a randomorder and then reading several subsequent records sequentially. VSAM may prefetch multiple tracks of data when using ACCESS IS DYNAMIC.

•

In general, sequential access is the most efficient, dynamic access the next, andrandom access is the least efficient. However, for relative record VSAM(ORGANIZATION IS RELATIVE), using ACCESS IS DYNAMIC when reading eachrecord 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 theindex for each request. If you use alternate indexes, it is more efficient to use theAccess Method Services to build them than to use the AIXBLD run-time option. Avoidusing multiple alternate indexes when possible since updates will have to be appliedthrough the primary paths and reflected through the multiple alternate paths.

• To get the best performance from arithmetic statements always use the simplestforms. Use simple two-operand arithmetic statements wherever possible.

• Use Proper USAGE clause for the numeric items, like for counters use COMP, forarithmetic calculations use COMP-3, this will be used for optimization – both speedand 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, butit does so at the expense of storage. When using binary (COMP) data items, the useof 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 theperformance of certain operations on some machines. Additionally, using signed dataitems with eight or fewer digits produces the best code for binary items.

• The following shows the performance considerations (from most efficient to leastefficient) for the number of digits of precision for signed binary data items (usingPICTURE S9(n) COMP):

n is from 1 to 8

For n from 1 to 4, arithmetic is done in half word instructions where possibleFor 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 9Full word values are converted to double word format and then double wordarithmetic is used (this is SLOWER than any of the above)

n is 18Double word values are converted to a higher precision format and thenarithmetic is done using this higher precision (this is the SLOWEST of all forbinary data items)

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

• STRING/UNSTRING should be used with care. A character by character MOVE loopis more efficient.





• Main program not COBOL: If the first program in the application is not COBOL, therecan be a significant degradation if COBOL is repeatedly called since the COBOLenvironment must be initialized and terminated each time a COBOL main program isinvoked. 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 thatare 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 bothbefore and after the computation. In some cases, this conversion is done by a call toa library routine, which can be expensive compared to using the proper data type thatdoes not require any conversion

• When using PACKED-DECIMAL (COMP-3) data items in computations, use 15 orfewer digits in the PICTURE specification to avoid the use of library routines formultiplication and division. A call to the library routine is very expensive whencompared to doing the calculation in-line. Additionally, using a signed data item withan odd number of digits produces more efficient code since this uses an integralmultiple of bytes in storage for the data item.

• For PACKED-DECIMAL : Using an odd number of digits is 6% faster than using thenext lower even number of digits using the fewest odd number of digits as possiblemay result in an additional 5% to 15% savings compared to using the next largernumber of odd digits

• Plan the use of fixed-point and floating-point data types. Performance of anapplication can be enhanced by carefully determining when to use fixed-point andfloating-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 beingconverted to or from floating-point (COMP-1 or COMP-2) data.

• When using fixed-point exponentiations with large exponents, the calculation can bedone more efficiently by using operands that force the exponentiation to be evaluatedin floating point.

• Forcing an exponentiation to be done in floating point is 98% faster than doing it infixed point.

• Using indexes to address a table is more efficient than using subscripts since theindex already contains the displacement from the start of the table and does not haveto be calculated at run time. Subscripts, on the other hand, contain an occurrencenumber that must be converted to a displacement value at run time before it can beused.

• When using subscripts to address a table, use a binary (COMP) signed data itemwith eight or fewer digits (for example, using PICTURE S9 (07) COMP for the dataitem). 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 offersome added reduction in CPU time since half word arithmetic can be used.

• When using OCCURS DEPENDING ON (ODO) data items, ensure that the ODOobjects are binary (COMP) to avoid unnecessary conversions each time the variable-length items are referenced.

Some performance degradation is expected when using ODO data itemssince special code must be executed every time a variable length data item isreferenced. This code determines the current size of the item every time the item isreferenced. It also determines the location of variably-located data items. Becausethis special code is out of line, it may inhibit some optimizations. Furthermore, codeto manipulate variable-length data items is substantially less efficient than that forfixed-length data items. For example, the code to compare or move a variable lengthdata item may involve calling a library routine and is significantly slower than theequivalent 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 canreduce some of this overhead.

• When using tables, evaluate the need to verify subscripts to determine if thesubscript is out of bounds. Using the SSRANGE option (to catch the errors) causesthe 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 thatthey are valid, then coding your own checks can improve the performance whencompared to using the SSRANGE compiler option.

• No optimization is done on arithmetic statements if the ON SIZE ERROR phrase isused. For this reason, it is recommended that this phrase should not be used, if highperformance is required.

• The ROUNDED phrase impacts performance, but it is generally faster to useROUNDED than try to round the result using your own routine.

• Do not use COMPUTE statements except for performing calculations involvingfloating-point data. In this case, COMPUTE is the most efficient statement.

• Do not use arithmetic expressions in conditional statements, rather compute thevalues 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 asthe control needs to be passed to the next COBOL sentence (COBOL statement aftera period is found) whereas Continue means execute the next logical instruction.

.

• Do not use the CORRESPONDING option of the MOVE verb. Also do not useSTRING and UNSTRING verbs.

• Avoid using group moves where ever possible.

• Avoid COBOL SORT, use SYNCSORT instead. COBOL SORT is only advisablewhen 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 avoidDB access for repetitive keys (current-key = previous-key)

• Define and populate and SORT Arrays in Working Storage for tables that have smallvolume 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 totables of fixed size, and so should be avoided where high performance is needed.

• Comparisons using EQUALS (=) or NOT EQUAL are faster than comparisons usingGREATER (>) or LESS (<).

• Do not use complex expressions or items defined in the Linkage Section asconditions 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 theEVALUATE statement.

• In IF statements, conditions within combined conditions are evaluated in the orderthat they occur. Therefore, you should put the conditions that are most likely toproduce 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 runningtimes. For example SSR, which checks for subscripts going out of range actuallyadds extra code to your program to check subscripts. SSR would be acceptablein 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 arevery inefficient. If you must do a sort in a COBOL program, specifying theFASTSRT compiler option may speed up the sorting process.

• When calling a subprogram with USING, try to specify as few parameters aspossible. Each parameter passed requires an individual BLL cell to be allocatedin 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 filesystem such as the SFS server or the database product.

• CICS/DB2 programs coded in COBOL application programs should use command-levelCICS rather than macro.

• Efficiency can be improved by using auxiliary trace to review your application programs. Itcan 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 seeif EIBCALEN is greater than zero and, if true, moving the LINKAGE SECTION itemDFHCOMMAREA into a WORKING STORAGE area. This technique may seem properon the surface, but it is not. CICS has no knowledge of the length of the LINKAGESECTION item DFHCOMMAREA. The length and layout of this item are set at compiletime. At execution time, the actual length passed from the invoking program is provided inthe EIB item EIBCALEN. It is the called program's responsibility to insure that EIBCALENmatches the compile time length of DFHCOMMAREA. Failure to verify that EIBCALENmatches 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, orDELETE (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 doso in ascending key order. A transaction that is accessing more than one fileshould do so in the same predefined sequence of files.

ü An application that issues a READ UPDATE command should follow it with aREWRITE, DELETE (without RIDFLD), or UNLOCK to release the positionbefore doing anything else to the file.

ü A sequence of WRITE MASSINSERT requests must terminate with the UNLOCKcommand 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 tolet CICS release them for you. Resource contention is always a big performanceproblem. Transactions which do not release resources can hold up the processing ofother transactions. The transactions which are held up are also holding resources whichmay 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 aCALL, as no CICS services are invoked; for example, the working storage of the programbeing called is not copied.

• If the invoking program does not need to have control returned to it after the invokedprogram is processed, it should use an XCTL command. Both processor and storagerequirements 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. Thisimproves performance by minimizing processor overheads and thereforeimproves the response times.

ü Use skip sequential processing if you are reading many records in sequencewhose keys are relatively close together but not necessarily adjacent. (Skipsequential processing begins with a start browse (STARTBR command).) Eachrecord is retrieved with an READNEXT command, but the key feedback areapointed to, by RIDFLD is supplied with the key of the next requested recordbefore 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 systemmalloc and free routines, and comes from the process data segment. CICS imposes alimit, configurable in the Region Definitions (RD), on the amount of this type of storagethat is given to a transaction program. This class of storage is reclaimed by CICS if thetransaction 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 remainsallocated 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, CICSinitiates a task to execute the transaction named in the TRANSID optionimmediately, before honouring any other waiting requests for a task at thatterminal and without accepting input from the terminal. The old task can evenpass data to the new one. The new task accesses this data with a RECEIVE, asif the user had initiated the task with unsolicited input, but no input/output occurs.

• The advantages of using the RETURN IMMEDIATE command versus the STARTcommands are :

ü The next transaction is initiated immediately, regardless of any other transactionwhich may be queued to start for that terminal. If a START is used and a pendingmessage or another started transaction is queued for the terminal, it will interruptthe 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 frombeing initiated. There is no exposure to this type of problem using RETURNIMMEDIATE commands.

ü STARTed transactions can not participate in dynamic routing. Once the STARTis issued, the transaction must run in the predetermined region.

ü Transactions initiated via RETURN IMMEDIATE can participate in dynamicrouting, making the move to parallel systems easier.

ü One thing to be aware of when changing from START to RETURN IMMEDIATEin an existing application is that the method for transferring data betweentransactions is different between the two methods. STARTed transactions mustRETREIVE the data, while those invoked by RETURN IMMEDIATE may accessany 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 toget 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 CISIZEdefault.

ü Let IDCAMS pick the INDEX CISIZE for you; that is, let the INDEX CISIZEdefault. IDCAMS does a good job of picking the best CISIZE for INDEXcomponents. If you prefer to specify your own INDEX CISIZE, 1K is preferredbecause 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 buffersizes in the CICS LSR pool. The only available buffer sizes in the LSR pool atCNS 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 unusedspace in the buffer.

ü All alternate index datasets should be defined with the UPGRADE option to forceVSAM to maintain all pointers to new records and keys.

ü SHAREOPTIONS (2, 3) is recommended for dataset integrity purposes. Thereare absolutely no data integrity guarantees when using SHAREOPTIONS (3, 3) -neither READ integrity nor WRITE integrity. Datasets can become corrupted anddata can be lost. If you still choose to bet your data on the use of this option, inspite 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 atCNS.

ü When requesting CICS table definitions for AIX paths, be sure to identify them assuch in the memo. There is a parameter in the FCT which associates a path withits 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 theprocessing 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 satisfya request using an existing index rather than no index

• If a table has only multicolumn indexes, try to specify the high-level column in theWHERE clause the query. This results in an index scan with at least one matchingcolumn.

• Use ORDER BY only when sequence is important: Code the ORDER BY clause whenthe sequence of rows being returned is important. Order only those columns that areabsolutely necessary in order to improve efficiency.

• Use BETWEEN rather than <= and >= : BETWEEN allows the optimizer to select a moreefficient 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 LIKEcan be imitated using a range of values. For example, for retrieving all employees with alast 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 dataaccess than a subquery.

• As a general rule, use the LOCK TABLE only after discussing its implications with DBAstaff. LOCK TABLE can significantly decrease an applications processing time byeliminating page locks, but will also make the tablespace unavailable to any otheraccess. It locks ALL tables in a Tablespace. The locks are held until a COMMIT orDEALLOCATE, 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 andefficient 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 onlyindexed 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 tobe processed. Do not have filtering in the application as it will consume more resourcesto pass a row to the application than to verify in DB2 that the row does not qualify yoursearch 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 willeliminate the greatest number of rowsA 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 theindexes.

ü Stage 2, which needs to obtain the information from stage 1, causes additionalCPU consumption. If your SQL contains only stage 2 predicates on an indexedcolumn, you can use that index-only in a nonmatching index scan, without indexscreening, which might be a very inefficient access path.

• Rebind your applications over time as the data changes. Rebinding will generally improvethe overall performance of your applications because the access paths will be betterdesigned based on an accurate view of the data.

• Let SQL do the work instead of the program. For example, code an SQL join instead oftwo cursors using program logic to join.

• Retrieve only the columns required, never moreLimit the columns being retrieved to those which the application actually needs. The CPUcost 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 thedifference between an index-only access path and an additional access to the datapages.

• Issue data modification statements (INSERT, UPDATE, DELETE) as close as possible tothe COMMIT statement, if possible

• Be sure to build a COMMIT strategy into every batch program that changes data. Failingto 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'tneeded.

• If you intend to update fetched data, you should specify FOR UPDATE clause inthe SELECT statement of the cursor definition. It decreases the possibility of deadlockand save the cost to perform lock conversions

• Use Compound SQL and Stored procedures for better performance and will minimizedata 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 toimprove recoverability.

•Use a simple table space only when the data needs to be mixed from different tables onone page.

• To improve performance, assign frequently accessed DB2 objects to different storagegroups 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 numberas 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 ormore partitions simultaneously (or one at a time while the other partitions are availablefor 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 asSEGSIZE 64. With fewer than 64 pages, define SEGSIZE as an even multiple of 4 asclose to the actual number of pages as possible.

• Assign one table per tablespace.

• Create tablespaces explicitly rather than implicitly (tablespaces are created implicitly bycreating 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 managementand better performance.

• USE WITH HOLD option with CURSOR, if the cursor needs to be used after theCOMMIT.

The COMMIT process closes all open cursors unless they are declared with theWITH HOLD option. These cursors must then be reopened and repositioned after eachCOMMIT in the batch application. To reduce the complexity of your application logic andto save the execution cost of cursor repositioning, you should use the WITH HOLD optionfor cursors declared in your batch applications.

• Control COMMIT Frequency





There is a trade-off between commit frequency and performance. Commitincreases CPU consumption and may increase I/O elapsed time due to cursorrepositioning overhead unless cursors are declared with the WITH HOLD option. Thedesired commit frequency can be stored in a DB2 table. This value can then be used inthe application program to determine when to commit. The commit frequency can bespecified differently for different periods of the day, for example, with low values duringthe 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 YESfor tables that are rarely used.

• Set PCTFREE and FREEPAGE to 0 for tables which will have read-only access (suchas 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 allowsDB2 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 inWHERE, HAVING, GROUP BY, and ORDER BY statements, and 3) it cannot be usedas an index.

• Avoid LONG VARCHAR if at all possible. It should only be used in cases where longstrings 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 WHEREclause.

ü Columns considered as keys





• Bad candidates for indexes:

ü Columns that are frequently updated

ü Columns with low cardinality (cardinality is the number of different values withinthe 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 inupdating. This causes an automatic edit against the WHERE clause when updatingthrough a view to prevent inadvertent inserts/updates outside of the clause.

• Do not use the LARGE Parameter. Instead use the DSSIZE parameter for largetablespaces.

• Create indexes for columns used frequently in ORDER BY, GROUP BY, SELECTDISTINCT, 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 ashared database, one could replace a single update PCB with a read or read-onlyPCB and another update PCB. The majority of application processing could residewith the read PCB and when an update is required, the data could be re-read andthen updated via the update PROCOPT PCB.

•

Use PROCOPT Effectively: The best way to reduce the overhead of lock contentionis simply to take less locks. A share lock does not cause contention between sharingusers; only update locks cause contention hence using correct values for PROCOPTis essential.

PROCOPT=G causes share locks to be acquired in the Coupling Facility, whilePROCOPT=R,I,D or A causes exclusive locks to be taken in the Coupling Facility. Ifoperation is read-only then use PROCOPT=G, or PROCOPT=GON instead ofPROCOPT=A. This reduces the amount of locking that IMS performs.

The read-only program can then recover from the error. PROCOPT=GON will use nolocks. PROCOPT=GOT will temporarily invoke locking if bad pointers areencountered.

PROCOPT=E: IMS programs can obtain exclusive access to an IMS database withthe IMS PCB option, PROCOPT=E.






• For best performance in the IMS environment, use the RENT compiler option. Itcauses COBOL to generate re-entrant code. You can then run your applicationprograms in either pre-loaded mode (the programs are always resident in storage) ornon-preloaded mode, without having to recompile with different options.

• Reduce the Number of DL/I Calls: Locking rates and contention are directly related tothe volume of concurrent, conflicting DL/I requests for shared resources, so one wayto 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 segmentD Path callF Get the first occurrence of the segment under its parent

L Get the last occurrence of the segment under its parentN Specifies that this segment is not to be replaced when segments are

replaced after a get hold callP Set parentage at this levelQ Enqueue the segment so no one else can change it until you are finished

with itU Limit the search for this segment on which position is to be establishedV 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 samesegment during a single execution.

Ø If possible, an attempt should be made to eliminate redundant or non productivecalls that result in GE, GB, or II status codes except where these status codesrepresent exceptional conditions.

Ø In order to reduce the large number of unneeded segments retrieved viaunqualified 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 parameterso that it becomes flexible to override them in exec JCL. Note that filename shouldn’tbe made symbolic parameter. Otherwise, the same filename might have differentnames (with different overrides) which is highly undesirable.

• There should not be any ‘SYSIN DD *’ statements. Place all the sort SYSIN cardsand other SYSIN cards required by program in a standard control card.

• There should not be any ‘SYSOUT DD *’ statements in the PROC. Instead, definesymbolic 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 theapplication doesn’t have one, standardize it and use it across all the PROCs thatcreate GDGs.

• Have a common set of step libraries for all the steps of a PROC. Generalize theselibraries 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. Definedefaults for these symbolic parameters in the PROC. These can be overridden inyour run JCL, if required. The advantage of having common STEPLIB is that youneed not override STEPLIB of each step in your run JCL. It’s enough if you justoverride the 3 symbolic parameters. If you want any step’s library different fromothers, then you can achieve it through step override.




• There are times to produce the hard copies of datasets by printing them on to aprinter and also at times may need to transmit some datasets (such as those whichcontains some reports) to a set of business people. It’s a good practice to check if adataset 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 orrandom access) can typically be greatly enhanced by proper specification of thenumber 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 themost 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 minimumof three sort work DDs. For very large files, always code the sorted data sets to becatalogued. The size of the sort work space allocations, if too small, may causedetrimental performance of the sort.

• Usage of SYNCSORT is recommended over other similar utilities, since it takes lessCPU 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 controlof the datasets

• Use the appropriate CLASS, REGION and TIME parameter for better performance

• Use TYPRUN=SCAN and check for JCL syntax, before submitting the actualprocessing (some installations have JEM, JSCAN, JJ etc editor comment for syntaxchecking). Before releasing to Production, make sure such statements are removed.

• Using RECFM=FB instead of RECFM=F reduces input/output operations and leadsto better performance.

mainframe performance guidelines

Documents