REPLACED WITH MAC DOCUMENT, OCT 2000, UPDATED JAN 2001
SEE PGR DISK1:NSTX:startupchecks_8-jan-2001.doc





28-sep-00 pr NSTX Data Acquisition and Analysis Startup checks

	check that RUNNSTX is running
	check that IPCS is running
	check that NFS is running on BIRCH

	check that the NSTX_ACQREMOTE queue has the proper jobs running
	check that the NSTX_DB queue has the proper jobs running
	check that the NSTX_VGDS queue has the proper jobs running

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

	to get the definition of "shw", execute DAS:DASLOGIN
	or define
		$ shw       :== $DAS$:[UTIL]show$world.exe


KEES$ shw runnstx
  Pid    Prcname         Image      State  Pri       CPU   ppgcnt/wspeak Fs
20809442 RUNNSTX         RUNNSTX     HIB   8/5   00:01:41.08 4720/6496    4
KEES$

KEES$ shw *ipcs*
  Pid    Prcname         Image      State  Pri       CPU   ppgcnt/wspeak Fs
20800224 IPCS_GRANDPA    GRANDPA     HIB  10/7   00:00:00.06 1200/2528    9
20800226 IPCSMAILER      NETMAILER   HIB  10/7   00:00:34.13 1648/2688    9
KEES$


	To verify the RUNNSTX is "seeing" ipcs events, check the
	end of the RUNNSTX_yymmdd.LOG and inspect the last IPCS
	messages whose receipt has been recorded; if RUNNSTX "knows" it has
	lost IPCS, a long list of "trying to connect" messages
	will be present, but this only happens if RUNNSTX is
	restarted after IPCS has been lost

	If it appears that IPCS is no longer connected, it must
	be restarted on the EPICS side:

	from control page CH01, in the Operations Startup panel,
	there is a large gray button marked with "!"
	This is normally set up and visible on the "CI&C Operations"
	window of the Common Desktop interface;

	The "!" button is a drop-down menu of actions; choose
	Restart IPCS tasks, and watch on the Xterm output that
	the shot-cycle events are subsequently subscribed by
	RUNNSTX, CLOCKSYNC and ACQ_EPICS; sometimes this takes
	more than one restart (RUNNSTX waits between attempts to
	reconnect, so the subscribe messages will not come
	immediately)


NFS server should be running on BIRCH (at some near future date,
                                       we will be using the NFS server
                                        on KEES, but as of Sep 2000,
                                        we are still using BIRCH
KEES$ shw nfs_server*/node=BIRCH

BIRCH:
  Pid    Prcname         Image      State  Pri       CPU   ppgcnt/wspeak Fs
216094B0 NFS_SERVER      NFS_SERVER  HIB  11/9   00:01:16.6316656/16912   0
21607CB1 NFS_SERVERIO_1  ASYNC_IO_ASSLEF  12/9   00:00:03.50  976/1424    5
216090C5 NFS_SERVERIO_2  ASYNC_IO_ASSLEF  12/9   00:00:00.11  976/1424    5
KEES$

	If the NFS server task is not present, or if users of NFS
	(at present: Fast Camera PC, USXR PC, UCLA MMWR PC)
	report that they don't see any change to their shotnumber
	files, it may be necessary to restart NFS:

$ NFS*_control :== @ops:[nfs]nfs_control.com
	SYSPRV is necessary to run this process

	$ NFS
		choose "2" to stop NFS and then "1" to restart;
		to see the status of the NFS server process from
		inside NFScontrol requires more than SYSPRV,
		but using SHW to check it does not


========================================================================

Troubleshooting:

		Log files

	Log files for all our shot-cycle jobs are meant to be
	placed in subdirectories of NSTX$:[LOGS]
	Currently:

 Subdirectories of NSTX$:[LOGS]
    ACQREMOTE  CAMAC  DB  EVENTS  MPTS  RF  RUNNSTX  SQLSERVER
    TC_MON  VGDS

The NSTX$:[LOGS.RUNNSTX] directory contains log files
for RUNNSTX, DISPATCHER, GKB2_SERVER and GKC2_SERVER, each
suffixed with the date in yymmdd format.

Using the SEARCH command on these logs, or using TYPE/TAIL=nn to
see the most recent entries, are the most common checking techniques

		NSTXACTMON and SHOTCAMACMON

$ nstxACTMON :==   -
    "spawn/not/now/input=nl: mcr actmon -monitor kees::mon_server"

	NSTXACTMON invokes the program that receives status messages from
the dispatcher and various mdsservers, relayed by a monitor_server task;
there is only one monitor_server, automatically installed, but there
can be many users watching procedings using NSTXACTMON without incurring
a performance penalty (or so we are assured).

	To discover what errors occured in an earlier shots, the PPPL
utility SHOTCAMACMON.PRO can be used. (?DMASTROVITO$:[CAMAC_ERRORS]
SHOWCAMACMON.PRO at the moment?)

=============================================================================

Remote acquisiton:

	file transfer via NFS, MDSplus tree writes initiated via IPCS event

EPICS
	FCPC		ACQ_EPICS in VMS queue NSTX_ACQREMOTE
	Gas
	NBI


PPCC			ACQ_PPCC in VMS queue NSTX_ACQREMOTE



	file transfer via SAMBA

USXR
		MDSplus tree writes initiated via MDSplus event sent from PC

RGA for trending files
		MDSplus tree writes initiated by polling for new data file
		(arrives about every two hours)
==========================================================================