Support library objects co-exist in 3rd party apps

For example, your third party app has a command called BUBBA. And their version of the command BUBBA has a parameter called FILE. While the version of BUBBA in your support library does not have a parameter called FILE, instead it has one called OBJECT

We normally put support libraries in our system library list.
We ran into an issue where 3rd party vendor object co-exists with support library object, which then caused the 3rd party app to fail.

If it is just commands that are conflicting, look at cleaning up the shared library and using CRTDUPOBJ to Copy commands from their original library. It is time to get a handle on your shared library.
Copy the command either from the 3rd party library - and from your own library.
Read up on Proxy Commands.

If there are other objects (pgm-objects) that are conflicting, then you are in a different area, and perhaps a "rename the pgm-object and wrapper to call qualified to library" methodology might be your solution.
Again, split the library. Follow that with analysis to see how much work "this XYZ" versus "that XYZ" will entail.

But since the problem just introduced itself to you, rather than jamming all objects into one library (where they must be uniquely named), you really should bite the bullet and split the libraries - - by function.
Develop liblist changers within the software to invoke before runtime. We change liblists in production jobs vs. set by *JOBD. And we found separation of duties really helps us control downtime and sw releases, and will move away from *JOBDs even more. When we started, it was rare we had "shared functions or conflicting names" on anything, and when we did and had to make changes, it was a lot easier than you would think = "scan replace recompile".

- John V