This week the Guardian (http://tiny.cc/mnn3b) reported how three million doctors have already downloaded a 59p stethoscope app for their iPhone. No more recoiling from that cold metal stethoscope now the doctor can press their warm iPhone to your chest.  This just the latest example of how consumer technology innovation can drive non-consumer use of technology such as enterprise IT.

More than that, this story shows why everyone in the corporate world – including senior management who may not really ‘get’ IT – expects so much from their IT systems, since they can do so much, so quickly with devices and software themselves.  That is all the more justification for companies making efforts to understand what their IT infrastructure and the business processes they are there to support actually do.

( 2 Votes )

IBM told the world that the new POWER7 range of servers were going to be fast.  We saw their benchmarks and read their white papers.  But I always reserve judgment until somebody else runs their own benchmark on a new piece of hardware.

( 2 Votes )

Having checked out an implementation of TSM for Sharepoint, I was surprised to see that backup data was being retained for longer periods than set in the backup plan. I checked the usual places (Server copygroups, expiration processing, etc) but everything seemed in order. I then turned to google and user groups and after many searches I finally stumbled across an answer to the problem. 

This can be caused by two different TSM server settings for the DocAve node.
1.  The node does not have Del Backup set to Yes
2.  The node's txngroupmax is too low Diagnostics:
1. Check the following:
 Query Node F=D for the node in question and ensure the following is set :
      Backup Delete Allowed: Yes

2. Check the actlog for the following
ANR0445W Protocol error on session 1115630 for node nodename (DocAve) - maximum group transaction size exceeded. (SESSION: 1115630) In the case where the node's Backup Delete Allowed is set to No, update the node so that it is set to Yes. In the case where you are getting the delete errors due to maximum group transaction size exceeded, then you need to update the node's txngroupmax.

During a DocAve backup, the data is segmented into 50mb chunks. This is stored individually on TSM as an object. Because DocAve uses the TSM API, the deletion of the old data is done as a single transaction. If the number of objects it is trying to delete is greater than txngroupmax, then the deletion will fail.

It seems that IBM hasn't slowed down the development of TSM since migrating the internal database to a DB2 database, as TSM v6.2 has just been announced this week. Availability will be electronic from March 19th, with physical media a month later. (Not that many people rely on physical media for software distribution these days.)

There's some interesting new features as well with this release. The most notable feature is block-level deduplication at the client level, so if you've got a client with a lot of similar files then this feature can provide significant benefit. both in terms of storage and network utilisation. Note that this dedupes at the client level, not the server, so if two clients have the same files this feature will not dedupe between those clients. {Edit: I'm told it's actually cross-client, however I'll wait until the official documentation is available before making further comment.) If you want cross-client dedupe then this can be achieved via other means, such as file based disk storage pools or deduped based storage at the back-end.

For many years, the NetBackup™ product suite has frowned upon technologies that didn’t use full backups as they claimed it impacted the RTO. In a change of face, Symantec now offer both source and target de-duplication in both NetBackup™ and BackupExec™.

This is achieved through the PureDisk™ when storing data in a media server de-dupe pool or a PureDisk storage pool.

For more information see:  http://eval.symantec.com/mktginfo/enterprise/fact_sheets/b-symc_netbackup_7_core_DS_12995286-2.en-us.pdf

EMC also have source and target de-duplication through its acquisition of Avamar and DataDomain.

I'm currently writing a script which needs to parse a configuration file and for one reason or another I got in to the situation where I wanted awk to use one of my shell variables.  I had never needed to do this before so I searched for a little while before coming across a guide on Tek-Tips that explains three ways of doing this.

http://www.tek-tips.com/faqs.cfm?fid=1281

IBM have released a draft version of the redbook for TSM 6.1.  This discusses the changes made to TSM including command line changes relating to the mov eto DB2.

For more detail, download the readbook at :

http://www.redbooks.ibm.com/redpieces/abstracts/sg247718.html

Ever wondered how to find technical information relating to TSM 6.1? Now you can find it easier with the TSM WIKI http://www.ibm.com/developerworks/wikis/display/tivolistoragemanager/Home

SSD (Solid State Disk) integrated support for IBM's SVC annouced.

http://www-03.ibm.com/systems/storage/news/press/20091014.html

Seems like the most logical way to make best use of an expensive resource like SSD's  - keep the performance where it counts by handling it in a virtual storage layer.

I hear they are going to get really clever eventually and move the intensive workloads to the SSD's automatically based on load calculations. - v.cool.

Whenever you clone an operating system you always end up with a few items that you didn't necessarily want.  Things like persistent hardware address can be a pain and cloning encryption keys is never a good idea.  When cloning SLES (SuSE Linux Enterprise Server) you may have issues when you come to register your systems online with Novell.  The problem is all cloned systems have an identical Zenworks device ID, so only the first system works.

 Follow these steps to create a new Zenworks device ID.