On Tue, 22 Aug 2006 07:03:25 +0800, Tommy Tsui <[EMAIL PROTECTED]> wrote:
> ...I think I have to read more manual >right now and perform more TEST cases.... > You might also want to think about how you will implement SMS. One way is to set up your SMS policy and convert your existing volumes to be SMS managed. This can be pretty complicated, but it may be your only option if you are very constrained on disk space The other way is to establish a limited SMS policy, then add to it. The risk of this is much lower. You can have an SMS policy that manages nothing that you can put in place if you have problems, and you are back where you were. For example, you could start by managing only temporary data sets, then gradually manage more. In order to do it that way, you would need volumes to add to your SMS pools as you need them You could increase your SMS environment by adding applications, by HLQ. Or you could add VOLUME as specified in the allocation. Alternatively, you could, for example, build a FILTLIST that covers all of your existing PRIVATE volumes and leave those allocations non-managed, but manage the rest. This will cause your non-specific, permanant data sets (the ones that today go to STORAGE) to be managed. Then you can remove volumes from the filtlist, allowing the data sets that had gone to those volumes to be managed. You might need to move data sets off of those volumes to get them to be empty, so you could add them to your SMS storage groups. Just understand that there are many ways to convert to SMS. Perhaps the easiest way is to bring in a new DASD subsystem and set it up as SMS managed, then adjust your ACS routines until you are managing all new non-system allocations. Good luck, Tom Marchant ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
