Image Database Aborts
One error message that strikes fear in the heart of an HP3000 System Administrator is:
DBG DISABLED; POTENTIAL DAMAGE; ONLY DBCLOSE ALLOWED
Under normal circumstances, the first process to DBOPEN a database creates the DBG file. The last process to DBCLOSE the database purges the DBG file. All Image intrinsics (DBOPEN, DBFIND, DBGET, DBPUT, etc.) access the DBG area.
The DBG DISABLED error is actually a feature of Image. A defense mechanism. When Image encounters a condition in which it cannot continue to process, it will abort. It is very rate to see an abort while in Image code. When Image aborts it disables the DBG and all subsequent database calls will return the error above.
Once the last user has closed the database and the DBG file has been purged, users can once again access the database. But a vicious circle has begun. Whatever situation led to the Image abort will undoubtedly occur again, and all programs will abort with the DBG disabled message.
As you can see the DBG DISABLED message does not tell you what caused the original Image abort, which is the error that must be tracked down. Consider that if you have 100 users accessing the system, one of the users saw the Image Abort message, and 99 of them saw a DBG DISABLED message. What are the chances you will hear from the user with the Image Abort? So, how do you track down the problem?
Enable Your Databases for Dumping
Enable DUMPING with DBUTIL. Setting this option tells Image to “dump” the contents of the DBG prior to aborting. Our support team can analyze the contents of the DBG file and advise you on how to fix it. The default setting for DUMPING is disabled. There is no overhead incurred by enabling a database for DUMPING. The only time it is invoked is when Image is aborting. During normal processing the DUMPING flag is never even interrogated. To enable a database for dumping you must log in as the database creator, and you must have exclusive access to the database. It is Beechglen’s recommendation to enable dumping for all production databases on your system.
:dbutil HP30391C.09.05 TurboIMAGE/XL: DBUTIL (C) COPYRIGHT HEWLETT-PACKARD COMPANY 1987 >>show esp flags For database ESP Access is enabled. Autodefer is disabled. Dumping is disabled. Rollback recovery is disabled. Recovery is disabled. ILR is disabled. ... >>enable esp for dumping Dumping is enabled. >>exit
Other Database Management Systems
As you look toward the future your organization may be thinking about migrating a homegrown application on another database system and computer platform. Or you may be considering what your software application vendor is offering. Or you may be contemplating deploying a new application. Keep these thoughts in mind when As you explore alternatives to your Image-based systems ask the vendor(s) these pointed questions, and accept nothing less than direct answers.
- Exactly what happens when the system is unexpectedly rebooted
(i.e. there is no controlled shutdown of processes?)
- Does the DBMS automatically recovery?
- Do I have to execute any manual recovery procedures?
- How long will the system be down before the users can access it again
(time waiting for hardware replacement notwithstanding)?
- How much data will I lose?
- Does the system complete or back-out in-progress transactions?
- Are cached transactions posted?
- What happens when the database server aborts?
Other systems will certainly offer features that Image doesn’t have. But many of the inherent features of Image that we take for granted may not exist in some of the “more modern” database systems. Gather as much information as possible so that you can be prepared.