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)
A common AS400 Database Maintenance Command – Finding and Fixing Dictionary Issues – is a quick task to complete. Follow these simple steps:
- Use the Verify Dictionary utility when you suspect dictionary mismatches such as missing objects or mismatched columns.
- Use the Build Data Definition Language utility to correct these issues or others, when you do not want to use the reorganization process.
- 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.
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.
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.”
In AS400, it is convenient to know where all your data is distributed as well as how much disk space you have consumed and have leftover to use. If you want easy access to all this information at hand, all you need to do is run a simple command.
To get your AS400 Disk space usage, use the following command in your green screen command line:
Dspsyssts
On the right-hand top corner, you will see the sizes listed. You can run this command as often as you need to keep track of your disk space usage on a daily (or periodic) basis.
Typically when you click on an LBI report that’s been setup on the dashboard, it will show you data of the last generated instance. To add a refresh is incredibly easy.
First login to LBI and go to the dashboard you want to modify a report on. When you click it, you’ll see something like:
To allow the report to refresh data, select the plus sign >> Edit
You’ll see a URL field, all you need to do is add &Refresh=True to the end of the URL and click save.
The URL may look something like this:
FSRemote%3Ffsid%3DRS%3ARS-COMPANY%20Reporting%20Services%3A25%26
Now add %Refresh=True at the end of it like below:
FSRemote%3Ffsid%3DRS%3ARS-COMPANY%20Reporting%20Services%3A25%26&Refresh=True
Done! Now the report will always pull up the parameters (if any) so you can see the latest data:
If your organization still heavily relies on LBI today, which is harder and harder to find individuals who support it, we recommend organizations 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.
There is not a delivered report that you can run to list out your recdef jobs. The file that holds the recdef data is called recurjob in your Gen Database Collection.
To get a report of all recurring jobs that are set up in recdef on AS400, follow these instructions:
From the AS400 command line type; CALL LAWENV hit enter and choose the subsystem in which you want to dump the records from.
qsh
rngdbdump -c GEN recurjob > /home/userprofile/recdef.csv (a dump of all recurring jobs that exist in recdef)
You can now use the wrklnk command to look in the directory listed in the rngdbdump command above to see the csv file that was created with these recurjob records.
wrklnk ‘/home/userprofile/recdef.csv’ place a 2 next to the file and hit enter
or
map a drive to your IBM i root directory via Windows Explorer and open the .csv file from there.
or
use the System i Navigator to open the file
