RE: LPAR Usage? -- MIDRANGE-L

This is a multipart message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
I take it that JDE OneWorld is not tiered priced?  Oh well, in this case
it probably doesn't matter since all your CPU's seem to be running it.  I
was thinking of the EDI example posted by Carl.

Often negotiations can be done that would not charge a system for
development/test.  Thus you *may* be able to get a free license on your
test/development machine.  Now, if you have tiered software, paid for on a
830 and free on the 720, and you combine the 830 and 720 to make an 890,
then it could be financially significant.

Rob Berendt
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin




"McGivern, Tom" <Tom.McGivern@Yum.com>
Sent by: midrange-l-admin@midrange.com
11/15/2002 06:46 PM
Please respond to midrange-l

        To:     <dennis.e.lovelady@accenture.com>,
<midrange-l@midrange.com>
        cc:
        Fax to:
        Subject:        RE: LPAR Usage?


We have:
9406-720, 2 Lpars (1 SBCS, 1 DBCS) Development/test
9406-830, 4 Lpars (1 boot, 1SBCS, 2 DBCS) Production
  Upgrading the 830 to 890 next month, the 890 will have 8 lpars to
support more countries.

You need to understand our environment for some of the reasoning to make
sense...

We're an international company, we run JDEdwards OneWorld (Financials)-
supporting 15 countries (when we're fully rolled out).  On a single
iSeries box here in Dallas, Tx.

This requires both Single Byte and Double Byte Languages (Simp. Chinese,
Trad. Chinese, Korean).  JDE Does not support (nor would we want) to mix
DBCS and SBCS languages (DBCS languages take up twice the disk space).
So we have different "Systems" for the different countries we're
supporting (consolidating where it makes sense
(US/Canada/Mexico/GreatBritan in one). Australia will be in it's own
(explained next).

Because we have all the world.. Trying to schedule backups and
maintenance during one countries "night-time", is right smack in the
middle of the day for somebody else.  Separate instances permit us to do
work on a sliding window.. (Doesn't Require LPAR).

Yes, all the above could be done across multiple systems.  But due to
our sliding windows, we can, on an 8CPU system (soon to be 16CPU),
schedule (through OPS_Navagator), CPU/Memory movement between the Lpars
so the prime shift for a given country gets the bulk of the resources.
Some of our systems need more than 1 CPU, but don't need 2.. We run
Taiwan with 1.5.. Try to do that on a stand-alone system.

This is also how we adjust the tape backups.. We flip the IOP with the
SCSI adapter between lpars, so each system can get to the tape drive.
(A 3590E11 costs $35K, only has two SCSI interfaces..)  If we had
multiple systems, we would not have enough SCSI interfaces on the tape
drive, additional drives/maintenance required.

SW/HW/Maint costs..  It's cheaper to pay for a single P40 license, than
3 P20s (830 2403/1531 vs. 830 2400/1531) -- Our Hwmaint on the 830 is
$13K/Qtr  For 3 individual systems, would exceed that, and we're adding
more every quarter.

Drawbacks...  If you boot Lpar 0, you take everybody down..
   Work around:  Run Lpar 0 with just the OS, no applications (infact I
think you only need the LIC), we have LP0 running on .25 CPU  I reboot
it about every 6 months when I apply maintenance to it.  This the users
can live with.

So... To wrap it up..  Why would we NOT want Lpar?
 -- We get shared resources  (Memory/CPU/Tape) so we can budget for the
aggregate, not the peak.
 -- We get lower SW/HW maintenance costs (and initial purchase costs).
 -- We have a slightly more complex environment... But nothing I can't
handle.




This communication is confidential and may be legally privileged.  If you
are not the intended recipient, (i) please do not read or disclose to
others, (ii) please notify the sender by reply mail, and (iii) please
delete this communication from your system.  Failure to follow this
process may be unlawful.  Thank you for your cooperation.
_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.