IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Cobol CALL ON EXCEPTION


IBM Mainframe Forums -> COBOL Programming
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
udaysnimje

New User


Joined: 12 Jun 2008
Posts: 12
Location: Pune

PostPosted: Fri Nov 14, 2008 7:27 pm
Reply with quote

Hi.
While calling a program from another In CICS we use LINK or XCTL. Everybody says COBOL CALL is equivalent to CICS LINK.
In CICS LINK we can check DFHRESP for various conditions eg.. Length err, PGMIDerror etc.
In COBOL call we can handle exception by coding ON EXCEPION.

My question ==> can we identify exact cause of exception. if its possible by using DFHEIBLK then how?
what should be declarations in Linkage of called program?

What should be syntax of EVALUATE or IF statement to know the various conditions?

Can we call a CICS program from another by simple COBOL CALL? What is Commarea length limit for COBOL call?

I want to pass 60k data in CICS link for that I need to use cannels and containers. Can it be done by simple COBOL call?

Please help me with answers or web links.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Fri Nov 14, 2008 7:51 pm
Reply with quote

First, you need to learn and use appropriate terminology. COMMAREA is a specific term used to refer to the memory passed between CICS programs via LINK, XCTL, START, and other CICS verbs. It has absolutely nothing to do with a COBOL CALL statement and it is not correct to say, as you did,
Quote:
What is Commarea length limit for COBOL call?
The answer to your question is that COMMAREA does not apply to COBOL call so the question is meaningless.

You cannot compare CICS DFHEIBLK to batch COBOL structures and expect them to correlate -- you're comparing apples to pomegranates. In a CICS program DFHEIBLK contains fields that can identify the precise problem if something goes wrong, but you must understand the codes generated and these codes don't necessarily apply to batch COBOL programs. For example, PGMIDERROR doesn't exist in batch because batch programs don't have a PCT of defined programs -- but you will get an S806 abend if the program you call cannot be found.

The CICS Application Programming Guide gives this about DFHCOMMAREA:
Quote:
The length of a COMMAREA on a RETURN command can vary from transaction to transaction, up to a theoretical upper limit of 32 763 bytes. (However to be safe, you should not exceed 24KB (1KB = 1024 bytes), as recommended in the Application Programming Reference manual, because of a number of factors that can reduce the limit from the theoretical maximum.)


Finally, if you look at the manuals link at the top of the page, you will find the COBOL Language Reference manual. This manual has an appendix which is entitled "Compiler Limits" and within that appendix you can find that a USING structure cannot exceed 32,767 bytes.

To summarize: you cannot pass 60K within CICS or via COBOL CALL statements. You'll have to find another way to do what you want.
Back to top
View user's profile Send private message
udaysnimje

New User


Joined: 12 Jun 2008
Posts: 12
Location: Pune

PostPosted: Fri Nov 14, 2008 8:24 pm
Reply with quote

Thank you Robert for prompt reply. I thought Commarea is communication area used to communicate between two programs. (any two)

Currently I am calling CICS program USING DFHEIBLK and PARM

In Program CICSP1
WS-COMM-CALL-AREA pic x(50) is defined in working storage

Procedure division:-

Code:
CALL CICSP2 USING DFHEIBLK
                             WS-COMM-CALL-AREA
ON EXCEPTION PERFORM ERROR-PARA
                              THRU ERROR-EXIT.

CICSP2

Code:
Linkage :-
01 DFHCOMMAREA.
   05 WS-PARM-MESS-INOUT    PIC X(50)

Please let me know if i want to find exact reason of CALL EXCEPTION what should be done?
Just like we check EIBRESP in CICS.

Both programs are defined in CICS region and PCT entries are present. Both program contains CICS commands So now can we get/identify PGMIDERROR kind of errors?

I have to use COBOL CALL and not CICS LINK then how exception handling should be?
Do I need to define separate 1 byte in Linkage of CICSP2 for DFHEIBLK ? before DFHCOMMAREA.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Fri Nov 14, 2008 8:44 pm
Reply with quote

From the Language Reference manual:
Quote:
6.2.4.6 ON EXCEPTION phrase


An exception condition occurs when the called subprogram cannot be made available. At that time, one of the following two actions will occur:

1. If the ON EXCEPTION phrase is specified, control is transferred to imperative-statement-1. Execution then continues according to the rules for each statement specified in imperative-statement-1. If a procedure branching or conditional statement that causes explicit transfer of control is executed, control is transferred in accordance with the rules for that statement; otherwise, upon completion of the execution of imperative-statement-1, control is transferred to the end of the CALL statement and the NOT ON EXCEPTION phrase, if specified, is ignored.
So basically from what I read it appears there is only one reason for this error -- the program CICSP2 cannot be found. I would link it into the CICS program to prevent this exception. Once I've done so, I would remove the ON EXCEPTION since there's no further reason for it.

Your CICSP2 program should have a LINKAGE SECTION of
Code:
01  DFHEIBLK.
01  DFHCOMMAREA.
     05  WS-PARM-MESS-INOUT PIC X(50).
since you (rightly) are passing EIB and commarea to the subroutine. Right offhand, I don't know if you need a full expansion for the EIB but I'd put one in just to be safe.

You are using COBOL CALL statement. PGMIDERR will not happen -- it only applies to EXEC CICS LINK, EXEC CICS XCTL, etc. A PCT entry for CICSP2 isn't required unless you've got EXEC CICS LINK or XCTL to it in other places.
Back to top
View user's profile Send private message
Guru Bob

New User


Joined: 31 Jan 2008
Posts: 21
Location: Malaysia

PostPosted: Wed Nov 19, 2008 1:44 pm
Reply with quote

If you are going to "pass" 60K between two programs you will have to write the data to a file and since you are usign "CALL" you cannot use CHANNELS and CONTAINERS I assume you are using CICS TS 3.2? The limit for TS queues and COMM area as robert points out is 32K.

The CALLED program in this case also cannot allocate any storage it must use only the LINKAGE section provided and working storage must not be modified.

You need to expand the EIBblock.

You program is missing from the loadlib.

the CALLED program cannot have a PPT entry as it is a non cics program.

I think you need to define "everybody" how big was your sampel of everybody - maybe I should come work in your CICS shop.

You cannot CALL another CICS program you must EXEC CICS LINK to it. Why bother with CICS if you want to "CALL" a cics program.

Coding "CALL"s wrong in cics will cause you no end of storage violations and 0C4 abends and untraceable until someone who knows cics sorts it out.
Back to top
View user's profile Send private message
udaysnimje

New User


Joined: 12 Jun 2008
Posts: 12
Location: Pune

PostPosted: Wed Nov 19, 2008 8:54 pm
Reply with quote

ya thats true.. I am facing all sort of difficulties using CALL in CICS..
Link is really cool.. ASRA on first line of called program.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> COBOL Programming

 


Similar Topics
Topic Forum Replies
No new posts Replace each space in cobol string wi... COBOL Programming 3
No new posts COBOL -Linkage Section-Case Sensitive COBOL Programming 1
No new posts COBOL ZOS Web Enablement Toolkit HTTP... COBOL Programming 0
No new posts Calling DFSORT from Cobol, using OUTF... DFSORT/ICETOOL 5
No new posts Generate random number from range of ... COBOL Programming 3
Search our Forums:

Back to Top