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.
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
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
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.)
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
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
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
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
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
/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
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
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:
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
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
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
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
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,
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.
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
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
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.
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
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
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
24 matches
Mail list logo
