Job overwrites a different job - LawsonGuru.com

Name	Points
Greg Moeller	4184
David Williams	3349
JonA	3288
Kat V	2984
Woozy	1973
Jimmy Chiu	1883
Kwane McNeal	1437
Ragu Raghavan	1348
Roger French	1311
mark.cook	1244

Mary Porter

Veteran Member

Posts: 337

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

Senior Member

Posts: 3348

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

George Graham

Veteran Member

Posts: 201

4/30/2013 11:09 PM

Is the job getting created from scratch or copied form another job?

Mary Porter

Veteran Member

Posts: 337

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

Posts: 151

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

Posts: 337

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

Posts: 151

5/1/2013 4:06 PM

I think so... that worked for me.

Ragu Raghavan

Veteran Member

Posts: 468

5/1/2013 5:14 PM

Thank you MikeP. This helped solved a mystery at one of my sites.

George Graham

Veteran Member

Posts: 201

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

Posts: 337

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

Posts: 201

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!