We are migrating from Lawson AS400 to Lawson Unix and we need to find a solution to archive automatically the Lawson BackOffice reports in LBI.
The AS400 keeps every report that the user runs. Unix is only keeping the last copy of the report.
We need to have copies of some payroll reports and we do not want do it manually after each payroll.
My question is: Is it possible to do it automatically once the Payroll job is completed? If yes, how it can be achieved?
Thanks,
Lorena.
Hi Greg,
Thank you for your response.
As you can see, I do not know anything about LBI and they told me that LBI does not archive the backoffice reports automatically.
They told me that someone will have to go to LBI and move the backoffice reports manually.
I want that every time a user runs the PR141, LBI will archive the output report without any humane intervention.
I do not know how the LBI historical archive works but I do not want to schedule something every day or every hour because I can have more than 1 PR141 in the same day or hour.
Thanks again,
I'm aware of 3 options: 1) Write a custom post-processing script [requires slight modification to *each* desired PR program to invoke it or using a multi-step job to run the script after the program] (i.e. "poor-man's archive) 2) Use LBI and 'back-office' publishing, which by design creates an "archive" 3) Purchase ReportSafe (http://www.ascendsoftware.com)
As Greg points out, one of the benefits of LBI's back-office publishing is that it does create an archive for you each time a job is run (assuming you don't run jobs more often that the publishing time window, which I think defaults to 5 minutes...). That "fixes" the problem of the UNIX print files being overwritten.
If you do not want to schedule something to run more than once a day, one of the only ways that I can see this happening, is to customize the setup for PR141. You would have to call a script that runs the lawson job (which can be done, and is fairly simple once you get the hang of it). You would have to either rely on a scheduled run of PR141 or set up a custom token that you can use to call a script in Unix. (probably the way that you want to go since you stated more than one per day). I can give you examples of what we've done here for something similar. -Greg
The LBI publishing feature works per JOB, not per PROGRAM, by creating "instances" of a report. Each time a published job is run on the "back office" server, it sets a flag/semaphore saying "I've got a new report to publish". An LBI polling process looks, at a pre-defined interval, for those semaphores, and if it sees one, pulls it from the 'back office' server and creates a new instance of the report, thereby creating an "archive" of reports for a particular job. And, since it's JOB, not PROGRAM-specific, if you want to archive PR140, you would need to set up LBI to publish the PR140 JOB, and make sure you use that SAME JOB NAME every time PR140 is run in order to build up an archive of PR140 reports in LBI. Not foolproof, but probably enough to meet your requirements.
The LBI publishing feature works per JOB, not per PROGRAM, by creating "instances" of a report.
Each time a published job is run on the "back office" server, it sets a flag/semaphore saying "I've got a new report to publish". An LBI polling process looks, at a pre-defined interval, for those semaphores, and if it sees one, pulls it from the 'back office' server and creates a new instance of the report, thereby creating an "archive" of reports for a particular job.
And, since it's JOB, not PROGRAM-specific, if you want to archive PR140, you would need to set up LBI to publish the PR140 JOB, and make sure you use that SAME JOB NAME every time PR140 is run in order to build up an archive of PR140 reports in LBI.
Not foolproof, but probably enough to meet your requirements.
This may be a little more than what they want, but attached please find a script that runs a Lawson job named LBIIPREV, copies the print file output (so that the next run does not overwrite it), loads it into Lawson's print manager or notifies the user if the job failed, then exits.
The whole bldxffiles section was put in to get around an error in Lawson's code which has since been fixed, so it's not needed any longer, just haven't gotten around to taking it out.
There's more steps to this, but will reply again.
We've created tokens to call these scripts. Attached please find a document describing the steps- If you are going to call this script from cron, this is all you'd need to do.
If using Portal the attached PD section would need to be added, and all the other sections of the program and would need to be compiled for Portal users to be able to access the GHS010 token/form.
Great info John. I've never really published a straight backoffice report via lbi. Good to know!!
Thank you so much to both of you.