Why HP NonStop Servers Should Embrace Reactive


If you’ve worked with reactive, you probably have never heard of HP NonStop servers, and conversely if you’re working on HP NonStop servers, you’ve probably never heard or “reactive”.

First, for anyone not familiar with HP NonStop servers, a little explanation.  HP NonStop servers were originally known as systems built by Tandem Computers back in the 70s.  You probably have never heard of either.  HP NonStop servers are a mainframe-grade server that has typically had a very niche market.  The servers are a fully fault-tolerant (not failover, not hot-standby) “never-go-down” systems.   They are used by many stock markets, ATM networks, 911 call centers, and pretty much any business critical environment where losing data causes loss of money or life.

The point of this post deals with another aspect of HP NonStop servers.  They are reactive and have been so since the 70s.  The weird part is that HP NonStop servers don’t realize or acknowledge it.  So what do I mean by “reactive”?

Reactive is the new hotness in IT. Back in 2014 a group individuals introduced the “Reactive Manifesto” http://www.reactivemanifesto.org to the world. In a nutshell, the Reactive Manifesto lays out a way to design, architect, and build software. Many large companies are adopting this approach. Programming languages and frameworks are arising and or are being modified to adapt to this way of doing things, Java, Scala, Akka, etc are just a few.

So what does it mean to be reactive?  Per the manifesto, a reactive system is: responsive, resilient, elastic, message-driven.  That last point should make your ears perk up if you are familiar with HP NonStop servers.  HP NonStop servers have been message-driven at the application and OS levels since day one.  What about the other points?


“Responsive systems focus on providing rapid and consistent response …”  One of the primary goals of HP NonStop servers is to meet business-critical response time SLAs, in a mixed workload environment. If you’re not familiar with this term, it is the HP NonStop server’s ability to run OLTP, batch, DSS, and Data Warehousing on the same machine, in production, at the same time.  In fact, there is no technical reason to have a batch window on the machine. HP NonStop servers are responsive.


“The system stays responsive in the face of failure.”  HP NonStop systems are truly fault-tolerant (more than fault-resilient).


Systems can react to changes in the input rate by increasing or decreasing the resources allocated to service these inputs”   HP NonStop servers have the ability to adjust to loads by spawning and killing off processes in order to handle the load for a given business task.  This is the HP NonStop server’s TS/MP (Transaction Services/Massively Parallel) environment.


Employing explicit message-passing enables load management, elasticity, and flow control by shaping and monitoring the message queues in the system and applying back-pressure when necessary.”   As I mentioned, HP NonStop servers are fully message-driven, including the OS itself.  What this implies is that the system is a shared-nothing environment.  There is no real shared memory or global space.

So where am I going with this. Simply put, HP NonStop servers are fully reactive and have been so since the 1970s.  However,  the platform has not embraced this approach in its tools or marketing.

HP NonStop can learn a lot from the reactive movement that is actively espousing it. In some ways it is also competing with HP NonStop.

Conversely, the reactive movement can learn a lot from how HP NonStop deals with reactive in a mainframe (as opposed to mini-server clusters).

HP NonStop programmers can and should learn a lot about how actors work and how to better implement asynchronous environments.

HP NonStop servers and the reactive model are made for each other.

On a personal note, “I have been doing reactive since the 1970s.”


“Code Review” – [sung to “Hotel California” – apologies to The Eagles]

On a bright sunny morning, I walked up the stair
Warm smell of nachos, rising up through the air
Up ahead in the lunchroom, I saw a shimmering light
My head grew dizzy and my sight grew dim
I had to stop for a bite
My manager stood in the doorway;
I heard her menacing growl
And I was thinking to myself,
“Oh oh this isn’t good, yes I’ll probably get Hell”
Her face lit up with a sneer, as she shoved me aside
There were voices down the corridor,
I thought I heard them say…

Welcome to today’s Stand Up
Such a lovely place (Such a lovely place)
Such an awful stack trace
Plenty of room at today’s Stand Up
Any time of day (Any time of day)
You can find it here

My mind is dazed-twisting, I got the mental bends
She got a lot of sticky sticky notes, notes she calls trends
How they stick to the whiteboard, bright paper squares.
Some code to remember, some code to forget

So I called up the source code,
“Please bring me my commit”
Siri said, “We haven’t had that project here since nineteen eighty nine”
And still those voices are calling from far behind me,
Wake me up in the middle of the night
Just to hear them say…

Welcome to today’s Stand Up
Such a lovely place (Such a lovely place)
Such an awful stack trace
They codin’ it up at today’s Stand Up
What a nice surprise (what a nice surprise)
Bring your alibis

Breakpoints on the display,
The tests crash the device
And I grumble “I am just prisoner here, of my own device”
And in my manager’s office,
Their coffee spills from their mugs
They stab at my code with their steely eyes,
But they just can’t kill the bugs

Last thing I remember, I was
Shown out the door
I had to find new employment now
I would code no more
“Relax, ” said git hub,
“We are programmed to receive.
You can check-out any time you like,
But you can never retrieve!

— @Archimage

Thoughts On Apple’s WWDC 2014 Keynote.

Apple is having its 2014 World Wide Developer Conference (WWDC) if you haven’t heard. As the name implies this is an opportunity for Mac and iOS developers to get together and learn about what is new in the Apple ecosystem.

Over the past few years developers have felt (right or wrongly) that Apple was giving short-shrift to developer concerns, problems, and wishes. Not this year.


So why should you, as a non-developer, care? Or for that matter if you’re a developer on another platform care what Apple developers do? The reason is pretty obvious: at this point in time, what Apple does (and has been doing) affects pretty much everyone who uses technology, even if they don’t use an Apple product.

So what’s different this year? Apart from the WWDC Keynote pretty much everything is still under non-disclosure. Here’s what we do know (and can talk about).

No new hardware was announced, which isn’t surprising for a developer’s conference. What usually gets announced are the new versions of Mac OS and iOS and Apple didn’t disappoint. Apart from the usual “chrome” updates on the Mac, Apple introduced a few unexpected things.


The major feature is what Apple calls “Continuity” which is the ability to seamlessly transition from an iOS device to your Mac and back. Say you’re working on a document on your iPad. If you get close to your Mac, your Mac detects your iPad and you can pick up working on your document on the Mac. This may not sound cool or useful, but seeing it is impressive. “It just works.” It’s the type of thing that makes you go, “why didn’t I think of that”, or “this is the way it’s supposed to work.”

Last year, Apple introduced their Multipeer Connectivity API along side their iBeacon technology. Both are “near-field”, meaning you have to be close to something to use it. iBeacons got all the “buzz” and press. I came out on Twitter a while back and stated iBeacons are cool, but the real power is in MPC. Apple’s new “Continuity” works more like MPC than an iBeacon setup. I think “Continuity” is just the first card in Apple showing us what MPC can really do. iBeacons are good in stores and factories, MPC is useful everywhere else. That’s just my observation.

“Continuity” was demoed with a focus on Macs, but switch your perspective. Continuity works just as transparently with iOS devices. It can also be made to work with other platforms. It requires no specialized hardware short of wifi or Bluetooth®. Expect to see lots of CAD (Context Aware Devices).

HealthKit / Health

Next, Apple didn’t announce the rumored iWatch, or Apple TV. What they did announce was a developer environment for managing your health, known as HealthKit and an app simply called Health. The app has similarities to Passbook, but will be more successful. Apple has done it’s homework. Instead of creating its own hardware Apple has provided an integration layer to allow vendors such as Nike and others to integrate their hardware and biometric data into a single (data) view. Genius. Now all the gizmos you may have can coalesce their data into a central repository.

Apple has also worked with health organizations to allow HealthKit to call out to doctors and hospitals if it detects your biometric data indicates you have a problem. Expect to see an uptick in consumer medical “widgets”.


Apple also threw its ring into the Internet of Things (IoT) when they announced HomeKit, which takes the HealthKit approach of providing an integration layer to all the home automation IoT devices that are coming on line. Apple says it’s providing a software hub with a standard protocol to allow the various devices to interact. IoT isn’t all that interesting if you can talk to a device and the device can talk to you; it becomes powerful when a device can control another device.

CloudKit / CloudDrive

Apple has been struggling with their iCloud environment, both from a user and developer perspective. iCloud sync was crippling to develop and worked sporadically if you got it right as a developer. Apple has shifted focus a bit (and I believe for the better) by sidestepping the syncing issues by allow a more “Drop box” approach. Now, users can see iCloud as a virtual drive on the desktop and iOS devices. A user can move whatever files and folders they want onto the CloudDrive and have it synced across devices. A lot simpler, a lot more fool proof than integrating background synching in an app via iCloud. iCloud synching is still there as well.

The other aspect of this technology is Apple is positioning this to developers as a back-end cloud platform. Apple has abstracted the server-side code and now developers can create Mac and iOS apps that have a back end server environment, essentially with no work on the back end. Apple hasn’t done so in this WWDC, but expect Apple to allow developers to be able to leverage this to create web front ends in addition to app clients.

Various Other Announcements

There were a lot of other announcements, that are mostly of interest to developers. Mac and iOS “widgets”, Inter-app functionality exports, etc.

One Last Thing

The one announcement that stunned everyone was Apple’s announcement of a new programming language.????!!! Objective-C was the language of choice for Mac and iOS developers.

I spent the night reading the Swift manual that Apple released. It’s an interesting mix of Ruby/Javascript/Go and a few other languages. It includes object-based, reactive, and functional elements.

So why a new language? Apple claims its more modern and designed to get the “C” language cruft out of developing in order to be able to code faster, and with the ability to avoid and detect problems in code. They also claim it executes faster than Objective-C.

The demo Apple gave shows a more interactive environment (think interpreted languages or languages with a REPL). Swift however appears to use a compile-REPL rather than being interpreted. The immediate feedback when coding is great and the code looks a bit “cleaner”.

One thing that Apple didn’t address, is that Swift is a lot easier to learn than Objective-C. I believe Apple wants to dip into the pool of Ruby / Javascript / Go programmers, and more importantly, they are going to get a lot of first-time developers drawn to the ecosystem.

Secondarily, I believe Apple is working on something that every developer has wanted since the original iPhone came out. On-board development. Swift is the perfect language to have if you’re going to be programming on the iPad or iPhone itself. The syntax is easily parsed and can actually be interpreted on a device without having a full compiler. This is the man behind the curtain of Swift.

Tie Swift on a device with Continuity, and you have something every developer wants yesterday.


Apple has had great announcements before. This year is up there as the best or if not the best, up at the top. The main takeaway I got was “ecosystem”. Whether you’re an Apple hater or lover, you’re going to be affected.

#technology # thoughts # iOS

Sent from my iPad

The Cost of Corporate Education

There is a problem. The issue is that employee education and training are seen as costs rather than investments. That’s just a symptom of the real problem.

I’ve spent a lot of years doing consulting, project management, and corporate training to Fortune 500 companies. I’ve seen it over and over. I’ve also experienced it personally. I have seen companies sign their employees up for training. They are in class, and then they get pulled out ‘to fight a fire’ or to attend a ‘weekly con call’. Hm… What does this say about the company’s priorities? They’ve already spent the money on training, but the con call is more important? The company didn’t have someone to backfill the ‘fire’? Short term goals vs. long range planning. It results in wasted money and frustrated employees.

The problem is that companies, both large and small, perceive employees from the perspective of businesses that existed in the 1920-1950s. Technology, culture, and products change. Businesses, to a great extent, apparently don’t.

Henry Ford invented the assembly plant as you probably know. It was an amazing innovation since it allowed cheaper products that could be delivered faster. (You can consider Henry Ford the first proponent of Lean, but that’s an aside.) The not so obvious other result of the assembly line is that it allowed for the easy measurement of and quantification of employee productivity. The assembly line and factories could easily measure how productive any given employee was based on how many widgets they installed, or produced. ‘Piece work.’ Employees got paid based on how many widgets they produced. The more you produced, the more you made, and the more productive you were perceived.

Employees spent most of their lives producing widgets, and if they wanted to succeed, they tried to eke out as much time as possible. This didn’t leave a lot of time for self-improvement. How do you measure the ‘productivity’ of programmers, consultants, or other ‘soft’ delivery employees? We need a new term.

There is another problem. Companies don’t like to change. The larger the company the less change they can either afford monetarily or tolerate due to internal processes, design by committee, the desire for internal consensus, and inertia. ‘We have always done it that way…’ It’s as difficult to change the direction of a large corporation as it is to rapidly change the direction of the Titanic. Another aspect of this that I’ve seen is the ‘If it’s not broke, don’t fix it’ philosophy of business. ‘If the assembly line worked for Henry Ford and my grandparents, it will work for me.’

You may argue that by training your employees they will be better able to do their job. Again, how do you quantify that. The perspective that everything needs to positively impact the bottom line stems from having to measure everything in terms of widgets, money and profit. Don’t get me wrong, and don’t take this out of context. I’m all for money and profit’it’s important. It is, however, not the only measure of success. Companies don’t measure ‘success’, they measure bottom-line metrics.

‘Human resources.’ Things that you can measure. ‘Personnel’ sounds more human, doesn’t it?

Education and training are investments. It’s a long-term perspective ‘this will help you solve problems and be more efficient in the future’, rather than the short term perspective of ‘what did you produce in the last week.’ Why do you send your kids to school? They aren’t productive when they are in school…

Another failure I see in a company’s approach to education, is employees are often sent to a class ‘because my manager told me I should take this class.’ That’s better, but really’talk about student motivation. The student doesn’t want to be there. The manager believes the information will help the employee be more productive and better able to do their job. The student is often the best judge of what he or she needs to improve in their job. Employees as a whole want to do a good job. They want to improve.

Employees are forced to take classes they may not need or want. Or they take a class and then they may shift to a new role or position and never get a chance to use the information. Then the company deduces that training is a waste of money, time, and productivity. It’s not the fault of the training or the employee. It’s the fault of the company in not managing education and training as part of the overall business process.

So, let’s pull this together. Education and training of employees are seen as costs rather than investments because of the outdated business model that if an employee is not producing something concrete and measurable, they aren’t productive. It’s extremely difficult to measure programmer or even consultant ‘productivity’. Companies don’t invest in something you they can’t quantify and ‘improve’. If it doesn’t have a direct effect on the bottom line, it doesn’t exist or is a cost.

That’s the bad news, and a lot of companies are in that ‘mindset’ (companies don’t have minds). The good news is that there are companies that value education and training and make it a yearly requirement. More importantly, they actually follow through rather than just having this as a hollow promise based on budgets.

Employees who can take training, and training they want or need, even if it’s not directly related to their jobs are going to be happier. They will be more creative. They will be able to have a perspective not tied to their immediate jobs (this can be scary for some companies). They will be able to solve a wider range of problems. They will be more productive.

Sent from Auteureist™

A Need for Code Understandability Metrics

I had an interesting Twitter chat with someone during the PhillyETE conference. One of the major takeaways from for me was that source code is written in order to be read (in addition to being executed.) Humans are going to spend a lot of time reading your code (even if its only you). The code should be written in a way that enhances its understandability. The chat got me thinking.

Testing is a hot topic. Many developers do TDD, BDD, unit testing, integration testing, deployment testing, etc. But when it comes to testing whether or not our code is understandable, we mostly fall back on code reviews. We don’t test the understandability of the code we review.

What does a code review test? I’d argue a code review’s purpose isn’tt to test anything, its purpose is to assess the quality of the code, its functionality for overlooked defects, to share knowledge amongst peers, and its readability.

For the most part code reviews are highly subjective and personal, guided only by experience and the process established to run them. “Readability” is often used interchangeably with “understandability”. A program with no white space is a lot harder to read than a program with white space. That doesn’t make the program any more understandable.

One point that came up in the chat was that whether the code is understandable is dependent on the business and understanding the business processes. It’s domain driven. (Assuming a non-DSL programming environment). I’d argue the domain information is independent of whether or not someone can read the code and easily understand what it does.

Knowing what code does is functional (no pun intended). The domain information is the purpose or reason for the code and function. You need to know how your bank implements a funds transfer, that’s domain information. Understanding that the code takes a value out of one database structure and adds the same value to another database structure is functional and independent of the banking domain.

Understanding why the code does something is different from understanding how it does it. These are two different levels of understanding.

So, why am I focusing on understandability? I’d argue that the greater the understandability of the code, the easier it is to manage, debug, pass on, etc. Read, “easier” as “more efficient” if that helps.

What makes one piece of code more understandable than another? Uncle Bob Martin’s book, Clean Code, is a good place to start. But there is a big problem. How do you quantitatively measure whether a piece of code is more understandable than another? One may argue that itâs highly subjective. I’d argue not. Here is a simple example:

What does this do? +/X>100 This is a real programming language.

What does this do?    for number in X
                                        if number > 100 print(number)
Which one is more understandable? You say that you need to know the language to understand the code. Of course. But I can give both of these examples to random non-programmers on the street and a majority could figure out what the second example does. It’s more understandable. “Well it’s more English-like.” True.

If you’re a c/C++ programmer, what does this do?

main(a,b)char**b;{int c=1,d=c,e=a-d;for(;e;e–)_(e)<_(c)?c=e:_(e)>_(d)?d=e:7;

(this from the Obfuscated C contest.) The understandability is [intentionally] bad even though you may know the language.

We need a way to measure and objectively compare one piece of code against another for understandability. We need metrics. We need tools.

This is an extremely hard problem to solve. It encompasses the language, white space, all of the “clean coder” concepts and others. It is, however, I’d argue independent of domain knowledge.  I believe it’s important.

Any volunteers? Flame on!

Philly ETE In Review

Welcome to my new blog.

First, a little about myself. I’ve spent most of my professional career designing, developing application solutions, and training people in massively scalable, massively distributed, “reactive” systems and relational databases. I’ve done project management, consulting and programming in more languages than I can list here. I develop iOS apps in my spare time and am teaching myself Android development. I’m also an author/writer, ham radio operator, cook, and beer brewer. I also stir the pot on Twitter.

Second, a little about this new blog. I hope this will be a place where I can toss some of my ideas about technology (specifically IT) to the internet winds and see what hits me in the face as it blows back. I’m going to try to post on a more or less regular basis as time and ideas permit. Why now? I’m looking for new opportunities and I have some time.

Third, so what’s a tesseract? It’s a four-dimensional cube, a hypercube. So the name references the idea of thinking a dimension or two “outside the box”. I like to challenge ideas and thinking.

So, enough about me. You probably dropped by to read about The Philadelphia Emerging Technologies for the Enterprise conference which had its 9th year.

PhillyETE, as it’s affectionately known, is organized by Chariot Solutions and is held at the Sheraton Society Hill and is the premiere technical conference for developers, managers, and thought people in the region. I’ve been attending for most of the years it has been put on and I have to say it is an amazing conference. This year was no exception.

The lineup this year was top notch including speakers from all over the country and attendees all over the world. If you’re interested in the details head over to http://phillyemergingtech.com/2014. Each year PhillyETE has a core topic. This year it was reactive programming and design, but as usual there were topics related to management, products and other technologies.

The firehose of information and knowledge, along with the conversations, food and location are both exhilarating and always leave me with more ideas and things I want to try than anyone can achieve. It’s a way to recharge and motivate myself as well as to meet new people on areas I normally haven’t had a chance to work in.

This year, PhillyETE’s topic seemed to be reactive programming. I’d heard about it for a few years now and really hadn’t had a chance to dive into it much. The ironic thing is I have been working on reactive systems and application designs since the 80s. The session called “Go Reactive: Blueprint for Future Reactive” by Roland Kuhn, Akka was stuff I already knew and used. The main difference was the language. The architectural design and paradigm was second nature to me and I was sensing déjà vu.

“Back in my day…” we called it “event-driven programming” on desktops. On servers we call it “message-driven”. On the server side the architectural differences are minor. I’ve worked with message-driven reactive operating systems as well. Who knew! Cool!

Now I just need to learn Akka well enough I can put it on my resume.

Dave Thomas did a great presentation on the programming language Elixir, and how it helps to learn new things and ways of thinking. He presented a video of a tribe that could not distinguish certain colors because they had no words for them. The analogy being you can’t see different ways of doing things if you can’t talk, describe, or code about it. There was a lot of startled murmurs in the room after the video. I have “collected” programming languages for years. I have done everything from APL to assembler to NewtonScript to ObjectiveC and a bunch in between. Elixir is different and interesting enough I should give it a try.

Those were just two highlights of the conference for me. At the end of every year I always feel a mixture of wishing it was a week long conference, and relief that it was done and would I ever use any of this “cool” stuff. In either case, I always look forward to the next year’s event.

Thanks much PhillyETE, Chariot Solutions, speakers, Sheraton, and new friends. Learn on!

Sent from Auteureist