GE Capital Bank, Gdansk, Poland

VisionPLUSTM Document

GE Capital Bank, Poland

Poland Batch Performance Tuning
VERSION HISTORY Version No. 1.0 1.1 1.2 Date 22/08/05 10/10/05 11/10/05 Changed By Amit Rajendran Amit Amit Changes Made Draft Version Added AMLD flow Added fix list in Remarks Column

Classification: GE Internal

GE Capital Bank, Gdansk, Poland

1 Table of Contents

1 TABLE OF CONTENTS...........................................................................................................................2 2 NEED FOR THE PROJECT..................................................................................................................5 3 OPTIMIZATION PLANS.........................................................................................................................6 4 TECHNICAL IMPLEMENTATION.......................................................................................................8 5 REMARKS...............................................................................................................................................11

Change History:Version 1.0 : Original Implementation document

Version 1.1 changes dated 10/10/2005

Last Update: Aug 22nd, 2005 Page 2 of 11 Batch optimization document

GE Capital Bank, Gdansk, Poland

Added the AMLD build flow Version 1.1 changes dated 11/10/2005 Added the list of fix/jcl/opc related details

Last Update: Aug 22nd, 2005

Page 3 of 11 Batch optimization document

GE Capital Bank, Gdansk, Poland

1. PURPOSE OF DOCUMENT

The objective of this document is to give various suggestions that may finally lead to reducing the batch window, Schedule Resources, minimize the CPU Time, Minimize I/O Time etc. It aims at bringing down the costs and at the same time reduces pressure on limited resources in conflicting demands; minimize the CPU Time, which is consumed. The aim of Performance Tuning is to improve performance within the constraints of the existing environment (E.g. To reduce the batch window without affecting Batch and meeting SLAs.), and that to a certain extent this requires a choice of tradeoffs performance versus DASD space, and program performance versus resource (CPU, storage...) usage .The throughput will depend on this. It is also important to acknowledge that tuning is an investment and requires a significant amount of resource, both human and machine time. Tuning should be an ongoing process with a pre-defined methodology, not just a fix for deteriorating performance.

Last Update: Aug 22nd, 2005

Page 4 of 11 Batch optimization document

GE Capital Bank, Gdansk, Poland

2 NEED FOR THE PROJECT The need for the Batch Performance Tuning is two-fold: It aims at bringing down the costs and at the same time reduces pressure on limited resources in conflicting demands. Batch performance tuning is not a one-time activity like any other development task. It is a continuous process and over the period of time we need to follow certain steps to successfully execute the batch performance-tuning project. This approach could be part of the regular performance management rather than an activity to solve batch window problems. It could also be used as a quick health check to analyze batch I/O performance across the window. This type of analysis can be performed over the period of time.

Last Update: Aug 22nd, 2005

Page 5 of 11 Batch optimization document

GE Capital Bank, Gdansk, Poland

3 OPTIMIZATION PLANS
3.1 Batch window level- Optimization.

3.1.1We have to check the position of the jobs where they are running. By placing these jobs at more appropriate positions we can reduce the batch window of the system. 3.1.2 We have to check the dependency of the jobs in the batch so that we can remove the unnecessary dependencies and can make the jobs to run parallel as the jobs running parallel will take less time and help us in reducing the batch window. 3.1.3 We have to check if we can place the backup jobs out of the batch window as the backup jobs are simply taking the backup of yesterdays data and we can run these jobs before the batch. So we need to identify the jobs which can me moved out of the critical batch window.
3.2 Job level optimization.

3.2.1 This can be achieved by adding faster IBM utilities like SORT and ADRDSSU in place of IDCAMS and ARU020. 3.2.2 In the job level optimization we can break a long job into smaller jobs, which can run parallel. There are certain jobs in the batch in which we have a large number of steps and so the jobs are taking a lot of time to execute. We need to check the dependency among the steps in the job, so if the job can be divided it into multiple jobs then we can run them parallel and reduce ample amount of time. To name a few PPLGRD42,PPLGSD10,PPLGMD12 3.2.3 There are certain jobs in which we are running unnecessary steps (Like generating the normal vision plus reports which are also being generated by our customized programs). So we need to communicate with the business and find out those unnecessary reports so that they could be switched off. 3.2.4 Stopping redundancy by removing some jobs, eg;ARU040 and ARD040 can be made to run in 2 jobs. The programs ARU040 and ARD040 are running many times :eg:RD14 ,RNMI and DUI, need to check if this can be run in 1 job.
Last Update: Aug 22nd, 2005 Page 6 of 11 Batch optimization document

GE Capital Bank, Gdansk, Poland

3.2.5 Changing the AMLD build structure. The current design is to build the dataset from scratches. Rather than starting it from scratch the dataset will be open in input output mode and only todays trasactions will be added to it.

3.3

Program level optimization.

3.3.1 In the program level optimization we need to remove all the unwanted displays from the programs. It will reduce the total number of writes and will help us to save the CPU time and reduce the MIPS. 3.3.2 Checking the logic of the program to find out if we can reduce the number of reads and writes in the program. This involves changing the access methods and making the logic simple. 3.3.3 Rewriting some programs in the system . eg: POLIH18, POLIH09A

Last Update: Aug 22nd, 2005

Page 7 of 11 Batch optimization document

GE Capital Bank, Gdansk, Poland

4 TECHNICAL IMPLEMENTATION 4.1 Changing the build structure of AMSS/AMSL.

Current Design The job PPLGRSM1 builds the file AMSS(small statement file ) and along with that we build AMSL which is the large statement File on a daily basis .AMSL contains all the transactions for the last 1 year.So the AMSL build job(PPLGRSS1) will run for 1 hour as we are rewriting the whole the transactions in the sytem for the past 1 year. Proposed Design We can run the job PPLGRSS1 either end of month or end of week(we can select the sutable timing when the system load is less) we can dump the data from AMSS to AMSL .This change requires lots of testing .

The above change will require rewriting the existing 3 programs in the system to make them use AMSS as well as AMSL to find the transaction details..These programs use AMSL on a daily basis.
1/. POLIH14E 2/. POLIH026 3/. POLIH16

4.2

Starting MBS immediately after CMS files are available. There are 2 ways to do this 4.2.1. Feeding the MBS stream with one-day-old POMR, the advantage of this will be CMS and MBS will run parallel. This needs lots of analysis as MBS has disb-date concept and it might effect some functionalities 4.2.2. Starting MBS immediately after PPLGROPN (cms files are available). This will require the above AMSS/AMSL change.

Last Update: Aug 22nd, 2005

Page 8 of 11 Batch optimization document

GE Capital Bank, Gdansk, Poland

4.3

Scheduling some reporting jobs to run monthly/weekly. Jobs running daily can be scheduled weekly/Monthly This mainly involves The job PPLGX14A runs for 1hr 30 mins ,we have to identify such job and reschedule then either towards weekend/month end or run it outside the critical window. Many more jobs are there which can be run outside critical wondow PPLGRLT1 , PPLGDISP Using faster IBM utilities like SORT/ADRDSSU Replacing SORT/ADRDSSU with IDCAMS/ARU020 which will help taking backups and file copying faster. Cutting down unnecessary displays in programs Removing the unnecessary displays- This will require analysis of every program to cut out all the displays, by saying this we will keep the ones which are necessary. The fix for some of the programs are already in place Removing the Give ,Take steps from CICS interface jobs The GIVE and TAKE step can be removed for job the PPLGROPN and PPLGRCLS ,we will need testing for this. OPC schedule changes to remove unwanted dependencies. OPC related changes for example currently CMS waits for ASM batch. This can be changed as only 1 file comes from ASM. This points needs more analysy in terms of system load also. Cutting down the number of steps in bigger proc. Splitting jobs All the jobs in MBS runs with more than 15 steps on each job .The aim is to help us restart the job faster incase of an abend and also to make it precise. Build structure of AMLD Current Design : The life to date file (AMLD) is build from the statement files AMOS ,AMSS and AMSL. The program ARD245 takes data for each account from the above 3 files and sort in based on the purchase date. This process of building AMLD takes lots of time as the file is build daily from Scratch.

4.4

4.5

4.6

4.7

4.8

4.9

Last Update: Aug 22nd, 2005

Page 9 of 11 Batch optimization document

GE Capital Bank, Gdansk, Poland

Current Flow

AMOS

AMSS

AMSL

ARD245

AMLD

Proposed design: The daily flow will be changed in order to increase the performance of the AMLD build. A new program which will take the daily posted transactions(ATPT) and generated transactions(ATGT) will be taken and merged to the existing AMLD file. This will take care of the time it consumes when we build the file from scratch. This also takes care of the AMPS reads which it used to perform. Proposed Flow ATPT ATGT

ARGD245

AMLD
Page 10 of 11 Batch optimization document

Last Update: Aug 22nd, 2005

GE Capital Bank, Gdansk, Poland

5 REMARKS
Attaching the fix list

fixes.xls

Last Update: Aug 22nd, 2005

Page 11 of 11 Batch optimization document