Update from TS. It's not truncating the last digit; it's truncating digit n-2:
I entered defect idsdb00106200: Last digit often truncated with MSG_DATE=2 or 3
We're printing using "%s.%-.0f " for MSG_DATE=3 and "%d%-.0f %s " for MSG_DATE=2, in both cases the millisecond format specifier should use "%.03f" to get a 3 digit, zero padded value.
Will provide APAR as it becomes available
------------------------------
TOM GIRSCH
------------------------------
Original Message:
Sent: Fri July 10, 2020 11:48 AM
From: TOM GIRSCH
Subject: MSG_DATE in 14.10.FC4W1
Before @Art Kagel asks:
TS003925148
:)
------------------------------
TOM GIRSCH
Original Message:
Sent: Fri July 10, 2020 10:58 AM
From: TOM GIRSCH
Subject: MSG_DATE in 14.10.FC4W1
Hmm; it doesn't seem to be trailing zeroes doing it. Definitely something weird going on:
2020-07-10 14:54:48.306 Value of MSG_DATE has been changed to 3.2020-07-10 14:56:00.82 Checkpoint Completed: duration was 0 seconds.2020-07-10 14:56:00.83 Fri Jul 10 - loguniq 16744, logpos 0x3c81018, timestamp: 0xd709f971 Interval: 3801012020-07-10 14:56:00.83 Maximum server connections 9 2020-07-10 14:56:00.83 Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 0, Plog used 1385, Llog used 02020-07-10 14:57:40.320 DR: This command is not valid on a secondary server.
------------------------------
TOM GIRSCH
Original Message:
Sent: Fri July 10, 2020 10:56 AM
From: TOM GIRSCH
Subject: MSG_DATE in 14.10.FC4W1
I see the same bug* with MSG_DATE=3. If the fraction(3) ends in 0, the trailing zero is trimmed.
* - Could be expected behavior. According to HCL, anything that isn't a crash is expected behavior.
------------------------------
TOM GIRSCH
Original Message:
Sent: Thu July 09, 2020 01:50 PM
From: Art Kagel
Subject: MSG_DATE in 14.10.FC4W1
OK, just checked setting MSG_DATE=2 that displays the number of 1/1000th seconds (ie the UNIX epoch * 1000 plus number of fractional 1/1000 seconds), followed by the default timestamp display. Witness:
1594316557969 07/09/2020 13:42:37 Value of MSG_DATE has been changed to 2.
159431689624 07/09/2020 13:48:16 MSG_DATE is already set to 2.
So, 1594316557 was the epoch in the first line, so the time in fractional seconds would have been 1594316557.969. There does seem to be a bug, however, as the trailing zero in the second line was not printed. That time in fractional seconds should have been: 1594316896.240
Art
Art S. Kagel, President and Principal Consultant
ASK Database Management
Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves.
Original Message:
Sent: 7/9/2020 12:49:00 PM
From: Snorri Bergmann
Subject: MSG_DATE in 14.10.FC4W1
Hello everyone.
Just installed 14.10.FC4W1 for testing and one of the new features is listed as:
MSG_Date Parameter enhancement
- MSG_DATE configuration parameter is enhanced to support insertion of a date in different formats at the beginning of each message printed to the online log.
However, the doc is silent about this new feature:
Use the MSG_DATE configuration parameter to enable the insertion of a date in MM/DD/YY format at the beginning of each message printed to the online log.
- onconfig.std value
- Not in the onconfig.std file.
- values
- 0 = OFF (the default)
1 = ON
Does anyone know what the new syntax is?
Best regards,
-Snorri
------------------------------
Snorri Bergmann
------------------------------
#Informix