Conference azur::mcc

    I think the problem is that your .exe is not installed in SYS$SHARE.
    MCC requires all shareable images (AMs, ...) to be installed in order
    to "find" them.
    To install ->
    INSTALL ADD file-spec /SHARED/HEADER
    
    Note: I'm not sure whether you need /HEADER or /NOHEADER. I can't
    remember which one I used. 
    
    Also make sure your file-spec includes the drive.
    Good-luck!
    				Cindy
    
    
    P.S. As far as ptb and dap are concerned, if you justed added your msls
    to the data dictionary (in other words, you compiled them using the msl
    compiler and then used dap to include them into the dictionary), you
    will need to run ptb. Otherwise, your commands won't parse.

    
    Cindy,
    
    Based on the discussion in 134.*, I fixed the write/share attributes of
    PSECTS.  So, I never needed to "INSTALL ADD file" my AM before I 
    "installed" the new version of MCC.  I haven't made any changes to the
    AM.
    
    Anyway I tried what you suggest in .1, but that didn't help!
    
    ================================================================
    
PENNI $ INSTALL add/share/header sys$library:mcc_trade_am
PENNI $ MANAGE/ENTER enroll mcc_trade_am mcc_trade_am
DECmcc (T1.0.1)

%RMS-E-FNF, file not found
PENNI $

    
    Interesting problem, have you resolved it yet?
    
    

The MCC installation procedure for your shareable image would be:

	0. (Before vmsinstal:  delete sys$specific:[syslib]mcc_trade_am.exe;*

	1. Deassign the file name (mcc_trade_am) from all tables
	2. copy the image to sys$common:[syslib]mcc_trade_am.exe
	3. if the image were already known, then
		install delete sys$share:mcc_trade_am.exe
	4. install add sys$share:mcc_trade_am.exe /header/share
	5. purge older versions
	6. manage/enterprise enroll mcc_trade_am



Note that the enrollment routine uses LIB$FIND_IMAGE_SYMBOL
to activate the shared image.  Check the VMS manual for
the description of its use and exception conditons.

Pete Burgess

    one more thing, when you linked it you did a
    LINK/SHARE=mcc_trade_am.exe?
    

    
    RE: .3
    
    The problem still exists!
    
    RE: .4
    
    I need to elaborate the statement I made in .2 about not having made
    any changes to the AM between V1.0 IFT and V1.1 IFT.  Because I did
    make one (small) change.
    
    The original AM image was named MCC$TRADE_AM.  It was located in a
    private directory (i.e., not in SYS$SHARE:), and worked like a champ
    through the logical MCC$TRADE_AM without INSTALLing it shared, based
    on discussions in another topic.
    
    When V1.1 IFT came along, I did make one change to the AM! I thought
    I'll follow your footsteps through the migration plans to the
    "greener" pastures of Ultrix.  I renamed the file from MCC$TRADE_AM
    to MCC_TRADE_AM.
    
    I have used both methods, viz., copying to SYS$SHARE and using logical
    MCC_TRADE_AM.  But either way it failed.
    
    I renamed the file back to MCC$TRADE_AM, and tried the two methods
    again.  But the problem persists:
    
    ----------------------------------------------------------
    PENNI $ d sys$share:mcc$trade_am.exe
    
    Directory SYS$SYSROOT:[SYSLIB]
    
    MCC$TRADE_AM.EXE;1      595   4-JUL-1990 12:28:54.00
    
    Total of 1 file, 595 blocks.
    PENNI $ shl mcc$trade_am
    %SHOW-S-NOTRAN, no translation for logical name MCC$TRADE_AM
    PENNI $ reca mana
    PENNI $ MANAGE/ENTER enroll mcc$trade_am mcc$trade_am
    DECmcc (T1.0.1)
    
    %RMS-E-FNF, file not found
    PENNI $
    ****************************
    PENNI $ define MCC$TRADE_AM     SLR:[MCC.TRADE]MCC$TRADE_AM.EXE
    PENNI $ d mcc$trade_am
    
    Directory SLR:[MCC.TRADE]
    
    MCC$TRADE_AM.EXE;1      595   4-JUL-1990 12:28:54.00
    
    Total of 1 file, 595 blocks.
    PENNI $ MANAGE/ENTER enroll mcc$trade_am mcc$trade_am
    DECmcc (T1.0.1)
    
    %RMS-E-FNF, file not found
    PENNI $
    ----------------------------------------------------------
    
    RE: .5
    
    I used MCC$TRADE_AM_AUTO_MAKE.COM, a procedure based on one that's part
    of the SAMPLE AM.  The LINK command in the procedure is:
    
    $ link /map MCC$TRADE_AM_OPTIONS.OPT /options /share=MCC$TRADE_AM.EXE
    
    Any other ideas?
    
    Muhammad

    
    Another thing to check when you changed the .exe name, if you changed
    your entry points, which I assume you did, you also needed to change
    the "UNIVERSAL = " to use the new _ name.
    
     

    Is your MCC$TRADE_AM image linked against any other shareable images
    that might actually be the culprit?  Our enroll mechanism is built on
    top of the standard VMS image activation, so if a required shareable
    image is missing, the "file not found" CVR is the result.  As we cannot
    signal (out-of-band writing to the screen is illegal for us) the name
    of the file that is missing, we cannot return any more information
    other than "a required image is not found".
    
       Ted

Re: 210.6
    
�    When V1.1 IFT came along, I did make one change to the AM! I thought
�    I'll follow your footsteps through the migration plans to the
�    "greener" pastures of Ultrix.  I renamed the file from MCC$TRADE_AM
�    to MCC_TRADE_AM.

    In other words, your AM was linked with the previous toolkit, so
    against  MCC$KERNEL_SHR.EXE.
    
    You need to relink with MCC_KERNEL_SHR.EXE .... and so do a
    Substitute/ALL of MCC$ to MCC_ in *ALL* your source files.
    
    I had a similar porblem, it's on it's way to being solved :-)
    
    Amicalement,
    
    Philippe.

    RE: .9, .8
    
    If you only renamed the MCC$TRADE_AM.EXE to MCC_TRADE_AM.EXE, the image
    activation of this file is looking for the MCC$KERNEL_SHR.EXE shareable
    image and can't find it, as mentioned in the .8 reply.
    
    Do what the .9 reply says and your image will enroll successfully. 
    Sorry about all the problems from our name changing.
    
    Ted

    Hello, 
    
    One small point to watch out for :
    
    Substitute/ all of  MCC$ to MCC_ is NOT the only thing to do, as
    symbol definitions sur as MCC$_NORMAL then get modified MCC__NORMAL.
  
    Status etc.. symbol names have been changed to MCC_S_<whatever>
    
    By the way, can anyone explain why all symbols, routines, CVR's
    etc have been renamed ? (Note : this is NOT a <flame on>, I'm just
    curious) :-)
    
    Philippe. 

    It was done so the programming interface to MCC would be identical
    on VMS and Ultrix.  

    and....
    cos $ is not allowed in Ansi C
    
    (no jokes please)
    
    Colin

    
After having been interrupted by another task, I am back into the pits
[:-)], struggling to get my AM (that was working fine with the earlier
version) back on its feet again!!!

The name change (plus the other changes) is really causing a
heartburn.  I couldn't just substitute every occurrence of "MCC$" prefix 
to "MCC_" because only the routine names have changed, not the symbol and
constant defintions.  Anyway after painstakingly going through the 
substitution process, I have been able to enroll my AM successfully!

The problem I am now having is with MANAGE/TOOLKIT/SPECing the .MS file.  
It compiled successfully with the earlier version.  I fixed initial
complaints from the new compiler by replacing SUBORDINATE with CHILD and 
changing "()" to "( )".  Now MSL is complaing about some missing PRIMARY 
DNS IDENTIFIER, as shown in the log below.

=========================================================================
$   manage/toolkit/spec MCC$TRADE_AM_SVC_INTERFACE.MS /lang=(cc,macro,pascal)
MCC Management Specification Language Translation Tool
               Version T1.0.1

%MCCMSL-E-MISDNSPNAME, ENTITY trade, is missing a PRIMARY DNS IDENTIFIER
%MCCMSL-I-CHKERRORFILE, Check error file for possible unmatched text
%MCCMSL-E-NOT_COMPLETE, MS file scan did not complete successfully
$
=========================================================================

Any ideas what it is complaining about?

Muhammad

    A quick overview of the change will help.
    
    Problem: The parsing of entity instances needs to know what identifiers
             are valid, and in what order to attempt to parse. This
             order is specified in the IDENTIFIERS field of the entity
             description in the MSL
    
             But, since the identifiers field is used for parsing, fullname
             tended to always be listed as the last item in the list
             (since full name is quite robust in its' input format, it
             can take on the form of almost any other data type). This 
             lead to problems with the registration FM which needed to
             know which identifier was the primary identifier (the one
             with the fullname data type).
    
    To solve this problem a new field was added to the attribute
    definitions so that you could specify for each identifier attribute
    which ones were the dns primary and secondary (alternate) identifiers.
    
    An example is:
    
    goste::goste$ search MCC_DNA4_AM_NODE4_SVC_IF.MS dns_ident/window=7
    
            ATTRIBUTE Name = 1 : Phase4Name
               ACCESS = NONSETABLE,
               DISPLAY = TRUE,
               DNS_IDENT = ALTERNATE_NAME,
               CATEGORIES = (CONFIGURATION),
               SYMBOL = DN4_NI_NODE_NAME,
               PRIVATE
    ***************
            ATTRIBUTE Address = 2 : Phase4Address
               ACCESS = NONSETABLE,
               DISPLAY = TRUE,
               DNS_IDENT = ALTERNATE_NAME,
               CATEGORIES = (CONFIGURATION),
               SYMBOL = DN4_NI_NODE_ADDR,
               PRIVATE
    ***************
            ATTRIBUTE Registered Name = 160 : FullName
               ACCESS = NONSETABLE,
               DISPLAY = TRUE,
               DNS_IDENT = PRIMARY_NAME,
               CATEGORIES = (CONFIGURATION),
               SYMBOL = DN4_NI_NODE_REG_NAME
            END ATTRIBUTE Registered Name;
    
    Interrupt

    

    
    <RE: .15>
    
    Jill,  thanks for the info.  Adding the DNS_IDENT field took care
    of that problem, and I have made some headway.
    
    The next problem I experienced is "undefined symbol" error.
    "Old" SAMPLE AM used the MCC$ILV_LIST_PUT routine.  I replaced that
    with MCC_ILV_LIST_PUT (just I did with others).  But it is still
    giving me the linker is still giving me the same error message.
    
    Is this routine obsolete or something?
    
    Muhammad

    
    That is an old routine. I am surprised you have gone this long
    without having hit this. The routines that replaced it were the
    mcc_ilv_put and mcc_ilv_put_cons routines. Check what you have in
    your SRM for documentation of these. If you don't have these then
    you didn't get the Feb 6th updates.
    
    jill
    

    
    I pulled these routines right out of the SAMPLE_AM source.  As a
    matter of fact, I used that as a template as much as I could.  I
    have updated my manual with the February 6 release.  It doesn't
    mention the MCC_ILV_PUT_LIST routine at all.  I tried simply
    changing the routine name from MCC_ILV_PUT_LIST to MCC_ILV_PUT.
    But I got the following error message when running MCC:
    
    --------------------------------------------------------------------
    MCC> show trade penni
    Using default ALL IDENTIFIERS
    %MCC-E-NOPARAMLIST, no parameter list was supplied in this ILV buffer
    MCC>
    --------------------------------------------------------------------
    
    So, I am not sure what else is involved in making the switch.
    
    BTW, I noticed that, after installing the latest version of MCC, 
    there are now three sets of sources in SYS$EXAMPLES:[.MCC]:
    
    (1)  MCC$SAMPLE_AM      (2)   MCC_SAMPLE       (3)  MCC_YOURMM
    
    Can you shed some light on how these three relate to each other?
    
    
    Muhammad

    
    
    MCC$SAMPLE_AM refers to the "old" SAMPLE AM source.  MCC_YOURMM is 
    foundation MM software designed to accelerate MM development--the "new"
    SAMPLE AM (same functionality yet totally rewritten) is built on using
    this foundation--called the design framework.  Take the time to print
    a copy of the new "Management Module Programming" which now contains two
    chapter's dedicated to the design framework.  
    
    Note that there was a lot of toolkit change for EFT Update--we tried to
    highlight the major areas in the release notes.  Many of the areas of
    trouble you have had were covered.  
    
    Please let us know if you find problems or errors in the "Management
    Module Programming" documentation.
    
    
    this
    
    

    
    It almost sounds like you are trying to do an ilv_put of a value
    before opening the construction. Since and attribute list (which
    is what you should be returning on a SHOW) is a constructed data
    type you need to do the put on the attribute list using the
    ilv_put_cons_begin and NOT the ilv_put routine. 
    
    What it comes down to is this:
    
    	o  use ilv_put_cons when you are putting in complex data such
	   as constructor or constructed datatypes (within the construction
           you can then put other construction or simple data)
    	o  use ilv_put when you are putting in simple data like numeric
           or string datatypes

    
    <RE: .19>
    
    I hope that all ducks are in a row as far as MCC's software
    development environment (Design Framework) is concerned 
    (;o` ;o` ;o` ;o`), now that V1.0 is about to be released.  I was sort
    of disappointed with the way the latest release clobbered my AM.  
    However I do understand that MCC, still being in field test, can be 
    can be expected to go through kinds of changes!  The release notes, 
    though covering the new features sufficiently, were not clear about 
    the changes required to get the MM's running again.
    
    Enough bad mouthing.  I have looked cursorily at the YOURMM code
    supplied with the kit, and it seems to have been organized much
    better (by functionality and modularity).  Having gone through the
    painful process of manually modifying SAMPLE_AM to create another 
    MM, I find the capability to do the same automagically through 
    MCC_YOURMM_AUTO_CREATE.COM very useful!
    
    <RE: 210.20>
    I did use the required sequence to construct the attribute list from 
    response data using ilv_put, as follows:
    
    ilv_put_param_begin()
        ilv_put_cons_begin()
           do n times
             ilv_put()
        ilv_put_cons_end()
    ilv_put_param_end()
    
    And this is the same code (apart from the mcc$ilv_put_list() to
    mcc_ilv_put() change) that worked with the earlier version.  So
    I don't understand why is it complaning now.
    
    
    Anyway, I really needed to get the AM running for a demo.  I 
    decided to back off and use the earlier expired version.  Thanks
    to Steve Wong, who provided a new PAK, I re-enabled that version
    and got going.
    
    So I am all set for now (until next release of MCC? ;-)  )
    
    Muhammad

    Another thing to note regarding the switch from the obsolete
    mcc_ilv_list_put to mcc_ilv_put_cons_begin:  the correct mode
    must be set.  Since you're trying to encode an attribute list,
    you should have set it to List mode when opening an ILV construction.
    
    Christine
    

    <RE: 210.22>
    
    Christine,
    
    I checked the mode used with mcc_ilv_put_cons_begin before calling 
    mcc_ilv_put.  It is set as:
    
    ----->>>    GenDesc.mcc$l_id = MCC$K_ARG_SHOW_VALUES;
    
    SRM talks about setting the mode to MCC$K_ILV_LIST_VALUE.  So I
    checked the defines in .h files and they matched:
    
    ----->>>    #define MCC$K_ARG_SHOW_VALUES 1
    ----->>>    #define MCC$K_ILV_LIST_VALUE 1
    
    
    It appears that if and when I need to get the AM going again, I'll
    have to roll up my sleeves and "dig" into TBD.
    
    Muhammad

    I'm not sure if I'm not understanding you, or you're not understanding
    me.  But what I meant by "mode" was not the mcc_l_id field of the
    descriptor, but rather the 5th argument to mcc_ilv_put_cons_begin,
    which you should set to MCC_K_ILV_LIST_VALUE.  Your mcc_l_id field
    is correct though.
    
    Check out page 339-341 in the SRM (pages should have an update date
    of Febrary 6, 1990 at the bottom).  There's an example of how to
    encode Attrib_list.
    
    Christine