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.
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!
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.
