Rob,

Does you HA environment replicate program objects or do you let your CMS handle sending changed
objects to the HA target?

It would seem to me that the v5r4 to v6r1 upgrade scenario is one place where it might be better to
let your CMS keep the HA target programs current instead of letting the HA software try to do it.


Charles Wilt
--
Software Engineer
CINTAS Corporation - IT 92B
513.701.1307

wiltc@xxxxxxxxxx


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Tuesday, May 06, 2008 3:53 PM
To: Midrange Systems Technical Discussion
Subject: Re: V6R1 in A HA environment

Is your development lpar part of your HA cluster? If so, and you compile
program XYZ123 for TGTRLS(*CURRENT) how will it go to your HA machine? If
you compile it TGTRLS(*PRV) and run STROBJCVN on it do you expect any
audit issues because the attribute will be different on one machine than
the other?

We're relatively new to HA.
One, this will be our first OS upgrade since implementing HA.
Two, then obviously we didn't have this running the last time STROBJCVN
was a concern (CISC-to-RISC).

Of course, we won't upgrade before ANZOBJCVN passes with flying colors.

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





"Salter, James" <JSalter@xxxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
05/06/2008 03:36 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
<midrange-l@xxxxxxxxxxxx>
cc

Subject
V6R1 in A HA environment






I have a development LPAR, production LPAR, & HA Backup LPAR, all at
V5R4.

I plan on resolving all issues on each machine prior to going to V6R1.

Once all programs have been resolved, I will upgrade development, then
the HA Backup, then the production LPAR.

I do not plan on going to V6R1 prior to the 4th quarter this year (in
development), but as long as you resolve all V6R1 program conversions on
all machines before upgrading any of them, then I would expect normal
migrations using HA processes would be fine.

Just my thoughts.

Thanks.
James Salter
Systems Programmer
American Cast Iron Pipe Co

message: 2
date: Tue, 6 May 2008 13:28:57 -0400
from: rob@xxxxxxxxx
subject: V6R1 in a HA (High Availability) environment.

When migrating to a new version of the operating system in an HA
environment the generally accepted practice is to upgrade your "target"
machine first and then your "source" machine. Your source system should

not be higher than the target machine. The theory being that it may be
hard to send changes to a program if it couldn't do a TGTRLS(*CURRENT)
and
get it to the target machine. Of course, the onus is now on you, once
you've upgraded your target machine, to upgrade your source machine
before
your next scheduled switch or you're back into that trap.

My question is this:
If I upgrade my target machine to V6R1 and run STROBJCVN and then start
up
my HA solution will the audits fail because of some change date or other

errata that STROBJCVN may perform to a program object? My HA vendor is
saying that I should be fine. I am wondering what your experiences have

been. (I sure miss Al Barsa.)


Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com



_________Confidentiality Notice_______________________
This e-mail and any files transmitted with it is
confidential and is intended solely for the use of
the individual(s) or entity(ies) to whom this e-mail
is addressed. If you are not the intended recipient
or the person responsible for delivering the e-mail
to the intended recipient, be advised that you have
received this e-mail in error, and that any use,
disclosure, dissemination, forwarding, printing,
retention or copying of this e-mail is strictly
prohibited. If you have received this e-mail in
error, please immediately return this e-mail to
the sender and delete the e-mail from your system.
Thank you.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.




This e-mail transmission contains information that is intended to be confidential and privileged. If you receive this e-mail and you are not a named addressee you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this communication without the consent of the sender and that doing so is prohibited and may be unlawful. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please delete and otherwise erase it and any attachments from your computer system. Your assistance in correcting this error is appreciated.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.