IBM Mainframe Forum

[DieZ]

Hi,
I am back to CICS after a few years' detour to J2EE. This topic has been covered so many times and yet I haven't got around it. Maybe, I am too bone-headed and if you refrain from answering, I will understand. So, here goes.

CICS ensures that the application program would respond only when a AID key is pressed. Typically, the time in which the program would process the input - even allowing for disk I/O - would be far lesser than the wet-ware spends time before the terminal. Hence, the idea of 'pseudo-conversation'. So, why does this venerable Redbook mention WAIT in this diagram ? As a matter of fact, why does it even mention 'conversational' ?

Here is the other confusion I have.

When SEND MAP is done, isn't control back to the map and the program is no longer "running" ? If so, how come the RETURN command gets the control immediately after SEND MAP (refer this diagram) ?

I am referring to Chapter 11.4 in the Redbook.

[Robert Sample]

The diagram is explaining conversational mode -- which is not recommended but is still possible in CICS. In fact, if you use APPC, the APPC verbs are conversational by their very nature.

Use CEDF to go through a program. You will find that after the SEND MAP is complete, control returns to your program -- all the SEND MAP does is display data on the terminal. And unless the first four characters of the map are the next transaction to execute, you need a RETURN TRANSID to tell CICS how to handle the map when an attention key is pressed.

[DieZ]

Thanks, Robert.

Use CEDF to go through a program. You will find that after the SEND MAP is complete, control returns to your program -- all the SEND MAP does is display data on the terminal.

If the control returns back to the program, does the program run until it encounters a RECEIVE MAP (waiting for a AID key to be pressed) or a GOBACK (in COBOL) ? And so, in the interim, are all 'business logic' code (update master file, insert database record for customer, etc.), executed regardless of what happens on the screen ?

And unless the first four characters of the map are the next transaction to execute, you need a RETURN TRANSID to tell CICS how to handle the map when an attention key is pressed.

I think, you are referring to Step 7 here ?

Suppose, the RETURN TRANSID command pointed to the same transaction that invoked the 'current' program in first place. That is, if V000 TRANSID (pointing to PROGV000) did a RETURN TRANSID(V000), it would have shown behavior of pseudo-conversational but still 'look' conversational to the operator. Am I correct ?

[DieZ]

BTW, on our development system, the SysProg has disabled access to CEDA/CEDB so, I am unable to add or install programs/mapsets, etc. I do want to be able to test my theories than shooting off questions in fora like these.

[dick scherrer]

Hello,

I am unable to add or install programs/mapsets, etc. I do want to be able to test my theories than shooting off questions in fora like these

Many systems have this restricted.

Possibly you can work with the SysProg and have a couple of test transactions, programs, and maps defined that would be only for your use. . .

[Robert Sample]

If the control returns back to the program, does the program run until it encounters a RECEIVE MAP (waiting for a AID key to be pressed) or a GOBACK (in COBOL) ? And so, in the interim, are all 'business logic' code (update master file, insert database record for customer, etc.), executed regardless of what happens on the screen ?

If this is the way you coded your program, then yes the business logic code would be executed without using the screen input. This is not a recommended way to do CICS code, but there's nothing to prevent you from doing so.

Suppose, the RETURN TRANSID command pointed to the same transaction that invoked the 'current' program in first place. That is, if V000 TRANSID (pointing to PROGV000) did a RETURN TRANSID(V000), it would have shown behavior of pseudo-conversational but still 'look' conversational to the operator. Am I correct ?

This is normally how CICS programs are coded -- this is nothing unusual or different.

Typically, a CICS program starts up and checks EIBCALEN. If the commarea length is zero, send the initial map and do a return to the same transaction with a commarea to indicate you are not starting fresh. When the data is entered on the map and an attention key (PA, PF, ENTER, etc) is hit, the transaction is restarted, determines from the commarea which map to receive, and goes from there.

[DieZ]

Robert,
Many, many thanks for helping me understand !