On Wed, 21 Jan 2009 08:18:44 -0600, Mark Zelden
mark.zel...@zurichna.com 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
On Wed, 28 Jan 2009 08:44:08 -0600, Arthur Gutowski aguto...@ford.com wrote:
On Wed, 21 Jan 2009 08:18:44 -0600, Mark Zelden
mark.zel...@zurichna.com 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
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 you
On Wed, 28 Jan 2009 10:31:05 -0500, Guy Gardoit ggard...@gmail.com 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
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
On Wed, 28 Jan 2009 11:15:43 -0500, Guy Gardoit ggard...@gmail.com 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
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 perfect
On Wed, 28 Jan 2009 12:52:49 -0500, Guy Gardoit ggard...@gmail.com 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
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
On Wed, 28 Jan 2009 13:40:14 -0500, Guy Gardoit ggard...@gmail.com 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
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
-
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 cwi_je...@yahoo.com 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 ,
Andrew,
We have a similar mixed environment. We approach it probably as Mark does.
SYSPLEX(YES) on all systems that use the shared SYSPLEX ROOT on the small
subset of shared DASD (with CDS' and a PARMLIB). We had one pre-existing
sysplex that fully shares its DASD. The rest of the
On Tue, 1 Jul 2008 09:03:57 -0500, Arthur Gutowski [EMAIL PROTECTED] wrote:
SYSPLEX(YES) only requires a common SYSPLEX ROOT within the Sysplex that
all systems can get to.
To clarify.. all systems that will run with SYSPLEX(YES). In the OP's case,
it is a subset of the sysplex. Other
Personally, I have always viewed the single HFSPlex as a deficiency. There
are so few items in z/OS that only allow one and present themselves as a
single point of failure. I would like it much better if it allowed for
multiple within a plex... similar to running multiple JES2's where you
I have a slightly different requirement, and I have come to the conclusion that
I can’t meet it.
I have a user that wants to share zFSes between a subset of systems within
a 13-way parallel sysplex.
Not all dasd is shared between all members of the sysplex. We merged 3
sysplexes into one and
On Mon, 30 Jun 2008 10:42:02 -0500, Andrew Metcalfe
[EMAIL PROTECTED] wrote:
I have a slightly different requirement, and I have come to the conclusion that
I cant meet it.
I have a user that wants to share zFSes between a subset of systems within
a 13-way parallel sysplex.
Not all dasd is
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Andrew Metcalfe
Sent: Monday, June 30, 2008 10:42 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: USS file sharing in z/OS
I have a slightly different requirement, and I have come
. but I guess that all systems in the subset have to be converted to have
the new file systems e.g. sysplex root and version? and the sysplex root has
to be AUTOMOVE. Whilst this may work technically, I feel that I might be
buying into a whole stack of trouble!
This will be difficult to
On Mon, 30 Jun 2008 12:15:00 -0500, Andrew Metcalfe
[EMAIL PROTECTED] wrote:
.. but I guess that all systems in the subset have to be converted to have
the new file systems e.g. sysplex root and version?
Not true.
and the sysplex root has
to be AUTOMOVE.
Yes, for the participating
Andrew Metcalfe wrote:
[snip]
As none of us are getting any younger,
I am trying to reduce complexity rather than introduce
some bespoke processing that will trip up our succesors!
And, of course, your company is preparing for the departure
of the older heads by training the younger
snip---
And, of course, your company is preparing for the departure of the older
heads by training the younger heads, to guarantee some continuity of
maintaining and enhancing the applications that keep the company running
successfully.
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden
Sent: Tuesday, May 27, 2008 3:31 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: USS file sharing in z/OS
[snip]
Except for read only requests (even when mounted R/W). IIRC
Mike,
As I understand it (doc is sketchy on this) from prior experience, if a PFS
like HFS or zFS is monted R/W on one or more of the systems in the sysplex,
then all requests, read and write, from non-owning systems are function shipped
to the owner. I.E., they auto-magically become
Hi:
I seem to recall seeing some restrictions on the ability to share USS files
between LPARs in a basic sysplex, although I don't remember where I saw the
reference.
My question is this. We have a basic sysplex here and our primary application
uses the DB2 Text Extender, which employs the
On Tue, 27 May 2008 13:59:46 -0400, Mike Myers [EMAIL PROTECTED] wrote:
Hi:
I seem to recall seeing some restrictions on the ability to share USS files
between LPARs in a basic sysplex, although I don't remember where I saw the
reference.
Perhaps in a recent thread where there seemed to be
Mark:
Thanks. I'll take a look.
Mike
Mark Zelden [EMAIL PROTECTED] 5/27/2008 2:30 PM
On Tue, 27 May 2008 13:59:46 -0400, Mike Myers [EMAIL PROTECTED] wrote:
Hi:
I seem to recall seeing some restrictions on the ability to share USS files
between LPARs in a basic sysplex, although I
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Mike Myers
Sent: Tuesday, May 27, 2008 1:00 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: USS file sharing in z/OS
Hi:
I seem to recall seeing some restrictions on the ability to
share USS
Mark Zelden wrote:
A properly configured shared file system in either a basic or parallel sysplex.
Have a look at the chapter on sharing file systems in a sysplex in the
UNIX System Services Planning manual. I think the doc is pretty good.
If you have questions after that, let us know.
Ed:
Sounds good to me. I am presently reading the File Sharing chapter in the USS
Planning manual. Sounds like I am going to like this one.
Mike
Edward Jaffe [EMAIL PROTECTED] 5/27/2008 2:42 PM
Mark Zelden wrote:
A properly configured shared file system in either a basic or parallel
PROTECTED]
616.653.8429
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Mike Myers
Sent: Tuesday, May 27, 2008 2:47 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: USS file sharing in z/OS
Ed:
Sounds good to me. I am presently reading the File Sharing
-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Mike Myers
Sent: Tuesday, May 27, 2008 2:47 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: USS file sharing in z/OS
Ed:
Sounds good to me. I am presently reading the File Sharing chapter in
the USS Planning manual. Sounds like I
Access thru XCF depends on whether the file-system is sysplex-aware. If so,
(like a R/O HFS) then access is local unless the requesting system does not
have DASD access. In that case, XCF to owning system is required.
The R/O VERSION ROOT FS should have local access to all sharing systems -
Richard Bond wrote:
Access thru XCF depends on whether the file-system is sysplex-aware. If so,
(like a R/O HFS) then access is local unless the requesting system does not have DASD
access. In that case, XCF to owning system is required.
The R/O VERSION ROOT FS should have local access to
Richard:
What you are saying is interesting. I am in the middle of reading the process
of setting up HFS file sharing. Are you saying that I can use XCF signaling to
function ship requests from an LPAR with read-only access to an HFS file to
another LPAR that has read/write access to the
On Tue, 27 May 2008 11:42:51 -0700, Edward Jaffe
[EMAIL PROTECTED] wrote:
Mark Zelden wrote:
A properly configured shared file system in either a basic or parallel
sysplex.
Have a look at the chapter on sharing file systems in a sysplex in the
UNIX System Services Planning manual. I think
On Tue, 27 May 2008 15:31:09 -0500, Mark Zelden wrote:
Except for read only requests (even when mounted R/W). IIRC, those are
handled from the local system regardless of the file system owner.
But beware; IIRC, even an apparent read request will attempt to
update the time-of-access in the
Mark Zelden wrote:
Except for read only requests (even when mounted R/W). IIRC, those are
handled from the local system regardless of the file system owner.
Are you sure about that? I could be wrong, but I thought that all
requests, when mounted R/W, were function shipped. Is there a
On Tue, 27 May 2008 13:58:19 -0700, Edward Jaffe
[EMAIL PROTECTED] wrote:
Mark Zelden wrote:
Except for read only requests (even when mounted R/W). IIRC, those are
handled from the local system regardless of the file system owner.
Are you sure about that? I could be wrong, but I thought that
On Tue, 27 May 2008 16:08:00 -0500, Mark Zelden [EMAIL PROTECTED]
wrote:
On Tue, 27 May 2008 13:58:19 -0700, Edward Jaffe
[EMAIL PROTECTED] wrote:
Mark Zelden wrote:
Except for read only requests (even when mounted R/W). IIRC, those are
handled from the local system regardless of the file
However, I thought I read somewhere else that the system was smart enough to
handle a read request locally.
I would think local reads could cause an integrity problem.
-
Too busy driving to stop for gas!
--
For IBM-MAIN
Mark Zelden wrote:
So it looks like it has to be mounted read only by reading the above.
Right. And, just to make sure we're both on the same page, the quoted
information says: ... all non-owning systems must access read-write
file systems through the remote owning system and each system
43 matches
Mail list logo
