Wednesday February 02, 2005

Doctor my car has developed flatulence...

After a particularly satisfying overtaking move on one of those wretched white vans we see so much of nowadays on our roads (on a dual carriagway) my last car decided it was time to embarrass its owner. As the white van disapeered out of sight there was a loud bang. After the bang I suppose you think what hit me ? Or what did I hit ? Nothing was anywhere near me. The next thought would be that sounded expensive I wonder what it was. The answer was given to me by the car. As I pressed the accelerator the flatulence noise appeared with a painful lack of horse power.

The white van then gleefully unlapped itself and I was left limping along at around 20mph. As I passed a group of schoolkids they all pointed and laughed. I developed a queue of cars behind me. At this stage of my journey I had left the dual carriageway and there was nowhere for people to pass.

I got to the VW garage and of course it was a known problem, "your manifold has a weak point that sometimes splits". There then followed an argument between the garage and the leasing company as the car was out of guarantee and being a known problem the leasing company were a bit miffed.

The Lab ( Part 2) The booking tool

As part of the process of describing the lab I work in I want to move onto one of the tools. This tool (javalabtool) is used to book hardware in the lab. With several labs over the world and engineers in many locations ( some of whom will never meet each other ) we need a single booking system for all.

It is based on a Sybase back end database. It has a Java, Web and command line front end user interface. I mentioned in a previous web log how the hardware is represented in the tool so let us take it another step further.

Each lab has a group named after its location. In each group there are a series of folders all names {LAB LOCATION}-Folder-name eg 'storage', 'san hardware' and so on. Hardware is then stored in the relevant folder. Engineers can view/search on single or multiple groups. The main view indicates if a piece of hardware is booked or free. Once the engineer has found the hardware they want they can book it to a customer call or for a time period. The maximum time period is defined by the booking tool administrator. When the customer call closes the booking is removed. When timed bookings are about to expire engineers are warned.

Each piece of hardware is made up of smaller pieces we call Sun part numbers. These take the form of a number eg 540-1234-04/50. The numbers after the last dash are the revision number. When we set new hardware up we make a note in the database of all the 'interesting' part numbers and revisions. This means we can search for a specific part numbers and revision. This is very powerful , as some revisions of a part might not exhibit the bad behaviour you the customer are seeing. Also if we add specific parts to a piece of hardware like a PCI card we 'attach' the part to the main hardware so we know where that part is. So if we are short of that part we can easily location where it is.

For domain based machines we only normally allow engineers to book domains. They then use the 'temporary' attachment feature of the tool to have the system and IO boards attached to the domain entity for the duration of the booking. After the booking the attachements are cleared. Engineers can use the same method to attach storage to a host to help them keep track of what they need during an customer call.

The tool has the concept of item attributes and every type of hardware has its own attributes and ones it inherits from its parent type ( the types tree is a hierarchal structure. We can store serial numbers and locations for example to do asset control.

The database also stores information about the console and remote power setups which are used by the software we use for doing this function.