Conference bulova::decw_jan-89_to_nov-90

    I picked up some stuff already done, here's what I got in my
    DECW$LOGIN.COM:
    
$ spawn/nowait @opcom2decw.com
    
    And in opcom2decw.com :
    
$	prv = f$setpriv("oper")
$	Wait 00:01:00
$	SessionProcess = F$GetJpi( "", "Owner" )
$ Loop:
$	Terminal = F$GetJpi( SessionProcess, "Terminal" )
$	If Terminal .nes. "" then goto TerminalKnown
$	Wait 00:00:05
$	Goto Loop
$ TerminalKnown:
$	Old_priv = F$SetPrv ("Oper,Security")
$	Define Sys$Command 'Terminal'
$	Reply/Enable=Security
$	Set Broadcast=(Mail,Phone)
$	Deassign Sys$Command
$	X = F$SetPrv (Old_priv)
$	Exit
    
    
    Many thanks to the guy who posted this in the defunt DECwindows
    notesfile, I'm sure he'll recognize his code :-)
    
    
    Pierre.

And if you want a fixed point font, the following in DECW$SESSION.DAT does the
trick (although there may be better fonts...):

*MainWindow*DwtText*font: -Adobe-Courier-Medium-R-Normal--10-100-75-75-M-60-ISO8859-1
*MainWindow*SText*font: -Adobe-Courier-Bold-R-Normal--18-180-75-75-M-110-ISO8859-1

re Note 73.1 by VISA::BIJAOUI:

        Pierre,

        I created the file verbatim, and I inserted an invocation of
        it in my decw$login.com file.  I got just one OPCOM message:

        	An illegal operator request was made

        appearing in the session manager window.  I went into
        Authorize and deliberately caused operator notification
        events;  they did not appear in the session manager window.
        Unfortunately, OPCOM messages still cause the workstation
        screen to go monochrome and freeze;  that is the problem that
        I really want to eliminate.

        Bob

    (sigh) Hummmm, I don't know, really. Have you checked that you had
    sufficient privileges ? Remember that you gotta 'spawn' the opcom2decw
    command procedure, and thus, your parent process must already have
    OPER (I got to admit that I had a 'SET PROC/PRIV=ALL' just before
    invoking the command proc -redfaced- :-) ).
    
    Anyway, regarding opcom messages on the console, I would suggest you
    try the following:
    
    $ <enable enough privs> 
    $ define sys$command opa0:
    $ reply/disable
    $ deass sys$command
    
    I *think* this should work. I can't check right now (I'm at home).
    
    
    Pierre.

    
    I'm running DW in its Ultrix incarnation. I would like to direct
    these messages to the dxsession window. The console line in ttys
    is:
    
    #conso "/etc/getty edw3 on secure #console terminal 
    
    Despite having the line commented out, DECnet, SU, and other such
    messages continue to clutter up my root window. 
    
    Any suggestions?
    

Re: .3
 
Add the following lines to your SYSTARTUP_V5.COM to disable OPCOM
messages from going to the operators window:

$    define/user sys$command opa0:
$    reply/disable
$    set terminal /perm /nobroad opa0:


Jim

re Note 73.4 by VISA::BIJAOUI:

>     (sigh) Hummmm, I don't know, really. Have you checked that you had
>     sufficient privileges ? Remember that you gotta 'spawn' the opcom2decw
>     command procedure, and thus, your parent process must already have
>     OPER (I got to admit that I had a 'SET PROC/PRIV=ALL' just before
>     invoking the command proc -redfaced- :-) ).
  
At the point I spawn it, my process has SETPRV but no particular extra
privileges.

Bob

You need OPER and SECURITY to enable/disable all operator classes.

re Note 73.8 by K9::PIPER:

> You need OPER and SECURITY to enable/disable all operator classes.

        I understand.  The DCL code in .1 does a f$setprv of OPER and
        SECURITY, so I assume that it is sufficient for the process
        to start out with SETPRV, right?

        Bob

And it doesn't require each user to be privileged, which keeps
.1 from working for me.  Thanks to everyone for their help.

    I need some additional help.  I tried .1 and .6, they redirected
    the  system messages, but left the operator window at the top of
    the screen.  How can I get rid of the area?  Am I putting these
    things in the wrong place?  Do they have to go before or after
    something special?  Thanks.

    Control-<f3>, I seem to recall. Possibly <f2>, I'm at home and can't
    test it out.
    
    Report back if either works.

     By default, the combination ctrl-F2 toggles whether the
     operator window is there or not.  The following are in
     DECW$SM_GENERAL.DAT:
     
          sm.operator_window_key:	F2
          sm.operator_modifier_key:	ctrl
     
     Be careful about ctrl-F3.  It toggles whether the arrow keys
     and the six keys above them (E1-E6, or "Find" - "Next Screen")
     are used with the keyboard or to control the mouse.  I.e.,
     after ctrl-F3 the "Wait" light turns on, and the arrow keys
     move the mouse, "Select" is like pressing the left button,
     etc.  A second ctrl-F3 puts things back to normal. 
     Accidentally hitting ctrl-F3 has confused many people.
     
     Dan
     

    Thank for the help.  Control f2 toggles the window, I assumes it
    was just f2 like in VMS 4.7.

    re: .6
    
    This does not work at all in V5.3 VMS.  Any updated info available?
    
    Thanks...Gary

RE: .15

At the end of my SYSTARTUP_V5.COM, I have the following line:

$ SET TERM/NOBRO/PERM OPA0:

This effectively kills the display of messages to the top of my terminal
screen. I do a

$ spawn/nowait @com_files:opcom2decw.com

in my DECW$LOGIN.COM to get the OPCOM messages into my session manager window.
I'm running the SSB version of VMS V5.3, DECwindows V2.

			-- Stan

    Sys$manager:decw$startserver.com contains this same line:
    
    	$ set term /nobroad/perm opa0:
    
    This should automatically be invoked by DECwindows startup. While
    this worked great in VMS V5.2, it doesn't seem to always do the
    trick in VMS V5.3 during startup. Entering the command after 
    DECwindows startup has completed always works for me.

    After blocking OPCOM and BROADCAST messages to OPA0: on my 5.3 system, I
    was still getting one message on OPA0 during reboot, and two during
    shutdown. They were all coming from DFS.
    
    DFS$STARTUP.COM starts some detached processes with /OUTPUT=OPA0:.
    To stop the OPA0 messages, I changed "OPA0:" to
    "SYS$MANAGER:DFS$OUTPUT.LOG" in both DFS$STARTUP.COM and DFS$CONFIG.COM.

Here is a command file that runs from the SYSTEM account, and causes OPCOM
messages to be broadcast to the session manager window of a user.  It does not
require the user to have OPER or SECURITY privilege.  For me it fills the need
to see OPCOM messages (without using the dreaded "OPCOM WINDOE"), and I can
still have a nonprivilged user account with proxy and not get INSPECT
violations.  It is initially run interactively, and submits itself to batch.

My environment, for reference, is a VS2000, 6MB, VMS 5.3, not part of a
cluster, doing my own system management, and running most processes on a remote
cluster managed by someone else.

---------------------------------------------------------------------------
$	! This procedure finds the Session Manager process and 
$	! causes the specified OPCOM messages to be sent to the
$	! terminal owned by the process.  It is run from the system
$	! manager's account, and requires no special privileges to 
$	! be given to the session manager process.

$	! The parameters are as follows:
$	! p1 classes of OPCOM messages to enable (default to security)
$	! p2 the time the last reply/enable was issued by this 
$	!    command procedure in comparison format.  ("" on
$	!    initial execution.

$	! This procedure should be executed initially in interactive mode
$	! from an account with SECURITY and OPER privileges.  For example:
$	!
$	!	@<file-location>OPCOM2DECW
$	!	@<file-location>OPCOM2DECW "SECURITY,NETWORK,PRINTER"
$	!

$	old_priv = f$setprv("OPER,SECURITY")
$	if .not. f$privilege("OPER,SECURITY")
$	    then
$		write sys$output "%OPCOM2DECW-F-INSPRI, InsufficientPrivileges"
$		exit
$	    endif
$	! Enable the privileges, and make sure they are on.

$	sm_image = "DECW$SESSION"
$	! The file name of the Session Manager Image.

$	interval = "4:00:00"
$	! Check every 4 hours.

$	pid_context = ""
$	! Initialize the pid context pointer
                                                                         
$ get_sm_pid:	! Find Session Manager Process

$	pid = f$pid(pid_context)
$	! Try next pid.

$	if pid .eqs. "" then goto resubmit
$	! If all processes have been checked, we are done.

$	image_file = f$parse(f$getjpi(pid,"imagname"),,,"name","syntax_only")
$	! Get the file name of the image the process is running.

$	write sys$output "PID: ''pid'  IMAGE: ''image_file'"
$	! Tell the world.

$	if image_file .nes. sm_image then goto get_sm_pid
$	! If it is not the session manager, try the next process.

$	sm_login_time = f$cvtime(f$getjpi(pid,"logintim"))
$	! Get the session manager login time in comparison format.

$	write sys$output "Session Manager login time: ''sm_login_time'"
$	write sys$output "Last REPLY/ENABLE time:     ''p2'"
$	! Tell the world.

$	if sm_login_time .les. p2 then goto resubmit
$	! If we have done a reply/enable since last login, skip it.

$ get_sm_terminal:	! Wait loop for session manager startup

$	sm_terminal = "''f$getjpi(pid,"terminal")'"
$	! Get the session manager terminal name.

$	if sm_terminal .nes. "" then goto got_sm_terminal
$	! If there is a termina, go do the reply.

$	wait 0:0:5
$	! Wait 5 seconds for the session manager to get started.

$	goto get_sm_terminal
$	! Go try again.

$ got_sm_terminal:	! Have session manager terminal name.

$	write sys$output "Session Manager terminal: ''sm_terminal'"
$	! Tell the world.

$	define sys$command 'sm_terminal'
$	! Point to the terminal

$	if p1 .nes. ""
$	    then
$		reply/enable=('p1')
$	    else
$		reply/enable=security
$	    endif
$	! If p1 overrides the enable classes, use it, otherwise use SECURITY.

$	set broadcast = all
$	! Let the other messages come thru while we are at it.

$	deassign sys$command
$	! Release the pointer.

$	p2 = f$cvtime()
$	! Update the last-time parameter.

$ resubmit:	! Done

$	write sys$output "Resubmit at ''f$cvtime(f$time()+"+"+interval)'"
$	! Tell the world.

$	submit -
	  /after="''f$time()'+''interval'"-
	  /noidentify-
	  /nonotify-
	  /parameters=("''p1'","''p2'")-
		'f$environment("procedure")'
$	! Resubmit the command procedure to check again later.

$	junk = f$setprv(old_priv)
$	! Restore privileges.

$	exit

    Let's try and figure out what I REALLY want to do.
    
    1. I NEVER want to see the OPCOM window at the top of the screen.
    2. I want operator commands caused by actions in a DECterm to be replied
       to in that DECterm, and messages resulting from actions in a DECterm
       to appear in that DECterm.
    3. General operator information messages should show up in the SM
       window (if that is not a contradiction to 2).
    
    I now have so many bits and pieces (SYLOGIN.COM - /NOASSIST; the last
    reply; OPCOM2DECW.COM; etc.), that I think a new start is in order.
    
    Thanks...Gary

>     <<< Note 73.21 by HABS11::MASON "Explaining is not understanding" >>>
>             -< It's 5.4 now, and broken again (for me)...help? >-
>
>   Let's try and figure out what I REALLY want to do.
>   
>   1. I NEVER want to see the OPCOM window at the top of the screen.
    
    $ DEFINE/SYSTEM OPC$OPA0_ENABLE FALSE (in SYLOGICALS.COM)
    
>   2. I want operator commands caused by actions in a DECterm to be replied
>      to in that DECterm, and messages resulting from actions in a DECterm
>      to appear in that DECterm.
    
    $ REPLY/ENABLE in the DECterm window?
    
>   3. General operator information messages should show up in the SM
>      window (if that is not a contradiction to 2).

    Use one of the aforementioned sm-opcom hacks.
    
    Did you upgrade to DECwindows V3 as well as V5.4?  I didn't have any
    problem doing what you're doing under V5.4, but it broke when I went to
    V3 of DECwindows.  I fixed it by first AUTOSTARTing the message window
    and then the sm-opcom hack.  

    I stayed at DECwindows V2.  Thanks for the info - I'll be back if it
    was as hard as 5.2 was.  8')
    
    Cheers...Gary