Every evening we create Save Files of our Production Libraries on our Production System. The next morning we FTP these Save Files to our Development System and do Restores to our Production Libraries on our Development System. We use TurnOver to handle the changes to our SQL Tables, Indexes, and Views. The issue is that after a change has been made to a Table, Index, or View, and the change is Distributed to our Production System the next morning the restore of that object fails. On the RSTLIB we are using ALWOBJDIF(*AUTL *FILELVL). The err msg is CPF3283 - The restore operation was not done because the member level ID that presently exists on the system is not the same as the member level ID for the file on the save media. Any idea on how we could improve upon this process so we don't get these error messages.
Software/Hardware used:
OS/400 i5
ASKED:
October 22, 2009 3:43 PM
UPDATED:
October 26, 2009 12:37 AM
Whatis23,
I used SAVRSTOBJ with ALWOBJDIF(*ALL) on the files in error and Yes OS/400 renamed my files with 00001 at the end, but did restore the files. I then had to do cleanup of the 00001 files.
I then tried the DLTF first and then the SAVRSTOBJ, which does work.
I was hoping for a cleaner solution, one that could be either incorporated into TurnOver’s Promotion/Distribution process or into my Production Libraries Restore process.
Any other thoughts ??
Thank You,
Bill Poulin
ALWOBJDIF(*ALL) needs to be together with MBROPT(*ALL).
However, I’d likely change the whole process. I’m not sure what the point is. What exactly is this process intending to accomplish?
Tom
Tom,
The Save of our Production data on the Production System happens just prior to our nightly run. If there are issues with the nightly run the programmers can look at the data as it was before any updates were done, make corrections and test on the Development System.
How would you change the process ?
Thanks,
Bill Poulin
Bill:
If there are issues with the nightly run the programmers can look at the data as it was before any updates were done…
Ouch. The implication is that this is needed often enough to make it a feasible procedure. Well, if it works…
It shouldn’t be necessary though. Basic journaling, for example, should help considerably. Errors could be backed out to the beginning of the process leaving everything where it started. Error logging should point to any exceptions that occurred. Journaled transactions should show the exact sequence of events against data.
It shouldn’t take but a few minutes to determine a cause for developers familiar with the nightly process with the underlying info available.
However, there’s no way to go through what might need to be done in a forum such as this. Is this many years of development that might need adjustments? Layers off changes, continual pressure to get the next enhancement in place while fighting fires,… never any time allocated to go through and do what’s needed…
Probably a decent development staff. Probably harboring frustrations about what they’d like to do (or maybe learn). Possibly limited by hardware — e.g., a couple disk units short of needs.
And budget…?
OTOH, you apparently can create a more or less complete development image of the production system. I’d want to know how hardware resources are partitioned before starting to think seriously. Even then, it’s like laying out any other app in a few notes. All it can be is… a few notes.
Tom