I certainly don't know how "everyone else" does this, but here's what we do:

For non-z/OS-root products, I help the installer modify the xxxMKDIR and 
xxxISMKD programs, such that the product will SMP/E install into a separate 
and distinct HFS.

Lets say a product wants to have a DDDEF PATH similar to the following:

'/usr/lpp/db2810_msys/IBM/'

I have the SMP/E installer use the following path in the DDDEF:
/u/userid/db2smpe/db2810_msys/IBM/

In this case, /u/userid is the home directory for the user, and db2smpe is 
a director within the user's home HFS.  Then, on the db2smpe mount point, 
we mount a HFS data set associated with the product.

We run the xxxMKDIR/xxISMKD rexx programs - appropriately modified - and 
proceed with product installation.  The aforementioned HFS mounted 
at /u/userid/db2smpe is then treated just like any other target zone data 
set, and is cloned along with the rest of the target zone data sets to 
deploy the software from environment to environment.

Then, in my z/OS root HFS (I'm simplistic and am not using shared HFS), I 
create a directory in /usr/lpp/ for the product.  In this case, it 
was /usr/lpp/db2/.  We mount the cloned target HFS at 
mountpoint /usr/lpp/db2 and the product gets the "default" and "expected" 
path to the executable HFS code/files.

Finally, I update BPXPRMxx to automatically mount the desired product HFS 
data sets at their respective mount points.  For product rollout, the 
product clone procedure includes steps to unmount and mount the old/new HFS 
file systems, just as they have always deleted / redefined target zone 
executable data sets.

I have never investigated whether a unix symbolic link could also be used 
to assist or replace the above process.  As a unix neophyte, I really 
didn't know how to do that.

Brian

On Thu, 3 Aug 2006 12:42:51 -0500, Patrick O'Keefe 
<[EMAIL PROTECTED]> wrote:

>IBM program products apparently have packaging rules for Unix libraries
>stating that the path to these libraries will be /usr/lpp/<product_name>/.
>How do shops handle this when they install program products (like
>PrintServe, DB2, NetView, etc.) in other than their main MVS SMP zones.
>In particular, how do shops handle maintenance or new releases when both
>old and new copies of the products needs to be executed simultaneously?
>
>Symbolic links so that /usr/lpp/<product_name>/ can point into different
>HFSs?  Temporary installation into something other than
>/usr/lpp/<product_name>/? Some other technique?
>
>That 2nd technique was sometimes used at my last shop, but apparently
>some products use hard-coded paths /usr/lpp/<product_name>/.../.  Is
>that common, standard practice in MVS program products?  To have the
>paths to Unix libraries hard-coded and not overridable by installations?
>
>
>I probably asked a question similar to this about a year ago, but couldn't
>find it in the archive.
>
>Pat O'Keefe

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to