EHLLAPI programs externally interact with emulator sessions. That is to say, the EHLLAPI program actually types data into the presentation space, just as the keyboard does. You can literally watch the data being entered in the emulator session if the window is visible while the program executes.
Because automation involves potentially sensitive data (for example, a password), two security concerns generally arise in EHLLAPI programming discussions. The concerns involve the specification and storage of this sensitive data.
Many users hard-code passwords in their EHLLAPI sign-on programs. Conventional wisdom suggests this is bad practice, but if only one user is executing the automation program and the PC is adequately protected (for example, power-on password, activated lock screen) the exposure is minimal, and perhaps the concerns are overstated.
However, if the integrity of a program or workstation cannot be assured, or the program needs to be shared by multiple users, there are some techniques to explore.
One technique is to parameterize the automation program, passing data in as arguments, perhaps even prompting a user for data. This way, sensitive data does not need to be maintained in the program itself. Parameterizing has the added benefit that multiple users can use the same programs with no modifications.
To keep observable screen activity to a minimum and prying eyes at bay, an EHLLAPI program can routinely minimize the emulator session while performing data entry or screen parsing activity. After the sensitive screen data has been cleared, the program maximizes the screen before exiting the program.
Security precautions are as appropriate in REXX EHLLAPI as they are in AS/400 applications. Where conflicts between convenience and security emerge, common sense should dictate a course of action.
LATEST COMMENTS
MC Press Online