Re: Differences in RSAM page structure 32 and 64 b
Aha! I have NOT given up! I managed to recompile my pgdump on my Linux box (A lot goes haywire in 2 decades) and here is a a little bit of the dump of a page in a DBspace with 16-k pages. It happens to be chunk number 6. pgdump -d /ifmxdev/js_server.data_dbs.P.001 -p 54 -fx -n 1 -s 16 The chunk file is /ifmxdev/js_server.data_dbs.P.001 and I want to dump 1 page starting at page 54 of the chunk. Here is the first few lines of the output: Device: </ifmxdev/js_server.data_dbs.P.001>; Page <0054/0x0036>; OnLine Page ID: <432/0> ----------------------------------------------------------------- 0000/0000||B0010000 060034E6 7A38B080 3A19F425 |~~~~~~4~z8~~:~~%| 0016/0010||00000000 00000000 09737973 7461626C |~~~~~~~~~systabl| 0032/0020||6573696E 666F726D 69782020 20202020 |esinformix | 0048/0030||20202020 20202020 20202020 20202020 | | 0064/0040||20200000 0301000A 73797363 6F6C756D | ~~~~~~syscolum| 0080/0050||6E73696E 666F726D 69782020 20202020 |nsinformix | 0096/0060||20202020 20202020 20202020 20202020 | | 0112/0070||20200000 0302000A 73797369 6E646963 | ~~~~~~sysindic| This happens to be the first page in systables for my stores_demo database. OK, that first word: B0010000 This is actually 0x'000001b0' or just 1b0. Back into decimal this is 432 but divide by 8 (the multiple over the default page size) and you get back the 54 you specified. In the next word, the chunk number is 0006 - that is Chunk 6, exactly as I specified. What that E634 is? Maybe is only 34 or decimal 52 but I believe I counted 62 slots in the slot table so that makes no sense. Furthermore I can see that the slot table starts at offset 3E14 and the last row in the page ends about offset 193A. And that I find in the last word of the top line: 3A19F425 There is the 193A in the first 2 bytes of the word. (Intel is little-endian.) I would presume than that the 25F4 is the free count, or 9716. But that does not work out; the full page dump told be there were 589 * 16 bytes of all 0, which comes out to 9524 Since the last 2 words of the page header are pointers to other pages (in the tblspace), in this case no further pages, now I'd like to gain that understanding of what all those other hex number all mean. Someplace is the number of slots in the slot table so I should see 3E someplace. And the page type is buried in there someplace, in a location other than where it was in the 32-bit version. So who will take me up on this journey of discovery?
Hi. Jake the obsessed still here and still at it. It takes a long time between my posts because I don't always have the opportunity to boot my home PC to Lunix. But here is the next installment of my investigations. First, I must confess that I have an error in my previous post: I had directly counted the slots but counted 2 slots as one. There were actually 122 slots, not 62. And that 7A in first full word of line 1 is exactly 122 back in decimal. My next point of attack was to determine where in the header it tells us what size page this is. Toward this end I created DBspaces of 2,3,6,8,10,12,14,and 16K pages. Notice after the 7A you see the number 38. For each page size I found a different number, according to the following table. Unfortunately, since I can't post fix-width fonts I have to beg your indulgence: // Page size codes // Code k/pg Binary // 00 = 2k 0000 0000 // 08 = 4k 0000 1000 // 10 = 6k 0001 0000 // 18 = 8K 0001 1000 // 20 = 10k 0010 0000 // 28 = 12K 0010 1000 // 30 = 14k 0011 0000 // 38 = 16K 0011 1000 At first I could not get the pattern, then I looked at the bit-field values. Taking the bit-field binary[2-4] I see the binary codes that flag the page size: 0: 2K 1: 4K 2: 6K 3: 8K 4: 10K 5: 12K 6: 14K 7: 16K If the other bits have any potential meanings, I'd love to hear about it. But for that one byte I can set up a structure: typedef struct { unsigned int idk_1 : 2; /* First <I Don't Know>: 2 bits */ unsigned int pg_sz_flag : 3; /* Page Size flag: 3 bits */ unsigned int ifk_2 : 3; /* Second <I Don't Know>: 3 bits */ } page_size_flag_t; So far I have managed to reverse engineer this much of the RSAM-64 page header: typedef struct page_header { long page_id; /* 4-byte signed page number within the chunk */ short chunk_num; /* 2 byte signed chunk num within the server */ short idontknow_1; /* 2 bytes. Checksum?? */ unsigned char nslots; /* 1 byte: Slot count in this page */ page_size_flag_t pgsize_flags; /* 1 byte: As per above typedef */ unsigned short pg_type; /* 2 bytes: Flags representing page type */ short free_ptr; /* 2 bytes: Offset to 1st free byte in page */ short free_cnt; /* 2 bytes: # bytes in page not in a row */ long next; /* 4 bytes: For index pages - -> next page */ long prev; /* 4 Bytes: For index pages - -> prev page */ } page_header_t; Now *that* adds up to 24 bytes! I have not been able to quite resolve the free_cnt field. For example, here is the "states" lookup table in an 8K page: 0000/0000||640F0000 1000D3EF 34180100 8C03A01B |d~~~~~~~4~~~~~~~| 0016/0010||00000000 00000000 414B416C 61736B61 |~~~~~~~~AKAlaska| 0032/0020||20202020 20202020 20484948 61776169 | HIHawai| 0048/0030||69202020 20202020 20204341 43616C69 |i CACali| Yes, this is page 0F64 (3940) in chunk[16]. That's as measured in 2K pages; it is actually 985 as measured by 8K pages. There are 34(hex) entries, for 52 states (+ DC and Puerto Rico. Hey, where's Guam? ;-) Where there are no entries the data is all zeros. And I can count 7056 null bytes. How did I count that? 0896/0380||72746F20 5269636F 20202020 00000000 |rto Rico ~~~~| 0912/0390||00000000 00000000 00000000 00000000 |~~~~~~~~~~~~~~~~| ------------------- Skipped <440> null lines ------------------- 7968/1F20||00000000 00000000 00000000 7B031100 |~~~~~~~~~~~~{~~~| The free pointer in the header is 038C (= 908(10), which matches exactly the offset of the first 00000000 you see above. The 00 bytes cover 441 completely null lines, plus 16 more null bytes. Total: Yet, the free count reads 1BA0, which is 7072. This discrepancy is a mild one compared to some others I have run into. WOW!! Did I write all that? Who in blazes is gonna read all that? All that said, however, I think I have enough information to start that update to pgdump. Thanks to a few folks who replied privately, so I presume they to not wish to be publicly named. One man's obsession is another man's idiocy! -- Jacob S.