Receiving value in DFHCOMMAREA in CALL



Support for CICS/ESA, CICS/TS & Transaction Gateway, CICS Configuration Manager and CICS Performance Analyzer

Receiving value in DFHCOMMAREA in CALL

Postby Parry O » Tue May 31, 2011 1:10 pm

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
Parry O
 
Posts: 7
Joined: Wed May 18, 2011 1:00 pm
Has thanked: 0 time
Been thanked: 0 time

Re: Receiving value in DFHCOMMAREA in CALL

Postby Robert Sample » Tue May 31, 2011 4:10 pm

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.
Robert Sample
Global moderator
 
Posts: 3719
Joined: Sat Dec 19, 2009 8:32 pm
Location: Dubuque, Iowa, USA
Has thanked: 1 time
Been thanked: 279 times

Re: Receiving value in DFHCOMMAREA in CALL

Postby Parry O » Tue May 31, 2011 5:47 pm

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
 
Posts: 7
Joined: Wed May 18, 2011 1:00 pm
Has thanked: 0 time
Been thanked: 0 time

Re: Receiving value in DFHCOMMAREA in CALL

Postby BillyBoyo » Tue May 31, 2011 6:36 pm

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?
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 265 times

Re: Receiving value in DFHCOMMAREA in CALL

Postby mongan » Wed Jun 01, 2011 11:41 am

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)
User avatar
mongan
 
Posts: 211
Joined: Tue Jan 11, 2011 8:32 pm
Has thanked: 1 time
Been thanked: 5 times

Re: Receiving value in DFHCOMMAREA in CALL

Postby Parry O » Wed Jun 01, 2011 1:46 pm

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
Parry O
 
Posts: 7
Joined: Wed May 18, 2011 1:00 pm
Has thanked: 0 time
Been thanked: 0 time

Re: Receiving value in DFHCOMMAREA in CALL

Postby Parry O » Wed Jun 01, 2011 1:49 pm

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 O
 
Posts: 7
Joined: Wed May 18, 2011 1:00 pm
Has thanked: 0 time
Been thanked: 0 time

Re: Receiving value in DFHCOMMAREA in CALL

Postby mongan » Fri Jun 03, 2011 11:53 am

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?
User avatar
mongan
 
Posts: 211
Joined: Tue Jan 11, 2011 8:32 pm
Has thanked: 1 time
Been thanked: 5 times

Re: Receiving value in DFHCOMMAREA in CALL

Postby Parry O » Fri Jun 03, 2011 1:12 pm

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 O
 
Posts: 7
Joined: Wed May 18, 2011 1:00 pm
Has thanked: 0 time
Been thanked: 0 time

Re: Receiving value in DFHCOMMAREA in CALL

Postby BillyBoyo » Fri Jun 03, 2011 1:15 pm

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.
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 265 times

Next

Return to CICS

 


  • Related topics
    Replies
    Views
    Last post