: Question on how RSU maintenance is being handled with
DIRMAINT and RACF in the picture
In order to be more democratic and accommodating, we could have
a CANCEL
button that said:
"CANCEL not allowed. You must press OK. Press CANCEL to press
OK.
Press
>
> In order to be more democratic and accommodating, we could have a CANCEL
> button that said:
> "CANCEL not allowed. You must press OK. Press CANCEL to press OK.
> Press OK to CANCEL the CANCEL and then press OK."
>
Maybe expand the choice with one more option: "If you still wish to press
CA
on how RSU maintenance is being handled with DIRMAINT and
RACF in the picture
On Wednesday, 07/16/2008 at 12:15 EDT, Adam Thornton
<[EMAIL PROTECTED]> wrote:
> > No. You'll also have the opportunity to delay the nag message for 3
> > minutes or 14.5 hours (your choice). The m
On Wednesday, 07/16/2008 at 12:15 EDT, Adam Thornton
<[EMAIL PROTECTED]> wrote:
> > No. You'll also have the opportunity to delay the nag message for 3
> > minutes or 14.5 hours (your choice). The messages will go to the
> > system
> > operator, but in a way that is not visible to system automa
On Jul 16, 2008, at 10:36 AM, Alan Altmark wrote:
On Wednesday, 07/16/2008 at 09:39 EDT, Rob van der Heij
<[EMAIL PROTECTED]> wrote:
On Wed, Jul 16, 2008 at 6:05 AM, Alan Altmark <[EMAIL PROTECTED]
>
wrote:
BTW, there's nothing wrong with building a test system and then
copying
that into
System [mailto:[EMAIL PROTECTED] On
Behalf Of Alan Altmark
Sent: Wednesday, July 16, 2008 11:36 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Question on how RSU maintenance is being handled with
DIRMAINT and RACF in the picture
On Wednesday, 07/16/2008 at 09:39 EDT, Rob van der Heij
<[EMAIL PROTE
> No. You'll also have the opportunity to delay the nag message for 3
> minutes or 14.5 hours (your choice). The messages will go to the
system
> operator, but in a way that is not visible to system automation. ;-)
And we are Marie of Roumania.
> Alan Altmark
> z/VM Development
> IBM Endicott
On Wednesday, 07/16/2008 at 09:39 EDT, Rob van der Heij
<[EMAIL PROTECTED]> wrote:
> On Wed, Jul 16, 2008 at 6:05 AM, Alan Altmark <[EMAIL PROTECTED]>
wrote:
>
> > BTW, there's nothing wrong with building a test system and then
copying
> > that into production in whatever way you wish. I'm not
I always user SERVICE and PUT2PROD, but I use them on the 2nd lvl test
system. They don't come near the systems that real people, i.e. users,
use. As far as an ESM goes, I have RACF, so that's a moot point for me.
I realize that VM development has limited resources and I recognize that
VM in
On Wed, Jul 16, 2008 at 3:53 AM, Feller, Paul <[EMAIL PROTECTED]> wrote:
> Everyone talks about a second level system. Our second level system is
> actually an lpar. We created a small "tech support" lpar that we first
> apply maintenance to. We also use it to test new z/VM upgrades. We do
>
On Wed, Jul 16, 2008 at 6:05 AM, Alan Altmark <[EMAIL PROTECTED]> wrote:
> BTW, there's nothing wrong with building a test system and then copying
> that into production in whatever way you wish. I'm not going to dictate
> to anyone how to get your system into Final Real Production.
So we're not
On Tuesday, 07/15/2008 at 07:40 EDT, Rob van der Heij <[EMAIL PROTECTED]>
wrote:
> Ugh. When I noticed that PUT2PROD would simply force the TCPIP service
> machine without any check & warning, I decided this was just not meant
> to be used in the open.
PUT2PROD hasn't done that for a long time.
Another LPAR is just as good as a second level system if you are already
familiar with using LPARs. The communications between LPARs requires a
bit more hardware but in a large shop with z/OS LPARs, there is usually
enough OSAs or CTC connections.
/Tom Kern
Feller, Paul wrote:
Thanks for al
Thanks for all the replies. It has given us something to think about.
We have only one more lpar to do the RSU on, so for now we will follow
the same process we did for the first two lpars. We are a zLinux only
shop. No big CMS usage or other stuff. We use a VSWITCH for the zLinux
network conn
On Wed, Jul 16, 2008 at 12:56 AM, Alan Altmark <[EMAIL PROTECTED]> wrote:
> Looking down the road, I see a rough ride for people who don't use SERVICE
> and PUT2PROD.
Ugh. When I noticed that PUT2PROD would simply force the TCPIP service
machine without any check & warning, I decided this was jus
On Tuesday, 07/15/2008 at 04:39 EDT, Kris Buelens <[EMAIL PROTECTED]>
wrote:
> I work like Jim: never PUT2PROD.
> Copy the runtime minidisks from the install user (eg 5VMTCP30) to
> alternate addresses of the "active" user (eg TCPMAINT). When the time
> is right, the mdisk addresses are swapped.
Of Kris Buelens
Sent: Tuesday, July 15, 2008 01:28
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: [IBMVM] Question on how RSU maintenance is being handled
with DIRMAINT and RACF in the picture
I work like Jim: never PUT2PROD.
Copy the runtime minidisks from the install user (eg 5VMTCP30) to
alternate
On Tue, Jul 15, 2008 at 11:10 AM, Colin Allinson <[EMAIL PROTECTED]> wrote:
> As Jim said - there are many different ways of doing maintenance. However,
> the guiding principal is always to have a thought out process where you can
> back out easily.
The requirement may actually be that "those in
Kris Buelens <[EMAIL PROTECTED]> wrote :-
> I work like Jim: never PUT2PROD.
> Copy the runtime minidisks from the install user (eg 5VMTCP30) to
> alternate addresses of the "active" user (eg TCPMAINT). When the time
> is right, the mdisk addresses are swapped. This process is first
> tested on t
; Paul Feller
> AIT Mainframe Technical Support
>
>
> -Original Message-
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
> Behalf Of Jim Bohnsack
> Sent: Monday, July 14, 2008 1:48 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Question on ho
eller
AIT Mainframe Technical Support
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Jim Bohnsack
Sent: Monday, July 14, 2008 1:48 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Question on how RSU maintenance is being handled with
DIRMAINT and R
Paul--I take a little more cautious approach to maintenance than you
do. I **DO NOT-EVER* *put RSU or any kind of maintenance on a
production system or on a "test" system, that being defined as not
really a production system but one that users can get access to in order
to test new or changed
We have been a z/VM shop for about three years and have applied RSU
maintenance during those three years. We currently are running z/VM 5.3
and are working on applying RSU0801. This is the first time we have
done an RSU with DIRMAINT and RACF in the picture. We are wondering how
other people ha
23 matches
Mail list logo