ALTER can change MGMTCLAS and STORCLAS, but not DATACLAS My best guess is that changing the DATACLAS would imply rewritting the data, since some DATACLAS attributes control the physical recording of data.
Don > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Mike Schwab > Sent: Friday, February 08, 2013 6:36 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: basic SMS question > > ALTER data.set.name DATACLAS(newvalue) > On a ISPF 3.4 line, a / picks up the data.set.name from that line. > > On Fri, Feb 8, 2013 at 3:15 AM, Jim McAlpine <jim.mcalp...@gmail.com> > wrote: > > 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 > > > > -- > Mike A Schwab, Springfield IL USA > Where do Forest Rangers go to get away from it all? > > ---------------------------------------------------------------------- > 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
