jayjacktx Absent Member.
Absent Member.

screen scraping IBM IMS TM screens

Hi everyone , maybe a basic question here.

we work with IMS TM , that does not still in "system" ( clock / wait in status bar ) after a enter .
it means to wait for the terminal response I can not go after " wait for cursor " or "keyboard lock" .

does anyone have build macros to handle this kind of terminal behavior ?

thanks for any information
1 Reply
TomFitz Absent Member.
Absent Member.

Re: screen scraping IBM IMS TM screens

Hi jayjacktx,

so you don't have any x-clock or similar locking of the terminal between sending an instruction and receiving the response, this can be tricky to deal with programmatically.

I would split this into two problems.
1. How do I know when the host has responded fully.
2. How can I read that response from the terminal display.

For 1: Normally one would simple wait a predefined amount of time before assuming the host has responded, or else would wait for a predetermined quiet time.

How to decide which would depend on whether the host is sending unsolicited messages to the terminal. If the host only responds to your command and there is not a continuous stream of messages being receive, then a quiet time should work well. If the host is sending a stream of messages, then using a fixed wait time might be a better option, it may be possible to handle both above using just IbmScreen.WaitHostSettle

For 2: This depends on how the response is displayed in the terminal.

Is the response displayed below the instruction, much like a DOS command and response would work.
Does the screen have a send command area and a separate display host messages area? If yes, does the host always send to response to the same display row, or does it display the messages to the top of messages area and work it's way to the bottom of the area as new messages are received? What happens when the messages reach the bottom of this area.

Once you have figured out both of the above, then you can think about implementing this.

Usually I would remap any key which you use to send an instruction to the host, so <Transmit>/<Enter> etc.
I would map the key to execute a macro which would maybe read the current display, then send the instruction to the host i.e. <Transmit>/<Enter> or whatever is usually mapped to that key, then wait for the response and again read the screen. Then extract the response using the before and after display contents.

I appreciate the above is very vague, but without knowing how the responses are appearing on screen it's impossible to be more specific. it may be possible to handle 1 above using just IbmScreen.WaitHostSettle

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.