From:	SMTP%"RELAY-INFO-VAX@CRVAX.SRI.COM" 11-AUG-1993 12:48:26.64
To:	EVERHART
CC:	
Subj:	RE: CREATE/TERM command timeouts?

X-Newsgroups: comp.os.vms
From: tillman@swdev.si.com (Brian Tillman)
Subject: RE: CREATE/TERM command timeouts?
Message-ID: <10AUG93.10190615@swdev.si.com>
Sender: news@esseye.si.com
Nntp-Posting-Host: terwed.si.com
Organization: Smiths Industries Aerospace & Defense
Date: Tue, 10 Aug 1993 10:19:06 GMT
Lines: 79
To: Info-VAX@KL.SRI.COM
X-Gateway-Source-Info: USENET

In a previous article, pbt@mail.ast.cam.ac.uk (Philip Taylor) wrote:
> 
>          Thanks to everyone who responded. It turns out that the reason for the
>time-outs was that the login.com for those accounts did a WRITE to SYS$OUTPUT.
>DECterm can't deal with this and it just times out rather than failing.
>Removing the offending DCL lines got the DECterm windows to start up OK. I was 
>told by someone that this "feature" of DECterm was introduced at VMS Motif 1.1.
> 
>Is this "feature" going to be removed again in a future Motif release?

Actually, the DECterm can handle it just fine.  It's the DECterm *controller*
that can't.  However, since the DECterm controller (the DECW$TE_xxxx process)
has a mode of OTHER, it's easy to avoid running your entire login by putting:

$ if f$mode() .eqs. "OTHER" then exit

right at the top of your login.

Moreover, for most autostarted applications such as Clock and Calendar that you
run in detached mode, you also do not want to run your login fully.  These
processes can be detected with the following DCL:

$ applic = f$getdvi( "sys$command", "mbx" )

The symbol APPLIC will be true for any application you start DETACHED from the
Session Manager.  You might also want to test for the Session Manager itself,
because it doesn't do a lot of good to run through your entire login command
procedure for it, either (most symbols don't have a lot of meaning in the
Session Manager's context, but a few might).  You can do this with:

$ sesmgr = f$extract( 1, 2, f$getdvi( "tt", "devnam" ) ) .eqs. "WS"

The symbol SESMGR will be true only for the Session Manager process.  My login
command procedure looks like this:

$   verify = 'f$verify( 0 )'
$   set noon
$   mode = f$mode()
$   set protection=(group,world)/default
$!
$!  Here go things for all login modes (INTERACTIVE, BATCH, NETWORK, and OTHER).
$!
$   if mode .eqs. "OTHER" then exit 1 + 0 * f$verify( verify )
$!
$!  Here go things for NETWORK, BATCH, and INTERACTIVE.
$!
$   applic = f$getdvi( "sys$command", "mbx" )
$   sesmgr = f$extract( 1, 2, f$getdvi( "tt", "devnam" ) ) .eqs. "WS"
$   if .not. ( sesmgr .or. applic ) then -
        write sys$output "Executing private login command procedure"
$   node_name == f$getsyi( "nodename" )
$   root = f$trnlnm( "sys$login" ) - "]"
$   define/nolog com 'root'.com]
$   xv == "$com:xv"
$ ...  A few other symbols and logicals. ...
$   if ( mode .eqs. "NETWORK" ) .or. sesmgr .or. applic then -
        exit 1 + 0 * f$verify( verify )
$!
$!  Here go things for BATCH and INTERACTIVE.
$!
$ ...  More symbols and logicals. ...
$   if mode .eqs. "BATCH" then exit 1 + 0 * f$verify( verify )
$!
$!  Here go things for INTERACTIVE only.
$!
$ ...  More symbols and logicals. ...
$   exit 1 + 0 * f$verify( verify )

This permits those processes that don't need or can't use a lot of symbols and
logicals to exit the login in the most timely manner possible, leaving those
processes for which you want the most symbols and logicals (such as DECterms) to
run the entire login.

-----------------------------+--------------------------------
 Brian Tillman               | Internet: tillman@swdev.si.com
 Smiths Industries, Inc.     |           tillman_brian@si.com
 4141 Eastern Ave., MS129    | Hey, I said this stuff myself.
 Grand Rapids, MI 49518-8727 | My company has no part in it.
-----------------------------+--------------------------------