print directory files cleared on next recurring job run

Oh, man!! Sorry to hear this news, and really sorry that you are in the midst of it all.

We rely on this type of 'left over' print files quite heavily. Good to say that we won't be on ESP8 until sometime next year. Maybe GSC will have 'fixed' it by then. Please let us know if you find any solutions for this!!

We had a similar situation. We have nightly jobs running, AP175, GL190, AC190. After each run, we extract the pdf version and send it to an archive folder. This allows us to keep the files.
I am sure it would be easy to save off the text or csv versions as well

One fix would be to change your script that copies the files to include the date/time stamp, and have them moved to different directory.

We have this situation worked-out long time ago by moving the files with timestamp into users shared directories. We use a product called Axway to pickup selected report files from lawson and deliver them to a designated shared drives. This is also our main interface engine to the outside world (its not cheap).

As John said its good idea to use some simple shell scripts. Run these back up scripts so that it will move previous run's print files to another back up directory.

Thanks for sharing your problem and its a good learn'g for us.

Thanks
Sam

Thanks, all, for your suggestions / sympathies.    We ended up following the advice posted here, particularly the part about moving the "copied" files to a *different* subdirectory.  That was the key part, because the new way that Lawson is processing the jobs now first wipes out the entire "normal" subdirectory (the one named .  It even, apparently, uses some type of wildcard to do this (example: it wipes out not only a directory name  'xx1234' but also one that might be named 'xx1234B').  We ended up PREfixing an extra letter (instead of SUFFIXing one); so now our "parallel" directory is called Bxx1234.   That seemed to work ok.

Thanks again, all.

Kirk,

We are on ESP8 as well. We upgraded recently. We do not see this behavior in your print directories. The recurring job only deletes the files it creates. An external file that I create remain there.

May be there is a difference in the additional patches that were applied on top of the base patch ?

We're in the process of migrating from AS400 to Windows, and I just encountered this issue today.  (The changes in behavior between platforms are really frustrating.)

Would someone be kind enough to post their script to back up print files, a little something to get me started?

Thanks.

Something like this should get you started:
USER="user1"
JOB="PC530"
PRINTDIR=${LAWDIR}/print/${USER}/1
ARCHDIR=/home/archive/sub-dir
if [ ${PRINTDIR}/${JOB}.prt ]; then
cp ${PRINTDIR}/${JOB}.prt ${ARCHDIR}/${JOB}.prt_$(date '+%a')
fi

Thanks Greg.

I've been doing some manual copying of the print files from one run, trying to work out the task before writing a command file/token, which I think is how we need to do scripting on the Windows platform.   

I've tried creating a new folder under the job name, and I can copy files to the new folder OK:

\ATT001\1\PR530.dtl
\ATT001\1\errors

to

\ATT001\2\PR530.dtl
\ATT001\2\errors

The files in \ATT001\2\ don't appear in portal Print Manager.  Do you know if there's a way to make that happen?

Thanks.

You need to use the Lawson utility loadrpts to do that...
loadrpts -s -u ${USER} ${JOBNAME} -t ${TOKEN} -p ${PROD_LINE}

Thanks Greg.  I'll research that.

mikeP,
Be careful! The way you're trying to archive, by just changing the number could be problematic, since (as you may know) that number means which job step the job has executed. the issue here is it might confuse the users seeing that, as to whether they are looking at a multi-step job or not.
Greg's suggestion of a seperate archive directory is safer since under both Windows and UNIX, the job's print directory location is cleared, and additionally mutexes can lock a file on rewrite (get used to seeing 9 065 errors)

Kwane

Kwane,

I had not picked up on the folder number:job step corelation, thank for that.

I guess we've had this for some time.  Our users have access to those print folders, and they know to backup their files after their jobs complete.  This is normal procedure for us.

I'm only going to do this for nightly scheduled jobs where the users may be gone for a while and need to review multiple days' reports when they return

So, the good news is I have a Windows .cmd file set up on a token and added as a job step, and that seems to work well. The print files are copied to a different folder in the same user's print directory, and it survives after rerunning the job.

The job runs as a special privileged user created specifically for scheduled jobs. After running loadrpts (part of the cmd file), this special user can see the copied print files in portal print management,

The true report destination is a distribution group with three users, but they cannot see the copied reports.

Is there any way to hook into a distribution list from the Windows command line, so I can determine the users in the group and copy the files to them as well?

If you have a way to query the database, sure. We use Oracle here, so mine is something like:
sqlplus -s user/pass@sid < select username from GEN.DSTGRPUSER where DSTGRP='YourGroup'
ENDSQL

Or you could do:
rngdbdump -cnt gen dstgrpuser -f username -v dstgrp=YourGroup and parse from there.

I don't think I have a command line SQL query tool, so I'm looking at rngdbdump. That works, but it gives me an NTID, e.g. "NT0000001c"

If there a lookup function that can provide the user name for those IDs? 

On Windows, listusermap does not allow you to specify a single ID, it's all or nothing.
  
Thanks,

Since we don't run Lawson on Windows here, all I can do is point you to other places.
https://www.lawsonguru.co...ldap-finding-userid/

Assuming you use LawsonSecurity, you can obtain the userid from the NT Id in a roundabout way:

1. Convert the NT Id from hex to decimal using a text editor tool (I use notepad++, which is an open source freeware download). This decimal value is the users uid in Lawson Security. In your case, 'NT0000001c' in hex is '0x1c'... and converted to decimal, the value is 28.

...Now, take the decimal value (28) of the NT Id and use it to find the user in Lawson Security...

2. Go to 'Manage Identieties' and select your product line from the listed 'Services'.
3. On the Select Identities tab, leave the first drop down set to "and".
4. In the second drop down, choose "uid".
5. Put your value of '28' in the value box on the right.
6. Click the 'Add Criteria' button.
7. Click the 'Execute Query' button below.
8. Then, click/highlight the sid value dispayed on the results tab and the details of that user wll be displayed below, with the 'RMIds assigned to Identity' being displayed at the very bottom. This is the user id associated with that NT Id.

Hope this helps!

I wrote a quick little sql query to get the jobnames out of the recdef, and linked to the jobstep table to get each of the steps, then eventually to the dstgrpuser table to get all of the employees for each step of the jobs.
[code] SELECT RECURJOB.JOBNAME, RECURJOB.FREQUENCY, DSTGRPUSER.DSTGRP, DSTGRPUSER.USERNAME, JOBSTEP.STEPNBR, JOBSTEP.TOKEN, JOBSTEP.DESCRIPTION, JOBSTEPRPT.DSTGRP FROM ((GEN.RECURJOB RECURJOB INNER JOIN GEN.JOBSTEP JOBSTEP ON (RECURJOB.USERNAME=JOBSTEP.USERNAME) AND (RECURJOB.JOBNAME=JOBSTEP.JOBNAME)) INNER JOIN GEN.JOBSTEPRPT JOBSTEPRPT ON ((JOBSTEP.USERNAME=JOBSTEPRPT.USERNAME) AND (JOBSTEP.JOBNAME=JOBSTEPRPT.JOBNAME)) AND (JOBSTEP.STEPKEY=JOBSTEPRPT.STEPKEY)) INNER JOIN GEN.DSTGRPUSER DSTGRPUSER ON JOBSTEPRPT.DSTGRP=DSTGRPUSER.DSTGRP ORDER BY RECURJOB.JOBNAME, DSTGRPUSER.DSTGRP, JOBSTEP.STEPNBR [/code]

You'll still be stuck with the NTID's though on Windows.

Here is that basic sql turned into a Crystal report if it helps anyone out there.

Thanks Greg.  I'll look into a way to run SQL from the command line. 

If you can mix in a perl script, I can get you pointers?
http://dolio.lh.net/~apw/...rl_to_SQL_Server.pdf