Which of the many DATACLAS attributes do you wish to change. Most are physical aspects of the actual existing dataset. Just changing the description will have no effect. These attributes are fixed when the dataset is created. Re-creation and copying the data is the only effective way to change most if not all DATACLAS attributes.
I will ask again, what is the real underlying problem you want to solve? > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Jim McAlpine > Sent: Friday, February 08, 2013 1:16 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: basic SMS question > > I've found another error in the data class selection routines which > means that datasets have been converted but not assigned the correct > data class. > What is the quickest way to reassign a data class (or storage class > come to that). Do I have to CONVERTV to NONSMS and then CONVERTV to > SMS again or is there some quicker method. > > Jim McAlpine > > On Thu, Feb 7, 2013 at 4:11 PM, Jim McAlpine <jim.mcalp...@gmail.com> > wrote: > > > Thanks for the explanation. Much appreciated. > > > > Jim McAlpine > > > > On Thu, Feb 7, 2013 at 3:51 PM, Darth Keller > <darth.kel...@assurant.com>wrote: > > > >> A couple of things - > >> > >> &DSN(2) = 'DSNDBD' - 'DSNDBD' in the 2nd level generally > identifies > >> the data component of a DB2 LDS. Data components do not get > assigned > >> their own SMS Constructs. Constructs are assigned at the cluster > >> level. I see this as useless code unless your shop is actually using > >> cluster names with DSNDBD as the 2nd level. > >> > >> 2ndly - the answer to your question is going to depend on what's in > >> the filterlist &DB2E. > >> > >> If it contains an entry like DB2E.** , then all those datasets > would > >> be assigned SCDB2 in the &DSN(1) segment and then re-assigned SCSMS > in the > >> SELECT/WHEN you've shown us. This is a result of not having a EXIT > in > >> the first set of statements - the allocation falls through into the > >> next code segment and gets re-evaluated. And it will continue to be > >> re-evaluated after your > >> SET &STORCLAS = 'SCSMS' as that statement also doesn't appear to > have a > >> paired EXIT. > >> > >> Without the WRITE stmts Lisa mentioned, it's pretty hard to tell > from > >> what you've shown us. Your allocation could actually have several > >> storage classes assigned and re-assigned, with some other segment > >> having the final assignment of 'SCSMS' before it finally falls out > of SMS. > >> > >> My general rule of thumb is that the only time I don't pair a SET > >> with an EXIT is when I want to set a default StorCLas. I always > pair > >> a SET with a WRITE and generally its a SET, WRITE, & EXIT. > >> > >> I'd recommend investigating NAVIQUEST to use in testing your code & > >> any changes you're thinking of making. > >> ddk > >> > >> > >> //////////////////////////////// > >> > >> > >> I've inherited an SMS setup and I know little about SMS but this I > >> know isn't working. In the storage class ACS routines is this > >> snippet - > >> > >> IF &DSN(1) = 'DB2E' THEN > >> DO > >> IF &DSN(2) = 'DSNDBC' THEN > >> DO > >> SET &STORCLAS='SCDB2' > >> END > >> IF &DSN(2) = 'DSNDBD' THEN > >> DO > >> SET &STORCLAS='SCDB2' > >> END > >> END > >> followed by this - > >> > >> SELECT > >> WHEN (&DSN = &DB2E) > >> SET &STORCLAS = 'SCSMS' > >> Question. Any dataset of the form DB2E.DSNDBC.** is getting the > >> storage class SCSMS and not SCDB2 which is what is required. I want > >> all > >> DB2E.DSNDBC.** datasets to get SCDB2 and any other DB2E.** dataset > to > >> get SCSMS. What is wrong with the above syntax please. > >> > >> Jim McAlpine > >> > >> > >> > >> > >> > >> This e-mail message and all attachments transmitted with it may > >> contain legally privileged and/or confidential information intended > >> solely for the use of the addressee(s). If the reader of this > message > >> is not the intended recipient, you are hereby notified that any > >> reading, dissemination, distribution, copying, forwarding or other > >> use of this message or its attachments is strictly prohibited. If > you > >> have received this message in error, please notify the sender > >> immediately and delete this message and all copies and backups > >> thereof. Thank you. > >> > >> -------------------------------------------------------------------- > - > >> - For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO > >> IBM-MAIN > >> > > > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
