Moving spool files from one AS400 to another

pts.
Tags:
AS/400
Backup and Recovery
DB2 administration
Hardware
IBM DB2
Installation
Migration
UDB for iSeries/i5
I'm having a problem retaining the spool file attributes when I tranfer spool files from one ISeries to another. I can use the SNDTCPSPLF and it retains most of the attributes but does not retain the user and date/time attributes of the original spool file. Any suggestions??
Asked: Last updated:
Related Questions
1

Answer Wiki

Thanks. We'll let you know when a new response is added.

I am more familar with the SNDNETSPLF command which has a DTAFMT parameter. The value *ALLDATA will retain all the attributes of the spool file except creation information. The user id and creation date/time are new because you are actually sending a created copy of the original spool file to a user on a target system. If you require original date/time and user information, rely on the spool file’s content as reference which is not change in the copy process. I have found these commands useful to send copies of a report to multiple users at their local printers without having to rerunning a report job stream.

Discuss This Question: 4  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • Ant009
    Another method is to create a remote outq which points to an outq on the remote iSeries Server
    0 pointsBadges:
    report
  • MikeCody
    As noted in the first reply SNDTCPSPLF actually creates a copy of the spool file on the remote system which has the user data of the account used to access the remote system. Depending on what you are using this for you can do many things. In xfer'ing spool files from AS400 to another during an hardware upgrade, I wrote a program to build a file list, gather attributes, etc.. and then submit a job under a diff user ID using the user id in the attributes. This of course would not work if that user didn't have an account and security on the remote machine.
    0 pointsBadges:
    report
  • Harrydean
    Spool files are considered to be temporary objects. As such, the attributes of the job, date, user, etc. are not retained when they are sent to another sytem. I ran into this problem some time ago and this was the response I was given by the Rochester, MN. SupportLine people. They said there was no way around this. This is true even if you use BRMS to save the spool files and then restore them to the same system.
    0 pointsBadges:
    report
  • TomLiotta
    Note that this could invalidate audit results. Is the user the same user that created the splf? No, it's not -- there are two user IDs that happen to have the same spelling (assuming there is a match). Was it created by the same job? No, it was not. Job 123456/XUSER/YJOBNAME on one system is not the same job as job 123456/XUSER/YJOBNAME on the other system. By wanting to have the system retain attributes across systems, there's an implication that audit trails are less important. A door is opened that could be used to generate seriously misleading results. Since spooled files should never be used as permanent records anyway, there is no reason even to keep them around. If you need to look up something, look at the files that were used to generate the spooled files. Spooled files should be printed (or otherwise distributed) and then deleted. Tom
    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.

Following

Share this item with your network: