« Wayback: Web prospect put songs in hearts | Main | HP is doing better without some customers »

May 25, 2018

Fine-Tune: Locking databases into lookups

Editor's Note: Monday is a holiday to commemorate Memorial Day, so we're celebrating here with time away from the keyboard. We'll be back with a new report May 30.

Lock files databaseWe’re migrating from our 3000 legacy applications to an ERP system hosted on another environment. Management has decreed the HP 3000 apps must still be available for lookups, but nobody should be able to enter new data or modify existing data. Should I do the simplest thing and change all of the databases so that the write class list is empty?

Doug Werth replies:

One way to do this is to write a program in the language of your choice that does a DBOPEN followed by a DBLOCK of each database (this will require MR capability). Then the program goes into an infinite loop calling the PAUSE intrinsic. Any program that tries to update the database will fail to achieve a lock, rendering the databases read-only. Programs that call conditional locks will come back immediately with a failed lock. Unconditional locks will hang.

This has been a very successful solution I have used on systems where a duplicate copy of the databases is kept for reporting and/or shadowing using IMAGE log files.

Steve Dirickson agrees with the poster of the question:

Since very few developers write their apps to check the subsystem write flag that you can set with DBUTIL, changing the classes is your best bet. Make sure you do so by changing the current M/W classes to R/R so the existing passwords will still work for DBOPEN, and only actual put/update/delete operations will fail.

The Big Picture: If protection is required for the database, that protection should reside in the database if at all possible. As mentioned, this is easy with IMAGE.

I am putting a new disk drive into my 3000 configuration, one that doesn't have an HP label on it. It's 500GB and a great value. What patches should I be sure to have installed on MPE/iX 7.5?

MPEMXT1
Large Disk: FSCHECK SYNCACCOUNTING fix for HFS files

MPEMXT3
Large Disk: limit maximum SCSI disk size to a half-terabyte

MPEMXT4
Large Disk: SSM changes for disk space allocation and accounting

MPEMXT7
Large Disk: Discfree changes to correct sector counts

MPEMXU3
Large Disk: REPORT "FORMAT=LONG" enhancement. MPEMXU3 includes patch MPEMXT2 which is another Large Disk/Files patch. MPEMXT2 provides changes to the ALTACCT, NEWACCT, ALTGROUP, NEWGROUP commands.

MPEMXU6
Large Disk: CATALOG.PUB.SYS changes for CIERR messages

MPEMXU7
Large Disk: CICAT and CICATERR.PUB.SYS changes

The critical one is MPEMXT3, which protects from other problems.

06:09 PM in Hidden Value, Homesteading, Migration | Permalink

Bookmark and Share

Use our search engine to find 20 years
of HP 3000 news and articles

Comments

Comments

The comments to this entry are closed.