It’s been a long time since I have clobbered production data, but sooner or later everyone gets bit. I am currently working on a project to interface iSeries application with a Windows SQL based application. While working on the concept for the technical design document I needed fresh test data.
The iSeries system I am working on has two LPAR’s, one production and one test. I only have access to the test system. I have never had the opportunity to work on a partitioned system but have studied the setup more than a few times. I have seen DDM in passing but have not worked on multiple networked iSeries in a long time.
Last week, when discussing the need for test data, the Manager quickly created a DDM file on the test LPAR. He then ran the copy command to populate the test file from the production system. I missed what system he ran the copy from and assumed it was on the test system. That was pretty cool and looked easy enough. I should have stopped right there and studied up on DDM!
Yesterday I needed some fresh data to validate that my program is working as desired. I ran a WRKOBJ *ALL/SOMEFILE and observed two objects one specified as DDM. I displayed the DDM object and observed the remote system is the production partition. I opened up the IBM Information Center and search on DDM. I read that the DDM file only needs to be created once so I know I don’t need create it again. I determined that I need to run the following command;
This should copy the file from production to test. I copied the command right out of the book and replaced with correct names.
The command failed with User not authorized, cool security is working.
I then asked another programmer if he had access and could run the copy for me. I copied the command and sent it to him via E-mail. As soon as the copy was done I started looking at the data and found it was not updated. We then get together and start analyzing the production data and find it is not correct, change date was today and should not be. The file is updated nightly.
Somehow we miscommunicated and we think he ran the copy command on the production system. I assume if you run the command on the production system the data is copied from test system, there does not seem to be any other explanation.
I did not realize that the DDM was a two way street and after studying the manual I have not found where that is documented. The DDM file is only on the test system, I could see this being an issue if a DDM file existed on the production system pointing to the test system.
In the end it turned out not to be a big problem, the file stepped on was created from a journal file and only took five minutes to correct the production file. Good thing since the tape backup failed the previous night.
All is well that ends well!
A failure is a man who has blundered, but is not able to cash in the experience. ~Elbert Hubbard
~Richard
The iSeries system I am working on has two LPAR’s, one production and one test. I only have access to the test system. I have never had the opportunity to work on a partitioned system but have studied the setup more than a few times. I have seen DDM in passing but have not worked on multiple networked iSeries in a long time.
Last week, when discussing the need for test data, the Manager quickly created a DDM file on the test LPAR. He then ran the copy command to populate the test file from the production system. I missed what system he ran the copy from and assumed it was on the test system. That was pretty cool and looked easy enough. I should have stopped right there and studied up on DDM!
Yesterday I needed some fresh data to validate that my program is working as desired. I ran a WRKOBJ *ALL/SOMEFILE and observed two objects one specified as DDM. I displayed the DDM object and observed the remote system is the production partition. I opened up the IBM Information Center and search on DDM. I read that the DDM file only needs to be created once so I know I don’t need create it again. I determined that I need to run the following command;
This should copy the file from production to test. I copied the command right out of the book and replaced with correct names.
The command failed with User not authorized, cool security is working.
I then asked another programmer if he had access and could run the copy for me. I copied the command and sent it to him via E-mail. As soon as the copy was done I started looking at the data and found it was not updated. We then get together and start analyzing the production data and find it is not correct, change date was today and should not be. The file is updated nightly.
Somehow we miscommunicated and we think he ran the copy command on the production system. I assume if you run the command on the production system the data is copied from test system, there does not seem to be any other explanation.
I did not realize that the DDM was a two way street and after studying the manual I have not found where that is documented. The DDM file is only on the test system, I could see this being an issue if a DDM file existed on the production system pointing to the test system.
In the end it turned out not to be a big problem, the file stepped on was created from a journal file and only took five minutes to correct the production file. Good thing since the tape backup failed the previous night.
All is well that ends well!
A failure is a man who has blundered, but is not able to cash in the experience. ~Elbert Hubbard
~Richard
I had to refresh my data and it gave me a chance to run the command. The problem was I copied right out off the book not realizing it was backwards. The DDM file is located on the test partition pointing to the production partition.
ReplyDeleteThe correct way -
CPYF FROMFILE(TEST/SOMEFILEDDM) TOFILE(TEST/SOMEFILE) MBROPT(*REPLACE)
Will not make that mistake again.