Re: Bundling CGIDEV2 - how much should be brought along?

Hi, Vern:

I have been following this thread with some interest.

The following discussion probably pertains mainly to ISVs who want to "bundle" CGIDEV2 into one or more of their own product(s), and may not apply to individual ("end user") companies who are using CGIDEV2 with their own "in house" applications.

Suppose an ISV "bundles" a copy of the CGIDEV2 tools with one or more of the ISV's products.What happens when the ISV sells (or licenses) one of these products to a customer who already has some version of CGIDEV2 tools installed on their system(s). How does the ISV prevent the possibility that their "bundled" version of CGIDEV2 tools does not "overlay" one or more parts of the customer's version of CGIDEV2(the *SRVPGM or any of those objects in Kevin's list,or any of the "template" stream files that are installed into IFS directories)?

ISVs might need to consider creating a (slightly) customized version of CGIDEV2 to "bundle" with their own applications. For example, an ISV could rename all of the objects in Kevin's list, and/or ensure they are installed in a different library, and ensure that any stream files needed or used are shipped and installed into different IFS directory paths. (Note that this may require some slight source code changes and recompiling of the CGIDEV2 objects.)

ISVs should ensure that, at run-time, when the product attempts to use CGIDEV2 services, they are really using the version that was shipped with that product, and not some other copy that the customer may have installed, either before or after installing the ISV's product(s).

If the ISV just uses the standard CGIDEV2 object names (e.g. CGISRVPGM2 *SRVPGM), what happens if the customer installs a different copy of CGIDEV2, and then decides to add those objects to some library higher in the library list than your product library, or they decide to add that library to the system portion of the library list?

Such ISV-related issues seem to warrant some further consideration.

Mark S. Waterbury