logTool:
 
We could not find the doc for logTool in the IOP page linked from
procedure page v1_22. Am I missing something???
 
While trying to save my log entry, I got,
 
Error:window name "logview3saveprompt" already exists in parent
 
Later I found a window asking about saving the log under other windows.
Maybe that is what the above referred to.
 
The popup window that asks you questions when you hit "Load", "Save",
or click "Editable" many times come up at a location not so close to the
window where I had the "logTool" window up. With the many many windows
we need to operate, this makes it very easy to loose the small
popup window behind others.


Landru:
 
Landru is great! I enjoyed having so many screens in front of me where
I can see many windows at once.  Craig and Scot spent time configuring
so that GNOME will be convenient for our use. But we found out that we
could not use GNOME due to the color map problem we have with TPM.
Until the problem is resolved, we will have to use KDM as our window
manager.  Gnome to work with TPM color map will be nice.
 
In IOP, arrow key no longer game me previous commands.  But in the
xterm, it works. Arrow keys for previous commands will be nice.
 
KDM does now allow us to drag windows from one virtual desk top to another.
It will be nice if we could do so -- other we have to always remember to start
this process and that process at different virtual windows which is tedious.

 
TPM:
 
Running TPM display on Landru:
As mentioned above, color map problem is a pain ---- for now, run KDE as your window
manager if you want to get the TPM display running. We did not get
others to work. Peregrine, any schedule on when we can get the color
map problem solved ?
 
For things that Peregrine requested us to shake,
 
        o Wind direction/speed [NEW] - the TPM software is in place but the
      hardware is in the process of installation.
 
--> Yes, the display is there and there are numbers in the display for them.
    We assume the current numbers displayed are just noise.
 
        o Slip detection [NEW] - many problems here, some stemming from
      the fact that the system only latches the data available to me
      for 5 microsecs.  Glenn is considering a redesign of that
      interface to make the data more persistent.
 
--> What do we expect to see  when all is well? I see the display and
many flashing lights on the amplifier status display. The SLIP
detection is 0x0.


In an IOP window, we saw the following message, but we (including Eric) did not understand
what it means. Does anyone know what it means? It seems nothing bad happened, but we are
curious to know what it means.
 
im> CA Exception was: Network connection lost
Context was: sdsstpm.apo.nmsu.edu:5064
When op=5 type=-1 count=0
im>


DAs:
At the beginning of the night, I placed tapes in the archiver as usual
and then started a bias drift. I then realized that I forgot to do a
tapeLoad. There were also some other bias runs taken earlier that day
by Jon B., so I stopped the run and did " initNight -tapeLoad" which
spent a long time "blam-o"ing because the drives were considered to
have "NoTape" or in "NotMount" status although they were loaded
prior to the bias drift. IOP tried blam-oing 181 times and then
restarted trying to it again (the counter restarted). Finally when iop
gave up initNighting, I tried to flush the Q since the Watcher
indicated that the Q was nonzero. IOP told me I cannot do so unless the
archiver is paused. So I tried to pause the archiver, but the archiver
status did not change and the tapes are either in "not Mounted" or "no
tape" status. We also saw in the murmur log many "loading tapes" messages
for all the drives, but the archiver status showed that the tapes were not
loaded successfully.  This exact same  thing has happened before few
times --- usually after someone did "goDrift" with the archiver
disabled.  After trying pausing, loading/unloading the tapes few times,
we found out that if we load the tape and do nothing for a
while (many minutes --- I was away from my terminal and watching Dan
take pointing model for about 20, 30 min before returning to mybut Watcher and "statusDump archDrvSts" showed that id4-1 was in the
"Reading tape label" state and not "Ready to Archive". Reloading the
tape few times did not clear the situation and we noticed the following
message in the murmur log.
 
Aug 06 23:09:49 sdssid4    dArchSrv   dsc_I_archFailMsg Rimfire failure  ID = 1  Status = 0xf0008001 0x5080
 
Aug 06 23:09:49 sdssid4    dArchSrv   UNKNOWN_MSG Unknown message code, 800140DB, received
Aug 06 23:09:49 sdssid4    dArchSrv   dsc_E_archNoLabel Tape does not have ANSI 3 label
 
So we decided to reboot the id4 to 6 (there is no way to reboot only
id4-1). We tried "tapeRelabel" again and got the same message as above.
We then decided to reboot and put in a new tape in id4-1. This time it
worked and we had all the drives ready to archive.  It will be nice if
the imager was used during the day without the tapes, the Q is flushed
so that we don't get into this situation again. And the observers
should make it a habit to check the Q depth before putting in tapes or
doing "initNight" so that in case the person who did a drift before the
the observers forgot to clear the que, we still do not end up in this
situation as we saw tonight again.
 
 
We saw the "Error: extra characters after close-brace" after
the endDrift.  Here is the message with the "tb".
terminal), the archiver will pause.  It seems that it just takes longer
than one thinks for the archiver to pause.  With the archiver paused,
we executed "archFlushQ", "initNight -poolInit" successfully.  When we
proceeded to do "tapeRelabel", IOP said that "IOP ready for flight",