Re: Managing /service for SMP/E
Shmuel, This is noise. Apparently you have no intentions of replying to my questions. As I said, I do not have a problem, but a solution. I *did* coordinate my DDDEF, naming conventions, /etc/auto.master, and map files, and it works fine. I was soliciting opinions and alternative solutions. If you have any idea how to implement Automount *and* provide for the path needed by AJVSCRPT, I'd still like to hear it. Tom Marchant On Thu, 1 Sep 2005 20:39:20 -0300, Shmuel Metz (Seymour J.) shmuel+ibm- [EMAIL PROTECTED] wrote: In [EMAIL PROTECTED], on 08/31/2005 at 08:21 PM, Tom Marchant [EMAIL PROTECTED] said: AFAIK, Automount won't extract TARGET from /service/java/TARGET/usr/lpp/java and use that to generate the HFS DSNAME OMVS.TARGET.JAVA14. Then it's just as well that nobody suggested that it would. Automount is defined with a policy that is defined, by default, in /etc/auto.master. For each mount point that is managed by Automount, there is a line in the policy such as this: /service/java /etc/service_java.map Water is wet. In my case, /etc/service_java.map looks like this: Therein lies your problem. You need to coordinate your DDDEF, naming conventions, /etc/auto.master, and map files. -- Shmuel (Seymour J.) Metz, SysProg and JOAT -- 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: Managing /service for SMP/E
In [EMAIL PROTECTED], on 08/30/2005 at 02:11 PM, Tom Marchant [EMAIL PROTECTED] said: AFAIK, it is not possible to do what you are suggesting because Automount does not work that way. Doesn't work what way? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Managing /service for SMP/E
You said that I should Automount OMVS.TARGET.JAVA14 at /service/java/TARGET/usr/lpp/java and use that in your DDDEF. AFAIK, Automount won't extract TARGET from /service/java/TARGET/usr/lpp/java and use that to generate the HFS DSNAME OMVS.TARGET.JAVA14. If you know something that I don't, please enlighten me. I'd also appreciate any thoughts that you have about the solution that I have described. Automount is defined with a policy that is defined, by default, in /etc/auto.master. For each mount point that is managed by Automount, there is a line in the policy such as this: /service/java /etc/service_java.map The first thing on the line is the directory that is to be managed by Automount, the second is a map file telling Automount what to do when there is a reference to a subdirectory to the Automount managed directory. In my case, /etc/service_java.map looks like this: name* typeHFS filesystem OMVS.ucname.JAVA14 moderdrw duration10 delay 10 This map tells Automount that the subdirectory of /service/java/ is to be converted to upper case (ucname) and used to construct the HFS DSNAME. Thus, if my DDDEF specifies /service/java/TARGET/usr/lpp/java, Automount will dynamically create a subdirectory of TARGET and mount OMVS.TARGET.JAVA14 at that directory. If you then look at /service/java/TARGET/ you will not find usr but J1.4 On Wed, 31 Aug 2005 19:39:23 -0300, Shmuel Metz (Seymour J.) [EMAIL PROTECTED] wrote: In [EMAIL PROTECTED], on 08/30/2005 at 02:11 PM, Tom Marchant [EMAIL PROTECTED] said: AFAIK, it is not possible to do what you are suggesting because Automount does not work that way. Doesn't work what way? -- In [EMAIL PROTECTED], on 08/29/2005 at 03:31 PM, Tom Marchant [EMAIL PROTECTED] said: snip! If you know a way that I can define Automount so that I can reference, for example, /service/java/TARGET/usr/lpp/java/J1.4 and Automount will mount OMVS.TARGET.JAVA14 at /service/java/TARGET/usr/lpp/java, I would be very interested in learning how to do it. Why would you want to? Automount OMVS.TARGET.JAVA14 at /service/java/TARGET/usr/lpp/java and use that in your DDDEF. -- 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: Managing /service for SMP/E
I do not understand. I believe I just asked how to do exactly what you suggested, and you asked why I would want to. AFAIK, it is not possible to do what you are suggesting because Automount does not work that way. Tom Marchant On Tue, 30 Aug 2005 08:58:40 -0300, Shmuel Metz (Seymour J.) shmuel+ibm- [EMAIL PROTECTED] wrote: In [EMAIL PROTECTED], on 08/29/2005 at 03:31 PM, Tom Marchant [EMAIL PROTECTED] said: snip! If you know a way that I can define Automount so that I can reference, for example, /service/java/TARGET/usr/lpp/java/J1.4 and Automount will mount OMVS.TARGET.JAVA14 at /service/java/TARGET/usr/lpp/java, I would be very interested in learning how to do it. Why would you want to? Automount OMVS.TARGET.JAVA14 at /service/java/TARGET/usr/lpp/java and use that in your DDDEF. -- 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: Managing /service for SMP/E
In [EMAIL PROTECTED], on 08/28/2005 at 01:18 PM, Tom Marchant [EMAIL PROTECTED] said: I guess you didn't bother to read my original post, And I guess that you didn't read my response ;-) If you use a naming convention that includes the target zone as part of both the dsname and the mount point, then I don't see the problem. When you wrote -PathPrefix-/usr/lpp/java/J1.4, did you mean the literal string -PathPrefix- or a prefix that you were free to assign? If the latter, what is your problem? Is something that should run on the driver or on the target? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Managing /service for SMP/E
I guess you didn't bother to read my original post, where I wrote: On Tue, 16 Aug 2005 12:03:25 -0500, Tom Marchant [EMAIL PROTECTED] wrote: snip! For example, Java is designed to be mounted at /usr/lpp/java/ and the DDDEF PATH is to be -PathPrefix-/usr/lpp/java/J1.4. Since I am automount managing /service/ I need another place to mount the Java HFS for SMP/E. I set my automount policy to manage /service/mvs with the corresponding change to the PATHs to /service/mvs/IPLVOL/ To provide a mount point that I can use for Java, I also manage /service/java and changed the path to /service/java/J1.4. Unfortunately, this does not work, because when it comes time to run AJVSCRPT, it expects the path to be of the form -PathPrefix-/usr/lpp/java/J1.4. On Mon, 22 Aug 2005 06:20:56 -0300, Shmuel Metz (Seymour J.) [EMAIL PROTECTED] wrote: In [EMAIL PROTECTED], on 08/19/2005 at 12:32 PM, Tom Marchant [EMAIL PROTECTED] said: I don't have any problem cloning them or changing the PATHs with ZONEEDIT. My question was about managing the mountpoints, specifically for those products that are not installed in the root HFS. If you use a naming convention that includes the target zone as part of both the dsname and the mount point, then I don't see the problem. /service/CICS01 could have an automount of OMVS.CICS01 and /service/CICS02 could have an automount of OMVS.CICS02, assuming two CICS target zones with those names. You must, of course, coordinate changes to automount policies for SMP and production. -- 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: Managing /service for SMP/E
In [EMAIL PROTECTED], on 08/19/2005 at 12:32 PM, Tom Marchant [EMAIL PROTECTED] said: I don't have any problem cloning them or changing the PATHs with ZONEEDIT. My question was about managing the mountpoints, specifically for those products that are not installed in the root HFS. If you use a naming convention that includes the target zone as part of both the dsname and the mount point, then I don't see the problem. /service/CICS01 could have an automount of OMVS.CICS01 and /service/CICS02 could have an automount of OMVS.CICS02, assuming two CICS target zones with those names. You must, of course, coordinate changes to automount policies for SMP and production. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Managing /service for SMP/E
Hello Tom. My comment about symlink for /usr/lpp etc was about the base files... the symlink is for $VERSION/usr The service mount point is always the same res pack, so never changes. Regards Bruce Hewson -- 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: Managing /service for SMP/E
I see. Thanks, Bruce. We are using sysplex shared structure, too. --- Bruce Hewson [EMAIL PROTECTED] wrote: My comment about symlink for /usr/lpp etc was about the base files... the symlink is for $VERSION/usr -- 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: Managing /service for SMP/E
/quote Peter, It does work great, doesn't it? No worries about having the wrong HFS mounted to go with your RESVOL, and always IPL with the correct root (or version, if you have a Sysplex shared HFS structure implemented). Do you have any other products installed in their own HFS? I know that JAVA doesn't play nice with Automount. I suspect the others don't either, but I'm not certain yet. Tom Marchant /quote Tom, Actually, I haven't seen any issues with java w/in the context of installing service when using this strategy, recently. Originally, when you had to run the post-SMP/E processing, yes it was a pain! Now however, SMP/E does that expansion that used to be post-APPLY processing. Anything that would normally reside on the RESVOL is installed in the RESVOL HFS. Other products, such as CICS, TSM, ISV products, etc.. have their own HFS/ZFS and their own mount point w/in the /service directory, all managed by Automount. It does take some planning, and when each product comes in, working with the person doing the install, so that they don't just blindly install according to the program directory, but make the proper adjustments to the DDDEFS and Automount mapping for the /service directory. For the non-RESVOL products, I look at it like this. You wouldn't want a non-sysres product to install it's code into SYS1.LINKLIB would you? Well, if a product is not in the same global as z/OS, I don't want them installing into the SYSRES HFS. Thanks, Peter I. Vander Woude Sr. Mainframe Engineer -- 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: Managing /service for SMP/E
In [EMAIL PROTECTED], on 08/17/2005 at 01:16 PM, Tom Marchant [EMAIL PROTECTED] said: The Unix System Services Planning manual has only limited references to mounting the HFS that is to be used by SMP/E at /service and changing the DDDEFS. It doesn't give any suggestions as to how to manage multiple target zones and ensure that the correct HFS is mounted at /service. Isn't there a discussion of including system-specific and sysres-specific strings in the HFS names? That should be enough to let you clone the whole set and do a UCL edit on your DDDEF's. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Managing /service for SMP/E
I don't have any problem cloning them or changing the PATHs with ZONEEDIT. My question was about managing the mountpoints, specifically for those products that are not installed in the root HFS. On Thu, 18 Aug 2005 18:10:34 -0300, Shmuel Metz (Seymour J.) shmuel+ibm- [EMAIL PROTECTED] wrote: In [EMAIL PROTECTED], on 08/17/2005 at 01:16 PM, Tom Marchant [EMAIL PROTECTED] said: The Unix System Services Planning manual has only limited references to mounting the HFS that is to be used by SMP/E at /service and changing the DDDEFS. It doesn't give any suggestions as to how to manage multiple target zones and ensure that the correct HFS is mounted at /service. Isn't there a discussion of including system-specific and sysres-specific strings in the HFS names? That should be enough to let you clone the whole set and do a UCL edit on your DDDEF's. -- 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: Managing /service for SMP/E
quote from Tom Marchant Still, the problem remains with applications that need to have their HFS mounted at /service/usr/lpp/, as clearly recommended in the SMP/E documentation. It seems as if we have an SMP/E that can handle an arbitrary large number of target zones and always access the correct target data sets through DDDEFs, but we are expected to manually mount the corresponding HFSes for the ROOT, JAVA, HOD, MQ, NetData, XML, and probably others. I would not want to go back to the days of running SMP with a PROC containing DD statements with VOL=SER=xx for every target data set. The way I see it, the tools available for managing the system HFSes is in a similar state. Tom Marchant /quote Tom, What we do here, and I find the simplest, is a couple steps: 1) create a file system and mount it at /service. 2) Prefix all paths in the smp/e target zone with /service/RESVOL (where RESVOL is the name of your TARGET zone volume). If you have more than one target volume for this zone, use the first one, i.e. the one that you IPL off when testing. 3) Allocate the HFS for the target zone to contain the name RESVOL (see above) in the dataset name. 4) Use Unix System Services Automount facility for the /service directory, such that whenever you reference /service/RESVOL, it will automatically mount the proper HFS dsn. 5) Code your BPXPRMxx member to reference the root hfs at IPL using the symbolic SYSR1. This is the basic process we use, and it works great! I can be installing a new release of z/OS, and upgrading the current one, at the same time, no problems! Peter I. Vander Woude Sr. Mainframe Engineer -- 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: Managing /service for SMP/E
Peter, It does work great, doesn't it? No worries about having the wrong HFS mounted to go with your RESVOL, and always IPL with the correct root (or version, if you have a Sysplex shared HFS structure implemented). Do you have any other products installed in their own HFS? I know that JAVA doesn't play nice with Automount. I suspect the others don't either, but I'm not certain yet. Tom Marchant On Thu, 18 Aug 2005 08:44:44 -0400, Peter Vander Woude [EMAIL PROTECTED] wrote: quote from Tom Marchant Still, the problem remains with applications that need to have their HFS mounted at /service/usr/lpp/, as clearly recommended in the SMP/E documentation. It seems as if we have an SMP/E that can handle an arbitrary large number of target zones and always access the correct target data sets through DDDEFs, but we are expected to manually mount the corresponding HFSes for the ROOT, JAVA, HOD, MQ, NetData, XML, and probably others. Snip! Tom Marchant /quote Tom, What we do here, and I find the simplest, is a couple steps: 1) create a file system and mount it at /service. 2) Prefix all paths in the smp/e target zone with /service/RESVOL (where RESVOL is the name of your TARGET zone volume). If you have more than one target volume for this zone, use the first one, i.e. the one that you IPL off when testing. 3) Allocate the HFS for the target zone to contain the name RESVOL (see above) in the dataset name. 4) Use Unix System Services Automount facility for the /service directory, such that whenever you reference /service/RESVOL, it will automatically mount the proper HFS dsn. 5) Code your BPXPRMxx member to reference the root hfs at IPL using the symbolic SYSR1. This is the basic process we use, and it works great! I can be installing a new release of z/OS, and upgrading the current one, at the same time, no problems! Peter I. Vander Woude Sr. Mainframe Engineer -- 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: Managing /service for SMP/E
Hi, Tom A bit late to this discussion, but here's what I did at a prior job, and wrote about back in January 2001. http://bama.ua.edu/cgi-bin/wa?A2=ind0101L=ibm-mainP=R40187 As far as Java is concerned, I choose to install it into the z/OS root file system (instead of into its own), which simplifies the problem you describe. The problem you describe (the lack of explicit guidance for managing service installation for ever increasing quantity of HFS/zFS elements) has existed for quite some time, and I certainly agree with the premise that IBM has not done very much to simplify this for customers. Brian On Tue, 16 Aug 2005 12:03:25 -0500, Tom Marchant [EMAIL PROTECTED] wrote: How do you manage the mountpoints when applying service with SMP/E? I am planning on discussing this at a BOF at SHARE next week, and I'd appreciate any thoughts that you have. I have a PMR open with IBM also. All of the documentation simply says to mount the alternate HFS at /service, but I don't find that to be a very adequate solution. To me it is akin to running SMP/E with a PROC that includes DD statements for every target data set that specifies the target volumes, and it is asking for trouble. My preference is to use Automount to manage /service and set the PATHs in my DDDEFs to /service/IPLVOL/... where IPLVOL is the first sysres for the target zone. Automount would then mount OMVS.IPLVOL.ROOT as needed. In the old days, with only one HFS per target zone, this worked fine. Now that we have other products broken out into their own HFS, it becomes a little more complicated. For example, Java is designed to be mounted at /usr/lpp/java/ and the DDDEF PATH is to be -PathPrefix-/usr/lpp/java/J1.4. Since I am automount managing /service/ I need another place to mount the Java HFS for SMP/E. I set my automount policy to manage /service/mvs with the corresponding change to the PATHs to /service/mvs/IPLVOL/ To provide a mount point that I can use for Java, I also manage /service/java and changed the path to /service/java/J1.4. Unfortunately, this does not work, because when it comes time to run AJVSCRPT, it expects the path to be of the form -PathPrefix-/usr/lpp/java/J1.4. My solution to this was to create a /usr directory in the Java root. Within that directory I created a lpp directory with a symbolic link at /usr/lpp/java in the Java HFS. This symbolic link has a value of ../.. (without the quotes). The result is that AJVSCRPT can find /service/java/IPLVOL/usr/lpp/java/J1.4. This allows everything to work. When I clone my target zone the /usr/lpp/java structure that is in the Java HFS gets copied along with everything else. There are ZONEEDITs to fix the DDDEF PATHs and I don't have to manually ensure that the correct HFSes are mounted for SMP/E. I think that XML, Host on Demand and MQ Series have similar requirements, but I have not spent much time investigating them yet. The PMR that I have open is against Unix System Services, but I think it might more appropriately be against SMP/E. The SMP/E manuals have numerous references to /service/usr/lpp/ without giving any hint of how to manage the mounting of the HFSes needed when applying service. I have looked at the AJVSCRPT script and it looks to me as if the limitation of using -PathPrefix-/usr/lpp/java is a result of the way that SMP/E calls the script. Any thoughts would be greatly appreciated. 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: Managing /service for SMP/E
Thanks, Shmuel. The Unix System Services Planning manual has only limited references to mounting the HFS that is to be used by SMP/E at /service and changing the DDDEFS. It doesn't give any suggestions as to how to manage multiple target zones and ensure that the correct HFS is mounted at /service. As others have noted, it is possible to create a different mount point for each target zone rather than always using /service. If designed correctly, Automount can even be used to ensure that the correct HFS is mounted at any service directory. Still, the problem remains with applications that need to have their HFS mounted at /service/usr/lpp/, as clearly recommended in the SMP/E documentation. It seems as if we have an SMP/E that can handle an arbitrary large number of target zones and always access the correct target data sets through DDDEFs, but we are expected to manually mount the corresponding HFSes for the ROOT, JAVA, HOD, MQ, NetData, XML, and probably others. I would not want to go back to the days of running SMP with a PROC containing DD statements with VOL=SER=xx for every target data set. The way I see it, the tools available for managing the system HFSes is in a similar state. Tom Marchant On Wed, 17 Aug 2005 09:07:18 -0300, Shmuel Metz (Seymour J.) shmuel+ibm- [EMAIL PROTECTED] wrote: In [EMAIL PROTECTED], on 08/16/2005 at 12:03 PM, Tom Marchant [EMAIL PROTECTED] said: How do you manage the mountpoints when applying service with SMP/E? I am planning on discussing this at a BOF at SHARE next week, and I'd appreciate any thoughts that you have. I vaguley recal discussions of this in Unix System Services Planning and in the CPAC documentation. -- 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: Managing /service for SMP/E
Tom, I've been half watching this thread - given my general antipathy to the Unix impimentation on z/OS. Maybe we are too simply setup here, but I don't see your issue. We have a target zone per resvol (set; res plus extension). When we clone, we mount the new root at /service. Maint is APPLY'd, and /service unmounted. The duration of the mount is as limited as we can reasonably manage. All maint is done by one team, again one target (resvol) and within a known timeframe as we go through a published roll-out cycle. No clashes, no concerns. KISS. Shane .. Tom wrote on 18/08/2005 04:16:52 AM: The Unix System Services Planning manual has only limited references to mounting the HFS that is to be used by SMP/E at /service and changing the DDDEFS. It doesn't give any suggestions as to how to manage multiple target zones and ensure that the correct HFS is mounted at /service. -- 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: Managing /service for SMP/E
Hi Shane Instead of using /service as the mount point we use /SYSRT1 After maintenance is installed the contents of SYSRT* are cloned to SYSRS* before rolling out the new set to dev and prod lpars. We also mount the active res as /SYSRS1 All access to /usr/lpp etc are done using symlinks. Since we use /SYSRT1 instead of /service it means changing all the SMPE DDDEFs to use /SYSRT1 etc. But that means all mounts are done consistently via the SYSRES VOLUME name, even when we test IPL off the SYSRT1 volume. Regards Bruce Hewson of course, our res volume names are different from above but I hope you can get the idea -- 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: Managing /service for SMP/E
Bruce, I'm not sure what you mean about using symlinks for /usr/lpp. Have you created links that are used both for production and for applying service? Do you have the likes of Java, HOD, MQ, XML, etc included in the root, or are they in seperate HFSes. If they are not in the root, how do you manage their mount points when you apply service to them? Thanks, Tom Marchant --- Bruce Hewson [EMAIL PROTECTED] wrote: Snip! All access to /usr/lpp etc are done using symlinks. snip! -- 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: Managing /service for SMP/E
Tom, There was a flash or something quite a while ago that explained just what to do for creating the /service directory and how to apply maintenance. I spent too long looking for it, but I can't find it now. I'm not sure if it's what you want, but I know someone sent the link to IBM-Main a year or 2 ago, and it helped me to set up correctly to do maintenance. Before I read that, I just did maintenance, and anything in the HFS was updated live. I was lucky - I never got burned. Hopefully, someone has the link bookmarked. I thought it would be under SMP/E, but I didn't see it there. Eric Bielefeld PH Mining Equipment On Tue, 16 Aug 2005 12:03:25 -0500, Tom Marchant [EMAIL PROTECTED] wrote: How do you manage the mountpoints when applying service with SMP/E? I am planning on discussing this at a BOF at SHARE next week, and I'd appreciate any thoughts that you have. I have a PMR open with IBM also. All of the documentation simply says to mount the alternate HFS at /service, but I don't find that to be a very adequate solution. To me it is akin to running SMP/E with a PROC that includes DD statements for every target data set that specifies the target volumes, and it is asking for trouble. My preference is to use Automount to manage /service and set the PATHs in my DDDEFs to /service/IPLVOL/... where IPLVOL is the first sysres for the target zone. Automount would then mount OMVS.IPLVOL.ROOT as needed. In the old days, with only one HFS per target zone, this worked fine. Now that we have other products broken out into their own HFS, it becomes a little more complicated. For example, Java is designed to be mounted at /usr/lpp/java/ and the DDDEF PATH is to be -PathPrefix-/usr/lpp/java/J1.4. Since I am automount managing /service/ I need another place to mount the Java HFS for SMP/E. I set my automount policy to manage /service/mvs with the corresponding change to the PATHs to /service/mvs/IPLVOL/ To provide a mount point that I can use for Java, I also manage /service/java and changed the path to /service/java/J1.4. Unfortunately, this does not work, because when it comes time to run AJVSCRPT, it expects the path to be of the form -PathPrefix-/usr/lpp/java/J1.4. My solution to this was to create a /usr directory in the Java root. Within that directory I created a lpp directory with a symbolic link at /usr/lpp/java in the Java HFS. This symbolic link has a value of ../.. (without the quotes). The result is that AJVSCRPT can find /service/java/IPLVOL/usr/lpp/java/J1.4. This allows everything to work. When I clone my target zone the /usr/lpp/java structure that is in the Java HFS gets copied along with everything else. There are ZONEEDITs to fix the DDDEF PATHs and I don't have to manually ensure that the correct HFSes are mounted for SMP/E. I think that XML, Host on Demand and MQ Series have similar requirements, but I have not spent much time investigating them yet. The PMR that I have open is against Unix System Services, but I think it might more appropriately be against SMP/E. The SMP/E manuals have numerous references to /service/usr/lpp/ without giving any hint of how to manage the mounting of the HFSes needed when applying service. I have looked at the AJVSCRPT script and it looks to me as if the limitation of using -PathPrefix-/usr/lpp/java is a result of the way that SMP/E calls the script. Any thoughts would be greatly appreciated. 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: Managing /service for SMP/E
Thanks, Eric. Everything I've seen from IBM simply says to clone your HFS and mount it at /service, but that is hardly adequate when you have 17 MVS images and can only get a few IPLs per year. We have several target zones to keep track of, and we may need to apply service to any of them. Automount is the best solution that I know to ensure that the correct HFSes are mounted at the correct mounty points. I had written about this several years ago in http://tinyurl.com/ajjmc . Tom Marchant On Tue, 16 Aug 2005 15:29:27 -0500, Eric Bielefeld Eric- [EMAIL PROTECTED] wrote: Tom, There was a flash or something quite a while ago that explained just what to do for creating the /service directory and how to apply maintenance. I spent too long looking for it, but I can't find it now. I'm not sure if it's what you want, but I know someone sent the link to IBM-Main a year or 2 ago, and it helped me to set up correctly to do maintenance. Before I read that, I just did maintenance, and anything in the HFS was updated live. I was lucky - I never got burned. Hopefully, someone has the link bookmarked. I thought it would be under SMP/E, but I didn't see it there. Eric Bielefeld -- 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: Managing /service for SMP/E
Tom,
I can speak only for DB2/CICS/WMQ but I believe our MVS folks choose the same
way. We use zFS for new products.
During product installation we run the following SMPE job.
SET BOUNDARY(CIC310T) .
ZONEEDIT DDDEF .
CHANGE PATH('/usr/lpp/cicsts/cic310'*,
'/smpt/usr/lpp/cicsts/cic310'*) .
ENDZONEEDIT .
So all apply goes to /smpt like /service which points to SMPT.CIC310.ZFSFILE
(VSAM linear dataset)
Then we copy this file like this
COPY DATASET(INCLUDE(SMPT.CIC310.ZFSFILE)) -
RENUNC(SMPT.CIC310.ZFSFILE, -
SYS5.CIC310A.ZFSFILE) -
SHARE -
TOL(ENQF) -
STORCLAS(AA01) -
MGMTCLAS(MSYST000) -
CATALOG-
TGTALLOC(CYL) -
REPLACE
/*
//*
//MOUNT EXEC PGM=IKJEFT01
//SYSPROC DD DISP=SHR,DSN=SYS5.STCSYS.CLIST
// DD DISP=SHR,DSN=SYS4.SPFSYS.CLIST
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
mount FILESYSTEM('SYS5.CIC310A.ZFSFILE') +
mountpoint('/add1') type(zfs) mode(rdwr)
unmount FILESYSTEM('SYS5.CIC310A.ZFSFILE')
mount FILESYSTEM('SYS5.CIC310A.ZFSFILE') +
mountpoint('/usr/lpp/cicsts/cic310') type(zfs) mode(read)
For zFS you need to mount a new zFS as READ/WRITE and then unmount and mount it
again as READ only. Product zFS or HFS are READ only and shared across several
images.
In case of new service we mount it again as
PROFILE MSGID WTPMSG
MOUNT TYPE(zfs) +
MODE(RDWR) +
MOUNTPOINT('/smpt/usr/lpp/cicsts/cic310') +
PARM('AGGRGROW') +
FILESYSTEM('SMPT.CIC310.ZFSFILE')
and then apply the new service. The new zFS will then SYS5.CIC310B.ZFSFILE
in case of a fallback.
Of course you need to create some mostly orphaned directory in you ROOT HFS.
It's a bit easier for HFS.
Roland
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Marchant
Sent: Tuesday, August 16, 2005 10:58 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Managing /service for SMP/E
Thanks, Eric.
Everything I've seen from IBM simply says to clone your HFS and
mount it at /service, but that is hardly adequate when you have
17 MVS images and can only get a few IPLs per year. We have
several target zones to keep track of, and we may need to apply
service to any of them. Automount is the best solution that I
know to ensure that the correct HFSes are mounted at the
correct mounty points.
I had written about this several years ago in http://tinyurl.com/ajjmc .
--
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: Managing /service for SMP/E
Tom, The requirements we have for applying maintenance to the z/OS operating system here has dictated how we name the HFS 'service' mountpoint. The 'key' requirement I must adhere to is: Must be able to apply any maintenance to any of the z/OS operating system levels we have installed using any z/OS image. I chose to create multiple SYSRES volumes for each z/OS operating system level we maintain. For example, we currently run z/OS R4 on our seven z/OS images. We have four SYSRES volumes ( named: ASR41Z, ASR42Z, ASR43Z ASR44Z ) that support these seven z/OS images. Each z/OS R4 SYSRES volume may have a different 'maintenance level' applied to it. Our preference is to apply our z/OS maintenance to these SYSRES volumes in numeric order, sometimes that is not possible. So, we addressed this requirement by taking the '/service' concept one level further. We created a second-level directory to the '/service' directory and added that second-level directory to the HFS DDDEFs within each Target Zone. For example: ASR41Z /service/ASR41Z/ ASR42Z /service/ASR42Z/ ASR43Z /service/ASR43Z/ ASR44Z /service/ASR44Z/ The above structure allows me another way to cross check the DDDEFs in a Target Zone are referencing the correct HFS ( assuming I mounted the correct HFS dataset to the correct mountpoint I listed above ). I ensure that by having HFS mount and unmount steps in each SMP/E Apply Check Apply jobs that are executed. That ensures no HFS was left mounted from a previous job and that no HFS is left mounted after a maintenance run. HTH Glenn Miller --- This message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorised use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. ABN AMRO Bank N.V. (including its group companies) shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system. ABN AMRO Bank N.V. (or its group companies) does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. --- -- 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: Managing /service for SMP/E
Thanks, Glenn. This is the same thing that I did, except that I established an Automount policy to mount the HFS when it is referenced. For the simple case of managing the MVS root (Version) HFS, it looks like this. /etc/auto.master contains this: /service/etc/service.map /etc/service.map looks like this: name * type HFS filesystem OMVS.uc_name.ROOT mode rdwr duration 10 delay10 Thus, when SMP/E references /service/ASR41Z/, Automount will automatically mount OMVS.ASR41Z.ROOT at that mount point. The duration and delay specification of ten minutes each means that the HFS will remain mounted for ten minutes regardless of access, then after the initial ten minutes, the HFS will be unmounted after it has not been referenced for ten minutes. This part of it works beautifully, and it has the additional advntage that I can't mount the wrong HFS at /service/ASR41Z/. The problem is that Java is then expected to be mounted at /service/ASR41Z/usr/lpp/java, but I can't use Automount to manage that mount point, because Automount uses the lowest level directory to build the HFS name. My initial solution is to change my /etc/auto.master like this: /service/mvs/etc/service_mvs.map /service/java /etc/service_java.map My /etc/service/map, as above is renamed to /etc/service_mvs.map and I have created /etc/service_java.map, which looks the same, except that the HFS that is mounted is OMVS.uc_name.JV390. Now, when I service the ASR41Z target zone, I will mount OMVS.ASR41Z.ROOT at /service/mvs/ASR41Z/ and OMVS.ASR41Z.JV390 at /service/java/ASR41Z/. I can change my path for JAVA to /service/java/ASR41Z/J1.4 and everything works fine until AJVSCRPT is called to unwind the tarball. It fails, because it expects the J1.4 directory to be at /service/java/ASR41Z/usr/lpp/java/J1.4. My solution is to create a /usr/lpp/java symbolic link in the Java HFS root so that AJVSCRPT can find /service/java/ASR41Z/usr/lpp/java/J1.4. Thanks agaib, Tom Marchant --- Glenn Miller [EMAIL PROTECTED] wrote: Snip! We have four SYSRES volumes ( named: ASR41Z, ASR42Z, ASR43Z ASR44Z ) that support these seven z/OS images. Each z/OS R4 SYSRES volume may have a different 'maintenance level' applied to it. Our preference is to apply our z/OS maintenance to these SYSRES volumes in numeric order, sometimes that is not possible. So, we addressed this requirement by taking the '/service' concept one level further. We created a second-level directory to the '/service' directory and added that second-level directory to the HFS DDDEFs within each Target Zone. For example: ASR41Z /service/ASR41Z/ ASR42Z /service/ASR42Z/ ASR43Z /service/ASR43Z/ ASR44Z /service/ASR44Z/ The above structure allows me another way to cross check the DDDEFs in a Target Zone Snip! Glenn Miller -- 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
