PROBLEM:  (QAR 59399)	(Patch ID: TCR150-010)
********
This patch fixes a problem with the Memory Channel API whereby the function 
imc_asalloc did not allow a negative key (most significant bit of key being 
set).

If the Memory Channel API function imc_asalloc is called with a negative key 
it returns a status of -2.  If the status is passed to imc_perror it will print 
the following error message:

  ": invalid parameter specification"

PROBLEM:  (MANT50554)    (Patch ID: TCR150-019)
********
This patch fixes a problem where errors in the resolver will cause the
clumember script,  which executes the mcm_init program at boot time, 
to core dump with a "Segmentation violation". 

PROBLEM:  (65732)    (Patch ID: TCR150-039)
********
This patch fixes a problem where errors in the resolver will cause the
clumember script,  which executes the mcm_init program at boot time, to
produce unhelpful error message such as:

   .
   .
   .
   ONC portmap service started
-> mcm_sysinit gethostbyname: not owner
   Cluster member started
   Starting ASE
   .
   .
   .

PROBLEM:  (none)    (Patch ID: TCR150-040)
********
This patch fixes a problem with the Memory Channel API whereby the
function imc_ckerrcnt was signifying an error had occurred when in fact
no error had occurred. The following is the error code seen when running
a Digital MPI code (Note Digital MPI uses the Memory Channel API):

        [5]MPI Die-ump2chck.c 91 "ump_wait failure" (-16)

PROBLEM:  (76608, 76806) (PATCH ID: TCR150-090)
********


This patch fixes a problem that can cause a panic in mcs_wait_cluster_event()
when using the Memory Channel API.  The following is an example stack trace
from a lockmode=4 panic:

  0 boot()
  1 panic()
  2 simple_lock_fault()
  3 simple_unlock_count_violation()
  4 mcs_wait_cluster_event()
  5 mcs_configure()
  6 kmodcall()
  7 syscall()
  8 _Xsyscall()
PROBLEM: (CFS.76473) (PATCH ID: TCR150-098)
********
This patch fixes a problem with the Memory Channel API whereby a node
crashes holding an mc-api lock, under certain circumstances the lock
will not be released after the node crashes. For the problem to occur there
must be 3 or more nodes in the cluster and the node handling the cleanup
after a node crashes (known as the primary mapper) does not have the lock
allocated.