| T.R | Title | User | Personal Name
 | Date | Lines | 
|---|
| 600.1 | About ALARMS | TOOK::ORENSTEIN |  | Wed Jan 09 1991 13:55 | 27 | 
|  |     Hi Philippe,
    
    Thank you for noting that the two FMs handle the use of files
    differently.  I will look into trying to make things a little
    more consistent.
    
    In the mean time, I can tell you why ALARMS check for file
    existence and saves the version number:  During the design 
    process we recieved input concerning security.  
    
    It was thought at the time that someone trying to sabotage
    security could easily replace a notification command procedure
    with one that turned on privileges and did harmful things.
    
    This is also the reason why we use MCC_ALARMS_SECURITY to
    normalize the environment before the notification command
    procedure is run.
    
    Even here in the development world, we realize that having to
    re-create your rule, or fix up version numberbers because you made 
    an edit to your notification procedure, can be a pain.
    
    We are hoping to provide a SET directive pretty soon.  This
    could be used to SET any of the arguments to the CREATE RULE
    directive.
    
    aud...
 | 
| 600.2 | This is not necessarily secure... | ULTMAT::BELANGER | A ROSE by anyother name, would not be manageable | Thu Jan 10 1991 12:25 | 9 | 
|  | 
	RE .1
	This is not necessarily secure.  If someone can write to the device
	with a new version, then they should also be able to rename the old
	version and copy a replacement version specifying the correct version
	number for ALARMS to find the file.
	~Jon.
 | 
| 600.3 | How about just discouraging | TOOK::ORENSTEIN |  | Fri Jan 11 1991 10:48 | 11 | 
|  |     Jon,
    
    It's true that this is not secure.  Infact, what you have described
    (renaming new version to old version number) is the only way to use 
    a new version of the command procedure without having to create the
    rule again.
    
    It's not secure, but it is pretty discouraging.
    
    aud...
    
 | 
| 600.4 | Domain directory setting and checking | TOOK::A_MOORE |  | Tue Jan 15 1991 16:20 | 17 | 
|  | If Domain FM could set the directory attribute it could pull the rug out from
under the XM's that use it, such as the Historian.  Other modules that I have
not even heard could  be effected.  In the future, there will be methods that 
will be used to inform other modules that a change has taken place.
VMS specific Directory checking was removed from the Domain FM for flexibility.
Many directory features such as VMS logicals, DFS, NFS, [], / and etc. are
not portable.  We need to solve the problem of how check multiple directory 
syntaxes from multiple platforms both ways.  In addition to the operating 
systems  syntaxes there are Network datastore syntaxes such as DFS and NFS.
So keeping it very simple avoids these problems.
The COPY DOMAIN command could used to easily create a new or temporary domain
with the directory you really meant to type.
Both of these items are on the wish lists, having been previously traded off.
 |