From mbell at snf.stanford.edu  Wed Jan  3 09:39:50 2001
From: mbell at snf.stanford.edu (Mike Bell)
Date: Wed, 03 Jan 2001 09:39:50 -0800
Subject: Bopeep - louder than a flock of sheep
Message-ID: <3A5363E6.B2CBA6A8@snf.stanford.edu>

John and Bill,

Bopeep has become progressively louder, so, with my sanity hanging by a
thread, I shut off the machine this morning. The blissful quite makes me
wonder if my office mate has an off switch as well - just kidding. 

If I don't hear from either of you, I plan to -

move Bopeep up to the computer room and power it back up 

figure out which internal hard drive is the culprit and replace it 

I will also copy the db1 db2 and db3 directories that I copied off Rosen
to bopeep as well.

I will do this by the end of today unless we need it sooner.

Thanks,

Mike


From WingoHuang at aol.com  Fri Jan  5 14:55:59 2001
From: WingoHuang at aol.com (WingoHuang at aol.com)
Date: Fri, 5 Jan 2001 17:55:59 EST
Subject: Problem with installation of remote Coral
Message-ID: <cd.a2a912.2787aaff@aol.com>

Dear SNF Coral Development Team:

  When I tried to install Web Start Program, I encountered some problem. The 
error message said "bad installation, problem with Java VM (SysExec)". I am 
using Window2000. When I tried to remove the installed program, it said bad 
installation, however the program was removed. I retried again, still same 
error message. Is there any suggestion? Thanks

Wingo


From jeffreys at stanford.edu  Wed Jan 10 18:41:37 2001
From: jeffreys at stanford.edu (Jeffrey Snodgrass)
Date: Wed, 10 Jan 2001 18:41:37 -0800
Subject: Fwd: failure notice
Message-ID: <4.2.0.58.20010110183934.013ed520@jeffreys.pobox.stanford.edu>


Another thing.  Seems silly to fail a message without a

>Date: 10 Jan 2001 19:04:55 -0000
>From: MAILER-DAEMON at snf.stanford.edu
>To: jeffreys at Stanford.EDU
>Subject: failure notice
>
>Hi. This is the qmail-send program at snf.stanford.edu.
>I'm afraid I wasn't able to deliver your message to the following addresses.
>This is a permanent error; I've given up. Sorry it didn't work out.
>
><coral at snf.stanford.edu>:
>ezmlm-reject: fatal: Sorry, I don't accept message with empty Subject (#5.7.0)
>
>--- Below this line is a copy of the message.
>
>Return-Path: <jeffreys at stanford.edu>
>Received: (qmail 29143 invoked from network); 10 Jan 2001 19:04:55 -0000
>Received: from smtp.stanford.edu (171.64.14.23)
>   by snf.stanford.edu with SMTP; 10 Jan 2001 19:04:55 -0000
>Received: from galaxie (galaxie.Stanford.EDU [171.64.118.51])
>         by smtp.Stanford.EDU (8.11.1/8.11.1) with ESMTP id f0AJ4sd13498
>         for <coral at snf.stanford.edu>; Wed, 10 Jan 2001 11:04:54 -0800 (PST)
>Message-Id: <4.2.0.58.20010110104212.00aba3e0 at jeffreys.pobox.stanford.edu>
>X-Sender: jeffreys at jeffreys.pobox.stanford.edu (Unverified)
>X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
>Date: Wed, 10 Jan 2001 11:04:37 -0800
>To: coral at snf.stanford.edu
>From: Jeffrey Snodgrass <jeffreys at stanford.edu>
>Subject:
>Mime-Version: 1.0
>Content-Type: multipart/alternative;
>         boundary="=====================_168421417==_.ALT"
>
>--=====================_168421417==_.ALT
>Content-Type: text/plain; charset="iso-8859-1"; format=flowed
>Content-Transfer-Encoding: quoted-printable

>Dear Coral People,
>
>Does this program actually work?
>
>I've installed java web start on four different machines on campus.
>(Win95, Win98, WinNT and Win2000)
>and it has never come close to working.
>Whenever I go back to this page:
>
>http://snf.stanford.edu/Labmembers/RemoteCoral.html
>
>I always get this message:
>
>=B7       Need to install Java Web Start
>=B7       Need to install Java Web Start (Note: Extreme Caution!!!)
>=B7       Download Java Web Start
>
>Despite having successfully installed the Java Web Start *and*
>the Java 1.3 Standard Runtime Environment.
>(I can successfully run the demos that come with the program
>as well as other Java programs on the Sun site.)
>
>--
>
>I was about to send the complaint above,
>when I found the problem.  The javascript does not appear to work with
>any version of Internet Explorer that we have installed.
>(5.5, 5.1, 5.0)
>
>It does however work with Netscape 4.08.  Has anyone else notice this?
>
>Jeff
>
>--=====================_168421417==_.ALT
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>
>Does this program actually work?
>
>I've installed java web start on four different machines on campus.
>(Win95, Win98, WinNT and Win2000)
>and it has never come close to working.
>Whenever I go back to this page:
>
><3d.htm>http://snf.stanford.edu/Labmembers/RemoteCoral.html<= br>
>I always get this message:
>
>=B7     Need to install Java Web Start
>=B7     Need to install Java Web Start (Note: Extreme Caution!!!)
>=B7     Download Java Web Start
>
>Despite having successfully installed the Java Web Start *and*
>the Java 1.3 Standard Runtime Environment.
>(I can successfully run the demos that come with the program
>as well as other Java programs on the Sun site.)
>
>--
>
>I was about to send the complaint above,
>when I found the error.  Your setup does not appear to work with
>any version of Internet Explorer that we have installed.
>(5.5, 5.1, 5.0)
>
>It does however work with Netscape 4.08.
>
>Jeff
>
>--=====================_168421417==_.ALT--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://snf.stanford.edu/pipermail/coral/attachments/20010110/ac8220b4/attachment.html>

From shott at snf.stanford.edu  Wed Jan 10 19:27:15 2001
From: shott at snf.stanford.edu (John Shott)
Date: Wed, 10 Jan 2001 19:27:15 -0800
Subject: Fwd: failure notice
References: <4.2.0.58.20010110183934.013ed520@jeffreys.pobox.stanford.edu>
Message-ID: <3A5D2813.A0D89DA8@snf.stanford.edu>

Jeff:

I checked and found that Sun's documentation had a bug in their VBScript that
determines whether Java Web Start is installed ... that affects Internet
Explorer but not Netscape.

Now that you know that you have things installed properly (as far as Netscape
is concerned) would you mind going to the snf page with Internet Explorer
where it says either "Download Remote Coral" or "You need to install Java
WebStart" and see if it now says "Download Remote Coral"? (Note: you may have
to either purge the cache or reload that page a couple of times to make sure
that it gets my updated version instead of pulling the old version from the
cache.

I don't seem to have IE on my machine ...

Thanks for the tip that IE was dead in the water ... I hope this helps the
situation.

John


From hopcroft at snf.stanford.edu  Wed Jan 10 23:00:05 2001
From: hopcroft at snf.stanford.edu (Matt Hopcroft)
Date: Wed, 10 Jan 2001 23:00:05 -0800 (PST)
Subject: crash Wed night
Message-ID: <Pine.LNX.4.04.10101102258430.3052-100000@snf.stanford.edu>


Hi,
	Coral crashed Wednesday night around 9pm. I had the nikon and
drytek2 enabled, and I can't disable them. Please disable and credit my
time. login name hopcroft. Thank you,

-Matt


Matt Hopcroft
hopcroft at snf.stanford.edu
650.736.2380



From mbell at snf.stanford.edu  Thu Jan 11 11:02:35 2001
From: mbell at snf.stanford.edu (Mike Bell)
Date: Thu, 11 Jan 2001 11:02:35 -0800
Subject: netscape problems
Message-ID: <3A5E034B.50F453D7@snf.stanford.edu>

John and Bill,

FYI-

I've run into at least 2 cases in which I was told by a member they
couldn't get remote Coral to work and that the options to Launch remote
Coral were not on the web page.  Turns out all they need to do is go
into edit -> preferences ->advanced ->cache and "clear memory cache" and
"clear disk cache". Then the "new version" of the web page shows up and
we live happily ever after. 

John - I can send email to labmembers if you think this might be a
widespread problem. I'm not sure why it happens because netscape
typically does a compare at least once each session. I think it might be
a bug. I hear version 6 of Netscape is REALLY bad.  I can hardly wait.

Also, this may be a problem in the future if we change the webpage.

Mike


From mbell at snf.stanford.edu  Thu Jan 11 11:53:11 2001
From: mbell at snf.stanford.edu (Mike Bell)
Date: Thu, 11 Jan 2001 11:53:11 -0800
Subject: [Fwd: tycom access on crystal.stanford.edu]
Message-ID: <3A5E0F27.9D828AC6@snf.stanford.edu>

John and Bill,

Brian has checked this as recently as today and is unable to get the
information he needs. Let me know if there is a course of action I can
assist with.

Mike
-------------- next part --------------
An embedded message was scrubbed...
From: Brian Joseph Greene <bgreene at stanford.edu>
Subject: tycom access on crystal.stanford.edu
Date: Thu, 11 Jan 2001 11:06:49 -0800 (PST)
Size: 1681
URL: <http://snf.stanford.edu/pipermail/coral/attachments/20010111/342f70bb/attachment.mht>

From bgreene at stanford.edu  Thu Jan 11 17:55:29 2001
From: bgreene at stanford.edu (Brian Joseph Greene)
Date: Thu, 11 Jan 2001 17:55:29 -0800 (PST)
Subject: [Fwd: tycom access on crystal.stanford.edu]
In-Reply-To: <3A5E0F27.9D828AC6@snf.stanford.edu>
Message-ID: <Pine.GSO.4.05.10101111750390.12696-100000@cvd.Stanford.EDU>

Folks,
  I was able to find the information I needed since all the tylan recipes
are stored in /micro/micro/labroot/lib/recipes/tylan on crystal, so there
is no longer a need to fix this on my behalf.

Thanks,
Brian
_____________________________________________________________
  Brian J. Greene                 Office: CIS-X 128X         
  Applied Physics Dept, MC 4090   Phone: (650) 723-4194 ext 5 
  Stanford University             Pager: (650) 354-9687       
  Stanford, CA  94305-4090        Fax: (650) 723-4659 


On Thu, 11 Jan 2001, Mike Bell wrote:

> John and Bill,
> 
> Brian has checked this as recently as today and is unable to get the
> information he needs. Let me know if there is a course of action I can
> assist with.
> 
> Mike



From ctull at photonimaginginc.com  Fri Jan 12 11:44:32 2001
From: ctull at photonimaginginc.com (Carolyn Tull)
Date: Fri, 12 Jan 2001 11:44:32 -0800
Subject: can't launch remote Coral
Message-ID: <001501c07cd0$163e5740$c22a1018@wntck1.sfba.home.com>


----- Original Message ----- 
From: Carolyn Tull 
To: coral at snf.standford.edu 
Sent: Friday, January 12, 2001 11:29 AM
Subject: cant launch remote Coral


Dear Coral people:

I am having trouble loading the Remote Coral application.  However, I believe the problem is not
with Coral, but with Java Webstart, since I also cannot launch any of the demos from the
java.sun.com  web site:

1) I downloaded Java Webstart with what seemed like no problems (using Internet Explorer, Windows 95)

2)  When I go to the SNF web site and try to launch Remote Coral, I get an error message  reading:
"Unable to load resource  http://snf.stanford.edu/coral/etc/coral.jnlp"

3) When I try to launch a demo from the Sun website, I get a similar error message:
"Unable to load resource  http://java.sun.com/products/javawebstart/apps/mg.jnlp

Any advice for me????

Thank you for any help you can give me.

-Carolyn Tull, industrial user
Photon Imaging, Inc.
925-519-1256
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://snf.stanford.edu/pipermail/coral/attachments/20010112/5d915d2e/attachment.html>

From mbell at snf.stanford.edu  Fri Jan 12 12:33:07 2001
From: mbell at snf.stanford.edu (Mike Bell)
Date: Fri, 12 Jan 2001 12:33:07 -0800
Subject: can't launch remote Coral
References: <001501c07cd0$163e5740$c22a1018@wntck1.sfba.home.com>
Message-ID: <3A5F6A03.1A3263AA@snf.stanford.edu>

Carolyn,

Are you behind a firewall?

Mike Bell


From shott at snf.stanford.edu  Fri Jan 12 15:40:12 2001
From: shott at snf.stanford.edu (John Shott)
Date: Fri, 12 Jan 2001 15:40:12 -0800
Subject: can't launch remote Coral
References: <001501c07cd0$163e5740$c22a1018@wntck1.sfba.home.com>
Message-ID: <3A5F95DC.26D1C3D2@snf.stanford.edu>

Carolyn:

One thing that you might try related to launching of remote Coral ...

1. Exit the current verion of javawebstart ... if it is running.

2. Fire up the "Task Manager" (by right-clicking on a non-icon part of the
task bar.

3. Scroll down the list of running processes and look for any that say
javaw.exe (which is the executable of Java Web Start). If there are any,
select each one and click "End Process".

Once they are all gone, fire up Java Web Start and try again.
Also, under the "Edit"/"Preferences" menu item on Java Web Start, click 
"Advanced" and check the "Log Output" and select some file name to use for
logging.  I use D:\Home\JavaWS.txt ... but anything should work.

That way, if you continue to have problems, you can send me a copy of that log
file and it should contain some error messages that may help to pinpoint the
problem ... 

Good luck,

John

p.s. If you are behind a firewall, what I have suggested may not help ...


From shott at snf.stanford.edu  Tue Jan 16 09:24:06 2001
From: shott at snf.stanford.edu (John Shott)
Date: Tue, 16 Jan 2001 09:24:06 -0800
Subject: Event Manager ...
Message-ID: <3A6483B5.522FFEEC@snf.stanford.edu>

Bill and Mike:

I've spent some time looking at the event manager code and also playing around
with some modifications that, I think, will improve things somewhat.  However,
there are also a couple of things that are less easy to do but, would probably
improve performance.

Virtually all of the stuff I've found of note lives in the file
labnet/event/server/EventManagerImpl.java.  The versions that I've been
playing with are either in ~shott/labnet or /home/labnet/.prod-install/labnet.

Most of the things that I've found and been looking at are in the postEvent
method ... with a couple of minor things in the unsubscirbeAll method.

I've also tried to add some performance monitoring logging that I'll describe
briefly.

Basically, the core of the event server is a single vector called subscribers
that maintains a list of each subscriber and the event to which they are
subscribing.  The method postEvent basically looks through this vector for a
match between the eventID of the posted event and that of each
subscriber/event pair.  If the eventIDs match, it tries to post the event to
that subscriber. If it fails, is assumes that that subscriber no longer exists
and tries to do an "unsubscribeAll".  At this level, this all seems logical
and clean.  However, there are a couple of deficiencies .... 

1. The current code isn't doing a great job of cleaning up after itself when
clients die ... I think that I've found part of that reason, but maybe not
everything.  The end result of this is that the vector subscribers grows
nearly monotonically in size.  This is, I believe the  primary reason that the
event server gets slow over time.  With the improved logging that I'll
descirbe shortly, we should be able to quantify this performance and/or
degradation.

2. There is a single subscribers vector that contains subscripritons for all
events for all clients.  That vector has to be searched completely for every
posting ... this is inefficient because each event has only one ID, but it
looks through all of the subscriptions for all of the events any how.

Before I talk about specific changes, let me talk about the performance
logging that I have added ... in fact, I've added this incrementally, and some
of the things that I've added have already helped me to understand
deficiencies in the currrent implementation.

Since the postEvent method is the core of the event server, I've concentrated
on the logging there.

For each postEvent, I now print the current time, the eventID, the size of the
subscribers vector, the number of successful postings, and the number of
failed postings.
I also log the difference in time between the timestamp of the incoming event
(I'm not 100% sure, but I think that this is the time that the relevant server
received a request for action from the client) and when postEvent starts. 
Finally, I log the amount of time that postEvent itself uses.

A typical entry in evtmgr.log now looks like:
2001-01-15 14:23:35 Posted event: 102 (51, 4, 0) Elapsed time: 20 + 6 msec

>From watching these logs, it is clear that the size of the vector subscriber
grows and that we aren't getting complete cleanup ... This is true even if a
user properly uses the "Exit" on the client. This caused me to look at the
unsubscribeAll(obj) and unsubscribe(obj, eventID) methods where obj is an
EventSubscriber. The unscubribe methods basically search through the
subscribers vector and compares the ior of the subscriber to the ior of the
person wishing to unsubscribe.

Here I've found 2 things: One minor and one important:

The minor thing: The ior of the person wishing to unsubscibe (objior) is
determined each time in the looping through the vector when it only needs to
be determined once prior to the entry into the loop.

The major thing:  David use an Enumeration to loop through the elements of
subscribers.  If he finds a match (in other words, a subscription to be
removed), he removes it using subscribers.removeElement.  I beleive that this
causes an error and that we don't remove everything that we should be removing
on a single pass:  For example, if we are currently examining element 15 and
remove it, then original element 16 becomes element 15 ... and the next time
through the Enumeration we examine new element 16 (which is original element
17) ... and failed to examing element 16.  Because subscriptions from a single
IOR are added sequentially, this has the end result of only removing half of
the subscriptions that we should be removing.

I beleive that we should be using an Iterator instead of an Enumerator  ...
the Iterator has the iterator.remove() method that removes the current element
of whatever is being iterated ... but when you then say iterator.next(), you
get the true next element instead of passing over  the next one as happens
with an Enumerator.  Note: Apparently Iterators are not thread safe ... but,
if I understand things correctly, the fact that the unsubscribe(),
unsubscribeAll(), and postEvent() methods are synchronized solves this
problem.

I now have a version of the event server running that uses an Iterator (and
pulls the determination of objior out of the iteration).  This has been
running since Sunday ... I'd like to shut it down at the end of the day and
rerun the origianl version (but with performance logging outlined above) to
see what improvements we have made.

Even with these changes, however, performance degrades over time becuase we
still don't get full cleanup and (I think) because we have one giant
subscribers vector.  Actually, if people do an "Exit" we get full cleanup now
... this is seen in the log file as a sequence of 5 entries that look like:
Client close removing: 6 subscriptions.
Client close removing: 0 subscriptions.
Client close removing: 4 subscriptions.
Client close removing: 0 subscriptions.
Client close removing: 2 subscriptions.
(Note: the order doesn't have to be the same ... but the equipment client
subscribes to 6 events, the maintenance client subscribes to 4, the
reservation client subscribes to 2 and the history and staff clients don't
subscribe to anything).

There are also lots of log entries that only have a single line:
Client close removing: 6 subscriptions.
that is preceded by:
sub.postedEvent: org.omg.CORBA.COMM_FAILURE: minor code: 1 completed: No

This is a case where a postEvent() didn't answer and adds that subscriber to
the badsubs vector and then tries to unsubscribe from all events for that
subscriber.  However, that is only one of the clients belonging to a "client
session".  (Note: usually it is the equipment client because there are more
equipment events than any other kind ...). As a result, the size of
subscribers is larger than it should be for folks who don't exit properly
because they have to fail to receive an event for the equipment client, for
the maintenance client, and for the reservation client before they are fully
cleaned out of the subscribers vector.  (Note: of course folks who still have
valid, but inactive sessions also cause the subscribers vector to be larger
than it should).

What additional things could or should be done:

1. (Fairly easy, I think) ... currently any excpetion in the try/catch block
of postEvent() is assumed to be a dead client.  To be precise, we should try
to catch COMM_FAILURE events with minor code: 1 as a "dead client" ... and
still catch and report other errors which might be trying to tell us something
different.

2. (Not too hard ... I think)  We should try to break subscribers into
multiple lists of subscribers ... for example, if we had a separate
subscribers vector for each event (maybe call them subscribers_101,
subscribers_102, etc. ...)
Then  a call to postEvent(Timestamp aTimestamp, long loid, Any news)
would take the eventID (loid), determine the proper subscriber vector to call
(using maybe a small hashtable with eventID as a key) .. and then call
postEvent(Timestamp, Vector event_subscribers, Any news).  On anverage, each
of the 10 or so lists would only be 1/10 as long as the current subscribers
list.  Plus, I think that it might be possible to handle posting to different
events (101 vs. 108, for example) "simultaneously" if we allowed that to
happen on multiple threads ... although I'm out of my element understanding
threads.

Note: Unsubscribe all would have to go through all 10 or so lists ... but the
total number of elements is no more than it would have been the old way.

3. (Not so easy ...) To do a better job of "cleaning up" a COMM_FAILURE from
one client should not only unsubscribe to all events assoicated with that IOR
but with all events associated with all of the IORs associated with a
particular cleint ... at the moment, however, I don't know that we know that
information .... although I bet that a combination of the auth manager and the
admin manager probably could put that information together.  However ... this
sounds like a lot of work, and I'm not sure that it would be worth it unless
we made the other changes and still determined that the event manager
performance was still degrading.

My current plan is to try to look a the evtmgr.log today ... then probably try
to restart the performance monitoring old version tomorrow to see if the
Iterator changes (in particular) have improved anything significantly.  

I apologize for the length of this message, but thought I'd try to write down
what I've learned and observed. Any thoughts, feedback, and reactions, would
be most welcome.

Thanks,

John


Well, I ap


From shott at snf.stanford.edu  Tue Jan 16 10:28:19 2001
From: shott at snf.stanford.edu (John Shott)
Date: Tue, 16 Jan 2001 10:28:19 -0800
Subject: evtmgr.log
Message-ID: <3A6492C3.F3184A7C@snf.stanford.edu>

Bill and Mike:

Periodically, we have some very log event posting times ... sometimes as long
as 200-400 SECONDS!!!! These always seem to occur when there are clients that
are found to be no longer there ... of course, if there is a following event
that comes in during that time, it ends up with a large "first time" in the
log (the difference between when the event occured and when postEvent() begins
working on it) because it has to wait until postEvent() from the preceeding
event is done.

I should probably go in an time each occurrence of unsubscribeAll() so that I
can determine whether it is delays in the actual posting (sub.postedEvent in
the main part of postEvent()) or in the "cleanup part" of postEvent() where it
does unsubscribeAll(sub.subscriber()).

While these log files get to be pretty large ... I think that there are some
intersting numbers in there ...

Talk to you later,

John


From bmurray at snf.stanford.edu  Tue Jan 16 10:55:08 2001
From: bmurray at snf.stanford.edu (Bill Murray)
Date: Tue, 16 Jan 2001 10:55:08 -0800 (PST)
Subject: Event Manager ...
In-Reply-To: <3A6483B5.522FFEEC@snf.stanford.edu>
Message-ID: <Pine.LNX.4.04.10101161046280.23780-100000@snf.stanford.edu>

John,

I'm reviewing the event manager code as I read through your email.  I'll
call you later to discuss.  

I think we should segregate your JDK 1.3 changes as a separate branch in
the source tree.  This should allow us to keep all the changes you've
made to accomodate 1.3 while we're waiting for a more robust 1.3.  This
should also allow us to continue with bug fixes (event manager) and
enhancements under both the 1.2 and 1.3 versions of the JDK.  I'll take
a look at this when I'm in the office tomorrow.

Mike should have the new xemacs profile ready to try out tomorrow also.

How frequently do you need to restart the servers?  Are the restarts
required for any reason other than event manager problems?

Thanks,
Bill 
 





From shott at snf.stanford.edu  Tue Jan 16 15:13:49 2001
From: shott at snf.stanford.edu (John Shott)
Date: Tue, 16 Jan 2001 15:13:49 -0800
Subject: Number of successful postings ....
Message-ID: <3A64D5AD.357ACBAA@snf.stanford.edu>

Bill and Mike:

In looking at evtmgr.log, I'm seeing some strange behavior ... in particular,
if we believe that a posting that results in errors from either a maintenance
client, a reservation client, or an equipment client should result in a
cleanup of each subscription list so that all events should successfully post
to the same number of clients (except for things like problems and shutdown
that should post to 2x number of clients).  So, what I have been seeing is a
little wierd ...

Following are some annotated logs when I exercised bottlewash while the lab
was fairly heavily loaded:

Enable:
2001-01-16 14:44:19 Posted event: 101 (1461, 86, 0) Elapsed time: 9 + 701 msec
Disable:
2001-01-16 14:44:37 Posted event: 102 (1461, 86, 0) Elapsed time: 2 + 321 msec
Problem:
2001-01-16 14:45:13 Posted event: 104 (1461, 264, 1) Elapsed time: 3 + 2266
msec
Problem clear:
2001-01-16 14:45:53 Posted event: 106 (1473, 179, 0) Elapsed time: 40 + 378
msec
Problem clear all:
2001-01-16 14:45:53 Posted event: 108 (1473, 86, 0) Elapsed time: 471 + 333
msec
Reservation:
2001-01-16 14:46:46 Posted event: 201 (1473, 118, 0) Elapsed time: 8 + 773
msec
Reservation delete:
2001-01-16 14:46:52 Posted event: 202 (1473, 118, 0) Elapsed time: 9 + 770
msec
Shutdown:
2001-01-16 14:51:03 Posted event: 103 (1455, 263, 0) Elapsed time: 2 + 576
msec
Shutdown clear:
2001-01-16 14:51:29 Posted event: 107 (1455, 178, 0) Elapsed time: 66 + 494
msec
Shutdown clear all:
2001-01-16 14:51:29 Posted event: 109 (1455, 84, 0) Elapsed time: 564 + 183
msec

If we believe that all clients are fully in sync, then I would have thought
that all events should have been reported to approximately 86 clients ...
well, except for problem, problem clear, shutdown, and shutdown clear that
actually get reported to both the maintenance clients and the equipment
clients.

The strangeness that I see is that problems and shutdowns seem to go to about
3x the number of active clients whereas I would have thought they should go to
2x the number of active clients (mainenance client and the equipment client). 
It makes me think that we are not handling subscription to the problem and
shutdown events properly and that either the maintenance client or the
equipment client is double subscribing.

Also, the number of reservations postings is rather wierd ... 118 instead of
86 or so.  I don't know what this means ...


From hopcroft at snf.stanford.edu  Thu Jan 18 17:58:03 2001
From: hopcroft at snf.stanford.edu (Matt Hopcroft)
Date: Thu, 18 Jan 2001 17:58:03 -0800 (PST)
Subject: terminal down
Message-ID: <Pine.LNX.4.04.10101181757020.23347-100000@snf.stanford.edu>


Hi,
	The sunray terminal in the lithography area, opposite the ovens,
is not working. It has a green light, as though there is a card in the
slot, but there is not card, and no signal to the monitor.

Matt Hopcroft
hopcroft at snf.stanford.edu
650.736.2380



From tkramer at stanford.edu  Mon Jan 22 10:21:29 2001
From: tkramer at stanford.edu (Theresa Kramer)
Date: Mon, 22 Jan 2001 10:21:29 -0800 (PST)
Subject: crystal connection to tycom
Message-ID: <Pine.GSO.4.31.0101221020380.3294-100000@saga16.Stanford.EDU>


The crystal connection to the tycom appears to be broken again.  I can't
check furnace status on crystal.

Theresa




From shott at snf.stanford.edu  Thu Jan 25 11:03:23 2001
From: shott at snf.stanford.edu (John Shott)
Date: Thu, 25 Jan 2001 11:03:23 -0800
Subject: Thinking about SECS ...
Message-ID: <3A70787B.7AC522C5@snf.stanford.edu>

Bill and Mike:

I know that we are not there yet ... but following are two links that appears
to be offering pieces and parts of what would be required to communicate to
fabrication equipment using SECS-I and SECS-II communications standards ...
but using Java and (I think) also seem to mention use of things like CORBA,
XML, etc ...

So, here are a couple of references for future examination ... 

www.ergotech.com/secsgem and www.jsecs.com

Note:  Just so that we have it, the "main" supplier of SECS communication
stuff (although I think their stuff is either C or, at most, C++) is GW
Associates at www.gwainc.com

Thanks,

John


From hopcroft at snf.stanford.edu  Wed Jan 31 20:01:32 2001
From: hopcroft at snf.stanford.edu (Matt Hopcroft)
Date: Wed, 31 Jan 2001 20:01:32 -0800 (PST)
Subject: multiple account order
Message-ID: <Pine.LNX.4.04.10101311959030.25267-100000@snf.stanford.edu>


Hi,

	Can I change the order that my billing accounts appear in the
Coral dialogs? The account I use the least is now the default. Thank you,

-Matt

Matt Hopcroft
hopcroft at snf.stanford.edu
650.736.2380