Conference azur::mcc

    By the way, my process quotas are as foolows:

Maxjobs:         0    Fillm:       100    Bytlm:        40000
Maxacctjobs:     0    Shrfillm:      0    Pbytlm:           0
Maxdetach:       0    BIOlm:        40    JTquota:       4096
Prclm:          20    DIOlm:        48    WSdef:          512
Prio:            4    ASTlm:       100    WSquo:         3000
Queprio:         0    TQElm:       128    WSextent:     10000
CPU:        (none)    Enqlm:       600    Pgflquo:      50000
    
          /Nils

    Still have the problem...
    
    Aren't there anyone who have had this kind of problem before and has
    any clues on what to look for.
    What SYSGEN-params is needed.  Are there any logical
    (MCC_ICONIC_MAP_PM_LOG ?) to set so that I get some more info.
    
    The errormessage is:
    %SYSTEM-F-ACCVIO, ..., reason code=00, virtual address=00000100, 
      PC=00011F25, PSL=0BC00000
    
    Show calls in the debugger tells me that it's the VXC-RTL that accvios
    called from SHARE$MCC_ICONIC_MAP_PM.  Don't know what routine in there,
    because SET IMAGE doesn't work with the IMPM (no symbol table).  There
    are 5 call-frames  between VAXC-RTL and the routine
    MCC_INVOKE_PRESENTATION in the module MCC_KERNEL_PRESENTATION.
    
    What can I do?  
       Help!
    
            /Nils

          I give up!!!
    
    [* flame on *]
    
    ARE THERE ANYONE READING THIS NOTESFILE?
    
    No answers on this topic.  Has the IMPM-responsible persons quit
    DIGITAL or what....?  Usually we see replys very quick, but not this
    time...
    
    [* flame off *]
    
    Again, are there any logicals to define to get some more
    info on what's going on with the Iconic Map PM?

    Now, after running out on ideas on what to do I reinstalled the whole
    VS3100 from scratch. VMS v5.4 + DECWindows, VAX-C, DNS v1.1 and DECmcc
    BMS v1.1. Everything installed from July-91 CD-distribution.

    The [MCC]-directory is on a separate disk than the  system-disk. 
    Everything looks fine; the mcc-IVP runs OK, DNS-directories are setup. 
    Process-quotas set up according  to rel-notes.

    Still, I can't run the Iconic Map PM! It crashes with an ACC-VIO.

    I'm running on a standalone WS with no connections to any networks, 
    (DECnet is running). 16 MB memory, Systemdisk on a RZ23 with pagefile
    (45000 blocks) and swap-file on another RZ23.  [MCC]-dir and 
    [DNS$SERVER]-dir on a RZ55   (it's not my disk, so I can't use it as 
    systemdisk wich would be the normal...)


    Anyone who has any clues on what to do/look for/change/setup/..../


    regards,
 Nils
 

    
    Did you try, giving your MCC account quotas a big increase, specially
    BYTLM, try doubling it from 40K to 80K.
    
    Also, it can't hurt to make sure of the following:
    
    You are running standalone VMS. You do have DECnet setup as a regular
    node anyway, right ?  With all default accesses, objects, and so on.
    
    Another thing to check, is the DNS access priviledges. Do the objects
    and directories give access to the account running DECmcc,...
    
    	Gil

What are you mcc_maps, mcc_uil, mcc_icons, decw$user_defaults logicals
set to?

What are the protections on mcc_icons:*icon.dat files?

Is anything printed on the terminal before it craps out?

Fred

    I have seen this kind of think when I didn't have access to all the
    files in MCC_COMMON:
    
    s/rob

    repl .5
    
>>> What are you mcc_maps, mcc_uil, mcc_icons, decw$user_defaults logicals
>>> set to?
    
    mcc-logicals points to MCC_COMMON (= RZ55:<MCC>)
    decw$user_defaults points  to SYS$LOGIN
    
>>> What are the protections on mcc_icons:*icon.dat files?
    It shouldn't have anything to do with protection on files. 
    I try it from the SYSTEM-account with all all privs.
    
>>> Is anything printed on the terminal before it craps out?
    NO, just ACCESS VIOLATION...
    
       /Nils

    repl .6
    
    It shouldn't have to have anything to do with protection on files.
    I tried to run with all privs enabled.
    
       /Nils

Allow me to ask the question again...What are the protections of the files
set to?

Fred

    repl .4
    
>>> Did you try, giving your MCC account quotas a big increase, specially
>>> BYTLM, try doubling it from 40K to 80K.
    Yes, no change.
    
>>> You are running standalone VMS. You do have DECnet setup as a regular
>>> node anyway, right ?  
    YES!
    
>>> With all default accesses, objects, and so on.    
    I guess so; It's a default VMS- DECnet- DECwindows installation. 
    Nothing special.  What accesses, objects is needed?
    $MC NCP SHOW KNOWN OBJECT   gives $IPCACP, $MOM, $NICONFIG,
    MCC_DNA4_EVL, SMISERVER, TASK, X$X0, FAL, HLD, NML, REMACP, MIRROR,
    EVL, MAIL, PHONE, CTERM, DNS$TA, DNS$BACK, VPM, DTR. 
    Anything missing?
    
    
>>> Another thing to check, is the DNS access priviledges. Do the objects
>>> and directories give access to the account running DECmcc,...
    As I understand it, default installation of DNS gives all users all
    access to all objects.  Right?  
    $ MC DNS$CONTROL SHOW ACCESS on all directories gives me all access
    as well as on all objects.
    
    
    /Nils

    repl .9
    
    all files in MCC_COMMON have the protection (RWED, RWED, RWED, RE)
    except for:  
    MCC_DEFINITION.DAT, MCC_DICTIONARY.DAT, MCC_DISPATCH_TABLE.DAT,
    MCC_META_DEFINITION.DAT, MCC_META_DICTIONARY.DAT,
    MCC_MIR_ATTRIBUTE.DAT, MCC_MIR_DIRECTORY.DAT, MCC_PTB_PARSER.BPT 
    which have  (RWED, RWED, RWED, R)
    
    /nils

    I've run the AUDIT_MCC.COM-procedure and it says that the
    sysgen-parameter PAGEFILE_PAGE is 30992 and should be >= 120000.
    I don't recognize that SYSGEN-parameter.  I created one more pagefile
    on the RZ55-disk, 120000 blocks, and no more complaints about
    PAGEFILE_PAGE.  Shouldn't the text say "PAGEFILE-SIZE instead of
    PAGEFILE_PAGE" (but that's another story...)?
    
    It also says that RDB is not started.  Is that a requirement?  If so, I
    missed it in the rel-notes as well as in the install-guide.  Is that
    the problem, or is RDB only needed for the exporter-fm?
    
    I'm also told that 16Mb is not adaquate to run DECmcc, but I guess
    that's just a performance issue; I guess that lack of memory can't 
    cause the ACC-VIO.
    
    After speaking with Jill Callander today (thanks Jill for your time)
    she suggested to try running DECWRITE to test a 'heavy'
    DECwindows-application to see if the problem could have anything to do
    with VMS/DECwindows not properly setup.  Sorry to say, DECWRITE works
    really well, but still ACC-VIO on IMPM.
    
    What else can I do?
    
    I guess I could need some help from above now...
    
         /nils

    Thanks for bug report on Audit_MCC. I agree and have updated the
    proceedure to indicate that it is Pagefile Size that needs increasing.
    Also, I updated the text around the RDB startup and memory size.
    
    s/rob
    

    Nils,
    
    I really don't have much in the way of ideas, my last attempt 
    at this would be to try running the same sequence of events that
    the IM PM does at start up from the FCL.
    
    Unluckily, since you are a clean installation that really amounts
    to doing just about nothing, except accessing the dictionary to
    setup some of the menu items.
    
    There have ben so many notes here, did you say that the FCL
    worked alright? also have you tried the FCL forms mode that
    requires more memory as well. 
    
    Now note that insufficient memory in the system can actually
    cause an accvio if the kernel is unable to load the image into
    memory. We try to handle all cases where insufficient memory can
    be returned but sometimes these get missed and cause an accvio.
    You see I don't know of anyone running with only the 16meg of
    memory. Is anyone out thee doing it? and did you have to do anything
    special to get it started?
    
    For now, do a quick test of some commands on the domains and
    registration FM to see if things work okay there. (IM PM uses
    these modules at startup). Attempt to show domain * all ident, and
    try to register anything.
    
    jill
    

    repl .14
>>> did you say that the FCL worked alright? also have you tried the
>>> FCL forms mode that requires more memory as well.
    
    YES and YES.


>>> Now note that insufficient memory in the system can actually
>>> cause an accvio if the kernel is unable to load the image into
>>> memory. We try to handle all cases where insufficient memory can
>>> be returned but sometimes these get missed and cause an accvio.
>>> You see I don't know of anyone running with only the 16meg of
>>> memory. Is anyone out thee doing it? and did you have to do anything
>>> special to get it started?

    To get what started? I haven't done anything specail to get anything
    started, except that IMPM isn't starting, but that you all know by now.
    I tried at the bank to run IMPM at a 16Mb B/W VS3100 (satelite in a
    cluster) and it worked OK.

>>>  Attempt to show domain * all ident

     Works OK.

>>> and try to register anything.

    Hmmm...  This is what I do:  (I'm not very good at using FCL, I've done
    all the registering with the IMPM, so maybe I do something wrong)
    
    MCC> regi node4 .dna_node.knutte       ! KNUTTE is the name of this node
    SYNONYM = KNUTTE
    
    Node4 KNUTTE_NS:.dna_node.knutte
    AT  9-SEP-1991 19:59:43
    
    The requested operation cannot be completed
       MCC Unhandled Service Reply = Internal error in DECnet Phase IV AM.
    
    Here I do a CREATE OBJECT .DNA_NODE.KNUTTE with DNS$CONTROL 
    
    MCC> regi node4 .dna_node.knutte
    SYNONYM = KNUTTE
    
    Node4 KNUTTE_NS:.dna_node.knutte
    AT  9-SEP-1991 20:00:17
    
    The requested operation cannot be completed
        MCC Unhandled Service Reply = Internal error in DECnet Phase IV AM.
    MCC> dir node4 .dna_node.knutte
    
    Node4 KNUTTE_NS:.dna_node.knutte
    AT  9-SEP-1991 20:08:36
    
    Directory successful.
                            Registered Name = KNUTTE_NS:.dna_node.knutte

    MCC> show node4 knutte all ident
    
    Node4 62.146
    AT  9-SEP-1991 20:18:02 Identifiers
    
    Examination of Attributes shows:
                                    Address = 62.146
                                       Name = KNUTTE
    
    MCC> deregi node4 .dna_node.knutte
    
    Node4 KNUTTE_NS:.dna_node.knutte
    AT  9-SEP-1991 20:19:36
    
    The requested operation cannot be completed
          MCC Unhandled Service Reply = Internal error in DECnet Phase IV AM.       
    
    Looking with DNS$CONTROL the node is still there. 
    
    I don't understand anything no more....
    
    
         Any help is very much appreciated....
    /nils

    >You see I don't know of anyone running with only the 16meg of
    >memory. Is anyone out thee doing it? and did you have to do anything
    >special to get it started?

    I've installed ssb 1.1 and applied all the patches on 16 mb 3100s
    and all was fine.

    Just a WAG but did you say VS3100 or WS3100?

    Bill
    

    repl .16
    
>>> Just a WAG but did you say VS3100 or WS3100?
    
    $ write sys$output f$getsyi("HW_NAME")   ==>   VAXstation 3100/GPX
    
    
        /Nils

    Try increasing your Pgflquo to 100000.  Also make sure your sysgen
    parameter VIRTUALPAGECNT is greater than your Pgflquo value.
    
    -Matt.

    
    Nils has the logical MCC_COMMON defined as disk:<MCC_COMMON>, and
    Iconic Map is expecting disk:[MCC_COMMON].  So, that's why it
    acc-vio'd when it's parsing the icon files spec.
    
    Solution for now: Change MCC_COMMON to disk:[MCC_COMMON] (and don't
    		      forget to change SYS$STARTUP:MCC_LOGICAL_DIR.COM.
    
    Solution for future:  Iconic map will be fixed to handle both cases.
    
    \david.

    Finally I found the bug.  
    
    When looking for mcc_*_icon.dat-files the IMPM scans in the full
    filename for a ']', like in "DISK1:[MCC]MCC_BRIDGE_ICON.DAT;1" to find
    the start of the name itself.  Well the problem is if MCC_COMMON is
    defined as DISK1:<MCC>  (which it is in my installation).  The full
    filename would be DISK1:<MCC>MCC_BRIDGE_ICON.DAT;1 and no beginning is
    found ==> ACC-VIO.
    
    To verify my thaughts, I redefined MCC_COMMON to be DISK1:[MCC] and
    guess what:
    
                I T   W O R K S !!!!!
    
       
        Thanks everyone, especially DAVID WONG, for all sugestions and
    help.  It's nice to know you're out there.
    
               /Nils
    

    Hmmm, wouldn't it be easier to use the VMS System Service to parse the
    filename and return the part wanted? There must be a system call which
    is equivilent to the DCL Lexical F$PARSE.
    
    s/rob