Performance issues with Y2RTTSK in runtime objects

Products

• CA 2E

Issue/Introduction

The Y2RTTSK module provides date/timestamp functionality for several programs.

The program's performance has degraded significantly since upgrading to either CA 2E 8.7.3 or 8.7.4.  After several calls, it now hangs for as long as 40 minutes, compared to under two minutes in pervious CA 2E versions.

Environment

CA 2E 8.7.3 and 8.7.4

Cause

In summary:

• Due to the runtime program Y2RTTSK attribute change from OPM (Original Program Model) to ILE (Integrated Language Environment), it is taking a longer time to run as ILE
• In 2E 8.7, Y2RTTSK was OPM COBOL and was working fine and giving the best results
• In 2E 8.7.3, as part of 8.7.3 feature "Handle Timestamps with Increased Microsecond Precision", the 2E Engineering team provided Y2RTTSK with SQLCBLLE, which is of ACTGRP QILE.  This caused a performance issue when the calling program is an OPM program and calling this Y2RTTSK multiple times in a loop

Resolution

Please contact Broadcom Support and requested PTF Y287427243.

Additional Information

PTF Y287427243 provides Y2RTTSK as SQLRPGLE ILE object with ACTGRP as *CALLER and also at the end RETURN statement. This allows Y2RTTSK to perform well regardless if the calling program is OPM or ILE. If the calling program is OPM, then this will run in DFTACTGRP and if the calling program is a QILE activation group, then this program runs in the QILE activation group

Here is the logic of SQLRPGLE(Y2RTTSK): 

• If YTIMSTPRFA data area value is *OLD then JOB.*TIMESTAMP is loaded as "yyyy-mm-dd-hh.mm.ss.uu0000"
• If YTIMSTPRFA data area value is *NEW then JOB.*TIMESTAMP is loaded as "yyyy-mm-dd-hh.mm.ss.uuuuuu" (To get this milliseconds precision we used SQL CURRENT TIMESTAMP keyword)

As it is a run-time object, there is no prerequisite and the PTF can be used with CA 2E 8.7.3 or 8.7.4.