logical file restore to test library, physical in different library

[davidjurban]

Hello all,
I tried to create a test library at my new job by restoring backup tape to tst libraries. Physical files in vendor library, homegrown logicals in another. I thought as long as I created the logicals via dds and related them to the physical files in the other test library, that any restore of the logicals would keep the test/test relationship intact. I recieve a CPI320A while restoring many of the files...file level identifiers do not match. The existing file is renamed, and a new logical is created with the restore file name, and now points to production physical. How do I prevent this renaming problem?
Thaks in advance.

[kitvb1]

Re: logical file restore to test library, physical in different library

Hi David

Do not compile them. You can set up your libl so that your test lib is at the top, then just use the CRTDUPOBJ command to create the LF in the test lib. This way, the file level identifiers remain the same for test as in live.
If you have many LF's to create, then using option 3 with PDM is even easier.

[davidjurban]

Re: logical file restore to test library, physical in different library

Thanks Kit, I wish it was that easy. I have the physical file library in my list but crtdupobj still creates the logical file based on the production physical file, not the test.

[davidjurban]

Re: logical file restore to test library, physical in different library

This link may help.... http://www.itjungle.com/fhg/fhg090804-story03.html

[davidjurban]

Re: logical file restore to test library, physical in different library

it's a pain in the butt, but like Ted says "I don't like roundabout methods. I hope there's an easier way that I'm overlooking and that someone will tell me about it. "
Vielen Danke

[DeadManWalks]

Re: logical file restore to test library, physical in different library

at here, we do a one time thing. copy all PF to test. Create the LFs in your lib.

Future, any time you make a new LF , make one in your lib as above.


Then when you want to refresh data, you only refresh the PFs, not the LF.

[tomliotta]

Re: logical file restore to test library, physical in different library

Why restore the LFs at all? The major (only?) reason should be because the LF definition has changed. In that case, the file identifier shouldn't matter because you could delete the LFs before restoring. But even better, instead of restoring, simply recreate them. Why restore LFs in a test environment? (Especially if libraries don't match anyway.)

[davidjurban]

Re: logical file restore to test library, physical in different library

Excellent point, Tom. While "sleeping on it", that same thought crossed my mind. Too bad RSTLIB OMITOBJ *ALL * FILE doesn't have a LF parameter.

[DeadManWalks]

Re: logical file restore to test library, physical in different library

You could always just ftp the data from the prod box to the test one. Thats what i do here. have different scripts for different data sets i need. I never have to worry about LFs that way.

[davidjurban]

Re: logical file restore to test library, physical in different library

Unfortunately, we don't have a test box to ftp from...one server that houses production and test. That's why it is necessary to get the paths correct. Thanks for everyone's help. I've deleted/recreated all the logicals and then omitted them in the RSTLIB command.

[tomholden]

Re: logical file restore to test library, physical in different library

one other tidbit CRTDUPOBJ will work as long as the library name is not specified in the DDS for the LF. if the library name (LIB/FILE) is specified in the DDS then it will always point to the file in that library. also if using CRTDUPOBJ you need to be aware that since (v6.1 i think, could be v5r4) there are "new" parameters you should ensure to handle correctly. CRTDUPOBJ will now duplicate triggers, journaling, constraints, etc. so if you have triggers, etc make sure that you deal with those appropriately.

[davidjurban]

Re: logical file restore to test library, physical in different library

Good stuff, Tom. I did encounter hard coded libraries in the dds which I took care of early in the process which thought would take care of my issue of test logicals pointing to prod, but restoring prog logical to test logical was the culprit. I believe IBM would do us all a favor by allowing us to OMIT *FILE LF in the RSTLIB command so explicitly adding all logicals to the OMIT wouldn't be necessary.

[tomholden]

Re: logical file restore to test library, physical in different library

well if you wanted to & have less than 300 objects you could write a custom command that calls a CL that does DSPFD on file in the library and read thru and string together the objects to omit and use that on a RSTLIB command

[Scott Klement]

Re: logical file restore to test library, physical in different library

CRTDUPOBJ added triggers and constraints in V5R4.

[tomliotta]

Re: logical file restore to test library, physical in different library

I tried to create a test library at my new job by restoring backup tape to tst libraries. Physical files in vendor library, homegrown logicals in another.

You tried to create "a" test library. The restore was to "libraries". Homegrown logicals are in another ("library").

An issue with hard-coded libraries would make it all moot, but it seems you have that cleared up. What's not very clear from this side is exactly how you want things to look based on the restores. Are you doing multiple restores into different test libraries?

...we don't have a test box to ftp from...one server that houses production and test.

It's not relevant to your problem, but FTP "server" and FTP "client" are separate functions. They don't care what each other is doing. Also, IP addressing works even within a single system. If you have reason to do it, SystemA can FTP to SystemA. Using FTP to LOCALHOST or LOOPBACK is often even better. It's a small bit of knowledge, but maybe worth remembering.