Informix

IDS 12.10.FC14

SOLARIS 10  1/13

The onaudit utility creates audit trail files, as documented here: Audit-record format

The second field is the date and time of the audited event.  I have enabled auditing with onaudit, and observe the audit trail files, and see that all the timestamps recorded in the audit trail files have precision only to the level of second.  For example, the following string was copy-and-pasted from an audit trail file: "2024-08-22 12:30:54.000".

The documentation ( Creating a table for audit data ) , quoted below, shows how to create a table to store output from the audit trail files.  Note that IBM shows the creation of a table which uses a precision of 1 millisecond for the datetime element:

The sample CREATE TABLE statement in the following example creates an audit table with the name frag_logs...

CREATE TABLE frag_logs(    adttag CHAR(4) NOT NULL,    date_time DATETIME YEAR TO FRACTION(3) NOT NULL,    hostname VARCHAR(128) NOT NULL,    pid INTEGER NOT NULL,    server VARCHAR(128) NOT NULL,    username VARCHAR(32) NOT NULL,    errno INTEGER NOT NULL,    code CHAR(4) NOT NULL,    dbname VARCHAR(128),    tabid INTEGER,    objname VARCHAR(128),    extra_1 INTEGER,    partno INTEGER,    row_num INTEGER,    login VARCHAR(32),    flags INTEGER,    extra_2 VARCHAR(160));

David:

I'm not sure if this affects the timestamps in the audit modules, but there is an ONCONFIG parameter, USEOSTIME, that improves the resolution of CURRENT from seconds to the maximum resolution of the processor. It defaults to zero (off) mainly because early on Informix mostly ran on XENIX and the gettimeofday() call that enabling this parameter uses was dirt slow in XENIX. In all modern OS's that system call is fast, so there is no longer any reason to not enable it in your ONCONFIG file.

Art

IDS 12.10.FC14

SOLARIS 10  1/13

The onaudit utility creates audit trail files, as documented here: Audit-record format

The second field is the date and time of the audited event.  I have enabled auditing with onaudit, and observe the audit trail files, and see that all the timestamps recorded in the audit trail files have precision only to the level of second.  For example, the following string was copy-and-pasted from an audit trail file: "2024-08-22 12:30:54.000".

The documentation ( Creating a table for audit data ) , quoted below, shows how to create a table to store output from the audit trail files.  Note that IBM shows the creation of a table which uses a precision of 1 millisecond for the datetime element:

The sample CREATE TABLE statement in the following example creates an audit table with the name frag_logs...

CREATE TABLE frag_logs(    adttag CHAR(4) NOT NULL,    date_time DATETIME YEAR TO FRACTION(3) NOT NULL,    hostname VARCHAR(128) NOT NULL,    pid INTEGER NOT NULL,    server VARCHAR(128) NOT NULL,    username VARCHAR(32) NOT NULL,    errno INTEGER NOT NULL,    code CHAR(4) NOT NULL,    dbname VARCHAR(128),    tabid INTEGER,    objname VARCHAR(128),    extra_1 INTEGER,    partno INTEGER,    row_num INTEGER,    login VARCHAR(32),    flags INTEGER,    extra_2 VARCHAR(160));

Good call Art!

I just tested this and setting USEOSTIME to 1 now includes the time fraction in the audit log.

The time fraction went from .000

ONLN|2024-08-23 21:18:21.000|localhost|1217|informixtest_shm|informix|0:INRW:sysmaster:232:1026:2566::
ONLN|2024-08-23 21:18:21.000|localhost|1217|informixtest_shm|informix|0:CLDB:sysmaster

to showing the fraction:

ONLN|2024-08-23 21:19:54.243|localhost|1290|informixtest_shm|informix|0:INRW:sysmaster:232:1026:7436::
ONLN|2024-08-23 21:19:54.245|localhost|1290|informixtest_shm|informix|0:CLDB:sysmaster

David:

I'm not sure if this affects the timestamps in the audit modules, but there is an ONCONFIG parameter, USEOSTIME, that improves the resolution of CURRENT from seconds to the maximum resolution of the processor. It defaults to zero (off) mainly because early on Informix mostly ran on XENIX and the gettimeofday() call that enabling this parameter uses was dirt slow in XENIX. In all modern OS's that system call is fast, so there is no longer any reason to not enable it in your ONCONFIG file.

Art

IDS 12.10.FC14

SOLARIS 10  1/13

The onaudit utility creates audit trail files, as documented here: Audit-record format

The second field is the date and time of the audited event.  I have enabled auditing with onaudit, and observe the audit trail files, and see that all the timestamps recorded in the audit trail files have precision only to the level of second.  For example, the following string was copy-and-pasted from an audit trail file: "2024-08-22 12:30:54.000".

The documentation ( Creating a table for audit data ) , quoted below, shows how to create a table to store output from the audit trail files.  Note that IBM shows the creation of a table which uses a precision of 1 millisecond for the datetime element:

The sample CREATE TABLE statement in the following example creates an audit table with the name frag_logs...

CREATE TABLE frag_logs(    adttag CHAR(4) NOT NULL,    date_time DATETIME YEAR TO FRACTION(3) NOT NULL,    hostname VARCHAR(128) NOT NULL,    pid INTEGER NOT NULL,    server VARCHAR(128) NOT NULL,    username VARCHAR(32) NOT NULL,    errno INTEGER NOT NULL,    code CHAR(4) NOT NULL,    dbname VARCHAR(128),    tabid INTEGER,    objname VARCHAR(128),    extra_1 INTEGER,    partno INTEGER,    row_num INTEGER,    login VARCHAR(32),    flags INTEGER,    extra_2 VARCHAR(160));

Thank you, Art and Mike, for that information.

That exactly fills the bill!

DG

Good call Art!

I just tested this and setting USEOSTIME to 1 now includes the time fraction in the audit log.

The time fraction went from .000

ONLN|2024-08-23 21:18:21.000|localhost|1217|informixtest_shm|informix|0:INRW:sysmaster:232:1026:2566::
ONLN|2024-08-23 21:18:21.000|localhost|1217|informixtest_shm|informix|0:CLDB:sysmaster

to showing the fraction:

ONLN|2024-08-23 21:19:54.243|localhost|1290|informixtest_shm|informix|0:INRW:sysmaster:232:1026:7436::
ONLN|2024-08-23 21:19:54.245|localhost|1290|informixtest_shm|informix|0:CLDB:sysmaster

David:

I'm not sure if this affects the timestamps in the audit modules, but there is an ONCONFIG parameter, USEOSTIME, that improves the resolution of CURRENT from seconds to the maximum resolution of the processor. It defaults to zero (off) mainly because early on Informix mostly ran on XENIX and the gettimeofday() call that enabling this parameter uses was dirt slow in XENIX. In all modern OS's that system call is fast, so there is no longer any reason to not enable it in your ONCONFIG file.

Art

IDS 12.10.FC14

SOLARIS 10  1/13

The onaudit utility creates audit trail files, as documented here: Audit-record format

The second field is the date and time of the audited event.  I have enabled auditing with onaudit, and observe the audit trail files, and see that all the timestamps recorded in the audit trail files have precision only to the level of second.  For example, the following string was copy-and-pasted from an audit trail file: "2024-08-22 12:30:54.000".

The documentation ( Creating a table for audit data ) , quoted below, shows how to create a table to store output from the audit trail files.  Note that IBM shows the creation of a table which uses a precision of 1 millisecond for the datetime element:

The sample CREATE TABLE statement in the following example creates an audit table with the name frag_logs...

CREATE TABLE frag_logs(    adttag CHAR(4) NOT NULL,    date_time DATETIME YEAR TO FRACTION(3) NOT NULL,    hostname VARCHAR(128) NOT NULL,    pid INTEGER NOT NULL,    server VARCHAR(128) NOT NULL,    username VARCHAR(32) NOT NULL,    errno INTEGER NOT NULL,    code CHAR(4) NOT NULL,    dbname VARCHAR(128),    tabid INTEGER,    objname VARCHAR(128),    extra_1 INTEGER,    partno INTEGER,    row_num INTEGER,    login VARCHAR(32),    flags INTEGER,    extra_2 VARCHAR(160));

Perhaps this line from the documentation on the ONCONFIG parm USEOSTIME:

"Systems that run with USEOSTIME set to nonzero notice a performance degradation of up to 4 to 5 percent compared to running with USEOSTIME turned off."

is no longer accurate, then.  That would be a high price to pay.  But, I'll give it a shot andl change that parm in our next maintenance window for our production server.

DG

Thank you, Art and Mike, for that information.

That exactly fills the bill!

DG

Good call Art!

I just tested this and setting USEOSTIME to 1 now includes the time fraction in the audit log.

The time fraction went from .000

ONLN|2024-08-23 21:18:21.000|localhost|1217|informixtest_shm|informix|0:INRW:sysmaster:232:1026:2566::
ONLN|2024-08-23 21:18:21.000|localhost|1217|informixtest_shm|informix|0:CLDB:sysmaster

to showing the fraction:

ONLN|2024-08-23 21:19:54.243|localhost|1290|informixtest_shm|informix|0:INRW:sysmaster:232:1026:7436::
ONLN|2024-08-23 21:19:54.245|localhost|1290|informixtest_shm|informix|0:CLDB:sysmaster

David:

I'm not sure if this affects the timestamps in the audit modules, but there is an ONCONFIG parameter, USEOSTIME, that improves the resolution of CURRENT from seconds to the maximum resolution of the processor. It defaults to zero (off) mainly because early on Informix mostly ran on XENIX and the gettimeofday() call that enabling this parameter uses was dirt slow in XENIX. In all modern OS's that system call is fast, so there is no longer any reason to not enable it in your ONCONFIG file.

Art

IDS 12.10.FC14

SOLARIS 10  1/13

The onaudit utility creates audit trail files, as documented here: Audit-record format

The second field is the date and time of the audited event.  I have enabled auditing with onaudit, and observe the audit trail files, and see that all the timestamps recorded in the audit trail files have precision only to the level of second.  For example, the following string was copy-and-pasted from an audit trail file: "2024-08-22 12:30:54.000".

The documentation ( Creating a table for audit data ) , quoted below, shows how to create a table to store output from the audit trail files.  Note that IBM shows the creation of a table which uses a precision of 1 millisecond for the datetime element:

The sample CREATE TABLE statement in the following example creates an audit table with the name frag_logs...

CREATE TABLE frag_logs(    adttag CHAR(4) NOT NULL,    date_time DATETIME YEAR TO FRACTION(3) NOT NULL,    hostname VARCHAR(128) NOT NULL,    pid INTEGER NOT NULL,    server VARCHAR(128) NOT NULL,    username VARCHAR(32) NOT NULL,    errno INTEGER NOT NULL,    code CHAR(4) NOT NULL,    dbname VARCHAR(128),    tabid INTEGER,    objname VARCHAR(128),    extra_1 INTEGER,    partno INTEGER,    row_num INTEGER,    login VARCHAR(32),    flags INTEGER,    extra_2 VARCHAR(160));

David:

My understanding that making the change now has little effect came from one of the developers years ago. I honestly have not benchmarked it, but a) I also have not noticed any significant degradation when enabling it, and b) if you need the resolution you don't have any good alternatives.

Art

Perhaps this line from the documentation on the ONCONFIG parm USEOSTIME:

"Systems that run with USEOSTIME set to nonzero notice a performance degradation of up to 4 to 5 percent compared to running with USEOSTIME turned off."

is no longer accurate, then.  That would be a high price to pay.  But, I'll give it a shot andl change that parm in our next maintenance window for our production server.

DG

Thank you, Art and Mike, for that information.

That exactly fills the bill!

DG

Good call Art!

I just tested this and setting USEOSTIME to 1 now includes the time fraction in the audit log.

The time fraction went from .000

ONLN|2024-08-23 21:18:21.000|localhost|1217|informixtest_shm|informix|0:INRW:sysmaster:232:1026:2566::
ONLN|2024-08-23 21:18:21.000|localhost|1217|informixtest_shm|informix|0:CLDB:sysmaster

to showing the fraction:

ONLN|2024-08-23 21:19:54.243|localhost|1290|informixtest_shm|informix|0:INRW:sysmaster:232:1026:7436::
ONLN|2024-08-23 21:19:54.245|localhost|1290|informixtest_shm|informix|0:CLDB:sysmaster

David:

I'm not sure if this affects the timestamps in the audit modules, but there is an ONCONFIG parameter, USEOSTIME, that improves the resolution of CURRENT from seconds to the maximum resolution of the processor. It defaults to zero (off) mainly because early on Informix mostly ran on XENIX and the gettimeofday() call that enabling this parameter uses was dirt slow in XENIX. In all modern OS's that system call is fast, so there is no longer any reason to not enable it in your ONCONFIG file.

Art

IDS 12.10.FC14

SOLARIS 10  1/13

The onaudit utility creates audit trail files, as documented here: Audit-record format

The second field is the date and time of the audited event.  I have enabled auditing with onaudit, and observe the audit trail files, and see that all the timestamps recorded in the audit trail files have precision only to the level of second.  For example, the following string was copy-and-pasted from an audit trail file: "2024-08-22 12:30:54.000".

The documentation ( Creating a table for audit data ) , quoted below, shows how to create a table to store output from the audit trail files.  Note that IBM shows the creation of a table which uses a precision of 1 millisecond for the datetime element:

The sample CREATE TABLE statement in the following example creates an audit table with the name frag_logs...

CREATE TABLE frag_logs(    adttag CHAR(4) NOT NULL,    date_time DATETIME YEAR TO FRACTION(3) NOT NULL,    hostname VARCHAR(128) NOT NULL,    pid INTEGER NOT NULL,    server VARCHAR(128) NOT NULL,    username VARCHAR(32) NOT NULL,    errno INTEGER NOT NULL,    code CHAR(4) NOT NULL,    dbname VARCHAR(128),    tabid INTEGER,    objname VARCHAR(128),    extra_1 INTEGER,    partno INTEGER,    row_num INTEGER,    login VARCHAR(32),    flags INTEGER,    extra_2 VARCHAR(160));

David:

My understanding that making the change now has little effect came from one of the developers years ago. I honestly have not benchmarked it, but a) I also have not noticed any significant degradation when enabling it, and b) if you need the resolution you don't have any good alternatives.

Art

Perhaps this line from the documentation on the ONCONFIG parm USEOSTIME:

"Systems that run with USEOSTIME set to nonzero notice a performance degradation of up to 4 to 5 percent compared to running with USEOSTIME turned off."

is no longer accurate, then.  That would be a high price to pay.  But, I'll give it a shot andl change that parm in our next maintenance window for our production server.

DG

Thank you, Art and Mike, for that information.

That exactly fills the bill!

DG

Good call Art!

I just tested this and setting USEOSTIME to 1 now includes the time fraction in the audit log.

The time fraction went from .000

ONLN|2024-08-23 21:18:21.000|localhost|1217|informixtest_shm|informix|0:INRW:sysmaster:232:1026:2566::
ONLN|2024-08-23 21:18:21.000|localhost|1217|informixtest_shm|informix|0:CLDB:sysmaster

to showing the fraction:

ONLN|2024-08-23 21:19:54.243|localhost|1290|informixtest_shm|informix|0:INRW:sysmaster:232:1026:7436::
ONLN|2024-08-23 21:19:54.245|localhost|1290|informixtest_shm|informix|0:CLDB:sysmaster

David:

I'm not sure if this affects the timestamps in the audit modules, but there is an ONCONFIG parameter, USEOSTIME, that improves the resolution of CURRENT from seconds to the maximum resolution of the processor. It defaults to zero (off) mainly because early on Informix mostly ran on XENIX and the gettimeofday() call that enabling this parameter uses was dirt slow in XENIX. In all modern OS's that system call is fast, so there is no longer any reason to not enable it in your ONCONFIG file.

Art

IDS 12.10.FC14

SOLARIS 10  1/13

The onaudit utility creates audit trail files, as documented here: Audit-record format

The second field is the date and time of the audited event.  I have enabled auditing with onaudit, and observe the audit trail files, and see that all the timestamps recorded in the audit trail files have precision only to the level of second.  For example, the following string was copy-and-pasted from an audit trail file: "2024-08-22 12:30:54.000".

The documentation ( Creating a table for audit data ) , quoted below, shows how to create a table to store output from the audit trail files.  Note that IBM shows the creation of a table which uses a precision of 1 millisecond for the datetime element:

The sample CREATE TABLE statement in the following example creates an audit table with the name frag_logs...

CREATE TABLE frag_logs(    adttag CHAR(4) NOT NULL,    date_time DATETIME YEAR TO FRACTION(3) NOT NULL,    hostname VARCHAR(128) NOT NULL,    pid INTEGER NOT NULL,    server VARCHAR(128) NOT NULL,    username VARCHAR(32) NOT NULL,    errno INTEGER NOT NULL,    code CHAR(4) NOT NULL,    dbname VARCHAR(128),    tabid INTEGER,    objname VARCHAR(128),    extra_1 INTEGER,    partno INTEGER,    row_num INTEGER,    login VARCHAR(32),    flags INTEGER,    extra_2 VARCHAR(160));

Good call Art!

I just tested this and setting USEOSTIME to 1 now includes the time fraction in the audit log.

The time fraction went from .000

ONLN|2024-08-23 21:18:21.000|localhost|1217|informixtest_shm|informix|0:INRW:sysmaster:232:1026:2566::
ONLN|2024-08-23 21:18:21.000|localhost|1217|informixtest_shm|informix|0:CLDB:sysmaster

to showing the fraction:

ONLN|2024-08-23 21:19:54.243|localhost|1290|informixtest_shm|informix|0:INRW:sysmaster:232:1026:7436::
ONLN|2024-08-23 21:19:54.245|localhost|1290|informixtest_shm|informix|0:CLDB:sysmaster

David:

I'm not sure if this affects the timestamps in the audit modules, but there is an ONCONFIG parameter, USEOSTIME, that improves the resolution of CURRENT from seconds to the maximum resolution of the processor. It defaults to zero (off) mainly because early on Informix mostly ran on XENIX and the gettimeofday() call that enabling this parameter uses was dirt slow in XENIX. In all modern OS's that system call is fast, so there is no longer any reason to not enable it in your ONCONFIG file.

Art

IDS 12.10.FC14

SOLARIS 10  1/13

The onaudit utility creates audit trail files, as documented here: Audit-record format

The second field is the date and time of the audited event.  I have enabled auditing with onaudit, and observe the audit trail files, and see that all the timestamps recorded in the audit trail files have precision only to the level of second.  For example, the following string was copy-and-pasted from an audit trail file: "2024-08-22 12:30:54.000".

The documentation ( Creating a table for audit data ) , quoted below, shows how to create a table to store output from the audit trail files.  Note that IBM shows the creation of a table which uses a precision of 1 millisecond for the datetime element:

The sample CREATE TABLE statement in the following example creates an audit table with the name frag_logs...

CREATE TABLE frag_logs(    adttag CHAR(4) NOT NULL,    date_time DATETIME YEAR TO FRACTION(3) NOT NULL,    hostname VARCHAR(128) NOT NULL,    pid INTEGER NOT NULL,    server VARCHAR(128) NOT NULL,    username VARCHAR(32) NOT NULL,    errno INTEGER NOT NULL,    code CHAR(4) NOT NULL,    dbname VARCHAR(128),    tabid INTEGER,    objname VARCHAR(128),    extra_1 INTEGER,    partno INTEGER,    row_num INTEGER,    login VARCHAR(32),    flags INTEGER,    extra_2 VARCHAR(160));