If you’re managing IPA flows daily, you may be used to working in Process Server Administrator. This gives you access to workunits, configuration sets, File Channels, among other features depending on your security.

Now if you’re logged into Process Server Admin as your own user, you don’t have access to scheduled IPA jobs. Creating new ones will tie them to your user, thus if you ever leave the organization, they all will fail. So, scheduling new IPA jobs under the system user require the system user password.

 

However, the good new is you could still edit these existing IPA scheduled jobs under the system user.

In order to edit them, you need to Async Administration Access, click the Process Server Admin drop down box and select Async Administration.

Select Request Management tab, then under Class, search PFITrigger and press enter

Now you will be able to view all the IPA Scheduled jobs, just double click them to view and edit them.

Note the Mapping field 1 will likely show the IPA Process Name since the job name may be named poorly.

 

When working with Perl and MySQL, one of the most reliable ways to establish a connection is through ODBC (Open Database Connectivity). This approach provides flexibility, as ODBC acts as a bridge between your Perl application and the MySQL database. In this post, we’ll walk through how to set up a simple Perl script that connects to a MySQL database using ODBC.


Prerequisites

Before we start coding, make sure the following are in place:

  1. Perl installed on your system.
  2. MySQL ODBC driver configured with a DSN (Data Source Name).
    • On Linux/Unix, you can configure this in /etc/odbc.ini.
    • On Windows, use the ODBC Data Source Administrator.
  3. Perl modules:
    • DBI — a generic Perl database interface.
    • DBD::ODBC — the ODBC driver for DBI.

You can install the modules via CPAN if they aren’t already installed:

cpan DBI

cpan DBD::ODBC


The Perl Script

Here’s a simple Perl script that demonstrates how to connect to a MySQL database using ODBC:

#!/usr/bin/perl

 

use strict;

use warnings;

use DBI;

 

# Define the DSN, username, and password

my $dsn = ‘DBI:ODBC:your_dsn_name’;

my $username = ‘your_username’;

my $password = ‘your_password’;

 

# Connect to the database

my $dbh = DBI->connect($dsn, $username, $password, {

RaiseError => 1,

PrintError => 0,

AutoCommit => 1,

}) or die “Failed to connect: ” . DBI->errstr;

 

print “Connected to the database successfully!\n”;

 

# Example query

my $sql = ‘SELECT * FROM your_table_name’;

my $sth = $dbh->prepare($sql);

$sth->execute();

 

# Fetch and display results

while (my @row = $sth->fetchrow_array) {

print join(“, “, @row), “\n”;

}

 

# Clean up

$sth->finish();

$dbh->disconnect();

 

print “Disconnected from the database.\n”;


Breaking It Down

  1. Connection String:
    The $dsn specifies the ODBC DSN you’ve configured, prefixed with DBI:ODBC:. Replace your_dsn_name with the DSN you set up for your MySQL database.
  2. Connection Attributes:
    • RaiseError => 1: Automatically die on errors.
    • PrintError => 0: Prevents warnings from being printed automatically.
    • AutoCommit => 1: Ensures changes are committed immediately.
  3. Query Execution:
    The script prepares a simple SELECT * query, executes it, and prints the results row by row.
  4. Cleanup:
    Always call $sth->finish() and $dbh->disconnect() to release resources properly.

Why Use ODBC?

Using ODBC adds a layer of portability to your applications. If your database backend changes in the future, you can update the DSN and driver without rewriting large portions of your Perl code. This is particularly useful in environments with multiple types of databases or when migrating systems.


Final Thoughts

With just a few lines of Perl code, you can connect to a MySQL database using ODBC and start running queries. While this example demonstrates a basic SELECT, the same connection can be used for inserts, updates, and more complex operations.

Whether you’re maintaining legacy Perl applications or building new scripts to interact with MySQL, ODBC gives you a stable, flexible way to manage database connectivity.

 

Summary: You have an email node going out to users with an attachment from a network path, but it seems to be failing.

Here is the email node, notice the network path by \\

This same email node will fail when you try to add an attachment like this by saying the file “does not exist”

One way to properly attach a file to the email node is to use IPA FileAccess nodes to read and then write the file to Landmark so it could be attached locally.

  1. FileAccess Node 1 (read) will need to be set to the Main configuration so it can read the file from your LSF server (assuming that is where your file exists).
  2. FileAccess Node 2 (write) will need to be set to the System configuration so it can write it to your Landmark server. If your file will be on landmark automatically or by some other means, skip this step.
  3. Now simply remove your existing \\ attachment network path and add a local Landmark path like D:\lawson\fileAttachmentName.txt

Done! Now just run and test it to make sure it works.

To view and manage favorites in the Infor Lawson Portal, follow these steps below.

From the home page, select the hamburger icon beside Menu > User Options and select the Favorites tab to view the Favorites configuration.

 

URL / Token

 

The URL is a direct link to an external site, and the token is what’s available to your user, within a specified data area and system code

Click Save to add the new favorite item to your Favorites list. You can also click “Edit Favorites” directly on the home page, then click the Add icon to create new favorites, such as URLs, tokens, or custom forms.

The GEN job tables provide detailed information about job execution, allowing for tracking and troubleshooting. Each table serves a specific function in recording various aspects of the job lifecycle, from submission through execution to completion. This structure ensures clear mapping of relationships and dependencies among the tables, which is essential for monitoring and managing batch processes efficiently allowing admins to be able to trace job progress and diagnose issues at both macro and micro levels.

🔹 Job Table Relationships

JOBQUEUE (one row per submitted job)

|

|–< JOBSTEP (one or more steps per job)

|       |

|       |–< JOBSTEPLOG (messages for each step)

|

|–< JOBLOG (high-level messages/logs for the job)

|

|–< JOBPARM (parameters used when submitting job)

🔹 GEN tables related to jobs:

JOBQUEUE.JobQueue = primary key (ties everything together).

JOBSTEP.JobQueue → foreign key to JOBQUEUE.

JOBLOG.JobQueue → foreign key to JOBQUEUE.

JOBPARM.JobQueue → foreign key to JOBQUEUE.

Each job in the system is uniquely identified by the JobQueue value, which acts as the primary key and links related records across all main tables. By using foreign keys, the JOBSTEP, JOBLOG, and JOBPARM tables maintain referential integrity, allowing for efficient tracking and management of job execution details and associated parameters.

To retrieve comprehensive job execution data, a query can be constructed that joins the JOBQUEUE table with JOBSTEP, JOBLOG, and JOBPARM using the JobQueue field. This ensures all relevant information, such as job parameters, execution steps, and log messages, can be efficiently accessed and analyzed for each job instance.

Here is an example of a query to find who ran the GL199 with any messages found in the joblog. The results will show

  • Who ran it → UserName.
  • When it ran → StartDate + StartTime.
  • Job status → Status (Success, Error, etc.).
  • Parameters used → from JOBPARM.
  • Messages → from JOBLOG.

 

SELECT     JQ.JobName,    JQ.Program,    JQ.UserName,    JQ.StartDate,    JQ.StartTime,    JQ.EndDate,    JQ.EndTime,    JQ.Status,    JP.ParameterName,    JP.ParameterValue,    JL.Message

FROM GEN.dbo.JOBQUEUE JQ

LEFT JOIN GEN.dbo.JOBPARM JP ON JQ.JobQueue = JP.JobQueue

LEFT JOIN GEN.dbo.JOBLOG JL ON JQ.JobQueue = JL.JobQueue

WHERE JQ.Program = ‘GL199’

ORDER BY JQ.StartDate DESC, JQ.StartTime DESC;

 

When working with date and time values in MySQL, it’s common to store durations in days. However, sometimes you need to present those days as a more human-readable format—like years and months. For example, showing “2 years, 3 months” instead of “825 days.”

Here’s a simple way to achieve this using a MySQL formula.


Converting Days to Years and Months

Since MySQL doesn’t have a built-in function to directly convert days into years and months, we can use arithmetic with division (/) and modulo (%) operators.

SELECT

FLOOR(days / 365) AS years,

FLOOR((days % 365) / 30) AS months

FROM

your_table;


How It Works

  • FLOOR(days / 365)
    Divides the total days by 365 to get whole years.
  • (days % 365)
    Gets the leftover days after subtracting the full years.
  • FLOOR((days % 365) / 30)
    Divides the leftover days by 30 to approximate months.

Example

Suppose your table looks like this:

CREATE TABLE durations (days INT);

INSERT INTO durations (days) VALUES (400), (825), (1200);

Running the query:

SELECT

days,

FLOOR(days / 365) AS years,

FLOOR((days % 365) / 30) AS months

FROM durations;

Would produce:

days years months
400 1 1
825 2 3
1200 3 3

Notes and Limitations

  • This method assumes 365 days per year and 30 days per month. It’s an approximation, not a precise calendar conversion.
  • If you need exact calendar-aware calculations (e.g., accounting for leap years or exact month lengths), you’ll need to work with MySQL date functions and actual date values instead of raw day counts.

Final Thoughts

Converting days to years and months in MySQL can be done easily with simple math functions. While the above approach works well for approximations, consider whether you need exact date-based calculations before choosing the method.

If you often store durations in days, this formula provides a quick way to present data in a more user-friendly format.

Most Lawson v10 systems has moved to Infor Security Service web portal to manage user provisioning etc.

 

However, Lawson Security Administration is still necessary for security reports, identity information, among other tasks.

 

When logging into Lawson Security Admin, you may receive this error and wonder why all of a sudden?

In order to resolve this, stop and start IBM and Lawson services in the proper order (your server names will differ from below but be similar under Windows Services.

STOP – Lawson and Websphere Services

  1. IBM WebSphere Application Server V8.5 – Infor10Prod-Appserver
  2. IBM WebSphere Application Server V8.5 – lsfappCellManager01
  3. IBM WebSphere Application Server V8.5 – Node Agent-Infor10Prod
  4. insight Environment “Prod”

 

Verify JAVA processes are down.

START – Lawson and Websphere Services

  1. insight Environment “Prod”
  2. IBM WebSphere Application Server V8.5 – Node Agent-Infor10Prod
  3. IBM WebSphere Application Server V8.5 – lsfappCellManager01
  4. IBM WebSphere Application Server V8.5 – Infor10Prod-Appserver

 

Follow this quick guide to re-label portal bookmarks in Lawson:

To change the Lawson v10 bookmark button label, locate and edit the file at %LAWDIR%\persistdata\lawson\portal\data\msgs\en-us\portal.xml, which controls how the label is displayed in the portal. Open the file in a text editor and search for “lbl_BOOKMARKS.”

Update the associated value to reflect your preferred naming convention, then save your changes. After updating, refresh the portal to confirm the new label appears correctly.

Keep in mind that this file may be overwritten during Portal or S3 Workspace patches and upgrades, so you will need to reapply your changes after each update to maintain the custom label.

Summary: When setting up a Distribution group so other users can view the print manager of another user, typically a system user like lawson. You need to complete a very important step before being able to add it.

 

  1. In Jobdef when you try and set the distribution group you get the “Distribution List Has Not Been Defined” error (not displayed below, but it’s an example of it being set)
  2. To resolve, go to users environment info shown below in ISS (This can be done in LSA or ISS)
  3. M sure to add the distribution group to the environment info of the Lawson user (assuming you’re distributing a lawson job to other users).
  4. Open jobdef and add it now. NOTE: After adding to Jobdef, you can clear this field and it should still work.

 

Follow the steps below to configure LSA logging for the passive client:

  1. Right mouse Click on the Lawson Security Administrator icon and run as Administrator
  2. On the upper right corner of the Server Connection form, click Settings.
  3. On the Settings form, select the Logging tab then configure the following:

    Configuration Directory

    Specify where LawsonNlog.Config is located. LawsonNlog.Config is the configuration setting for LawsonHttpClient that takes care of logging.

    Enable Logging- toggle logging.

    Log level

    Debug – Log the detailed trace

    Error – Log the exception errors

    Log Directory

    Provide the location where the generated logs will be saved on the same computer where LSA is installed.

  4. Select Apply, and Yes – to apply the settings before re-launching LSA.