What to do if Landmark is crashing with core dumps

, ,

Here are a few mitigation procedures to use when Landmark applications are crashing or performing very slowly and throwing core dumps on the server.

 

First, check the environment.properties file.  Validate that file is pointing to the correct version/location of Java.  Sometimes, Java is updated on the server, and the environment.properties file is not changed accordingly.  It’s not a guaranteed issue, but should be validated and resolved if found.

 

Secondly, make sure there is adequate heap space provided to the jvm.  Here are some examples for heavy processing:

 

com.lawson.was.nodeagent.jvm-init-mem=1024

com.lawson.was.nodeagent.jvm-max-mem=3072

com.lawson.was.dmgr.jvm-max-mem=4096

com.lawson.was.dmgr.jvm-init-mem=2048

com.lawson.was.<app Server>.jvm-init-mem=3072

com.lawson.was.<app server>.jvm-max-mem=12228

 

àThese values will be deployed every time a CU is applied, so you don’t have to keep updating them

 

Be sure to recycle the Landmark application server once these changes are made.

 

Note that clustering Landmark WebSphere would not do any good.  Landmark applications behave very differently from Lawson applications, and it would only waste resources to vertically scale.

 

ProcessFlow Inbasket No Action

, ,

A user accesses their inbasket they can see the workunit and the associated data, however when they approve the requisition it leaves their inbasket view in portal with a success message.  The workunit does not move on, nor does it show action has been taken within the workunit.

 

Also, no actions can be taken from that workunit.

 

Error from the lps.log

 

Thu Jun 16 14:19:48 PDT 2016 – Message “com.lawson.bpm.errors.ErrorMessages.com.lawson.rdtech.framework.ProcessFlowException: Unknown security exception has occurred.

at com.lawson.bpm.eprocessserver.grid.ProcessFlowExecutor.getActorContext(ProcessFlowExecutor.java:651)

at com.lawson.bpm.eprocessserver.grid.ProcessFlowExecutor.getActorContext(ProcessFlowExecutor.java:617)

at com.lawson.bpm.eprocessserver.grid.ProcessFlowExecutor.processProcessFlowQueue(ProcessFlowExecutor.java:409)

at com.lawson.bpm.eprocessserver.grid.ProcessFlowExecutor._executeFlowPrivate(ProcessFlowExecutor.java:332)

at com.lawson.bpm.eprocessserver.grid.ProcessFlowExecutor._executeFlow(ProcessFlowExecutor.java:212)

at com.lawson.bpm.eprocessserver.grid.ProcessFlowExecutorProcessorImpl.sweepPrivate(ProcessFlowExecutorProcessorImpl.java:284)

at com.lawson.bpm.eprocessserver.grid.ProcessFlowExecutorProcessorImpl.processMessage(ProcessFlowExecutorProcessorImpl.java:81)

at com.lawson.bpm.eprocessserver.grid.ProcessFlowExecutorProcessorImpl.runPrivate(ProcessFlowExecutorProcessorImpl.java:186)

at com.lawson.bpm.eprocessserver.grid.ProcessFlowExecutorProcessorImpl.run(ProcessFlowExecutorProcessorImpl.java:150)

at java.lang.Thread.run(Thread.java:744)

Caused by: com.lawson.security.interfaces.GeneralLawsonSecurityException: Unknown security exception has occurred.

at com.lawson.interfaces.security.LawsonSecurityFactory.setRunAsUserOnDuplicateContext(LawsonSecurityFactory.java:1549)

at com.lawson.bpm.eprocessserver.grid.ProcessFlowExecutor.getActorContext(ProcessFlowExecutor.java:634)

… 9 more

Caused by: java.lang.reflect.InvocationTargetException

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:606)

at com.lawson.interfaces.security.LawsonSecurityFactory.setRunAsUserOnDuplicateContext(LawsonSecurityFactory.java:1545)

… 10 more

Caused by: com.lawson.security.authen.SecurityAuthenException: com.lawson.security.authen.LawsonUserContextImpl.security.authen.actor_does_not_support_run_as

at com.lawson.security.authen.LawsonUserContextImpl.setRunAsUserOnContext(LawsonUserContextImpl.java:1497)

at com.lawson.security.authen.LawsonUserContextImpl.setRunAsUserOnContext(LawsonUserContextImpl.java:1460)

at com.lawson.security.authen.LawsonUserContextImpl.setRunAsUserOnContext(LawsonUserContextImpl.java:1451)

at com.lawson.security.authen.LawsonUserContextImpl.setRunAsUserOnDuplicateContext(LawsonUserContextImpl.java:1592)

at com.lawson.security.authen.DataCtxUserCtxWrapper.setRunAsUserOnDuplicateContext(DataCtxUserCtxWrapper.java:432)

… 15 more

” not found.

 

 

 

Resolution:

The lawson user does not have Run As enabled.  Infor Security Administrator by default has the enable Run As set to “NO” for the lawson user.  When a change is done on the lawson user and saved in the Infor Security Administrator the run as gets flipped back to “NO” in Landmark.  Go to Infor Security Administrator and change the Enable Run As to “YES” save it.  Restart LPA and Async grid nodes.

 

 

Keywords:

 

Using jobdef to distribute job files in Lawson

, ,

In LID, type in jobdef, select a user and job name, then F6 >> B. Report Distribution

As you can see, this job isn’t being distributed beyond the prt file that is produced in the users print manager:

You have three options to None, direct to a printer, or to a distribution group:

If we use a distribution group, a distribution group consists of a list of users which can all have different printers setup under them within this group:

The printer itself has to be defined in printer definitions (prtdef) as well as setting up in the distribution list group definitions (dstlistgrpdef)

 

In this example, if the job definition (jobdef) was set to BENEFIT distribution group and ran, it would auto print to PRINTER123 under the lawson user.  All other users are not set so it wouldn’t print to them.  That’s it!

If your organization still heavily relies on Lawson recurring/custom jobs and are looking to support or migrate those jobs to IPA, which is harder and harder to find individuals who have all the skillsets to do so, we recommend you look into hiring a Lawson consultant team who offer managed services at a fixed monthly rate.

These Lawson teams have a wider range of expertise and knowledge and are ideal for larger organizations but also are great for smaller ones that don’t need a dedicated Lawson employee on-site that may only be an expert in 2-3 portions of Lawson.

Lawson Security – No Programs Found with All Securable Types enabled

, ,

In Lawson Security, you may come across a problem where no programs are found with any securable types enabled. This is a simple fix. Follow the steps below to learn how to fix security not registering Lawson (when given all securable types):

When editing the class select Add Rule, then in the Securable Types Online, add all top system codes (HR, AP, TE etc.) as shown below:

Next, you will need to validate that the objects are added:

Clear Server cache in LSA, Clear IOS cache in Portal.

Logout then log back in and test again. This should enable all and solve the issue.

 

Good luck!

LBI Error in validating session

, ,

After a system outage, or maintenance, or reboot of LBI, you may encounter this “Error in validating session” error message when trying to navigate around LBI.  If you receive this message, the first step is to check the WebSphere systemout.log.  If you are seeing messages such as “Failed to obtain DB connection from data source” and “Could not retrieve datasource via JNDI url”, this could simply mean that the IBM services didn’t come up in the proper order.  The solution is to bring all the services down (order doesn’t matter), then bring them back up in the proper order, ensuring that each one is completely up before you move onto the next one.  That proper order is: Cell Manager, Node Manager, then Application Server.

[9/7/22 13:18:35:153 PDT] 0000009b ErrorLogger   E org.quartz.core.ErrorLogger schedulerError An error occured while marking executed job complete. job= ‘LBIAdmin.133’

org.quartz.JobPersistenceException: Failed to obtain DB connection from data source ‘ejs’: java.sql.SQLException: Could not retrieve datasource via JNDI url ‘java:comp/env/jdbc/LawsonRS’ javax.naming.ConfigurationException: A JNDI operation on a “java:” name cannot be completed because the server runtime is not able to associate the operation’s thread with any J2EE application component.  This condition can occur when the JNDI client using the “java:” name is not executed on the thread of a server application request.  Make sure that a J2EE application does not execute JNDI operations on “java:” names within static code blocks or in threads created by that J2EE application.  Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on “java:” names. [See nested exception: java.sql.SQLException: Could not retrieve datasource via JNDI url ‘java:comp/env/jdbc/LawsonRS’ javax.naming.ConfigurationException: A JNDI operation on a “java:” name cannot be completed because the server runtime is not able to associate the operation’s thread with any J2EE application component.  This condition can occur when the JNDI client using the “java:” name is not executed on the thread of a server application request.  Make sure that a J2EE application does not execute JNDI operations on “java:” names within static code blocks or in threads created by that J2EE application.  Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on “java:” names.]

at org.quartz.impl.jdbcjobstore.JobStoreSupport.getConnection(JobStoreSupport.java:575)

at org.quartz.impl.jdbcjobstore.JobStoreTX.triggeredJobComplete(JobStoreTX.java:1320)

at org.quartz.core.QuartzScheduler.notifyJobStoreJobComplete(QuartzScheduler.java:1490)

at org.quartz.core.JobRunShell.completeTriggerRetryLoop(JobRunShell.java:392)

at org.quartz.core.JobRunShell.run(JobRunShell.java:276)

at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:520)

* Nested Exception (Underlying Cause) —————

java.sql.SQLException: Could not retrieve datasource via JNDI url ‘java:comp/env/jdbc/LawsonRS’ javax.naming.ConfigurationException: A JNDI operation on a “java:” name cannot be completed because the server runtime is not able to associate the operation’s thread with any J2EE application component.  This condition can occur when the JNDI client using the “java:” name is not executed on the thread of a server application request.  Make sure that a J2EE application does not execute JNDI operations on “java:” names within static code blocks or in threads created by that J2EE application.  Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on “java:” names.

at org.quartz.utils.JNDIConnectionProvider.getConnection(JNDIConnectionProvider.java:166)

at org.quartz.utils.DBConnectionManager.getConnection(DBConnectionManager.java:111)

at org.quartz.impl.jdbcjobstore.JobStoreSupport.getConnection(JobStoreSupport.java:553)

at org.quartz.impl.jdbcjobstore.JobStoreTX.triggeredJobComplete(JobStoreTX.java:1320)

at org.quartz.core.QuartzScheduler.notifyJobStoreJobComplete(QuartzScheduler.java:1490)

at org.quartz.core.JobRunShell.completeTriggerRetryLoop(JobRunShell.java:392)

at org.quartz.core.JobRunShell.run(JobRunShell.java:276)

at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:520)

 

AS400 Database Maintenance Commands

, ,

A common AS400 Database Maintenance Command – Finding and Fixing Dictionary Issues – is a quick task to complete. Follow these simple steps:

  1. Use the Verify Dictionary utility when you suspect dictionary mismatches such as missing objects or mismatched columns.
  2. Use the Build Data Definition Language utility to correct these issues or others, when you do not want to use the reorganization process.
  3. Use the Verify Dictionary (verifyibm) utility to check the two definitions.

If any problems are identified, you should use the Build Data Definition Language utility (bldibmddl) to modify an object (table or index) that needs rebuilding or modification. These utilities are used from a Lawson command prompt.

IBM WebSphere Application Server Network Deployment – Remote Code Execution Vulnerability

, ,

Issued: November 16, 2022

 

Impacted Product

ALL Infor Lawson 10.0.X application customers, Infor Landmark version 11 and version 10 application customers, Infor Business Intelligence for Lawson 10.6 customers, and Mobile Supply Chain Management 11 customers deployed on-premises or managed by Infor (Infor Cloudsuite single tenant cloud customers do not need to take any action).

 

Vulnerability Summary

 

A security vulnerability due to ‘Dojo’ CVE-2021-23450 CVSS 9.8 has been identified by IBM® within the IBM WebSphere® Application Server Network Deployment (WAS ND) 8.5 used by the Infor Lawson 10.0.X applications and the Infor Landmark version 11 and version 10 applications deployed on-premises.

 

It is recommended for customers to take immediate action to mitigate this threat.

 

Background:

IBM has addressed this vulnerability. IBM interim fix (iFix) PH43148 resolves the problem.

IBM WebSphere Application Server is vulnerable to remote code execution due to Dojo (CVE-2021-23450 CVSS 9.8).

 

Action Steps:

Lawson and Landmark on-premises customers must install IBM interim fix PH43148.

ALL on-premises Lawson 10.0.X application customers and Landmark version 11 and version 10 application customers must apply the IBM WebSphere Application iFix patch as directed in the Infor Support Portal’s knowledge base (KB) article 2275124, title “IBM WebSphere Application Server Network Deployment – Remote Code Execution Vulnerability.”