I did some searching on the list archives for this, but 8 or 9 pages into it, didn't really find anything specific to my question. I want to have a PC in the control room with the ability to launch read-write DMs and AMs from adjacent WPs in the event of plant upsets, startups, ops engineer wants to play, etc. I've defined extra DMs/AMs in the dmcfg file as class O, but they still come up with omsets disabled and access class 100 protected. This of course is contrary to what all the docs I read said (dmcfg.man, Workstation Alarm Management, the X-terminal user guides). I can work around it in DM, however, by enabling omsets and unprotecting value 100 in the initial environment file; I like this better anyway because there is no reboot required if I ever have to change it. However, the alarm manager is killing me. It will not inherit the unprotected 100 class from the DM (like the docs imply that it should). It also will not read the initial environment file, even if I define that in the ADMC (I tested this by including a pref -SOMEOTHERDM DMCMD "msglin am_activated" -- it worked when I launched the DM, but not the AM). I can pref the unprotect 100 to the AM after it's up, and the buttons become black on cue, but I can't automate this on AM startup, since it won't read the environment file. Other hacks I've considered, like a daemon script to 'ps' periodically for the AM and pref it, or launch it with the DM, wait a few, and then pref it, are just too ugly. The only other thing that crossed my mind here is that I'm not launching the DM or AM as root, but as a special account I created for this purpose (though I made sure this account has read access to all the files in question, if that's even necessary). No mention of that in the docs, but I wouldn't be surprised if that is the problem, I'll probably try that later today, though I would not prefer to run that way. Anyone else run across this (OK, stupid question :)? Thanks, Corey Clingo BASF Corporation _______________________________________________________________________ This mailing list is neither sponsored nor endorsed by Invensys Process Systems (formerly The Foxboro Company). Use the info you obtain here at your own risks. Read http://www.thecassandraproject.org/disclaimer.html foxboro mailing list: //www.freelists.org/list/foxboro to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave