Data recovery from Informix 3.30 RDB
Trying to do a favour for a small business who had a XENIX machine (circa 80's) that has crashed beyond repair which was running an Informix 3.3 RDB ... luckily they have all the nightly backup files which offload via samba onto DVD's ... in particular all the .dbd and .dat files are intact ... as the data .dat files are in flat fixed format and the .dbd (data dictionary) files are readable the assumption is this data should be easily recoverable. I have dechiphered some of the details out of the .dbd files but still struggling with the Field data types and data lengths. Could someone possibly lead me to a dbd file structure for this version of Informix to complete this task. If I can pick the Field Data Type and lengths out of the dbd files then I should have no problem converting the .dat files into a comma delimited format so we can recover this 20+ years of customer data. The dat files were designed as flat fixed data structures with no delimiters so without the absolute lengths of each field its not easy to predict the lengths with out the schema details. What I have so far is 0000: 58FE - appears to be a unique dbd file marker 0002: mmnn- is the absolute offset to the end of the ASCII TABLE/FIELD stringZ 0004: <Table String> 0 qqrr: <Field String> 0 nnmm: bbcc is the number of tables in this definition file nnmm + 2: 0000 ???? ???? FFFF 0000 the first 16 bit number is the offset into the ASCII TABLE/FIELD ... referencing the TABLE name the first entry in this is offset by 4 so address 0004 is actually 0000 ... there will be one block for each of the tables defined the remainder of the file is a jumble of numbers that I haven't been able to associate
On Sep 21, 12:46 pm, bxd...@shaw.ca wrote: > Trying to do a favour for a small business who had a XENIX machine > (circa 80's) that has crashed beyond repair which was running an > Informix 3.3 RDB ... luckily they have all the nightly backup files > which offload via samba onto DVD's ... in particular all the .dbd > and .dat files are intact ... as the data .dat files are in flat fixed > format and the .dbd (data dictionary) files are readable the > assumption is this data should be easily recoverable. > > I have dechiphered some of the details out of the .dbd files but still > struggling with the Field data types and data lengths. > > Could someone possibly lead me to a dbd file structure for this > version of Informix to complete this task. If I can pick the Field > Data Type and lengths out of the dbd files then I should have no > problem converting the .dat files into a comma delimited format so we > can recover this 20+ years of customer data. > > The dat files were designed as flat fixed data structures with no > delimiters so without the absolute lengths of each field its not easy > to predict the lengths with out the schema details. > > What I have so far is > > 0000: 58FE - appears to be a unique dbd file marker > 0002: mmnn- is the absolute offset to the end of the ASCII TABLE/FIELD > stringZ > 0004: <Table String> 0 > qqrr: <Field String> 0 > nnmm: bbcc is the number of tables in this definition file > nnmm + 2: 0000 ???? ???? FFFF 0000 the first 16 bit number is the > offset into the ASCII TABLE/FIELD ... referencing the TABLE name the > first entry in this is offset by 4 so address 0004 is actually > 0000 ... there will be one block for each of the tables defined > > the remainder of the file is a jumble of numbers that I haven't been > able to associate The field type and length fields probably follow the same convention as modern SE and IDS. Types will be in the sqltypes.h header in the Informix SDK. The length field mod 0xFF00 is the actual length and the high bit indicates whether the column supports NULLs or not. More exotic schemes for new types like DATETIMEs and DECIMALs were probably not supported in RDS 3.30, well perhaps DECIMALs - hopefully they didn't use them if they were supported. Decoding decimals is tricky, understanding the type field is described in the SDK headers and ESQL/ C manuals (decoding is described there also but it's incomplete). If you have to decode DECIMALS contact me, I have a function. Everything else should be native machine types. Art S. Kagel
bxdobs@shaw.ca wrote: > Trying to do a favour for a small business who had a XENIX machine > (circa 80's) that has crashed beyond repair which was running an > Informix 3.3 RDB ... luckily they have all the nightly backup files > which offload via samba onto DVD's ... in particular all the .dbd > and .dat files are intact ... as the data .dat files are in flat fixed > format and the .dbd (data dictionary) files are readable the > assumption is this data should be easily recoverable. > > I have dechiphered some of the details out of the .dbd files but still > struggling with the Field data types and data lengths. > > Could someone possibly lead me to a dbd file structure for this > version of Informix to complete this task. If I can pick the Field > Data Type and lengths out of the dbd files then I should have no > problem converting the .dat files into a comma delimited format so we > can recover this 20+ years of customer data. > > The dat files were designed as flat fixed data structures with no > delimiters so without the absolute lengths of each field its not easy > to predict the lengths with out the schema details. > > What I have so far is > > 0000: 58FE - appears to be a unique dbd file marker > 0002: mmnn- is the absolute offset to the end of the ASCII TABLE/FIELD > stringZ > 0004: <Table String> 0 > qqrr: <Field String> 0 > nnmm: bbcc is the number of tables in this definition file > nnmm + 2: 0000 ???? ???? FFFF 0000 the first 16 bit number is the > offset into the ASCII TABLE/FIELD ... referencing the TABLE name the > first entry in this is offset by 4 so address 0004 is actually > 0000 ... there will be one block for each of the tables defined > > the remainder of the file is a jumble of numbers that I haven't been > able to associate You need my Informix 3.30 to SQL migration toolkit. I'll have to brush the cobwebs off it. It looks like the last time I did anything much with it was in October 1998 (and it wasn't a lot I did even then). The code did compile without squawk from GCC 4.0.1 on MacOS X (10.4.10) when I tried it just now. I have a tool ix33sch which derives a schema (Informix 3.30) from a dbd file, and a tool ixsql which converts an Informix 3.30 schema into SQL, and yet another tool dbdperms that deals with permissions. There's a whole ragbag of other bits. One little thing I saw in the code for prdbd is the constant 0xFE58, the byte-swapped version of the number you quote. There might be some issues with byte order that would need to be resolved in Some parts of the toolkit assume you have DBSTATUS available for unloading the data; however, there is yet another tool, isextract, that can unload the data from C-ISAM files given the data description, which you would have by the time we're done. That requires ESQL/C. Informix 3.30 did include DECIMAL (and float and double) and integers (2-byte and 4-byte) and various date formats - internally, all integers encoded as in SQL (number of days since 1989-12-31) but presented in different formats. Plus fixed-length CHAR fields. No DATETIME or INTERVAL types; no variable length types. The toolkit is not well polished. The first (and last) time I used it in earnest was in 1992 or 1993. Then I had a working Informix 3.30 to play with. If the worst comes to the worst, I'll put 3.30 onto an Intel machine - more for the amusement than anything else (it's only for my amusement that it runs on MacOS X). But the data you have is salvagable if you have the complete backup. Contact me offline... -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2007.0914 -- http://dbi.perl.org/ publictimestamp.org/ptb/PTB-1357 sha256 2007-09-22 03:00:04 78D010D59D9EE3519C4259C632ED6B73EC392400B1D53648C35FFDFC638984F7