HP made a decision to help its HP 3000 customers recently, a choice that involved walking away from many man-months of HP 3000 engineering. Such HP 3000 engineering resource, at least from HP, is becoming more rare all the time. That rarity made HP's decision to help stamp out Large File Datasets, eliminating a concept that never worked quite as flawlessly as promised, as disappointing as it was necessary.
I recall the SIG-IMAGE meeting in 1999 where the database vendor community — those third parties who rely on IMAGE structures inside of the HP 3000 — asked for HP to stay the course. "Don't bother with Large Files in the IMAGE/SQL structure," they said; just build out the Jumbo Datasets so they can be as useful and reliable as the rest of the HP 3000.
However, HP took its counsel from large applications vendors back in those days. In modern times, the company knows it needs to be more aware of how it can help these third parties survive, carry the 3000 customer a little further. Introducing deep-seated database change at this point of the 3000's transition would be foolish. Besides the database tool providers such as Adager, Robelle and Bradmark, other companies and software providers would stall in their Unix-bound plans.
Adager's Alfredo Rego drew all these pieces and choices together in a message when HP announced it will be scrapping LFDS. "It is really sad to realize that the result of all of that effort by HP will never see the light of day," he said, "but the alternatives would have been much worse."
Rego makes an excellent point. Any tool or application vendor with an ounce of gumption has already accomplished the latest magic using an IMAGE structure well-known to developers. Fixing Large File databases — so they don't corrupt in "a rare incidence" of HP 3000 shops, as HP's Ross McDonald said — would've broken a lot of software. Rego said:
In fact, not only database tools would be affected. For instance, fast-speed report writers would be affected, as well as many other applications that take advantage of TurboIMAGE’s underlying privileged file system to bypass DBGET, DBPUT, etc.
It is noteworthy that underlying privileged data structures are NOT guaranteed (by any vendor) to remain stable. HP could have easily changed these privileged data structures to suit HP’s own purposes.
It is the responsibility (and duty) of privileged-mode programmers (whether in-house or third-party) to do whatever it takes to keep abreast whenever the vendor changes privileged material. In this case, HP chose to sacrifice the results of its own development process to avoid inflicting a painful blow to the worldwide HP 3000 community.
May LFDS rest in peace