Hi Liz, I'm running JES2 v2.2 @ RSU1703 and I've done the MERGE form of JES2 spool volume migration 7 times to mostly migrate our spool farm of 14 3390-27 volumes to 7 3390-54 volumes. I still have a few volumes to go to completely replace all of the 3390-27 volumes in this environment. Each time, I add a 3390-54 volume and migrate 2 3390-27 volumes to the 3390-54 volume. All of the migrations have been successful and we've had no problems occur as a result of the merge migration. Our migrations have taken about 15 minutes per volume, though that's probably a function of the utilization of the source volume.
We age-delete our spool data after 5 days (held output) and 14 days (non-held) respectively, so this method is fundamentally similar to the old method of adding a new spool volume and halting source spool volumes, to replace spool volumes. After the $M command completes (maybe even during, I don't remember), the source volume is MAPPED to the target volume until all of the source volume data is age-deleted two weeks later and the source volume is DRAINed; I don't know if this philosophy is sanctioned by IBM but think of this as mapping the virtual spool volumes to physical dasd volumes, where the virtual volser can be different than the physical volser. The major difference between the old method and the $M MERGE method is that the physical dasd source volume is immediately available for reclaim by the dasd administrators after completion of the $M command, even though the data which previously resided on that volume still exists and JES2 tells you the data still resides on the source volume. Of course, the old source volser can't be added back to JES2 until the source volume is DRAINed. We're not able to use the MOVE form of JES2 spool migration in a real environment because our spool data is so large and actively changing that we can't afford to make the source volume INACTIVE prior to the migration, as is required for MOVE. The key to the MERGE migration is to use the output of $DSPL(xxxx),MIGDATA to ensure that the SPACE_USED quantity of the source volume is less than/equal to the LARGEST_FREE quantity of the target volume. You also need to ensure sufficient SPOOLDEF TGSPACE MAX capacity exists for both the source and target volumes (and any other volumes being used) to exist concurrently, until the source volume(s) are DRAINed. We generally $S the target volume and immediately do the merge migrations after target volume is formatted, to ensure a large output job doesn't jump in and claim some of that LARGEST_FREE space we were expecting to use for the MERGE migration. I hope that helps you. Please let me know if you have any specific questions. Dennis Schaffer ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
