[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

127.0. "Can't redefine MCC$COMMON logical" by GDJUNK::HOULE (Steve, NM is the future!) Wed May 09 1990 13:43

HI,

I can't seem to be able to redefine the mcc$common logical to a data disk.
It is me or is this a known problem?

Somehow I lost the long & detailed information I had for 
this problem (eve -my stupidity).

A long time ago I redefined mcc$common to a data disk. Well, yesterday I found
out that mcc really wasn't using the "copy" of the sys$common:[mcc] files.
I was trying to install the IFT ICONs & Domains and didn't have enough system
disk space. So I "removed" the mcc files from sys$common:[mcc]
I reran mcc$startup and the output with failures is attached.

I know all the files are in the data disk directory and I'm logged is as system
so access can't be the problem (i even gave all the files open access).

When I put the files back in sys$common:[mcc] --and leave the logical redefined
to the data disk  mcc works??
So, tell me, what did I overlook  or is there some "hard" coding in my way?
===Steve


=============
The MCC$STARTUP startup procedure for DECmcc UT1.0.0 is now running.

%DCL-I-SUPERSEDE, previous value of MCC$SYSTEM has been superseded
%DCL-I-SUPERSEDE, previous value of MCC$COMMON has been superseded
%DCL-I-SUPERSEDE, previous value of MCC$ALARMS has been superseded
%DCL-I-SUPERSEDE, previous value of MCC$SPECIFIC has been superseded
%DCL-I-SUPERSEDE, previous value of MCC$TDF has been superseded
DECmcc (T1.0.0)

%MCC-E-CMDPROCNFND, Command procedure file specification not found
%MCC-E-NOTFOUND,  Dispatch entry for the specified entity does not exist
%MCC-E-NODICTIONARY, DICTIONARY file(s) not found
%MCC-E-NOTFOUND,  Dispatch entry for the specified entity does not exist
%MCC-E-NOTFOUND,  Dispatch entry for the specified entity does not exist


The MCC$STARTUP startup procedure for DECmcc UT1.0.0 is now ending.
                  
SYS_GSFMCC::sho log mcc*

(LNM$PROCESS_TABLE)

(LNM$JOB_804F3A00)

(LNM$GROUP_000001)

(LNM$SYSTEM_TABLE)

  "MCC$ALARMS" = "DUA1:[MCC.ALARMS]"
  "MCC$COMMON" = "DUA1:[MCC_OLDDIR]"
  "MCC$SPECIFIC" = "SYS$SPECIFIC:[MCC]"
  "MCC$SYSTEM" = "SYS$SYSROOT:[MCC]"
  "MCC$TDF" = "-4:00"

(DECW$LOGICAL_NAMES)
SYS_GSFMCC::

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


T.RTitleUserPersonal
Name
DateLines
127.1MCC$SYTEM, MCC$COMMON & MCC$SPECIFICTOOK::DITMARSPeteWed May 09 1990 18:1357
Hi,

******************************** WARNING!! ************************************
I can't make any statements about the advisability of redefining your MCC$
logicals.  I'm pretty sure the current MCC vmsinstal procedure will not be
happy with you doing so, and you will be bitten, one way or another, during 
upgrades unless you "un-do" whatever you've done before doing an upgrade.

This stuff is not in my realm of responsibility, but I do understand
enough about the use of search lists to (hopefully) help answer your question.  

If this is something lots of folks will want to do, maybe we (MCC) should 
explicitly add support for the kind of thing you are trying to do.
*******************************************************************************

Your problem isn't with MCC$COMMON, it's with MCC$SYSTEM.  There's some good
information on clusters and common/specific stuff in the VAXcluster manual of
the VMS docset.

The MCC$COMMON logical is used to place (create) files that MUST be common,
but the MCC$SYSTEM logical is used to access most files.  Your current 
definition of MCC$SYSTEM:

  "MCC$SYSTEM" = "SYS$SYSROOT:[MCC]"

relies on your definition of SYS$SYSROOT.  Normally VMS systems define 
SYS$SYSROOT to be a search list, the first element of which points to a 
system-specific directory, the second element of which points to a 
cluster-common directory.  For example, on node FOO in a cluster where FOO is
system 11, you would have something like:

   "SYS$SYSROOT" = "DISK$DUA0:[SYS11.]" (LNM$SYSTEM_TABLE)
        = "SYS$COMMON:"
1  "SYS$COMMON" = "DISK$DUA0:[SYS11.SYSCOMMON.]" (LNM$SYSTEM_TABLE)

What that all means is that your stuff in your private MCC$COMMON was never 
being seen, but the stuff in SYS$COMMON:[MCC] was.

What you want is something like this:

  "MCC$COMMON" = "DUA1:[MCC_OLDDIR]"
  "MCC$SPECIFIC" = "SYS$SPECIFIC:[MCC]"
  "MCC$SYSTEM" = "MCC$SPECIFIC:"
	= "MCC$COMMON:"

To build a logical name search list, separate each element by a comma in your
define command, like so:

$ define/system mcc$system mcc$specific:, mcc$common:

If you try this, *then* we'll see if there's any hard-coded stuff in your way.

NOTE: I would NOT consider re-defining SYS$SYSROOT

regards,

Pete
127.2untangle the mess & dictionary MUST be movableGDJUNK::HOULESteve, NM is the future!Wed May 09 1990 20:5516
Thanks for the help. I'll have to untangle the mess I have. It seems MCC is
using my redefined logical. For example, thats where all my alarms rules went.
I'm not a VMS expect but I have found that with Many applications if a logical
is defined in the startup file, its there for the very purpose I tryed to use
it for.

***I Strongly believe that Users MUST be at LEAST be able to put the dictionary
file on a disk other than the SYSTEM disk!!!!!!!!!!
No matter what platform MCC recommends a "large" application like MCC can't
require such Huge files on the system disk; Look at what's already happening,
a 150Mg disk is becoming to small to support VMS & DECwindows (a basic OS)!

Also, when the performance FM comes to life its files will need to be on 
other disk.

Thats my two cent, ===Steve
127.3try search listsTENERE::DUNONPaul Dunon - Telecom Engineering - VBOThu May 10 1990 10:1116
Hi,

We have installed MCC on a cluster but it can only be started on some sattelite.
I've modified my satellite mcc$startup.com the following way:

$ define/system mcc$system   disk$alezan_64750:[mcc],sys$sysroot:[mcc]
$ define/system mcc$common   sys$common:[mcc]
$ define/system mcc$specific disk$alezan_64750:[mcc]


to have the dictionary, gs_pool, event_pool and ptb_parser  data files on my
local disk when I run DAP, PTB and MCC.

It works fine.

			-- Paul
127.4what are logicals forGOSTE::CALLANDERThu May 10 1990 18:2832
    
    We seem to be walking around, without discussin, "What does MCC
    use logicals for, and which ones can I redefine?"
    
    Okay let's clarify what is being asked here. I frist saw a question
    about storing icons for the IFT release of the Iconic Map PM; then
    there was a question regarding the location of the pool, dictionary,
    and parse tables.
    
    MCC$ICON is use as the logical for identifying the location of the
    icons. You should be able to do a show logical on this and find
    it (it may be MCC$ICONS, you can check with TOOK::F_Messinger, or
    TOOK::D_Moore).
    
    MCC$SYSTEM is a search list used to find all of the dictionary files,
    the parse tables and the pools. Please note though that moving one
    of the dictionary files to a new directory and resetting the logical
    will NOT do it. You must move all of the MCC$... dictionary files to
    "move" a dictionary. In the developers toolkit manuals there is
    information on how to define the logicals and move files to create
    private libraries.
    
    Regarding your cluster problem, I run on a cluster now, the only
    thing we have to do is make sure that the DCLtables are reinstalled
    on each node so that the commands are available. If you don't do
    this then it tries to run the previous version (which was probably
    deleted by the installation procedure).
    
    Does this help?
    
    
        
127.5It shouldn't be a big problem to solveNSSG::R_SPENCETue May 15 1990 02:3510
    We have been able to take the whole [MCC...] directory set to another
    disk and simply update the startup file to make sure ALL the required
    logicals pointed to the new disk. It seems to work and (in my humble
    opinion) MUST work for the released V1.0.
    
    Actually I had to hack the KITinstal to actually install it that way
    but that's another storey. I did write up my comments and give them
    and the modified code to the KITINSTAL developer.
    
    s/rob