When migrating or copying custom COBOL programs, it is often necessary to also migrate messages and work file definitions (aka metadata).
First, dump the messages and work file definitions using the following syntax:
metadumpmsg <productline> <messagecategory>
metadumpwrk <productline> <programcode> <workfilename>
For example, metadumpmsg prod ZC186 and metadumpwrk prod ZC186 ZC186_ERROR-RPT
The messages will be dumped to a file <messagecategory>.msg.
The work files will be dumped to a file <program_workfile>.wrk. Work file names can be found in workdef.
After all the metadata elements are dumped, copy them to the other server/productline. Using a command line utility or LID, navigate to the location where you placed the files, then run the commands to load them.
Loading messages syntax is metaloadmsg <productline> <filename>.msg
Loading work syntax is metaloadwork <productline> <filename>.wrk
If you want to use filters with a user, you can enable filtering when you create a user. Follow these steps below:
Enabling users for filtering
- Open a user and then select the “Is Filter Enabled” check box.
- Click Save.
Enabling tasks for filtering
- Open a Task and select a User Task.
- Select the “Is Filter Enabled” check box when you link a task to a user.
Note that a user must also be filter-enabled to use filtering associated with tasks.
Often times a user is responsible for updating dozens of LBI report schedules that generate daily, weekly, and monthly report instances.
A parameter might have been set incorrectly and is now generating the incorrect data for a bunch of instanced reports that now are useless and no one noticed until several report instances existed.
Today we are going to go over how to easily fix those report instances assuming one has admin access and crystal reports installed.
Here is an example of a report a user was viewing that contains no bursting data for that user because it has the incorrect parameters:
First thing to note is the Report ID and Instanced ID as highlighted below.
Let’s now export the report as a Crystal report as shown by the arrow below.
Open the exported report in Crystal and press F5 >> Prompt for new parameter values >> OK
This should pull up the incorrect saved parameters. Change it to the proper values and press OK to generated the report with data. (you may be prompted for credentials, you’ll need some sort of db read access).
After the data is generated go to File >> Save and make sure “Save Data with Report” is highlighted:
Now go to the report instance that you exported this from and click details:
Under Report Actions >> Republish >> Choose File >> Find the updated crystal report, select >> Save
Now view the report again and see if it shows the correct data. Do this for the rest of the reports.
Numerous organizations choose to leverage Lawson consultant teams to oversee their Lawson Security and LBI systems. These expert teams provide managed services at a predictable monthly rate, offering extensive knowledge and specialized expertise. This solution is ideal for larger organizations, while smaller entities seeking efficient management without the need for full-time on-site staff can also benefit. Nogalis delivers these services, and additional details can be obtained by contacting us through our dedicated contact page.
In Lawson, your users may be experiencing a GL190 job in recovery.
You may be getting this error:
This is due to the GL190 job being ran when another GL190 job is running in the same jobqueue.
Locate the job in recovery (notice the Job Queue below *********):
Go to GLMONITOR, inquire on GL190 program. This will bring back all jobs in recovery here, only delete the one you plan on recovering, then do so for the remaining.
Once the GLMONITOR is cleared of that specific job, lets recover it and see if it completes (make sure no other GL190 jobs are active).
That’s it, hopefully this helped resolve your issue!
We recently had an issue with a new install where all batch jobs were going into recovery with the error “Unable to log in <username>”. The can often be attributed to an incorrect password in the BATCH privileged identity, but in this case it was due to a typo in lajs.cfg. The “RUNUSERKEY” field was misspelled. So, if you ever encounter this issue, you can save yourself some time and get a couple of sets of eyes on the lajs.cfg file! After making the change, reboot the Lawson server or stop/start services. You should now be able to log in.
When it comes to IPA security access, you can assign the following Lawson delivered roles to IPA users:
| Delivered role | Intended for use by | Contains these security classes |
| InbasketUser_ST | Normal end-users who receive work items in the Inbasket | BasicProductLineAccess_ST
ProductLineAccess_ST InbasketUser_ST Lpa_ST ProcessSchedulingAllAccess_ST |
| JobQueueServer_ST | Users who must perform actions on the Landmark job queue. | BasicProductLineAccess_ST
ProductLineAccess_ST JobQueueAccess_ST |
| ProcessDesigner_ST | Process developers | BasicProductLineAccess_ST
ProductLineAccess_ST Lpa_ST ProcessDesigner_ST ProcessSchedulingAllAccess_ST |
| ProcessServerAllAccess_ST | IPA system administrators | BasicProductLineAccess_ST
ProductLineAccess_ST Lpa_ST LpaAdmin_ST ProcessServerAllAccess_ST ProcessSchedulingAllAccess_ST ScheduledActionsAccess_ST |
| ProcessServerReadAccess_ST | IPA assistant administrators, power users, developers | ProductLineAccess_ST
ProcessServerReadAccess_ST |
