Who am I?
My name is Joe Peterson. I am a software engineer at NuWave Technologies, the leading NonStop application integration solutions provider. I joined NuWave a little more than two years ago, and it’s been a rejuvenating experience for this long-time veteran of the NonStop world. I come from a background mainly in online transaction processing. I have worked on nearly every variation of the NonStop platform, from the ancient T-16 to the venerable VLX to the latest “X” and blade systems.
Some of the many benefits of the NonStop platform are that the user experience is the same across platforms and that applications are easily portable from one generation of the NonStop to another.
However, one of the disadvantages is that the way applications are built changes very slowly. Many, if not most, NonStop developers are still using the same tools and processes from decades ago: TEDIT or EDIT/VS for editing code and simple TACL scripts or homebrewed Make tools for compilation and linking/binding. This is usually followed by “single issue” testing. In many cases, these repetitive tasks are performed manually, making them error-prone.
Granted, this is not the current situation for everyone, especially not larger organizations with the funding and wherewithal to implement more sophisticated tools and processes.
Many companies have embraced newer technology. Much of that technology has been used by developers for many years, developers who’ve probably never heard of a “NonStop.” This newer technology can be integrated into NonStop development practices with a little work. For example:
- Smooth-running, feature-packed integrated development environments (IDEs) such as VS Code, instead of just tedious “green screen” text editors.
- Windows Subsystem for Linux (WSL) for using shell scripting, running cross-platform compilers and linkers, and locally running Java for running tests against NonStop code.
- Near standard services such as GitHub for revision management and job running for building automated continuous integration testing.
- Source code analysis through services such as SonarCloud to expose errors and security holes.
My daily workflow has changed dramatically since I began using these new technologies. Learning the “ins and outs” of NuWave development (on top of learning the inner workings of NuWave’s product line) was quite an adjustment at first, but adjustment is continuous.
Green Screens in Smithereens
Most who’ve worked on a NonStop platform for more than a few years have likely used TEDIT or EDIT/VS to edit text files. There’s nothing wrong with that. I did it myself that way for decades. Unfortunately, it does have its drawbacks, not the least of which is what we “old timers” call “green screens” – simply because the only color we could see was green. The size of the screen was limited to 24 or 52 lines of 80 or 132 characters each. We know them as the “T-6530” or just “6530”. This nomenclature is from the original terminal model names for the NonStop (the history of which is beyond the scope of this story).
Also, for decades, we’ve had “6530 terminal emulators”: applications (usually) running on Windows desktops that mimic the behavior of the original hardware. Emulators helped break the green monopoly by making a large spectrum of colors available. However, the emulators are still limited by the NonStop to 24 or 52 lines by 80 or 132 characters.
If you explained this scenario to a young developer who is used to IDEs and graphical interfaces for every task, they would likely look at you with disbelief. Then they would ask: “How can you work like that?” Before entering this brave new world at NuWave Technologies, I would have answered, “It is what it is.”
Now, if asked the same question, my response is, “I don’t!” with a smile. For me, the “green screen” has been shattered forever.
Tools and Utilities and Libraries, Oh My!
Many of us compensated for the monochromatic by using “programmer’s editors:” graphical editors with features like syntax highlighting and minor code completion mechanisms. But an editor is still just an editor, even with a “macro language” behind it.
An integrated development environment, however, includes so much more. IDEs add so many other tools to the development process that it is impractical to list them all. But my personal favorite is a tool like IntelliSense in VS Code. It offers suggestions and automated code generation as you type, helping to speed up the process and reduce errors. Other features include context-aware suggestions and code snippets. TEDIT can’t do that.
Another new tool for me is Windows Subsystem for Linux (WSL). I didn’t used to think much about it – until I started working at NuWave. Now, it’s integral for my daily work with Git/GitHub, VS Code, Java-based unit testing, and more.
Probably the biggest change between my past NonStop work and my work at NuWave is using open-source libraries on the NonStop. There were countless occasions over the years where functions in the C language run-time library, for example, would have made my task quicker and simpler. But they were unavailable due to the application’s programming language (TAL, as venerable as it is, cannot compete as a modern language). Now, I spend less time rebuilding wheels and use that time instead of working on the actual program logic.
My Only Way to Fly
My developer’s life at NuWave is like no other job I’ve had. I’ve learned a lot about tools and techniques (that I should have learned ages ago). One might say I have “seen the light.”
Contrasted with many years consulting in the NonStop world, where I saw many ways of building software for the enterprise: from plain TACL obey files to sophisticated systems that build and package it all for you. I have repeatedly seen different built-in libraries encapsulating the same basic functionality. I’ve seen code changes made on top of commented-out changes on top of other commented-out changes because of antiquated source revision management, or the complete lack thereof, making such breadcrumbs comfort food for the forgetful developer.
I don’t think there are any technical justifications for any of those things. The tools and techniques are there for modernizing the development process:
- The technology behind Git/GitHub is open source, meaning any organization could set up its own internal Git servers to store code and documentation (or almost anything else).
- Shell scripting to interact with Git and the NonStop does not have to be in a WSL bash. PowerShell and even plain command-line scripts could be used readily.
- Desktop Java Gradle projects to build unit tests instead of expensive third-party tools.
- Desktop Java code that can monitor changes to your local code base and automatically submit SFTP transfers to copy those changes to the NonStop.
- Automated continuous integration with tools like GitHub Actions (GHA) to schedule test runs, move code, or any number of things.
These tools and techniques have been available to modernize the enterprise development process for quite a while. Some are used piecemeal. But rarely are they used as a cohesive whole. We did that at NuWave. Of course, it didn’t happen overnight. And though some of the tools have changed over time, the patterns of development remain the same: coding in modern languages that support the adoption of open-source libraries, building unit and continuous integration tests so everything can always be tested, and consistently packaging the software.
You could be working like that, too.
NuWave Technologies leads the way in innovative enterprise solutions, specializing in HPE NonStop integration. Our mission is twofold: to deliver intuitive software solutions while making a positive impact. With a focus in sustainability, we’re dedicated to reducing our environmental footprint and supporting initiatives for a greener future. Join us, as we innovate, streamline and make a difference.
Connect with NuWave Technologies:
Website: https://www.nuwavetech.com/
Twitter: https://twitter.com/nuwave
LinkedIn: https://www.linkedin.com/company/nuwave-technologies/
Be the first to comment