Whilst being a bit of a techie I’m highly reluctant to write pieces that by their very nature exclude a good number of non-technical folks from enjoying the content. Needless to say, one of my colleagues managed to nail me down to putting into black and white what I usually reserve for the deep tech meetings. It seems with remote working evolving from the “New Normal” to just “normal”, dropped connections need discussing.
One of my first assignments as an intern, back in the last century, was the removal of a Twinax network and the associated Twinax cards from PC’s across the business. The dawn of TCPIP had arrived and our keenness to embrace the future with Cat 5 drove our efforts.
It wasn’t a simple process, it was the good old Microsoft DOS days, where you needed to install a TCPIP stack, install DOS LAN services and then configure each instance, basically giving the PC directions to find its way across the network “go to the end of this wire, hang a left at the switch, use the underpass at the printer spool traffic and then head toward the light”.
An article about cables, really!
The Twinax network essentially daisy chained each connected terminal directly to the IBMi, in fact Twinax had served the IBM midrange all the way back to System 34 days. I won’t go into the then limitations of addressable devices as it’s kind of irrelevant. Modern versions of Twinax, notably those connecting to SFP+ devices, are still regularly found in heavy industry- they are commonly used in place of fiber connections over short distances due to their high bandwidth, low latency and generally lower implementation costs.
The Twinax direct connection to the host meant that a dropped connection at any terminal would rarely be anything to do with network connectivity and if it was, it was because a physical connection had been kicked or partially unplugged. I’m not suggesting the move to TCPIP networking was bad, it just meant that there was a lot more networking reasons why a connection might fail, in fairness with TCPIP, dropped connections were still a rare happenstance.
Until recently, when they became much more common, when in response to Covid19 entire organizations started working from home. Then the IBMi connections started travelling out of the corporate LAN, nestled in VPN’s over the internet, traversing public infrastructure. Some folks had good connections at home but were still having dropped connections, some are using unreliable home WiFi and worse still some are using cellular data connections, in the latter cases folks are suffering terribly with dropped connections.
Adding the extra distance and sometimes air and weather, with various nodes, switches and routers in between just dramatically increases the chance of breaking our fragile IBMi connections, let me explain why.
The Cup and String Phone. A little layperson context- every green screen session on the IBMi, as far as the IBMi is concerned, is literally running on the IBMi itself. Like a keyboard and screen being plugged straight into the IBMi. All that the 5250 protocol does is allow those keyboard interactions and those screen updates to travel further away. It’s simply a piece of string with a cup at the end. You talk in, you hear it at the other end and vice versa. When the 5250 session sends a screen update, if you saw it great, if not bad luck. It’s a very basic connection.
The direct connection is important though, because it means that protocols like 5250 are stateful, they expect the host to be at the end of the line for the entire duration of any transaction or session. If there is an interruption in that connection the IBMi has no way of knowing the client isn’t there, or hasn’t got the message, let alone the concept of having to find the client again.
If your chatting with a friend in another room via “Cup and String technology” and Mum comes by and snips the string, your friend is just gone, you have no concept of anything having happened. Stretching the metaphor beyond logical boundaries, even if you knot the string back together it won’t work anymore. That session is effectively gone for both sides.
5250 does not have any of the sophistication of cyclic redundancy checking and similar packet integrity checking that you get with a modern protocols like TCPIP. So there is no “I didn’t quite get that, can you send it again please”.
In contrast a stateless application doesn’t necessarily expect that the source that started the conversation will be the one that completes it. It doesn’t actually care, moreover it will happily just sit and accept the conversation being completed by a completely different source to the original.
TCPIP as a networking protocol directly support stateless applications, it breaks down all the data being sent into packets that can be reassembled at the other end. The provision is already in place for a piece of data to lose its way over a vast network and then the receiving end knows it doesn’t have all the packets and it can therefore ask for a packet to be resent, this all happens before the tertiary end client attempts to process its next application step.
Why dropped sessions are bad
A user can be mid-way through a task and then all of a sudden with no rhyme nor reason, the session is gone or becomes unresponsive. You can reconnect and start a new session but the work that was being done before is lost and you will probably need to start again. It can be even more annoying if the session is lost and the file/record that was previously being updated is then locked by the previous orphaned session and you have to wait for that old lost session to timeout on the IBMi before you can carry on.
This normally happens to users running the business end of the organizations operations, quite rightly they don’t tend to think warmly about the science involved or the history of the protocol, especially when they are having to make excuses to a customer on the phone or they are having to start a longwinded process all over again.
The help desk phone starts to ring and a highly agitated person is making a complaint about how bad all this technology is and “it’s the Nth time today I’ve had to repeat this task” or even worse delay a customer.
If we were really motivated, we could probably do a time and motion study and calculate the lost productivity that this caused our organization, or even calculate how much lost revenue taking X amount more time with each customer costs. Regardless of this the business has a right to put their hand up and ask can something be done about this.
How to solve the problem
The challenge really is turning a stateful application protocol like 5250 into a stateless application more akin to a modern internet application. So essentially a screen update, or a block mode form submission, has to be intercepted by a tertiary application and transformed (I reluctantly say magically) into a stateless state. Let’s call this public infrastructure traversal dropped connection solution the “Abracadabra” application, because ideally it will just change the IBMi application from stateful to stateless on the fly without having to make any changes to the application itself.
Specifically, changing the 5250 application into something that can be comfortably broken into packets of data and then conversely have the end point that can comfortably reassemble that data into the meaningful 5250 session we are used to seeing.
So as far as the IBMi is concerned it’s new end point is the Abracadabra application, the Abracadabra application then becomes responsible for converting the 5250 end point into another format that can more comfortably live in the disconnected/stateless world of the internet.
Finding the best Abracadabra Application to solve your dropped connection issue
There are good and bad solutions. A bad way of doing it, which is both bandwidth and server resource hungry, would be converting it to video. This means that even a well specified server/VM will only run around 35 high usage sessions, also interactive video is about the heaviest medium to use over the web and is totally unusable over slow connections. We’ll call this question number one to establish with your potential abracadabra vendors.
Another bad way of doing it would be to take a traditional Java applet based emulator, convert it to a Java servlet and run it on the IBMi itself, victims of this strategy find themselves needing another IBMi pretty quickly as the machines resources get consumed just running the inefficient servlet, regardless of the Java licensing considerations, we’ll call this vendor question number two.
The best way to do it is to convert the screens into pure HTML, the native internet language. Like its origin protocol. It’s just text, so it’s weight travelling over the internet is extremely light and therefore also very fast. Moreover, because it’s pure HTML we can use the fastest applications on the planet to interact with it- web browsers. These already in situ web browsers replace our clunky old terminal emulators, not only are web browsers free and updated for security all the time but it means we don’t have to install anything locally. An additional bonus is that they should run on any client as well, be it PC, laptop, tablet or phone. Vendor question number three.
If the Abracadabra application manages the transformation in a truly multithreaded way, a single server/VM will be able to support sometimes thousands of concurrent sessions without breaking into a sweat, which is another good question for the would be tertiary Abracadabra vendor. You guessed it; question number four.
Ideally ,the new Abracadabra application will be a well-behaved web citizen, meaning that you won’t find any black box technology that prevents you from using all the latest security hardening that your web server can support. That’s question number five.
Good Abracadabra vendors will also allow you to leverage the HTML delivery with API’s that extend the older 5250 application even further, some even allow you to create web services and more. Consider these bonus questions that will allow you to deliver additional value add from your IBMi to your business customers and also see you not just swapping new for old.
The Net Net
If you’re running IBMi and lately remote users are complaining of dropped connections, then you need to engage with an Abracadabra web based terminal emulation vendor. Ask the above questions, if the answers are all “gold star tick”, give it a try and get the problem put to bed.