Conference azur::mcc

you are failing the link because you must link it with the mcc_kernel_shr
as well as the c run time library. The instructions on link are in the
guide to writing an access module.

If you are using an options file add into it the lines:

sys$share:mcc_kernel_shr/share
sys$share:vaxcrtl/share

This will pull in the files you need to link against.

    RE:.0
    
    I'm not exactly sure what you mean by index structures.  If you mean
    common routines for B-tree management, then no, we don't.
    
    The MCC Kernel supports interprocess concurrency control only through
    the mcc_lock_... routines.  I'm not sure if these routines are fully
    supported on Ultrix, since Ultrix has more restrictions on managing
    system resources (such as locks).
    
    Building a management module requires (yet another) manual called
    the "Guide to Writing a Management Module", or "Management Module
    Programming", or something like that.  I don't have the list of
    MCC documentation handy.  But there is note in this conference
    someplace which gives a pointer to all the latest MCC Documentation
    (with the exception of the SRM which must be ordered).  You could try
    directory/key=documentation.  (They're someplace on node WORDY::.)
    
    Some things you are probably missing.  You need to link with
    sys$share:mcc_kernel_shr.exe/share and define the entry points in
    your dispatch table (not defined in the SRM for the example), as
    Universal symbols in your link options files.  Also you need to
    link as a shareable image (I assume you want to run as an FM or AM,
    not as a PM).
    
    When I wrote that sample program for MIR routine usage, I compiled,
    linked, and ran it on an MCC V1.0 VMS platform, so it should still
    work (I think).
    
    -Matt.

>    The MCC Kernel supports interprocess concurrency control only through
>    the mcc_lock_... routines.  I'm not sure if these routines are fully
>    supported on Ultrix, since Ultrix has more restrictions on managing
>    system resources (such as locks).
    
   Can you give me some more information on this?  I need to confirm it.
If it is true, we might be in big trouble.

                       Sieg

    The MCC kernel FULLY supports mcc_lock... routines on Ultrix.  What it
    costs you is Ultrix *semaphore* resources.  The default semaphore setup
    on Ultrix is pitiful: 10 semaphore sets.  A semaphore set is required
    for *each* unique lock created.
    
    The fix is simple:
    
    (1) Edit /usr/sys/h/sem.h to change SEMMNI (max # of semaphore sets),
    SEMMNS (max # of semaphores per set), SEMMNU (max # of semaphore undo
    structures), and possibly SEMUME (max # of undo entries per undo
    structure).
    (2) Rebuild your kernel.
    
    Note that MCC locks require 5 semaphores per set, so SEMMNS must be at
    least 5 X SEMMNI.  Also, there is a hard limit in Ultrix of about 32K
    sempahores.  I don't know how much memory each semaphore requires, but
    memory is cheap these days.
    
    Ted

>    The MCC kernel FULLY supports mcc_lock... routines on Ultrix.  What it
>    costs you is Ultrix *semaphore* resources.  The default semaphore setup
>    on Ultrix is pitiful: 10 semaphore sets.  A semaphore set is required
>    for *each* unique lock created.

	So only a lock of 10 SQL tabel entries could be performed?

>    Note that MCC locks require 5 semaphores per set, so SEMMNS must be at
>    least 5 X SEMMNI.  Also, there is a hard limit in Ultrix of about 32K
>    sempahores.  I don't know how much memory each semaphore requires, but
>    memory is cheap these days.

	Does this reflect the number of SQL table rows that MCC can have locked
simultaneously?  Or is it the number of MCC processes?  How does this relate to
MCC directives?

	Carl