Testing MSP9 LP140 taking too long

Hello,

We're testing MSP9 in our development server. Our LP140 job normally takes 1 hour to run is now taking 16 hours.

Infor support has this to say:

With the version of LP140PD you have, it is now processing unpaid records behind the scenes and marking those records as "9" - CLOSED after running LP140 and LP197. The first time LP140 was run after applying the JT-1127592 CTP (which you have) only caused an increase on processing time because it's processing all unpaid records as well. But now that these unpaid records are also marked as CLOSED, they will not be included on the next LP140 process and should reduce processing time on the succeeding LP140 runs. My recommendation is that you run this cycle through Lp197 and perform another LP140 test to confirm that the run time is as expected.

We have performed LP197 and another LP140 to confirm run times as instructed but it is still taking 13 hours(no records processed).

We have tried copying and compiling back the MSP8 version of LP140 in dev. it is taking just as long. We thought that something in the data is causing the issue but this is the same data in PROD (still on MSP8) and it only takes about an hour there.

We've also tried truncating TAEMPTRANS/TAEMPSERV to just 2 years worth of data but still no go.

Any suggestions on what we can try / test next?

Find more posts tagged with

Infor Lawson Technology Group - Discussion

Comments

unknown

My install doesn't have LP. However I take it that the source is not COBOL?

unknown

Hi, assuming you also went to lsf 11 with this upgrade. We went to msp09 / esp11 this summer and we have not seen this issue with LP140, but I have a feeling our use of LP is much lighter than yours. I took a look at our TAEMPTRANS and TAEMPSERV tables anyway, and all our records are in status 9. Have you checked to see how many old records you still have on the new database that are not in status 9?

SELECT STATUS, COUNT(STATUS) FROM TAEMPTRANS

GROUP BY STATUS

Other things to try, if you have not already.

-Recompile new version of LP140 again, after deleting all the LP140 xml's in /map/default and /prsrc, and the LP140 executable in /obj

-Check rpt.cfg in /law/system folder, and if any of the "RUNTIME_" variables in there are turned on, try turning them off (sometimes writing the report files slows things down quite a bit). Also check the /prsrc folder and make sure there are not any unexpected LP140 files lurking, like a LP140.cfg. If you find one, rename it and recompile.

- Check that you are not about to run out of space in /law or /law/print

-Bounce the servers with msp09 on them

hrkb_2023.x_kbcmag__en-us.pdf

unknown

-take a look in the /system folder to see if there is anything funky in the logs

-check to see if the user monitoring that is part of ISS got turned on, if it is, try turning it off

jeanjacqueslerossignol

Some times Dev systems are undersized. Is the Dev system including the database server comparable to Production in terns of cpu, memory, etc. so your performance comparisons between Dev and Prod should be similar?

You could also have your DBA update database statistics and check indexes as incorrect indexes can result in full table scans causing long program run-time.

unknown

doesn't seem like the issue is with the cobol program because we've tried recombiling back the MSP8 version and it took just as long.

CEB Call - Semi-Annual Executive Review (1).mp4

unknown

Thank you all for the suggestions. Just updating on the issue;

tldr; Infor support acknowledges the issue and has issued a triage ticket JT-1336773 (What is a triage ticket?)

They kept asking us to rerun LP140, LP197, LP199 hoping those records get 'closed' but run times still has not improved.

I narrowed down the issue to TAEMPSERV and the EVENT_STATUS flag.

under MSP8, EVENT_STATUS changed from 1 to 0. no matter how many times you run LP197+LP140 afterwards, this stays 0 and processing time is good. DATE_STAMP/TIME_STAMP is not changed. This means they are not re-processed.

under MSP9, EVENT_STATUS is NOT changed. every time you run LP197+LP140 afterwards, timestamp on the table is updated but nothing else is changed. processing time is very long. this means LP140 is reprocessing those records.

Do you have any notes about TAEMPSERV.EVENT_STATUS ?

I do not know what job makes EVENT_STATUS =1

TES-EVENT-STATUS TES-SERVICE-STATUS

0 = Created 0 = Created

1 = Not Processed 2 = Processed

2 = Processed 9 = Closed

9 = Closed

unknown

What value are you using in the Rerun parm on LP140? For the records where the EVENT-STATUS is not changing, what is the value of SERVICE-STATUS in TAEMPSERV?

unknown

Rerun parameter always at 2=Yes. is there a reason to use 1=No?

We process all process levels with LP140

We tried rerun=1 and it tells us that "Rerun parameter must be Yes; employees in process"

We can specify rerun=1 after LP197. Process times is good but we don't see a reason to run LP140 after LP197.

For the records where the EVENT-STATUS is not changing;

EVENT-STATUS(1) SERVICE-STATUS is 9 no change except datestamp/userid. - LOTS of records

EVENT-STATUS(9) SERVICE-STATUS is 2 changed to 0 - some records have this (event-type 1)

EVENT-STATUS(1) SERVICE-STATUS is 2 changed to 0 - very few records have this (LP199 will later change this from 0 to 9)

unknown

We were always told to use Rerun = Yes also, and that is what we do here.

Here is what I think LP140 is doing:
In LP140, paragraph 123-RERUN-CLEANUP-TAEMPSERV, which executes when Rerun=Yes, updates all those timestamps on your EVENT-STATUS 1 / SERVICE-STATUS 9 records. It also sets the EVENT-STATUS from 1 to zero. But, there is a paragraph further down, 351-UPDATE-EVENT-RECORD, that moves 1 back into EVENT-STATUS. I think that is how you are getting all the 1/9 records with the timestamp updated.

What is confusing me is, if you run LP197 in update mode after LP140, paragraph 221-CLOSE-TES-RECS in LP197 should set all those EVENT-STATUS 1 records to EVENT-STATUS 9, update the timestamp and put "LP197" in the userid. And then, LP140 should not look at them anymore. Do any of your EVENT-STATUS 1 / SERVICE-STATUS 9 records have "LP197" in the userid? If the last program to touch the record is LP140, you should see the id of the user running the program in the userid.

inal_us_payroll_eligibilityreport_for_the_afforda.pdf

Copyright © 2025 Infor. All rights reserved.