MVSFORUMS.com

[Jshank]

My group has an interesting task to perform:

The intention is to map PF1 to run a utility program separate from the main application, and without interfering with the existing program. We think we have this figured out since we are currently able to trigger execution without any activity in debug for the underlying program.

This new program then has to, somehow, figure out which screen the underlying program is on, hopefully what field is highlighted, since that's a phase II thing.

Using this data, our new program will reach out to a database. To get help data for the screen (or the field in phase II).

Then the program will get the data back and display it in a map overlaying the underlying application until the user dismisses it with another keypress.

The Challenge we face, as stated in the second paragraph, is to figure out what screen we are on, for database lookup by screen name, and field name or ID for similar lookup. The Screen name is displayed on the screen.

Thoughts:
Is there a memory area that contains names of maps, screen ids, field ids, that this program can gain access to that would be present because CICS just displayed the screen? (Perhaps by termId). Anything that we can tie directly to a screen can serve us as we can create a DB table to translate it to the screen name or ID we need. (for example)

Is there a way to read a label or section of the screen from an independent CICS program (again, perhaps by termId).

Is the EIB* data from the previous transaction available to this program?

We have a program in place that performs this type of activity, but it is a third party program and we have no insight into how it accomplishes it.

The thought behind the forum post was that if this program can get this data, then someone else must have seen something similar.

We understand that it would be somewhat trivial to accomplish this task directly, except that this would require us to implement the change for every screen and program in the entire CICS implementation, which is quite large, making it a non-trivial and much riskier task, so instead we are attempting to emulate the behavior of this other program, which does it's work without requiring changes to the underlying code.

Any thoughts?

Thanks,
Jim
_________________
Thanks,
James Shank