From mtang at snf.stanford.edu  Mon Dec  1 08:53:32 2003
From: mtang at snf.stanford.edu (Mary Tang)
Date: Mon, 01 Dec 2003 08:53:32 -0800
Subject: Narya
Message-ID: <3FCB720C.A96BC559@snf.stanford.edu>

Hi guys --

"narya" is graduating and no longer wants to be notified of the doings
at SNF (I just saw him in the hall).  Could you take him off the email
lists?  I take it this also means that his Coral login can be disabled
or disconnected or otherwise stowed away for future use (in case he, as
so many others have done, decides to return later)?

Thanks,

Mary

--
Mary X. Tang, Ph.D.
National Nanofabrication Users' Network
Stanford Nanofabrication Facility
CIS Room 136, Mail Code 4070
Stanford, CA  94305
(650)723-9980
mtang at stanford.edu
http://snf.stanford.edu




From mtang at snf.stanford.edu  Tue Dec  2 11:56:23 2003
From: mtang at snf.stanford.edu (Mary Tang)
Date: Tue, 02 Dec 2003 11:56:23 -0800
Subject: History question?
Message-ID: <3FCCEE67.1FAEB301@snf.stanford.edu>

Hi Coral guys --

Just a question...  A situation (or series of situations) came up...
There are a couple of labmembers who have left machines enabled for long
periods of time after use -- and a couple of other labmembers who have
complained because they thought the machines were in use by the enabler
and so didn't use them.  They didn't have reservations, so no reason to
enable over the first people.  I guess it hadn't occured to me before,
but it looks like you can't really tell from Coral History how long the
current enabler has had the machine enabled (otherwise, it would have
been clear that these people just forgot to disable the machines.)  Is
there another simple way for labmembers to tell how long a current
enable session has been going?

Thanks,

Mary

--
Mary X. Tang, Ph.D.
National Nanofabrication Users' Network
Stanford Nanofabrication Facility
CIS Room 136, Mail Code 4070
Stanford, CA  94305
(650)723-9980
mtang at stanford.edu
http://snf.stanford.edu




From shott at stanford.edu  Wed Dec  3 08:26:35 2003
From: shott at stanford.edu (John D Shott)
Date: Wed,  3 Dec 2003 08:26:35 -0800
Subject: History question?
In-Reply-To: <3FCCEE67.1FAEB301@snf.stanford.edu>
References: <3FCCEE67.1FAEB301@snf.stanford.edu>
Message-ID: <1070468795.3fce0ebbefb1c@webmail.stanford.edu>

Mary:

The short answer is "no".  Basically, equipment use isn't entered into the
eq_activity table until the use is completed ... and it is the eq_activity
table that contains what is displayed in the history table. There is a table
called current_eq that contains all of the information pertinent to all of
the equipment currently in use ... that is, equipment that has been enabled
but no disabled.  At this point, the data in current_eq is not visible
within the coral client.  One option, I think, might be to add the
capability to double-click on a piece of enabled equipment and see the
details of the current_eq record that would show when it had been enabled.

Thanks,

John


Quoting Mary Tang <mtang at snf.stanford.edu>:

> Hi Coral guys --
> 
> Just a question...  A situation (or series of situations) came up...
> There are a couple of labmembers who have left machines enabled for long
> periods of time after use -- and a couple of other labmembers who have
> complained because they thought the machines were in use by the enabler
> and so didn't use them.  They didn't have reservations, so no reason to
> enable over the first people.  I guess it hadn't occured to me before,
> but it looks like you can't really tell from Coral History how long the
> current enabler has had the machine enabled (otherwise, it would have
> been clear that these people just forgot to disable the machines.)  Is
> there another simple way for labmembers to tell how long a current
> enable session has been going?
> 
> Thanks,
> 
> Mary
> 
> --
> Mary X. Tang, Ph.D.
> National Nanofabrication Users' Network
> Stanford Nanofabrication Facility
> CIS Room 136, Mail Code 4070
> Stanford, CA  94305
> (650)723-9980
> mtang at stanford.edu
> http://snf.stanford.edu
> 
> 
> 




From Yiching_Liang at MolDev.com  Wed Dec  3 14:38:03 2003
From: Yiching_Liang at MolDev.com (Yiching Liang)
Date: Wed, 03 Dec 2003 14:38:03 -0800
Subject: Remote Coral Problem
Message-ID: <sfcdf559.070@MDGW2.moldev.com>

** High Priority **

Hi-

I am a new industry user at SNF. I'm trying to set up remote Coral at
my office so I can view/edit reservations. I've installed Java WebStart
(version 1.2) successfully. 

When I clicked on "Launch Remote Coral " from the SNF website., a Java
WebStart logo was displayed briefly, then an error message "Java Web
Start - Invalid Argument error: Unable to launch the specified
application." There are 2 buttons on the error dialog. If I click "OK",
then the process is aborted. If I click "Details", the following is
displayed:

"An error occurred while launching/running the application.

Category: Invalid Argument error

Could not load file/URL specified: C:\Documents and
Settings\YLiang\Local Settings\Temporary Internet
Files\Content.IE5\76CJJDOX\coral[1].jnlp"

I went into the specified directory, but there is no "Content.IE5"
subdirectory under my "Temporary Internet Files" folder. In fact
there're no subdirectories at all in that folder, just files. Is there
some settings I need to change in my computer? Or is this the network
COBRA problem that I should discuss with our IT guys?

I would really like to start making reservations on Coral as soon as
possible. And since I'm off-site, getting remote Coral set up is very
urgent. Your help is greatly appreciated. Thanks!


Yiching
Coral name: yiching

--
Yiching Liang
R&D Engineer, IonWorks
Molecular Devices
1311 Orleans Dr.
Sunnyvale, CA 94089
Direct: 408-548-6011
Fax: 408-747-0965


From shott at snf.stanford.edu  Wed Dec  3 15:49:46 2003
From: shott at snf.stanford.edu (John Shott)
Date: Wed, 03 Dec 2003 15:49:46 -0800
Subject: Remote Coral Problem
In-Reply-To: <sfcdf559.070@MDGW2.moldev.com>
References: <sfcdf559.070@MDGW2.moldev.com>
Message-ID: <3FCE769A.1040200@snf.stanford.edu>

Yiching:

It would be useful if you could generate a full set of diagnostics ...

You can do this by:

1. Starting up Java Web Start (there should be either an Icon on your desktop 
or something in your Start menu if JWS has been properly installed.

2. Go to the preferences menu item and click it.  THis will open a window with 
3 or 4 panels.  Open the "Advanced" which should then allow you to select 
logging and a file name:  Anything will do ... something where you can find 
the file like:
C:\JavaWS.txt

3. Then exit that java web start session and try to re-start remote coral. 
Hopefully this will generate some useful details in C:\JavaWS.txt.  Send me 
that file and I'll try to help ...

John




From Yiching_Liang at MolDev.com  Mon Dec  8 16:19:18 2003
From: Yiching_Liang at MolDev.com (Yiching Liang)
Date: Mon, 08 Dec 2003 16:19:18 -0800
Subject: Coral password problem
Message-ID: <sfd4a497.042@MDGW2.moldev.com>

Hi-

I am having problem changing my pre-assigned Coral password. 

>From a Sun terminal inside the lab, I followed the instructions I got,
and ran the command "ssh snf" under a console terminal. From there, I
changed my password and closed the window. But after I logged out of
Coral and tried to log back in, I still have to use the old pre-assigned
password to log in. But after I log in, if I do "ssh snf" again, it
recognizes my new password. I did this several times and it's still the
same. So somehow my password was changed for the ssh connection, but not
in the main login screen. 

This is not a critical problem, but I'd like to get it resolved so I can
use a password that is easier to remember. Thanks!


Yiching
coral name: yiching

--
Yiching Liang
R&D Engineer, IonWorks
Molecular Devices
1311 Orleans Dr.
Sunnyvale, CA 94089
Direct: 408-548-6011
Fax: 408-747-0965


From shott at snf.stanford.edu  Tue Dec  9 07:35:11 2003
From: shott at snf.stanford.edu (John Shott)
Date: Tue, 09 Dec 2003 07:35:11 -0800
Subject: Coral password problem
In-Reply-To: <sfd4a497.042@MDGW2.moldev.com>
References: <sfd4a497.042@MDGW2.moldev.com>
Message-ID: <3FD5EBAF.1030000@snf.stanford.edu>

Yiching:

I don't know where you got those instructions ... but it only takes care of 
half of the problem.  There are actually 2 machines on which you need to 
change your password ... you changed your password on the machine named snf, 
but you didn't change it on the machine on which you login to coral.

So, log into one of the sunrays ... and then directly type the command 
"passwd" on that machine which will let you change your normal "Coral password".

Good luck,

John





From shott at snf.stanford.edu  Tue Dec  9 15:09:35 2003
From: shott at snf.stanford.edu (John Shott)
Date: Tue, 09 Dec 2003 15:09:35 -0800
Subject: Final shutdown of "old style" accounts and projects ....
Message-ID: <3FD6562F.1000904@snf.stanford.edu>

Jane, Bill, and Mike:

I think that it is finally time to shutdown all of the old style projects and 
accounts.

I propose shutting them down with a manual SQL command that will give them an 
edate of '01-Dec-2003'.  I believe I can find the ones that need to be 
shutdown by selecting those things where:

UPDATE account
SET edate = '01-Dec-2003', active = 0
WHERE name(length) = 7 and (name like '1%' or name like '2%' or name like 
'9%') and active = 1 and edate is null;

Then, I think that I can do equivalent things for the project, charges_to, and 
works_on tables.

This will occasionally result in someone who hasn't got their numbers 
converted not being able to fire up Coral ... but, they've all had numerous 
warnings.  The only thing that I may do is contact Eric P (who still has a 
handful of oldstyle account numbers) and see which of those should still be 
active.

Thanks,

John




From shott at snf.stanford.edu  Fri Dec 12 08:38:45 2003
From: shott at snf.stanford.edu (John Shott)
Date: Fri, 12 Dec 2003 08:38:45 -0800
Subject: Reboot and sluggish behavior ....
Message-ID: <3FD9EF15.3090307@snf.stanford.edu>

Bill and Mike:

I just rebooted the servers at about 8 a.m. ... they didn't have a problem, 
but I wanted to restart the rscmgr after all of the old style accounts and 
projects had been deactivated.

While I can't imagine why a reboot would have made a difference, at the moment 
the Coral client on Sunstar is behaving in an extremely sluggish fashion ... 
it takes forever to respond to mouse clicks and get things repainted.  The 
load on both sunstar and on atu is virtually 0 and I/O waits are also low.

So, I can't quite figure what is going on.  Does anyone know of anything else 
going on?  While the resource client could be behaving badly if I did 
something silly in terms of hiding/showing inactive members/projects/accounts 
(although that client has been released for a couple of weeks) ... I can't 
figure out why the "normal" client would be slow even if I did screw anything up.

I'm about to go up and run a client on the sunstar console and a remote client 
to see if there is any evidence of a network problem.

Talk to you later,

John




From shott at snf.stanford.edu  Fri Dec 12 09:02:57 2003
From: shott at snf.stanford.edu (John Shott)
Date: Fri, 12 Dec 2003 09:02:57 -0800
Subject: Coral clients are no longer sluggish ...
Message-ID: <3FD9F4C1.7050608@snf.stanford.edu>

Bill and Mike:

I don't know what was going on a few minutes ago ... but by the time I ran a 
Coral client on the sunstar console, it was fine, and when I went back down to 
run it on a sunray, it was also fine.  So, sorry for the false alarm ... while 
I don't know what caused this sluggish client behavior, it seems to have gone 
away.

John




From shott at snf.stanford.edu  Tue Dec 16 02:02:33 2003
From: shott at snf.stanford.edu (John Shott)
Date: Tue, 16 Dec 2003 02:02:33 -0800
Subject: Atu reboot ...
Message-ID: <3FDED839.4060600@snf.stanford.edu>

Bill and Mike:

Funny what some folks think of as an emergency at 1 a.m. ... I got a call at 1 
a.m. from someone in the lab notifying me that Coral was dead.

 From home I could get to snf and some of the other machines (but not atu) as 
root ... but not as myself which led me to believe that atu wasn't up enough 
to have the RAID mounted.

When I got in, atu had tried to reboot ... but had gotten to the "run fsck 
manually" stage.

So, I ran fsck manually and it asked if I wanted to fix 6-8 things.  All but 
one of them were "counts" that were 0 and should have been 2 on /home/User.

In any event, after running fsck, it began to reboot normally ... although it 
did take time to spit out a crash dump for the machine named reef ... which, 
to be honest, seemed a little strange.  That stuff is sitting in /var/crash ...

So, I don't know what brought us down, but we are back up ... and the 
"emergency" have been averted.

Talk to you later,

John