The other Big Lie

Almost every month or so I hear from my vendor Rocket Software how moving off Telnet will be a low-code/no-code approach. Sometimes is about this piece of software or it is about this "new" language that hooks up into the database that will ease my transition to the web. All of these scenarios are based on a big lie.

Before I get to the big lie, I should mention U2logic has been off Telnet since the early 2000s. As I stated before I embraced Rocket Software precursor companies of IBM/Informix/Ardent and others of what their visions of how I should get off either my customer's Telnet code or our internally developed code and move to the web. This generally involved 6 months to 18 months of programming work to take our 15-plus years of Telnet development and make it work on the web. For the most part, these strategies worked, however, our team barely understood why the code had to be migrated all of the time.

I learned a lot about why Telnet code makes an absolutely poor transition to the web. No matter if it was developed internally, or if the customer purchased the code from their now-defunct software supplier the problem was always the web did not work as the code was expecting.

In UniBasic for Universe/Unidata databases from Rocket Software, there is the lonely INPUT statement for all Telnet programming. With this statement, you have to wait for the user to use the enter key. Some of us got fancy using INPUT MYKEY,-1 which allowed us to read the input buffer character by character. Either way, this is the total limit of what events I have had to deal with for about 40 years.

The web is a different story when it comes to event programming. At last count, there are over 60 events?you can program for. Some of my favorite events on the web that you can use are onfocus, onchange, onblur, and onclick. onchange, and onkeypress. The onfocus gets triggered when your text box gets focused. The event onblur gets triggered when your text box loses focus. The event onclick gets triggered with you clicking a button or checkbox with the mouse. The event onchange is triggered when the value of the element is changed?in a text box. The event onkeypress is triggered when a key is pressed and released in a text box.

You get the idea web is much more complicated when compared to a single event in Universe/Unidata database programs. When programming on the web you must allow for the data to transfer from the browser to your program bypassing all of the problematic INPUT statements. Additionally, after those INPUT statements, there is more code to check whether the user has entered invalid data. Some of those tests can be moved from the program to the web which means that code can be bypassed as well. Oh boy, more code to remove.

This is not just refactoring the code as some people would like you to believe. These code changes are changing the external as well as the internal behavior of the code. I am going to stay out of the weeds where I describe all of the other things that go wrong with this approach and how these many thousand-line programs should be only a couple of hundred lines. For now, just trust me this is not as simple as I have reduced it for this article.

The Big Lie if you will, is that this is a simple, straightforward, minimal cost, and short time frame job that can be implemented by any company. Wrong! Wrong! First, your company probably does not have programmers that are adept at UniBasic, JavaScript, and HTML let alone the tools and software packages that implement them.

Most of your staff will say they can do it but fall down every time when something as simple as what do we do about record locking. Record locking is how you get consistent data updates in Telnet so that two people are not updating a vendor record simultaneously. Gee, what approach can you take on the web since you cannot lock records on the web. There you go let's have a meeting to hear all the viewpoints.

The last point on the Big Lie is scalability. With Telnet, you scaled by adding more database users. That approach will fail on the web. For example, I can open 2 to 3 tabs on my browser that should on consume a single license on the database even though I have more than one connection. If I opened 3 telnet sessions, I would need 3 database licenses. Continuing on with that example: those 3 telnet sessions are constantly polling me to see when I enter something, but those web sessions only see you when you create an event such as clicking on a button or moving off a field.

The middleware on the web must be able to scale up and down based on the transactions or events your users are requiring of it. Oh, by the way, your transaction volume will be much greater on the web depending on how you validate what your users are entering. For example, your transactions may be 30 per second which may require at least 3 users, or maybe 3000 per second which may require 30 users. The increase is not linear like in telnet because of the way the web handles transactions. This kind of thinking requires a different mindset than your staff currently has.

Do not get fooled by the Big Lie of converting your legacy applications to the web. Your VAR or Rocket Software is only telling you a portion of the truth to get the sale.