Dan (see, I can get it right!),

I also got to enjoy ASP's once.  Performance is NOT good if any of the ASP's
that you create have too few arms for the amount of activity they
experience.  As James mentioned, there may be cases where something about
the way the data is used makes splitting it into separate ASP's helpful,
however I'll assert that we have to be talking about substantial amounts of
data before any benefit starts.  The only performance success I ever had
with a separate ASP was for journal receivers and save files (lots of save
to disk, copy to tape later going on).

Restores can be simpler IF the backup strategy is properly designed.  If I
remember right, if you have to restore ASP 1 you have to do a RCLSTG for the
machine to find the objects still intact on the other ASP's, then do your
RSTAUT after that.  I remember we didn't get that one quite right, and ended
up having to manually correct some authorities before everything ran again.

Suggestion - get some info about BRMS and show it to the mainframers.
They'll probably go ga-ga, and hopefully stop worrying about how the /400
stores stuff since recovery using BRMS is as simple as following a list of
customized instructions generated by the magic in the machine.  Then ask the
NT folks what they have that makes it simple like that.  (There actually are
some products out there, but if your shop doesn't have any of them this is a
good way to pull rank. ;)

Dave Shaw
Simpsonville, SC
---
If you would like to participate in the MAPICS-L mailing list send email to
MAPICS-L-SUB@midrange.com or go to www.midrange.com and follow the
instructions.

----- Original Message -----
From: <D.BALE@handleman.com>


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

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.