• Search Forums
    Advanced Search Topics Posts
Prev
Next
Forums Infor / Lawson Platforms S3 Systems Administration

Job overwrites a different job

 10 Replies
 0 Subscribed to this topic
 27 Subscribed to this forum
Sort:
Author
Messages
Mary Porter
Veteran Member Send Private Message
Posts: 337
Veteran Member
4/30/2013 10:43 PM
We have a user with two separate job definitions for the same form. The jobs are called PR132R and PR132U. When the user runs the PR132R, it puts the print files in the print directory for PR132R. When the user runs PR132U, it also puts the print files in the print directory for PR132R, overwriting the previously run PR132R print files. There is nothing in the print directory for PR132U. We had the user delete those jobs and add new ones and the behavior is still the same.  In the Job Schedule you can see that the two different jobs were run. What could cause one job to overwrite a different job?
John Henley
Send Private Message
Posts: 3351
4/30/2013 11:05 PM
What platform/environment?
Try the same process (delete and re-add jobs) but between adding the first and second, run
tmcontrol -rp PR132
Thanks for using the LawsonGuru.com forums!
John
George Graham
Veteran Member Send Private Message
Posts: 201
Veteran Member
4/30/2013 11:09 PM
Is the job getting created from scratch or copied form another job?
Mary Porter
Veteran Member Send Private Message
Posts: 337
Veteran Member
4/30/2013 11:37 PM
What platform/environment? Windows
Try the same process (delete and re-add jobs) but between adding the first and second, run
tmcontrol -rp PR132

We will try delete and re-add and run tmcontrol -rp PR132 between adding PR132R and PR132U

and the jobs are being created from scratch

Thank you both for your replies
mikeP
Veteran Member Send Private Message
Posts: 151
Veteran Member
5/1/2013 2:57 PM
Check the print file name in your PR132U job.  I have been working with jobdefs a lot lately, and at least once, I found that when I copied a jobdef, the print file name in the destination job remained the same as the source job.  These were copies of the same job from user to different user, and the print file name still showed the first user's print folder.  Most of the time, Lawson was smart enough to change it when copied, but apparently not always. 

In LID, arrow down to the job step that runs your PR132, then F6 Define, select B. Report Distribution. In the Output files box, tab over to the Destination column, F6 Define, select B. Print File Name to see the path to the print files.
Mary Porter
Veteran Member Send Private Message
Posts: 337
Veteran Member
5/1/2013 3:27 PM
the print files were set to pr132r for job pr132u - so if I just change it there to pr132u we should be good, right?
mikeP
Veteran Member Send Private Message
Posts: 151
Veteran Member
5/1/2013 4:06 PM
I think so... that worked for me.
Ragu Raghavan
Veteran Member Send Private Message
Posts: 477
Veteran Member
5/1/2013 5:14 PM
Thank you MikeP. This helped solved a mystery at one of my sites.
George Graham
Veteran Member Send Private Message
Posts: 201
Veteran Member
5/1/2013 5:36 PM
But Mary - you said the jobs were getting set up from scratch - not copied, correct? So is the first job left on the screen - and then the job name changed and the new job added? I would test if you create one - go out of the form and come back in and then create the second - and see if that still has the wrong print file name.
Mary Porter
Veteran Member Send Private Message
Posts: 337
Veteran Member
5/1/2013 6:25 PM
I'm pretty sure what she did was create PR132r with Report Only checked, click Add, change the name to PR132u and change it to Update, and then click Add again.
is that technically a copy?
George Graham
Veteran Member Send Private Message
Posts: 201
Veteran Member
5/1/2013 7:48 PM
Not technically. But could be a bug on your version. Tried that here and looked at the print file paths/names and they were different. I saw this happen a while back but it was when jobs were actually copied from one user to another - then it was putting the new job in the original users print file path - that was a mess!