Moving spool files from one AS400 to another

Pperry

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: November 12, 2004 5:47 AM Last updated: November 26, 2009 1:35 AM

Answer Wiki

Last updated: November 12, 2004 10:28 AM GMT

Byimw020 pts.
History
Contributors
- Ordered by most recent
- Byimw020 pts.

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

Ant009 Nov 14, 2004 4:59 PM GMT

Another method is to create a remote outq which points to an outq on the remote iSeries Server

0 pointsBadges:

report
MikeCody Nov 15, 2004 10:39 AM GMT

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 Nov 15, 2004 1:09 PM GMT

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 Nov 26, 2009 1:35 AM GMT

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