Fast and successful week...

It was a really good week, it went by very fast and I have managed to get ahead of schedule. I hoped to finish off the week with a home run but best I could do was lay the foundation for a good start next week. ;)

I am unable to see the recently setup MidRetail test server from the test LPAR. So I spent the morning verifying the iSeries TCP and NetServer configuration and testing the QNTC file system. I took my findings to the IT Manager and he reached the same conclusion, there is a DNS problem. Come to find out, the MS DNS server for the test network recently died and new server had to be reconfigured manually. Unfortunately the iSeries entries were missed. I do not have access to the server so have to wait until Monday to have the network guys figure it out.

The iSeries QNTC file system is part of the iSeries Netserver and allows the iSeries programs output stream files, STMF, directly to a Microsoft Windows share. Very cool stuff, easy to setup and really handy when you need to feed your back end data to a PC application.

I have been using MidRetail on the the production server since the iSeries test LPAR is on a different Domain and unable to directly communicate. While waiting on the Microsoft Application test server to be setup I have been moving documents between systems manually to test my XML output. Once we get the connection issues resolved I will be able to install the MidRetail application on the test server and be able to start daily full cycle testing of the completed interface programs.

I finished polishing the Store interface program and moved on to the Sales History interface program. Each program grows in complexity as I work through the project. This interface requires that store sales be summed to Date, Store, Style, Color and Date, Store, Style, Color, Size daily and  Date, Store, Style, Color weekly. The input data is from a file that is populated nightly from sales of over 300 stores. This is looking like a good fit for my first embedded SQL, whoopee!

I may break the task into two programs, daily and weekly, that creates three XML documents. Some consideration will be needed on handling missed Stores and how to process them once data is retrieved.

I have been writing and learning RPGLE Free and now ready for trying my hand at some embedded SQL. I have seen working examples but have never actually coded myself. I do use SQL Explorer on a regular basis to write Select queries to verify data and find it extremely useful. I have a day or two to work out the techniques but if it looks like it will take me too long to figure out I will just fall back to RPGLE.

After a couple of hours with the IT Manager I have enough information to start analyzing data and putting together a plan. I ran a few SQL queries over the file and have a good feeling for what needs to be done.  

~Richard


Three things are certain:
Death, taxes, and lost data.
Guess which has occurred.
~David Dixon, 1998, winning entry of the Haiku Error Messages 21st Challenge by Charlie Varon and Jim Rosenau, sponsored by Salon.com

iSeries DDM file copy rookie mistake....

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;

CPYF      FROMFILE(TEST/SOMEFILE)  TOFILE(TEST/SOMEFILEDDM)   MBROPT(*REPLACE)

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