× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 20-Oct-2011 19:39 , Jim Wiant wrote:
I've searched the net and tried the archives, but to no avail.

I'd like to programmatically get the date and time that the data in
a physical file changed. Not when the object changed but when the
data changed, available only (it appears) in a DSPFD statement. My
question is "Where does DSPFD get the last change date and time?" It
must be in the system somewhere...QUSROBJD shows if for example a
member was added... but not when the data was last modified.

Yes, the database *FILE object change date\time is separate from that of each member. Defer to the member for information specific to the members listed\presented by DSPFD. If supported, one might use QUSROBJD to get some information about the member object. However that API supports only "external object types":
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/rbam6/rbam6objecttypes.htm

I found the QADBXREF table in QSYS2 and it seems to have what I want
but only files in *SYSBAS not in an IASP.

The DBXATS data is the "alter timestamp" which effectively refers to the ALTER TABLE rather than data changes. If the database cross reference had to update the timestamp for each I\O on each member.data on the system....

I know that I can do a DSPFD to an outfile and read the outfile but
I feel that's rather 'old school' when I'm used to working with API's
and getting the exact information I need directly instead of commands
to outfile and/or print files.

Does anyone know where the system keeps this data? Thanks for any
help


The database file object with the external object type of *FILE is a composite object, made of a collection of other less visible\internal object types; some optional. For any file that can contain data there must be another object, the dataspace object of type *QDDS, for which there must be a corresponding object, the member object of type *MEM. To get the last change date\time of the data, that information would effectively be required from\about the dataspace object in which the changed data resides. However the database [¿both stores and?] exposes the capability to retrieve that information about the dataspace via the member object. Note that the "source" change date for the data in source physical file members is tracked separately.

In either case, the API that corresponds to the information presented by the request to DSPFD TYPE(*MBR) FILEATR(*PF) which presents the "Last change date/time" [in the US English installation as primary or secondary language] as the date and time in which either the member object or the data was last changed, is the "Retrieve Member Description (QUSRMBRD) API" with format MBRD0200:
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/apis/qusrmbrd.htm

As I recall the RTVMBRD CHGDATE() retrieves that same information. And for the source change date, the SRCCHGDATE() parameter instead.
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/cl/rtvmbrd.htm

Since the database *FILE is a directory and each *MEM represents an object [a "link"] within that directory, the details shown in "Display Attributes" of WRKLNK should be available by the stat() "Get File Information" API; stat64() may be more appropriate, if size information is also of interest. The object and data change dates appear to be exposed separately as st_mtime and st_ctime, respectively.
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/apis/stat64.htm

There is also the SQL catalog information which as I recall contains information for database file members [regardless they are not of a partitioned TABLE] via a UDTF which implements the catalog VIEW SYSPARTITIONSTAT [aka SYSPSTAT] which exposes a column LAST_CHANGE_TIMESTAMP for LASTCHG data type TIMESTAMP for which its value presumably comes from the same [place as the] "Change date and time" of the MBRD0200 format for the QUSRMBRD API:
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/db2/rbafzcatsyspstat.htm

Regards, Chuck

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.