Immediate return code = 255 when calling a module

Are you by any chance using the directive $set initcall"MFEXTMAP" in your subprogram?

This is one known cause of the 255 error to be returned because return-code is not intialized properly when MFEXTMAP is loaded in this manner.

Is the call statement working correctly. e.g. the called subprogram executes correctly and returns via goback or exit program?

It could be another call that is made from within the subprogram that is setting return-code to this value.

I would recommend that you try adding a native code watchpoint to the subprogram and then run it under control of the debugger.

Any time that the return-code value changes the debugger will stop and show you its value.

Because return-code is a special register and is not available directly in working-storage you will need to add a statement in the procedure division like:

    display return-code

Then right-click on the return-code variable and select Add COBOL Watchpoint.

Then run your application.

Everytime return-code changes the debugger will stop and display its value.

Thanks.

Hi Chris,

Yes, we were using the $set initcall"MFEXTMAP" directive in the sub-program.   Recompiling the module without that directive corrected the call to the module---IN MOST CASES.   There seems to have been an additional issue that the runtime system did not like.  The reason I stated above that changing the directive didn't seem to make any difference is we continued to get a 255 return-code when calling a module at the very end of the program...even without the $set initcall "MFEXPMAP" directive.

Here is a simplified description of what continued to happen and how I solved the issue (although I'm not sure why my change was needed):

Main ProgramA calls ProgramB which in turn calls ProgramC to connect to an Oracle database.   Processing returns back to ProgramA after the connection is successful (using goback through ProgramB).     ProgramA calls ProgramB multiple times during the main processing routine to get information from the same Oracle table that was opened by ProgramC.     At the end of program A, it calls ProgramC directly to disconnect from the database (remember we stepped through ProgramB to do the original connection).     We would get a 255 return-code immediately when calling ProgramC.     In order to prevent the 255 return-code I added a 'cancel ProgramC' statement right before I called ProgramC with the disconnect request--even though ProgramA had never directly called ProgramC up to this point.   I know ProgramB never issued a cancel statement for ProgramC (which was done intentionally by 1 of our developers so that a working storage field could hold a flag indicating whether there was current connection to the Oracle database).  One other thing I noticed is that ProgramB does a 'move zero to return-code' before issuing a goback command to the calling program.  So return-code will always be equal to zero after execution of that program.

I don't understand why a cancel statement would be required in program A.   Do you have any idea?

Thanks for your help and quick response!

Brian