A common confusion with these environment variables. I think you want to use TM_GW_AUDITLOG_ACCURATE =YES.
Here are the three that are commonly confused with each other.
requests the enhanced formatting of the audit log "SequentID:ProcessID:LocalDomain:RemoteDomain:SVCName:TranID:NetTranId:RequestType:filed7:Timestamps"
changes the auditing from 1 second to 1 millisecond timestamps level of data logging
when set=1 AND the dmadmin "audit on" command is executed then prepare,commit and rollback actions will also be logged to the AUDITLOG.
Any one of these when used will increase the size of the file generated and so will effect overall performance.
I have tried setting all three of these variables in my shell and rhen turning aufit logging back on, and it made no difference to the format, Is there something I am missing
Tuxedo processes do not pick up environment variable changes immediately. They need to be rebooted.
Are these steps similar to what you followed?
1)tmshutdown the domain group of interest (shutting down just the GWTDOMAIN might work but I would do it for the whole group, GWTDOMAIN+GWADM)
2)set the environment variable TM_GW_AUDITLOG_ACCURATE=YES (try checking it after with an "env|grep AUDIT" to see if it set)
3)tmboot the domain group
There are sometimes issues if you are trying to set environment variables from a shell script(e.g. syntax issues) or ENVFILE.
Are you setting the environment variable manually from the shell command prompt, by using a shell script before tmboot, or using ENVFILEs that are defined in the UBB config file?
If you still don't get millisecond logging let me know the platform and shell you are using (also the Tuxedo release version and patch level if different than previously mentioned).
Thanks. I have now got more detailed logging but the subsecond format is very hard to interpret (as below):
000010000000009:22159:FXOPS_UAT3SG:FXOPSJMS_UAT3SG:QSPCMessagesM:::IN FROM TUXEDO :1377721096.7481 :Wed Aug 28 16:18:16 2013 000010000000009:22159:FXOPS_UAT3SG:FXOPSJMS_UAT3SG:QSPCMessagesM:::OUT TO NETWORK :1377721096.7981 :Wed Aug 28 16:18:16 2013 000010000000010:22159:FXOPS_UAT3SG:FXOPSJMS_UAT3SG:QSPCMessagesM:::IN FROM NETWORK:1377721096.27086 :Wed Aug 28 16:18:16 2013 000010000000010:22159:FXOPS_UAT3SG:FXOPSJMS_UAT3SG:QSPCMessagesM:::OUT TO TUXEDO :1377721096.27482 :Wed Aug 28 16:18:16 2013
We are using Tux 184.108.40.206.0
The additional timestamp format is "seconds.microseconds".
The "seconds" is the number of seconds since the great epoch of 1970 (or some platform specific hubris fixed time point). The timestamp format was chosen so that it would be an easier calculation of the delta for users
from one logged datum to the next. (i.e. rather than a conversion from a string, like "Wed Aug 28 16:18:16 2013", and then a calculation).
so leading zeros are dropped and the timetamps from earlier mail would be?
Yes. That is my thinking also.
I think that "seconds" and "micrsoseconds" may each have independent fixed starting time points which are platform dependent.
(it varies on an OS providing/use of time functions). So rollover from microseconds to seconds may not occur always as
expected but the deltas from/to the previous/next datum should be correct.