A Little History of EHLLAPI
HLLAPI followed the use of 8086 Assembler as a means to integrate to the screen sessions active in the 3270 emulation portion of the device and featured accessibility from Compiled BASIC (which at the time was "it" for "High Level Languages" on the PC).
EHLLAPI adds the "Extended" to the HLLAPI API with a few additional synchronization and convenience functions. So, with just a few additions to the API a whole new acronym was introduced and today we treat both HLLAPI and EHLLAPI as one and the same, obsolete relics!
Over time, the term "HLLAPI" has been used for a variety of WinHllapi libraries from vendors such as IBM, WRQ, Attachmate, Rocket and Microfocus. Basically, any technique for interacting with a screen from languages like C, C++, VB, Javascript and Java can wrapper EHLLAPI functionality.
"Screenscraping" Has a Bad Name...Why?
EHLLAPI/WinHLLAPI is, unfortunately, not that "high level" in that each and every operation needs to be performed using low-level parameters that have little resemblance to high-level data types. In fact, the parameters used in EHLLAPI are closer to machine registers for a specialized emulation integration hardware than they are to anything like a true API. Compared to the high-level workflow capture tools, screen field modeling, web service encapsulation of work processes and advanced testing tools provided to our existing customers by Inventu Viewer+, EHLLAPI is stone-aged in comparison!
The use of EHLLAPI as a means of integration between the programs in the PC and the emulation sessions continued as the PC evolved, and multiple hardware/software developers introduced their own emulation solutions to the market. This was unfortunate for those needing to use the API, as the strict and limited parameter approach meant long and arduous coding, test and debugging cycles. In addition to the long development cycle, the obtuse nature of the API makes modifications very difficult. Due to the typical high change rate of screen-based applications this high maintenance cost added to developer frustration over the use of EHLLAPI in implementing screen integration projects.
Most organizations today have moved away from any screenscraping approach and instead are building micro and web services where needed on their host platforms. This avoids the maintenance "lock" that a screenscraping application can put on the host developers.