Re: How can I copy only certain file types to tape and/or

Dave

A couple ideas - you can get a list of the files, as you know, with DSPOBJD to 
an output file. The attribute, whether PF or LF, is contained in that 
information. Then loop through the output file and take action only for PFs.

I'm not sure I get the problem with SAVF's - if you save the PFs and their LFs 
together, you can save them without access path data, for one thing. In any 
case, the restore works just fine, in my experience - nothing points to the old 
system, as I recall. You must restore the PFs first - I assume you knew that. 
It really doesn't matter what the libraries were - you WILL have trouble if you 
restore the LFs to a library other than the one where the PFs are, however. 
Generally speaking, it's not a good idea to have PFs and LFs in different 
libraries. If you need to do that, the long-accepted practice is to send source 
for the LFs and create them on the remote system, as you describe. Many vendors 
do this anyway, as source is often smaller than the LFs would be.

Back to the CPYTOTAP - if you use this with an LF, it puts the data on the tape 
as "viewed" through the LF, as I recall. It does not put just the access path 
on tape - you use SAVxx commands for that. So you cannot use this method to put 
an LF on a remote system - besides, CPYFRMTAP can only go to a PF.

CPYTOTAP is the basic copy file technique for going to tape. It may also be 
possible to use an OVRxx command to redirect CPYF to different "file 
structures". E.g., OVRTAPF (Override with Tape File) will probably redirect 
things. This lets you have a single program, naybe, that can be wrappered with 
various overrides to direct the output where you want it. Not used so much as 
it used to be when there were more device types to worry about, perhaps, but 
still there.

But this should not be this complicated. It usually just works.

Does this help? Come on back with more questions!

Vern
-------------- Original message -------------- 

> Vern, 
> 
> I'm not fixated on any one command. I just need a command or commands 
> that will allow me to back up and recover PF and LF separately so I can 
> just move the data in the physicals from one environment to another 
> where the PF names will be the same but the library names will change. 
> This for a data refresh on a regular basis. We found that using the 
> standard movement command like SAVF backs up the PF and LF which screws 
> us because the LFs point back to the system they came from. 
> 
> I'd like to copy to tape so I don't have to take up DASD but I may have 
> to use whatever I'm stuck with. 
> 
> Again, I can't believe the iSeries doesn't have a basic copy file 
> technique found in any well architected OS that allows the movement of 
> data from one file structure to another without having to deal with any 
> logical file/view over that data. If the native OS doesn't have 
> commands or utilities that will allow me to do what I want to do I'm 
> thinking about using SQL to INSERT * ... (SELECT from ... to tables on 
> DASD and then use a SAVF, move the SAVF, "unpack" it and do a Clear of 
> the PF and then another INSERT * ... What a long way 
> around the barn if I have to do this. 
> 
> In the above case, I'm not exactly sure what I'll need to do vis-a-vis 
> the access paths/methods of the LF on the gaining system. As you can 
> imagine, the data may be new in the new PFs and the LF will have to 
> know where everything is. 
> 
> If and when I need to deal with LFs, it looks like I'll have to move 
> their Source and then recompile; much like Views over Tables. 
> 
> Any ideas? 
> 
> Thanks, 
> 
> Dave 
> -- 
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list 
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx 
> To subscribe, unsubscribe, or change list options, 
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l 
> or email: MIDRANGE-L-request@xxxxxxxxxxxx 
> Before posting, please take a moment to review the archives 
> at http://archive.midrange.com/midrange-l. 
>