Conference azur::mcc

>    	Question 1.
>    
>    		   Is there anyway to create a small private dictionary to
>    		   use for development? I would like to use a small one
>    		   because  frequent updates to the large dictionary take
>   		   what seems a very long time.

  Do you have the Toolkit Management Module Programming (MMP) guide ?
  There is a section on using the Developers Dictionary.

  The Developers Dictionary is a subset (read: small) version of the DECmcc
  dictionary which contains IMPM, Alarms, Domain, Registration MS data.
  Then you can add your MS information for *quick* testing of your Management
  Module.

  The source files are located in mcc_examples.  Here is a little script
  I wrote to make my private dictionary .. /keith

  ----------------------------------------------------------------------------

$!
$!  mcc_build_dev_dict.com
$!
$!  03-Jun-1992
$!  Keith Roberts
$!  DECmcc Toolkit
$!
$!  This procedure will build a developers dictionary by coping the
$!  necessary files from the DECmcc Examples Directory to the current
$!  directory.
$!
$  say :== write sys$output
$  cwd = f$environment("default")
$!
$  say " "
$  say "  This script will build the DECmcc Developers Dictionary"
$  say "  in the current directory, ''cwd'"
$  say "  Also, logicals will be set to access your private Dictionary"
$  say " "
$!
$  inquire copy_files   "  * Do you want to copy the files   (Y/N) [Y] "
$  say " "
$  inquire purge_files  "  * Do you want to purge files replaced by this script (Y/N) [Y] "
$  say " "
$  inquire set_logicals "  * Do you want to set the logicals (Y/N) [Y] "
$  if (copy_files.EQS."")   then copy_files   = "Y"
$  if (set_logicals.EQS."") then set_logicals = "Y"
$  if (purge_files.EQS."")  then purge_files  = "Y"
$!
$  say " "
$  say "      No further questions will be asked"
$!
$  if (copy_files)
$  then
$    copy mcc_examples:mcc_dev_fdictionary.dat mcc_fdictionary.dat
$    copy mcc_examples:mcc_dev_fdictionary.bpt mcc_fdictionary.bpt
$!
$    say " "
$    say "  Created:  mcc_fdictionary.dat"
$    say "  Created:  mcc_fdictionary.bpt"
$  endif
$!
$  if (purge_files)
$  then
$    purge/nolog mcc_fdictionary.dat
$    purge/nolog mcc_fdictionary.bpt
$  endif
$!
$  if (set_logicals)
$  then
$    define/nolog mcc_system 'cwd',mcc_specific,mcc_common
$!
$    say " "
$    say "  Defined:  mcc_system -> mcc_specific,''cwd',mcc_common"
$  endif
$!
$  say " "
$  say "  Done"
$  say " "
$!
$  exit

RE: .1

  Keith:  Thanks for answering question 1.

  -----------------------------------------------------------------------------

  > Problem 1. Right now each time I update the dictionary with the
  >  	       command files from the access module, after the step 
  >  	       of hitting ^z the message "READING PARSE TABLE (not
  > 	       exact but close) comes out and I'm stuck there. The cpu
  >  	       usage goes to 100% and will be there for hours, at least 
  >  	       that's as long as I wanted to wait. Is this a known
  >  	       problem? Am I doing something wrong?

  The Parse Table Builder portion of DAP is (probably) deleting data from the
  parse tables before it re-loads it back into the parse tables from the 
  dictionary.

  The parse table structures are complex and the algorithm to delete all of the 
  data for a particular class is quite time consuming.  Your not doing anything
  wrong.  It is a known performance problem with the dictionary sub-system.  
  This issue will be addressed in a future release.

  >  
  >  	       What I have to do to recover this is delete the
  >  	       fdictionary.bpt file and let it rebuild it. Will
  >  	       this act cause any problems? BTW the rebuild takes 2
  >  	       Hours.

  No, it shouldn't cause any problems.  Actually, I do the same thing every 
  once in a while, because it is often cheaper (time-wise) to rebuild the 
  parse tables from scratch rather than do a partial rebuild.  This is true
  whenever the class that you are updating is already in the parse tables and
  this class is large (i.e., contains many objects including other subclasses).

  Now, to be fair, partial rebuild is much faster than a total rebuild when
  you are loading new classes into the dictionary (i.e.,  no deleting has to
  be done).

  Hope this explanation helps...

                                                                       - Jerry    

    Thanks for the replies,
    
    re <.1> I did a like procedure, but for some reasson the Dictionary
    so much bigger than it used to be. If all the layered access modules
    are enrolled via BMS startup with the P1 parameter will this in fact 
    make the dictionary large, or is the newer version just larger than the
    old one?
    
    RE <.2>  I was afraid of that answer. Although it's good that I
    am not causing the problem it's kind of tedious developing access
    modules in pieces and having to wait so long for the update.
    
                                                               
    				Chuck

If you are adding new pieces as you say, then don't re-add the entire
MSL each time! That will cause the entire entity class to be removed
and rebuilt, which depending upon the model size can be time consuming.

Instead, just add then new information/fields into the dictionary. This
can be done by using seperate MS files for the new changes (such as for
a new entity class or new directives for an entity class), or it can be
done by only loading a portion of the .com file produced by MSL (please
be careful if you are going to be editing .com files, read the DAP commands
carefully, and make sure the USE command is in there so that the correct
seciton of the ditionary is updated). Partial updates are MUCH faster.