Rob van der Heij wrote: > John Campbell blathered: >> Unless the DataBase engine makes an effort to handle all >> non-internal-code numbers in an interchangable format-- and with >> appropriately fixed sizes-- the binary form of the data file-- or >> container files, for a database-- will be incompatible if copied, bit >> for bit, from one machine architecture to another... but there is a >> performance impact to ensuring that all binary coded numeric fields >> have, across all architectures, a consistent and "machine independant" >> format. > > Having the database swap the bytes on the fly for everything would be > pretty expensive, and probably best done on database load only. And I would > assume similar issues for floating point numbers that are kept in machine > format (like when you go from DB2 on z/OS to DB2 on zLinux).
Well, for Business BASIC, even with the various file types we dealt with, maintaining the external values in the files in big-endian was handled by a bunch of C macros... though, really, there were some issues using the [mumbles]Microsoft[/mumbles] C compiler found on SCO Xenix/386 and SCO Unix, especially evident when generating code to run on a 16bit 286 CPU. The performance hit, for BASIC programs, wasn't all that onerous, simply because we only needed to mess with byte order when doing I/O. I will grant that a DBMS is a bit more (ahem) I/O centric than an interpretive language application platform. > Another area potentially is code page for character data. While the > database may be able to translate the retrieved data based on table code > page and application needs, I recall that we made some CPU usage > improvements by doing that at the database load and keeping the tables in > the native code page. I managed to escape from the Business BASIC world long enough ago that character set code pages were still a gleam in some mad-man's eyes. :-) All right, so there were some rumblings but it was all more-or-less flat ASCII. Nowadays even simple jobs AREN'T. -soup -- John R. Campbell Speaker to Machines souperb at gmail dot com MacOS X proved it was easier to make Unix user-friendly than to fix Windows "It doesn't matter how well-crafted a system is to eliminate errors; Regardless of any and all checks and balances in place, all systems will fail because, somewhere, there is meat in the loop." - me ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
