Conference azur::mcc

    Marc,
    
    Do your enrollment entry points follow the naming conventions?
    
    Your executable if MCC$TEST_AM. Do your _INIT, _PROBE, and _LOG
    also follow this: (explain in chapter 7 of the SRM)
    		MCC$TEST_AM_INIT
    		MCC$TEST_AM_PROBE
    		MCC$TEST_AM_LOG
    
    if they don't then they won't be found, and the tables inserted.
    
    This is only one possible problem, others can be due to insufficient
    privileges to access the dispatch file or test_am. (See the AM guide
    worksheet on dispatch table problems.)
    
    Hope these help.
    jill
    

    Jill,
    
    You were right on the spot. 
    
    The entry names were the problem.  I have added the _AM in the name of
    the exec and forgot to update accordingly the entry points.
    
    Thanks,
    
    Marc.

    
    I am also having a problem enrolling my AM!!!  I used the SAMPLE_AM
    to create the TRADE_AM.  The error message is as follows:
    
    =================================================================
    MCC> enroll mcc$trade_am
    %LIB-E-ACTIMAGE, error activating image
    PENNI$DUA0:[SYS0.][SYSLIB]MCC$TRADE_AM.1
    -SYSTEM-F-NOTINSTALL, writable shareable images must be installed
    %MCC-E-ENROLL_FAILED,  Enroll failed, table is not fully inserted.
    MCC>
    ==================================================================
    
    MCC seems to be running fine otherwise since I can access the
    SAMPLE AM.
    
    I looked through the documentation, particularly the Toolkit and
    the AM programming manual but that didn't help.  All the steps
    for developing an AM are elegantly described upto using the linker
    to obtain a shareable image (for e.g., Chap. 9 in AM Programming
    manual).  But then the enrollment step is skipped, and the
    documentation continues with debugging and testing an AM.
    
    Any idea what is it that I need to install?
    
    Regards,
    
    Muhammad
    

    This often happens in VAXC when someone defines a "static" variable
    because VAXC defaults the static variables to be "share" (i.e.,
    writable).  Please include the .map file of your exe, that should narrow
    the problem down.  If you are defining static variables, make them
    "noshare", for example:
    
    static unsigned long int init_flags = 0;
    
    should be:
    
    static noshare unsigned long int init_flags = 0;
    
    -Matt.

    RE .3:

    You need to install the AM image itself.  As your AM contains PSECTs
    that are shared and writeable, VMS is requiring that you install it
    before it will allow you to image-merge into DECmcc.  There are 2
    things that you can do about this.

    The first is to go ahead and install your AM.  This gets to be a pain
    if you are in early development mode, as re-installs may be frequent,
    and it is easy to forget to install a new version and end up running an
    old one.

    The second is to eliminate the need to install your AM.  In order to do
    this, you must eliminate the shared and writable portions of your
    image.  The offending pieces are data that are declared externally to a
    function (static allocation), but are not declared to be not shareable. 
    The VMS linker puts these into individual PSECTs that are shared and
    writable.  This makes your image writable, and VMS is trying to protect
    you from subversion by forcing you to install your image.  
    
    Examine your link map.  You will see some of your variables identified
    as PSECTs:

    Psect Name   Module Name    Base     End          Length         Align
    ----------   -----------    ----     ---          ------         -----
    SOME_VARIABLE             00000200 00000203 00000004 (       4.) LONG 2
                 MCC_IM_FM    00000200 00000203 00000004 (       4.) LONG 2

       with PSECT attributes of:

    PIC,USR,OVR,REL,GBL,  SHR,NOEXE,  RD,  WRT,NOVEC
                          ===              ===

       for a variable declaration of:

    long some_variable;

    It is the SHR and WRT together that cause the problem.  If a variable
    it declared externally to a function, but is qualified with "noshare"
    (assuming use of C language), the PSECT attributes for this variable
    will be:
    
    PIC,USR,OVR,REL,GBL,NOSHR,NOEXE,  RD,  WRT,NOVEC
                        =====              ===

    The fix is to change the declaration to:

    noshare long some_variable;

    A variable declared this way will permit the module to be enrolled into
    DECmcc without being installed in VMS.  Now VMS is happy, because the
    writable parts of your image are not shareable, so you cannot be easily
    subverted.  The only shareable pieces left are the code and constant
    data.  Someone sharing your image cannot affect you by modifying your
    (unshared) data.

    You must change all PSECTs with SHR and WRT attributes before the image
    can be enrolled without being installed.

       Ted Hupper
    

    
    RE: .4, .5
    
    Matt and Ted,
    
    Thanks for the hints.  So it's time to go back to the drawing
    board ;-)
    
    I'll make the necessary changes and re-build the AM.  If that still
    doesn't work, I'll post the .MAP file here.
    
    I have a related question about the necessity of running PTB (and 
    DAP) once I re-build the AM.  Since I won't be making any changes 
    to the MSL file, do I need to re-run it considering it is such a 
    bear?
    
    Regards,
    
    Muhammad

re: -< So its just a few bits set by the linker! >-

	It's also considering the implications of shared writeable data
	when more than 1 thread is executing in your code, if you really
	want it.

	But if the MS hasn't changed, then you don't need to rerun DAP and
	PTB.

	Mike
    

Re: 134.4

>    This often happens in VAXC when someone defines a "static" variable
>    because VAXC defaults the static variables to be "share" (i.e.,
>    writeable).

In VAX C, "static" variables have the NOSHR PSECT attribute by default.

It's the external variables, which have SHR and WRT PSECT attributes, that
cause the "writeable shareable images must be installed" error.  (external
variables are those which are defined with no storage class keyword - *not*
the ones defined with "globaldef").


Roy

    
    When I want back to the drawing board I realized that there are
    quite a few variables that needed to be changed from "static" to
    "static unshared".  :-<  (Remember, I am trying to retrofit an
    existing program to become an AM.  It is establishing it's own
    handlers, AST's and such.  I figure if I am the only one using 
    MCC then the code will not run multiple threads.  Please correct
    me if I am wrong.)
    
    So I decided to take Ted's suggestion 1 in .5 for now.  The compiles
    were all clean, with no errors.  When using the linker, however, I 
    got the following error:
    
    ================================================================
    !+
    !   End mcc$trade AM LINKer options file.
    !-
    %LINK-I-BASDUERRS, basing image due to errors in relocatable references
    %LINK-W-ADRWRTDAT, address data in shareable writeable section
        in psect CURRENT_NODE offset %X00000004
        in module MGMT_TRADECP file USER$A:[ASHRAF.MCC.TRADE]TRADE_OBJLIB.OLB;2
    ================================================================
    
    Assuming that this can be ignored if I used suggestion 1, I proceeded 
    to install and enroll the image.  However, I got the following error
    message:
    
    ================================================================
    
    PENNI $ MC INSTALL
    INSTALL> ADD/HEAD/SHARE/WRIT SYS$SHARE:MCC$TRADE_AM
    INSTALL> EXIT
    PENNI $ MCC
    DECmcc (T1.0.0)
    
    MCC> ENROLL MCC$TRADE_AM
    %LIB-W-EOMWARN, compilation warnings in module MCC$TRADE_AM
    %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
    address=00000000, PC
    =000BD994, PSL=03C00000
    %SYSTEM-E-ACCVIO, access violation, reason mask=00, virtual
    address=0000000A, PC
    =0000000A, PSL=0000000F
    PENNI $
    
    ================================================================
    
    Does anyone have any insights into this problem?
    
    Regards,
    
    Muhammad

    RE:.9
    
    I believe that Linker warning message is telling you that the linker
    COULD NOT create a sharable image, and gave you a non-sharable image
    instead.  MCC REQUIRES the image to be sharable.
    
    -Matt.

    RE: .4 & .10
    
    Matt,
    
    I bit the bullet, and replaced all the occurences of "static"
    variables to "static noshare"!  Then I re-compiled and re-linked 
    the files.  Unfortunately, the problem is still there with psect
    CURRENT_NODE!
    
    I am reproducing the segments from various files related to 
    the problem, and will appreciate any help you can provide.
    
=============================================================================
MGMT_TRADECP.H (fragment)
-----------------------------------------------------------------------------
#define MAKE_VS_DESCRIP(descrip_name,max_size,init_string)	            \
    struct {								    \
	unsigned short dsc$w_maxstrlen;					    \
	unsigned char dsc$b_dtype;					    \
	unsigned char dsc$b_class;					    \
	char *dsc$a_pointer;						    \
	struct {							    \
		unsigned short current_len;				    \
		char characters[max_size];				    \
	       } counted_string;					    \
	   } descrip_name = {max_size,DSC$K_DTYPE_VT,DSC$K_CLASS_VS,	    \
			     &descrip_name.counted_string,		    \
			     sizeof(init_string)-1, init_string}

=============================================================================
MGMT_TRADECP.C (fragment)
-----------------------------------------------------------------------------
MAKE_VS_DESCRIP (current_node,MGMT_K_MAX_NODE_SIZE,"");   /* For ^c */
    
=============================================================================
MGMT_TRADECP.MAP
-----------------------------------------------------------------------------
                                             +------------------------+
                                             ! Object Module Synopsis !
                                             +------------------------+
MGMT_TRADECP    V1.0              8489 [ASHRAF.MCC.TRADE]TRADE_OBJLIB.OLB;3 
                                          12-JUN-1990 14:51  VAX C V3.0-031
%LINK-I-BASDUERRS, basing image due to errors in relocatable references
%LINK-W-ADRWRTDAT, address data in shareable writeable section
	in psect CURRENT_NODE offset %X00000004
	in module MGMT_TRADECP file USER$A:[ASHRAF.MCC.TRADE]TRADE_OBJLIB.OLB;2

---------------------------------
                                            +--------------------------+
                                            ! Program Section Synopsis !
                                            +--------------------------+
CURRENT_NODE                 00008468 00008477 00000010 (         16.) LONG 2   
                             PIC,USR,OVR,REL,GBL,  SHR,NOEXE,  RD,  WRT,NOVEC
             MGMT_TRADECP    00008468 00008477 00000010 (         16.) LONG 2

try:

static MAKE_VS_DESCRIP (current_node,MGMT_K_MAX_NODE_SIZE,"");   /* For ^c */
^^^^^^

since you're not specifying any storage class, the variable being defined 
(if the call to the macro is outside of a function) is EXTERN (the default
storage class).

Roy in 134.8 had the problem nailed.

Also, Matt (134.4), My V3.0 VAXC manual says there is no difference in the 
storage class for STATIC or STATIC NOSHARE. 

Could you verify what you entered in 134.4 is correct?

regards,

Pete

    A) As pointed out by several above, "noshare" is the default attribute
    for "static" allocation, but "extern" is the default allocation for a
    variable.  Thus "noshare" is not the default attribute.  As Matt points
    out, MCC requires shareable images for management modules.  However,
    all this does not address the problem specified in .9.
    
    B) RE .9:
       The linker is basing (putting at a fixed location = not relocatable)
    your image because of address information in a shared section.  A
    non-relocatable image cannot be successfully used in MCC, unless it is
    the ONLY management module to enroll AND is the presentation module
    (user interface).  It MUST be relocatable otherwise.  There is no
    workaround if it is not.  So let's make the image relocatable if
    possible:
    
       The construct that is killing the relocatability is of the form:
    
    static long some_variable;
    static long *ptr_to_variable = &some_variable;
    
       In the above example, the pointer variable (supposedly static) is
    initialized (by the linker) to point to a variable.  The linker does
    not seem to know how to make it relocatable and initialize it also.  It
    gives up and makes your image non-relocatable so that it can initialize
    the pointer variable.  That is what the errors mentioned in .9 mean.
    
       The fix is to perform initialization of pointer variables in code,
    not in the link operation (initialization of static variables).  The
    MAKE_VS_DESCRIP macro described above is in violation of this rule.  An
    enhancement to the initialization routine for your AM would be a possible
    fix. Note that this fix REQUIRES changes in the management module code
    (boy, this MCC stuff sure is nasty!!).
    
       It looks as though some changes will have to made in the AM to get
    it to enroll.  Choose your poison based on what is easier for your AM.
    Good luck.
    
       Ted Hupper

>       The construct that is killing the relocatability is of the form:
>    
>    static long some_variable;
>    static long *ptr_to_variable = &some_variable;
>    
>       In the above example, the pointer variable (supposedly static) is
>    initialized (by the linker) to point to a variable.  The linker does
>    not seem to know how to make it relocatable and initialize it also.  It
>    gives up and makes your image non-relocatable so that it can initialize
>    the pointer variable.  That is what the errors mentioned in .9 mean.
 
I don't think the above is correct.  To illustrate, if you make a .c with just 
the two example definitions, compile it and link it /SHARE, the linker happily
produces a shareable image.  If remove the "static" from the second declaration, 
you get the following error:

%LINK-I-BASDUERRS, basing image due to errors in relocatable references
%LINK-W-ADRWRTDAT, address data in shareable writeable section
        in psect PTR_TO_VARIABLE offset %X00000000
        in module x file y

The problem is the PSECT generated by the [EXTERN] storage class is
marked SHR, but the  &descrip_name.counted_string in your macro (and the
&some_variable in the example definitions) generates the equivalent of a 
.ADDRESS assembler directive, which is not allowed in a SHR PSECT.  Using 
the STATIC storage class will make the PSECT NOSHR and the .ADDRESS will
then work fine.

>       The fix is to perform initialization of pointer variables in code,
>    not in the link operation (initialization of static variables).  The
>    MAKE_VS_DESCRIP macro described above is in violation of this rule.  An
>    enhancement to the initialization routine for your AM would be a possible
>    fix. Note that this fix REQUIRES changes in the management module code
>    (boy, this MCC stuff sure is nasty!!).
 
Before you do that, just try using the STATIC storage class.  That will make
the psect NOSHR and should get rid of the ADRWRTDAT error.

regards,

Pete

    RE:.*
    
    Yes, Pete and Roy, changing something declared as [extern] int to just
    static int, should be good enough, you don't have to declare it as
    static noshare int (although I could swear that bit me one time).
           ^^^^^^^
    
    RE:.11
    
    Why don't you try changing the module to use a
    
    static MAKE_VS_DESCRIP (current_node,MGMT_K_MAX_NODE_SIZE,"");   /* For ^c */
    
    and give it a try?   It should at least link cleanly.  If you get an
    error when you try to install, saying it is a writable sharable image,
    you will know that Ted was right (or Pete was right if it's readonly).
    
    -Matt.

	re .9:

> I figure if I am the only one using   
> MCC then the code will not run multiple threads.  Please correct 
> me if I am wrong.)                                               

	You are wrong.  There is no way to control the number of threads
	executing your AM once you are part of an mcc system.  For instance, 
	the user can create several alarm rules that eventually call your AM.

	Mike

    Not to be a spoiler, but...
    
    Are you sure it isn't easier to have your application (I assume
    it's fully functional/already exists) run as a detached process
    and just write an AM that talks to it?

    I haven't seen much existing code that lends itself to running
    in the DECmcc environment...    

RE: .12 & 15
------------
Pete, I made the changes you suggested in <.12> for all the structures 
without a storage class, viz., 

>> static MAKE_VS_DESCRIP (current_node,MGMT_K_MAX_NODE_SIZE,"");   /* For ^c */
>> ^^^^^^

PRESTO! My problem went away!!!  So what Roy described in <.8> seemed to
be causing the problem for me.  I am new to C data structure attributes,
so <.12> and <.15> really helped.  Since these are fundamental issues 
with shareable images and multi-threading, I hope documentation (such as 
the SRM and TOOLKIT) covers them for languages, particularly C.

RE: .16
-------
>> For instance,
>> the user can create several alarm rules that eventually call your AM.

Mike, I think I wasn't quite clear on the MCC test environment I am
using.  This is a vanilla MCC-installed workstation.  The only 
additional AM enrolled is mine, the TRADE_AM test prototype, which does
have AST's and SYS$QIO's.  I am the only user; no other MCC monitoring,
and no alarms.  Do you think the AST's and SYS$QIO's are going to cause
a problem for this testing?

RE: .17
-------

>>  Are you sure it isn't easier to have your application (I assume
>>  it's fully functional/already exists) run as a detached process
>>  and just write an AM that talks to it?
    
Chris, the two components of my application (a V1.0 product) that 
relate to the migration to DECmcc are the control program (TRADECP) and 
the detached server (TRADE$MGMT) - just like NCP (or MCC) and NETACP/NML.  
The prototype AM I am developing translates the command and forwards the 
request to the server for a response - just like SAMPLE_AM.  The 
forwarding part -  from TRADECP - is what I am having difficulty 
interfacing with MCC.  This exercise is solely for the purpose of proving 
the concept, so I'd like to use as much existing code as possible.


Muhammad

	Oh.  If this is just a breadboard it's fine.