[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

2006.0. "Changes to DAP for v1.2 kit" by DFLAT::PLOUFFE (Jerry) Mon Dec 30 1991 16:21

  Effective w/ the x1.2.14 baselevel, DAP's user interface has changed --
  hopefully for the better!

  A number of people have complained and filed QARs concerning the mystery
  of how DAP manipulates the dictionary files.  The following information
  should hopefully clear up this mystery.  If you use DAP often, please take
  the time to read this note completely.  I will make sure that this
  information finds its way into the Toolkit Reference Manual.
  Unfortunately, DAP is still not as simple as I'd like to see it, but I
  believe the following changes have improved DAP in the short term.

  DAP now works in the following way:

    ON VMS platforms:

      When DAP is run it uses the MCC_SYSTEM logical to find a version
      of the main dictionary file whose default name is: mcc_fdictionary.dat.

      If it finds one, then it will note the actual directory where the
      file was located and all subsequent dictionary file operations will
      use this same directory.  For example, if DAP finds mcc_fdictionary.dat
      in mcc_common ( == a:[mcc]), then the parse table file will be read from

                 mcc_common:mcc_fdictionary.bpt

      and written to

                 mcc_common:mcc_fdictionary.bpt

      using a new version number.
      A new version of the log file,

                 mcc_fdictionary.log

      will be written to mcc_common also.

      Appropriate error messages will be generated if these files cannot be
      read or written in this directory.

      If DAP doesn't find the main dictionary file, then it will create a new
      one in mcc_common and all subsequent dictionary file operations will
      use mcc_common as above.

      The dictionary routines will continue to use the mcc_system logical
      to read the mcc_fdictionary.dat file.  The parse table file read
      routine also will continue to use mcc_system logical to read the
      mcc_fdictionary.bpt file.

      Using this scheme the three files that make up the dictionary will
      always be treated as a set of files by the DAP utility.  At the
      same time users will still be able to place different versions of
      the .dat and .bpt files into mcc_specific for their own private
      uses.

      Note that in order for the above logic to work correctly, the definition
      of MCC_SYSTEM must include MCC_COMMON.

    On ULTRIX platforms:

      DAP will attempt to translate the MCC_SYS_LOCATION environmental
      variable.  If it translates to a non-null value then this value
      will be considered to be the directory for all subsequent DAP
      operations.  That is, DAP will attempt to find the main dictionary
      file, mcc_fdictionary.dat, in this directory.  If one is not found,
      a new file will be created in this directory.  The parse table
      and its corresponding log file will also be read from or written
      to this directory.

      If MCC_SYS_LOCATION translates to null, the directory,
      /usr/mcc/mcc_system will be used.

      Appropriate error messages will be generated if these files cannot be
      read or written.

    On both platforms:

      The logical or environmental variable, MCC_DICT_NAME can be used to
      change the default filename (just the filename, not the extension
      or directory of the full file specification) for the three
      dictionary files.  For example, if MCC_DICT_NAME is defined to be
      "my_dictionary" and DAP is run, then DAP will attempt to operate
      on the files:  my_dictionary.{dat, .bpt, .log} in the directories
      as described in the paragraphs above.

    DAP also requires the ability to read three other datafiles installed
    with the utility:

        mcc_meta_dictionary.dat
        mcc_meta_definition.dat
        mcc_dap_keytbl.txt

    On ULTRIX, these three files must exist under the MCC_SYS_LOCATION
    directory if MCC_SYS_LOCATION translates to a non-null value, or
    /usr/mcc/mcc_system if MCC_SYS_LOCATION is undefined.

    On VMS, these three files must be located in the MCC_SYSTEM directory.

    Appropriate error messages will be displayed if any of these three
    files are not found or if DAP cannot open them for reading.

    Last, but not least, on both VMS and Ultrix platforms, information
    messages are displayed to inform the user which files are being used by
    the DAP utility.
 
    I hope these changes make DAP a little easier to use!!  Keep those
    suggestions coming! :)

                                                                   - Jerry
T.RTitleUserPersonal
Name
DateLines
2006.1X1.2.14 is NME internal onlyTOOK::MINTZErik MintzFri Jan 03 1992 19:537
>  Effective w/ the x1.2.14 baselevel, DAP's user interface has changed --
>  hopefully for the better!

Note that x1.2.14 is an NME only development baselevel.  This change
will probably not be generally available until the SSB kit is released.

2006.2A suggestion from Ed Tan...DFLAT::PLOUFFEJerryThu Jan 09 1992 12:1413
RE: .0

  Ed Tan has recently made a suggestion that users may find useful.

  If you are running DAP on ULTRIX and you define MCC_SYS_LOCATION 
  to a private directory, you can set up symbolic links to the dictionary
  files in /usr/mcc/mcc_system in order to manipulate the standard
  dictionary instead of copying the dictionary files to MCC_SYS_LOCATION.

                                                                 - Jerry


                                                       
2006.3Oops, here's the list of necessary softlinks...DFLAT::PLOUFFEJerryThu Jan 09 1992 13:0318
RE: -.1

  The softlinks that one would have to set up are as follows:

  First change directory to MCC_SYS_LOCATION:

    cd $MCC_SYS_LOCATION 

  Then set up the following links:

    ln -s /usr/mcc/mcc_system/mcc_dap_keytbl.txt      mcc_dap_keytbl.txt
    ln -s /usr/mcc/mcc_system/mcc_meta_dictionary.dat mcc_meta_dictionary.dat
    ln -s /usr/mcc/mcc_system/mcc_meta_definition.dat mcc_meta_definition.dat
    ln -s /usr/mcc/mcc_system/mcc_fdictionary.dat     mcc_fdictionary.dat
    ln -s /usr/mcc/mcc_system/mcc_fdictionary.bpt     mcc_fdictionary.bpt
    ln -s /usr/mcc/mcc_system/mcc_fdictionary.log     mcc_fdictionary.log

                                                                       - Jerry
2006.4TOOK::SWISTJim Swist LKG2-2/T2 DTN 226-7102Thu Jan 09 1992 15:289
    re: .-1
    
    You don't need to repeat the lowest level pathname on the "ln -s"
    command if it's the same as the path being linked to.
    
    i.e.  ln -s /usr/mcc/mcc_system/mcc_fdictionary.bpt
    
    is all you need
    
2006.5TOOK::FONSECAI heard it through the Grapevine...Mon Mar 09 1992 16:0519
Following up from a pointer in the TSAM install problem note,
I would like to know what DAP's behaviour will be in 1.2.14 and
onward on VMS when MCC_SYSTEM is defined to be a search list
which includes three directories:  current, mcc_common, mcc_specific.

Does DAP make any assumuptions about the number of equivalence names
MCC_SYSTEM equates to?

The reason I ask, is TSAM does do this during the installation.  The dictionary
is copied from MCC_SYSTEM to the installation work directory, then
MCC_SYSTEM is temporarily defined to the above list.  After the installation
completes successfully, the appropriate dictionary files are copies back
to the directories wence they came.

It appears the current TSAM kit may have some problems, (including the
order of the three items above.)  While I am in working on this, I
want to make sure DAP has not changed here either.

-Dave
2006.6ClarificationDFLAT::PLOUFFEJerryTue Mar 10 1992 12:2450
Dave:

  When DAP runs on VMS it uses the mcc_system logical to find the main
  dictionary file.  If mcc_system is a search list (and it usually is), the
  first occurrence of the main dictionary file in the search path is used
  to determine the directory for all subsequent dictionary file manipulation.
  It doesn't matter how many equivalence names mcc_system equates to.

  The default name of the main dictionary file is mcc_fdictionary.dat.  This
  name can be overridden by the logical MCC_DICT_NAME.  For example if the
  logical MCC_DICT_NAME is defined to be "dave_fonseca", the name of the
  main dictionary file is assumed to be dave_fonseca.dat.

  So, let's say that you have mcc_system defined to be: current, mcc_common,
  mcc_specific.  If you have copied the main dictionary file and its 
  corresponding parse table file to current, then DAP will use current as
  the directory for all future dictionary file manipulation.  That is, it
  will use this directory for all read and write operations for all three 
  dictionary files.

  If no main dictionary file is found in current, DAP will check in mcc_common.
  If there is no main dictionary file in mcc_common, DAP will look in 
  mcc_specific.  If there is no main dictionary file in mcc_specific, DAP will
  create one in mcc_common and then use mcc_common for all subsequent dictionay
  file manipulations.
  
  Also, when DAP runs, it prints out informational messages that tell you
  what files (full file specification) it is manipulating.

  This agorithm was chosen because it accomplished two goals:

    o First, it ensures that all of the dictionary files will be treated as
      a set in one directory.  We will never have the old situation where the
      main dictionary file was in mcc_common and the corresponding parse table
      file was in mcc_specific.

    o Secondly, it allows users in clustered VMS environments to utilize 
      mcc_specific fully.  Users can place the dictionary of their choice
      in mcc_specific and the DECmcc package will use this dictionary instead
      of the one in mcc_common (so long as mcc_system is defined to be 
      mcc_specific, mcc_common, which is its usual definition).  That's how
      clusters are usually set up.

  The second goal does cause the algorithm to be more complex, but that's the
  nature of clusters -- more power, more complexity! ;)

  Anyway, hope this answers your question...

                                                                       - Jerry
  
2006.7TOOK::FONSECAI heard it through the Grapevine...Tue Mar 10 1992 14:405
Thanks Jerry...

That is exactly what I hoped it would do!

-Dave