TCS general help

Logging in as TCSMGR to check TCS logs

Use telnet to the alpha, e.g. telnet lpas5. Log in as TCSMGR. Ask CRB or FJG for the password. The TCS process logs are under
[tel.DATA.PROCESS], where tel is either INT or WHT. For example to look at the USER process log for the WHT
TYPE [WHT.DATA.PROCESS]USER.LOG 

Note that at the WHT commands issued at the USER> prompt are echoed to the talker syslog on taurus /var/log/talker/talker.info

Logging in at the Alpha console

The TCS login accounts are restricted accounts, which means they cannot be used to login directly from an Alpha console. If you need to use the Alpha graphics console to run the TCS, first login as TCSMGR, then telnet to the the Alpha and then login. For example, at the INT Alpha, login as TCSMGR then telnet LPAS2 and login as INT_LOGIN. Where the console is a VT220, one can log in as TCSMGR to see logs, but it won't be possible to start the TCS displays there. 

TCS displays are not created (INT & WHT)

If neither the TCS DISPLAY nor the TCS USER windows are created when the TCS is started, then the most likely cause is that the x-windows creation on the local display is failing. Log files [wht.data.process]user.log or [wht.data.process]display.log may contain messages like

Xlib: connection to "_WSA41:" refused by server
Xlib: No protocol specified

%DECW-E-CANT_OPEN_DISPL, Can't open display

Things to check are

1. Use the xhost command to check that displays are allowed. xhost + enables from any host
   
2. By default, ubuntu sytems do not allow remote x displays to the desktop. Machines where the TCS displays are expected to run have been configured to allow x displays. These include osadisplay1/2 and whticsdisplay1/2 at WHT and miranda plus inticsdisplay at the INT. Check the file /etc/lightdm/lightdm.conf contains xserver-allow-tcp=true. More information about configuring the local display machine can be found in confluence.
3. The TCS will only create x displays on x server 0, screen 0. echo $DISPLAY will show the display definition (e.g. :0 ) . In general the display machines boot with console display as server 0, but miranda can boot with different server for the console display. If this occurs then reboot miranda until it has display 0 defined for the console. ps -ef | grep Xorg will show information about the x sever process.
   

One can check creation of a DECterm window from the alpha, without starting the TCS

       $ XDISPLAY
       $ CREATE/TERM 

Again see more details in confluence.

TCS displays created but soon disappear (WHT)

When the user starts the TCS. The login session disappears. A detached process called MONITOR runs to start the other TCS processes. These are started and then MONITOR sends interrupts (INITAST) to tell each to initialise. When all of the processes have initialises (warmed up) the the TCS runs. If one of the processes fails to initialise, there will be a message in [WHT.DATA.PROCESS]MONITOR.LOG
that   

 00:00:00  %STATUS-F-TCSNOINI, TCS did not initialise

and MONITOR will close down the TCS processes. 

One cause of such a failure appears to have been the autoguider connection. In this case the TCS did not start until the autoguider cable was disconnected from lpas5. If this is suspected, then disconnect the autoguider serial line from the alpha and restart the TCS. 

It has also happened on the development machine (lpas3) that the OUTLOG process did not fully initialise due to a full disk. SHO DEV D will show disk free space information.  The TCS uses the system disk for storage.

TCS displays created but soon disappear (INT)

If the TCS appears to start, i.e. it creates the windows which then disappear soon afterwards, the problem is likely to be in the CAMAC interface. The problem could be located on the PCI card in the Alpha, or in the CAMAC controller module in the system crate. To check whether the CAMAC interface is the problem, login as TCSMGR and look at the log of the SYNC process:
type [tel.DATA.PROCESS]SYNC.LOG
If the log has the entry Unable to link LAM to AST routine, the CAMAC interface must be initialised by reloading the CAMAC driver, which can only be achieved by rebooting the Alpha. It is also a good idea to power cycle the system crate as well, as follows.

    Shut down the Alpha using the SHUT account.
    On the CAMAC system crate, switch the branch coupler (BR CPR 4-1) offline then power off the system crate.
    After about 10 seconds, power on the system crate and wait for the fans to run up.
    On the branch coupler, press the branch initialise switch, then switch to ONLINE.
    Boot the Alpha by typing boot at the >>> prompt.

If the TCS starts, but there is no data in the DISPLAY window, check that the CAMAC cable is connected correctly. If you need to reconnect the CAMAC cable, first shutdown the Alpha and power it off, then switch the branch coupler offline and power off CAMAC. Check the pins on the connector for damage. Spare cables are kept in the drawer of the desk in the back right-hand corner of the WHT computer room. Once the cable is connected securely, power on CAMAC, initialise the branch coupler and then put it online, then power on the Alpha which will boot automatically.

TCS communication with ICS (INT)

If commands cannot be sent to the TCS from the ICS, it may be that the TELD process on the Alpha has died. To restart the TELD process, login as normal and choose the TELD option. On the ICS use the startobssys command to reconnect to the new TELD process.

If the TCS header collection is not working, either the TELD process has died, so the ARCHIVE commands do not work, or else the Unix partition is not mounted on the Alpha. TELD can be restarted as described above. The Unix partition can be remounted by logging in as normal and choosing the NFSMOUNT option.

TCS User window hangs (INT & WHT)

If the TCS User window stops accepting input, it may be that the communications have hung