Dale,
David's probably going to say to post this on another list but re-copy the data with *MAP *DROP instead of *NOCHK. *NOCHK just copies the bits over without regard to what field they are supposed to be in. Using *NOCHK can bite you badly and you should not use it unless it is required for the copy (like when you change the data type on a field).
*MAP *DROP will put the fields in their proper place in the new file. If you look at the data, you'll probably find bits and pieces of the timestamp in the new fields you added.
The reason you're seeing the date of the copy in the timestamp fields is that the default behavior when you write a record and don't provide the data is to put the current date and time in it.
Matt
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of dale janus
Sent: Friday, July 24, 2009 11:07 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: timestamp data type in DDS
I know this may not be pure RPG, but I have an "interesting" set of
circumstances that need some light shed on.
We created a file with DDS. In this file, we put a timestamp field as
the last field, type Z. This was so PHP could make use of the date in
a format it recognized rather than a 6 digit number. The file is a
dashboard file with one record per day and we want to use some google
tools to display as graphs, charts, etc.
After creating the file and getting some PHP programs to use the data,
we found we needed to add new fields. Rather than add them on the end,
I put them in the front of the timestamp field, so that timestamp was
the last field in the file? Why? I don't know. I probably should have
just added the new fields to the end of the file.
Then I used my normal technique of CPYF with NOCHK to populate the new
file with data, leaving the new fields blank. Much to my surprise, this
changed all the timestamps to the date and time of the CPYF. I used
DFU to change only the date portion of the timestamp to reflect the
correct day, since we don't care about the time part.
This broke the PHP program, causing a fetch error. Now that I'm
thinking about it, the PHP program probably did not work before I
changed the dates.
PHP can open the file ok, but anything after that gets a fetch error:
*Warning*: db2_fetch_both() [function.db2-fetch-both
<
http://192.168.1.200:88/dashboard/function.db2-fetch-both>]: Fetch
Failure in */www/sptserver/htdocs/dashboard/index.php* on line *8*
We can read the old file just fine.
I am guessing there is invalid data in the timestamp field.
So what is the magic with a timestamp field? Why did the timestamp
change in the first place from my copy? Did I create invalid data when
correcting it with DFU? How do I go about correcting a timestamp
field? How do I go about adding fields to a file with timestamp without
changing the stamp?
---Dale
midrange.com
