× 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.



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
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.