T.R | Title | User | Personal Name | Date | Lines |
---|
1493.1 | | TOOK::SWIST | Jim Swist LKG2-2/T2 DTN 226-7102 | Thu Sep 12 1991 18: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 18: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 09: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
|