From Telnet to Web: A Short Story

Let's go through a brief history of moving to the web through our eyes. Of course, we only used Unidata back then. U2logic was a VAR for Unidata the company. Nearly 100% of the work we did back then was to maintain Telnet applications (green screen) and enhance them. Today 100% percent of our work is Web-based application development. 

We starting looking at going to the web in the late 1990s. There was not much in the way of tools or technique. It was tough to get any traction until we found an ISP that would host our site. We created the site using HTML and a little JavaScript. By the way. Cascading Style Sheets was just invented and we could not figure it out so we embedded style in the HTML. We had a CGI interface. We read information from a flat file and posted it from our database to the web and read back the data to our database. 

We found Redback back around 1999. Redback only ran on Internet Explorer version 4 using the Microsoft web server. The Redback code was kludgy and our code was even worse. Nonetheless, we starting learning how to talk to the Web and how clients would react to entering data and running reports. 

Shortly thereafter Unidata replaced Redback with Redback Open containing Redback Objects (RBO). This time we had an executable that we could talk to our database. RBO’s were a major step up when communicating with our database. Nonetheless, the problem was all of the code we created with Redback we had to throw away. The two systems were not compatible. Well, that did not stop us. We converted most of our applications to Redback RBO's.

There were a few severe problems with Redback RBO’s. Redback required us to restart our Microsoft web server at least once a week or it would just stop working. We had to run a manual purge to clean up temporary files that Redback created because the Redback garbage collect did not delete all of the files and would continually slow down.

One of U2logic's staff suggested we write our own middleware to solve Redback’s issues. We thought the idea was crazy, but what the heck. Though and behold around 2006 we created U2WebLink which supported Unidata and Universe. This software used the same ideas as Redback's RBO. U2Weblink middleware which was written in Java ran using UniObject for Java and Apache Tomcat as the webserver. We got to keep most of UniBasic code, HTML, and JavaScript a very surprising fact for us all. 

Today we are still using U2WebLink. The current version runs on Java 15 and Apache Tomcat 10. Moreover, U2Weblink supports an open-source reporting tool call BIRT from Eclipse.org that can produce PDF, HTML, DOCX, and XLSX output. We developed an API that allows us to call UniBasic Subroutines without creating an object for interface purposes. U2Weblink is highly scalable and has been tested with up to 15000 users. Since we built our monitoring system from within it does not take up any noticeable resource and gives you a picture of how the system is running. We stopped trying to develop our own JavaScript library routines back in 2008. Currently, we use a JavaScript library called Webix.

Telnet to Web: A selected example

 There has been a lot of talk over the years of how to get your telnet applications to the web or at a minimum change the user interface (UI). I have lost count of how many times my database supplier Rocket Software for the last 10 years and IBM before them have told me how easy it would be with this tool or that tool to do this. Most of those tools are long since gone and replaced by others every time I see a new demo or “training seminar” from them. Every example that is shown is so simple you have to wonder why is this so hard. Then it dawns on you that have are just showing text boxes, images, or other uncomplicated things.

There is a simple example that I will show you what I mean. Almost all telnet applications have user input and programmers need to verify this against a code file to get verifiable data. For example, the users enter an employee type code such as “DW” for dock worker or “FO” for forklift operators. We verify that “DW” or “FO” is in the code file before we let the user go to the next prompt in a telnet program. All the user sees is an empty box in that type of UI. The backend software is doing all of the work and telling them if the data entered is correct.

On the web, we change the plain area to a select box. A SQL/SELECT statement is written to select all of the records in the employee type file and display them to the user. That way you do not have to keep verifying the data every time the user types in the UI because you have allowed only valid data that can be selected.

The first complication sets in if this field allows no value you have to change the select to have “Pick-a-Value” or “Please choose” that equates to no value. This means you cannot easily select all of the values from the code file because you need to prepend a null value onto the list and must do this programmable. You can do this with UniBasic code in our database or using a function in SQL to concatenate on to your select.

The second complication sets in because once the user sees this UI, they want it to autocomplete. Oh really, that was not even how the prior application even worked. Welcome to the web because those users have spent time on Google, Amazon, eBay, and others to name a few and they work that way so why does not yours. Of course, the JavaScript library tools I use to support these select types: select, combo, multicombo, multiselect, and richselect. All of those types all have additional options that will keep you busy for hours.

The third complication sets in because the code file you have is not as simple as employee types. This file, for example, is customers in which there are about 100,000 records. You cannot have a 100K select box that would be awful to load and be unusable. The solution is called lookups which are concealed in the text box in the right or left corner with an image of a magnifying glass. After the user presses the UI magnifying glass they are presented with a table of the first 15 to 20 values. The bottom of the form has page numbers to show you how many pages there are or just shows a left arrow on the left and a right arrow on the right with a few page numbers in between that is called pagination.

I have completed a few complications about SELECT HTML code boxes that can have lots of complexity. There are many other issues that were glossed over in many of those demos I saw and you may have seen as well, while this article has taken the time to show you one piece of this web-based UI puzzle that hopefully shows you what it takes to complete just one specialized prompt.

I have just finished an upgrade from our prior JavaScript library to a new JavaScript library that changes our entire UI. There is a lot to learn even for this old dog and SELECT boxes were just one of the many different UI choices that were made during the upgrade.

Software is all about compromises

The client wants this function or the client wants that function. Your staff says this new cool JavaScript library will save you time and money. Your staff says if you buy this tool you will be able to do amazing things with it. You find out that you nobody on your staff has the expertise that you promised a client you could do. Let's take this one by one and see where they lead

This function the client says their software needs are based on what? It could be their competition has this. Or the CEO saw this in a premier business paper and tasked the client to get it done who called you. Whatever the reason, the software company must look at maybe this is a need that can be filled later without impacting the current timeline. Maybe if you don't architect this into the software, you will be delivery the software on time and in working condition.

Every tool that gets released the staff says the same thing: with this tool or software package, we will save lots of time and money. Anyone remember VB4, dBASE4, ACT2000, or some other acronym software that has long since died. Look for tools and databases that are stable that have been out for a while that may not be the best in class but they are backed by a good company and still have updates.

When a client asks you to write a PCL driver. Of course, we all say yes even though no one in the company has ever written a driver before. Then when the client gets the bill, you have to explain why it took many more months and cost 400% more. Only write software in your comfort zone you will be happier and your clients will be too.

No one can foresee the future yet, so it becomes apparent that you must look at each new idea with a grain of salt. Always, ask the stupid questions up front rather than explaining to your client that this project, database, and or tools you picked cause us not fit your client budget or timing.