Hi Tom,
Thanks your advice again.
I still have a little question on SMS.
I have three JCL to allocate 3 types datasets
s
/* case 1 allocate temporary file
//BACKUP1 EXEC PGM=ICEGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DUMMY,DCB=(RECFM=FB,LRECL=80,BLKSIZE=0)
//SYSUT2 DD DSN=&&TEMP,DISP=(,PASS),UNIT=SYSDA,
// SPACE=(CYL,(1,1),RLSE)
//SYSIN DD DUMMY
/* case 2 allocate a dataset with volume assigned it will allocate to
"PRIVATE" volume TSMD12 under NON-SMS managed
//BACKUP1 EXEC PGM=ICEGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DUMMY,DCB=(RECFM=FB,LRECL=80,BLKSIZE=0)
//SYSUT2 DD DSN=TSMD.TEST.FILE1,DISP=(,PASS),UNIT=SYSDA,
// SPACE=(CYL,(1,1),RLSE),VOL=SER=TSMD12
//SYSIN DD DUMMY
/* case 3 allocate a dataset without volume assinged it will allocate to
"STORAGE" volume under NON-SMS managed
//BACKUP1 EXEC PGM=ICEGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DUMMY,DCB=(RECFM=FB,LRECL=80,BLKSIZE=0)
//SYSUT2 DD DSN=TSMD.TEST.FILE1,DISP=(,PASS),UNIT=SYSDA,
// SPACE=(CYL,(1,1),RLSE)
//SYSIN DD DUMMY
Assume I have the following ACS ..
FILTLIST TSMDFILE INCLUDE(TSMD.TEST.**)
IF &DSTYPE = 'TEMP' then
SET &STORCLAS= 'TEMPDS' /* for case 1 , I can group all &&TEMP
datasets into same pool with DSTYPE=TEMP , it's fine
IF &DSN = &TSMDFILE then
SET &STORCLAS = 'SCTSMD' /* for case 2 & case 3 it will go to the
same pool
/* for case 2 if I want it allocate to volume
"TSMD12" I think I can use "GUARANTEED SPACE" or allocate to "SCTSMD"
group. it's fine.
/* for case 3 - how can I managed all the
dataset allocate into individual storage group if no volume specified? is
that &ANYVOL or &ALLVOL works for that case? any other recommendation?
thanks
----- 轉呈者 Tsui Yuk Kai/Production Mgt Div/Information Technology
Dept/BOCHK/BOCG 於 2006/08/21 上午 08:48 -----
Tom Marchant
<[EMAIL PROTECTED]
AHOO.COM> 收件人
寄件人： IBM [email protected]
Mainframe 副本抄送
Discussion List
<[EMAIL PROTECTED] 主旨
.EDU> Re: How can the ACS routine to
bypass checking the storage volume
datasets?
2006/08/20 上午
09:58
請回信 給
IBM Mainframe
Discussion List
<[EMAIL PROTECTED]
.EDU>
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
***********************************************************
This message contains confidential information which is intended only for the
person or entity to which it is addressed. If you are not the intended
recipient, you should not read, disseminate, distribute or copy this e-mail.
Any opinion contained in this message are those of the author and are not given
or endorsed by BOCHK unless otherwise stated in this message and the authority
of the author to so bind BOCHK is duly verified. We do not guarantee that this
e-mail is virus-free or secure and are not liable in respect of any delay or
omission in the transmission of this message.
***********************************************************
----------------------------------------------------------------------
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
