[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

1493.0. "threads problem?" by NAC::ENGLAND () Thu Sep 12 1991 18:24

    I went ahead and re-installed MCC, this time with the default
    dictionary directory.  The installation gets a lot farther this time
    without error, but strangely enough the dictionary wound up in 
    /users/england/mcc, which is where I asked MCC to put it on the first
    abortive attempt.  Hypotheses... The softlinks in /usr/mcc/mcc_system
    didn't get deleted, so MCC accidentally put it there.
    
    Also, I now get:
    
    ----------
    DOMAIN LOCAL_NS:.mcc_scp_test
    AT 1991-09-12-19:16:39.684Iinf
    
    Delete Successful
    
    %Internal error: cma__open_general: unexpected fstat error
    Thread Exception: Internal error detected in thread library
    --------------
    
    right before the prompt for the known DECnet node.
    
    
    The system has insufficient shared memory and semaphore resources 
    configured in its kernel, according to the MCC release notes.
    However, Jim said that this shouldn't be an issue unless I ran the
    Exporter FM.  I didn't install Ultrix/SQL and I don't plan to run 
    Exporter FM or create a database for it.  
    
    
T.RTitleUserPersonal
Name
DateLines
1493.1TOOK::SWISTJim Swist LKG2-2/T2 DTN 226-7102Thu Sep 12 1991 20:0810
    Never seen this one.   Cma_open_general is a cma routine which is part
    of the pseudo-non-blocking I/O package in cma.  
    
    It has nothing to do with shared memory, semaphores, or SQL, so I doubt
    your resource setup is an issue.
    
    What version and rev level of ULTRIX are you running?   What is your
    max open files per process set at (the default of 64 should allow you
    to run a reasonable number of things, you didn't lower it, did you?)
    
1493.2configuration dataNAC::ENGLANDThu Sep 12 1991 20:1716
    ULTRIX V4.2 (Rev. 96) System #2: Wed Sep  4 09:56:57 EDT 1991
    UWS V4.2 (Rev. 270)
    
    ident           "TLON"
    machine         mips
    cpu             "DS3100"
    maxusers        32
    processors      1
    maxuprc         50
    physmem         24
    timezone        5 dst 1
    
    64 = per-process descriptor table size
    
    Is that what you wanted?
    
1493.3TOOK::SWISTJim Swist LKG2-2/T2 DTN 226-7102Fri Sep 13 1991 11:095
    Does this cma error only happen during installation, or can you
    reproduce at will.  Do other things work?
    
    
    
1493.4CMA incompatibility?MACROW::SEVIGNYIlliterate? Write today for free helpFri Nov 01 1991 12:1415
    
    ULTRIX question...
                   
     I had a problem with my agent using RPC.  I was linking in the
    mcc_exec.a to resolve some calls that I'm making to the mcc_asn_xxx()
    routines.  As soon as I started to link in the mcc_exec.a, RPC wouldn't
    work.  As i looked though the library, I noticed that there are cma
    routines in the library.  Are these CMA routines incompatible with the
    threads package that RPC uses?  When I resolved the problem by taking
    the mcc_asn_xxx() source and linking with that instead, the problem
    went away.....
    
    Marc
    
    
1493.5TOOK::SWISTJim Swist LKG2-2/T2 DTN 226-7102Fri Nov 01 1991 12:473
    It's the same threads package but we may be on different baselevels
    which could definitely cause a problem.  MCC is at CMA BL7 prior to
    something in the vicinity of x1.2.6 and BL8 afterward.
1493.6MACROW::SEVIGNYIlliterate? Write today for free helpMon Nov 04 1991 13:229
    
    Well, I solved the problem on the agent side by linking with a subset
    of the MCC executive.
    
    But what can I do to link the AM which makes explicit RPC calls and
    MUST link with the entire mcc_exec.a library?
    
    Marc
    
1493.7Coordination of CMA baselevels MCC<>DCEMACROW::SEVIGNYDress code: 4 tooth minimumThu Nov 07 1991 15:2517
    
    
    Well, the REAL problem seems to be a lack of coordination between
    releases of MCC and DCE, both of which bundle CMA.
    
    Perhaps I'm the only one to notice this problem because we are the only
    users of MCC *and* DCE.  What we really need is to have some effort to
    have these different layered products work together.
    
    What I need to know is what the version of CMA that will be bundled
    with the External Field Test release of MCC on ULTRIX (coming up soon)
    and compare it to the new DCE that we will get in about a week.  If (by
    co-incidence) they happen to be compatible, then I will be happy (for
    the time being), but it doesn't solve the overall problem.
    
    Marc
    
1493.8TOOK::SWISTJim Swist LKG2-2/T2 DTN 226-7102Thu Nov 07 1991 17:3613
    I have asked the dce people for a clarification on this (i.e., what
    their CMA upgrade plans are).
    
    You may not not be aware of the fact that the MCC development team
    expends ENORMOUS amounts of manpower working issues like this. 
    However, there are 3 operating systems, 10-20 "middleware" subsystems
    like CMA and DECwindows.  And at least half of these components are
    themselves in a development process such that everyone is using
    intermediate baselevels of something or other.
    
    So when you suggest that we need more effort in this area, I suggest
    you consider the magnitude of the problem.
    
1493.9MACROW::SEVIGNYDress code: 4 tooth minimumThu Nov 07 1991 19:067
    
    Naturally we all view problems from our own perspective.  I hope that I
    did not imply that you haven't been trying.  I was pointing out a
    problem that I am trying to resolve (6 days before a code freeze!).  I
    hope that you'll sympathize with MY position, too.
    
    
1493.10bent on FTTOOK::BURGESSThu Nov 07 1991 19:2716
	
	Once we get a big enough disk, then we will using both packages, too ;)

    Today we using cma bl8 which has been patched to handle a mutex create 
    problem.  There might be a cma snapshot within the next few days that
    we might evaluate.  We'll go to v1.2 FT with one of these field test
    versions of CMA.  

    Our first priority is getting to field test with something that works.
    But we *do* need to resolve these product compatility issues
    which are getting more and more complex.

\Pete Burgess
    
    
    
1493.11Now if only the interfaces stopped changing...TOOK::BURGESSMon Nov 11 1991 00:539
We'll be testing out the latest cma snapshot (version 5d) starting Monday.
We're also freezing for field testing early this week.  One scenario is
that 5d fixes bugs without introducing more bugs, and DECmcc and DCE and ADA 
and VMS and ULTRIX all pick up this "field test baselevel" of CMA.


\Pete