Conference bulova::decw_jan-89_to_nov-90

$ def/user sys$command opa0:
$ repl/disable


Then pick a window you want the NCP messages in and do a reply/ena=network.

For example:

	if TWA1: was you session manager window, then you'd do:

	$ def/user sys$command twa1:
	$ reply/enable=network

Jeff

(Of course you need the proper privilieges to do the above)

    Jeff,
    
    Thanks for your reply. I have the right privileges. Was this meant
    to be the behaviour or did I miss something. I saw the parameter
    WS_OPA0 coule be disabled.
    
    
    Ren�

    I don't know how WS_OPA0 is handled in the DECwindows environment. I
    thought that this was a VWS only parameter, but i could be mistaken.
    
    (actually i use it on my private workstation. In SYSTARTUP_V5.COM , I
     set repl/ena or repl/dis depending on the setting of that bit, but
    that's just me)
    

If you always want to disable Operator messages to OPA0:, and you're running
VMS V5.3 (or later), you should have a read of SYS$MANAGER:SYLOGICALS.COM which
documents a set of logical names which can be used to control OPCOM.

We've used one of those to disable OPA0 on all of our standalone workstations.
(I got fed up of explaining Ctrl-F2 to people).  Unfortunately, I can't
remember the logical name offhand, but it's all there in SYLOGICALS.COM.

BTW, I'm sure this is documented elsewhere, but I found it first in SYLOGICALS
and didn't look any further.

-- Paul.

The logical is OPC$OPA0_ENABLE.

Dick

Yeah, that's right...  Now I remember...  ;-)

Define OPC$OPA0_ENABLE to FALSE, and it should stop OPCOM messages from
appearing at the top of you WS screen.

-- Paul.

    
    This and more are listed in the file SYS$MANAGER:SYLOGICALS.TEMPLATE
    which should be on most systems...
    
    
    � J.

    Does it follow, then, that if I have a standalone workstation (and am
    privileged), that re: .1, I can
    
    	$ def/user sys$command opa0:
    	$ repl/disable
    
    to avoid creation of the operator window, and in sylogin.com (or
    login.com), use
    
    	$ def/user sys$command (my own terminal ID here via lexical)
    	$ reply/enable=(all classes I might need - tape, disk, etc.)
    
    to allow each terminal window to handle operator requirements that it
    may have caused?
    
    The goals are:
    
    1. NEVER have the operator window, and the associated need for ctrl/F2
    2. Handle operator requests from the terminal window causing them
    
    Thanks...Gary

The bottom line is that OPCOM inhales profusely on workstations where single 
user = system manager/operator.  It is not the environment that OPCOM was 
designed for.

As the system manager of my workstation, I have disabled the OPCOM "window" 
(bad choice of name...if any other product had windows like that, they would
no longer be products).

In order to be consistent with Corporate Security Policy, and maintain my proxy
access to my workstation account, I have eliminated the privileges needed to 
turn ANY of my windows into OPCOM windows.

The end result is that it takes extra time and effort to peruse the operator 
logs to ensure system security.

How about making a secure yet friendly OPCOM interface in a DECwindows future 
release?

    or in your systartup do:
    	set term/perm/nobroad opa0: