If you are updating from a version of the extend Interoperability Suite prior to version 10.2.1, you need to be aware of the following changes that may affect your existing applications:
In a multi-threaded environment, previous behavior was such that the Return-Code or Return-Unsigned special registers could be updated by any subprogram, from any thread in the run unit. This behavior could make it difficult when debugging multithreaded programs.
As of this version, the Return-Code and Return-Unsigned values are stored locally to each COBOL thread. Within COBOL, these 'local' special registers behave exactly the same as they did previously; and for non-COBOL programs, you can still reference the external return_code as defined in sub.h, and it will be echoed by the thread-local value in a thread-safe fashion. (For COBOL threads, if you create operating threads outside of COBOL, you are still responsible for your own thread safety.)
Although this change should not affect the large majority of programs, there is one (uncommon) scenario that may need to be worked around; consider:
CALL THREAD "SUB1" ... IF RETURN-CODE ...
With the new behavior, RETURN-CODE will not contain the return value for SUB1 (that will be contained within the SUB1 thread), and so you may experience unpredictable behavior with this type of construction. A work-around is to re-code as follows:
77 RCODE SIGNED-LONG. CALL THREAD "SUB1" GIVING RCODE IF RCODE …
This type of construction provides the same behavior as before, and is thread-safe. The local Return-Code for the SUB1 program is copied to RCODE, and can then be safely used in the calling program. The same principle also applies to the use of Return-Unsigned.
A previous change (ECN-2921) changed the behavior of the tree view control in character mode programs, to behave more like the Windows Tree-View control with respect to messages; this change became effective starting with objects compiled in extend version 7.0. The change had a side effect of a MSG-TV-SELCHANGE message being sent during the first MODIFY of the control as it was being fully initialized. This message was not sent to the Windows control, which is a behavior difference that could cause unexpected behavior in programs with certain message handlers for this message type. This release corrects that behavior.
If your programs rely on this previous behavior, then set configuration variable ECN_4585 to OFF to revert to the behavior described above; the default for this variable is ON.