× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



As someone with numerous lpars scattered across three Power 8's I'd like
to take a stab at that.

"IF" you have your security right I would not partition just to separate
the applications. IOW, if one of those packages is running payroll and
has *PUBLIC *ALL and someone is on some serious weed and believes they
just can't change that without the world coming to an end they maybe I'd
put that on it's own lpar. But in general I'd test him, toss him and get
someone else in there to clean up that security.

If, like us, you like to keep development on a separate lpar for testing
purposes, and keep no source on production, then I would create one source
and one development lpar.

If you have a web presence you might want to put that lpar into a DMZ and
have that query your internal systems. For example, we have our web
presence on a Domino lpar (lpars actually) and they query our DB2
production lpar.

If you want to replicate your data to another lpar and query that in order
to stop the runaway query from hell from killing your production system
that is a possibility.
In that same vein, if you want to replicate your data to another lpar and
do your backups from that lpar and not bring down your primary or deal
with the concerns of save-while-active that has often been done.
I know of people using Mimix between lpars for just this reason. We tend
to put our Mimix lpars on another system in another town. I actually work
out of the backup town and cover the tape gal when she is out for the day.
You could use the replica lpar for both backup and query. We tend to
query our production system. We've been lucky. That and when we do
planned outages on the 'backup' lpars I do those midday, midweek.

BTW, we used to use BPCS only for manufacturing and had another package
for financials. Now we run both on Infor LX. I'm the list admin for the
bpcs-l list hosted by midrange.com.

We keep Domino on a different lpar than our other data for a number of
reasons. One, the Domino servers query the ERP data. If you have
"PRIMARY" down and running on "BACKUP" it's awfully hard for domino to go
to the backup machine when domino is running on the same lpar. The
workaround is to always make sure domino on that lpar is down also. We
just didn't want to do that.
Another reason was that we were running some really old Domino stuff like
Quickr and older Sametime that was holding up IBM i upgrades. That just
drives me batshirt crazy. As of now, I'm waiting for Domino 9.0.1FP6
before I can upgrade numerous lpars to IBM i 7.3.

A close example might be if you're running BPCS 405CD and went cheapskate
on SSA/Infor and stopped paying maintenance. Expecting them to give you
updated code for no charge to run on newer versions of the OS, or
expecting it at a ridiculously low charge, would be insulting to those of
us who kept up on our maintenance. If you really want a higher version of
the OS then you could move the other lpars to a higher version. Of course
that old unlicensed 405CD is probably stuck at V5R4 and won't run on any
hardware capable of running 7.2 or 7.3. So that would have only bought
you some time in the past.


Rob Berendt

As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.