Re: Moving disk from one ASP to another

[CRPence <CRPbottle@xxxxxxxxx>]

Michael_Smith wrote:
> Michael_Smith wrote:
>
> <<SNIP>>
>
> > At that point, ASP3 should be almost completely empty.
>
> It was weird, there was .004% used in ASP3 but I deleted
> everything I knew I had over there.  I did a WRKLIB LIB(*ALL)
> ASP(3) and there were no libraries and when I did a WRKLNK
> /dev/QASP03, again there were no entries.
>
> > Anyone got any ideas if there is another way to have data in
> > another ASP?
>
> I guess it's secondary now, since it's deleted.

   Directories and Objects in libraries should be mostly all.  An 
alternate style ASP allows the storage for save file(s) [dump spaces 
of] or the storage for journal receiver(s) rather than the objects 
themselves [which use an ASP() parameter to denote the alternate ASP 
as location of the data for the object], but then as a special type 
of ASP, any directories or library objects would be disallowed.

> > Shut down and IPL manual again into DST. About 15 minutes to
> > shutdown and IPL to DST
>
> I had to Delete ASP 3 (after a few moments to pause and think
> before I hit enter "What is the .004%!! utilized")

  There may be some system-specific storage required to support an 
ASP for which neither directory nor object listings will show the 
storage taken.  I am not sure, or even so how much storage one would 
expect; way too long since I ever used the ASP support and even 
longer since actually clearing one.

  However there is a recommendation to RCLSTG *ALL before removing 
an ASP, to ensure that any /orphan/ storage is made available in the 
form of a library or directory object; i.e. manifest as a named 
object in either the QRCL#### *LIB, or an STMF in the special named 
[for its ASP] reclaim directory.  Had that been done, then perhaps 
some of the missing storage would have been made visible to allay 
concerns for what if anything might be lost.

> > Move the remaining, 'near empty' DASD units to ASP 1.
>
> This is what really got me.  I thought that since there wasn't
> anything on the disk, and therefore nothing to move around, that
> adding them would be quick.  No deal, as this was another 2
> hours.  I guess when you think about it, you increasing the area
> single level storage can access and there is probably a lot of
> addressing work that goes on.
>
> <<SNIP>>

  IIRC the time spent would have been for initialization of the 
disk units.  Empty, new, or full, each entire disk is processed 
[larger disk requires more time] in order to make the initialized 
units available to the [chosen ASP of the] system.

Regards, Chuck