Your comfort zone may not be so comfortable

It seems like the world is changing at a faster pace. The challenge for NonStop customers running critical applications is to stay calm and focused on keeping their businesses running with as little change as possible. However, ignoring the storm around you may not be such a good idea. Recently, I received questions regarding the use of SQL/MP which inspired me to write some observations about change.

One customer wanted to implement a query that they were using in Oracle in SQL/MP. Perhaps this was part of an attempt to shift workload from Oracle to NonStop, or as a defensive move to keep applications on NonStop. I know that both situations do happen within enterprises.

The query in question, was not a very complex one, its construct however, is not supported by SQL/MP.  The question that came to my inbox was: “How can this query be transformed to SQL/MX, preferably by a tool?”.

The answer to the question is simple: “There is a tool, and you already have it on your system. It is called SQL/MX, and the SQL/MX engine supports SQL/MP tables”.

The SQL/MX engine supports many more functions and features of the SQL language than SQL/MP. Many of the functions in the engine do not depend on native SQL/MX tables and therefore an expansion of capabilities can be achieved without too much effort and risk, since all can be done with existing products.

For those that are interested in the details, SQL/MP does not support queries that include subqueries such as the following:

SELECT MAX(val)  FROM  (SELECT DISTINCT a, COUNT(*) AS val FROM TAB
WHERE y = 1234 GROUP BY b) as T;

Another customer explores ways to move data from an Enscribe database to SQL. As they described it, the database will mostly be used for writing, however they would like to use SQL for research query purposes. Again, the SQL/MX engine comes to mind because of the much richer functionality that it has over what SQL/MP has to offer.

For example, the SQL/MX engine has support for a large set of Oracle functions, which are familiar to many SQL developers. Language constructs such as the one required in the first example, may also be generated by query tools, and are therefore, supported out of the box by SQL/MX. Not to mention that NonStop SQL/MX now includes a procedural language called PL/MX, which removes a one big hurdle when migrating from Oracle stored procedures.

“Can we run this from Guardian?” is a commonly asked question, and it was also asked in these two examples. The simple answer is “yes, you can”, however, a counter-question I’d like to ask is “What is the long-term benefit of staying in your comfort zone?” Of course, people do not want to change a stable environment. On the other hand, a stable environment can become less stable because of a changing IT landscape, and there are many changes happening in that landscape today, with “Everything-as-a-service”, cloud- and microservices architectures just to name a few of these changes.

It reminds me of a conversation of many years ago. I met an IT-manager of a long-term customer. He told me that “Finding NonStop expertise was so hard”. This must sound familiar to many readers, and I asked if he could give some examples. Most of them were operational, and about the use of TACL. I asked him “Why not hire people who know Unix and Linux scripting, because the most common tools are available on his system already, and newer developments (such as webservers, Java and Python development, SQL/MX database and API-gateway) all require OSS. Besides, all Guardian programs can be launched from within OSS. In my opinion, NonStop system specific tools such as PATHCOM, SCF, MEASURE, to name a few, are programs that have a syntax that one needs to know to take advantage of certain capabilities of a NonStop system, and in essence they are not different from specific tools in certain Linux implementations”, and he agreed.

Recently I met some people from this customer, and I asked them if they were using more bash scripts in OSS these days. “Nah”, one said, “I do a lot of Python scripting though. As you know, our company has embraced Agile and DevOps across the enterprise, and therefore, also for the NonStop applications. We may rewrite some TACL every now and then into bash or Python, but only when it makes sense. Most of the applications are still Guardian based, however with the automated procedures that use DevOps tooling including git and NS-GIT repositories, NonStop plays well with the mainstream developments”.

This customer has been able to adhere to new enterprise standards which were just put upon them by embracing the OSS environment. While it is possible to start a shell process from the TACL environment and directing the output to other Guardian processes, it is not as easy as doing the reverse. Using OSS as a starting point means that you can benefit from Linux market experience, which is much more common than that of TACL and Guardian. Teaching those with Linux or other IT expertise a few new utility commands for specific Guardian features will not be hard.

To come back to my two examples, adopting the use of OSS will silently remove the hurdle that has kept many from using NonStop SQL/MX to use existing data for new applications. And it allows a smooth introduction of SQL/MX native tables that support hash partitioning in addition to range partitioning, larger block sizes of 32K for tables and indexes plus support for large objects to name a just a few highlights.

Perhaps more important is what can be learned from the customer that needed to implement new development and architecture standards. Whether development standards, such as DevOps or architectural standards or using Microservices, the NonStop OSS environment allows you to say “Yes, we can accommodate this approach”.

And with NonStop SQL/MX as a database server platform your NonStop will even be able to act as the scalable and available database platform regardless of where the applications might be implemented: as containerized stateless apps in Kubernetes clusters or as applications that run on the NonStop platform in a Java or Python application framework that communicates via the standard database APIs.

You don’t have to leave the comfort-zone, think of it as just expanding it in preparation for adjusting to the changing IT-climate.