Re: 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. Interesting. The problem with
just manipulating your library list is this:
Let's say you have another program called XYZ123 in your support library
that says
BUBBA OBJECT(...)
And the vendor has a program with
BUBBA FILE(...)
And it gets even more interesting when you decide that vendor program
AAA111 would be enhanced if you called your program XYZ123. So you have
this jobd set up to put the vendor library first because it uses vendor
programs. But now it can't use your program AAA111 until you modify that
program.

Solution: Change your object in your support library. Sure, I hear your
wailing and gnashing of teeth, "but I use that object in dozens of
programs!!!". My reply "sucks to be you". Only because I feel your pain.
I've been there. I had a command called RUNSQL with some parameters. IBM
added one to their OS with different parameters. I had to modify buku
programs.

Now, if you're really good with exit programs you can add a command exit
point program that will check the command before it executes. If the
parameters are one way you can override to one library. If the parameters
are another, override to a different library. Quite Easily Done. I've
done this a few times. Once for whenever any program tried to run SNDDST
it ran my email command instead, remapping to the right parameters.


Rob Berendt