Search results for query: *

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

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. :-)

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?

Can one transaction be mapped to multiple programs in that table?

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...

Hmmmm. . .We compile using CList scripts, I'm going to need to talk to someone else I think.

Marc, Steve, That sounds like a viable option, now I've done some reading, the exit that we're looking at using gives us easy access to the transaction number (don't ask why that's hard, it's too painful). For like 90% of our programs, the transaction ID and the program name are identical...

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.

Best way to access that from within a CICS COBOL Program? I need to get, given a Transaction ID from the commarea, the name of the associated program. Jim

Does anyone know where CICS stores information about which programs are associated with which transactions?

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

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...

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...

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...

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...

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...