×
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.