We have Implemented Shared HFS in Our Sysplex with 4 Members ,
a few months ago.
Now, we want to upgrade the SYSTEM of 1 of the 4 members of
the sysplex with an Updated ROOT ,as part of Maintenace service for that
system , but leaving the 3 other members in the old state.
As reccomended in "UN
-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Cwi Jeret
Sent: Wednesday, January 21, 2009 5:12 AM
To: IBM-MAIN@bama.ua.edu
Subject: USS file sharing in z/OS - Version Ugrade
We have Implemented Shared HFS in Our Sysplex with 4 Members , a few
months ago.
Now, we
On Wed, 21 Jan 2009 04:12:01 -0600, Cwi Jeret wrote:
>We have Implemented Shared HFS in Our Sysplex with 4 Members ,
>a few months ago.
>
>Now, we want to upgrade the SYSTEM of 1 of the 4 members of
>the sysplex with an Updated ROOT ,as part of Maintenace service for that
>system , but leaving th
On Wed, 21 Jan 2009 08:18:44 -0600, Mark Zelden
wrote:
[...]
>There is no requirement for the "directory"
>file system, but I've seen a shop's sysplex root grow because all of
>the directories / mount points were getting created within the sysplex
>root. This eventually led to a sysplex wide IPL
On Wed, 28 Jan 2009 08:44:08 -0600, Arthur Gutowski wrote:
>On Wed, 21 Jan 2009 08:18:44 -0600, Mark Zelden
> wrote:
>[...]
>>There is no requirement for the "directory"
>>file system, but I've seen a shop's sysplex root grow because all of
>>the directories / mount points were getting created wi
I'm having trouble understanding why an IPL'ed system's sysres and USS files
are being used for cloning. I've always used a "staging" concept wherein
the SMP/E target sysres and USS file(s) for each running z/OS release are *
never* IPLed. This relieves a lot of issues and provides a "base", if
On Wed, 28 Jan 2009 10:31:05 -0500, Guy Gardoit wrote:
>I'm having trouble understanding why an IPL'ed system's sysres and USS files
>are being used for cloning. I've always used a "staging" concept wherein
>the SMP/E target sysres and USS file(s) for each running z/OS release are *
>never* IPLe
Actually, they don't. They are only mounted (to a /service' directory in
the sandbox system) when service is applied; unmounted when service
application is complete. The way I do staging is to NEVER used the staging
resvol(s) nor $VERSION FS(s) files for an IPL'ed system. They are only
used for
On Wed, 28 Jan 2009 11:15:43 -0500, Guy Gardoit wrote:
>Actually, they don't. They are only mounted (to a /service' directory in
>the sandbox system) when service is applied; unmounted when service
>application is complete. The way I do staging is to NEVER used the staging
>resvol(s) nor $VERSI
If all systems in a plex are IPLed from the new sysres-root combo, the "old"
FS are not mounted anywhere and can be deleted by the clone job. And,
yes, it does take a "perfect" world to get each sysplex to be on *one* set
of resvol(s) and one $VERSION root FS but I guess I have lived in a perfe
On Wed, 28 Jan 2009 12:52:49 -0500, Guy Gardoit wrote:
>We don't always do sysplex-wide IPLs but roll out the new sysres-root combo
>to all members of our plexes as soon as "doable". Once all systems in a plex
>are on the new "set", the "old" set is not mounted anywhere. I don't
>understand why
Eh! I do apologize. The first step in the clone job performs a Rexx exec
that ensures no system in the plex is running from the target resvol and
also dis-mounts the associated FS. So routine that I forgot what the job
does!
Guy Gardoit
z/OS Systems Programming
On Wed, Jan 28, 2009 at 1:13 P
On Wed, 28 Jan 2009 13:40:14 -0500, Guy Gardoit wrote:
>Eh! I do apologize. The first step in the clone job performs a Rexx exec
>that ensures no system in the plex is running from the target resvol and
>also dis-mounts the associated FS. So routine that I forgot what the job
>does!
>
>Guy G
13 matches
Mail list logo
