Re: Ontape restore to another server

Ian Michael Gumby wrote: > > > >> Ian Michael Gumby wrote: >> <SNIP> >>> Remember its not just "integers" but all words would be flipped. >>> >> <SNIP> >> >> Careful. No ALL WORDS will be flipped. Intel, unlike some old >> little-endian chips (DEC K10/K20 chips most notably) does not flip the >> contents of words within a character array. Also, since DECIMAL and it's >> derived types in IDS (DATETIME, INTERVAL, etc.) are not native types they >> are also not byte flipped. So before you willy-nilly flip every word of >> data on the tape you have to process the table schema's for each table. >> So, >> this is NOT trivial. >> > > Art, > > There are two issues. 1) Identifying what needs to be flipped, and 2) the > actual flipping. > > The flipping part is *trivial*. > > The identification may or may not be trivial depending on the ancillary data > being provided. > (Meanind do you know the data types of columns in the table?) > > Again, you read in your input page to a buffer and then start the processing > part, with the output being the new page. > > Yes it can be done and no, while not *trivial* the whole project isn't > rocket science level either. > >> Now, could someone update archecker to be able to read cross platform tapes >>from a different -endian platform? Sure, it only has to deal with one >> table >> at a time and 95% of the work's already done. However, making ontape or >> onbar do that is a HUGELY different story. >> > > Even though its a different story, its not unrealistic that it can be done. > > You have to know the page layout. > You have to know the data types embedded in the page > You have to have some way to track off page references. > > And of course, you're going to need a lot of disk space. > > The key is in the use cases for such a tool. > Why would anyone want it? And could you justify the cost of ~360K to produce > such a beast? > > One main reason that I say build it, is that it would help in defining the > next generation of database backup tools. > > But hey! What do I know? I haven't seen any of the source code for Ontape, > nor have I tried any reverse engineering of an ontape back up. > > -G Actually, the flipping part is not so trivial - aside from shorts and ints, which are easy enough, there's the floating point representation for instance, which changes from architecture to architecture - which in turn requires knowledge of the schema of the tables, and row uncompressing to identify where the floats are, and then row compressing - a triple whammy which would make the conversion orders of magnitude slower (for other types this is not necessary, but I won't go into the technical details). And then there's port page size, and platform specific stuff like differing path formats between NT and *xes. And this doesn't even begin to take into account disk differences in between versions (surely you would want to do to be able to do something like restore with a 10 an archive produced by a 9) Doable, but not easy, and not entirely sure it's worth the risk. Look at archiving and migration as specialized race cars. Sure, you can have a rally car go almost everywhere and run decently on track, but it will be no match to an F1 in its own environment. -- Ciao, Marco ______________________________________________________________________________ Marco Greco /UK /IBM Standard disclaimers apply! Structured Query Scripting Language http://www.4glworks.com/sqsl.htm 4glworks http://www.4glworks.com Informix on Linux http://www.4glworks.com/ifmxlinux.htm