Conference azur::mcc

Colman, 

I am not a MIB guru, so I won't be of any help regarding your first problem, but 
I can give you some information rearding the second one. 

On Ultrix (DECmcc V1.2 and V1.3), the dictionary is implemented using a hashed
package called nDBM. This package creates a "sparse" dictionary with a virtual 
size far larger than the real one. 

So ls -l will give you the virtual size (which might even be larger than the sze
of your partition) and ls -s or du will give you the physical size. Do not use
the results of an ls -l to calculate the dictionary size. 

A side effect of that is that the standard copy command (cp) should not be used
as the virtual size will become the physical one. Use tar instead to copy these
files. 

Hope this helps,

Marc. 

>================================================================================
>Note 5779.0         Dictionary corruption and size questions          No replies
>SIOG::PARKS                                          44 lines   9-DEC-1993 12:18
>--------------------------------------------------------------------------------
>
>
>A customer has the following configuration
>        DECstation 5000/200 with 128 Mbytes
>        Ultrix V4.3
>        DECmcc V1.3 (network manager 200)
>        Extended LAN AM V1.3 (from August CDs)
>There were no errors during installation and all the IVPs ran successfully.
>
>Problem 1.
>
>I was trying to load in some XYPLEX mibs that are distributed with DECmcc when
>a segmentation fault occured during the dictionary update procedure. There were
>no DECmcc processes running during the MIB load. The XYPLEX_BOOTCLNT_MIBDEF.TXT
>loaded successfully, the failure occured loading in the
>XYPLEX_INTERNET_MIBDEF.TXT. Using mcc_dap I saw that part of the mib that was
>being loaded when the failure occured was in the dictionary. 
>
>Has the dictionary been corrupted ?
>
>I copied mcc_fdictionary.dat,.bpt and .ctm before the copy. Will restoring 
>these files recover the dictionary ?
>
>Problem 2.
>
>After installing DECmcc, doing a 'du /usr/mcc/mcc_system' gives 
>
>162     /usr/mcc/mcc_system/mcc_scripts
>34746   /usr/mcc/mcc_system
>
>Doing a 'ls -l /usr/mcc/mcc_system/mcc_fdict*' gives
>
>-rw-r--r--  1 root      2151776 Sep 29 15:38 mcc_fdictionary.bpt
>-rw-r--r--  1 root       350424 Sep 29 15:37 mcc_fdictionary.ctm
>-rw-r--r--  1 root     58638336 Sep 29 15:23 mcc_fdictionary.dat
>-rw-r--r--  1 root         4096 Sep 29 15:22 mcc_fdictionary.dat.dir
>-rw-r--r--  1 root         8134 Sep 29 15:38 mcc_fdictionary.log
>
>How can the 'du' command show the mcc_system directory using ~35 Mbytes of
>disk space when the /usr/mcc/mcc_system/mcc_fdictionary.dat file is 58 Mbytes.
>
>After the mib load failed in problem 1 the 'du' command showed the mcc_system
>using about 71 Mbytes of disk up from about 35 Mbytes.
>
>Colman
>

set face/colour=red

I repeated the note just by accident. Sorry.

*Robert

Thanks for the replies. Re: problem 2 in .0 on the size of the dictionary file, 
and how to backup/restore it, here's what I found.

Solution 1.

As said in .1, the mcc_fdictionary.dat is an NDBM format file and so is the 
mcc_dispatch_table.dat file. The following command will backup a dictionary
file and preserve its original size

dd if=mcc_fdictionary.dat of=/usr/mcc_temp/mcc_fdict.dat conv=sparse

Doing a diff of the original dictionary file and the backed up file showed
they were identical.

When restoring the file you have to use the 'conv=sparse' option as well.

On my own system I backed up and restored the dictionary as above and I was 
able to load the XYPLEX_INTTERNET_MIBDEF.TXT into the restored dictionary. Note
when backing up the dictionary also backup mcc_fdictionary.bpt,.ctm files,
these are not NDBM as far as I could tell so cp works.

Solution 2.

An offline mail from .1 suggested using mcc_ndbm. I tried backing up the 
dictionary using the command

mcc_ndbm -u mcc_fdictionary.dat /usr/mcc_temp/mcc_fdict_u.dat

This worked and produced a smaller file than the original dictionary. It also
needs the mcc_fdictionary.dat.dir file to work so it can't be used to backup
the mcc_dispatch_table.dat.

The restore command is

mcc_ndbm -l /usr/mcc_temp/mcc_fdict_u.dat mcc_fdictionary.dat

This produces a file of the same physical and 'virtual' size as the original
dictionary file. It also produces a new mcc_fdictionary.dat.dir file. A diff 
between the restored dictionary and the original showed they were different !!
However when I started MCC using the restored dictionary it appeared to work. 
I didn't have time to load in a mib.


Maybe somebody who knows ndbm and the dictionary structures could say whether
the above solutions are supported and will work in all cases. In the meantime
they have my 5 year guarantee which is, they are guaranteed for 5 years or
whenever you use them whichever comes first.

Colman