Performance approach on ZOS

Performance approach on z/OS application In this article I will briefly present the method I follow when analyzing for optimization a z/OS application. I present this method here because I think that this could be useful even in system which are not mainframe. For lenght reason i couldn’t go deeply into details, (however on thesite you can find a document on coding standards that is possible to use to obtain good performance).

Going back to the subject, the activity goes trough some phases.


 * Set-up Here we need to understand the expectation and, based on this to plan and prepare the work. Usually the main activities are:
 * Define scope of work
 * Define client expectation
 * Review existing tool and data
 * Define strategy of work
 * Define a plan to share with the client
 * Set-Up the work team


 * Measure Here we prepare all the tools, to measure the characteristics of the system, if possible we gather and organize already existent measures:
 * Define tools and sources for getting data
 * Gather data -This phase is often really complex on the practical side, because, even if sources and tool are well defined, often there is a lack in global vision and data are spread on excel sheet, local databases, central databases… The biggest part of the work is to be able to extract the most interesting data and to put them in an easy and readable way. We may have to dig into:
 * System Data. For example the CPU usage during the day. This category of data depends on the scope of work;
 * Data on On-Line usage (CICS, IMS). usually, at first, I first ask data on the CPU and response time for each transaction Then, once found the problem, it is possible to go in more detail with specific data;
 * Data on Batch (night processes). Here it is quite important the job sequence, their CPU consumption, their execution time and their I/O. Then it is important to obtain in a readable way the scheduling plan (i.e. the list of real dependencies).
 * Data on DB. Usually for a first screening I usually need: physical design, Plan_Table, lock logs and Master log (for DB2 systems);
 * Functional data. In my case, when I work for banks, I usually ask the number of daily transactions, the number of physical branches, the number of clients, of current accounts, of loans, of daily payments, the critical days and possibly the business growth plans


 * Performance log. Here we need to create a document which list all the known (and newly found) problems and the planned development to solve this problem. If the document doesn’t exist we need to create it, if it exists we should modify it to get data in the easiest way:
 * Prepare the analysis tool and load data into them.
 * Create TOP 10 Lists. You should create a set of TOP 10 list, such that you will be able to avoid loosing time in changes which give small added value to your work. As example top 10 transactions for CPU, consumption, top 10 for elapsed time…
 * Together with the top 10 lists you need a list of most executed programs/transactions in a time span that range from, few days to one week. If a transaction is not on the first 50, for example, you should consider it only if requested.


 * Analysis in the three basic areas. That means analysis of Databases, batches and online transactions. Following a list of point of attention:
 * DB2
 * Physical DB
 * Partitioning
 * Data Clustering
 * Tablespaces definition (e.g. compression, freepage, pctfree, lock size)
 * Index study (delete unused indexes, redefine wrong indexes). Usually it is possible to carry on this analysis by checking data contained in the PLAN_TABLE
 * Define correctly Buffer Pools
 * Check policies for deletion (and tape storage) of hystorical data
 * Check maintenance standards (IMAGE COPY, RUNSTATS..)
 * Reengineering of SQL statements inside programs, with particular care on COMMIT usage.
 * Batch
 * Check of program restartability and commit policies/standard (if needed it is possible to bypass this check by using ARC product). Definition of corret commit frequencies, based on time of the day;
 * Reduction of nightly error, by direct modification of job quality, if needed;
 * Reengineering of jcl and batch processes, by deleting un-needed links and enhancing parallelism;
 * Determination of critical path (by practical analysis) and reengineering of job on the critical path.
 * On-line. Usually in this area the work is not so strong, unless there are main problems. Mainly optimization is obtained by changing the program code and the SQL statements. If more is needed, usually the work is carried on together with system analyst of CICS/IMS.


 * Assessment preparation. This is done by:
 * Going trough check-lists for optimization (you can download the check-list from this site)
 * Preparation of the top 10 list, with analysis
 * TOP CPU consumption (both on-line and batch)
 * TOP Elapsed time (both on-line and batch)
 * TOP Bath Job CPU
 * TOP Batch Job Elapsed
 * Most executed transactions
 * Most executed programs
 * List of proposed work/problems on the DB part. Development is usually both on physical DB and on programs to change their SQL code.
 * Proposal for a new batch plan


 * Performance as a process. Once analysis is closed. We should leave the organization the decision about how to proceed if they need our further support or if they want to go on alone. What is important is that you should make the stakeholders understand that “performance” is a process and it doesn’t finish, once the modifications are done. It is important to:
 * Define standard – in case of z/OS system we should define standard on how to design a program, a jcl, a table, a SQL statement.
 * Build knowledge of people by:
 * Specific Training
 * Changes in the organization – in a big installation where I worked we created a “performance team”, a “war room” with an analysis committee and we assigned a performance responsible to each team.
 * Improve quality of software trough creation of control committee, inspection processes and the usage of automatic control tool.