Pseudo-conversational mode in a XCTL target program

Bartolomeo Vaieretti · New User Joined: 09 Mar 2011 Posts: 6 Location: Germany

Transaction TRN1 has associated program PROG1 (pseudo-conversational). Under certain condition, PROG1 transfer control (XCTL) to PROG2, which should have his own pseudo-conversation with the terminal. When PROG2 send the map and execute a RETURN TRANSID('TRN1'), after receiving the control from the terminal, which program will be initiated?

Tnx for your time

dbzTHEdinosauer · Posted: Thu Mar 10, 2011 8:41 pm

TRN1 is associated with PROG1
what tran is associated with PROG2?

Ronald Burr · Posted: Thu Mar 10, 2011 8:46 pm

There is a complete description of what happens when you issue a 'RETURN TRANSID(name)' in the CICS Application Programming Reference Manual.
How do YOU interpret what it says?
Is the explanation in the manual confusing?
Have you even looked at the manual?

Anuj Dhawan · Posted: Fri Mar 11, 2011 2:43 pm

Nice Avatar Ronald - Dinosaur still rules, even in Ice-age!

Bartolomeo Vaieretti · New User Joined: 09 Mar 2011 Posts: 6 Location: Germany

@ dbzTHEdinosauer:
In my case, there is no second transaction associated with PROG2, because my idea was to use XCTL. But maybe I should transfer the control in another way, creating the second transaction TRN2 associated to PROG2 and then doing a START. By now, I solved temporary my problem including the logic of PROG2 into PROG1, and flagging in the COMMAREA which map and program is active.
I wanted to solve the case splitting both pseudo-conversations in two programs (and two transactions maybe) to understand better how this would work, because I'm sure I'll have in the near future cases where I'll need to split the logic yes or yes. So, my current problem is solved, but I still want to learn the alternative.

Robert Sample · Posted: Mon Mar 21, 2011 8:32 pm

If you want to do EXEC CICS RETURN TRANSID from PROG2, and have it return to PROG2, there must be a transaction name associated with PROG2. Otherwise, the only way you can get back to PROG2 is to set a flag in DFHCOMMAREA that PROG1 checks and immediately does an XCTL to PROG2.

Copying the logic from program to program is a really bad idea -- because sooner or later the logic will require a change. Unless there's very clear documentation that BOTH programs must be changed, one will get changed and the other won't -- although you could use a copybook to help (but still you'd have to know to recompile both programs when the copybook changed).

Bartolomeo Vaieretti · New User Joined: 09 Mar 2011 Posts: 6 Location: Germany

@ Ronald Burr (and others):
I'm agree with Anuj, nice avatar.
Well, I was reading the CICS Application Programming Reference Manual before to write the original question, and now again, before to write this time.
The RETURN description is complete as reference, but nothing in this description clear what I was asking about (the target transaction is clear, I minded if the target program would change because my last program was PROG2 and not PROG1, but I think it's not like this).
Maybe my question was not clear. Anyway, the description is clear: If I write RETURN TRANSID(TRN1) then the transaction TRN1 will be started (with the exception of the terminal's permanent transaction, but it's not my case).
I think my understanding problem is more about XCTL and not about RETURN TRANSID().

In the main transaction (TRN1), main program (PROG1), the main logic is "pseudo-conversing" with the terminal operator.

Now the thing itself: At certain point, the operator press any key (for any specific action) and I need to jump to a second pseudo-conversational logic, in an small window (leaving the rest of the last full screen in the background), where the operator needs to enter and confirm some data. And after finished this secondary logic, I should return to the main one. This secondary logic is the one I wanted to split to PROG2, not only to have two simpler separated logics instead one more complex like now, also to be able in the future to call the secondary logic from any other main program which needs the same extra data and confirmation.

Right now, I solved the case including all (both logics) in PROG1 (associated with TRN1). And it's working perfectly. But I'd still like to separate both processes.

I think my solution pass by using START instead XCTL. But I'm minding in which pseudo-conversational cases could XCTL be used.

Anyway, thanks for your time. As soon I finish the set of transactions my boss asked me for, I'll return to the case to try with START.