ETL9.2:TL_ST_LOADER Kick-off Twice And Segment Size (Doc ID 2068504.1)

Last updated on OCTOBER 21, 2015

Applies to:

PeopleSoft Enterprise HCM Time and Labor - Version 9.1 and later
Information in this document applies to any platform.

Goal

While running the EOP_PUBLISH process, we notice the TL_ST_LOADER kickoff twice automatically within moments of each other for the same file that was in the TCD folder. The second loader process failed becuse it was trying to do some updates at the same time and table as the first process (see attached for errors). We only use the ELAPSED_ADD_TIME and we have never seen this before happened before. We recently applied maintenance bundles up to 18. Could this be caused by the new bundles? What could automatically trigger a second TL_ST_LOADER processing the same file?

 

What could automatically trigger a second TL_ST_LOADER processing the same file? At this point after verifying the tl audit and reported time tables, it seems that everything made it fine. We have recently added more employees to the time and labor process and we need to know if there's some sort of "threshold" or limit that automatically triggers the invocation of a second TL_ST_LOADER process. We noticed in the audit table that the ST_INSTANCE value from this two loader processes were different, so were the loaded times (date is the same). So, there must be a condition where a 2nd loader is invoked. We need to be clear on this as the trust and integrity of our system could be compromised if we don't understand this new LOADER behavior.We are seeing the TL_ST_LOADER process split with around 475 employees. Is this by design? Could you please check with development to see what is the actual amount that triggers more than one tl_st_loader process?I was tracing the EOP_PublishF process and saw and interesting call to the PSOPTIONS table making a reference to %MaxSegmentSize, which is set by default to 10,000,000. According to PBooks, this is the approximate size of the uncompressed XML data generated when the message is published. Based on the IB service ours seem to be larger than that and I belive this may be why the difference is being split into two files. Since the EOP_PUBLISHF checks for this param, perhaps it could be increased just enough to handle our file, with the understanding that it is a global setting.
 

Solution

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms