In traditional COBOL, if a Menu program (or say "PROGA") CALLs a sub-program (or say "PROGB") and doesn't CANCEL it upon return, the next time it CALLs it, PROGB may have its variables in the state that they were in - left over from the earlier CALL, instead of being in their initial state (let's ignore the INITIAL key word for this discussion). My understanding is that most all the time this type of situation can result in hard-to-debug-and-maintain programs and that the general recommendation is to always follow a CALL with a CANCEL and design the subprograms accordingly (i.e., don't ever use this as a "feature").
OK, but what about Managed non-procedural programs (classes) using WinForms or WPF and such? These are not being CALLed; they are being INVOKEd, right? Is there an equivalent of a CANCEL that we should be doing after it returns to the INVOKEing program?