From mtang at snf.stanford.edu Fri Nov 2 19:10:16 2001 From: mtang at snf.stanford.edu (Mary Tang) Date: Fri, 02 Nov 2001 19:10:16 -0800 Subject: Password/login Problem Message-ID: <3BE36018.AD0D8368@snf.stanford.edu> Dear Coral Development Team -- Peter Leonov is a new labmember from Megasense who is having password problems. His boss called, saying that he had difficulty finding anyone to help him and reminded me that one of his other employees also had difficulty with her password/account. I blithely informed him that four people are here just about every day who can help him - please don't make me a liar? His login is "pleonov" 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 snf.stanford.edu From bmurray at snf.stanford.edu Fri Nov 2 19:20:16 2001 From: bmurray at snf.stanford.edu (Bill Murray) Date: Fri, 2 Nov 2001 19:20:16 -0800 (PST) Subject: Password/login Problem In-Reply-To: <3BE36018.AD0D8368@snf.stanford.edu> Message-ID: Mary, Everything looks ok to me. He has accounts on snf and sunray and is in the Coral database with login "pleonov". Perhaps he's just typing the wrong password. He should check with Ciara to confirm his password. Bill On Fri, 2 Nov 2001, Mary Tang wrote: > Dear Coral Development Team -- > > Peter Leonov is a new labmember from Megasense who is having password > problems. His boss called, saying that he had difficulty finding anyone > to help him and reminded me that one of his other employees also had > difficulty with her password/account. I blithely informed him that four > people are here just about every day who can help him - please don't > make me a liar? > > His login is "pleonov" > > 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 snf.stanford.edu > > From shott at snf.stanford.edu Fri Nov 2 21:23:10 2001 From: shott at snf.stanford.edu (John Shott) Date: Fri, 02 Nov 2001 21:23:10 -0800 Subject: Password/login Problem References: <3BE36018.AD0D8368@snf.stanford.edu> Message-ID: <3BE37F3E.B829C73F@snf.stanford.edu> Mary: It appears that pleonov successfully logged in to coral on August 7th ... so, at some point, he appears to have known his password. On the 29th, he tried 3 times to login remotely ... those attempts failed because he has not yet set a remote password (which, as you know, has to be done here). While it is clear that Megasense does seem to have a password problem, given the fact that 2 of them are currently barred for password infractions, I'm not sure that the problem is at our end. However, if Mr. Leonov contacts me, I will gladly help him ... Thanks, John From shott at snf.stanford.edu Sat Nov 3 12:48:45 2001 From: shott at snf.stanford.edu (John Shott) Date: Sat, 03 Nov 2001 12:48:45 -0800 Subject: Postgres update .... Message-ID: <3BE4582D.11339507@snf.stanford.edu> Bill and Mike: If I am not mistaken, I have installed postgres on both bopeep and rosen, created a "postgres" user that owns the database (who is a member of the pgdba group), and generated an empty database on each machine that is stored in /db/postgres (in the root partition ... not a separate partition ... on each machine. I have also installed, I think, the perl DBI, DBD::Oracle, and DBD::Pg modules that will be needed to test out the ora2pg conversion stuff. At this point, my next task is to install the ora2pg stuff .... Talk to you later, John From shott at snf.stanford.edu Tue Nov 6 16:14:45 2001 From: shott at snf.stanford.edu (John Shott) Date: Tue, 06 Nov 2001 16:14:45 -0800 Subject: Database tables ... Message-ID: <3BE87CF5.CD6F0687@snf.stanford.edu> Bill and Mike I've left a listing of current set of Oracle tables that we currently use (or, in some cases, don't yet use) under your respective doors. In particular, I'm trying to sort out which need to be manually generated (presumably from a tab-separated file), which are generated by one of the clients (normally, the ResourceClient), which once are automatically generated once in use (most of them) and which ones are not yet used ... I'd appreciate it if you'd look this over when there is a break in the action ... it doesn't have to be quickly because I think that I now know enough to give Mark Rogosky some more information. It looks like there are a total of 10 manually generated files: 5 related to accounting rates (acct_rate, eq_rate, inventory_rate, res_rate, and staff_rate) and 5 related to equipment (equipment, eq_affiliation, eq_hierarchy, requires, uses). Another 5 are generated "on the fly" by the resource client: (member, project, account, works_on, charges_to) and one is generated by the equipment client (qualify). Roughly 30 tables are generated automatically .... in particular the *_activity, *_history, and the summary tables *_sum (note: this also includes a variety of the old_* tables that we don't actually use ... but when we do they will be automatically populated by whatever approach we use to copying current stuff into "cold storage". There are about 15 tables that we don't use yet: This includes some of the group stuff, the is_account_admin class, parameters, places, and things. It probably also includes a couple of things that we have currently hardwired but should probably be moved to the database including event, evnet_hierarchy, and qualcode. I'm going to send Mark Rogosky a bit of an update ... and let him know that we are going to send him a set of excel files with our current data for the files that he will need to begin to manually update .... Talk to you later, John From shott at snf.stanford.edu Tue Nov 6 16:34:13 2001 From: shott at snf.stanford.edu (John Shott) Date: Tue, 06 Nov 2001 16:34:13 -0800 Subject: Postgres update .... Message-ID: <3BE88185.C1AF1792@snf.stanford.edu> Mike: While Bill and Mike are putting some of the finishing touches on the resource client/server and the admin server, I've begun to play around with postgres. I've got it installed on one of our solaris boxes and on a linux machine. I've also begun to work with the perl module called Ora2Pg that claims to be able to extract table structure from an Oracle database and generate the proper Postgres compliant SQL to create the same table structure in Postgres. The output files that I'm generating look pretty reasonable ... although I haven't actually tried to use them to generate tables in postgres. I'm still trying to learn a bit more about properly setting up users, permissions, and table spaces. As soon as I can generate some tables out here, I will send you a total of about 10 Excel files that are related to how you wish to set up your lab: 5 of them are database tables related to equipment and are named equipment, eq_hierarchy, eq_affiliation, requires, and uses. equipment will include equipment names, descriptions, whether it is interlocked or not, and a handful of other parameters. Eq_hierarchy basically generates the structure of how you want to group your equipment in Coral ... we use functional areas like "Photolithography", "Dry Etching", "Wet Benches" but other places might wan't to do it by room. Eq_affiliation basically assigns each piece of equipment to a place in the hierarchy. "Requires" and "uses" are facilities tables ... we actually list facilities such as house vacuum, DI water, etc. as pieces of equipment that can be up or down. Requires and uses determine whether a piece of "real" equipment actually requires or uses a particular facility. We also have about 5 tables named things like eq_rate, staff_rate, res_rate, inventory_rate, and acct_rate that contain some of our accounting rules for equipment use, staff charges, etc. If you don't charge for reservations ... you don't need much there. At the moment, coral doesn't have an inventory client/server so you probably don't need that table either. Most of the other stuff that you need to run is either stored in a handful of configuration files or is added by the resource client ... in particular members, projects, and accounts are added by the resource client as well as the relation of which member works on which project and which project charges to which account. Those tables are called, surprisingly, works_on and charges_to, and the resource client is also in charge ot adding, removing, and changing those privileges. So, I hope that gives you an update on what is going on here. The only fly in the ointment is that I have to attend the NNUN annual meeting in Santa Barbara on Thursday and Friday ... and then I will be on vacation next week. However, I'm making some progres on the Postgres front and Bill and Mike are really getting the real guts of the system ready to go. Talk to you soon, John From bmurray at snf.stanford.edu Tue Nov 6 22:44:41 2001 From: bmurray at snf.stanford.edu (Bill Murray) Date: Tue, 6 Nov 2001 22:44:41 -0800 (PST) Subject: vossough account problem Message-ID: John, As far as I can tell from the logs this user (vossough) has not been able to get access to the lab since October 22. Here's the log entry from the resource manager: Default project and/or account are/is not in the works_on or charges_to relation s. Inconsistent data for vossough. Is this a problem? Bill From pruitt at stanford.edu Wed Nov 7 12:33:35 2001 From: pruitt at stanford.edu (Beth Pruitt) Date: Wed, 07 Nov 2001 12:33:35 -0800 Subject: remote down again Message-ID: <5.1.0.14.2.20011107123028.00a88d00@pruitt.pobox.stanford.edu> am on campus trying remote coral and it is "unable to get admin mgr" again. it says no update of javaws is available and i reloaded coral from the website (deleted cache first) and no luck. thanks beth -------------- next part -------------- Java Web Start Console, started Wed Nov 07 12:33:06 PST 2001 Java 2 Runtime Environment: Version 1.3.0_03 by Sun Microsystems Inc. Logging to file: d:\users\beth\coral log From bmurray at snf.stanford.edu Wed Nov 7 12:48:19 2001 From: bmurray at snf.stanford.edu (Bill Murray) Date: Wed, 7 Nov 2001 12:48:19 -0800 (PST) Subject: remote down again In-Reply-To: <5.1.0.14.2.20011107123028.00a88d00@pruitt.pobox.stanford.edu> Message-ID: Beth, That's odd. I just had the lab manager and a faculty member at MIT download the remote version and log in with no problems. I've got about 20+ active remote clients running right now. It must be something local on your machine. Bill On Wed, 7 Nov 2001, Beth Pruitt wrote: > am on campus trying remote coral and it is "unable to get admin mgr" again. > it says no update of javaws is available and i reloaded coral from the > website (deleted cache first) and no luck. > thanks > beth From shott at snf.stanford.edu Mon Nov 12 09:50:33 2001 From: shott at snf.stanford.edu (John Shott) Date: Mon, 12 Nov 2001 09:50:33 -0800 Subject: Update ... Message-ID: <3BF00BE9.E2F6F9FB@snf.stanford.edu> Bill and Mike: I've received the Zelix KlassMaster stuff ... it is currently in the directory /app/solaris/2.6/zkm. Apparently, to use it we need to make sure that ZKM.jar in that directory (or otherwhere it we move it) is specifically mentioned in the classpath when we want to use obfuscation ... I've also downloaded but not installed the j2se 1.4 beta 3 stuff. It is in my directly as ~shott/j2sdk-1_4_0-beta3-solsparc.tar.Z. I've checked that, for once, we've got all of the proper patches installed. This is the "packages", rather than the self-extacting binary. I've printed out a copy of the installation instructions ... basically, its a matter of extracting the *.tar.X file that creates the packages in the current directory. Then, you uninnstall the existing packages and then install the new packages .... I think that it only takes 15 minutes or so. (Note: after installation, assuming that it is installed in /usr/j2se ... you will ahve to move /usr/j2se/jre/jce.jar to somethlng like /usr/j2se/jre/jce.jar.ignore to "uninstall" the jce stuff ...). There should be no Makefile or other changes required to begin to use the beta 3 version. Final note: of course, this needs to be done on all machines wherre we hope to use beta 3 ... rosen, guilden, sunray, and bopeep, I think. I hope this helps ... John From bmurray at snf.stanford.edu Fri Nov 16 09:20:04 2001 From: bmurray at snf.stanford.edu (Bill Murray) Date: Fri, 16 Nov 2001 09:20:04 -0800 (PST) Subject: [Fwd: dummy machine] In-Reply-To: <3BF433EF.D4E820B9@mtl.mit.edu> Message-ID: Tom, I apologize for my delay in responding. I'm just finishing up release 1.4 now. I'm on vacation all next week. I will get this release checked-in today so that you can get it next week. John has been gone this week, but will return next week. It's at the top of our priority list to get MIT and Penn State running on Coral. Although John and I will have no overlap in the office, I will copy him on this message and phone him to discuss the dummy machine. We have two options. We could give you complete and total access to our development version of Coral so you could do anything you want without worrying about doing any harm. Or, we could set up a dummy machine on our production platform. I will discuss with John so we can get this done right away. Thanks, Bill On Thu, 15 Nov 2001, Thomas Lohman wrote: > Bill, I was wondering if you'd had a chance to look at setting up a dummy/test > MIT machine in your system. Also, is your next release ready for download? > And lastly, I was wondering what was new from the user's perspective in this > next release vs. the release Vicky was playing with on her desktop. I think > it's important to know if there are any new user/functional pieces since Vicky > is in the middle of figuring out what else they would require/need. > > thanks, > > > --tom > > > Nancy Latta wrote: > > > > Great question..... > > > > I can qualify you if you will send me the snf account logins. Should take > > me all of 2-3 mins.... > > > > Nancy > > > > On Wed, 14 Nov 2001, Duane Boning wrote: > > > > > A related question -- is there a way to make sure we are "qualified" > > > or otherwise have full permissions to play with the state of that > > > machine? > > > > > > /Duane > > > > > > > From: Nancy Latta > > > > Date: Wed, 14 Nov 2001 13:00:53 -0800 (PST) > > > > Subject: Re: Comment tylannitride 2001-11-14 12:06:09: can't clear shutdown > > > > Hi again, Vicky, > > > > > > > > I think John is on vacation, so I'd recommend that you use the machine > > > > wbebres under wetbenches. It has been taken out of the lab and I can't > > > > think of a machine that fits the description of dummy more! > > > > > > > > Anyway, I'll set it to 'green' and y'all can play away..... > > > > > > > > Nancy > > > > > > > > On Wed, 14 Nov 2001, Vicky Diadiuk wrote: > > > > > > > > > Hi Nancy, > > > > > Yes - thx a lot, I tried but failed to clear it. > > > > > I called John abt it & asked to create a dummy machine for us to play on > > > > > without screwing you guys up. > > > > > > > > > > Hope all's well, > > > > > Vicky > > > > > > > > > > I>Hi Vicky- > > > > > > > > > > > >Can I assume that this is a remote shutdown?..... > > > > > > > > > > > >A user acct can shutdown equip, but only a staff acct can un-shutdown > > > > > >equip. > > > > > > > > > > > >I've gone ahead and removed all the shutdowns and problems. > > > > > > > > > > > > Nancy > > > > > > > > > > > >On 14 Nov 2001 diadiuk at snf.stanford.edu wrote: > > > > > > > > > > > >> Was able to shutdown, but can't clear it! > > > > > >> Vicky > > > > > >> > > > > > > > > > > > > > From bmurray at snf.stanford.edu Fri Nov 16 09:21:13 2001 From: bmurray at snf.stanford.edu (Bill Murray) Date: Fri, 16 Nov 2001 09:21:13 -0800 (PST) Subject: Charges for 2FBL702 In-Reply-To: <3BF4626E.9D733CCC@snf.stanford.edu> Message-ID: Ciara, I'm not authorized to release any accounting information without John's approval. This request will have to wait for him to return. Bill On Thu, 15 Nov 2001, Ciara Preston wrote: > Hi Bill, > > In Johns absence, Can you please generate the charges for the three > months from August to October.for Stanford Student Qian Wang? (login) > qwang. > Thank You, Ciara > -- > Ciara Preston > Lab Services Administrator > Stanford Nanofabrication Facility > Phone 650-725-3664 > From thomasl at mtl.mit.edu Fri Nov 16 09:23:51 2001 From: thomasl at mtl.mit.edu (Thomas Lohman) Date: Fri, 16 Nov 2001 12:23:51 -0500 Subject: [Fwd: dummy machine] References: Message-ID: <3BF54BA7.1D1F314D@mtl.mit.edu> Thanks Bill. I think having access to the development system may be a better way to go if only so we don't mess something up in your production system. What do we need to do to point the remote CORAL installation at the development system instead of the production system once we have accounts of course. thanks much, --tom Bill Murray wrote: > > Tom, > > I apologize for my delay in responding. I'm just finishing up release 1.4 > now. I'm on vacation all next week. I will get this release checked-in > today so that you can get it next week. John has been gone this week, but > will return next week. It's at the top of our priority list to get MIT and > Penn State running on Coral. Although John and I will have no overlap in > the office, I will copy him on this message and phone him to discuss the > dummy machine. We have two options. We could give you complete and total > access to our development version of Coral so you could do anything you > want without worrying about doing any harm. Or, we could set up a dummy > machine on our production platform. I will discuss with John so we can > get this done right away. > > Thanks, > Bill > > On Thu, 15 Nov 2001, Thomas Lohman wrote: > > > Bill, I was wondering if you'd had a chance to look at setting up a dummy/test > > MIT machine in your system. Also, is your next release ready for download? > > And lastly, I was wondering what was new from the user's perspective in this > > next release vs. the release Vicky was playing with on her desktop. I think > > it's important to know if there are any new user/functional pieces since Vicky > > is in the middle of figuring out what else they would require/need. > > > > thanks, > > > > > > --tom > > > > > > Nancy Latta wrote: > > > > > > Great question..... > > > > > > I can qualify you if you will send me the snf account logins. Should take > > > me all of 2-3 mins.... > > > > > > Nancy > > > > > > On Wed, 14 Nov 2001, Duane Boning wrote: > > > > > > > A related question -- is there a way to make sure we are "qualified" > > > > or otherwise have full permissions to play with the state of that > > > > machine? > > > > > > > > /Duane > > > > > > > > > From: Nancy Latta > > > > > Date: Wed, 14 Nov 2001 13:00:53 -0800 (PST) > > > > > Subject: Re: Comment tylannitride 2001-11-14 12:06:09: can't clear shutdown > > > > > Hi again, Vicky, > > > > > > > > > > I think John is on vacation, so I'd recommend that you use the machine > > > > > wbebres under wetbenches. It has been taken out of the lab and I can't > > > > > think of a machine that fits the description of dummy more! > > > > > > > > > > Anyway, I'll set it to 'green' and y'all can play away..... > > > > > > > > > > Nancy > > > > > > > > > > On Wed, 14 Nov 2001, Vicky Diadiuk wrote: > > > > > > > > > > > Hi Nancy, > > > > > > Yes - thx a lot, I tried but failed to clear it. > > > > > > I called John abt it & asked to create a dummy machine for us to play on > > > > > > without screwing you guys up. > > > > > > > > > > > > Hope all's well, > > > > > > Vicky > > > > > > > > > > > > I>Hi Vicky- > > > > > > > > > > > > > >Can I assume that this is a remote shutdown?..... > > > > > > > > > > > > > >A user acct can shutdown equip, but only a staff acct can un-shutdown > > > > > > >equip. > > > > > > > > > > > > > >I've gone ahead and removed all the shutdowns and problems. > > > > > > > > > > > > > > Nancy > > > > > > > > > > > > > >On 14 Nov 2001 diadiuk at snf.stanford.edu wrote: > > > > > > > > > > > > > >> Was able to shutdown, but can't clear it! > > > > > > >> Vicky > > > > > > >> > > > > > > > > > > > > > > > > > From bmurray at snf.stanford.edu Sat Nov 17 01:25:13 2001 From: bmurray at snf.stanford.edu (Bill Murray) Date: Sat, 17 Nov 2001 01:25:13 -0800 (PST) Subject: Coding Complete Message-ID: John, I have just now completed coding all the items we discussed, setting up the new tables, and compiling everything. I will run some basic tests tomorrow before I leave town. I will check everything in then. However, I won't install anything in production until I get back and test everything. I have modified the adjustment code to make adjustments to the new lab activities. However, I have not modified the activity or accounting scripts to extract data from the admin manager's lab_activity table or to charge for lab time. Bill From bmurray at snf.stanford.edu Sat Nov 17 17:59:33 2001 From: bmurray at snf.stanford.edu (Bill Murray) Date: Sat, 17 Nov 2001 17:59:33 -0800 (PST) Subject: Status Message-ID: John, I have compiled all and briefly attempted to test. I have a bug which prevents the development servers on guilden from running. I don't think it's major, but I don't have time to run it down until I return from vacation. For this reason, I have not checked in my changes. I'll do this when I return and it's all running properly. Mike's changes are checked in and all my code which he uses has been checked in for some time. If you want to take a look at those changes or run the development servers, you will need to check out the latest version from the repository and install on guilden. I apologize for leaving a non-functional development version, but it should be quick to get back to a working version. However, I was prudent enough not to touch the production servers. I did restart the servers last night after 31 days running. Have a great Thanksgiving! I'm heading off to Carmel. I won't have access to email. However, you can reach me at the house I'm renting (831) 626-3773. Bill From shott at snf.stanford.edu Sun Nov 18 11:56:50 2001 From: shott at snf.stanford.edu (John Shott) Date: Sun, 18 Nov 2001 11:56:50 -0800 Subject: Installation of j2se 1.4 beta 3 ... Message-ID: <3BF81282.BC19DCAA@snf.stanford.edu> Bill and Mike: Now that I'm back and you guys are away ... have a good Thanksgiving. I'll probably send out a few messages during the week to keep you apprised of things ... but none of them are urgent. But, for the record, here is what I've done to install 1.4 beta 3 on guilden, bopeep, rosen, and sunray. I've installed them ... and made sure that the production clients on sunray still work, even though I didn't restart the production servers ... 1. I downloaded the "package" version into my home directory. 2. I uncompressed it with: zcat j2sdk-1_4_0-beta3-solsparc.tar.Z | tar -xf - which creates a handful of directories called SUNWj3rt, SUNWj3dev, etc. 3. Then I become root and "cd ~shott". 4. Then I remove the installed versions with: pkgrm SUNWj3dmo SUNWj3man SUNWj2dev SUNWj3rt (note: on bopeep, because of disk space limitations, the SUNWj3dmo (demo stuff) isn't installed, so I omit it from the list). 5. Then I install the new stuff with: pkgadd -d . SUNWj3rt SUNWj3dev SUNWj3man SUNWj3dmo (Note: on bopeep, I don't install the SUNWj3dmo stuff, either ...) (Second note: on guilden the command is slightly modified: pkgadd -a basedir_ask -d . SUNWj3rt SUNWj3dev SUNWj3man SUNWj3dmo This is becuase /usr is pretty full and the default installation is /usr/j2se ... The "-a basedir_ask" asks where you want to install it. On guilden only, I anwser "/app" which installs everything as /app/j2se instead of the default /usr/j2se ... then there is a link on guilden that points /usr/j2se to /app/j2se so that all machines thing that java in in the same place. 6. Finally, we need to disable the JCE stuff. This is done, still as root, by: cd /usr/j2se/jre/lib mv jce.jar jce.jar.ignore (In other words, I make sure that the jce.jar stuff "is invisible" when you start up java). Thanks, Have a good week ... John From shott at snf.stanford.edu Mon Nov 19 10:21:19 2001 From: shott at snf.stanford.edu (John Shott) Date: Mon, 19 Nov 2001 10:21:19 -0800 Subject: Coral Maintenance Client ... Message-ID: <3BF94D9F.81F49BFF@snf.stanford.edu> Vicky, Duane, and Tom: I hope that you are now able to fully exercise the shutdown/problem, enable/disable and clear shutdown/clear problem capabilities of coral using the equipment named bottlewash. If problems persist, let me know and I will resolve them. Let me also say that we are aware that the maintenance client ... where you go to see and clear problems and shutdows ... is probably the weakest point in Coral. In particular, you only see the subject line of a problem/shutdown in the client and there isn't the capability to double-click on that to see the full text of the message. We are certainly aware of those deficiencies and certainly plan to fix those deficiencies ... but have had other, more important, matters that have received our attention. Part of the reason that we have been able to get away with this is that we do have a Web-accessible set of archives of all of our equipment-related mailing lists. If you want to check that out, it is at: http://snf.stanford.edu/Equipment/ArchiveByArea.html There you see that each piece of equipment has two mailing lists: one that is labelled "Discussion List" and one that is called "Equip Archive". These correspond to the two mailing lists that we have for each piece of equipment: equip at snf.stanford.edu and equip-pcs at snf.stanford.edu (where the "-pcs" stands for Problems/Comments/Shutdowns) for every piece of equipment in the lab. In other words, we have mailing lists named karlsuss at snf.stanford.edu and karlsuss-pcs at snf.stanford.edu for our Karl Suss MA-6 double-sided aligner, etc. In general, only the people in charge of maintenance of equipment are on the *-pcs mailing list: In other words, the engineer and the maintenance staff get the equip-pcs messages for each piece of equipment for which they are the maintenance or engineer. The equip at snf.stanford.edu is for more general announcements, changes in policy, etc. For example, all people qualified to use (or any "higher" level of capability such as instructor, process, maintenance, or engineer) are on the karlsus at snf.stanford.edu for our Karl Suss double sided aligner. While the existense of these archives at least partially obviates the urgent need for the maintenance client to display the full text of problems, shutdowns, and their resolutions, if you check out some of the "Equip Arvhive" messages (and their resolution), you will find that we have a hard time getting our labmembers to report detailed symptoms of problem and shutdown conditions and, more disturbingly, our staff often writes very terse messages when they resolve a problem such as the dreaded, one-word resolution message: "Fixed". We had certainly hoped that these archives would become a repository of previous problems and their resolution and that they would include more detailed discussion of what the problem was, how something was resolved, etc. so that it could become a resource to be used the next time a similar problem occurs ... particularly if it was a new staff member inheriting a piece of equipment. Of course, that is more of a management failure, as opposed to a technical deficiency, that we can't seem to get our staff to do a comprehensive job of using these e-mail archives to log specifics of what they found, what they fixed, etc. In any event, let me know if you have any further problems in terms of exercising the "bottlewash" equipment. Thanks, John From shott at snf.stanford.edu Mon Nov 19 18:23:09 2001 From: shott at snf.stanford.edu (John Shott) Date: Mon, 19 Nov 2001 18:23:09 -0800 Subject: KlassMaster obfuscation .... Message-ID: <3BF9BE8D.29F838B7@snf.stanford.edu> Bill and Mike: I think that I'm getting pretty close to having obfuscation working with the new Zelix KlassMaster. They have a problem with 1.4 that Sun is aware of ... so that if you actually run ZKM you have to run it under some other JDK, but it seems to work with 1.4 beta 3 class files. In any event, I've modified my copy of labnet/Makefile to use this stuff ... it's a little different in that if you read in a jar file to be obfuscated we can specify the directory in which the obfuscated file is stored ... but not the name. In other words in the old days we used to read in coral.jar and store the obfuscated file as coral-o.jar in the same directory. Now, it appears as if it is easiest to read in coral.jar (stored in ~/labnet/lib) and then store the obfuscated version as ~/labnet/lib/obfuscated/coral.jar. Then during install, depending on whether obfuscation is on or not, we install either coral.jar or obfuscated/coral.jar. Since the development version isn't quite working, I've tried to test this by obfuscating coral.jar, signed it (in the normal way), and then manually copied it to coral-dev.jar. In other words, temporarily our "remote development coral" is really "obfuscated production remote coral". When I do this, it seems to work. I probably won't check this in until we get the development system back when we can test it more thoroughly. Note, although we may not want to do it now, since we are now running local clients and servers from jar files, we could consider obfuscating ALL of our jar files: they would probably load incrementally faster and if anyone thinks that they are going to "steal" coral, this may make it a bit more difficult (depending on how closely we protect source access in our system, of course). This would probably take a bit of playing around to figure out what we don't need to obfuscate for each server ... and, of course, if we are obfuscating everything, it makes it more difficult to diagnose error conditions (although ZKM generates a nice listing that indicates that class labnet.equipment.server.something was obfuscated to labnet.a.a.a, etc.). In any event, I will probably play with this a bit more, but I think that we can count on the fact that we can resume obfuscating the remote client the next time that we make a major release. Thanks, John From shott at snf.stanford.edu Tue Nov 27 16:41:41 2001 From: shott at snf.stanford.edu (John Shott) Date: Tue, 27 Nov 2001 16:41:41 -0800 Subject: Labnet ... lines of code: Message-ID: <3C0432C5.BCD249A0@snf.stanford.edu> Bill and Mike: I think that I got the program sloccount (for Source Lines of Code count) working ... Following is the current breakdown of a freshly checked out version of labnet ... of course, this doesn't include all of Bill's additions to the admin server so we may want to update this when we have that all checked in. In any event, here is the analysis: Note: in all cases, it does its best to eliminate comment lines from the number of "real lines of code" (I think that it also eliminates blank lines as well). Note: that the idl lines (it didn't originally know about IDL, but it appears that counting idl lines of code is virtually identical to counting C in terms of eliminating comment lines) will also generate an extra 19-20 thousand lines of java code ... however, I didn't think that it was fair to count them among the total lines of code. Also, I think that both the sql lines are bigger than are really in coral because we had a fair number of *.sql files for loading our Crystal data. Also, the ansic lines are nearly double what they should be because in addition to the daemon and the driver there is a "temp" directory that seems to include duplicates of nearly everything ... In any event, I thought that this was interesting to look at ... and they even make the estimate that this represents a little over 10 person-years of effort and an estimated development cost of $1.4M. Thanks, John SLOC Directory SLOC-by-Language (Sorted) 42466 labnet java=31822,sql=6123,ansic=2192,makefile=1133,idl=853, sh=334,perl=9 Totals grouped by language (dominant language first): java: 31822 (74.94%) sql: 6123 (14.42%) ansic: 2192 (5.16%) makefile: 1133 (2.67%) idl: 853 (2.01%) sh: 334 (0.79%) perl: 9 (0.02%) Total Physical Source Lines of Code (SLOC) = 42,466 Development Effort Estimate, Person-Years (Person-Months) = 10.24 (122.93) (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05)) Schedule Estimate, Years (Months) = 1.30 (15.56) (Basic COCOMO model, Months = 2.5 * (person-months**0.38)) Estimated Average Number of Developers (Effort/Schedule) = 7.90 Total Estimated Cost to Develop = $ 1,383,837 (average salary = $56,286/year, overhead = 2.40). Please credit this data as "generated using 'SLOCCount' by David A. Wheeler." From hphan at snf.stanford.edu Thu Nov 29 16:34:53 2001 From: hphan at snf.stanford.edu (Henry Phan) Date: Thu, 29 Nov 2001 16:34:53 -0800 Subject: Long-in Message-ID: <3C06D42C.A1C215E0@snf.stanford.edu> Hi Dear: I have a problem log in to coral. It said my user name has expired. Please help, thank you. Henry -- Henry _ _ _ _ Henry Q. Phan Stanford Nanofabrication Facility CIS Room 146, Mail Code 4070 Stanford, CA 94305 (650)725-3659 hphan at snf.stanford.edu From shott at snf.stanford.edu Thu Nov 29 18:58:07 2001 From: shott at snf.stanford.edu (John Shott) Date: Thu, 29 Nov 2001 18:58:07 -0800 Subject: Long-in References: <3C06D42C.A1C215E0@snf.stanford.edu> Message-ID: <3C06F5BF.3450A109@snf.stanford.edu> Henry: We are checking things in the database to see why you appear to have expired ... but we have reset things for you so you should now be able to login to coral ... well by 9 p.m. this evening. Thanks, John