Program hangs after 'exit program' statement

[clegg]

I've written a program in Netexpress 3.0 which calls a 3rd party API that brings back and address after being given a postcode.

Everything works fine in 'debug' mode, but when I run it as a release version something strange is happening. The program calls the API fine, but when it gets to the 'exit program' statement to return to the calling program it just hangs.

I've tried everything I can think of but haven't managed to solve it or find out where the program is going (or thinks its going!!).

Any help would be greatly appreciated.

Clegg

 

[MarcLodge]

Clegg,
Check that the linkage section and calling area between called and calling programs are identical. I've had this before where the calling chain gets corrupt.

Let us know how you get on

 

[clegg]

These areas are setup correctly - its one of the first things that I checked!

Clegg

 

[MarcLodge]

Clegg,
My experience may not be relevant but I'll tell it in the hope that it might be: I had a program that was on the mainframe in CICs and accessed DB2. I think that in the linkedit of the program, the TSO version of the DB2 interface (DSNHLI) had been accidently included instead of the CICs version(DSNCLI). When the program accessed DB2 it lost it's addressability under CICs and when the EXIT statemnet was hit, it just stopped.

Hope that this might help in some way, but I not holding my breath!

Marc

 

[k5tm]

Clegg,

This is sort of a generalized hint, but perhaps it pertains to your situation.

Perhaps your API is oriented toward C data types. The C string data type is zero-byte (x'00') terminated; COBOL strings are 'counted' and typically contain no zero bytes. It may be that the called program is bashing memory due to the fact that it is copying strings onto critical areas. When you are in debug mode, there is a lot of noncritical data generated that is used for the debug session. In debug mode, the same bashing may be happening but the bashed memory is noncritical. Or the debug information may inadvertantly be providing a zero-byte to terminate a string.

If you think this is possible, make sure that strings that are passed into the API are zero-byte terminated. You can accomplish this by putting a filler with VALUE LOW-VALUES after the data area holding (in this case) the postcode. Another way to do this is something like:

01  POSTCODE-PARAM    PIC X(50).
...
move LOW-VALUES to POSTCODE-PARAM.
string POST-CODE delimited by SPACES into POSTCODE-PARAM.
call "POSTCODEAPI" USING POSTCODE-PARAM.

(Note that LOW-VALUES usually provides zero bytes.)

Also, make sure that you allow enough space in the output parameters to accomodate the zero byte that might be after the "end" of the string.

Hope this helps. Tom Morrison

 

[gregsimpson]

Only thing I could think of was checking with the vendor of the package whether you should be going along the lines of CALL BY REFERENCE or CALL BY VALUE on your call to the API.

 

[gregsimpson]

Have you tried using a GOBACK?

 

[AndrewGregory]

I've had this very problem too.
For me, it was resolved when I realised a mistake I had made with Reference Modification. This is when you specify a substring of an alphanumeric variable eg WS-VAR(4:10) which means the string formed from the variable WS-VAR starting at position 4 and with a length of 10 bytes.
You can use this sort of thing as a sending and a receiving field, but it is the latter which is dangerous. I used to think that if you specified a length which was too long, cobol would automatically assume the end of the variable.
So I said MOVE WS-VAR1 TO WS-VAR2(WS-POINTER:999) thinking that this would overwite from WS-POINTER to the end of WS-VAR2. But it doesn't, it writes WS-VAR1 plus any additional spaces it needs to the memory occupied by WS-VAR2 from the pointer specified and for 999 bytes. Yes, it is overwriting memory beyond the extent of the variable.
To do what I had in mind, I now know you should use the construct MOVE WS-VAR1 TO WS-VAR2(WS-POINTER
For me this had the effect you describe. Sub-routine runs normally to completion, then hangs on the EXIT PROGRAM whilst the CPU is being thrashed.
Hope this helps you.