Re: HFS files for IBM program products
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//. >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// can point into different >HFSs? Temporary installation into something other than >/usr/lpp//? Some other technique? > >That 2nd technique was sometimes used at my last shop, but apparently >some products use hard-coded paths /usr/lpp//.../. 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
Re: HFS files for IBM program products
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//. >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// can point into different >HFSs? I'm not sure what you hope to achieve with a symbolic link. You can mount the HFS at /usr/lpp/. Tom Marchant -- 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
Re: HFS files for IBM program products
Most of the execs that IBM distributes (xxxMKDIR, etc) allow you to prefix the install path with a higher level directory name. We use /maint/ so that the actual directory that these products point to is /maint/usr/lpp/. We then mount an HFS at that point to receive the maintenance. As far as implementing the new version of an existing product, we have a symbolic link in /usr/lpp/ called product that points to a directory on the root called product (/usr/lpp/product -> /product. The product directory has subdirectories for each product and each subdirectory has version identifiers (/product/db2/v8 /product/db2/v7) at each of these subdirectories we mount the correct version of the product. When someone wants to use the product they point their startup scripts or configuration files to point to the correct directory. It sounds complex but it has saved us a ton of problems and allows us to mount the version root directory as read only which can prevent folks from inadvertantly (or not) overlaying our running system code. If you have access to the SHARE archives there are several presentations on this subject (one of them mine from the Nashville SHARE). Good luck! Jon Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Patrick O'Keefe Sent: Thursday, August 03, 2006 1:43 PM To: IBM-MAIN@BAMA.UA.EDU Subject: HFS files for IBM program products IBM program products apparently have packaging rules for Unix libraries stating that the path to these libraries will be /usr/lpp//. 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// can point into different HFSs? Temporary installation into something other than /usr/lpp//? Some other technique? That 2nd technique was sometimes used at my last shop, but apparently some products use hard-coded paths /usr/lpp//.../. 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 - This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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
Re: HFS files for IBM program products
On Thu, 3 Aug 2006 13:08:47 -0500, Tom Marchant <[EMAIL PROTECTED]> wrote: >... >>Symbolic links so that /usr/lpp// can point into different >>HFSs? > >I'm not sure what you hope to achieve with a symbolic link. You can mount >the HFS at /usr/lpp/. >... My understanding of this is a bit shakey , but this is for the migration process that exists at my shop. Software upgrades are migrated from test LPARs to development LPARs to production LPARs. I think I would be expected to maintain 3 HFSs for the product (for production and 2 levels of mainteenance, I guess). /usr/lpp// would point into one of the 3 HFSs; a different HFS for each type of LPAR. That doesn't address the need to switch back and forth between 2 maintenance levels since the resolved path is tied to the LPAR, but I guess I could dynamically change the value of the symbolic link if I needed to drop back to the previous level. This technique does not allow for execution of multiple levels of the product on the same LPAR, but neither does anything using /usr/lpp//. 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
Re: HFS files for IBM program products
On Thu, 3 Aug 2006 13:00:20 -0500, Brian Peterson <[EMAIL PROTECTED]> wrote: >... >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. >... We do use shared HFS, but I don't think that changes much. In my case I would have the old product in z/OS ROOT HFS pointed to by /usr/lpp/netview/v5r1/ and a new level of the product in its own HFS pointed to by /usr/lpp/netview/v5r2/. I guess I could mount and unmount the new HFS as needed during implementation ... Except that I don't think I will be allowed to do that on our development and production LPARs. :-( 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
Re: HFS files for IBM program products
You don't need to use /usr/lpp/ for your mountpoint. Products have either configuration files or startup parms that point to the directory for the product. You can crate a productname directory with mountpoint directories for each of the versions and have your parms point to that directory. We do that for all of our non-root products. It works and allows quick upgrade/backoff paths. We alos use symbolic links a lot. They can make life a lot easier. Less moving parts to change. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Patrick O'Keefe Sent: Thursday, August 03, 2006 2:42 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: HFS files for IBM program products On Thu, 3 Aug 2006 13:08:47 -0500, Tom Marchant <[EMAIL PROTECTED]> wrote: >... >>Symbolic links so that /usr/lpp// can point into >>different HFSs? > >I'm not sure what you hope to achieve with a symbolic link. You can >mount the HFS at /usr/lpp/. >... My understanding of this is a bit shakey , but this is for the migration process that exists at my shop. Software upgrades are migrated from test LPARs to development LPARs to production LPARs. I think I would be expected to maintain 3 HFSs for the product (for production and 2 levels of mainteenance, I guess). /usr/lpp// would point into one of the 3 HFSs; a different HFS for each type of LPAR. That doesn't address the need to switch back and forth between 2 maintenance levels since the resolved path is tied to the LPAR, but I guess I could dynamically change the value of the symbolic link if I needed to drop back to the previous level. This technique does not allow for execution of multiple levels of the product on the same LPAR, but neither does anything using /usr/lpp//. 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 - This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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
Re: HFS files for IBM program products
On Thu, 3 Aug 2006 15:03:59 -0400, Veilleux, Jon L <[EMAIL PROTECTED]> wrote: >You don't need to use /usr/lpp/ for your mountpoint. >Products have either configuration files or startup parms that point to >the directory for the product. ... Aha! So that is standard practice in IBM program products? NetView does not have this for at least one Unix fuction. When I complained about that during the ESP I was given the packaging rules as justification for not providing an override. 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
Re: HFS files for IBM program products
On Fri, 4 Aug 2006 09:43:52 -0500, Patrick O'Keefe <[EMAIL PROTECTED]> wrote: >... >>Products have either configuration files or startup parms that point to >>the directory for the product. ... > >Aha! So that is standard practice in IBM program products? >NetView does not have this for at least one Unix fuction. When I >complained about that during the ESP I was given the packaging rules as >justification for not providing an override. >... Well, this issue just got changed to a great big "Never mind!". In an offline communication (Thank you, Mark!) I was informed that NetView has an initialization parm to override the /usr/lpp/... path. The info I was given during a year ago during the ESP and again earlier this week was flat out wrong. IBM's NetView folks usually know their product very well. This laps is very out of character. I'm a bit irritated that I believed the misstatement. I would have install the new release many months ago had I known this. 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
