Midrange News for the IBM i Community

Posted by: Bob Cozzi
Rogue Programmer
Cozzi Productions, Inc.
Isn't there any way to do Restore?
has no ratings.
Published: 01 Feb 2012
Revised: 23 Jan 2013 - 2187 days ago
Last viewed on: 19 Jan 2019 (5382 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