ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

Refreshing Production Data to a Test Server

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Refreshing Production Data to a Test Server

    After 15+ years of working with the IBM i line of servers (AS/400, System I, iSeries, etc), I have never coded a data replication scheme. I have always relied on 3rd party utilities to handle this for me. I have used SAVOBJ and RSTOBJ before, but only in scenarios where I'm not replacing existing objects. That being said, I restored a PF (PF only) to a test library, and it seems to have renamed the existing PF to MYFILE0001 and ensured the existing LF's were still associated with the renamed PF. I tried digging through documentation and various posts on the web and it seems I cannot simply restore a PF to a target system without having to somehow manage the attached LF's....or can I? I was thinking of looking into FTP'ing the PF from the source machine to the target machine but wasn't sure of the implications/impact.

    What would be the best way (without 3rd party tools) to replicate data from a production machine to a test machine (once-a-day replication is suitable for our needs)?





  • #2
    Oddly enough, if I create a test PF on both systems, and I transfer the data from one to the other using FTP it works. But the moment I try to transfer the actual production data file to the test system, it fails for 426 - Cannot write to member xxxxxx in file yyyyyy in library zzzzzzz. I researched this a little and found two possible problems:

    1. authority
    2. file size differences

    Both files were set up with the same authority, including libraries (owership and object/data authorities). I'm not sure how else to change the file sizes but I created both files with *NOMAX

    Comment


    • #3
      I just did a test using SAVRSTOBJ of a PF with attached LFs. I used SAVRSTOBJ of the PF to save it to another system, modified some records in the file, then used SAVRSTOBJ to restore it back to the original system. It worked fine.

      You must be specifying ALWOBJDIF(*ALL) when you are doing the restore. I would suggest checking the help on that parameter as the system will rename the object on the target system under certain conditions. Maybe an alternative would be to copy the source to a temporary spot on the target system then delete all the members from the target file and then copy all the members to the target would work better?

      Hard to know why the error in the FTP process, but could it be that the target file allows only 1 member in the file?

      Comment


      • #4
        Originally posted by john.sev99 View Post
        I just did a test using SAVRSTOBJ of a PF with attached LFs. I used SAVRSTOBJ of the PF to save it to another system, modified some records in the file, then used SAVRSTOBJ to restore it back to the original system. It worked fine.

        You must be specifying ALWOBJDIF(*ALL) when you are doing the restore. I would suggest checking the help on that parameter as the system will rename the object on the target system under certain conditions. Maybe an alternative would be to copy the source to a temporary spot on the target system then delete all the members from the target file and then copy all the members to the target would work better?

        Hard to know why the error in the FTP process, but could it be that the target file allows only 1 member in the file?
        Thanks for your response John. I will look into the SAVRSTOBJ option. I had previously reviewed the documentation for RSTOBJ for the ALWOBJDIF parameter and the wording seems to be a tad cumbersome for my level of understanding but it seemed that (given our situation) *ALL should have worked since the objects were exactly the same regarding record format, authority, etc.


        Comment


        • #5
          Another method to replicate the data in the file is to create a DDM file on the source machine that points to the file at the target machine and then run command CPYF FROMFILE(sourcename) TOFILE(ddmname) MBROPT(*REPLACE).

          Comment


          • #6
            Make sure you don't replace any configuration data that would end up pointing a development box to production, such as URLs, server names, JDBC settings, etc. You still want the development box pointing to other development boxes.

            Comment


            • #7
              Just keep it simple. On the basis that you are "replacing existing objects" use standard save and restore commands. Use the tape you take from a standard save and mount it on the development box. Have a CL on the Development box that you can run. The program can issue a CLRLIB command as an initial step, this prevents the first issue you experienced of the renamed objects and LF issues. Once the CLRLIB has completed run the RSTLIB command. If you have files in the library that contain data that you don't want, ie email addresses that you don't want your development or testing to send out too. you can have development appropriate data on the development box in a separated library ready to copy across ie CPYF *Replace or CPYF *ADD as appropriate. If any of those files have triggers you could remove them do the copy and then add the triggers back on.

              Comment

              Working...
              X