View previous topic :: View next topic
|
Author |
Message |
sherlinpaul
New User
Joined: 28 Aug 2007 Posts: 3 Location: Chennai
|
|
|
|
We are invoking a transaction from Program A. That new transaction invokes program B. Is there a way to receive the map sent from program B in program A? |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
Normal CICS map processing logic:
1. initialize the map
2. send the map to the screen
3. return to CICS with transid
4. the program invoked by transid determines it needs to receive the map (usually but not always via DFHCOMMAREA data being passed), receives the map, and continues.
Since sending the map and receiving the map are distinct and separate logical operations, why would you think program A cannot do the receive of the map program B sent? |
|
Back to top |
|
|
sherlinpaul
New User
Joined: 28 Aug 2007 Posts: 3 Location: Chennai
|
|
|
|
Thanks Rob. Our requirement is bit different.
1. User will invoke program A with tran1.
2. Program A starts tran2 (i.e START TRAN tran2).
3. Tran2 invokes program B.
4. Program B sends map.
5. Program A should capture this map and make some changes.
6. Atlast Program A sends the altered map to the user. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
After B sends the map, what does it do? It should issue
Code: |
EXEC CICS RETURN TRANSID(tran1) |
so that program A will be started up again. Whether you use DFHCOMMAREA or TS queue or TWA or ... (there are many ways of passing data between programs), Program A can then receive the map, make the changes needed, send the altered map back out, and then do a return to TRANSID(tran1). This is pretty much normal CICS program logic other than one program sending the map and another receiving it -- but that's not that unusual, either. |
|
Back to top |
|
|
sherlinpaul
New User
Joined: 28 Aug 2007 Posts: 3 Location: Chennai
|
|
|
|
I belive, If we use 'EXEC CICS RETURN TRANSID(tran1)' then the user will see the map send from Program B. When he preses enter key. the control will come to Program A.
But we dont want the user to see the map sent from program B. He or She should see the altered map only. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
Terminology note: a map to CICS is a formatted set of data that is displayed upon the user's terminal. When you say
Quote: |
But we dont want the user to see the map sent from program B |
what you mean is that you do not want to use a map in program B -- because a map goes to the terminal for display. What you really want to do, it sounds like, is invoke program B to retrieve some data (from somewhere), and pass it -- via DFHCOMMAREA, TS queue, TWA, or whatever -- to program A to be modified and then a map sent at that point.
Again, pretty much simple, straightforward CICS coding that is done all over the world. Get data, send to another program, then display it on the terminal. |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
sherlinpaul wrote: |
Thanks Rob. Our requirement is bit different.
...
4. Program B sends map.
5. Program A should capture this map and make some changes.
...
|
herein lies the rub..
on the surface this seems simple- Program B Sends map
- EXEC RETURN is executed
- user sends map back to CICS
- Prgm A
- receives
- alters
- resends
- EXEC RETURN
But, i think sherlinpaul means something else
like A intercepting the send from B, modifying the map and then sending onto the user.
Have fun with this one, Robert. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
Quote: |
like A intercepting the send from B, modifying the map and then sending onto the user. |
If that's what is required, I'll say good luck and let us know if you get it to work. Intercepting a map send would require very in-depth knowledge of CICS as well as VTAM and while I won't say it is impossible, I will say it would be extremely difficult. If that is the desired process, REDESIGN THE PROCESS! |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
One thing I can think of is too START a separate pre-emptive task against the terminal-orientated task, which has issued a SEND MAP and issued a RETURN TRANSID(TRAN) COMMAREA (COMM-AREA) LENGTH(COMM-LEN).
When the pre-emptive task is started against the terminal, it issues a RECEIVE BUFFER (state is left unchanged), writing (for example) the terminal-buffer to a TSQ, followed by an INQUIRE (or addressing the TCTTE for earlier versions of CICS) to determine the "NEXTTRANSID" posted against this terminal, ending with a RETURN TRANSID("NEXTTRANSID") COMMAREA (DFHCOMMAREA) LENGTH(EIBCALEN). This is necessary to ensure that the next invocation of this transaction against this terminal goes undisturbed and will launch next time as if nothing had happened.
Basically, you're "Screen Stealing".
About 20 years ago, I wrote something similar to allow customer service to view the screen of a subordinate (updates were not allowed), naming the pre-emptive transid "ICU2" (Some IT humour here).
Just my .02 cents....
Bill |
|
Back to top |
|
|
Earl Haigh
Active User
Joined: 25 Jul 2006 Posts: 475
|
|
|
|
Quote: |
1. User will invoke program A with tran1.
2. Program A starts tran2 (i.e START TRAN tran2).
3. Tran2 invokes program B.
4. Program B sends map.
5. Program A should capture this map and make some changes.
6. Atlast Program A sends the altered map to the user. |
How do you expect this logic to ever work if all programs are
running at the same terminal?
If ProgramA starts tran2, then programB won't run until ProgramA
has ended.
I suppose you could:
(1) ProgramA start Tran2 and then return cics
(2)ProgramB sends map
ProgramB starts Tran1 and returns cics
(3)ProgramA receives the map sent by ProgramB |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
Earl, you're thinking the way I was before the o/p made the statement
Quote: |
But we dont want the user to see the map sent from program B. He or She should see the altered map only. |
They don't want the terminal user to see the map sent by program B -- only the map after it was modified by program A. You might be able to pull the map out of the VTAM buffers somehow, modify it, and put it back in there -- but it would take more smarts than I have to code up such an approach! |
|
Back to top |
|
|
Earl Haigh
Active User
Joined: 25 Jul 2006 Posts: 475
|
|
|
|
[/quote]They don't want the terminal user to see the map sent by program B -- only the map after it was modified by program A. You might be able to pull the map out of the VTAM buffers somehow, modify it, and put it back in there
Quote: |
Robert.
Your right it'll take some customized code to do what they are asking.
if they REALLY need to this , I could do it , but not for free. |
|
|
Back to top |
|
|
|