Hi Family.

While playing around with the catalogs I ran the following query on syslogs:

select number, uniqid, size, used, is_used, is_current, is_backed_up, is_new,
       is_archived, is_temp, is_pre_dropped, flags, hex(flags) h_flags
from syslogs
  order by uniqid

Here are the last two rows; one already backed up on one is the current log:

number          2
uniqid          10
size            12500
used            12500
is_used         1
is_current      0
is_backed_up    1
is_new          0
is_archived     0
is_temp         0
is_pre_dropped  0
flags           5
h_flags         0x00000005

number          3
uniqid          11
size            12500
used            98
is_used         1
is_current      1
is_backed_up    0
is_new          0
is_archived     0
is_temp         0
is_pre_dropped  0
flags           16387
h_flags         0x00004003
^

I added that caret under the 4 in the last row.

I understand the 5 on the flags of the previous rows: binary 101 in the flags.  And the last log - the current log - is_used, is_current, not is_backed_up.  So those make sense, But where did the 4 (as in 0x4003) come from?  Well, as it happens, it is in the undocumented table syslogfil, upon which syslogs is the documented view.  Running a similar query on syslogfil:

select hex(address) address,
       number, uniqid, flags, hex(flags) h_flags, fillstamp, filltime, chunk,
       offset, size, used
  from syslogfil
 order by uniqid

Here are the last 2 rows of that:

address    0x00000000461546c8
number     2
uniqid     10
flags      5
h_flags    0x00000005
fillstamp  2264515
filltime   1697574653
chunk      1
offset     117513
size       12500
used       12500

address    0x0000000046154730
number     3
uniqid     11
flags      16387
h_flags    0x00004003
fillstamp  0 ^
filltime   0
chunk      1
offset     130013
size       12500
used       98

Again, me inserting the caret under the 4.

This has not affected anything, of course, but it might cause a bit of grief when I write a Perl script to analyze the syslogs rows.

Any clues as to that mysterious flag that seems utterly undocumented?

Thanks for ideas.  If the guys in sunglasses and black limos come for me I'll know I've hit on an evil conspiracy.  <Grin>

Hello Jacob,

syslogs is a view on syslogfil. The flags are also documented there. 

0x4000 = Log file contains the last checkpoint written

https://www.ibm.com/docs/en/informix-servers/14.10?topic=tables-syslogfil-table

Regards

Andreas

Hi Family.

While playing around with the catalogs I ran the following query on syslogs:

select number, uniqid, size, used, is_used, is_current, is_backed_up, is_new,
       is_archived, is_temp, is_pre_dropped, flags, hex(flags) h_flags
from syslogs
  order by uniqid

Here are the last two rows; one already backed up on one is the current log:

number          2
uniqid          10
size            12500
used            12500
is_used         1
is_current      0
is_backed_up    1
is_new          0
is_archived     0
is_temp         0
is_pre_dropped  0
flags           5
h_flags         0x00000005

number          3
uniqid          11
size            12500
used            98
is_used         1
is_current      1
is_backed_up    0
is_new          0
is_archived     0
is_temp         0
is_pre_dropped  0
flags           16387
h_flags         0x00004003
^

I added that caret under the 4 in the last row.

I understand the 5 on the flags of the previous rows: binary 101 in the flags.  And the last log - the current log - is_used, is_current, not is_backed_up.  So those make sense, But where did the 4 (as in 0x4003) come from?  Well, as it happens, it is in the undocumented table syslogfil, upon which syslogs is the documented view.  Running a similar query on syslogfil:

select hex(address) address,
       number, uniqid, flags, hex(flags) h_flags, fillstamp, filltime, chunk,
       offset, size, used
  from syslogfil
 order by uniqid

Here are the last 2 rows of that:

address    0x00000000461546c8
number     2
uniqid     10
flags      5
h_flags    0x00000005
fillstamp  2264515
filltime   1697574653
chunk      1
offset     117513
size       12500
used       12500

address    0x0000000046154730
number     3
uniqid     11
flags      16387
h_flags    0x00004003
fillstamp  0 ^
filltime   0
chunk      1
offset     130013
size       12500
used       98

Again, me inserting the caret under the 4.

This has not affected anything, of course, but it might cause a bit of grief when I write a Perl script to analyze the syslogs rows.

Any clues as to that mysterious flag that seems utterly undocumented?

Thanks for ideas.  If the guys in sunglasses and black limos come for me I'll know I've hit on an evil conspiracy.  <Grin>

Hello Jacob,

syslogs is a view on syslogfil. The flags are also documented there. 

0x4000 = Log file contains the last checkpoint written

https://www.ibm.com/docs/en/informix-servers/14.10?topic=tables-syslogfil-table

Regards

Andreas

Hi Family.

While playing around with the catalogs I ran the following query on syslogs:

select number, uniqid, size, used, is_used, is_current, is_backed_up, is_new,
       is_archived, is_temp, is_pre_dropped, flags, hex(flags) h_flags
from syslogs
  order by uniqid

Here are the last two rows; one already backed up on one is the current log:

number          2
uniqid          10
size            12500
used            12500
is_used         1
is_current      0
is_backed_up    1
is_new          0
is_archived     0
is_temp         0
is_pre_dropped  0
flags           5
h_flags         0x00000005

number          3
uniqid          11
size            12500
used            98
is_used         1
is_current      1
is_backed_up    0
is_new          0
is_archived     0
is_temp         0
is_pre_dropped  0
flags           16387
h_flags         0x00004003
^

I added that caret under the 4 in the last row.

I understand the 5 on the flags of the previous rows: binary 101 in the flags.  And the last log - the current log - is_used, is_current, not is_backed_up.  So those make sense, But where did the 4 (as in 0x4003) come from?  Well, as it happens, it is in the undocumented table syslogfil, upon which syslogs is the documented view.  Running a similar query on syslogfil:

select hex(address) address,
       number, uniqid, flags, hex(flags) h_flags, fillstamp, filltime, chunk,
       offset, size, used
  from syslogfil
 order by uniqid

Here are the last 2 rows of that:

address    0x00000000461546c8
number     2
uniqid     10
flags      5
h_flags    0x00000005
fillstamp  2264515
filltime   1697574653
chunk      1
offset     117513
size       12500
used       12500

address    0x0000000046154730
number     3
uniqid     11
flags      16387
h_flags    0x00004003
fillstamp  0 ^
filltime   0
chunk      1
offset     130013
size       12500
used       98

Again, me inserting the caret under the 4.

This has not affected anything, of course, but it might cause a bit of grief when I write a Perl script to analyze the syslogs rows.

Any clues as to that mysterious flag that seems utterly undocumented?

Thanks for ideas.  If the guys in sunglasses and black limos come for me I'll know I've hit on an evil conspiracy.  <Grin>

Hi Jacob,

I believe that if you use the "Insert/edit code sample" option (looks like "{;}" on the ribbon menu) of the editor, your issue of the extra spaces is addressed.  Here is your output with the caret correctly located:

address    0x0000000046154730number     3uniqid     11flags      16387h_flags    0x00004003fillstamp  0     ^filltime   0chunk      1offset     130013size       12500used       98

Hello Jacob,

syslogs is a view on syslogfil. The flags are also documented there. 

0x4000 = Log file contains the last checkpoint written

https://www.ibm.com/docs/en/informix-servers/14.10?topic=tables-syslogfil-table

Regards

Andreas

Hi Family.

While playing around with the catalogs I ran the following query on syslogs:

select number, uniqid, size, used, is_used, is_current, is_backed_up, is_new,
       is_archived, is_temp, is_pre_dropped, flags, hex(flags) h_flags
from syslogs
  order by uniqid

Here are the last two rows; one already backed up on one is the current log:

number          2
uniqid          10
size            12500
used            12500
is_used         1
is_current      0
is_backed_up    1
is_new          0
is_archived     0
is_temp         0
is_pre_dropped  0
flags           5
h_flags         0x00000005

number          3
uniqid          11
size            12500
used            98
is_used         1
is_current      1
is_backed_up    0
is_new          0
is_archived     0
is_temp         0
is_pre_dropped  0
flags           16387
h_flags         0x00004003
^

I added that caret under the 4 in the last row.

I understand the 5 on the flags of the previous rows: binary 101 in the flags.  And the last log - the current log - is_used, is_current, not is_backed_up.  So those make sense, But where did the 4 (as in 0x4003) come from?  Well, as it happens, it is in the undocumented table syslogfil, upon which syslogs is the documented view.  Running a similar query on syslogfil:

select hex(address) address,
       number, uniqid, flags, hex(flags) h_flags, fillstamp, filltime, chunk,
       offset, size, used
  from syslogfil
 order by uniqid

Here are the last 2 rows of that:

address    0x00000000461546c8
number     2
uniqid     10
flags      5
h_flags    0x00000005
fillstamp  2264515
filltime   1697574653
chunk      1
offset     117513
size       12500
used       12500

address    0x0000000046154730
number     3
uniqid     11
flags      16387
h_flags    0x00004003
fillstamp  0 ^
filltime   0
chunk      1
offset     130013
size       12500
used       98

Again, me inserting the caret under the 4.

This has not affected anything, of course, but it might cause a bit of grief when I write a Perl script to analyze the syslogs rows.

Any clues as to that mysterious flag that seems utterly undocumented?

Thanks for ideas.  If the guys in sunglasses and black limos come for me I'll know I've hit on an evil conspiracy.  <Grin>

Hi Mark.

I had done exactly as you suggested. The line with the caret was within the {;} and displayed in red.

And, btw, your sample code in your example looks like this, all on one line:

address 0x0000000046154730 number 3 uniqid 11 flags 16387 h_flags 0x00004003 fillstamp 0 ^ filltime 0 chunk 1 offset 130013 size 12500 used 98

Note that what I presume was meant to be 2 lines with the caret carefully placed, wound up on one line.

So our text entry facility is rather imperfect.

------------------------------
Jacob Salomon
---
Nobody goes there anymore, it's too crowded.  --Attr: Yogi Berra

Original Message:
Sent: Thu October 19, 2023 10:37 AM
From: mark collins
Subject: Mystery flag in syslogs/syslogfil

Hi Jacob,

I believe that if you use the "Insert/edit code sample" option (looks like "{;}" on the ribbon menu) of the editor, your issue of the extra spaces is addressed.  Here is your output with the caret correctly located:

address    0x0000000046154730number     3uniqid     11flags      16387h_flags    0x00004003fillstamp  0     ^filltime   0chunk      1offset     130013size       12500used       98

------------------------------
mark collins

Original Message:
Sent: Wed October 18, 2023 10:33 AM
From: Jacob Salomon
Subject: Mystery flag in syslogs/syslogfil

Original Message:
Sent: 10/18/2023 3:56:00 AM
From: Andreas Seifert
Subject: RE: Mystery flag in syslogs/syslogfil

Hello Jacob,

syslogs is a view on syslogfil. The flags are also documented there. 

0x4000 = Log file contains the last checkpoint written

https://www.ibm.com/docs/en/informix-servers/14.10?topic=tables-syslogfil-table

Regards

Andreas

------------------------------
Andreas Seifert
CURSOR Software AG
http://www.admin-scout.com

Original Message:
Sent: Tue October 17, 2023 06:15 PM
From: Jacob Salomon
Subject: Mystery flag in syslogs/syslogfil

Hi Family.

While playing around with the catalogs I ran the following query on syslogs:

select number, uniqid, size, used, is_used, is_current, is_backed_up, is_new,
       is_archived, is_temp, is_pre_dropped, flags, hex(flags) h_flags
from syslogs
  order by uniqid

Here are the last two rows; one already backed up on one is the current log:

number          2
uniqid          10
size            12500
used            12500
is_used         1
is_current      0
is_backed_up    1
is_new          0
is_archived     0
is_temp         0
is_pre_dropped  0
flags           5
h_flags         0x00000005

number          3
uniqid          11
size            12500
used            98
is_used         1
is_current      1
is_backed_up    0
is_new          0
is_archived     0
is_temp         0
is_pre_dropped  0
flags           16387
h_flags         0x00004003
^

I added that caret under the 4 in the last row.

I understand the 5 on the flags of the previous rows: binary 101 in the flags.  And the last log - the current log - is_used, is_current, not is_backed_up.  So those make sense, But where did the 4 (as in 0x4003) come from?  Well, as it happens, it is in the undocumented table syslogfil, upon which syslogs is the documented view.  Running a similar query on syslogfil:

select hex(address) address,
       number, uniqid, flags, hex(flags) h_flags, fillstamp, filltime, chunk,
       offset, size, used
  from syslogfil
 order by uniqid

Here are the last 2 rows of that:

address    0x00000000461546c8
number     2
uniqid     10
flags      5
h_flags    0x00000005
fillstamp  2264515
filltime   1697574653
chunk      1
offset     117513
size       12500
used       12500

address    0x0000000046154730
number     3
uniqid     11
flags      16387
h_flags    0x00004003
fillstamp  0 ^
filltime   0
chunk      1
offset     130013
size       12500
used       98

Again, me inserting the caret under the 4.

This has not affected anything, of course, but it might cause a bit of grief when I write a Perl script to analyze the syslogs rows.

Any clues as to that mysterious flag that seems utterly undocumented?

Thanks for ideas.  If the guys in sunglasses and black limos come for me I'll know I've hit on an evil conspiracy.  <Grin>

------------------------------
Jacob Salomon
---
Nobody goes there anymore, it's too crowded.  --Attr: Yogi Berra
------------------------------