Re: Question(s) on ASP's

["Steve Richter" <srichter@xxxxxxxxxxxxx>]

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 )