| T.R | Title | User | Personal Name
 | Date | Lines | 
|---|
| 1493.1 |  | TOOK::SWIST | Jim Swist LKG2-2/T2 DTN 226-7102 | Thu Sep 12 1991 17:08 | 10 | 
|  |     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.2 | configuration data | NAC::ENGLAND |  | Thu Sep 12 1991 17:17 | 16 | 
|  |     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.3 |  | TOOK::SWIST | Jim Swist LKG2-2/T2 DTN 226-7102 | Fri Sep 13 1991 08:09 | 5 | 
|  |     Does this cma error only happen during installation, or can you
    reproduce at will.  Do other things work?
    
    
    
 | 
| 1493.4 | CMA incompatibility? | MACROW::SEVIGNY | Illiterate? Write today for free help | Fri Nov 01 1991 10:14 | 15 | 
|  |     
    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.5 |  | TOOK::SWIST | Jim Swist LKG2-2/T2 DTN 226-7102 | Fri Nov 01 1991 10:47 | 3 | 
|  |     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.6 | Solved � the problem | MACROW::SEVIGNY | Illiterate? Write today for free help | Mon Nov 04 1991 11:22 | 9 | 
|  |     
    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.7 | Coordination of CMA baselevels MCC<>DCE | MACROW::SEVIGNY | Dress code: 4 tooth minimum | Thu Nov 07 1991 13:25 | 17 | 
|  |     
    
    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.8 |  | TOOK::SWIST | Jim Swist LKG2-2/T2 DTN 226-7102 | Thu Nov 07 1991 15:36 | 13 | 
|  |     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.9 |  | MACROW::SEVIGNY | Dress code: 4 tooth minimum | Thu Nov 07 1991 17:06 | 7 | 
|  |     
    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.10 | bent on FT | TOOK::BURGESS |  | Thu Nov 07 1991 17:27 | 16 | 
|  | 	
	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.11 | Now if only the interfaces stopped changing... | TOOK::BURGESS |  | Sun Nov 10 1991 22:53 | 9 | 
|  | 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
 |