Hi Family.
Working toward my better knowledge of onbar, I'm writing a Perl script to sort the DBspaces and logs sections of the oncfg file in more sensible ways. (I have yet to determine if my new employer will permit me to post it where y'all can get it.) My source of information on the columns is the IBM site: Facts about the ONCFG file
(There is a minor flaw in the section on the logs - skipping one column number.)
The columns are:
1 Object Name
2 Log file number
3 Log file flags
4 Time stamp
5 Date/Time file filled
6 Unique identifier
7 Is the beginning page of log file in chunk
8 Is the beginning page of log file in chunk offset
9 Log size
10 Number pages used
(Hmm.. Very few of these are in sysmaster:syslogs.)
The difference in meanings between lines 7 and 8 is a bit confusing but my main issue is column 4: the "time stamp". When I printf() a line using %u format for this column those numbers are 20 digits long. (%d in the printf() format yielded negative numbers.) Among the saner values, I have numbers like 2125340496 (32-bit); for the 20-digit value I have numbers like 18446744071566045023 (64 bit?). Either way they are not useful numbers to the human trying to make sense of them. If they are datetime values in some internal binary format, is there an Informix task that can decipher these into human-comprehensible date-times? Or am I completely misreading that document? And why would there be both sized numbers here? BTW, Excel messes up the big numbers, zeroing out the lowest 5 digits.
For that matter, column 5 - Date/Time file filled - makes no human sense if it is a data-time value.
Quite a while back, on the newsgroup comp.databases.informix (remember newsgroups?) red_valsen posted a question about a sysutils query that could generate the columns in the ixbar file. That was obviously trying to comprehend the ixbar columns. (I intend to revive that question in a separate thread.)
The ideal solution to my issue would be for someone to post a query, likely in the sysutils database, that could be used to produce the oncfg data. My utility must work on the oncfg directly because it should work even when the server is down. But it would make the information in oncfg more comprehensible.
Anyone out there willing to share such deep-down knowledge?
Thanks much!
------------------------------
Jacob Salomon
---
Nobody goes there anymore, it's too crowded. --Attr: Yogi Berra
------------------------------