Monday at work was frustrating; two of the team were off sick, so I spent a decent proportion of my day answering helpdesk calls. A lot of the rest of the day was spent looking at backups in our
As it turned out, the robot problem was easy enough to solve; the drive hadn’t been settled quite properly in its slot and the resulting difference (barely a millimetre!) was enough to upset the tape grabber. That was quickly fixed. It took me a further three or four very frustrating hours to get both of the drives showing as online and working reliably though. Despite the much vaunted plug-and-play abilities of modern computer Operating Systems, including Windows Server, seemingly they still aren’t able to allow you to change the settings on a SCSI* device without then needing to reboot the whole computer to get it to recognise the change. It’s ridiculous. That was the main source of frustration; every time I tried something new, I had to go through a cycle of telling the office that their server was going to be rebooted, waiting fifteen minutes so they could save their work, downing the server and then checking all of the services when it came back up. Very intrusive to the users. Not an ideal way to work at all. Surely it should be possible to just reboot the affected component of the system, rather than the whole system! (If there are any SCSI experts out there who can tell me how to do this, I would be SO grateful.)
Other than that, not a lot has been happening; Chorus on Monday night was fine. I cycled there and back for the first time and that all went very smoothly thanks to Tomtom. An upside of going to Leeds yesterday is that I don’t have to spend an even longer day in
* SCSI is the name for a way of connecting devices to server computers if they need to move a lot of data very quickly, like disk drives, tape drives and scanners. It’s quite an old technology but is still standard in most server devices.
No comments:
Post a Comment