I'd guess that fewer than 1,000 IT professionals are reading the 3000 mailing list and newsgroup these days. But just like at the end of a sporting event, the people left in these stands are the most knowledgeable and ardent in the game. They know what it has taken 20 years and more to learn. Today, like many days in the 3000 community, these biggest fans pass along what they know for free.
Today's subject on "the L," as it's called by its longest residents, is IMAGE, the database that made your HP 3000 famous. (And the best in the business, at least once, when Datamation ran a contest to determine which database won among contenders like Oracle, Informix, Ingres, Sybase, DB2, and a raft of others. Datamation is published no more, and some of those databases not survived. either. IMAGE, in its newer generations of TurboIMAGE and then IMAGE/SQL, rolls on.)
An IT pro posting to the mailing list was misunderstanding how Adager, the IMAGE/SQL all-purpose tool, was keeping him from corrupting his database. He asked, "When I try to change a dataset capacity in Adager, it tells me the minimum acceptable capacity is higher than I’m trying to set it at. Why?"
The answer gave the community a chance to teach IMAGE/SQL, instruction that's not only hard to purchase these days, but a great resource for a developer or somebody who maintains HP 3000 apps. A free resource, from the Web.
Wes, our confused IT pro, reported on 3000-L that Adager's dialogue was:
Present : 9763397
The minimum acceptable capacity is 9763396
The answers rolled in on the 3000-L, right away. First an overview:
I would venture to say that you are dealing with a detail dataset and you can’t reduce it without performing a reorganization of the set. There are detail records in entries above 5,500,000 and without updating all the pointers in the detail entries and the corresponding master entries, you simply can’t do that and hope to have a working database.
Adager prevented you from mangling your database.
Is it a detail dataset that you are trying to change? If so, you cannot make the capacity less than the high water mark unless you first detpack the set.
You need to pack the detail dataset to remove entries in the dataset that are marked as deleted logically, but not physically deleted, then you can reduce the capacity.
When a DBDELETE call is made to a detail dataset, in order to save processing time, the entry is logically flagged as being deleted, and any pointers to that entry are changed to bypass the entry in the chain. The entry is NOT physically deleted from the PRIV file that represents that detail dataset. By performing a detail pack, either with Adager, DBGENERAL, or DBUNLOAD/DBLOAD, the logically deleted (flagged as being deleted) entries are physically removed, leaving only the active, live entries.
When adding entries to a detail dataset, a highwater mark is kept that indicates the maximum number of entries in the dataset. For example, if I add 1,000 entries and delete 100 afterwards, my highwater mark remains at 1,000 because that is the most number of entries ever in the detail dataset. Adager, in such a case, is telling the user that you cannot change the capacity below 1,000 (the highwater), because there are physically 1,000 entries in the file (100 are logically deleted, but are physically still there).
Read can the entire thread for yourself to get a fine education on IMAGE, the database that makes your 3000 sparkle in the enterprise. Subscribe to get the messages by e-mail, if you prefer. It sure makes it easier to participate and learn.