Thanks Mike. Jim
On Fri, Feb 8, 2013 at 11:35 AM, Mike Schwab <[email protected]>wrote: > 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 <[email protected]> > 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 <[email protected]> > wrote: > > > >> Thanks for the explanation. Much appreciated. > >> > >> Jim McAlpine > >> > >> On Thu, Feb 7, 2013 at 3:51 PM, Darth Keller < > [email protected]>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 [email protected] with the message: INFO IBM-MAIN > >>> > >> > >> > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] 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 [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
