From bmurray at snf.stanford.edu Fri Jun 1 21:07:10 2001 From: bmurray at snf.stanford.edu (Bill Murray) Date: Fri, 1 Jun 2001 21:07:10 -0700 (PDT) Subject: Great Progress Message-ID: Mike and John, Everything compiles and runs. I'm tracking down bugs. Heading home for dinner. Will keep you updated. I hope to finish this weekend so that I can go to JavaOne on Monday. Hope to sign up at the door. Bill From Jdas at activeoptical.com Tue Jun 5 14:29:49 2001 From: Jdas at activeoptical.com (John Das) Date: Tue, 5 Jun 2001 14:29:49 -0700 Subject: Java Webstart 1.0.1 keeps giving out "unable to load.." error message Message-ID: <639B8C163707B3429AE22ACC0C3190B703F987@newton.activeoptical.com> Hi I have recently started working at the SNF. My coral user id is 'jdas' I was able to download and initiate the remote access Java Webstart 1.0.1, Every time I activate the remote Access, the Small Java 1.0.1 window comes on, but it keeps giving the same error message like "Unable to load resource: http/...../Coral.jnlp" not quite sure if I my desktop is correctly setup. I am using A Dell computer with "Windows 2000" Thank you very much for your help. Sincerely John Das From shott at snf.stanford.edu Thu Jun 7 12:08:24 2001 From: shott at snf.stanford.edu (John Shott) Date: Thu, 07 Jun 2001 12:08:24 -0700 Subject: J2SE 1.4 beta install on guilden ... Message-ID: <3B1FD128.DE3D138@snf.stanford.edu> Bill and Mike: Because of disk space shortages on guilden, I installed the 1.4beta version of j2se in /app/j2se ... instead of /usr/j2se. I have then made a sybolic link that points from /usr/j2se to /app/j2se. It is my hope that this means that all of our Makefiles, install, and run scripts will work normally ... without any fiddling with those changes. Here is what I propose to do ... all on guilden: 1. I'll create a new directory ~/labnet1.4beta and then do a fresh "cvs checkout -P labnet" there. 2. I'll make the standard changes to make it work under the idlj instead of the idltojava compiler. I will also need to modify the makefile associated with the idl stuff so that it uses the older BaseImpl approach rather than the POA approach. 3. If this works, I'll hope to be able to compile and install the servers ... and see if our old CORBA problems still occur. 4. If we don't have problems ... great!!! If we still have problems we will need to strategize ... One option is going from the Sun ORB to JacORB. Bill, I've downloaded (but not installed ...) the latest version of JacORB. I've also left you a copy of the JacORB 1.3 programming guide. Without being "Mr. ORB", I can see that it offers a few features that we don't seem to have with the Sun ORB. Among them, it offers 3 different levels of logging ... as near as I can tell, the Sun ORB doesn't do any logging but only throws exceptions. JacORB also allows significant amounts of configuration including the number of retries, the time interval between retries, etc. Bill, you'll probably have a lot more to say after reading the JacORB stuff. One thing I notice, however, is that JacORB seems to only support the newer POA approach. I think that means that we can't instantly test out JacORB without knowing a bit more (at least for me ...) about what is involved from converting from an idltojava converter that supports POA vs. BaseImpl. Clearly some of the files are named different things ... but I don't know whether the changes are as mechanical as from going from idltojava to idlj (e.g. changing _ClassOperations to ClassOperations and _ClassTie to Class_Tie). Bill, you probably have a lot to add on the subject based on what you've learned at JavaOne ... I know you talked to the fellow who really liked JacORB ... and I vaguely recall that this evening was the evening that you were going to be able to confront the Sun CORBA team. Talk to you later, John From shott at snf.stanford.edu Fri Jun 8 11:43:33 2001 From: shott at snf.stanford.edu (John Shott) Date: Fri, 08 Jun 2001 11:43:33 -0700 Subject: Resource client "works_on" and "charges_to" functionality ... Message-ID: <3B211CD5.F22D8215@snf.stanford.edu> Bill and Mike: Now that we have the 3-panel template for the resource client (I know that there are things that still need to be added to that portion, but ...), I thought I'd give you my thoughts related to what additional functionality we need to be able to release this. At the moment, for member, project and account, we have "Add", "Edit", and "Delete" in each of their menus. (Note: we still need to decide what we mean when we say "Delete", but ...). The next most important thing, from my perspective, that is the functionality that will let us deal with the "works_on" relationships between member and project and the "charges_to" relationships between project and account. I think that this functionality is a higher priority that searching .... Following is a first pass at defining the menus that I think would be useful for member, project, and account .... For the member menu, I would suggest (using --- as a menu separator, and indentation of some of the "For selected menu ..." sub entries. Suggested Member menu: Add Edit Delete ------ For selected member ... Set default project Add project to list Remove project from list Replace project with ... Show active projects Show all projects Suggested Project menu: Add Edit Delete ------ For selected project ... Set default account Add account to list Remove account from list Replace account with ... Show active accounts Show all accounts Show active members Show all members Suggested Account menu: Add Edit Delete ------ For selected account ... Show active projects Show all projects Here is my description of what I think that each of these menu items should do: The "Set default xxx" would prompt for a project or account, as appropriate, and change the existing project or account field in member or project, respectively, to that value. It would also make sure that the new default was in the charges_to or works_on table and add it if need be. Of course, it would give an error if that project or account didn't exist or wasn't active. (Presumably, clicking on the appropriate project or account would also enter that value). The "Add xxx to list" would prompt for a project or account, as appropriate, and add the appropriate entry to the works_on or charges_to table (but not change the default). The "Remove xxx from list" would prompt for a project or account, as appropriate, and "remove" the appropriate entry from the works_on or charges_to table. Actually, be remove I mean, set active = 0, set edate = SYSDATE, and set revoker = 'whomever is running the application' ... in other works, it makes an entry in either works_on or charges_to inactive. Note: this would also need to give an error if the entry being removed as either the default project or account. The "Replace project with ..." or "Replace account with ..." is probably one of the most important, but also one of the trickest things to do. Part of the reason that this is tricky is that it is often done retroactively to the start of the month (or even the start of last month) ... and appropriate database changes need to be made. Basically, what I view as happening is a popup window with the Old Project, the New Project, and the Effective Date. (I'll do this for changing project ... but similar things should happen for changing account). When they click "OK", here is what I think should happen. 1. Check to see that "Old Project" and "New Project" already exist in the project table. Abort if Old Project doesnt' exist. Abort or maybe prompt for new project if it doesn't exist. 2. Get member/old project entry from works_on: set revoker, edate = 'effective date', active = 0. 4. Get member/new project entry from works_on (or create it if it doesn't exist), set approver, bdate = 'effective date', active = 1. 5. Make appropriate changes in eq_activity, staff_activity, training, inven_activity, and reservation: Change old project to new project, old project's default account to new project's default account where member = 'member' and project = 'old_project' and account = 'old_projects default account' and edate >= 'effective_date' The "Show active xxx" entries should, more or less, show the results of the following queries: select * from (works_on or charges_to) where master = 'this_member or this_project' and active = 1; or select * from (works_on or charges_to) where slave = 'this_project or this_account' and active = 1; Note: whether the query involves "master" or "slave" depends on whether we are searching "downstream" (from member to project to account) or "upstream" (from account to project to member). Of course, the "Show all xxx" would be the same thing ... but without the active = 1 clause. In either case, I envision a popup window with a table with columns that are exactly those in the works_on or charges_to tables: master, slave, approver, revoker, bdate, edate, active. I'm not sure that I've got a strong opinion yet of the degree to which this table should be editable ... I need to think more about that. Sorry about this long winded message ... but I thought that I should try to write down the things that I feel are most important to allow the resource client to be fully functional. In particular, it seems as if juggling entries in the works_on and charges_to tables is a fact of life ... particularly the "oops, this account/project (and all activities) need to be changed effective some date in the past". I'm sure that this will generate questions, discussion, and differences of opinion, but I thought I'd take a stab at writing down my initial thoughts. Thanks, John From bmurray at snf.stanford.edu Sat Jun 9 10:15:30 2001 From: bmurray at snf.stanford.edu (Bill Murray) Date: Sat, 9 Jun 2001 10:15:30 -0700 (PDT) Subject: Rosen Reboot? Message-ID: John and Mike, It looks from my logs like rosen died about 3:00am this morning? I assume one of you rebooted this morning? The coral logs looked okay so I'm assuming it wasn't a Coral problem. Bill From shott at snf.stanford.edu Sat Jun 9 10:19:17 2001 From: shott at snf.stanford.edu (John Shott) Date: Sat, 09 Jun 2001 10:19:17 -0700 Subject: Rosen Reboot? References: Message-ID: <3B225A95.24EF1229@snf.stanford.edu> Bill: Yes, I came in this morning and found that things had died shortly after 3 a.m. I did a reboot ... and things now seem fine. It certainly seems suspicious that all of our "mystery crashes" occur in the 3-4 a.m. time window when you'd think that lab usage would be at a minimum. In any event, I think we are back on the air ... John From mbell at snf.stanford.edu Mon Jun 11 09:09:54 2001 From: mbell at snf.stanford.edu (Mike Bell) Date: Mon, 11 Jun 2001 09:09:54 -0700 Subject: Coral Arcive Problem Message-ID: <3B24ED52.F216527C@snf.stanford.edu> Coral Team, In Len's effort to remain the bug reporting record holder, he found that when you go to equipment archives to check email for - General User Wet Bench (wbgeneral) you get: Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, root at localhost and inform them of the time the error occurred, and anything you might have done that may have caused the error. Premature end of script headers: /home/httpd/cgi-bin/ezmlm-cgi Thanks, Mike From shott at snf.stanford.edu Wed Jun 13 15:01:28 2001 From: shott at snf.stanford.edu (John Shott) Date: Wed, 13 Jun 2001 15:01:28 -0700 Subject: JCE, encryption, etc. Message-ID: <3B27E2B8.4068AE4@snf.stanford.edu> Bill and Mike: I've been doing some snooping to try to figure out why our existing encryption doesn't work under JDK 1.4. I think that I've got a couple of things of interest to report: 1. A possible short term fixe (actually, I found this in learning about how to try to get option 2 to work without a signed jar file). That is, I think that we can "disable" the JCE stuff by doing two things: a. Remove /usr/j2se/jre/lib/jce.jar (actually I renamed it as /usr/j2se/jre/lib/jce.jar.ignore). and b. Remove (well, rename) /usr/j2se/jre/lib/ext/sunjce_provider.jar. To test this, while Bill is dealing with the medical/dental world, I'm going to do a "make prod-install" from ~shott/labnet1.4/labnet ... which will undo what you were working on, Bill, but I think you should be able to reset by re-doing your most recent "make prod-install". I just re-started all of the servers with the non-JCE j2se 1.4 ... and blackbox is initialized, the client fired up, etc!!! If I am not mistaken, I believe this now means that we can convert to j2se 1.4 for further development if we wish. I'll let you make that determination, Bill ... If you want to do that, I think that I have made it easy to checkin the changes that I made to the labnet tree ... I've left the rosen monitor (in CIS 220) locked as root. If you login there, there is only one window opened ... I sshed to guilden as root, "su - shott", and then moved to the directory that has all of the appropriate 1.4 stuff. That is ~shott/labnet1.4/labnet ... in that directory, you will see a file named update.log which is the result of "cvs diff". If you will look at that, you will see that I've made changes to about 25 files: 1. All of the *.idl files have been "bracketed" by the module labnet { module idl{ stuff goes here }; // end of idl }; // end of labnet. 2. All of the this/server/ThisServer.java and this/server/ThisManagerImpl.java (where this = auth, admin, equipment, hardware, reservation, staff, and resource plue a handful of client things ...) have had the _ManagerTie converted to Manager_Tie and _ManagerOperations changed to ManagerOperations. 4. Finally, I made a change to etc/Makefile to allow better selection of JAVA_VERSION = 1.2.2, or 1.3, or 1.4 (with the checked in default as 1.4). So, Bill, in that window, I think that all you need to do is say "cvs commit" and it should do the check-in if you determine that this is appropriate. Good luck, John p.s. Oh yes, the other thing that I wanted to report ... there is a place called Bouncy Castle (www.bouncycastle.org) that seems to be actively working on public-domain encryption stuff and that seem to be further up the learning curve in terms of supporting JCE ... in fact, it was this site where their mailing list told me how to disable jce in JDK 1.4 that allowed me to get the ABA stuff that we are using working again ... While it appears that we may not have any immediate need for their stuff, it looks as if they are more active that either ABA or Cryptix ... In any event, Bill, if you want to begin to work under 1.4, I would suggest that you do the commit up in the machine room of my changes and then do a re-build in your directory to get back the things that you are working on. REMINDER: The servers running currently on Guilden are the 1.4 servers ... not whatever you had been running most recently, Bill. From shott at snf.stanford.edu Fri Jun 15 09:27:48 2001 From: shott at snf.stanford.edu (John Shott) Date: Fri, 15 Jun 2001 09:27:48 -0700 Subject: Makefile, installation, etc. Message-ID: <3B2A3784.B78D093A@snf.stanford.edu> Bill and Mike: I know that you each are either already on vacation or on the verge of being on vacation, but I wanted to let you know what I have been thinking of doing in terms of standard installation that would, I think, make coral install more readily at other sites ... and may streamline the process for us as well. Here is what I am thinking: Default installation directory: /usr/local/coral This would have subdirectories: bin: with stuff like labnet, coral lib: all of the jar files sbin: the servers, newuser, ... scripts. I would also likely create links so that: /usr/local/bin/coral points to /usr/local/coral/bin/coral /usr/local/sbin/servers points to /usr/local/sbin/servers, etc. Note: of course, if we wish, we could override all of that so thour our "home directory" still points to /home/labnet ... As a result, over the coming week, I'll try to modify the Makefiles so that these things begin to happen. Since both of you are doing "real work" on *.java files, my guess is that there is very little chance that we will run into a conflict situation ... but I wanted to let you know what I was thinking of doing and to invite your comments in case there is any problem you see with what I am proposing ... Thanks, John From shott at snf.stanford.edu Mon Jun 18 17:25:18 2001 From: shott at snf.stanford.edu (John Shott) Date: Mon, 18 Jun 2001 17:25:18 -0700 Subject: Supporting different files at different sites ... Message-ID: <3B2E9BEE.594014C4@snf.stanford.edu> Bill and Mike: I realize that you are on vacation and probably don't care about this stuff right now ... and I'm not expecting that you'll read this now ... but I think that I've been making progress on being able to support different source files at different sites. I thought that I'd try to write this down to see if if makes sense to you ... At the moment, in any particular directory we have a set of java files. For simplicity, I'll assume that the name of the java files are FileOne.java and FileTwo.java. Somebody at another site, might be happy with our FileOne.java, but want to modify our FileTwo.java to better meet their needs, and add a third file called FileThree.java that does something that we don't currently support. Our current file structure would be: directory: FileOne.java FileTwo.java What I propose we create is a sub-directory called "site-specific" that would include all of those files that weren't part of the "base distribution". I would propose to have a new structure that would look like: (assuming that mit is the site having the different file names) directory: FileOne.java FileTwo.java site-specific: FileTwo.java,mit FileThree.java,mit In this case, any site that is not mit should only compile files FileOne.java and FileTwo.java. For mit, however, they should compile the base FileOne.java, their FileTwo.java,mit, and their FileThree.java,mit. Note: the site-specific files end with ",sitename" note ".sitename". In part it is easier to handle if it is a comma rather than an extra dot. I think that I've got the Makefiles modified (well, etc/Makefile and auth/server/Makefile as test cases ...) to do the right thing. The main requirement is that everyone who is compiling this stuff needs to have the environment variable SITE set to their appropriate value. For us, this would be accomplished with the bash command "export SITE=stanford" either on the command line or, preferably, in our .bashrc. I've modified etc/Makefile so that it compiles FileOne.class from site-specific/FileOne.java (instead of the normal FileOne.java). Note: site-specific/FileOne.java doesn't exist ... I have written three "implicit" rules that know how to make site-specific/FileOne.java: 1. The "base condition": If FileOne.java exists but site-specific/FileOne.java,mit doesn't exist. In this case, temporarily make a copy of FileOne.java as site-specific/FileOne.java. 2. The "only site-specific" condition: If site-specific/FileThree.java,mit exists, but FileThree.java doesn't exisit. Create site-specific/FileThree.java as a copy of site-specific/FileThree.java,mit 3. The "both" condition where FileTwo.java exists and is a part of the base distribution and site-specific/FileTwo.java,mit exists and contains their modifications. In this case, we assume that the site-specific file takes precedence and copy site-specific/FileTwo.java,mit into file site-specific/FileTwo.java. Also, once the compilation takes place, these "intermediate" files are automatically deleted ... so that the file structure won't be screwed up if we do a "cvs commit", for example. Note: also, it issues a warning if FileTwo.java is newer than site-specific/FileTwo.java,mit that it is going to use the site-specific file. In this case, the subdirectory named site-specific is both the repository of the site-specific files as well as the "build directory" (that is, the temporary location of the actual *.java files that are compiled ... although all of the class files are stored in their normal location). Note: site-specific would need to be "add"ed to cvs in any directory in-which we wanted to store site-specific files. However, if there are none, the directory site-specific is actual created as a part of the build process. Also, I've modified the Makefile in the source tree so that issuing a "make all" will compile both all of the base files and all of the local-site-only files ... without having to modify the Makefile. (Note: this actually only took the addition of about 15 lines in etc/Makefile) and the replacement of the specific naming of class files to be compiled currently "OBJ = AuthServer.class AuthManager.class" in auth/server/Makefile with about 5 lines that says "compile the class files for everything based on *.java in auth/server as well as anything based on *.java,$(SITE) in auth/server/site-specific where $(SITE) = my site.) Final note: I think that it will also take very little work to allow site-specific versions of various *.sql files, shell-scripts, etc. I need to look to see if it is also easy to do site-specific files in the "conf" directories. The one thing that I'm not sure that we can do is to have site-specific Makefiles. Of course, folks who have site-specific files have no guarantees if the baseline stuff changes ... they will get the warning that one of the baseline files changed, but it will be up to them to make sure that their stuff works with our improvments. At the very least, I'm hopeful that this approach (or something like it) will allow us to allow for site-specific differences in the context of a (hopefully) largely single codebase. Thoughts, comments, etc. will be welcome when you return ... have a good week. Later, John From beckwith at snf.stanford.edu Tue Jun 19 12:34:33 2001 From: beckwith at snf.stanford.edu (Sharleen Beckwith) Date: Tue, 19 Jun 2001 12:34:33 -0700 (PDT) Subject: terminal between wbmetal & wbnitride does not work. Message-ID: From a.heibel at bioprocessors.com Tue Jun 26 15:32:14 2001 From: a.heibel at bioprocessors.com (Anne T. Heibel) Date: Tue, 26 Jun 2001 15:32:14 -0700 Subject: remote access Message-ID: <002c01c0fe8f$da39e6a0$0400a8c0@ANNE> I was able to login to Coral remotely, but after logging on, an error message stating "Cannot access equipment information!" came up. This is the first time I had tried to log in and was wondering if this is due to a firewall at my office. Thanks for the help!! Anne Heibel _________________________________________ Anne T. Heibel Director of Engineering BioProcessors Corporation 1900 Addison St., Mezzanine Berkeley, CA 94704 510.883.0190 a.heibel at bioprocessors.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From shott at snf.stanford.edu Tue Jun 26 17:03:49 2001 From: shott at snf.stanford.edu (John Shott) Date: Tue, 26 Jun 2001 17:03:49 -0700 Subject: Checked in Makefiles ... Message-ID: <3B3922E5.8C91235@snf.stanford.edu> Bill and Mike: Oops ... I think that I forgot to send this message earlier about setting the site environment variable ... that is another reason that the make may not be working. ... I think that I've checked in all of the Makefiles so that we now get site-specific compilation, etc. One additional change that I made ... it nows makes the target "check-site" that checks to see if the environment variable SITE is set ... if not it bombs out. If you initially run make, it should bomb. Then add the line: export SITE=stanford to ~/.bashrc and then say "source ~/.bashrc" ... to make it reload. Then compilation should proceed OK. One thing that I haven't yet done ... it seems as if many of the places that have "conf" directories will have site-specific values in them. I need to think if we want to require the use (or at least support the use) of site-specific conf files. Any thoughts? John From sjlee at rpl.stanford.edu Tue Jun 26 23:46:25 2001 From: sjlee at rpl.stanford.edu (John Lee) Date: Tue, 26 Jun 2001 23:46:25 -0700 Subject: Coral Remote Message-ID: <000701c0fed4$e393a5c0$349842ab@LocalHost> Hi, I've been trying for some time to use Coral Remote and have been unsuccessful. I installed Java Web Start per the instructions, and I have absolutely no problem running the demo applications available on the Sun website. However, Coral Remote always gives "Unexpected Error", "Unable to launch Coral Remote (SNF)". I've tried fresh uninstall/install with both Internet Explorer 5.5 and Netscape Navigator 4.73. Even tried different computers, as well as modem dialup vs. direct LAN within Stanford. I have had it work many months ago on a different computer, so I can't tell what's wrong now. Any suggestions? Many thanks, -John sjlee at snf.stanford.edu From bmurray at snf.stanford.edu Wed Jun 27 11:18:37 2001 From: bmurray at snf.stanford.edu (Bill Murray) Date: Wed, 27 Jun 2001 11:18:37 -0700 (PDT) Subject: wafersaw Message-ID: Len, It appears from the logs that the wafersaw walker box was returning an out-of-range value of 0. The error began occurring around 13:00 yesterday. I did notice that it looks ok this morning. I've included the first error message from the logs below. ReturnValue: 0 2001-06-26 13:09:40 - wafersaw: Disable failed. Return value exceeds limits. Thanks, Bill From shott at snf.stanford.edu Wed Jun 27 12:57:37 2001 From: shott at snf.stanford.edu (John Shott) Date: Wed, 27 Jun 2001 12:57:37 -0700 Subject: wafersaw References: Message-ID: <3B3A3AB1.D32D0EC@snf.stanford.edu> Len and Bill: Yes, last evening, near 6:30 p.m. somebody caught me about this ... I went in and wiggled wires/boxes, etc. and got it so they could enable it ... but I beleive that we either have intermittent wiring near the wafersaw or an intermittent box of some sort ... Later, John