T.R | Title | User | Personal Name | Date | Lines |
---|
2006.1 | X1.2.14 is NME internal only | TOOK::MINTZ | Erik Mintz | Fri Jan 03 1992 17:53 | 7 |
|
> 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.2 | A suggestion from Ed Tan... | DFLAT::PLOUFFE | Jerry | Thu Jan 09 1992 10:14 | 13 |
| 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.3 | Oops, here's the list of necessary softlinks... | DFLAT::PLOUFFE | Jerry | Thu Jan 09 1992 11:03 | 18 |
| 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.4 | | TOOK::SWIST | Jim Swist LKG2-2/T2 DTN 226-7102 | Thu Jan 09 1992 13:28 | 9 |
| 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.5 | | TOOK::FONSECA | I heard it through the Grapevine... | Mon Mar 09 1992 13:05 | 19 |
| 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.6 | Clarification | DFLAT::PLOUFFE | Jerry | Tue Mar 10 1992 09:24 | 50 |
| 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.7 | | TOOK::FONSECA | I heard it through the Grapevine... | Tue Mar 10 1992 11:40 | 5 |
| Thanks Jerry...
That is exactly what I hoped it would do!
-Dave
|