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

Reply via email to