Print files for multi-step jobs - how is the order/placement determined?

We have some nightly multi-step jobs (some have 14 steps) with many batch jobs that get run, which creates print files each time the job runs. The folder for the print files has several folders under it, normally numbered, like 1 through 14 or whatever. That's standard of course, for jobs in general.

We were just making some changes to one of them and noticed that when we had a 2 steps containing the same job (different parms, and placed directly after the first one) it did not leave a print file in the matching step numbered folder - it actually overwrote the first one (just like a normal job would do). So we put them in a different order, not one after the other, and then we got the file created in its own folder. But we noticed that we still don't always get a file in the same "step #" folder that we would expect.

I tried to look for some documentation on what determines the creation of these numbered print file folders, specifically for multi-step jobs, but I can't find anything. Does anyone have any information on this or know where I can find it?

Find more posts tagged with

Infor Lawson Technology Group - Discussion

Comments

asztudenyak

Bumping this. Really hoping someone has some information.

robert-canham

I checked a recurring job I have with 14 steps. From what I can see, the output got placed in the numbered directory that goes along with the step. This is what I understand the expected behavior to be. With your scenario, I would assume you can't view the report output in print manager? What you're experiencing sounds like an issue you'd want to bring up with support.

unknown

That's very odd. What O/S and version are you running on?

jocurrin

Reports aren't always visible in S3 immediately (not sure why) but you could try the loadrpts command (if you type it in LID it will give you the syntax). We sometimes use this command from our Processflows to insure reports are loaded to users profiles.

asztudenyak

I'm not sure that answers my question. We have mutli-step jobs that contain many jobs in them. We would expect the print files that are created, to be in the order that the jobs were run in the multi-step job (which is of course the order that they were created in the job stream). But they are not. I need to understand how Lawson determines this order.

0911060553270289.pdf

unknown

If someone built the jobs in LID, and clicked on the "Report" button and changed it to something other than the defaults, and then the step was later updated but the "Report" info was not, you might have some "leftover" setup sitting that that has been applied to the updated job.

unknown

Sorry - not necessarily LID anymore, but hopefully you get the idea. There are output parameters in the "Reports" button on batch S3 jobs.

asztudenyak

These jobs were created in LID (we have had no ability to create them in Portal - I don't remember the exact issue but it seems like there is no place to populate certain things that we are able to do in LID). These are recurring nightly jobs that perform various updates. The users do not submit them, ever. The only thing the users do is check the report outputs that were distributed to their print files. And lately, we have noticed that the print files are sometimes overwriting the previous job. When we go to look for the print files, we also realized that they were in the wrong order (or different from the job order).

unknown

Have you ever Inserted or Deleted steps within this job over time? It will not renumber the print files output folder number. example: Job has 4 steps. Insert a new step at placement # 3, so steps 1, 2 are the same, inserted new step 3, then old step 3 becomes 4, and 4 becomes 5. The output folder for the New step 4 will be in Folder # 3, step 5 will be in # 4, the new step 3 may be in #6. So in short, if you ever have to insert/delete steps within a multistep job, it is best to just recreate it from scratch, unless you want to fix it directly within the GEN database in several of the tables needed.

unknown

ok - actual LID, I'm getting security violation.

Going through command line/jobdef, create the job, arrow down to the step, then use F6/Rept Dist. Tab over to destination and then use F4, select Printer (even though you don't want to print it) and then use F6 to define the print file path.

I'm not certain this is your issue, but it's something that I would look at.

unknown

Hi, can you give more information about the type of changes you made to the multistep job. The print folders are created the first time the job is submitted, and the job just places the reports into them. I am wondering if perhaps you have a permissions issue on one of the step folders, or one of the report files (like maybe someone touched a report file and the owner changed), which is causing an old report to not be replaced in the folder. One thing that would help is to delete the print folder for the job and let the job recreate it the next time it runs.

asztudenyak

Thank you Michael - yes we absolutely HAVE. Over time we have requests or changes in requirements that necessitate changes to these jobs. Sometimes we remove a step, sometimes we add one, sometimes we change something in the step. It's not often, in fact it is very infrequent, maybe once a year.

What you are saying makes sense then. Unfortunately it is a massive PITA to recreate these jobs from scratch. Each one has unique inputs/parms/user distributions. We may just have to live with this. But thank you for this - we have been scratching our head over this for a few months now and could not find anything in the documentation on it. I appreciate it!!

unknown

you can make some fixes to it. Dump the job definition out using jobdump. Edit the print file paths within the job dump file to the correct order, then use the jobload utility to load it back in. This should fix your folder numbering for the next time it runs.

You can dump the job out by JobName (but will dump out all Jobs with that same name) or all jobs by a user. Either way, if you have extra jobs in the output file, just remove those jobs from the file before you reload it.

Each Job starts/ends with a JOB, JOB tag, and each step within a job has a JOBSTEP, JOBSTEP tag.

example of print file path within the job def output file:

JOBSTEPREPORT
PrtFileName elig
PrtFilePath L:Dlaw/print/TMK_PMORTIZ/bn100.fin1/1

The file path for this particular job step is in folder "1" as seen as the last folder in the path above. In this example, "bn100.fin1" is the job name and the /1 is the numeric folder under the job name in the print file structure. You will need to edit the PrtFilePath for each output file for each JobStep (for programs that have multiple output files/reports). Give your job def a good eye ball'n and fix them to be in the correct folder for the step that they are.

I use the jobdump/jobload utility to manage many different types of job definition related issues and maintenance and mass copying job def's to multiple users where needed, where we have custom CSV file locations defined for certain jobs.

unknown

Earlier you mentioned that you had issues viewing this job in Portal. If the job was created using LID, the job type was set to "0" (zero). Portal can't see Type 0 jobs, only LID. If created in Portal, it will be set to a Type 1. This can be changed within the jobdump definition file as well and loaded back in. LID will still be able to see it and edit, but Portal will see it as well when it is a Type 1.

For further grins, if you can see the job in Portal, then you can change the ouput path for each report. Within the Job Definition, click the Report button, the reports will popup. highlight a report file then scroll all the way down and you will see the "File Path" field. You can edit that path to correct the folder number value or the entire path if you actually wanted to. Click the submit button to save that report file path change, then click Change at the main job definition window to save the job.

Just giving you options...

unknown

Okay, while I'm on a roll, you can also do the same within LID.

Edit the job def, go to each step, F6 define, B Report Distaribution, output files will be listed. for each file one at a time, highlight then F6 for Define, B Print File Name. The Print File Path value will show up and you can edit/correct it this way as well.

So, you now have a dart board wall full of cat skins...

asztudenyak

There is no permissions issue. And I do think that we have tried deleting the print files. We'll try that again to be sure, but I believe the answer was provided by Michael, above. We'll have to investigate the possibility of correcting the job in GEN, but recreating these jobs is simply too much of an ordeal. We won't be doing that.

asztudenyak

LOL!! Thanks a bunch - we'll look at this today!!! :-)

asztudenyak

This is interesting. So we have certain jobs (not multi-step) that our users run regularly, but those jobs have custom input files. And they cannot enter that information in portal (we don't even want them to!) so what we have been doing is we have them create the job in portal, with the correct parameters, and then we go into LID and modify the job and enter the path for the input file, and any group distribution if they need it. We had discovered that if we create the job for them, that they can't see it in portal, so this is what we have had to do. I had noticed the type 0 and type 1 thing...but did not understand what it was doing or why. And I had looked everywhere but couldn't find any information on so thank you again!

unknown

Michael Thedford: Thank you for sharing many different ways that print jobs can be adjusted! I use jobdump/jobload and I know about editing the file, but you have explained all sorts of new possibilities. I will definitely be using it more effectively in the future.

0911060553270289.pdf

Copyright © 2025 Infor. All rights reserved.