GL199 Error Company Being Processed in Different Job

If you are running GL199 to close the period, you may encounter the below error message in the print file (or in the job scheduler log) “Company being processed in different job”.

This means that Lawson “thinks” there is another GL199 job running that is processing the same company your job is trying to process.  If that is the case, allow the first job to finish before running yours.  However, there may not be any other jobs running, yet you are still encountering the error.

To troubleshoot, first try to trace back to the first time the GL199 ran and failed (it may be in recovery or canceled).  Look at the examine log for that run.  There may be a different error that indicates the root cause of the issue.  If so, resolve that issue and recover or rerun that job.

If there are no issues to resolve, and you are certain that the GL199 hasn’t failed in the middle of updating records, you can get your DBA to update the status flag so that Lawson will no longer think the GL199 is running.  This can be accomplished by creating a paint screen for GLSYSTEM, or by making a direct update in the database.  The field “UPDATING” needs to be set to 0.  Additionally, you should check to see if your failed GL199 job is stuck in GLMONITOR.  If so, you should delete the record for that job.  But make sure you are deleting the record for your job!!!

DME Queries in Lawson

Lawson provides the ability to query Lawson tables via URL.  These transactions are called “DME” queries, and can be quite useful in IPA processes, or in scripting bulk data calls.

To query data using a DME call, the URL is https://<server name>/servlet/Router/Data/Erp?.  To select specific fields, use the “FIELD” key word.  To filter the results, use the “SELECT” key word.  You will need to have knowledge of the data tables and columns to build these queries.  The dbdef command in LID can be quite useful for this.

GEN

To query GEN data, the syntax would be https://<servername>/servlet/Router/Data/Erp?PROD=GEN

For example, this URL would return the PRODUCTLINE and FILENAME fields for the FILEDEF record with prefix “API”:

https://lawson.company.com/servlet/Router/Data/ERP?PROD=GEN&FILE=FILEDEF&SELECT=PREFIX=API&FIELD=PRODUCTLINE,FILENAME

LOGAN

To query LOGAN data, the syntax would be https://<servername>/servlet/Router/Data/Erp?PROD=LOGAN

For example, this URL would return the VERSION data in the LOGAN data area

https://lawson.company.com/servlet/Router/Data/ERP?PROD=LOGAN&FILE=VERSION

Data Area

To query your desired data area, the syntax would be https://<servername>/servlet/Router/Data/Erp?PROD=<data area>

For example, this URL would return the CUCODE “USD” from the CUCODES table in the TEST data area.

https://lawson.company.com/servlet/Router/Data/ERP?PROD=TEST&FILE=SELECT=CURRENCY-CODE=USD&FIELD=CURRENCY-CODE,DESCRIPTION

Output

The default output type is XML, but you can also output in CSV format.  To do that, in the URL, append the command “&out=csv”.

Outdated TLS 1.0 and TLS 1.1

After performing WebSphere or Infor application maintenance, your browser may present you with the error code “NET:ERR_SSL_OBSOLETE_VERSION”, indicating that the Quality of Protection (QoP) protocol in WebSphere is using an outdated version.

To resolve this issue, open the WebSphere administration console for the application causing the error.  Navigate to SSL certificate and key management.  Select SSL configurations on the right-hand side.  Then select the Node for your web application, and click “Quality of protection” on the right-hand side.  Select a supported protocol.  Save the changes and restart the WebSphere services.  NOTE: also make this change to the Cell if applicable.

 

MSCM Handheld Test Fails with Secured URL

If you are testing your MSCM handheld connection against the secured MSCM URL, and getting a “Test Failed” error, you may need to modify the Quality of Protection protocol in WebSphere.

The symptoms of the issue are: “Test Failed” message on the handheld, and the MSCM COMM log will show an error stating “Failed during SSL handshake”.

To update the QoP protocol in WebSphere, open the WebSphere Admin Console for MSCM, and navigate to Security > SSL certificate and key management.  Click “SSL configurations” on the right side of the page.  Then select the NodeDefaultSSLSettings.  Click “Quality of protection (QoP) settings” on the right.  Update the Protocol to “SSL_TLSv2”.  Click “Apply” and save the configuration.  Repeat these steps for the cell (if applicable), then restart WebSphere services for MSCM.

 

**NOTE: To avoid future issues with the MSCM/Lawson connection, it is best to set the QoP protocol in the LSF WebSphere Console to the same values as MSCM.  Do this both for the Node and the Cell.

 

 

 

 

 

Lawson MSCM Handheld Unable to Download PlatformDLL File

Infor recently updated handhelds and MSCM for a cloud environment. The test user was able to download the Infor CAB files to the handheld but was unable to download the PlatformDLL file. The error message kept coming back with “Internet Explorer cannot download file”

 

After ensuring all permissions were set for the user and running several tests, rechecking the configuration setup. We finally located the issue from the update and it turns out a port was reset to a default value and we had to change the Service Type to LHC. Below are the steps you can take to resolve this if you’re experiencing a similar issue.

 

  1. Login into MSCM with Server Administration group rights.
  2. Select MSCM Configuration >> Additional Settings
  3. Select Service Type LHC and under Handheld Service Properties, ensure you’re using the correct port. For us we had to update it to 1447

  1. We updated both LSF and handheld ports to 1447 and the user was now able to download the file.

Hope this was helpful!

Lawson System Foundation Older Addins Attributes

If you have suddenly noticed in Lawson Security Administrator that certain users have different attributes in their addins field other than ALLOW or DENY, don’t worry as this was setup by design back before LSF version 9.

These values were removed in version 9+ because Lawson User Security (LAUA) and Lawson System (LS) security can now secure these actions on specific tables and records.

If you want to convert the old Addins Attributes like to Allow or Deny, simply edit the users RM info and change the Addins field to Allow or Deny.

 

If you prefer to stay on the older attributes, see the table below for in-depth access descriptions:

Attribute ID Description
Dxxxx The user does not have access to the Query Wizard, but has full access to the Upload Wizard.
DDxxx The user does not have access to any Addins functionality.  Same as the current Addins attribute = DENY.
ADxxx The user has access to full QueryWizard functionality, but is blocked from using any part of the UploadWizard.
AADDD The user has access to both the QueryWizard and the UploadWizard, but is blocked from adding, changing, and deleting records.
AAADD The user can use the QueryWizard and UploadWizard to add records only.
AADAD The user can use the QueryWizard and the UploadWizard to change records only.
AAAAD The user can use the QueryWizard and the UploadWizard to both add and change records, but is blocked from deleting records.
AADDA The user can use the QueryWizard and the UploadWizard todelete records only, but is blocked from adding or changing any records.
AAADA The user can use the QueryWizard and the UploadWizard to add and delete records, but is blocked from changing any records.

 

How to Efficiently Analyze and Clean Up Lawson Directory Space

Overtime the LSF Lawson directory builds up and may even cause performance issues given the amount of data that may need to be backed up every night. Below are some steps you can take to help analyze and clean up your LSF Lawson directory.

 

  1. Download and Install the free WinDirStat tool found at https://windirstat.net/
  2. Once you open the tool, select and run it for your local LSF directory:
  3. You may notice right away that 3 directories stand out:
    • %LAWDIR%\print
    • %LAWDIR%\work
    • %LAWDIR%\system\joblog


These directories will fill up overtime as users run batch jobs/reports.

  1. To clean up the work directory, you can expand the directory in Windirstat and manually get rid of large files, outdated reports and files.
  2. For cleaning up the print and joblog directory, Lawson has a utility called deljobhst
    • To get a more in-depth look at the deljobhst utility see here
    • NOTE: It is recommended to backup these directories especially if your organization has a retention policy.
  3. Open LID and connect to the environment you want to clean up.
  4. We personally are going to delete all printed reports and joblogs that are over 400 days old.
  5. convertunits.com can help determine what the date is 400 days from today is.
    1. In our case, it is November 26, 2019
  6. In LID, we would run: deljobhst -crj 112619
    • This would remove all completed jobs (c)
    • All generated print files associated with batch jobs (r)
    • All recurring job entries (j)
  7. After this completes, if Windirstat is still open, click the refresh all button:

Hope this was helpful!

How to uninstall a CTP in Lawson using lawappinstall

You’ve applied a patch to your system and it caused more problems than it fixed or it was not the solution to your problem and there is no point in pushing it to PROD. Today we are going over simple steps to uninstall a CTP which is similar to how you install a patch via lawappinstall.

  1. Ensure security is turned off and it is typical to bring down websphere before starting so no user can login during this process.
  2. In LID, start with the uninstall command:
    • perl %GENDIR%\bin\lawappinstall uninstall <productline> <patchxxxxx>
  3. Run lawappinstall STAGE (optional but recommended)
    • perl %GENDIR%\bin\lawappinstall stage <productline>
  4. Verify stage compilation complete:
    • qstatus | wc -l (this command will return the number 4 when compiling is complete)
  5. Check for compiling errors:
    • ls %LAWDIR%\<productline>\*\*.err
      • If any errors found, recompile failed programs with this command:
        • qcompile productline SystemCode ProgramCode
  6. Run lawappinstall VALIDATE:
    • perl %GENDIR%\bin\lawappinstall validate <productline>
  7. Run stgcmp
    • stgcmp list <productline>
      • If the program’s status is FAILED or RECOMPILE REQUIRED, submit the program to the compile queue using the -A option.
  8. Finally, Activate
    • perl %GENDIR%\bin\lawappinstall activate <productline>
      • You should see the patch(es) you ran the initial uninstall for, confirm, verify any other prompts.
  9. Verify Non-stage compilation (if you didn’t run stage):
    • qstatus | wc -l
  10. Turn security on, turn websphere on, run your typical post smoke tests as if you were applying a patch.

 

Hope this was helpful!

How to enable IOS DEBUG Logging in Lawson System Foundation

IOS debug logging can be useful for tracking down issues in Lawson Portal, Add-ins, and Ming.le. There are two methods to enable it, we prefer method 1 below.

Method 1 (ios_logging.properties file must be renamed or deleted for this method to work):

  1. Login to your LSF on-prem server (Admin access required)
  2. Make a backup copy of your xml in %LAWDIR%\system
  3. Edit the xml file with a text editor.
  4. Change INFO to DEBUG as shown below
    • Ideally only use DEBUG if temporarily debugging an issue else leave it on INFO)
  5. If using DEBUG (or prefer a longer history of logging), you also may want to increase the log file size MaxFileSize and maximum number of logs to be generated MaxBackupIndex

Below our IOS logs will be 20mb and we will have a max backup of 5.

 

 

You should now see DEBUG entries in the log.

Method 2 – ios_logging.properties (this will be used by default over ios_logging.xml if it exists)

 

  1. As the lawson user, make a backup copy of ios_logging.properties in %LAWDIR%\system (if it exists).
  2. Copy the ios_logging.properties file from %GENDIR%\install to %LAWDIR%\system (you will only need to do this once to update the formatting of the ios_logging.properties file with the latest delivered version from %GENDIR%\install).
  3. Edit the ios_logging.properties file in %LAWDIR%\system:
  4. Change the second line in the file from INFO to DEBUG.

##Set root logger level to DEBUG and its only appender to A1.

log4j.rootLogger=INFO, IOS

to:

log4j.rootLogger=DEBUG, IOS

 

  1. Change these lines:

log4j.appender.IOS.MaxFileSize=2048KB

log4j.appender.IOS.MaxBackupIndex=5

to:

log4j.appender.IOS.MaxFileSize=20480KB

log4j.appender.IOS.MaxBackupIndex=5

This increases your log from 2mb to 20mb with a max of 5 log files. Adjust based on how busy your system is.

NOTE: A restart of WebSphere is not needed for these changes unless you are switching between ios_logging.properties and ios_logging.xml.

You should now see DEBUG entries in the log.

 

Good luck and happy debugging!