DB2 - Date table was last ALTERed

HI All,

Is there any way on AS400 that I can find out when a table in a schema was last ALTERed. Currently we don't have any mechanism to track table changes in production. ALTER commands are run manually during the implementation of every release. As part of an audit we have been asked to provide a list of all tables that have changed since 2010.

I tried doing a DSPOBJD of all objects in our production schema and then using the "Change Date" column to get the information i need. To my dismay I realized that "Change Date" gets updated every time I run an update on the table data.

Any ideas?

Who is Participating?
Good choice for ALTER_DATE from PRODSCHEMA/systables. It might depend on what version your OS is. I suspect that almost anything in version 5 or later should make it reliable, especially if the DB2 group PTF level is reasonably current.

I would run DSPFD to an outfile, selecting a wide subset of physical files. I would include both DDS PFs and SQL tables. Then I would input that file into a simple program that passed each file through the Retrieve Database File Description (QDBRTVFD) API. The file identifier level is right in the header at offset 69 as a CHAR(13) field. I would have the program convert the file ID to a timestamp, and the file name, library and timestamp would all be written into a new table.

That should be easy enough to create. It gives you a good set of test data to start from.

Then I'd run a SQL statement that compared that timestamp for each file against the timestamp from SYSTABLES.

If they all match, then I'd be satisfied with reliability on that system. If they didn't match, I'd attempt to reconcile any mismatches and make my decision based on results.

I haven't had to do the same thing you're doing, so I don't have anything available. But the API will be simple because you won't need to drill into any of its data structures. You only need to retrieve 82 bytes or so for each file you test.

As long as reliability is acceptable, I'd go with ALTER_DATE from the system database catalog. There have been times when DDS PF details weren't recorded the same in the SQL database catalog as SQL tables. I'd just run a basic test to be comfortable. Most recent releases have been pretty good at it.

Dave FordSoftware Developer / Database AdministratorCommented:

To my knowledge, the only way to tell if the table was ALTERed would be to look at the journals. An ALTER would record a journal entry of type CH and code F ... probably also an entry of type CG with a code of D.

As you discovered, the "last change date" in DSPFD includes the changes in data, not just structure. Therefore, I think the journals are the only way to detect changes in structure.

You might review the "File level identifier" of the tables. This is a kind of timestamp value in the form CYYMMDDHHMMSS that attempts to record the current version level of the file object. Changes to data do not affect the file level, but recreation of the file or ALTER TABLE operations that change structural characteristics will generate new file level IDs.

Note that this value is not the same as a member level ID nor a format level ID.

I'm not sure if there's an easier way to check.

Cloud Class® Course: CompTIA Cloud+

The CompTIA Cloud+ Basic training course will teach you about cloud concepts and models, data storage, networking, and network infrastructure.

Dave FordSoftware Developer / Database AdministratorCommented:

Tom, that's really cool. I never knew that about the file level identifier. That information will definitely come in handy. Thanks!

-- DaveSlash
bhagataliAuthor Commented:
Hi Tom,

I had been working all morning today to get that file level identifier extracted. You are right. That field is like a time stamp and gets affected only with an ALTER. Apparently the only easy way to extract that information is using an API. Do you know of any easier method?

There was someone else in my team who found that the the SYSTABLES contains a last modified information too.

select  substr(table_name,1, 20) as TABLE, last_altered_timestamp  
as ALTER_DATE from PRODSCHEMA/systables                                
where date(last_altered_timestamp) >= '2010-10-01'                
and table_type = 'T'                                                    

I am now trying to determine how reliable this information is. Any thoughts on this?

I never knew that about the file level identifier.

That's used by RSTOBJ when restoring *FILE objects to choose how the restore progresses. When you see things like old copies getting renamed to something like MYFILE0001, it's usually because file IDs don't match.

Unfortunately some times, file ID doesn't work like format ID, so restores don't care if the formats haven't actually changed. It can seem messy to clean up, but there is method behind most of it.

Member IDs can get involved for member restores.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.