Test environments typically use concatenations of promotion (or shadow) libraries concatenated ahead of production (or baseline libraries). When an application in a test environment produces unexpected results, it is usually caused by old versions of a component still hanging around in one of the promotion (or shadow) libraries  in the concatenation list. That's where the ChangeMan ZMF helpdesk calls typically come in.

The typical approach to research such issue is as follows:

• Use the component's membername to perform a Q.C (query component), to check if ChangeMan ZMF is at least aware of any such component (if it has ever been migrated via ChangeMan ZMF). If so, continue the research for each of the relevant library types. Note: if you did create an initial ChangeMan ZMF history record before (e.g. at application boarding time), that will help you quite a lot in the research about the topic here!
• Identify the change packages that the component (member name with library type) has ever been included in, hopefully all packages relate to the same application (if not continue your research for each relevant application).
• Query the package(s) to lookup the DSNs of each promotion (or shadow) library into which the component may ever have been promoted to (for which a component history record exists).
• Search each of the promotion (or shadow) libraries for the specific component (by checking if the actual component is actually present in the specified DSN).
• Eventually, perform a similar search for each of the baseline or production libraries.

For a research similar like the one above, you often need at least between 5 and 30 minutes. There should be a way to simplify (and speed up) this research, or even better your ChangeMan ZMF users should be able to do such research themselves (without the need for a ChangeMan ZMF helpdesk intervention).

Consider the approach to address this issue as documented in the Z-Clues (login required).