I wrote earlier in reply to Ken Paul: > The reason that IMAGE uses the right-most 32 bits is because that is where > most of the information lies for an integer number. Integer-based formats > begin counting in the right-most (least significant) bit. Real numbers, on > the other hand, begin counting at the other end, more or less at the > left-most (most significant) bits -- and that's where the greatest amount of > "information" (unexpectedness) lies for a real number. IMAGE, unfortunately, > doesn't discriminate between reals and integers and always hashes its > address values based on the right-most bits, leaving us with the R4 problem. Please allow me to add just a note or two about the problem with real numbers. After I wrote the above note, I read Ken Paul's comments last night in the 3000 News/Wire about the current limits in the size of IMAGE datasets. In the News/Wire's October Flash Paper, Ken is reported to have said: "Paul believes the most critical to-do item for the [IMAGE] labs is one of 'a major need to address the current limitation issue. This will probably be my crusade for the next several years.' The biggest HP3000 customers are encountering real limits in databases, and the IMAGE lab, Paul believes 'will probably do a small fix by making the block pointer an unsigned number instead of a signed number, which will double the true limit of an IMAGE dataset. But [Adager colleague] Fred White and I would like to see IMAGE convert all pointers to 32-bit or even 64-bit and get it over with. This would require a similar program like DBCONVert, which would also make it difficult to move databases from one machine on a new version of IMAGE to a machine on an older version of IMAGE. But we feel that the Lab will have to bite the bullet sooner or later.'" I wholly agree with what Ken and Fred have to say. Converting IMAGE and the file system into a flat address space large enough to hold any imaginable amount of information is clearly going to have to be one of the primary goals of the next few years. Databases are going to grow very large during the next several decades. "Chunking," as was done with Jumbo datasets, can only be considered a clumsy, stopgap solution. And doubling dataset sizes by gathering a bit here and there will only hold things off for a few years, at most. To make these changes to the internal structure of existing IMAGE databases will require however a second version of the DBCONVERT program. But as long as such a program is required for one functionality, it can repair other primary deficiencies as well during its one-time execution. One of those deficiencies is the real number problem that Ken spoke of, where "hashing" is done off of the bottom 32-bits in real numbers (hashing in this case is limited to mean that the integer and real number conversions that IMAGE uses to create an address into a master dataset is relatively simple; no matter how a hash algorithm is implemented, the intent is use the most non-uniform, "unexpected" portion of the information held in the search item value and convert it into a relatively uniformly distributed address somewhere within the current capacity of the master dataset). As I mentioned earlier, real numbers larger than 32-bits in length don't act this way. The informational portion of a real number lies in its high-order bytes, not the low-ones. Because disc space is no longer anywhere near as precious as it once was -- and because the use of real numbers have significant user-friendly values over the use of integer numbers with implied decimal points, it seems only reasonable to expect the increased use of long reals in the future. Indeed, we're seeing that trend in all of the new databases that we encounter at customer sites (except, of course, for those sites that use COBOL as their primary application development language). Correcting the poor choice of the "hashing" algorithm that currently exists within IMAGE for long reals is a relatively desirous thing to do -- and I would like to add it as an addendum rider to Ken's crusade. If we're going to convert databases sometime in the near future, we might as well fix everything we can in one fell swoop. Wirt Atmar PS: On a second subject, Cortlandt Wilson has a nice article/opinion piece in the same issue of the News/Wire on the subject of the still-missing "908", the "personal mainframe" HP3000. I not only agree with everything Cortlandt has to say, I have for some time now shamelessly appropriated his "personal mainframe" phrase since I heard him first say it six months ago. Our best customers take total psychological ownership of their HP3000s and treat them exactly as if they were "personal mainframes," regardless of the machine's actual size or the number of people they have to share it with. However, over the years I've noticed that taking such total psychological ownership of an HP3000 is a great deal easier if the machine is smaller rather than larger -- and that our customers who started on micros and who now run 987s still treat their 987s as if they were PC-like devices. They can do anything on these machines that they wish because they are totally in control. If I had to pick one single reason why I believe the 908 is so important, it is to create a new generation of people who understand how to use the HP3000 for imaginative and creative business purposes without getting too entangled in all of the technical detail. As I tell all of our customers, if you can run a micro, you can run a 997. There is no difference between the machines -- other than the size of the lease payments.