SCO OpenServer Enterprise System Release 5.0.5,5.0.6,5.0.7 
          SCO OpenServer Host System Release 5.0.5,5.0.6,5.0.7 
          SCO OpenServer Desktop System Release 5.0.5,5.0.6,5.0.7 

          My server has panicked with the following messages:

NOTICE: growreg - Insufficient memory to allocate 1 page - system call
failed
NOTICE: growreg - Insufficient memory to allocate 75896 pages - system call
failed
NOTICE: growreg - Insufficient memory to allocate 75896 pages - system call
failed

PANIC: HTFS: Bad directory ino 110048 (offset 116) on HTFS dev hd (1/45)
Trying to dump 32671 pages to dumpdev hd (1/41), 409 pages per '.'
........

Panic String: HTFS: Bad directory ino %d (offset %d) on HTFS dev %s (%u/%u)

          

The PANIC message indicates a problem with a bad directory on a
possible corrupted file system.

The NOTICE message indicate a problem with memory allocation by an
application.

Tools to help identify this would be to use the dump analysis "crash"
tool provided by SCO OpenServer to analyze the dump after the server
is next re-booted.  See Technical Article 105619, "Panic/Crash
Analysis if a dump is available.

Alternatively, if the SCO Kernel Debugger (scodb) is installed, you
can press <Ctrl><X> at the console and run the commands interactively
as the server is live on the console, although this would suspend
normal operation while you are in "scodb".  To exit "scodb", enter
<q> to quit and press <Enter>.  Normal operation should then resume.

For more information on how to use "scodb" visit:

                http://<your_server>:457/SCODB/CONTENTS.html

          and see:

Technical Article 109310, "Gathering information when SCO OpenServer 5.0.4 system panics but 
does not produce a valid dump or the system hangs."

Before starting to install "scodb", ensure you have a backup of your
kernel.  To do this, run the following commands:

                cd /
                /etc/btmnt -w
                cp /stand/unix /stand/unix.backup
                chmod bin:mem /stand/unix.backup
                /etc/btmnt -r

To install "scodb", change the "N" to "Y" for the 2nd parameter of
the file /etc/conf/sdevice.d/scodb.  Then save the file and re-link
the kernel using the command:

                /etc/conf/cf.d/link_unix -y

          If you get the following warning message:

                db_symtable in unix would only fit 200000 out of 216984 bytes

          Corrected table sizes in:

                /var/opt/K/SCO/link/1.1.1Eb/etc/conf/pack.d/scodb/tune.h
                ready for next re-link

Then you can run the re-link command again.

It is recommended to re-link the kernel twice, in general, when
installing "scodb".

          

Using the commands "user" or "u -f" within "crash" when analyzing the
dump may reveal the commands being run when the server panicked.  If,
for example, the server was running a "find" or "cpio" command then
it could indicate a damaged filesystem.

The panic message clearly indicates, at least the very strong
likelihood, that the filesystem is corrupted.  The above commands
may help identify the exact filesystem, directories or files that
may be corrupted and what application/script is being run.

To test the integrity of the filesystem run the following commands:

                cd /
                umount /<filesystem>
                fsck -ofull /dev/<filesystem>
                mount /dev/<filesystem> /<filesystem>

See Technical Article 105411, "Filesystem Repair Utilities for SCO OpenServer 5.0.0, 5.0.2,
5.0.4, 5.0.5." for more information.

The panic message contains a disk inode number.  After running fsck
and remounting the filesystem, assuming that this is successful, you
could try to find out the directory corresponding to this inode
number, using "ncheck" (below) and then try listing its contents and
even adding a file to it.

If you wanted to avoid a panic while doing this (in case there is
still corruption), then you could mount the filesystem read-only.

                ncheck -i <inode> /<filesystem>

There is also a command called "ff", which lists file names and
statistics for a filesystem.  However, this command does not operate
on an HTFS filesystem.

If the problem seems to be confined to the single directory indicated
by the panic message, you may wish to simply delete and recreate the
directory.  Since the panic happens explicitly upon either a directory
lookup or a directory file write, use:

                rm -r /<filesystem>/<directory>/[files]

If the "fsck" did not fix the filesystem then it may be necessary to
remove, re-create and restore the filesystem.  To do this follow the
instructions in Technical Article 109223, "How can a filesystem be
removed if there is no delete function in divvy?" to remove and then
re-create the same filesystem.

After this exercise you will have an empty filesystem.  Check it is
still valid by umounting the filesystem and running an "fsck".

If the filesystem is valid, then re-mount it and restore the data for
this filesystem from backup media.

If the filesystem is not valid then this indicates a disk or
controller problem rather than a filesystem problem.

          

  Technical Article 103593, "Cannot clean a secondary filesystem using fsck."

  Technical Article 103734, "What is /dev/recover and what is it used for?"

  Technical Article 105169, "How can I delete unremovable files from my system?"

  Technical Article 106350, "Using fsdb to modify filename; good for removing unusual 
            characters."

  Technical Article 105411, "Filesystem Repair Utilities for SCO OpenServer 5.0.0,
            5.0.2, 5.0.4, 5.0.5."

  Technical Article 105619, "Panic/Crash Analysis if a dump is available.

  Technical Article 105935, "How do I create customized system dump images on demand?"

  Technical Article 109223, ""How can a filesystem be removed if there is no delete 
            function in divvy?"

  Technical Article 109310, "Gathering information when SCO OpenServer 5.0.4 system    
            panics but does not produce a valid dump or the system hangs."

  Technical Article 111074, "Some of the commands that should work in scodb under 
            OpenServer 5.0.5 do not execute and I get "expected expression"."

  Technical Article 113281, "I am unable to fsck my filesystem and re-mount the 
            filesystem after a power failure."

       btmnt(ADM); crash(ADM); divvy(ADM); dumpsave(ADM); ff(ADM);
       fsck(ADM); mount(ADM); ncheck(ADM); scodb(ADM); sysdump(ADM)