IBM Mainframe Forum

Hello I have following query

If I am CALLing a CICS prog PROGB from CICS prog PROGA. In the PROGA I code as below:
CALL WS-PROGB USING DFHEIBLK
DFHCOMMAREA
WS-VARIABLE

And in PROGB I code as below:
LINKAGE SECTION
01 WS-VARIABLE PIC X(80)

PROCEDURE DIVISION USING WS-VARIABLE

and I get the contents of WS-VARIABLE from PROGA to PROGB

If I do not want to use WS-VARIABLE in PROGB and want the contents of WS-VARIABLE from PROGA in DFHCOMMAREA of PROGB, can I use following ?

In PROGA
CALL WS-PROGB USING DFHEIBLK
WS-VARIABLE

In PROGB
LINKAGE SECTION
01 DFHCOMMAREA PIC X(80)

PROCEDURE DIVISION (*No USING here)

Kindly advise if latter is right way of coding. Though I ve seen it works.

Regds Parry

Does PROGB have CICS commands in it? If not, why bother with DFHEIBLK and DFHCOMMAREA in your CALL? If it does, why not use EXEC CICS LINK instead of CALL? Using EXEC CICS LINK means the linkage is correctly set up.

What you are doing might work -- but the next release of CICS might change something to make it not work. CICS programs have DFHEIBLK and DFHCOMMAREA, period. If you don't want both of them in your code, don't make PROGB a CICS program -- or use EXEC CICS LINK instead. Otherwise, sooner or later your approach will backfire and production programs will start abending due to your (mis)coding technique.

Thanks Robert for your response

PROGB is a CICS prog. I think following use of CALL for CICS prog is perfectly Ok and is more efficient than LINK in certain circumstances. Ex. if the prog is called multiple times from PROGA.
CALL WS-PROGB USING DFHEIBLK
DFHCOMMAREA
WS-VARIABLE

However I was suspecting following CALL might be bad coding practice, though it works
CALL WS-PROGB USING DFHEIBLK
WS-VARIABLE

The CICS translator will insert dfheiblk and dfhcommarea in PROGB neways.

regards

Parry O wrote:Thanks Robert for your response

PROGB is a CICS prog. I think following use of CALL for CICS prog is perfectly Ok and is more efficient than LINK in certain circumstances. Ex. if the prog is called multiple times from PROGA.
CALL WS-PROGB USING DFHEIBLK
DFHCOMMAREA
WS-VARIABLE

However I was suspecting following CALL might be bad coding practice, though it works
CALL WS-PROGB USING DFHEIBLK
WS-VARIABLE

The CICS translator will insert dfheiblk and dfhcommarea in PROGB neways.

regards

Robert asked if it had any CICS commands in it. Does it?

Why do you think CALL more efficient than LINK?

Definitely the 2nd call is bad practice. Someone maintaining the program will see it, and wonder what is going on. Maybe they'll fix it.

I don't understand

If I do not want to use WS-VARIABLE in PROGB and want the contents of WS-VARIABLE from PROGA in DFHCOMMAREA of PROGB

What do you mean? Why wouldn't you "want" to use WS-VARIABLE?

It appears that you do not know much about CICS programming. What concerns me is your DFHCOMMAREA. I have the impression that you assume that you have a DFHCOMMAREA. You only have a DFHCOMMAREA if you DEFINE one somewhere in your transaction logic! A DFHCOMMAREA does NOT just exist. It has to be created from the working storage and then it can be passed to the next program. When a transaction is first started there is NO DFHCOMMAREA at all, the EIBCALEN is 0, and you can pass a area to the next programm something like this:
EXEC CICS RETURN
TRANSID(EIBTRNID)
COMMAREA(WSCOMBER)
LENGTH(190)

BillyBoyo wrote:Robert asked if it had any CICS commands in it. Does it?

Yes it has CICS commands in it.

BillyBoyo wrote:Why do you think CALL more efficient than LINK?

It may be under some circumstances. 2 that I can think of are:
1. If a prog is called multiple number of times at the same logical level the WORKING STORAGE remains in its last-used state . It is not freed and initialized again and again as in case of LINK

2. CALL can pass more than 32K bytes of data unlike LINK(as it uses only dfhcommarea) and CALL can pass multiple parameters unlike LINK.

However I think we are digressing here; besides I dont think i can change the call to link coz it is an existing prog in production i dont want to change. I am just analysing it.

BillyBoyo wrote:Definitely the 2nd call is bad practice. Someone maintaining the program will see it, and wonder what is going on. Maybe they'll fix it.

I don't understand

If I do not want to use WS-VARIABLE in PROGB and want the contents of WS-VARIABLE from PROGA in DFHCOMMAREA of PROGB


What do you mean? Why wouldn't you "want" to use WS-VARIABLE?

Actually this 2nd call is coded in an existing prog in production and I was suspecting its a bad coding practise and posted in this respected forum to confirm. Its not that I do not "want" to use WS-VARIABLE. I just wrote to explain. Apologise for any confusion i may have caused. I did not code this 2nd CALL

However I got wat i was looking for from this post i.e. "2nd Call is bad coding practise and shud be corrected"

cheers

mongan wrote:It appears that you do not know much about CICS programming. What concerns me is your DFHCOMMAREA. I have the impression that you assume that you have a DFHCOMMAREA. You only have a DFHCOMMAREA if you DEFINE one somewhere in your transaction logic! A DFHCOMMAREA does NOT just exist. It has to be created from the working storage and then it can be passed to the next program. When a transaction is first started there is NO DFHCOMMAREA at all, the EIBCALEN is 0, and you can pass a area to the next programm something like this:
EXEC CICS RETURN
TRANSID(EIBTRNID)
COMMAREA(WSCOMBER)
LENGTH(190)

It appears that you do not know much about CICS programming AND Common sense.

Common sense because I gave snippets of the code just to explain. I am not writing the whole code here. Therefore you shud not expect me to write LINKAGE section where I DEFINE DFHCOMMAREA in PROGA and logic to populate it. Besides I am concerned on passing WS-VARIABLE from PROGA to PROGB not DFHCOMMAREA(though it does get passed in 1st CALL and not in 2nd CALL tht i posted), if u understand COBOL i.e.

CICS programming because if I want to pass DFHCOMMAREA from PROGA to PROGB i will use either, LINK , XCTL, or CALL. We use RETURN with COMMAREA option only if we want to give control to operator and wait for him to press AID key. Why do u want me to use RETURN?

I do not usually wanna write such harsh response but your arrogance (with lack of knowledge) made me do it.

Parry, I find your response to be totally inappropriate. If you notice, I said I assume, appears, impression - because I did not have enough information to be sure. As to the CICS return, that is just an example of how a new Commarea can be defined. As to why, use of the Commarea is a CRITICAL problem with many CICS programmers and I wanted to make sure that it is being used correctly, which you have not confirmed yet and I am still suspicious. How do you CREATE your Commarea?

Mongan, your assumption/impression was wrong in this case. I understand the usage of commarea tht u r trying to explain. In my specific case DFHCOMMAREA in PROGA is populated by java front end (However this is not wat my query was)
Lesson: Don't pass judgement if u r unsure. I hope u ll agree.

Parry, everything in your first post was "first person". We had no way to guess that the code was not yours, it was something "working" etc.

The current commarea received by progb (we'll assume now that that is not its real name) is just a piece of working storage from proga. If progb is doing any cics commands which requires the commarea to be "handed off" then you can definitely expect problems.

OK, we know now, not your code, but we are just trying to help. If you had said "I came across this code that looks like garbage but seems to work" it might have avoided some of the senseless toing-and-froing. If you answer about the CICS commands question, instead of saying "it's CICS" (which can mean as little as "it has been through the pre-compiler") things might have gone better.