Currently, having the "Tools > Options > Debugging > Micro Focus COBOL > Suspend at 'STOP RUN'" option set, the debugger visually appears to stop before the final line is being executed:

From above screenshot you can see that it looks like the CALL statement has not been executed yet. But actually, execution has already passed the final line in the code.

This current behaviour is very irritating.

Furthermore, I'm used to continue (by hitting <F5>) a successful program when it's halted instead of aborting it (by hitting <SHIFT> <F5>). So, it's cumbersome to alter that common behaviour just for the "Suspend On 'STOP RUN'" feature (see error message above).

So, I'd like to suggest four improvements regarding the "Suspend On 'STOP RUN'" feature:

1. When building a DEBUG build, have the COBOL linker add a terminating __debugbreak operation (or Debugger.Break method) to the generated code to have the debugger always stop there.
   
   By analyzing the program counter when that final opcode is reached you can easily identify this halt as the "Suspend On 'STOP RUN'" debugger break and either continue the program (when the option setting is disabled) or just have the debugger halt at that position (when the option setting is enabled).
   
   
   
2. Map the source code for above mentioned final __debugbreak/Debugger.Break operation beyond the final line in code or to the final, solitary dot in code, so the yellow program position pointer shall point to what is expected to be the end of the source code:

1.  
2.  
3. Make the "Suspend On 'STOP RUN'" setting available either in Solution Explorer or in the COBOL toolbar, as it tends to be rather a temporary setting than a permanent one.
   
   
4. The Micro Focus documentation states that the STOP statement is an obsolete element that's about to be purged from being supported in the future. So, I'd like to suggest that the option setting should be renamed to "Suspend when completing final statement".

Thanks for your suggestions. I agree that the inability to exit out of the program by pressing Resume or Step after the STOP RUN is a bit irritating. Currently the only way to exit is to stop debugging. 

In your case it stops on the CALL statement because that is the last executable statement in your program so the compiler inserts an implied STOP RUN after this statement but the debugger cannot be positioned to an implied statement. The END PROGRAM is not an executable statement nor is a period by itself.

Since the STOP RUN has already been executed at the time the break is encountered the program has actually terminated. Running the program further doesn't make sense as there are no further executable statements.

I will create a request to have the current behavior changed if it is possible.

BTW, it is only the STOP "literal" statement that has been obsoleted. STOP and STOP RUN are not obsolete.

Thanks