On Fri, 18 Aug 2006 07:21:49 +0800, Tommy Tsui <[EMAIL PROTECTED]> wrote:
>thanks BOB and TOM briefly explanation..thanks again... >Under non-sms managed, we have to allocate some double journal VSAM file >into different volumes such as IBMA01, IBMB01, (for performance purpose) >In SMS managed, the two journal may allocate to same volume after reorg (if >use a same pool)....except we fine tune the ACS and use separate storage >group. Are you sure you still need to ensure that these two data sets go to different volumes for performance reasons? If it is a concern on today's DASD, you should be looking at other techniques to improve performance, such as striped data sets. In any case, what will you do to prevent hundreds of other address spaces from causing interference? >It is difficult to manage the ACS as you know we many double journal >files and the ACS may be vey complex. IMHO, you don't want to do this that way. You will end up with scores of storage groups and SMS will not be able to manage effectively. The more storage groups you have, the more work you will have to do, rather than let SMS do the work. >As you know, our boss always ask me the STORAGE/PUBLIC volumes sufficicent >for tonight batch processing? how to manage after convert to >SMS The answer is that SMS will manage it, you don't need to. I know that it's difficult to convince management, but that's the way it is. I suggest you start small, perhaps managing only temporary data sets. Then add data sets with no volume specified. There is no need to add more storage groups. There should be a good reason for adding storage groups. You should not create storage groups to mimic the pools that you have today. When yu have things working smoothly, you can get rid of your STORAGE and PUBLIC volumes and add them to your storage groups. Begin managing other data sets. You could do this by HLQ, for example. Or you could manage data sets when they were spevified to go to particular volumes. You might have to move data sets off of volules to get them empty so that you can add the volumes to your storage groups. Whatever you do, beware of creating storage puddles. >....haha,,I reply ,there are no more storage/public volume under SMS >managed all volumes are private....then he will ask how many volumes you >required for each application if no common pool for STORAGE/PUBLIC >volume... > I think you are planning to create storage groups for each application. I advise against it. These are only suggestions. I'm sure you don't want to cause yourself more pain than you have now. Others here have different opinions about how to go about this. I know because we have debated it here before. I will tell you that, while I have strong opinions about the best way to implement SMS, other points of view are important, too. Please search the archives of this list and of ibm-main-archives. Tom Marchant 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
