Getting to that point

I've been banging my head against a hard problem at work for a while. Without getting into too much detail, I'm trying (as I often do) to get a program to do what I want, not what the creators designed it for. At least that's how I've been looking at the problem and it's been very frustrating and now I come to find out that I was wrong. Very wrong and very stubborn and maybe the head banging is part of my natural learning process, I've been through similar things before.

We've got a program that is mostly used by people sitting at PCs (or any kind of terminal) and interactively doing the tasks required to get medical bills and prescriptions and office schedules to behave the way we want. The problem is that there are cases where a person sitting at a terminal is just too error prone and slow and overall a silly way to do things. Like processing 986 claims (like we did this morning) to see if they should be paid and then printing a check for each that is valid.

We've been using a couple ways of simulating a person at a keyboard and hooking that up to the application and getting things done faster than a real person. The main technique has been to script a terminal emulator program to send keystrokes in the correct sequence to get a process done. This way the application thinks it's attached to a real terminal and behaves normally. A proper script can automate the process by becoming the perfect user.

Except that the terminal emulator program itself has problems. If the application doesn't send back the expected prompt quick enough, like if the system gets busy, then the emulator stops waiting and starts sending the next keystrokes which the application isn't expecting and the whole process falls apart. Other random failures are occurring, in these cases the perfect synchronization between the emulator sending keystrokes and the application expecting them fails and nothing much gets done.

I have been focusing on sending the keystroke data to the application in different ways without the emulator being involved at all with little success. You know this button across the top of your keyboard? Labeled F1, F2 etc...? They send out special codes that the application needs if it is attached to a terminal and are very difficult to send without a real keyboard or an emulator.

That was the key insight that has broken my logjam. If the application is attached to a terminal... Well, how about if it's not? Like if it's a batch job reading input from a file? Then, it behaves completely differently. The application running in batch happily reads an input file without needing the troublesome function key commands. Almost like someone designed it that way. I think they probably did but nobody bothered to tell me. My predecessors and then myself were focused on one mode that was driving us all crazy, not knowing that there was another mode that did everything we wanted. If we had only known.

Hopefully, with this breakthrough, I can move forward to getting this place out of the stone age. With a reasonable batch control system, scheduling and monitoring batch processes nirvana can be just around the corner. At least that's how I feel now until the next unexpected roadblock. But optimism for now and face that when it comes.