Conference azur::mcc

    No news on turning off functions - but logging should be possible.  The
    DECpresent/DECwrite applications have journaling, which has an amazing
    amount of detail around what one did with the mouse and menu
    selections.  While not a V1.2 issue, it should be considered for future
    versions.
    
    bill

RE: .0

Andrew,

I've occaisionally considered doing things differently in my AM depending
on which PM was talkin' to the user. You can't tell, they did the form/function
split correctly.

But if you are willing to consider a modified UID file for the Iconic PM,
consider a modified dictionary. Using searchlists you can cause certain
accounts to run against a dictionary in which there aren't any of the 
directives you want to avoid. If they aren't in the dictionary, the Iconic
PM won't put them in the operations menu / toolbox.

You can put ACLs on the PM shared images, so that the account that sees
the readonly dictionary can only use the Iconic, and the audited account
can only use FCL.

    Hi,
    
    	Firstly, thanks for the quick replies. The news of DECwindows
    logging progress is good as we are having problems with all our
    DECwindows-based proposals.
    
    	Richard, I am looking at what you have suggested. To confirm, if I
    can modify the dictionary (presumably using DAP) to remove or disable
    the directives I don't like then they won't appear on the iconic map
    UI. (Have I got this right?)
    
    	Working from there. How do I get rid of the directives. Notes 967
    and 385 seem to indicate that maybe I can get creative with this
    undocumented DELETE command in the DAP. Certainly I don't want to have
    to build a new 24,000 block dictionary from a dump of the current file.
    Is this the best way to go? (I will try some more testing tonight but
    any headstarts I can get from more experienced dictionary players would
    be much appreciated.)
    
    thanks,
    Andrew

>    Richard, I am looking at what you have suggested. To confirm, if I
>    can modify the dictionary (presumably using DAP) to remove or disable
>    the directives I don't like then they won't appear on the iconic map
>    UI. (Have I got this right?)

Andrew, notice that the folks that support the PMs are wisely
avoiding this hacker's discussion, so take anything I tell you with a
block of salt. But what you want to do is set the dictionary up so
that it looks like the directives you want to hide were specified
in the MSL with DISPLAY = FALSE. The ICONIC PM won't list them in the
operations box then, but other AMs and FMs can still use them.

When in doubt as to how to set such a value, I let the MSL compiler
tell me. Write a simple MSL with a directive and compile it, save the .COM
file produced. That is the DAP commands used to set the dictionary entries.
Now change the MSL to make the directive DISPLAY=FALSE, compile it again,
and compare.

Build yourself a command file to do that for some directives on the entries
you want to change, and give it a try on a local copy of the dictionary.
Remember to copy all 4 of the dictionary files as a unit.

To further test your resolve, I'll remind you that having a dictionary out
of sync with AMs and FMs is one of the most aggravating problems you
can get, mostly because it can manifest itself in a subtle manner. I doubt
such a change is supported, and the MCC folks in this conference know who
you are now, so don't be surprised if they ask you to reproduce any problem
you report on a stock dictionary before they expend much time on it. This
could leave your customer in an unsupported state for their "readonly"
configurations.

What might be best is to try it, and if it works pursue a way of doing it
in a supported manner.

    Rich, boy you hit the nose on the head, yes I admit I was avoiding
    this, but just to state for the record, what you are saying will
    work, and no I am not conding it since it is a hack (but a nice
    one at that). By the way PTB in V1.1 ignores the display field
    for verbs, but this IS fixed in v1.2 so...build your parse tables
    then set the verbs to display=false. As long as it is in the parse
    tables (.bpt) the fcl will continue to allow the directives to pass
    and the iconic map will check the dictionary and they will fail...
    
    just beware of the iconic map special verbs lke delete and deregister
    I don't know all of the details around how they will react. Verna
    said she would try to look into it.
    
    jill
    

>>    Rich, boy you hit the nose on the head, yes I admit I was avoiding

	Jill, 

	Are implying that Rich has a pimple on his nose?
	
	/doug

	  8^)    8^)   8^)   8^) 

(Apologies for wasting the bandwidth/disk but I just couldn't stop myself...)

    Hi,
    
    	re .4 - I think I already have a bit of a reputation with the
    developers anyway --- but now I'm a responsible person.
    
    	The modification (not a hack - responsible people don't do that)
    seems to work well. I have to play around a bit but that was due to my
    lack of understanding of how to do things.
    
    	It now seems that I can run the DAP (the toolkit) on a separate
    copy of the dictionary (4 files as you said) and just:
    
    DAP> USE CLASS TERMINAL_SERVER DIRECTIVE TEST
    DAP> SET DEFINITION DISPLAY TYPE BU LENGTH 1 COUNT 1 CLASS 1 VALUE 0
    
    	and whacko the TEST option on the TS pulldown disappears.
    
    	This is particularly nice as this SET seems to be undocumented
    (although it follows fairly logically from the UPDATE .COM file) and it
    means I don't need .COM or .MS files (and its quick). Now I'll just
    have to find a minion to work through all the "change" type directives.
    
    PROBLEM:
    
    	As mentioned in .5 the REGISTER, DELETE, etc directives seem to be
    pretty special - disabling display certainly doesnt drop them out of
    the toolbox (although register doesn't seem to work but delete does).
    My wish for this evening is to get hold of the UID file for the MCC
    iconic map so I can disable (desensitize) the toolbox option. I figure
    the toolbox is coming from the UIL so this should be feasable. PLEASE -
    this is really close to wonderfulness.
    
    Finally:
    
    	A not-so-urgent issue but related. Shouldn't this sort of capacity
    (functional limitation within a domain) be possible as a standard
    feature. I appreciate that maybe I can do this using appropriate
    security and ACL's but I suspect that these would not be discrete
    enough for most user's needs.
    
    regards and thanks,
    Andrew
    
    p.s. Tony Chance (a partner in crime ahem tailoring) has observed that
    my personal name may indicate (to British people or students of
    history) all sorts of things. The reference to Wellington is to the
    town in New Zealand which is renowned the world over for its
    excuriating excitement (especially when the power is on).

>    My wish for this evening is to get hold of the UID file for the MCC
>    iconic map so I can disable (desensitize) the toolbox option. I figure
>    the toolbox is coming from the UIL so this should be feasable. PLEASE -
>    this is really close to wonderfulness.
  

  Responsible person, :>

  The toolbox is not created via UIL.

  Fred

    But the Edit/Toolbox menu item is in the UIL.  Or do we also have
    code scattered everywhere that sensitizes/desensitizes this menu item,
    so that it's not just in the UIL?
    
    Christine
    

...Yes

    re .8 - .10
    
    Guys,
    
    	I'm on the wire here. Is the message you are giving me that
    the DELETE, REGISTER, ERASE, etc directives cannot be disabled? I find
    this a bit hard to believe. What is the point in having so-called
    security domains if you can't ...
    
    	Thinks....
    
    	I'll try going back to glungy old file security to set the map file
    to read-only and then try to set the DNS stuff to read-only too. I
    guess all that toolbox stuff only changes those (yes/no?) and you have
    to use OPERATIONS-type directives to effect the network elements
    themselves.. (yes/no/maybe).
    
    	Yech. The thought of trying to apply security to DNS is a bit
    frightening. It is so good at locking me out without even trying to
    secure things...
    
    	Any final words on long-term plans here?
    
    	Also, .6 mentioned a wonderful person called Verna who was looking
    into the REGISTER and DELETE commands... any progress? If the glungy
    old security works that will be okay but it will probably look messy
    with options on the screen that don't work.
    
    thanks,
    Andrew

  Well I hate to say it but...   Having a read only map was not a 
goal for v1.1 or v1.2.    The functionality you are asking for falls under
the v2.0 task for making the iconic map more user customizable.  That is, the
user (and system manager) wants to do things like


	- Disable the toolbox

	- Disable navigation

	- display specific directives/groups in operations menu in
	  a specific order.

	- display specific attributes within a group in user defined 
          location.

	- display specific entity classes in the toolbox.

	- etc... 

  Now the toolbox operations you want to shut off are the ADD operation
(REGISTER, CREATE, SET REFERENCE, and CREATE DOMAIN MEMBER) and the 
DELETE operation (DELETE, DEREGISTER, and DELETE DOMAIN MEMBER).  
To do this you can protect the DNS object representing the 

	- entity 
	- domain to which it is a member.  

You can also protect the DNS directory so objects can't be created in it.

/Jim

    re .12
    
    Jim,
    
    	Its good news that this functionality is planned for some stage in
    the future. I believe it is an important element of the domains
    concept. I found the DNS security stuff yesterday and used it to secure
    the register, deregister, etc functions (I figure the toolbox primarily
    touches DNS and the map - the map isn't that critical).
    
    	So it looks like a combination of the mods to the dictionary plus
    DNS security will be sufficient although there seems to be some
    inconsistency in the messages I get when DNS stops
    registration/deregistration of nodes. Right now no big deal.
    
    	For anyone interested in doing something similar the dictionary
    mods involve:
    
    1) Make a copy of the 4 dictionary files (MCC_DICTIONARY,
    MCC_DEFINITION, MCC_MIR_ATTRIBUTE and MCC_MIR_?? ENTITIES maybe - its
    in the doc somewhere).
    
    2) Define MCC_COMMON to be a search list pointing to the new directory
    and the standard MCC_COMMON
    
    3) Run MANAG/TOOL/DICT and do things like..
    
    USE CLASS TERMINAL_SERVER
    USE DIRECTIVE SET
    SET DEFINTION DISPLAY TYPE BU LENGTH 1 COUNT 1 CLASS 1 VALUE 0
    ...
    
    4) Set security on the MCC directories and entities so thatthe
    read-only user has READ (and no other) access to MCC objects and
    directories (incl DEFAULT flag). Use the DNS$CONTROL ADD ACCESS command
    for this stuff.
    
    regards,
    Andrew

Better late than never,


Just to recap the last few messages:

	In V1.2, the Iconic Map does not allow user customization of
	verbs like add, delete, deregister, register, create.  They 
	are special-cased out of the Operations menu, but are handled
	behind the scene when the user does toolbox actions.  

	As Jim Lemmon mentioned, we hope to have more user customization
	capabilities in V2.0.

Verna

    Verna,
    
    	Just to make sure of what I understand. The verbs you mentioned
    basically manipulate DNS objects so if I protect the directories and
    objects from being manipulated thay will just fail from the toolbox
    (mostly with a DNS-nopriv type of error although some AMs seem to to
    handle the DNS security differently). Whatever the error, the
    add/register/deregister/delete/etc should fail (even if a little messy
    on the screen) to change anything.
    
    	Is this correct?
    
    	Also, are you saying that we will still be able to set other 
    directives as DISPLAY=FALSE under V1.2?
    
    thanks,
    Andrew

Andrew,

If the directive isn't one which we special-case, we DO check the DISPLAY 
definition.  If true, we put into the menu; if false, we do not.

As far as DNS behavior goes, I am not an expert there.  Any comments?  We do not put certain
verbs into the menu, but handle them thru icons in the toolbox.

Verna