Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

ON CALL exception

Status
Not open for further replies.

rajesh082

Programmer
Dec 18, 2007
38
DK
Hi,

First of all, let me admit that its been a long time since I have written a plain COBOL call.
However I still do remember the syntax and everything, so when this happened it really puzzled me.

I have written a new COBOL Batch Module, lets say PROGA
PROGA is calling PROGB as follows:

Code:
Call PROGB using inPROGB outPROGB                 
   on exception                                         
   move 'Fejl - Call PROGB'     to logLocation        
   string 'Program ' PROGB ' not found'               
     delimited by size            into logDescription   
   end-string                                           
   perform errorExit                                    
end-call

The thing is PROGB has not even been written till now.
So I expected the program to fail here, but it went ahead without doing anything to the next statements.
What I fopun even stranger was that when I removed the On exception condition, The program did abend as expected saying that the module PROGB is not found.

Code:
Call PROGB using inPROGB outPROGB                 
end-call

What is that I am overlooking for the ON exception condition not getting executed?
 
Hi Rajesh,
I must admit I've never used the ON EXCEPTION statement as I've always passed return codes between programs and allowed the Operating System to sort out any errors where the program doesn't exist. To my mind, if somebody has gone to the trouble of including exception handling of this type in their operating system, then I might as well use it [smile]

But, your statement, as you've coded it on this forum looks ok to me. I would therefore check:[ul]
[li]Is your code in the program the same as you have coded here?[/li]
[li]When executed, does it definitely NOT pass through your error handling?[/li]
[/ul]

I would though give serious consideration to removing the ON EXCEPTION condition and letting the operating system do its job.

Marc
 
Hi Marc,

First of all, yes my code does handle the return codes as you suggested:

Code:
Call PROGB using inPROGB outPROGB                     
   on exception                                             
   move 'Fejl - Call PROGB'     to logLocation            
   string 'Program ' PROGB ' not found'                   
     delimited by size            into logDescription       
   end-string                                               
   perform errorExit                                        
end-call                                                    
                                                            
evaluate rtkd                     in outPROGB              
   when 0                                                   
      continue 
   when 4
      BLAH ... BLAH                                              
   when other                                               
      move 'Error Calling Program PROGB'                  
                                  to logDescription         
   perform errorExit                                        
end-evaluate

To answer your Questions:
• Is your code in the program the same as you have coded here?
YES :)
• When executed, does it definitely NOT pass through your error handling?
NO :(
The problem is right now I am not even bothered about the error handling at all.
My main concern is why PROGA doesn't fails. I find it very strange and confusing.

I find that the ON CALL EXCEPTION statement helps with relevant information when the Job fails, to populate the log with the relevant information.

 
When runniing this with the non-existent PROGB, what value is in "rtkd" in outPROGB?

"My main concern is why PROGA doesn't fails"
Possibly because the exception was handled?
 
Hi PAPADBA,

[ul]
[li]When runniing this with the non-existent PROGB, what value is in "rtkd" in outPROGB?[/li]
[/ul]I am not sure what you meant to ask here, how will the rtkd in outPROGB be set if the PROGB itself is not written. If you are trying to cross check that there is another Load in the library by name PROGB, I assure you there is not, because when I call PROGB without the exception clause PROGA does fail saying thatthere is no load for PROGA.

[ul]
[li]Possibly because the exception was handled?[/li]
[/ul]Again, if the exception was handled shouldnt it go to the next statement?


Code:
Call PROGB using inPROGB outPROGB                     
   on exception                                             
   [b]move 'Fejl - Call PROGB'     to logLocation[/b]               string 'Program ' PROGB ' not found'                   
     delimited by size            into logDescription       
   end-string                                               
   perform errorExit                                        
end-call
 
My bad - i meant to ask what is placed in outPROGB before the call? And after the call (regardless of whether it works or not (i realize it will to catch the "after" when it abends<g>). Just trying to see as much as we can see.

"Again, if the exception was handled shouldnt it go to the next statement?"
I don't know. I searched the biggest source repositories on these systems and did not find a single bit of code that specifies this.

Time permitting, i'll see if i can run a test over the weekend. If i don't post something by Sat afternoon, do post a reminder.


 
It sounds like what you are saying is that you expected the ON EXCEPTION clause to be executed but was not. But you are not clear about what evidence there is to show that the ON EXCEPTION clause statements were not executed. It sounds to me like they were executed, they simply did not do what you thought they would do. You say "I expected the program to fail here..." but why would the program fail unless there is something to be executed in paragraph errorExit that would cause a failure. Perhaps if you posted the contents of errorExit, it might be clearer.

Does paragraph errorExit terminate with a GOBACK, STOP RUN or EXIT PROGRAM statement? If not, then execution would simply continue with the statements following the CALL statement. If in fact you wish the program to truly ABEND, you would have to program something in paragraph errorExit to explicitly cause that to happen. After 12 years away from an IBM mainframe environment, I don't remember the name, but I do know there is a specific IBM subroutine call that can be invoked to explicitly force an abend. You would have to ask your systems people or you could try an internet search for it.

Code what you mean,
and mean what you code!
But by all means post your code!

Razalas
 
The exception hadling works as expected. The best is to try it on a simplest example:

Code:
       [COLOR=#804040][b]IDENTIFICATION[/b][/color][COLOR=#804040][b] DIVISION[/b][/color].              
       [COLOR=#804040][b]PROGRAM-ID[/b][/color]. CALLEDTEST.               
       [COLOR=#804040][b]ENVIRONMENT[/b][/color][COLOR=#804040][b] DIVISION[/b][/color].                 
       [COLOR=#804040][b]CONFIGURATION[/b][/color][COLOR=#804040][b] SECTION[/b][/color].                
       [COLOR=#804040][b]SOURCE-COMPUTER[/b][/color]. IBM-AS400.           
       [COLOR=#804040][b]OBJECT-COMPUTER[/b][/color]. IBM-AS400.           
       [COLOR=#804040][b]DATA[/b][/color][COLOR=#804040][b] DIVISION[/b][/color].                        
       [COLOR=#804040][b]WORKING-STORAGE[/b][/color][COLOR=#804040][b] SECTION[/b][/color].              
      [COLOR=#6a5acd]                                       [/color]
       [COLOR=#804040][b]PROCEDURE[/b][/color][COLOR=#804040][b] DIVISION[/b][/color].                   
       [COLOR=#804040][b]MAIN-PARA[/b][/color].                            
      [COLOR=#6a5acd]     [/color][COLOR=#804040][b]DISPLAY[/b][/color] [COLOR=#ff00ff]"HELLO FROM 'CALLEDTEST'."[/color]
      [COLOR=#6a5acd]     [/color][COLOR=#008080]GOBACK[/color]                            
      [COLOR=#6a5acd]     [/color].

Code:
       [COLOR=#804040][b]IDENTIFICATION[/b][/color][COLOR=#804040][b] DIVISION[/b][/color].           
       [COLOR=#804040][b]PROGRAM-ID[/b][/color]. CALLERTEST.            
       [COLOR=#804040][b]ENVIRONMENT[/b][/color][COLOR=#804040][b] DIVISION[/b][/color].              
       [COLOR=#804040][b]CONFIGURATION[/b][/color][COLOR=#804040][b] SECTION[/b][/color].             
       [COLOR=#804040][b]SOURCE-COMPUTER[/b][/color]. IBM-AS400.        
       [COLOR=#804040][b]OBJECT-COMPUTER[/b][/color]. IBM-AS400.        
       [COLOR=#804040][b]DATA[/b][/color][COLOR=#804040][b] DIVISION[/b][/color].                     
       [COLOR=#804040][b]WORKING-STORAGE[/b][/color][COLOR=#804040][b] SECTION[/b][/color].           
       [COLOR=#2e8b57][b]01 [/b][/color]CALLED-PGM  [COLOR=#804040][b]PIC[/b][/color] X([COLOR=#ff00ff]10[/color]).          
      [COLOR=#6a5acd]                                    [/color]
       [COLOR=#804040][b]PROCEDURE[/b][/color][COLOR=#804040][b] DIVISION[/b][/color].                
       [COLOR=#804040][b]MAIN-PARA[/b][/color].                         
      [COLOR=#6a5acd]     [/color][COLOR=#804040][b]MOVE[/b][/color] [COLOR=#ff00ff]"NOEXIST"[/color] [COLOR=#804040][b]TO[/b][/color] CALLED-PGM   
      [COLOR=#6a5acd]     [/color][COLOR=#008080]PERFORM[/color] CALL-PGM               
      [COLOR=#6a5acd]     [/color][COLOR=#804040][b]MOVE[/b][/color] [COLOR=#ff00ff]"CALLEDTEST"[/color] [COLOR=#804040][b]TO[/b][/color] CALLED-PGM
      [COLOR=#6a5acd]     [/color][COLOR=#008080]PERFORM[/color] CALL-PGM               
      [COLOR=#6a5acd]     [/color][COLOR=#008080]GOBACK[/color]                                             
      [COLOR=#6a5acd]     [/color].                                                  
      [COLOR=#6a5acd]                                                        [/color]
       [COLOR=#804040][b]CALL-PGM[/b][/color].                                              
      [COLOR=#6a5acd]     [/color][COLOR=#008080]CALL[/color] CALLED-PGM                                    
      [COLOR=#6a5acd]       [/color][COLOR=#804040][b]ON[/b][/color] [COLOR=#804040][b]EXCEPTION[/b][/color]                                     
      [COLOR=#6a5acd]          [/color][COLOR=#804040][b]DISPLAY[/b][/color] [COLOR=#ff00ff]"CALL OF '"[/color] CALLED-PGM [COLOR=#ff00ff]"' FAILED !"[/color]   
      [COLOR=#6a5acd]       [/color][COLOR=#804040][b]NOT[/b][/color] [COLOR=#804040][b]ON[/b][/color] [COLOR=#804040][b]EXCEPTION[/b][/color]                                 
      [COLOR=#6a5acd]          [/color][COLOR=#804040][b]DISPLAY[/b][/color] [COLOR=#ff00ff]"CALL OF '"[/color] CALLED-PGM [COLOR=#ff00ff]"' SUCCESSFUL."[/color]
      [COLOR=#6a5acd]     [/color][COLOR=#008080]END-CALL[/color]
      [COLOR=#6a5acd]     [/color].

Output:
Code:
> CALL CALLERTEST                  
  CALL OF 'NOEXIST   ' FAILED !    
  HELLO FROM 'CALLEDTEST'.         
  CALL OF 'CALLEDTEST' SUCCESSFUL.

After calling NOEXIST I see in joblog the message Cannot resolve to object NOEXIST. Type and Subtype X'0201' Authority X'0000', but - because the exception was handled - the program doesn't failed and it contines with next statements, which is calling of CALLEDTEST.

When I remove the exception handling from the caller, i.e. I change the source to
Code:
       CALL-PGM.                                              
           CALL CALLED-PGM                                    
      *      ON EXCEPTION                                     
      *         DISPLAY "CALL OF '" CALLED-PGM "' FAILED !"   
      *      NOT ON EXCEPTION                                 
      *         DISPLAY "CALL OF '" CALLED-PGM "' SUCCESSFUL."
           END-CALL                                           
           .
then - because the exception was unhandled - the execution of caller breaks on statement
Code:
    16     001400     CALL CALLED-PGM
with error Cannot resolve to object NOEXIST. Type and Subtype X'0201' Authority X'0000'. In this case next statements will not be ececuted, i.e. CALLEDTEST will never be called.
 
Your last post is really stating that the on exception is working as expected. Nothing wrong with it unless you expected something else to happen.

So if on this program the exception handling works, and it doesn't on your original sample then I would say the difference in behaviour is related to different compile/link options being used.

Regards

Frederico Fonseca
SysSoft Integrated Ltd

FAQ219-2884
FAQ181-2886
 
The OP didn't say what happens in the error errorExit paragraph, which is coded on exception
Code:
Call PROGB using inPROGB outPROGB                     
   on exception
     ...                                             
     [highlight]perform errorExit[/highlight]                                        
end-call
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top