Lawson Security Administrator (LSA) Reporting is stuck in “processing” status

, ,

Problem:

You’re trying to generate a v10 Lawson Security Administrator (LSA) report and its stuck in “processing” status

 

Resolution:

Edit your GENDIR/java/command/lsserver.properties file (Back it up first).

 

Locate the following line:

ljx.ext.dirs=${GENDIR}/java/ext:${LAW_JAVA_HOME}/jre/lib/ext:${LAW_JAVA_HOME}/lib/ext

 

To incorporate the modification, append “${GENDIR}/java/impl:” so that it appears as follows:

 

ljx.ext.dirs=${GENDIR}/java/ext:${GENDIR}/java/impl:${LAW_JAVA_HOME}/jre/lib/ext:${LAW_JAVA_HOME}/lib/ext

 

Save the file.

 

After implementing this change, you will need to perform the following restarts:

  1. Stop your WebSphere application server or cluster for this environment.
  2. Stop the Lawson environment using the stoplaw command.
  3. Start the Lawson Environment using the startlaw command.
  4. Start the WebSphere application server or cluster for this environment.

Execute the report again to verify that it completes successfully.

 

PR160 In Recovery but can’t delete and need to update the file path parameter

, ,

So you ran the PR160 again and it went into recovery due to an ACH file path parameter not being correct.

 

We don’t want to delete this but we also want to resolve it so we can recover it quickly.

 

To do this, perform a jobdump on this specific job:

jobdump -d -o Job -v JobName PR160JOBNAME -v UserName YourUSERNAME YourUSERNAME_dmp.txt

 

Once you dump this job, edit it in notepad or notepad++ and locate the incorrect path, example below:

 

Update this path ONLY to what you need it to be and use jobload to reload it:

jobload -c -o Job YourPR160JOBNAME.txt

 

Then recover the job and it should put the file in the correct path.

 

Compiling all invoked programs

, ,

When you’re logged into Lawson, in order to compile all the programs invoked by one program, make sure that the syntax reads: lstinvk -q <pdl> <program>.

 

By doing this it will compile anything that is invoked by the program. After, you do this, then you will need to also compile the program itself. (See screenshot below for reference)

 

That’s all there is to it!

Lawson PR160 Job is in Needs Recovery or “is currently running”

, ,

If your Lawson PR160 job status is in “Needs Recovery” or “Is currently running” (because it’s in recovery), see below for the potential fix.

Another error you may encounter is “Ern2 Record Exceeded limit size of 15000”

 

 

Resolution:

  1. Rerun PR140 (If you encounter an error indicating that PR160 is currently running when rerunning PR140, you should restart PR00 by performing a “double delete.”)
    1. “Double Delete” means going to PR00 and hitting the delete button twice until you clear out * and R flags
  2. Run PR160 with the Earnings Record NOT equal to blank after clearing flags in PR00

 

Hope this was helpful!

Lawson Error – PR160 error Bad File Status 9 009 on File TAPE-FILE

, ,

Problem:

So you’re running a Lawson PR160 job (Payment Print) and encounter the “Bad File Status 9 009 error on File TAPE-FILE” error. What do you do?

 

Resolution:

First, understand that the error message “Bad File Status 9 009” signifies that either the directory is full or doesn’t exist.

What you will need to do is simple: ensure that a valid path is specified in the PR160 parameters. If there is, double-check that the path is correctly spelled and has sufficient available space in the default location (along with any folder permissions). See the screenshot below for guidance. That’s all there is to it!

 

dbreorg -lc lists does not show dictionary changes exist

, ,

Problem:

After adding a view to a productline database and adding it to the application productline using dbdef, blddbdict and dbreorg, the blddbdict created  a +dictionary, but the dbreorg -lc does not show anything as being added.

 

Resolution:

Files added in dbdef and assigned a database space defined as “Is View Yes” are treated as views by the dbreorg.

Views are not created or modified in the database by the dbreorg process, therefore, they will not show up in the output list from dbreorg -lc.

The dbreorg -lc only lists structure changes that the dbreorg makes to the database.

Any non-structure changes made to the file definitions are not shown in the dbreorg -lc output.  Non-structure changes are file relation definitions and fields defined as compute, conditional or string.

CKPOINT table does not exist after a productline copy

, ,

If you’ve ever come across the following problem below, follow this quick guide to solve it.

 

Problem:

Users receive error messages when they are running jobsf. The errors are indicating that the CKPOINT table does not exist after the system admin completed a productline copy.

 

Resolution:

Simply put, the CKPOINT file did not get copied over during the copy procedure. Run the following commands to add the CKPOINT table into the productline:

bldckp productlinename

blddbdict productlinename

 

Stop the WebSphere Application Server

dbreorg productlinename

Have the users login and try to run their jobs again. Your error message is now resolved.

 

Should Users CheckLS be set to Yes in v10 Lawson?

, ,

As a Lawson Managed Service provider, we see many different Lawson v10 systems (even v9 systems) and often we find users with CheckLS = No but get asked if this should be set to Yes.

In the past when migrating clients from LAUA to v9 or v10, CheckLS to Yes would put them on v9 or v10 security instead of LAUA security.

 

Today if you’re on later versions of v10, it’s still the best practice to set CheckLS to Yes in the users RM info but the official Infor documentation reads as follows:

“When you upgrade to 10.0.x, the system will treat this field (checkLS) as set to Yes in all cases”

 

So if you’re scratching your head, what this means is that in v10 and forward, checkLS field Yes or No still puts you on v10 Security. However, setting it to Yes can also give users the ability to access LID if needed (assuming they have ENV access to specific LID command tokens).