Re: Differences in RSAM page structure 32 and 64 b

After Marco posted his response last July, I allowed the issue to drop. However, some recent events at my client revived my interest in this issue. In the process, I got my hot little hands on an old (2007) Art Kagel presentation on Informix internal architecture. On page 30, he gives the following structure for the page header as of release 10: struct page_header { int PageNumber; short ChunkNum; short chksum; short pagesize; short NumSlots; short Flags; short FreeOffset; short FreeBytes; int NextPage; int PrevPage; }; There is one little problem with this: The structure is now 26 bytes long, that is: (7 * 2-bytes) + (3 * 4bytes). This is incompatible with Marco's assertion that the header is still 24 bytes. This leads me to suspect a slight overreach in the above structure; that a couple of the above "short" structure members are actually [unsigned] char. I seek feedback on what is actually correct. But here's my reasoning: Since the slot number has always been limited to 8 bits (unsigned) with a max value of 255, we don't need a 16-bit short to tell us the number of slots; an "unsigned character" (AKA uchar) would be sufficient. And since the variety of page sizes is severely limited, it should be sufficient to have a small (in the human sense) integer to tell us the page is 2, or 4,8,10,12,14, or 16k. Or, perhaps, a number that multiplies the default page size. For example, in a 2k server, the number 5 in this spot would tell us the page is 10k. If my reasoning is correct (agreeably, an arguable proposition :-) that would bring the page-header structure back to the original 24 bytes, as Marco explained all those months ago. Anyone out there who can confirm or correct my reasoning and get me to the correct layout? BTW I am blindly assuming (praying?) that the structure remains unchanged through release 12.x. If not, we must prevail upon Art (promise to pay him in chocolate? :-) to update that presentation! Thanks much for guidance! -- Jacob S.

The page header went through quite a few changes when we introduced multiple page sizes, but is still contained in 24 bytes. From: "JACOB SALOMON" <jakesalomon@yahoo.com> To: ids@iiug.org Date: 01/16/2015 09:39 AM Subject: Re: Differences in RSAM page structure 32 and 64 b [34479] Sent by: ids-bounces@iiug.org After Marco posted his response last July, I allowed the issue to drop.= 24 bytes. However, some recent events at my client revived my interest in this is= sue. In the process, I got my hot little hands on an old (2007) Art Kagel presentation on Informix internal architecture. On page 30, he gives the following structure for the page header as of release 10: struct page_header { int PageNumber; short ChunkNum; short chksum; short pagesize; short NumSlots; short Flags; short FreeOffset; short FreeBytes; int NextPage; int PrevPage; }; There is one little problem with this: The structure is now 26 bytes lo= ng, that is: (7 * 2-bytes) + (3 * 4bytes). This is incompatible with Marco'= s assertion that the header is still 24 bytes. This leads me to suspect a slight overreach in the above structure; tha= t a couple of the above "short" structure members are actually [unsigned] c= har. I seek feedback on what is actually correct. But here's my reasoning: Since the slot number has always been limited to 8 bits (unsigned) with= a max value of 255, we don't need a 16-bit short to tell us the number of slo= ts; an "unsigned character" (AKA uchar) would be sufficient. And since the variety of page sizes is severely limited, it should be sufficient to have a small (in the human sense) integer to tell us the = page is 2, or 4,8,10,12,14, or 16k. Or, perhaps, a number that multiplies the default page size. For example, in a 2k server, the number 5 in this spot would= tell us the page is 10k. If my reasoning is correct (agreeably, an arguable proposition :-) that= would bring the page-header structure back to the original 24 bytes, as Marco= explained all those months ago. Anyone out there who can confirm or correct my reasoning and get me to = the correct layout? BTW I am blindly assuming (praying?) that the structure remains unchang= ed through release 12.x. If not, we must prevail upon Art (promise to pay = him in chocolate? :-) to update that presentation! Thanks much for guidance! -- Jacob S. ***********************************************************************= ******** Forum Note: Use "Reply" to post a response in the discussion forum. =