From:	CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX"  6-DEC-1990 09:26:33.79
To:	MRGATE::"ARISIA::EVERHART"
CC:	
Subj:	Re: Session Manager window enabled for OPCOM

Received:  by crdgw1.ge.com (5.57/GE 1.80)
	 id AA08059; Thu, 6 Dec 90 09:09:42 EST
Received: From ucbvax.Berkeley.EDU ([128.32.130.12]) by CRVAX.SRI.COM with TCP; Wed,  5 DEC 90 19:09:33 PST
Received: by ucbvax.Berkeley.EDU (5.63/1.42)
	id AA06740; Wed, 5 Dec 90 18:39:39 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for info-vax@kl.sri.com (info-vax@kl.sri.com)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 5 Dec 90 05:23:04 GMT
From: infopiz!mark@decwrl.dec.com
Organization: INFO COMM - Computer Consulting, Redwood City, Ca
Subject: Re: Session Manager window enabled for OPCOM
Message-Id: <5163.275c21c8@infocomm.com>
References: <1990Nov26.084300@uvphys.phys,uvic.ca>
Sender: info-vax-request@kl.sri.com
To: info-vax@kl.sri.com

In article <1990Nov26.084300@uvphys.phys,uvic.ca>, zapantis@uvphys.phys,uvic.ca writes:
> Does anyone know how to enable the DECWINDOWS(VMS) session manager window to
> receive OPCOM messages? There must be a way of doing a REPLY/ENABLE on that
> window.

This was asked a week or so ago, and no one has answered, so I'll post what
I've got on our systems here.  With this procedure any account that has OPER
priv will end up with the Session Manager Message window enabled for OPCOM
messages while logged in.  This can obviously be altered depending on the
requirements of your site.  Digital supplies an empty template
SYS$MANAGER:DECW$SYLOGIN.COM file, use this in it's place and have fun.

-- 
Mark Pizzolato - INFO COMM Computer Consulting, Redwood City, Ca
PHONE:	(415)369-9366	UUCP:  decwrl!infopiz!mark or uunet!lupine!infopiz!mark
DOMAIN:	mark@infocomm.com

$ !
$ ! DECW$SYLOGIN.COM - Initialize the DECwindows applications
$ !
$ !
$ ! This command procedure is executed when a user logs into the workstation
$ ! with DECwindows.  You may run clients from this command file which
$ ! you would like all users of your system to have running when they
$ ! log into their workstation.
$ !
$ ! If this process doesn't have an owner, then we are being invoked
$ ! directly from the session manager, if we do have an owner, we are being
$ ! called recursively in the context of a subprocess.  The reason we need 
$ ! to use a subprocess, is that for some strange reason, when a DECwindows
$ ! session is initially created with the session manager, the session manager
$ ! process is actually created with it's input being the appropriate
$ ! DECW$DISPLAY device (i.e. WSAn:).  A PTY (TWAn:) is later attached by the
$ ! session manager to provide the session "Messages" window. and to have a
$ ! window to catch things like newmail messages, etc.  Here we create a 
$ ! subprocess actually running this procedure.  When the subprocess runs
$ ! it's ONLY job is to hang around for a while waiting for it's OWNER (parent)
$ ! process to have a "TERMINAL" associated with it.  Once this
$ ! process/terminal relationship is observed, the PTY (TWAn) that is the
$ ! "TERMINAL" is enabled as an operator console.  Note: all of this
$ ! foolishness is only done if the original (Session Manager) process has 
$ ! OPER priv, which will allow the eventual enabling of the PTY as an operator
$ ! console, anyway.
$ !
$ owner = f$getjpi("","OWNER")
$ if owner.NES.""
$    then
$ loop:	wait 0:0:20
$	if f$getjpi(owner, "TERMINAL").eqs."" then goto loop
$	assign/user 'f$getjpi(owner, "TERMINAL")' sys$command
$	reply/enable
$	exit
$    else
$	if f$privilege("OPER") then spawn/nowait @'f$environment("PROCEDURE")
$ endif