Midrange News for the IBM i Community


Posted by: Bob Cozzi
Rogue Programmer
Cozzi Productions, Inc.
Chicagoland
Restore Members
has no ratings.
Published: 09 Mar 2012
Revised: 23 Jan 2013 - 4110 days ago
Last viewed on: 24 Apr 2024 (5703 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.

Restore Members Published by: Bob Cozzi on 09 Mar 2012 view comments(3)

I asked this same questions but a different way a few weeks ago.

What I want to do is save source file members on one system and restore those source files members to an existing source file on another system WITHOUT REPLACING the target source file (i.e., do not delete all the existing members).  Any ideas?

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: Restore Members
Posted: 12 years 1 months 15 days 20 hours 25 minutes ago
Edited: Fri, 09 Mar, 2012 at 10:50:47 (4430 days ago)

Sounds like you want MBROPT(*NEW); this only restores members in the save that do not currently exist in the file. If you want to replace existing members, that's *OLD. If you want *NEW and *OLD, that's *ALL. *MATCH, however, means it only restores, and overlays, if the list of members is identical between the save and the *FILE.

You'll also need ALWOBJDIF() for file level and owner. If you don't tell it to ignore those, and there are object level differences, it doesn't restore (which might be a good thing). If you use ALWOBJDIF(*ALL), and there are object level differences, that's when restore renames the existing file to *000n, and creates new object with what's restored (which is usually a pain in the neck, but at least you still have everything).

Might want to save the restore-to object to a save file or something, so you can reset it if you don't like the results after your restore.

Posted by: bobcozzi
Site Admin ****
Chicagoland
Comment on: Restore Members
Posted: 12 years 1 months 12 days 19 hours 44 minutes ago
Edited: Mon, 12 Mar, 2012 at 11:29:49 (4427 days ago)

Dale, you're right, what I want is at the member-level the ability to restore in the same way we can at the object level. If I restore a member to QRPGLESRC, I don't want to replace the QRPGLESRC file entirely and end up with just the one member--that's just incredibly stupid and careless design. If I restore one object to a library, it doesn't delete all the other objects--imaging if it did.

If I change one member and create a new one, I'm screwed there too.

We do development on one system and push those changes out to 7 to 10 other systems and this is constantly giving us problems.

I think what I am going to do is this:

  1. Save the file/members on system DEV to a savf.
  2. FTP that save file to system PROD.
  3. Restore the objects to QTEMP.
  4. Use CPYSRCF to then copy FROMMBR(*ALL) from QTEMP to the target library.

That is the only way it will actually do what I want. If I'm missing something let me know.

Posted by: DaleB
Premium member *
Reading, PA
Comment on: Restore Members
Posted: 12 years 1 months 12 days 19 hours 10 minutes ago

Your process is very similar to what I do with certain libraries for refreshing test data from production saves. I'm not sure about restore to QTEMP, though; you might need to create a real library. I use RST* for restore-to temporary holding place libraries, but of course your naming might not work with that. Before restoring, part of my process includes the step "Clear the RSTxx library", which removes the need for ALWOBJDIF. You might want to use a member list on either the save or the restore, to keep the size down.