latm (PrcTPCrash): Received death notification of lacobrts

We have a few users that are getting kicked out of Portal. When I check the latm.log file I am seeing the error below. It happens mostly with PO20, but it has happened with other programs. Has anyone else seen this error below? What did you do to fix it? Thank you.

Tue Jan 16 16:59:36 2018: latm (PrcTPCrash): Received death notification of lacobrts, Uid=36, Pid=13556
Tue Jan 16 16:59:36 2018: Program Code = PO20 , DataArea/DataID = PROD
Tue Jan 16 16:59:36 2018: ERROR: Exited with error code 1

Find more posts tagged with

Infor Lawson Technology Group - Discussion

Comments

bhillz

Do you have any other messages in lase, auth or ladb logs?

Does MSS/ESS or other portal apps continue to run fine?

How about Batch jobs? Do they run unaffected?

Any other symptoms, like JVMs need to be restarted?

What version of LSF, Apps, RQC are you running?

unknown

It isn't affecting batch jobs or MSS/ESS. I don't see any errors in lase or ladb logs. We don't have to restart any JVMs. Environment version 10.0.9, application 10.0.7 and RQC is 10.00.06. Thank you.

0712050809193544.doc

unknown

We too have had numerous issues with PO20, though with the 9.x versions more than v 10.x. We tried recompiling, having the network traffic reviewed and changed browsers. None seem to have an impact. However, we did notice that our Procurement department typically opens multiple (5 - 6) tabs and/or separate browser occurances for access. We believe this was the problem. Too many open connections to PO20 forcing many buffered instances of the one application. Having said that, we could not prove it. Our environment changed. As did the browsers. Most of which patched their memory leak issues.

unknown

KB 1943571 might be relative.

bhillz

Do you use Punchout, especially with additional extrinsic variables?

unknown

Thank you for the responses everyone. We do have Punchout, but I am not sure how that relates to this problem. I will check the KB article.

unknown

We too were having this issue and could only replicate the crash with a very particular purchasing routine with one buyer. It appears that CTP 116060 fixed it for us. I say 'appear' because the patch just went to production last night but we could not replicate the error in test with this patch installed. I should know for sure today. Prior to the patch we were on PO20PD 138.2.57.1.47.1.44 Now we are 138.2.57.1.47.1.55 Good luck!

d-hofmann

We recently had issues with LATM crashes. For us it was more than just PO20. I could sit and watch tmmon and spawn new processes when programs went into waiting. Sometimes I could keep the system up and sometimes it would eventually crash. We are on Lawson 10, we had to make some changes to Websphere and apply some LATM patches.

Make sure to check if you getting any Websphere Core Dumps?

unknown

In addition to the death of lacobrts if you find Database Error(94) Additional Information 4098 in the log file- look to validate the table, then have the DBA's check the triggers on the table... your upgrade/patch might not be compatible to your triggers.

Marilyn Sizemore

Do you ever go to the grocery store during peak times and realize there is a long line at the checkout? And you think.....they should really open another checkout lane to make this process faster.

Well, there's a chance that this is what is happening in your system. How will you know that this is the case? During peak business activity - or when they start complaining that PO20 is too slow, fire up tmmon and take a look at the status of the processes running for latm and lacobrts. You may have 20 PO20 latm processes waiting on a single lacobrts transaction to complete. In a healthy system, the exec status should come and go. If you see processes stuck with a status of 'waiting', or even worse 'zombie', your users will start to notice. They are probably thinking you should really open another lane to make this process faster. <grin>

Out of the box, all your latm requests (think shoppers) will spawn a single lacobrts process (think checkout lane). As users are working in LSF forms, you can end up with more latm requests than the lacobrts process can handle. If lacobrts cannot keep up with the demand, the latm requests will begin to queue with a status of 'waiting'.

You can use the LSF utility pgmtrndef to configure an online form and define the number of users that the program can support simultaneously. If the 'number users' value in this utility for your form is set to blank, then a single lacobrts is used for all user requests. This can generate a bottleneck, resulting in the issues you are experiencing. You can change this value to spawn a new lacobrts process when users' latm processes are in a waiting status. The number you set will depend on your business, number of users running processes, and the number of cobol licenses you have setup on your system. Changing the value to 1 for PO20 will provide a new lacobrts process when 1 latm process is queued, 2 when 2 are queued, and so on. The more lacobrts running for a program on your system, the more cobol licenses will be used. I'm curious to hear back from other admins what number they like to start with. Sometimes it takes a village. When you update pgmtrndef, you will need to restart your system for it to take effect, so this will require LSF downtime.

For more information on how to use this utility, please reference the LSF Server and Maintenance Guide for your version of LSF. Hope this helps.

d-hofmann

Nicely put. Support has me Change values to 3, but not down to 1. I will try that.

unknown

I was not aware of pgmtrndef. Thanks for the info.

unknown

we had similar issues with po20, rqc and bunch of other programs that were heavily used and we changed setting to 3 per support and have not had any trouble since. @Marilyn C Sizemore Nicely put on how it works and impacts.

unknown

Please clarify the 'setting to 3' you changed. I want to confirm our value with my system admin.

Copyright © 2025 Infor. All rights reserved.