Caveat: insert the daily delay for listServ digestion here... Small v1.12 monoplex shop.
Our (my) mandate is that unless there's a good/valid reason/justification, any given dataset should be SMS managed. [1] As such, my CDSs are non-managed [2] since I inherited them that way and see no reason/benefit to change; being all of 5 cylinders each. All my uCats are managed and directed to a restricted access pool along with (non-z/OS) LinkList, procLibs, and zUnix root(s). DB2 uCats are pooled with the table/index spaces strictly for FlashCopy consistency. [3] z/OS volumes are non-managed because the guy in charge won't consider SMS at all. He manages those volumes himself and the StorClas ACS routine has specific code to avoid them. [1] The mCat(s) are on those volumes as well. Follow-up tips: 1) I have multiple ACDS on different volumes; 3 of which include FAILOVR in their name. As part of the process to harden/finalize a new configuration, I issue SETSMS SAVEACDS(ACDS.FAILOVR#) for each. It allows me to endure 3 volume failures [4] before I need to panic; using SETSMS ACDS(ACDS.FAILOVR#). I have the same for the CommDS. 2) One housekeeping item to consider is moving APF-only ie. not LinkList as well, datasets to SMS managed. Then, the ParmLib APF entries use the volume *SMS* and they can be moved around if/as desired ie. HSM interval processing, FDRMove. [1] My ACS routine(s) auto-assign class values unless specifically directed not to ie. StorClas=[nonSMS | None], volSer=nonSMS, HLQ=nonSMS, etc. [2] I am prepared for the eventuality by including them in the DataSet Separation profile. [3] We had catalogue consistency problems with DR when the uCats were in a different pool and backed up at a different time of day. That led to moving them into the same storage pool. [4] Although Rad will point out that 'volumes' are strictly a logical construct not actually reflected in the physical storage medium. *grin* --------> signature = 6 lines follows <-------- Neil Duffee, Joe Sysprog, uOttawa, Ottawa, Ont, Canada telephone:1 613 562 5800 x4585 fax:1 613 562 5161 mailto:NDuffee of uOttawa.ca http:/ /aix1.uOttawa.ca/ ~nduffee “How *do* you plan for something like that?” Guardian Bob, Reboot “For every action, there is an equal and opposite criticism.” “Systems Programming: Guilty, until proven innocent” John Norgauer 2004 -----Original Message----- From: Toni Cecil [mailto:ac...@gma...com] Sent: February 22, 2015 13:34 Subject: Re: DFSMS: Can CDSs and UCAT, be SMS managed or not ?? [snip] talking about DFSMS ACDS,SCDS and COMMDS (i'll refer CDSs hereafter). The reason for this question is that I have "all flavours". Systems with UCAT be SMS managed and CDSs not be sms managed. CDSs be SMS managed and UCAT not sms managed. I wonder if there was any "not mandatory but very much advisable rule" to set up these datasets. In all cases, each of these CDSs is placed in one dedicated dasd volume. On Wed, Feb 18, 2015 at 5:42 PM, R.S. <r...sk...@bre...com...pl> wrote: > W dniu 2015-02-18 o 18:27, Toni Cecil pisze: > >> do you know any consideration to have ACS,SCDS and COMMDS as sms >> managed or not ?? and how about the catalog where these datasets are >> placed ?? >> I'm with z/os V1.13 >> > According to ServerPac Installation Dialog the CDSes have to be > cataloged in MCAT, but this is not true. > I have never put those CDSes on SMS-managed volume and I think there > is good reason for that, like never putting spare door key inside the room. > However AFAIR there is no requirement for those datasets to be not > SMS-managed. There is no requirement to be SMS-managed as well. > -- > Radoslaw Skorupka ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
