Midrange News for the IBM i Community


Posted by: Bob Cozzi
Rogue Programmer
Cozzi Productions, Inc.
Chicagoland
Isn't there any way to do Restore?
has no ratings.
Published: 01 Feb 2012
Revised: 23 Jan 2013 - 4082 days ago
Last viewed on: 28 Mar 2024 (14288 views) 

Using IBM i? Need to create Excel, CSV, HTML, JSON, PDF, SPOOL reports? Learn more about the fastest and least expensive tool for the job: SQL iQuery.

Isn't there any way to do Restore? Published by: Bob Cozzi on 01 Feb 2012 view comments(5)

If I do a SAVLIB each night of a library with database files in it, and then restore that library onto a backup machine (sending it over via FTP each night), I'm having a bit of an issue.

If I do a plain old RSTLIB it will restore all files that match file-to-file and mbr-to-mbr. But if the file's member list changes it doesn't restore. If I add MBROPT(*ALL) then I also have to do ALWOBJDIF(*ALL) and what happens is that if a member is in a file with MAXMBR(1) doesn't match last nights backup, a new member is added and the old one renamed to mbr000001 like you'd see with a source file and its members.

All I want to do is a restore each night on the backup system so that I have an identical set of libraries each morning when the client's store opens. One system is on-site the other is in a remote location. Sort of a poor man's D/R setup.

What's happening is that the first night everything works, but the 2nd night, I get the error on the RSTLIB about the maxmbrs being exceeded so it doesn't restore.

Am I thinking wrongly here? Or shouldn't there be something like REPLACE(*YES) on the RSTLIB command so that existing objects are replaced and new ones are added?

ALWOBJDIF(*ALL) requires MBROPT(*ALL) and that causes MBR00001 to be generated for existing members. WTF?

IF I do a RSTLIB with MBROPT(*NEW) and then another RSTLIB with MBROPT(*OLD) I get the results I want but WTF? Why should I have to do two restores just to avoid the renaming of the members?

Return to midrangenews.com home page.
Sort Ascend | Descend

COMMENTS

(Sign in to Post a Comment)
Posted by: DaleB
Premium member *
Reading, PA
Comment on: Isn't there any way to do Restore?
Posted: 12 years 1 months 25 days 3 hours 43 minutes ago

I guess it's always been that way; amazing what you can get used to. When I refresh test data, I restore to a separate library, then have a program that copies member by member into the target (i.e. actual restore) library.

You could probably write some sort of workaround using the file you get from the SAVx command with INFTYPE(*MBR). Use that on the target system to deal with existing members before you restore. The two-restores option is a reasonable compromise, but it will never go away; at least you don't have to deal with rewinding media if you're using save files.

But the real question is, why are you using multi-member files in the first place?

Posted by: bobcozzi
Site Admin ****
Chicagoland
Comment on: Isn't there any way to do Restore?
Posted: 12 years 1 months 24 days 23 hours 57 minutes ago

I'm not using multimember files except for source code.

The restore is (maybe due to owner changes or something else) but we have a lot of files restored with member renamed to XXXX00001, and not only source files.

Posted by: DaleB
Premium member *
Reading, PA
Comment on: Isn't there any way to do Restore?
Posted: 12 years 1 months 24 days 7 hours 37 minutes ago

You can restore an object to a different library. You can restore an entire library to a different library. What you can't do is rename an object as part of a restore, and you can't rename a specific member as part of a restore. No combination of MBROPT and ALWOBJDIF is going to change this.

Any reason you can't clear the restore-to library before restoring? CLRLIB takes time, but will solve the problem. The only real complication is the loss of object authorities, in which case I'd consider authorization lists. The *AUTL has to exist on both servers, but the user's in the *AUTL's can be completely different.

Posted by: bobcozzi
Site Admin ****
Chicagoland
Comment on: Isn't there any way to do Restore?
Posted: 12 years 1 months 24 days 35 minutes ago

I'm not sure what is going on, but we do a SAVLIB and then a RSTLIB to a backup system. On that backup system on "day 2" the library already exists. In some (many?) cases the RSTLIB tries to rename the members in the database files much like it does when you restore a source file and the member(s) already exist. Problem is since the DB files are MAXMBRS(1) the restore doesn't complete. That is the issue I'm trying to resolve.

Posted by: DaleB
Premium member *
Reading, PA
Comment on: Isn't there any way to do Restore?
Posted: 12 years 1 months 23 days 8 hours 1 minutes ago

So ... library name, file name, and member name are the same, and restore wants to rename members within a file, while keeping the file name the same? That's just bizarre. Usually it wants to create a new object with a different name with the 000n business.

Joblog for RSTLIB has too much stuff to wade through. Can you isolate to one object? Do RSTOBJ for one of these files, and make sure OPTION, MBROPT, and ALWOBJDIF are the same as the RSTLIB. Probably should submit with the same user profile and job de!--script--ion, so you don't introduce other side effects due to different user authorities, special authorities, etc.