Wpoulin
1115 pts. | Oct 22 2009 6:34PM GMT
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
TomLiotta
7990 pts. | Oct 23 2009 12:58AM GMT
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
Wpoulin
1115 pts. | Oct 23 2009 12:25PM GMT
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
TomLiotta
7990 pts. | Oct 26 2009 12:37AM GMT
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






