I caught up with Chis Rooke on the way over to Brighton for the Euro ITUG event and we shared the same flight into Heathrow. Chris was already showing the first signs of the flue and he was quick to put distance between himself and anybody else as he didn’t want to spread the germs.
As any traveler can tell you, getting any cold virus or a flue is the last thing you need! Early this year, while at SATUG, I managed to catch the bug. Out of desperation I overdosed on medication mixtures, and thought I was going to die! I still don’t recall much of the closing evening river cruise.
Seeing Chris again reminded me of one of our earliest meetings some 15 years back – in Nice back in 1992. I was a Program Manager working out of Tandem Cupertino and had been working on NonStop NET/MASTER – indeed it was at this event where we first demonstrated working code.
But my time with Chris in Nice was on a different topic completely. I was interviewing with him for a new job in his marketing team, and on my return, elected to join Chris’s team and my career path within Tandem was to start down an entirely new track…
My first assignment was to work on NonStop Availability concept marketing rollout. The platform de jour was a K Series, if you still remember these…
Fast forward: to the last day of the European event where I moderated an early morning session that was an SQL Survey Follow-Up. Essentially, itself a follow on to earlier discussions by the SQL SIG, it was chaired by Klara Franko with support from Tim Keefauver of HP NonStop Product Management.
The session was going over the results from a survey last year and was reviewing a number of action items that had been generated. HP Product Management had developed responses for them and all was going pretty well.
That is, until Klara brought up the slides on performance and suggested to the audience that the less than ideal performance being delivered was probably closely related to the undisputed fact that SQL/MX was designed to support Decision Support Systems (DSS) rather than the traditional OLTP environments where Enscribe and SQL/MP were more often found.
Well, nothing in this world is more guaranteed to grab the attention of a product manager than when someone tells him his product has performance issues! Considering that we are talking now about a product running on Itanium, and an order (and more) of magnitude better performing than anything on the K Series… I even felt nostalgic, for a moment.
To his credit, Tim remained composed but quietly rose and turned to the audience. “Before we go on, I need to clarify a point just made – it wasn’t on the slide, but the comments just made about the performance, and indeed the categorization, of the SQL/MX product are just plain wrong”!
Yes, there were some bugs in the code and it had some early performance issues, particularly with simple SQL requests where older versions appeared to be much faster. And yes, the original code base for SQL/MX was developed back in the days of ServerWare (later NonStop Software), as part of a planned move into the NT space, in support of data warehouses. But to relate early releases of the product with “what we ship today, was unfair” added Tim.
I was sitting next to Sam Ayres – and Sam took it upon himself to point out that there was definitely a perception in the user community that SQL/MX was a different product and that it was more DSS-centric than the previous OLTP-centric offerings. Indeed, wasn’t SQL/MX the base for all the Neoview efforts – didn’t the Neoview team build their offering directly on top of SQL/MX?
Now it was on – blame everything on Neoview! I could just see the first drifts of steam coming, ever so faintly, off of Tim! How had this perception developed? Where had this myth originated?
The fact that today, the Neoview team have developed a pretty good data warehouse offering from SQL/MX had nothing to do with its original design center. The fact that it had some connection with the very early efforts by the ServerWare team was of no consequence. Developers working on SQL/MX today are completely aware of the demands of OLTP, and as best as I can tell, 80 to 90 percent of deployments are in support of OLTP applications.
Sam turned to me, and said “I just wonder how we could all have fallen for this misperception! How did that happen!” I voiced my own opinion here, as I too had been in some of the user meetings where this sentiment had been expressed. I had connected the dots myself, and had wondered for some time whether the SQL/MX project was floored for the prevailing OLTP user.
“So Tim, our understanding here is all wrong then?” Sam threw back at Tim.
Fortunately for Tim, Wolfgang Breidbach, a large German user of the new Integrity NonStop server, was able to point out that performance had improved significantly and that they were having no problems with SQL/MX usage within their OLTP applications. Could it be improved? Yes, of course! But for now, it was working fine.
In remarks he made during the final Q and A session, Randy Meyer pointed out that there was a lot of investment being made in NonStop infrastructure and tools. Security, Service Oriented Architecture (SOA), and Data Base were the three big areas for him. SQL/MX was just that important for NonStop. These were all areas of importance to NonStop users and fitted well with the evolving open, industry-standard, messages now coming from HP.
Perhaps this is not the best way to open a dialogue on data base and the related subject, business intelligence (BI), and the road SQL/MX is travelling, but I will return to these topics often in future postings. Data base, whether in support of transactions as an operational data base or in support of corporate information in a data warehouse, as well as BI, are important infrastructure componenets that benefit greatly from being deployed on the NonStop platform. Something many of us overlook, with the history of NonStop so closely aligned with transaction processing, but becoming increasingly important for the future of NonStop.
I didn’t catch up with Chris as the event concluded but I can only assume he is a lot better now. I didn’t catch his flue and I don’t appear to come anywhere near being close to death from the flue bug he had. It’s uncomfortable at the time, but we all seem to get through these bouts with colds and the flue. And I am pretty sure it’s the same with SQL/MX – it may have had some bugs, and some of us have had issues, but for most of us, it looks like it’s on the mend and definitely showing good improvement.