Limitations: Before using independent ASP support, be aware that independent ASPs do not protect against disk failure. If the disks in the independent ASP are damaged and the data is unrecoverable, data is available only up to the last backup copy. A replication solution such as MIMIX is still required for high-availability and disaster recovery. In addition, be aware of the following limitations:
-
Although you can use the same library name between independent ASPs, an independent ASP cannot share a library name with a library in the system ASP or basic ASPs (SYSBAS). SYSBAS is a component of every name space, so the presence of a library name in SYSBAS precludes its use in any independent ASP. This will affect how you configure object for replication with MIMIX, especially for IFS objects. See Configuring library-based objects when using independent ASPs .
-
Unlike basic ASPs, when an independent ASP fills, no new objects can be created into the device. Also, updates to existing objects in the independent ASP, such as adding records to a file, may not be successful. If an independent ASP attached to the target system fills, your high-availability and disaster recovery solutions are compromised.
-
IBM restricts the object types that can be stored in an independent ASP. For example, DLOs cannot reside in an independent ASP.
Restrictions in MIMIX support for independent ASPs include the following:
-
MIMIX supports the replication of objects in primary and secondary independent ASPs only. Replication of IFS objects that reside in user-defined file system (UDFS) independent ASPs is not supported.
-
You should not place libraries in independent ASPs within the system portion of a library list. MIMIX commands automatically call the IBM command SETASPGRP, which can result in significant changes to the library list for the associated user job. See Avoiding unexpected changes to the library list.
-
MIMIX product libraries, the LAKEVIEW library, and the MIMIXQGPL library must be installed into SYSBAS. These libraries cannot exist in an independent ASP.
-
Any *MSGQ libraries, *JOBD libraries, and *OUTFILE libraries specified on MIMIX commands must reside in SYSBAS.
-
For successful replication, ASP devices in ASP groups that are configured in data group definitions must be made available (varied on). Objects in independent ASPs attached to the source system cannot be journaled if the device is not available. Objects cannot be applied to an independent ASP on the target system if the device is not available.
-
Planned switchovers of data groups that include an ASP group must take place while the ASP devices on both the source and target systems are available. If the ASP device for the data group on either the source or target system is unavailable at the time the planned switchover is attempted, the switchover will not complete.
-
To support an unplanned switch (failover), the independent ASP device on the backup system (which will become the temporary production system) must be available in order for the failover to complete successfully.
-
In order for MIMIX to access objects located in an independent ASP, do one of the following on the Synchronize Object (SYNCOBJ) command:
-
Specify the data group definition.
-
If no data group is specified, you must specify values for the System 1 ASP group or device, System 2 ASP device number, and System 2 ASP device number parameters.
Also be aware of the following temporary restrictions:
-
MIMIX does not perform validity checking to determine if the ASP group specified in the data group definition actually exists on the systems. This may cause error conditions when running commands.
-
Any monitors configured for use with MIMIX must specify the ASP group. Monitors of type *JRN or *MSGQ that watch for events in an independent ASP must specify the name of the ASP group where the journal or message queue exists. This is done with the ASPGRP parameter of the CRTMONOBJ command.