It all began with a machine which has long since found itself in an eddy of the big computer river: the IBM 3270 PC. This oddball machine was a combination of a 3270 Terminal Device and a personal computer. As one of the first recipients of one of these beasts, the author of this guide was in some ways impressed with it compared to the typical PC, as it sported a monitor with far better resolution and color than other monitors of the time. On the 3270PC, you could use a special hot-key to switch between one of four (count 'em, four) independent terminal sessions and one PC session, which was for executing personal productivity packages such as the revolutionary Lotus/123 or other exciting packages such as Microsoft MultiPlan or Word Version 1 (with a free mouse). The PC session on the 3270 PC was a standard PC/DOS session with a few TSR (terminate-stay-resident) programs to support switching out the keyboard and display in order to display one of the terminal emulation sessions. You could program the PC session just like on any PC using Assembler, the Microsoft BASIC compiler or Turbo Pascal. After only a few months on the market, a few customers started asking why they couldn't start to do stuff between the PC session and the host sessions, so that they could do fancy things like controlling the tiling of the screen or even copy information from one host session to another using a program instead of the operator's fingers. An enterprising IBM Systems Engineer in Texas (he will remain anonymous) got the hardware specifications from the Raleigh lab and figured out an ASM program that gave a programmer the ability to access the 3270 sessions from the PC session. He quickly came-up with some useful functions for reading/writing screen data, sending keystrokes and so on. This original program was distributed via mail to a number of bleeding edge IBM Systems Engineers including one in Vermont who, while anonymous is quite close to this story. He used it along with a bunch of assembler to fiddle and demonstrate a number of classy new capabilities to any and all that would listen. Low becomes high
The assembler code that formed the original capability to program the 3270PC was eventually given a high-level "wrapper" making it accessible to compiled BASIC (at which time the S.E. in Vermont threw away the wrapper he had already built). This new wrapper for these original, somewhat ad-hoc functions was given the dubious name of "EHLLAPI" which stands for Extended High-level Language Application Programming Interface. The rest is history. EHLLAPI became a standard for accessing and controlling 3270 sessions from PC programs, and it really has never gotten much better than it was originally. EHLLAPI is outside looking in
The problem with EHLLAPI in terms of productivity, is that the developer is working "here" while the terminal emulation session is "over there". In other words, the developer is "outside looking in" at the emulation session. Any time there is an action performed by a user that requires interaction with the screen, the developer must coordinate the movement of data from the user's action to the screen. Following an enter or other AID key, each reaction by the host program must be anticipated and handled by the programmer in both normal-flow and exception routines. GUI programming--a long way from a terminal
Terminals like the 3270 are controlled with streams of data and commands which format the information on the display and then control how the user's interaction with the terminal are returned to the host application program. GUI programming, on the other hand, is an event-driven, complex environment which due to its complexity provided thousands of software tools companies with the opportunity to go broke competing with Microsoft and Powersoft. The commercial complexities aside, the programming model of GUI user interfaces creates a large gap between how the terminal works and how the PC screen works. A maintenance headache
When you combined the outside-in approach of EHLLAPI with the complexities of GUI programming, the act of front-ending host screens with client/server GUI programs involved a lot of code.Now, once you have a lot of code, what is the worst thing that can happen? You need to maintain a lot of code. That is because host screens are not always static entities that are never changed. Quite often, the reason screenscraping was used was because the host application in question was a high-volume core business transaction that had to run on the mainframe because it was the only platform that could support the core transaction volumes. Maintenance isn't necessarily a big problem if it is well controlled and synchronized. The problem with PC-side screen-scraping is that all those PC's need to be updated concurrently with updates to the host screens. If the number of PC's is high enough, this becomes a logistical nightmare which can actually reduce the opportunities for enhancements to those core business transactions, as scheduled maintenance can't occur as often as would be ideal.