Re: Question(s) on ASP's -- MIDRANGE-L

A few comments on the ASP questions:

1).  The number for User ASPs ranged from 2 to 16 prior to V5R1.  In V5R1
they go all the way to 32.  This completely omits the issues regarding
Independent ASPs, (those numbers go up to 99) which only hold IFS objects
in V5R1, but based on an IBM SOD will include library objects and DLOs in a
future release.
2).  There are two kind of User ASPs, "Old ASPs" and "New ASPs".  As you
mentioned in your post, a library is assigned into an ASP, although the
User ASPs have the option of overflowing into the system ASP, which
compromise the integrity of the ASP until it is fixed.  This was the ASP
implementation as introduced in V1R3.  Prior to V1R3, User ASP libraries
all existed in ASP #1, but a User ASP was defined as such the first object
created in that ASP.  Then, only journals, journal receivers and save files
could exist in a User ASP, and if the first object created in that ASP
claimed it, then the ASP was used.  Today both types of ASP coexist, and
must be either the "Old" type or the "New" type.  This causes it to be very
difficult to code for these different type of ASPs, and I am unaware of any
easy way to determine if a User ASP is "Old" or "New".  (This might be
possible via API, but I have not coded to it.)

Al - on the way from Charlotte back to New York

Al Barsa, Jr.
Barsa Consulting Group, LLC

400>390

914-251-1234
914-251-9406 fax

http://www.barsaconsulting.com
http://www.taatool.com






                    "Steve Richter"
                    <srichter@AutoCoder       To:     <midrange-l@midrange.com>
                    .com>                     cc:
                    Sent by:                  Subject:     Re: Question(s) on 
ASP's
                    midrange-l-admin@mi
                    drange.com


                    04/01/02 11:39 AM
                    Please respond to
                    midrange-l







I had a transitioning  720 to work with last week ...

there can be from 1 to 16 ASPs on the system.

You use DST to physically assign disk drives to each ASP.

ASPs from 2 to 16 can be compressed at the drive hardware level.

Libraries are assigned to an ASP. All the objects in the library then
reside
in the ASP.

Use SAVLIB and RSTLIB to move a lib from one ASP to another.

Dont overflow an ASP.  When I was restoring to a compressed ASP, the ASP
overflowed and the 720 croaked a slow death.  That was the end of my
experiment.

The ASP concept is excellent.
   - mirror the drives that your production data is on, dont mirror the
online save files.
  - compress seldom used libraries, dont compress others

with the potential of:
  - physically seperate one appl from another.
  - no disk contention between the applications.
  - to load or unload an application from the system, just pull or insert
the drive(s) ??

But sadly, IBM has not completed the circle
  - reconfiging your ASPs is time consuming.
  - ASP overflow is a hassle and from my brief experiment, a system killer.

Object level asp assignment and real time asp config are needed.
  -This would enable the system to transition the system one object at a
time after a real time ASP config change.
  -Also, ASP overflow could be better handled, as the overflowing object
would simply be moved to an ASP that has room.

Steve Richter

( expression space left intentionally blank )


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