|
midrange.com
> ... journal receivers are _almost_ entirely a sequential write
> operation. If you can isolate them to their own ASP the arms will move
> sequentially with the write operation and usually be in the right spot
to
> write the next block of data.
A point often missed - ASP dedicated to journal receivers should contain
only *one* active receiver - otherwise there will be contention between
receivers. If you have more than one journal, every one should have
separate ASP for receivers.
In this case, ASP can have a single unit and it will still be good from
performance point of view.
If receivers for different journals are in the same ASP it can be worth
then having a single large ASP on system with all the stuff intermixed.
Alexei Pytel
"Walden H.
Leverich" To:
"'MIDRANGE-L@midrange.com'"
<WaldenL@TechSoftIn <MIDRANGE-L@midrange.com>
c.com> cc:
Sent by: Subject: RE: ASPs
owner-midrange-l@mi
drange.com
05/17/2001 09:09 AM
Please respond to
MIDRANGE-L
OK, this is theory here as I haven't tried this but... I can see a design
where three ASPs would be of great use from a performance point of view.
ASP 1: Operating system and LPP
ASP 2: Data files (PFs and LFs) and user programs
ASP 3: Journal Receivers (you DO journal, right?)
However the standard caveat of disk arms applies. If you have 2 drives in
ASP 1 mirrored and they are 17G drives, you may have 17 Gig available, but
you only have one arm. BAD. However, if you have, say, 3-4 arms and you're
probably ok.
Someone brought up the concern of disk contention because the low-level
operating system programs would be all on ASP 1. While it's true that they
are on ASP 1, they also page to the machine pool, not the user pool, and
are
used so often that I'd bet good money they are always in memory so disk
contention is not an issue for these programs.
ASP 2 has all your data files and I'd guess 90% of your disk arm movement
is
to retrieve data so make damn sure you have sufficient drive arms in that
ASP. You're moving the arms around so much anyway that the additional
movement to load programs would be minimal.
Finally, journal receivers are _almost_ entirely a sequential write
operation. If you can isolate them to their own ASP the arms will move
sequentially with the write operation and usually be in the right spot to
write the next block of data.
Now, as I said, this is theory, so I await the flames <G>
-Walden
-----Original Message-----
From: D.BALE@handleman.com [mailto:D.BALE@handleman.com]
Sent: Wednesday, May 16, 2001 7:17 PM
To: MIDRANGE-L@midrange.com
Subject: ASPs
Again, from my mainframe and NT bosses...
I am being asked as to whether the AS/400 supports (what they call)
"channels", which (based on a 20 minute conversation that I will avoid
here)
I
have interpreted to mean what the AS/400 calls ASPs. The idea is to keep
the
OS and LPPs and all other (if any) objects that do not change except on
installation and PTF installs in a single ASP all by itself and then all
user
libraries and perhaps (?) other system objects that are subject to change
are
kept in another ASP.
I have had only a brief exposure to ASPs at one client site several years
ago
and my only rememberence as a programmer was that it was a royal PITA and
could not understand the benefits of having 2 user ASPs. FWIW, it was a JD
Edwards shop.
The basis for which my bosses are asking this question seem related to
being
able to backup the user libraries on a daily basis but only have to backup
the
OS & LPPs when they are upgraded/PTF'd/whatever. Yes, I know, I know, this
is
a SAVSYS & SAVLIB *IBM stuff vs. SAVLIB *NONSYS stuff (as well as the
SAVDLO
&
SAV commands), but I just wanted to have a clear(er) understanding from
those
on the list with ASP experience to see if there are other considerations I
am
not thinking of. One that I'm guessing on is that recovery from a DASD
failure that requires a restore would be much less blood-letting if the
system
were set up using ASPs. Yes/No?
TIA.
- Dan
Dan Bale says "BAN DALE!"
IT - AS/400
Handleman Company
248-362-4400 Ext. 4952
D.Bale@Handleman.com
Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---
As an Amazon Associate we earn from qualifying purchases.
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.
