If the STM daemons are running you will see 3 "stm" processes typically
near the bottom of the list. The long names in lower case make them easy
to find.. This can take minutes (sometimes 5 or 10 minutes) after
restarting the system or issuing a :STMSTART.DIAG.SYS

> :showproc 1;tree;system   <----YOU TYPE THIS
> QPRI  CPUTIME   STATE  JOBNUM  PIN  (PROGRAM) STEP
>
> A13 * 0:15.386  WAIT           1    (PROGEN.PUB.SYS)
> B142* 0:02.484  WAIT             2    (LOAD.PUB.SYS)
> B100* 0:02.615  WAIT             3    (..)


******* SNIP ********

>
> B150* 0:29.918  WAIT             40   (/usr/sbin/stm/uut/bin/sys/diagmond)
> B150  0:33.514  WAIT               69   
> (/usr/sbin/stm/uut/bin/sys/diaglogd)
> B150  0:00.874  WAIT               75   
> (/usr/sbin/stm/uut/bin/sys/memlogd)
> C152* 0:00.287  WAIT             53   (SNMP.NET.SYS)
> :


Bob J. -- Ideal Computer Services
http://www.icsgroup.com



Tim O'Neill wrote:

>Since SYSDIAG has become CSTM, I ran CSTM.  It suggested that name-to-address resolution was not working, so I went and verified
>that it was working.  As proof, NSLOOKUP run from Posix shell returns correct IP of the FQDN.
>
>I can CSTM again.  
>Within CSTM, I ran STMSTART then CONNECTSYS.  The same error recurred.  I.e. it cannot connect to itself.
>
>* To join/leave the list, search archives, change list settings, *
>* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>
>
>
>  
>

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *