Has it been a week already? I am here in Europe checking out various options for mobile, social media and cloud on my "Digital IBMer" tour. Here´s where we have been so far...

Frankfurt, Germany

We landed at the Frankfurt airport, which will serve as our starting and ending point. It is close to Mainz where my IBM colleagues at the Executive Briefing Center for Germany is located. I looked throughout the airport for a SIM chip for my smartphone that worked in all European countries, but nobody had one for sale. We had lunch while we wait for the train to Brussels.

Brussels, Belgium

Our next stop was Brussels, capital of Belgium. The Belgians speak Flemish, which is like a Belgian version of Dutch, and French. I don´t speak Flemish nor Dutch, so I have been able to get by on French here. The Hotel Opera was near the central station, but we got off at the Bruxelles-Midi, thinking that Midi meant middle, or central of the city, but is Flemish (er.. make that French) for South instead, so we had a bit of walking to do!

Bruges, Belgium

Bruges is only an hour train ride from Brussels and is worth seeing. Our Eurail pass makes it easy just to go from city to city by train. Our particular one allows us first class travel through 23 countries for 15 contiguous days. We had lunch at the central square, and for dessert... Belgian Waffle-on-a-stick! Mine was covered in powdered sugar, and soon the rest of me was also.

Through tweets on Twitter, I was able to meet up with Stef, a local storage administrator and fan of my blog, and go out for beers. Stef was kind enough to lend me a pre-paid SIM chip for my phone that provided data plan while I am in Belgium! Thank you Stef!

Amsterdam, The Netherlands

Not surprisingly, Amsterdam is one of my favorite cities. It´s like Las Vegas without casinos. Our hotel, The Bulldog, is conveniently located in the center of town.

I met up with Joanne, a professional cellist (yes, she plays the Cello musical instrument for a living) who took us on a tour of the MuzikGebouw, which is where they hold concerts and events. Using the "Amsterdam City Guide" app from Travel Advisor on my smartphone, we followed one of their suggested self-guided walking tours. We also went to the Rijksmuseum, which is under construction, so only a subset of the art is on display.

Copenhagen, Denmark

From Amsterdam, we took a night train to Copenhagen. This is a 15-hour train ride, no dinner, but they give you breakfast. Men and women are in separate sleeping cars, and I was paired up with a business man, Danny, from Tiawan trying to sell clothing for firefighters.

Until now, I have managed with German, French and English, but I wasn´t sure about Danish, so I brought this "European Phrase Book" that has 14 languages. We stayed at the DanHostel, conveniently located near"Tivoli Park".

Berlin, Germany

We have safely arrived to Berlin. Our train from Copenhagen to Hamburg went on a ferry boat to cross over the water! We are staying at Plus Berlin Hostel,which has a nice indoor swimming pool and dry sauna.

Until now, we have had beautiful sunny weather, but today is cold and dreary. We started out taking photos of all the graffiti in East Berlin we could find, but it started raining, so we changed plans and went to the world famous Pergamonmuseum.

Well, that´s my first week of adventure. Tomorrow, we leave for Prague in the Czech Republic!

Tags:  #digitalibmer

"This week, IBM is launching a companywide effort to build the digital eminence of all IBMers. The goal is to arm you with the tools and knowledge to effectively use emerging technologies -- such as social, mobile, and cloud computing -- for strategic advantage."

This is how Rod Adkins, IBM Senior VP of Systems Technology Group, and my sixth-line manager, starts a memo to declare April "Digital IBMer awareness month". I am not sure if this is just for this April, or every April going forward. Included with this is a set of ten guidelines to improve CyberSecurity:

In honor of this, I will be spending the next two weeks traveling through Europe. Instead of bringing a large suitcase and my laptop, I have decided instead to only take:

• The clothes I am wearing on the plane
• A heavy jacket with lots of pockets
• A backpack with 15 pounds of clothes
• A hipsack with my smartphone, digital camera, MP3 player and all the related adapters, chargers and cables

My smartphone uses a GSM chip, so I should be able to get a European SIM when I arrive. I have not booked any hotels, tours, or transportation. Instead, I will rely on social media and cloud computing to take care of things on a daily basis.

(Why only 15 pounds of clothing? I just had major surgery two weeks ago, and my doctor advised me not to lift more than 15 pounds for the next six weeks!)

I plan to have a series of blog posts documenting what I learn from this trip. For those who want to follow along, I will be tweeting from @az990tony. You do not need a Twitter account to read my tweets. You can read them directly from [http://twitter.com/#!/az990tony].

I can't remember the last time I have gone this long without the comforts of my laptop or desktop, so it will be interesting how it works out!

Tags:  awareness+month digital+ibmer rod+adkins ibm

On my last blog post [Is this what HDS tells our mainframe clients?], I poked fun at Hu Yoshida's blog post that contained a graphic with questionable results. Suddenly, the blog post disappeared altogether. Poof! Gone!

Just so that I am not accused of taking a graph out of context, here is Hu's original post, in its entirety:

"Since my last post on Storage Performance Efficiency, Claus wrote on the use of HDP, Hitachi Dynamic Provisioning and HDT, Hitachi Dynamic Tiering for mainframes on Virtual Storage Platform (VSP). Naturally, this prompted me to think of the specific performance efficiency implications for mainframes.

HDP brings the performance benefits of automated wide striping and HDT automatically keeps the hot pages of data on the highest performance tier of storage for mainframes, just as it does for open systems. There are differences between open systems and mainframe implementation due to mainframe CKD and CCHHR formats for instance, the page size is optimized for mainframe storage formats and storage reclamation must be host initiate. For more information check out our website: http://www.hds.com/assets/pdf/how-to-apply-latest-advances-in-hitachi-mainframe-storage.pdf

There are also additional performance efficiencies specific for mainframes.

Mainframe HDP is the foundation for Extended Addressable Volumes, which increases the size of 3390 volumes from 65,520 cylinders to 262,668 cylinders. This, along with HyperPAV--which facilitates multiple accesses to a volume, addressing the problem of queuing on a very large volume with a single UCB--enhances throughput with many more concurrent I/O operations.

[graph]

The thin provisioning of HDP also increases the performance of mainframe functions that move, copy, or replicate these thin volumes like Concurrent Copy, FlashCopy V02, and HUR, since the actual volumes are smaller.

If you have mainframes, check out the capacity and performance efficiency of VSP with HDP and HDT.

For other posts on maximizing storage and capacity efficiencies, check these out: http://blogs.hds.com/capacity-efficiency.php"

At this point, you might be wondering: "If Hu Yoshida deleted his blog post, how did Tony get a copy of it? Did Tony save a copy of the HTML source before Hu deleted it?" No. I should have, in retrospect, in case lawyers got involved. It turns out that deleting a blog post does not clear the various copies in various RSS Feed Reader caches. I was able to dig out the previous version from the vast Google repository. (Many thanks to my friends at Google!!!).

The graph itself was hosted separately has been deleted, but it was just taken from slide 10 of the HDS presentation [How to Apply the Latest Advances in Hitachi Mainframe Storage], so it was easy to recreate.

(Lesson to all bloggers: If you write a blog post, and later decide to remove it for whatever legal, ethical, moral reasons, it is better to edit the post to remove offending content, and add a comment that the post was edited, and why. Shrinking a 700-word article down to 'Sorry Folks - I decided to remove this blog post because...' would do the trick. This new edited version will then slowly propagate across to all of the RSS Feed Reader caches, eliminating most traces to the original. Of course, the original may have been saved by any number of your readers, but at least if you have an edited version, it can serve as the official or canonical version.)

Perhaps there was a reason why HDS did not want to make public the FUD its sales team use in private meetings with IBM mainframe clients. Whatever it was, this appears to be another case where the cover-up is worse than the original crime!

technorati tags: HDS, Hu Yoshida, VSP, EAV

Tags:  vsp hu+yoshida eav hds

Five years ago, I sprayed coffee all over my screen from something I read on a blog post from fellow blogger Hu Yoshida from HDS. You can read what cased my reaction in my now infamous post [Hu Yoshida should know better]. Subsequently, over the years, I have disagreed with Hu on a variety of of topics, as documented in my 2010 blog post [Hu Yoshida Does It Again].

(Apparently, I am not alone, as the process of spraying one's coffee onto one's computer screen while reading other blog posts has been referred to as "Pulling a Tony" or "Doing a Tony" by other bloggers!)

Fortunately, my IBM colleague David Sacks doesn't drink coffee. Last month, David noticed that Hu had posted a graph in a recent blog entry titled [Additional Storage Performance Efficiencies for Mainframes], comparing the performance of HDS's Virtual Storage Platform (VSP) to IBM's DS8000.

For those not familiar with disk performance graphs, flatter is better, lower response time and larger IOPS are always desired. This graph implies that the HDS disk system is astonishingly faster than IBM's DS8000 series disk system. Certainly, the HDS VSP qualifies as a member of the elite [Super High-End club] with impressive SPC benchmark numbers, and is generally recognized as a device that works in IBM mainframe environments. But this new comparison graph is just ridiculous!

(Note: While SPC benchmarks are useful for making purchase decisions, different disk systems respond differently to different workloads. As the former lead architect of DFSMS for z/OS, I am often brought in to consult on mainframe performance issues in complex situations. Several times, we have fixed performance problems for our mainframe clients by replacing their HDS systems with IBM DS8000 series!)

Since Hu's blog entry contained very little information about the performance test used to generate the graph, David submitted a comment directly to Hu's blog asking a few simple questions to help IBM and Hu's readers determine whether the test was fair. Here is David's comment as submitted:

"Hello, Hu,
(Disclosure: I work for IBM. This comment is my own.)

I was quite surprised by the performance shown for the IBM DS8000 in the graph in your blog. Unfortunately, you provided very little detail about the benchmark. That makes it rather difficult (to say the least) to identify factors behind the results shown and to determine whether the comparison was a fair one.

Of the little information provided, an attribute that somewhat stands out is that the test appears to be limited to a single volume at least, that's my interpretation of "LDEV: 1*3390-3"? IBM's internal tests for this kind of case show far better response time and I/Os per second than the graph you published.

Here are a few examples of details you could provide to help readers determine whether the benchmark was fair and whether the results have any relevance to their environment.

1. What DS8000 model was the test run on? (the DS8000 is a family of systems with generations going back 8 years. The latest and fastest model is the DS8800.)
2. What were the hardware and software configurations of the DS8000 and VSP systems, including the number and speed of performance-related components?
3. What were the I/O workload characteristics (e.g., read:write ratio and block size(s))?
4. What was the data capacity of each volume? (Allocated and used capacity.)
5. What were the cache sizes and cache hit ratios for each system? (The average I/O response times under 1.5 milliseconds for each system imply the cache hit ratios were relatively high.)
6. How many physical drives were volumes striped across in each system?"

Unlike my blog on IBM, HDS bloggers like Hu are allowed to reject or deny comments before they appear on his blog post. We were disappointed that HDS never posted David's comment nor responded to it. That certainly raises questions about the quality of the comparison.

So, perhaps this is yet another case of [Hitachi Math], a phrase coined by fellow blogger Barry Burke from EMC back in 2007 in reference to outlandish HDS claims. My earliest mention was in my blog post [Not letting the Wookie Win].

By the way, since the test was about z/OS Extended Address Volumes (EAV), it is worth mentioning that IBM's DS8700 and DS8800 support 3390 volume capacities up to 1 TB each, while the HDS VSP is limited to only 223 GB per volume. Larger volume capacities help support ease-of-growth and help reduce the number of volumes storage administrators need to manage; that's just one example of how the DS8000 series continues to provide the best storage system support for z/OS environments.

Personally, I am all for running both IBM and HDS boxes side-by-side and publishing the methodology, the workload characteristics, the configuration details, and the results. Sunshine is always the best disinfectant!

technorati tags: IBM, DS8000, DS8800, HDS, Hu Yoshida, USP, VSP, mainframe, EAV

Tags:  hds usp hu+yoshida mainframe ds8800 vsp ibm eav ds8000