Performance Optimization of translated application

The most common performance problems are:

DB2 on Mainframe has commnunication lags

The communication between DB2 on mainframe and external Java / C# applications is usually slow. The application's performance may significantly improve by moving the database to another machine - perhaps as much as couple of orders of magnitude. An alternative approach would be to deploy the Java application on the mainframe.
The effects of this communication lag can be measured by switching SoftwareMining PROFILER on to generate timing logs, and checking the logs for Connection and SQL retrieval times.

Other database performance issues

Additionally, the following should help reducing impact of database communications :

• For Java applications: Use type-4 Jdbc Drives
• For C# applications: Use libraries utilizing MSSQLServer, Oracle or ADO drivers (rather than ODBC)
• Where possible reduce database communications: For example the following SQL Statement does not retrieve any stored data, it just returns time with better precision:

      EXEC SQL SET :WS-DATE-TIME = CURRENT TIMESTAMP 

  
  The above call can be replaced with a local call to a Java (or C#) utility to perform the same function, e.g. DateUtil.getDb2Date()
  NOTE: The default configuration for SoftwareMining CORECT Translator will do this automatically.



• Review SQL Code
Due to the low cost of SQL communications, some COBOL developers may have used multiple database calls when one would have been sufficient. For example:

    EXEC SQL SELECT id FROM MASTER_TABLE where name = 'ABC' 
...
    EXEC SQL SELECT * FROM CHILD_TABLE where id = :MASTER_ID 

The cost of above statements could be cut in half by using a the following statement, ie by changing the program to make a single call to the database:

    EXEC SQL SELECT * FROM CHILD_TABLE WHERE id in (SELECT id FROM MASTER_TABLE where name = 'ABC') 

Translation of VSAM KSDS files to Database table

On mainframe, VSAM is a file-access, it does not require a database connection to be setup and it does not require queries and results to be marshalled (usually via TCP/IP). As such accessing VSAM files is faster than Database. (Storing data in databases have other HUGE advantages). There are several approaches to overcome performance problems resulting from migration to VSAM to SQL databases:

• Optimizing database - by adding additional indexes
• Optimizing Object-Relational API's - adding new conditions. See Performance Optimization Techniques in VSAM Translation Guide
• When the data is accessed only by one program at a time (ie not requiring Transaction Management), a file based approach can be used. To do this you can change the super class of the relevant Object-Relational class from SQLWrapper to IndexedFile

In built PROFILER

SoftwareMining's framework libraries have a built-in Profiling system.
The focus of the profiler is to show which set of API's may be causing bottlenecks and performance issues. The profiler is most useful for detecting bottlenecks in batch programs.

Enabling the Profiler
Place the following line in corect.properties configuration file to enable the profiler.

PROFILE_RUNTIME=true

Also, make sure the Log4j/Log4net has been set to write out "INFO" level logs.

What to look for in the generated logs:
look out for lines relating to timings on the following

• SQL & Database communication (e.g. ConnectionFactory, ESQLProcessor)
• SQLWrapper times (to do with migration of VSAM data to SQL Database)
• Sequential File Access
• SortManager
• CBLField.resetWrapperOffset (used in OCCURS DEPENDING)

Timing Business Logic Performance

The translated application uses the following Log4j (C# log4net) log levels:

• TRACE
- traces library functions. for example for sqlProsessor.executeQuery() statement it will write out statement relating to
• retrieving connection from pool
• preparing SQL Statement
• executing SQL Statement
• Assigning value of column-1 to variable ...
• DEBUG
Writes out entries into (and sometimes exits from) the methods in translated code.
• INFO
Used for general information including PROFILING information,
• WARNING
- Continue-able warnings. These are mostly generated when the following flag has been switched on in the corect.properties configuration file.

SAFE_MODE=true

• ERROR
- Errors

With the right configuration of the logging system, the "Trace" or "DEBUG" log levels can be used to help identify where most of the time is being spent.

What to look for in the generated logs:
Switch log level to trace, and look in log file for the following type of entries

Created new database connection ... 

• For batch programs, there should only one instance of the above line.
• For online programs, the number of entries can be more, depending on how many times the program is executed concurrently.
However as programs are concluded, the connections should be placed in a connection-pool. The size of the pool is allocated in db.properties file.

Increasing performance of Batch Programs: Parallelization

Whether the application is deployed on a Cloud or local servers, these days processing power is cheap. I.e. By slight manual adjustments, batch programs can benefit from multi-threaded / multi-processor approaches for significance performance gains. SoftwareMining has already built parallelization techniques into our framework libraries to provide a quick path to parallelization and multi-threading. Please see How-to parallelize translated Batch programs

  © 2023 SoftwareMining is a trademark of Software Modernization Technologies Ltd (UK). Registered in England company no: 07300248. Reg Offices: 79 Stevens House, Jerome Place, Kingston Upon Thames, KT1 1HX, United Kingdom.