The green screen days aren’t completely gone yet! If you are working in integration projects, there will be a couple of times when you bump into those ugly green screens that want to hide everything that they have into a closed box called the mainframe. Most of the times, these mainframe apps just wont go because they are very crucial to the business. But the entire org moves over to the Microsoft platform. So what do you do? The simplest way is of course – use emulators 🙂 There are a lot of emulators in the market that you can use like the Zephyr Passport or the Attachmate Extra or the BlueZone emulator by Seagull Software.
Much of these 3270 apps were designed the archaic way and have no real connection to the word “UI”. But still they stand there and we got to figure out some ways to ease the pains of using them. That’s where we think of automating them from our own applications.
Somewhere in the medieval age, between ours and the archaic green screen age, when the green screens were being accessed from the PCs using the DOS based TSRs, somebody came up with a API interface that can be used to access and control these 3270 sessions. Personally, I don’t think anybody has touched these APIs to make them better after that. These are being called the EHLLAPI (right from the medieval age) – the Extended High Level Language API.
Now when you are dealing with integrating the functionality at the presentation layer – which is what you would be doing most of the times with CCF, the EHLLAPIs come real handy. Most of the emulators out there in the market support EHLLAPI as a standard way of interacting. In effect, you can get one EHLLAPI program that can work with all the emulators that support EHLLAPI. The EHLLAPI will allow you to interact with the emulator screen exactly as if you have a user interacting with it. If it can be best understood with a scenario, here goes a simple one. You have a mainframe app that requires you to provide your username and password in order to use it. Simple isn’t it? In a default case, the user would always need to go to the emulator screen and type in his credentials and hit the “Return” key. That’s definitely a very repetitive task and you would love it if the system just knows who you are and logs you in. Right? Combining the stuff, we can use the SSO to map the users windows credentials to his mainframe login and then use the EHLLAPI with the emulator to automate the login procedure after fetching the credentials from the SSO.
The EHLLAPI provides just one method to interact with it. That’s the hllapi(). The function takes certain parameters that determine what actions are to be performed. The actions to be performed are determined by an integer number. For example its 40 to set the cursor position and 3 to send a keyboard key to the emulator. (I told you guys, I don’t think this has been updated ever since the medieval age 🙂 ). Along with every function goes the data that the API can use for performing the action. Like for example, to set a cursor position, you need to know what the position is. Or to set the text, you need to know what text to set. This information goes in the data field.
To access the EHLLAPI, the emulator would usually come with a DLL that would encapsulate the EHLLAPI code. In my case, I worked with the BlueZone Emulator by Seagull Software and they ship a DLL named – PCSHLL.dll. This can be referenced using a DllImport statement and that’s it. Your C# code will be able to interact with the emulator. Here is an example of how it will go –
public static extern UInt32 hllapi(out UInt32 Func, StringBuilder Data, out UInt32 Length, out UInt32 RetC);
Hope this alleviates a bit of pain for all you guys who are looking at a way of getting these green screens to do some productive work on Windows.