Filter
Top Products
360 DS6000 Series: Concepts and Architecture
Copy Services for iSeries
Due to OS/400 having a single level storage, it is not possible to copy some disk units without
copying them all, unless specific steps are taken.
FlashCopy
When FlashCopy was first available for use with OS/400, it was necessary to copy the entire
storage space, including the Load Source Unit (LSU). However, since the LSU must reside
on an internal disk, this first had to be mirrored to a LUN in the external storage subsystem.
Because it is not possible to IPL from external storage, it was then necessary to D-Mode IPL
the target system/partition from CD, then Recover Remote LSU. This is sometimes known as
basic FlashCopy.
In order to ensure the entire single level storage is copied, memory needs to be flushed –
preferably with a
PWRDWNSYS or perhaps more acceptable, taking the system into a Restricted
State using
ENDSBS *ALL.
For most customers, this is not a practical solution.
To avoid this and to make FlashCopy more appropriate to iSeries customers, IBM has
developed a service offering to allow Independent Auxiliary Storage Pools (IASPs) to be used
with FlashCopy independently from the LSU and other disks which make up *SYSBAS
(ASP1-32). This has three major benefits:
1. Less data is copied.
2. Recover Remote LSU recovery is not necessary.
3. Communication configuration details are not affected.
The target system can be a live system (or partition) used for other functions such as test,
development and Lotus® Notes®. When backups are to be done, the FlashCopy target can
be attached to the partition without affecting the rest of the users. Or perhaps more likely, the
target will be a partition on the same system as production but may have no CPU or memory
allocated to it until the backups are taken, when these resources are then reallocated from
the production environment (or other) and moved to the backup partition.
Again, like the basic FlashCopy, it is necessary to flush memory for those objects to be saved
so that all objects reside in the ESS (where FlashCopy runs). However, unlike basic
FlashCopy, this is achieved by varying off the IASP rather than powering off the system or
taking it to restricted state. The rest of the system is unaffected.
Remote Mirror and Copy
Although the same considerations apply to the Load Source Unit as for FlashCopy, unlike
FlashCopy which would likely be done on a daily/nightly basis, Remote Mirror is generally
used for DR. The additional steps required to make the target volumes usable (D-IPL, recover
remote LSU, abnormal IPL) are more likely to be acceptable due to the infrequent nature of
invoking the DR copy. Recovery time may be affected but the recovery point will be to the
point of failure. This is sometimes known as
basic Remote Mirroring.
Using the advantages previously discussed when using IASPs with FlashCopy, we are able
to use this technology with Remote Mirror as well. Instead of the entire system (single level
Attention: You should not assume that Copy Services with iSeries works the same as with
other open systems.