Getting access to CICS Current Screen Data from an external program 3

[jshankjr]

Interesting situation:
We have a CICS application. (heh)
What we need to do:
Press a Function Key that'll trap the system and run a cobol (or other) program external to CICS.
This program then needs to get access to various information about the current screen, I.E. which field is highlighted, which map is being displayed, etc.

The reason we're trying to do this is because we need to implement the function of this program globally in the program, but we're trying to avoid making changes to every program in a large application.

We know that this or something similar can be done because we're using another product which gets the information for its purposes, but it's a third party product so we don't know how it does it.

Anyone have any ideas?

Thanks,
Jim

 

[stevexff]

Most CICS applications are pseudo-conversational. What this means to you is that by the time the 3270 datastream hits your terminal emulator, the transaction has already ended. CICS then processes 500 or so other transactions during your think time before you press enter again.

It is possible to get the TIOA, scrape it, and work out which map and transaction to execute, but it requires a fairly deep knowledge of CICS and writing exit programs to do it. Mostly in assembler. Furthermore, when you say you want to execute a program outside of CICS, do you mean in a separate address space, or just a non-cics program running in the CICS address space? Certainly, there is no possibility for the function key press to be handled anywhere else except inside the CICS address space, regardless of what happens to it after that.

Not wishing to put you off, but this is not going to be something you can knock of in an afternoon...

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object:erlDesignPatterns)[/small]

 

[jshankjr]

Fortunately, I don't think knocking it off in an afternoon is a requirement .

It makes sense, of course, that the keypress will occur inside CICS, and I figure we need to make CICS calls to get the other work done, so calling it external to CICS is parobably dead wrong. It does, however, need to be external to the flow of the existing application. What we need to do is hit a key, figure out the screen and the highlighted field, access a database based on that data, and display a field/box containing text data from the database. All without actually changing the underlying application, or it's flow beyond the fact that it won't be doing anything else until we dismiss this little display.

Don't worry about putting me off. I'm fearless.

Thanks,
Jim

 

[MarcLodge]

Jim,

Is this a Windows based platform that uses a mainframe emulator to interface with CICS? If so, which flavour of Windows are you using (XP, Vista etc.) and which emulator (Attachmate, Reflections)?

If not Windows, what are you using?

Marc

 

[stevexff]

Marc

Good example of thinking outside the box (quite literally in this case ). A macro in the emulator might provide the capability you need without getting up to your elbows in exit programs...

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object:erlDesignPatterns)[/small]

 

[jshankjr]

To clarify our data needs a little bit, this program is meant to be a help facility, thus what we need is data like which screen we're on and what field is highlighted, not the value of the field. (Though that might be useful at some point.) So we're not necessarily looking at screen scraping for data or anything right now.

We are working through a terminal emulator but I don't think we can accomplish what we need through Macros on the Mocha W32 TN3270 terminal emulator. We need to access an SQL database.

 

[MarcLodge]

Hi Jim,
I'm still not 100% certain what it is you're after.....

You have a CICS program linked to a screen, and when the user, from within that screen presses F1 (for instance), you want to pop up another help type screen.

But (and this is the bit I'm confused about) you want to do this without changing the existing program?

Does the help screen that pops up take data from the CICS region e.g a DB2 table, or does it require it's data a source that is not available to CICS.

Sorry to ask so many questions.

Marc

 

[jshankjr]

The CICS program that we are trying to build is not linked to a screen.

The intention is to trap PF1 to run a utility program separate from the existing program, and without interfering with the existing program except that it won't be reciving any input until our new program is done doing what it does. 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 another data source, probably through a CICS web service since we're sharing this database with another application. 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.

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 do it then someone else must have seen how it accomplishes it's task.

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.

Thanks,
Jim

 

[MarcLodge]

Jim,
Do you wish to change the underlying existing CICS program in order to trap the PF! press?
Marc

 

[MarcLodge]

Jim
At the site I'm at we've a system similar to that which you describe except PF1 processing it has been inbuilt into each program. What they do is when PF1 is pressed, they call a program passing the DFHEIBLK, DFHCOMMAREA and populate a TSQ with other relevant data. The TSQ stores the cursor position and the calling program/screen name.

The called program then issues a CICS START to another tran which obtains the commarea and data from the TSQ. Using these it does a look up to a DB2 table to determine whether 'field' level help is available or whether help on the whole screen is available.

Using the termid passed, it overlays on top of the existing screen a much smaller map which contains the data and requires a PF3 to exit, which transfers control back to the original calling program.

I'm not sure if you can use this method as all of our programs have this processing in as standard but thought I'd share the info with you to see if it of any help.

Marc

 

[jshankjr]

As I said, we have already managed to trap the PF1 key without changing the underlying program.

Except for the part where we'd have to add the PF1 processing to every single program that accesses a screen, your example is exactly what we're looking for.

If we didn't have a third party product that didn't require those changes in order to work, we might already be coding just that, but our time constraints make it necessary to investigate as much as we can before we commit to such an effort. If we can create a single application that can work by spying on the application, then it will save us months over creating essentially the same program but it has the info handed to it by changes (albeit small ones) in several hundred programs.

Thanks,
Jim

 

[jshankjr]

If the screen name is displayed on the screen, is there a way to read that label from my program?

 

[stevexff]

How are you trapping the PF1? Mapping a new transaction to the PFKey, or with an exit?

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object:erlDesignPatterns)[/small]

 

[jshankjr]

We currently have both methods available. If we leave our third-party product in place, we may be leveraging it's capabilities to perform the task as an exit. If we go the other way, we'll be mapping a new transaction to PF1.

 

[jshankjr]

Okay, so a technical limitation is now going to make it difficult to impossible to keep the third-party product in place.

This means that we will probably need to be mapping a transaction to the F1 Key to run a separate program, but somehow we need access to the information from the previous transaction. Since we will be returning to the previous transaction after termination of the new transaction, is there a way to get access to the previous transaction's data? (Transaction ID, etc?). I know, pretty much what I've been asking.

 

[stevexff]

The XZCATT exit gives you access to the TIOA (for the data), the TCTTE (for the terminal) and the transaction ID. This may allow you to intercept the inbound data, determine which key was pressed, save the TIOA to TS, substitute your own transaction, and then when it finishes, re-invoke the original transaction with the TIOA you previously saved.

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object:erlDesignPatterns)[/small]

 

[jshankjr]

At the risk of sounding overly newbish (I am, if you haven't noticed. My background is in COBOL and I'm in the process of picking up CICS), where/how would this exit need to be invoked? Would this be in my PF1?

 

[jshankjr]

Is there a standard Assembler program stub out there somewhere that I could use to pass control out to a cobol program? I haven't done assembler since I was 18, which is a long time ago.

 

[jshankjr]

Which guide has informationon mapping transactions, etc. to keys anyway?

 

[stevexff]

[ol][li]Global user exits have to be enabled. You can do this from a COBOL program in the PLT (list of programs that gets run at CICS startup). See resource definition guide.[/li][li]Once enabled, the program(s) get invoked each time a VTAM request comes in, before CICS starts the transaction.[/li][li]You have access to the TIOA (terminal I/O area), the TCTTE (terminal control table terminal entry), and the transaction ID that CICS is about to start.[/li][li]Exits have to be in assembler (or possibly C, I think) but the LE/370 environment has not been initialised at that point, so no COBOL I'm afraid. So the assembler stub idea is a no-go.[/li][li]You can't do EXEC CICS calls, but there is a limited set of functions that you can do via the XPI (exit programming interface) from within your exit. All this used to be in the Customisation Guide, but at v4.1 they seem to have reorganised all the docs into an Information Centre online.[/li][li]If you want to map a transaction to a key, use the PCT, which is now done by the transaction definition under RDO[/li][/ol]Hope this helps...

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object:erlDesignPatterns)[/small]