Re: SMS Question
Since you are receiving an IGD message, I am going to presume your TMS is RMM (as opposed to CA1). RMM AFAIK does not allow reading of a scratch tape. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Kayhan Tanriverir Sent: Wednesday, July 10, 2019 1:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMS Question Hi, I received the following messages when I process the JCL: •IGD330I ERROR OCCURRED DURING CBRXLCS PROCESSING- FOR DATA SET VOLUME REQUESTED BY SPECIFIC VOLUME SERIAL IS A SCRATCH VOLUME THE FAILING VOLSER IS A00195 •IGD306I UNEXPECTED ERROR DURING ?CBRXLCS PROCESSING RETURN CODE 8 REASON CODE 51 I know that when processing a tape data set, if SMS detects an error from the macro CBRXLCS, SMS will try to issuse the message IGD330I. IGD306I: An unexpected error occurred during storage management subsystem processing. I checked ISMF Mountable Tape Volume List panel (ISMF option 2.3). The volser was in SCRATCH status, but I noticed that there is an undefined library in this panel. And the failing volser is in this library. How can I remove this undefined library. Iyi calismalar, saygilar / Regards _ Kayhan TANRIVERIR Senior Systems Programmer VBT Bilgi Teknolojileri A.S. https://apc01.safelinks.protection.outlook.com/?url=www.vbt.com.trdata=02%7C01%7Callan.staller%40HCL.COM%7Cfd08d282e35e4a5ea75008d70503563e%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636983384255906708sdata=behGLm%2Fv6tThnez0x%2BDKlzlnktP%2FMztsTPYSpAJoLMo%3Dreserved=0 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SMS Question
Hi, I received the following messages when I process the JCL: • IGD330I ERROR OCCURRED DURING CBRXLCS PROCESSING- FOR DATA SET VOLUME REQUESTED BY SPECIFIC VOLUME SERIAL IS A SCRATCH VOLUME THE FAILING VOLSER IS A00195 • IGD306I UNEXPECTED ERROR DURING ?CBRXLCS PROCESSING RETURN CODE 8 REASON CODE 51 I know that when processing a tape data set, if SMS detects an error from the macro CBRXLCS, SMS will try to issuse the message IGD330I. IGD306I: An unexpected error occurred during storage management subsystem processing. I checked ISMF Mountable Tape Volume List panel (ISMF option 2.3). The volser was in SCRATCH status, but I noticed that there is an undefined library in this panel. And the failing volser is in this library. How can I remove this undefined library. Iyi calismalar, saygilar / Regards _ Kayhan TANRIVERIR Senior Systems Programmer VBT Bilgi Teknolojileri A.S. www.vbt.com.tr -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS QUESTION
Thanks to all who contributed ot my post. A special shout out to Vroom for mentioning the Dynamic Volume count. On Monday, February 18, 2019, 12:00:30 p.m. EST, John McKown wrote: On Mon, Feb 18, 2019 at 10:57 AM esmie moo < 012780d99c7b-dmarc-requ...@listserv.ua.edu> wrote: > Yes the dsn was reallocated. I tried out Dynamic Volume Count (Vroom > had mentioned it) and I was able successfully run the job. It allocated 37 > vols.I am curious to try out your recommendation to use the ALTER. I > assume I have to issued the command while the job is executing because if > the job abends the dsn is deleted. Could you please confirm my > understanding? > Sorry, I didn't realise that the DSN was deleted at job end. The ALTER won't help while the job is in execution. I sometimes use it for CICS datasets, but CEMT SET CLOSE , do the ALTER, then CEMT SET OPEN. The dataset must be closed and reopened to pick up the catalog entry changes. > Thanks. > On Monday, February 18, 2019, 9:24:28 a.m. EST, John McKown < > john.archie.mck...@gmail.com> wrote: > > On Mon, Feb 18, 2019 at 8:07 AM esmie moo < > 012780d99c7b-dmarc-requ...@listserv.ua.edu> wrote: > > > Gentle Readers, > > I encountered a problem with a space abend for a IAM VSAM EXTENDED > > FORMAT.dsn. In the DATACLAS we have the Volume Count at 30 so I changed > it > > to 40. I restarted the job however it abended at NUMBER OF VOLUMES 30.My > > question Is what is the maximum number of volumes that cane be allocated > > via the SMS DATACLAS for the Volume Count? > > > > Did you reallocate the DSN? The value for volume count is set from the > DATACLAS at allocation time. Any changes to the DATACLAS after allocation > are not used. The simpliest way to increase the volume count is to: > > ALTER <<>> ADDVOL(* * * * * * * * * *) > > Put in as many asterisks are you want extra volumes. > > > > > Thanks in advance. > > > > > -- > I just burned 2000 calories! > That's the last time I'll nap with brownies in the oven. > > Maranatha! <>< > John McKown > > -- > 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 > -- I just burned 2000 calories! That's the last time I'll nap with brownies in the oven. Maranatha! <>< John McKown -- 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
Re: SMS QUESTION [EXTERNAL]
There is the 24 bit TIOT. That is limited in size. Depending on how many datasets you have allocated and how many volumes you allow the dataset(s) to expand to you can run out of 24 bit TIOT. All that said I've only seen the 24 bit TIOT space issue a few times. With the 31 bit TIOT the issue basically goes away. Thanks.. Paul Feller AGT Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Schramm Sent: Monday, February 18, 2019 12:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS QUESTION [EXTERNAL] There used to be an issue with below the line control blocks when having lots of eligible volumes that were not being used. Lots of vsam + lots of eligible volumes on the vsam definition leads to more storage being chewed up. Since i am experiencing a memory fault that seems unlikely to swap in, I will hope that this jogs someone else's memory Rob Schramm On Mon, Feb 18, 2019, 12:00 PM John McKown On Mon, Feb 18, 2019 at 10:57 AM esmie moo < > 012780d99c7b-dmarc-requ...@listserv.ua.edu> wrote: > > > Yes the dsn was reallocated. I tried out Dynamic Volume Count > > (Vroom had mentioned it) and I was able successfully run the job. > > It allocated > 37 > > vols.I am curious to try out your recommendation to use the ALTER. > > I assume I have to issued the command while the job is executing > > because if the job abends the dsn is deleted. Could you please > > confirm my understanding? > > > > Sorry, I didn't realise that the DSN was deleted at job end. The ALTER > won't help while the job is in execution. I sometimes use it for CICS > datasets, but CEMT SET CLOSE , do the ALTER, then CEMT SET OPEN. The > dataset must be closed and reopened to pick up the catalog entry changes. > > > > > Thanks. > > On Monday, February 18, 2019, 9:24:28 a.m. EST, John McKown < > > john.archie.mck...@gmail.com> wrote: > > > > On Mon, Feb 18, 2019 at 8:07 AM esmie moo < > > 012780d99c7b-dmarc-requ...@listserv.ua.edu> wrote: > > > > > Gentle Readers, > > > I encountered a problem with a space abend for a IAM VSAM EXTENDED > > > FORMAT.dsn. In the DATACLAS we have the Volume Count at 30 so I > changed > > it > > > to 40. I restarted the job however it abended at NUMBER OF > > > VOLUMES > 30.My > > > question Is what is the maximum number of volumes that cane be > allocated > > > via the SMS DATACLAS for the Volume Count? > > > > > > > Did you reallocate the DSN? The value for volume count is set from > > the DATACLAS at allocation time. Any changes to the DATACLAS after > > allocation are not used. The simpliest way to increase the volume count is > > to: > > > > ALTER <<>> ADDVOL(* * * * * * * * * *) > > > > Put in as many asterisks are you want extra volumes. > > > > > > > > > Thanks in advance. > > > > > > > > -- > > I just burned 2000 calories! > > That's the last time I'll nap with brownies in the oven. > > > > Maranatha! <>< > > John McKown > > > > > > -- 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 > > > > > -- > I just burned 2000 calories! > That's the last time I'll nap with brownies in the oven. > > Maranatha! <>< > John McKown > > -- > 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 -- Please note: This message originated outside your organization. Please use caution when opening links or attachments. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS QUESTION
There used to be an issue with below the line control blocks when having lots of eligible volumes that were not being used. Lots of vsam + lots of eligible volumes on the vsam definition leads to more storage being chewed up. Since i am experiencing a memory fault that seems unlikely to swap in, I will hope that this jogs someone else's memory Rob Schramm On Mon, Feb 18, 2019, 12:00 PM John McKown On Mon, Feb 18, 2019 at 10:57 AM esmie moo < > 012780d99c7b-dmarc-requ...@listserv.ua.edu> wrote: > > > Yes the dsn was reallocated. I tried out Dynamic Volume Count (Vroom > > had mentioned it) and I was able successfully run the job. It allocated > 37 > > vols.I am curious to try out your recommendation to use the ALTER. I > > assume I have to issued the command while the job is executing because if > > the job abends the dsn is deleted. Could you please confirm my > > understanding? > > > > Sorry, I didn't realise that the DSN was deleted at job end. The ALTER > won't help while the job is in execution. I sometimes use it for CICS > datasets, but CEMT SET CLOSE , do the ALTER, then CEMT SET OPEN. The > dataset must be closed and reopened to pick up the catalog entry changes. > > > > > Thanks. > > On Monday, February 18, 2019, 9:24:28 a.m. EST, John McKown < > > john.archie.mck...@gmail.com> wrote: > > > > On Mon, Feb 18, 2019 at 8:07 AM esmie moo < > > 012780d99c7b-dmarc-requ...@listserv.ua.edu> wrote: > > > > > Gentle Readers, > > > I encountered a problem with a space abend for a IAM VSAM EXTENDED > > > FORMAT.dsn. In the DATACLAS we have the Volume Count at 30 so I > changed > > it > > > to 40. I restarted the job however it abended at NUMBER OF VOLUMES > 30.My > > > question Is what is the maximum number of volumes that cane be > allocated > > > via the SMS DATACLAS for the Volume Count? > > > > > > > Did you reallocate the DSN? The value for volume count is set from the > > DATACLAS at allocation time. Any changes to the DATACLAS after allocation > > are not used. The simpliest way to increase the volume count is to: > > > > ALTER <<>> ADDVOL(* * * * * * * * * *) > > > > Put in as many asterisks are you want extra volumes. > > > > > > > > > Thanks in advance. > > > > > > > > -- > > I just burned 2000 calories! > > That's the last time I'll nap with brownies in the oven. > > > > Maranatha! <>< > > John McKown > > > > -- > > 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 > > > > > -- > I just burned 2000 calories! > That's the last time I'll nap with brownies in the oven. > > Maranatha! <>< > John McKown > > -- > 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
Re: SMS QUESTION
On Mon, Feb 18, 2019 at 10:57 AM esmie moo < 012780d99c7b-dmarc-requ...@listserv.ua.edu> wrote: > Yes the dsn was reallocated. I tried out Dynamic Volume Count (Vroom > had mentioned it) and I was able successfully run the job. It allocated 37 > vols.I am curious to try out your recommendation to use the ALTER. I > assume I have to issued the command while the job is executing because if > the job abends the dsn is deleted. Could you please confirm my > understanding? > Sorry, I didn't realise that the DSN was deleted at job end. The ALTER won't help while the job is in execution. I sometimes use it for CICS datasets, but CEMT SET CLOSE , do the ALTER, then CEMT SET OPEN. The dataset must be closed and reopened to pick up the catalog entry changes. > Thanks. > On Monday, February 18, 2019, 9:24:28 a.m. EST, John McKown < > john.archie.mck...@gmail.com> wrote: > > On Mon, Feb 18, 2019 at 8:07 AM esmie moo < > 012780d99c7b-dmarc-requ...@listserv.ua.edu> wrote: > > > Gentle Readers, > > I encountered a problem with a space abend for a IAM VSAM EXTENDED > > FORMAT.dsn. In the DATACLAS we have the Volume Count at 30 so I changed > it > > to 40. I restarted the job however it abended at NUMBER OF VOLUMES 30.My > > question Is what is the maximum number of volumes that cane be allocated > > via the SMS DATACLAS for the Volume Count? > > > > Did you reallocate the DSN? The value for volume count is set from the > DATACLAS at allocation time. Any changes to the DATACLAS after allocation > are not used. The simpliest way to increase the volume count is to: > > ALTER <<>> ADDVOL(* * * * * * * * * *) > > Put in as many asterisks are you want extra volumes. > > > > > Thanks in advance. > > > > > -- > I just burned 2000 calories! > That's the last time I'll nap with brownies in the oven. > > Maranatha! <>< > John McKown > > -- > 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 > -- I just burned 2000 calories! That's the last time I'll nap with brownies in the oven. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS QUESTION
Yes the dsn was reallocated. I tried out Dynamic Volume Count (Vroom had mentioned it) and I was able successfully run the job. It allocated 37 vols.I am curious to try out your recommendation to use the ALTER. I assume I have to issued the command while the job is executing because if the job abends the dsn is deleted. Could you please confirm my understanding? Thanks. On Monday, February 18, 2019, 9:24:28 a.m. EST, John McKown wrote: On Mon, Feb 18, 2019 at 8:07 AM esmie moo < 012780d99c7b-dmarc-requ...@listserv.ua.edu> wrote: > Gentle Readers, > I encountered a problem with a space abend for a IAM VSAM EXTENDED > FORMAT.dsn. In the DATACLAS we have the Volume Count at 30 so I changed it > to 40. I restarted the job however it abended at NUMBER OF VOLUMES 30.My > question Is what is the maximum number of volumes that cane be allocated > via the SMS DATACLAS for the Volume Count? > Did you reallocate the DSN? The value for volume count is set from the DATACLAS at allocation time. Any changes to the DATACLAS after allocation are not used. The simpliest way to increase the volume count is to: ALTER <<>> ADDVOL(* * * * * * * * * *) Put in as many asterisks are you want extra volumes. > Thanks in advance. > > -- I just burned 2000 calories! That's the last time I'll nap with brownies in the oven. Maranatha! <>< John McKown -- 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
Re: SMS QUESTION
Just asking, you did do the validate and activate? Doug . On Feb 18, 2019, at 09:32, Vernooij, Kees (ITOP NM) - KLM wrote: The statement that the DC is never used again after allocation was true, until Dynamic Volume Count was introduced. A Data set allocated with a DC with a DYNVOL COUNT value will honor changes in this DC. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of John McKown > Sent: 18 February, 2019 15:24 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMS QUESTION > > On Mon, Feb 18, 2019 at 8:07 AM esmie moo < > 012780d99c7b-dmarc-requ...@listserv.ua.edu> wrote: > >> Gentle Readers, >> I encountered a problem with a space abend for a IAM VSAM EXTENDED >> FORMAT.dsn. In the DATACLAS we have the Volume Count at 30 so I > changed it >> to 40. I restarted the job however it abended at NUMBER OF VOLUMES > 30.My >> question Is what is the maximum number of volumes that cane be > allocated >> via the SMS DATACLAS for the Volume Count? >> > > Did you reallocate the DSN? The value for volume count is set from the > DATACLAS at allocation time. Any changes to the DATACLAS after > allocation > are not used. The simpliest way to increase the volume count is to: > > ALTER <<>> ADDVOL(* * * * * * * * * *) > > Put in as many asterisks are you want extra volumes. > > > >> Thanks in advance. >> >> > -- > I just burned 2000 calories! > That's the last time I'll nap with brownies in the oven. > > Maranatha! <>< > John McKown > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- 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
Re: SMS QUESTION
The statement that the DC is never used again after allocation was true, until Dynamic Volume Count was introduced. A Data set allocated with a DC with a DYNVOL COUNT value will honor changes in this DC. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of John McKown > Sent: 18 February, 2019 15:24 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMS QUESTION > > On Mon, Feb 18, 2019 at 8:07 AM esmie moo < > 012780d99c7b-dmarc-requ...@listserv.ua.edu> wrote: > > > Gentle Readers, > > I encountered a problem with a space abend for a IAM VSAM EXTENDED > > FORMAT.dsn. In the DATACLAS we have the Volume Count at 30 so I > changed it > > to 40. I restarted the job however it abended at NUMBER OF VOLUMES > 30.My > > question Is what is the maximum number of volumes that cane be > allocated > > via the SMS DATACLAS for the Volume Count? > > > > Did you reallocate the DSN? The value for volume count is set from the > DATACLAS at allocation time. Any changes to the DATACLAS after > allocation > are not used. The simpliest way to increase the volume count is to: > > ALTER <<>> ADDVOL(* * * * * * * * * *) > > Put in as many asterisks are you want extra volumes. > > > > > Thanks in advance. > > > > > -- > I just burned 2000 calories! > That's the last time I'll nap with brownies in the oven. > > Maranatha! <>< > John McKown > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS QUESTION
59 -Original Message- From: IBM Mainframe Discussion List On Behalf Of esmie moo Sent: Monday, February 18, 2019 8:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMS QUESTION Gentle Readers, I encountered a problem with a space abend for a IAM VSAM EXTENDED FORMAT.dsn. In the DATACLAS we have the Volume Count at 30 so I changed it to 40. I restarted the job however it abended at NUMBER OF VOLUMES 30.My question Is what is the maximum number of volumes that cane be allocated via the SMS DATACLAS for the Volume Count? Thanks in advance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS QUESTION
On Mon, Feb 18, 2019 at 8:07 AM esmie moo < 012780d99c7b-dmarc-requ...@listserv.ua.edu> wrote: > Gentle Readers, > I encountered a problem with a space abend for a IAM VSAM EXTENDED > FORMAT.dsn. In the DATACLAS we have the Volume Count at 30 so I changed it > to 40. I restarted the job however it abended at NUMBER OF VOLUMES 30.My > question Is what is the maximum number of volumes that cane be allocated > via the SMS DATACLAS for the Volume Count? > Did you reallocate the DSN? The value for volume count is set from the DATACLAS at allocation time. Any changes to the DATACLAS after allocation are not used. The simpliest way to increase the volume count is to: ALTER <<>> ADDVOL(* * * * * * * * * *) Put in as many asterisks are you want extra volumes. > Thanks in advance. > > -- I just burned 2000 calories! That's the last time I'll nap with brownies in the oven. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SMS QUESTION
Gentle Readers, I encountered a problem with a space abend for a IAM VSAM EXTENDED FORMAT.dsn. In the DATACLAS we have the Volume Count at 30 so I changed it to 40. I restarted the job however it abended at NUMBER OF VOLUMES 30.My question Is what is the maximum number of volumes that cane be allocated via the SMS DATACLAS for the Volume Count? Thanks in advance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM/SMS QUESTION - SPACE MANAGEMENT
There is no HSM backup taken for this storage group. On Fri, 1/15/16, Gibney, David Allen,Jr <gib...@wsu.edu> wrote: Subject: Re: DFHSM/SMS QUESTION - SPACE MANAGEMENT To: IBM-MAIN@LISTSERV.UA.EDU Received: Friday, January 15, 2016, 8:06 PM What about back up? > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of willie bunter > Sent: Friday, January 15, 2016 4:07 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM/SMS QUESTION - SPACE MANAGEMENT > > Migrate the dsn after 10 days of non-usage. > > > On Thu, 1/14/16, Lizette Koehler <stars...@mindspring.com> wrote: > > Subject: Re: DFHSM/SMS QUESTION - SPACE MANAGEMENT > To: IBM-MAIN@LISTSERV.UA.EDU > Received: Thursday, January 14, 2016, 1:52 PM > > What does your management > class for this dataset say as well as the HSM policy? > > Lizette > > > > -Original Message- > > From: IBM Mainframe Discussion List > [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On > > Behalf Of willie bunter > > Sent: Thursday, January 14, 2016 10:53 AM > To: IBM- > m...@listserv.ua.edu > Subject: Re: DFHSM/SMS QUESTION - SPACE > MANAGEMENT > > Lizette, > > Thanks for the info. For this dsn in > particular there is no migration it is > to be expired/deleted after 1 day of > non-usage. > > > > You have touched on the point of space management algorithms for > migration. I > assume that this would also pertain to the deletion of files as > well. Right? > > > > > > > On Thu, 1/14/16, Lizette Koehler <stars...@mindspring.com> > wrote: > > > > Subject: > Re: DFHSM/SMS QUESTION - SPACE MANAGEMENT > To: IBM- > m...@listserv.ua.edu > Received: Thursday, January 14, 2016, > 12:45 PM > > > > So > depending on the > > version of z/OS - > look at On Demand Migration (v2.1 and above), this might > help more > > > > Second, correct, files are only > moved if DFHSM feels the volume needs to > have the space back, however, > you could have a migration policy in the > management class that says - if > this is still on DASD after 1 month, then > migrate the file. > > > > It > depends on > > what your requirements > are. You can just let files migrate as HSM sees fit > based on its algorithms > for space management, or you can setup a management > class that says > it gets migrated if unused in XX days. > > > > Many choices. > > > > Lizette > > > > > > > > -Original Message- > > > From: > IBM > > Mainframe Discussion List > [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On > Behalf Of > > willie bunter > > Sent: Thursday, January 14, 2016 10:23 AM > To: > IBM- > > m...@listserv.ua.edu > > Subject: DFHSM/SMS QUESTION - SPACE MANAGEMENT > > > Good Day > To All, > > I need to confirm if I my understanding about SMS & > > SPACE management is > correct. > > > We have noticed that > there are several dsns which have been on dasd for > over > > 10 > months. The volumes and dsns are all SMS managed and DFHSM performs > the > > necessary migration and deletion. I checked the MANAGEMENT > class and the > dsns > are to be deleted after 1 day non-usage > > > Expire after Days > Non- > > usage . : 1 > Expire > after Date/Days . . . . : 1 > Retention > Limit . . . . . . . > : > > 0 > > > > > > Below > are the > > attributes of the Storage > Group: > > > > > > > > > > Allocation/migration > > Threshold : High > > 85 (1-100) Low . . 1 > > > > > (0-99) > > > Alloc/Migr Threshold > > Track-Managed: High > 85 (1-100) Low . . 1 (0- > > 99) > Guaranteed > > Backup > Frequency . . . . . > > . > (1 to or > > > > NOLIMIT) > > > > > > BreakPointValue . . . . . . . . . . . . > > > (0-65520 > > > or > blank) > > > Processing > > Priority . . . . .
Re: DFHSM/SMS QUESTION - SPACE MANAGEMENT
This storage group is selected for space management. Thanks for the tip about the patch. I will try that out. On Fri, 1/15/16, Glenn Wilcock <wilc...@us.ibm.com> wrote: Subject: Re: DFHSM/SMS QUESTION - SPACE MANAGEMENT To: IBM-MAIN@LISTSERV.UA.EDU Received: Friday, January 15, 2016, 10:31 AM Hi, a couple of other things to look at: (1) Verify that the volume is being selected for space management. As indicated, HSM doesn't process data sets on a volume unless the volume exceeds its high threshold. Once a volume is selected, HSM will process all eligible data sets on that volume until the low threshold is reached. (2) Enable PATCH .MGCB.+26 X’FF’, which indicates that HSM should issue additional ARC0734I messages to indicate why data sets weren't selected for processing. (This patch is documented in the DFSMShsm Diagnosis manual). Glenn Wilcock DFSMShsm Architect -- 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
Re: DFHSM/SMS QUESTION - SPACE MANAGEMENT
I stand corrected. There is a backup done for this storage group. On Fri, 1/15/16, Gonzalo Cengotita <gonzaloce...@gmail.com> wrote: Subject: Re: DFHSM/SMS QUESTION - SPACE MANAGEMENT To: IBM-MAIN@LISTSERV.UA.EDU Received: Friday, January 15, 2016, 3:31 AM Hi If the those file's Management class has the "Auto backup" set to YES but the storage Group has the "Auto Backup" set to NO you will find an error in your HSM log saying the dataset cannot be removed because is in need of a backup. Those messages are in the HSM MIGLOG in the records headed ACTION=EXPIRED or SPCMGMT, (RC=53). Regards, Gonzalo Cengotita *Gonzalo Cengotita* 2016-01-14 21:18 GMT+01:00 Gibney, David Allen,Jr <gib...@wsu.edu>: > Also, what are the actual dataset attributes? DFHSM doesn't do some > "incomplete" datasets. Are they backed up. DFHSM often doesn't delete if > there is not a back-up. > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of willie bunter > > Sent: Thursday, January 14, 2016 9:53 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: DFHSM/SMS QUESTION - SPACE MANAGEMENT > > > > Lizette, > > > > Thanks for the info. For this dsn in particular there is no migration > it is to be > > expired/deleted after 1 day of non-usage. > > > > You have touched on the point of space management algorithms for > > migration. I assume that this would also pertain to the deletion of > files as > > well. Right? > > > > > > On Thu, 1/14/16, Lizette Koehler <stars...@mindspring.com> wrote: > > > > Subject: Re: DFHSM/SMS QUESTION - SPACE MANAGEMENT > > To: IBM-MAIN@LISTSERV.UA.EDU > > Received: Thursday, January 14, 2016, 12:45 PM > > > > So depending on the > > version of z/OS - look at On Demand Migration (v2.1 and above), this > might > > help more > > > > Second, correct, files are only moved if DFHSM feels the volume needs > to > > have the space back, however, you could have a migration policy in the > > management class that says - if this is still on DASD after 1 month, > then > > migrate the file. > > > > It depends on > > what your requirements are. You can just let files migrate as HSM > sees fit > > based on its algorithms for space management, or you can setup a > > management class that says it gets migrated if unused in XX days. > > > > Many choices. > > > > Lizette > > > > > > > -Original Message- > > > From: IBM > > Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > > Behalf Of willie bunter > Sent: Thursday, January 14, 2016 10:23 AM > > To: > > IBM-MAIN@LISTSERV.UA.EDU > Subject: DFHSM/SMS QUESTION - SPACE > > MANAGEMENT > > Good Day To All, > > I need to confirm if I my > > understanding about SMS & SPACE management is > correct. > > > We have noticed that there are several dsns which have been on dasd > for > > over > > > 10 months. The volumes and dsns are all SMS managed and DFHSM > > performs the > necessary migration and deletion. I checked the > > MANAGEMENT class and the dsns > are to be deleted after 1 day > non-usage > > > > Expire after Days Non-usage . : 1 > Expire after Date/Days . . > . . : 1 > > > Retention Limit . . . . . . . : > > 0 > > > > > > Below are the > > attributes of the Storage Group: > > > > > > > > > Allocation/migration > > Threshold : High > > 85 (1-100) Low . . 1 > > > > > (0-99) > > > Alloc/Migr Threshold > > Track-Managed: High 85 (1-100) Low . . 1 (0- > 99) > > Guaranteed > > Backup Frequency . . . . . > > . (1 to or > > > NOLIMIT) > > > > > BreakPointValue . . . . . . . . . . . . > > (0-65520 > > > or blank) > > > Processing > > Priority . . . . . . . . . . 50 > > (1-100) > > > > > > I think that the dsns are not deleted because SMS did not select > some of > > these > volumes have not
Re: DFHSM/SMS QUESTION - SPACE MANAGEMENT
Hi, a couple of other things to look at: (1) Verify that the volume is being selected for space management. As indicated, HSM doesn't process data sets on a volume unless the volume exceeds its high threshold. Once a volume is selected, HSM will process all eligible data sets on that volume until the low threshold is reached. (2) Enable PATCH .MGCB.+26 X’FF’, which indicates that HSM should issue additional ARC0734I messages to indicate why data sets weren't selected for processing. (This patch is documented in the DFSMShsm Diagnosis manual). Glenn Wilcock DFSMShsm Architect -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM/SMS QUESTION - SPACE MANAGEMENT
Migrate the dsn after 10 days of non-usage. On Thu, 1/14/16, Lizette Koehler <stars...@mindspring.com> wrote: Subject: Re: DFHSM/SMS QUESTION - SPACE MANAGEMENT To: IBM-MAIN@LISTSERV.UA.EDU Received: Thursday, January 14, 2016, 1:52 PM What does your management class for this dataset say as well as the HSM policy? Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of willie bunter > Sent: Thursday, January 14, 2016 10:53 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM/SMS QUESTION - SPACE MANAGEMENT > > Lizette, > > Thanks for the info. For this dsn in particular there is no migration it is > to be expired/deleted after 1 day of non-usage. > > You have touched on the point of space management algorithms for migration. I > assume that this would also pertain to the deletion of files as well. Right? > > > On Thu, 1/14/16, Lizette Koehler <stars...@mindspring.com> wrote: > > Subject: Re: DFHSM/SMS QUESTION - SPACE MANAGEMENT > To: IBM-MAIN@LISTSERV.UA.EDU > Received: Thursday, January 14, 2016, 12:45 PM > > So depending on the > version of z/OS - look at On Demand Migration (v2.1 and above), this might > help more > > Second, correct, files are only moved if DFHSM feels the volume needs to > have the space back, however, you could have a migration policy in the > management class that says - if this is still on DASD after 1 month, then > migrate the file. > > It depends on > what your requirements are. You can just let files migrate as HSM sees fit > based on its algorithms for space management, or you can setup a management > class that says it gets migrated if unused in XX days. > > Many choices. > > Lizette > > > > -Original Message- > > From: IBM > Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of > willie bunter > Sent: Thursday, January 14, 2016 10:23 AM > To: IBM- > m...@listserv.ua.edu > Subject: DFHSM/SMS QUESTION - SPACE MANAGEMENT > > > Good Day To All, > > I need to confirm if I my understanding about SMS & > SPACE management is > correct. > > We have noticed that there are several dsns which have been on dasd for > over > > 10 months. The volumes and dsns are all SMS managed and DFHSM performs the > > necessary migration and deletion. I checked the MANAGEMENT class and the > dsns > are to be deleted after 1 day non-usage > > Expire after Days Non- > usage . : 1 > Expire after Date/Days . . . . : 1 > Retention > Limit . . . . . . . : > 0 > > > > Below are the > attributes of the Storage Group: > > > > > > Allocation/migration > Threshold : High > 85 (1-100) Low . . 1 > > > (0-99) > > Alloc/Migr Threshold > Track-Managed: High 85 (1-100) Low . . 1 (0- > 99) > Guaranteed > Backup Frequency . . . . . > . (1 to or > > NOLIMIT) > > > BreakPointValue . . . . . . . . . . . . > (0-65520 > > or blank) > > Processing > Priority . . . . . . . . . . 50 > (1-100) > > > > I think that the dsns are not deleted because SMS did not select some of > these > volumes have not met the criteria of the Low threshold of 1. I > remember > reading somewhere (on this board the following): > > > > For primary space > management, HSM only looks at the low threshold. If the > volume exceeds the > low threshold, then we will process any data sets that are > eligible for > migration on that volume. > > > > > Could someone confirm if I am > correct? > > > > > Thanks. -- 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
Re: DFHSM/SMS QUESTION - SPACE MANAGEMENT
What about back up? > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of willie bunter > Sent: Friday, January 15, 2016 4:07 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM/SMS QUESTION - SPACE MANAGEMENT > > Migrate the dsn after 10 days of non-usage. > > > On Thu, 1/14/16, Lizette Koehler <stars...@mindspring.com> wrote: > > Subject: Re: DFHSM/SMS QUESTION - SPACE MANAGEMENT > To: IBM-MAIN@LISTSERV.UA.EDU > Received: Thursday, January 14, 2016, 1:52 PM > > What does your management > class for this dataset say as well as the HSM policy? > > Lizette > > > > -Original Message- > > From: IBM Mainframe Discussion List > [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On > > Behalf Of willie bunter > > Sent: Thursday, January 14, 2016 10:53 AM > To: IBM- > m...@listserv.ua.edu > Subject: Re: DFHSM/SMS QUESTION - SPACE > MANAGEMENT > > Lizette, > > Thanks for the info. For this dsn in > particular there is no migration it is > to be expired/deleted after 1 day > of > non-usage. > > > > You have touched on the point of space management algorithms for > migration. I > assume that this would also pertain to the deletion of > files as > well. Right? > > > > > > > On Thu, 1/14/16, Lizette Koehler <stars...@mindspring.com> > wrote: > > > > Subject: > Re: DFHSM/SMS QUESTION - SPACE MANAGEMENT > To: IBM- > m...@listserv.ua.edu > Received: Thursday, January 14, 2016, > 12:45 PM > > > > So > depending on the > > version of z/OS - > look at On Demand Migration (v2.1 and above), this might > help more > > > > Second, correct, files are only > moved if DFHSM feels the volume needs to > have the space back, however, > you could have a migration policy in the > management class that says - > if > this is still on DASD after 1 month, then > migrate the file. > > > > It > depends on > > what your requirements > are. You can just let files migrate as HSM sees fit > based on its > algorithms > for space management, or you can setup a management > class that says > it gets migrated if unused in XX days. > > > > Many choices. > > > > Lizette > > > > > > > > -Original Message- > > > From: > IBM > > Mainframe Discussion List > [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On > Behalf Of > > willie bunter > > Sent: Thursday, January 14, 2016 10:23 AM > To: > IBM- > > m...@listserv.ua.edu > > Subject: DFHSM/SMS QUESTION - SPACE MANAGEMENT > > > Good Day > To All, > > I need to confirm if I my understanding about SMS & > > SPACE management is > correct. > > > We have noticed that > there are several dsns which have been on dasd for > over > > 10 > months. The volumes and dsns are all SMS managed and DFHSM performs > the > > necessary migration and deletion. I checked the MANAGEMENT > class and the > dsns > are to be deleted after 1 day non-usage > > > Expire after Days > Non- > > usage . : 1 > Expire > after Date/Days . . . . : 1 > Retention > Limit . . . . . . . > : > > 0 > > > > > > Below > are the > > attributes of the Storage > Group: > > > > > > > > > > Allocation/migration > > Threshold : High > > 85 (1-100) Low . . 1 > > > > > (0-99) > > > Alloc/Migr Threshold > > Track-Managed: High > 85 (1-100) Low . . 1 (0- > > 99) > Guaranteed > > Backup > Frequency . . . . . > > . > (1 to or > > > > NOLIMIT) > > > > > > BreakPointValue . . . . . . . . . . . . > > > (0-65520 > > > or > blank) > > > Processing > > Priority . . . . . . . . . . 50 > > (1-100) > > > > > > I think > that the dsns are not deleted because SMS did not select some of > these > > > volumes have not met the criteria of the Low threshold of 1. I > > remember > reading somewhere (on this board the following): > > > > > > For primary space > > management, HSM only looks at the low threshold. If the > volume > exceeds the >
Re: DFHSM/SMS QUESTION - SPACE MANAGEMENT
Lizette, Thanks for the info. For this dsn in particular there is no migration it is to be expired/deleted after 1 day of non-usage. You have touched on the point of space management algorithms for migration. I assume that this would also pertain to the deletion of files as well. Right? On Thu, 1/14/16, Lizette Koehler <stars...@mindspring.com> wrote: Subject: Re: DFHSM/SMS QUESTION - SPACE MANAGEMENT To: IBM-MAIN@LISTSERV.UA.EDU Received: Thursday, January 14, 2016, 12:45 PM So depending on the version of z/OS - look at On Demand Migration (v2.1 and above), this might help more Second, correct, files are only moved if DFHSM feels the volume needs to have the space back, however, you could have a migration policy in the management class that says - if this is still on DASD after 1 month, then migrate the file. It depends on what your requirements are. You can just let files migrate as HSM sees fit based on its algorithms for space management, or you can setup a management class that says it gets migrated if unused in XX days. Many choices. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of willie bunter > Sent: Thursday, January 14, 2016 10:23 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: DFHSM/SMS QUESTION - SPACE MANAGEMENT > > Good Day To All, > > I need to confirm if I my understanding about SMS & SPACE management is > correct. > We have noticed that there are several dsns which have been on dasd for over > 10 months. The volumes and dsns are all SMS managed and DFHSM performs the > necessary migration and deletion. I checked the MANAGEMENT class and the dsns > are to be deleted after 1 day non-usage > > Expire after Days Non-usage . : 1 > Expire after Date/Days . . . . : 1 > Retention Limit . . . . . . . : 0 > > Below are the attributes of the Storage Group: > > > Allocation/migration Threshold : High 85 (1-100) Low . . 1 > (0-99) > Alloc/Migr Threshold Track-Managed: High 85 (1-100) Low . . 1 (0- > 99) > Guaranteed Backup Frequency . . . . . . (1 to or > NOLIMIT) > BreakPointValue . . . . . . . . . . . . (0-65520 > or blank) > Processing Priority . . . . . . . . . . 50 (1-100) > > I think that the dsns are not deleted because SMS did not select some of these > volumes have not met the criteria of the Low threshold of 1. I remember > reading somewhere (on this board the following): > > For primary space management, HSM only looks at the low threshold. If the > volume exceeds the low threshold, then we will process any data sets that are > eligible for migration on that volume. > > Could someone confirm if I am correct? > > Thanks. -- 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
DFHSM/SMS QUESTION - SPACE MANAGEMENT
Good Day To All, I need to confirm if I my understanding about SMS & SPACE management is correct. We have noticed that there are several dsns which have been on dasd for over 10 months. The volumes and dsns are all SMS managed and DFHSM performs the necessary migration and deletion. I checked the MANAGEMENT class and the dsns are to be deleted after 1 day non-usage Expire after Days Non-usage . : 1 Expire after Date/Days . . . . : 1 Retention Limit . . . . . . . : 0 Below are the attributes of the Storage Group: Allocation/migration Threshold :High85 (1-100) Low . . 1 (0-99) Alloc/Migr Threshold Track-Managed: High85 (1-100)Low . . 1 (0-99) Guaranteed Backup Frequency . . . . . . (1 to or NOLIMIT) BreakPointValue . . . . . . . . . . . . (0-65520 or blank) Processing Priority . . . . . . . . . . 50 (1-100) I think that the dsns are not deleted because SMS did not select some of these volumes have not met the criteria of the Low threshold of 1. I remember reading somewhere (on this board the following): For primary space management, HSM only looks at the low threshold. If the volume exceeds the low threshold, then we will process any data sets that are eligible for migration on that volume. Could someone confirm if I am correct? Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM/SMS QUESTION - SPACE MANAGEMENT
So depending on the version of z/OS - look at On Demand Migration (v2.1 and above), this might help more Second, correct, files are only moved if DFHSM feels the volume needs to have the space back, however, you could have a migration policy in the management class that says - if this is still on DASD after 1 month, then migrate the file. It depends on what your requirements are. You can just let files migrate as HSM sees fit based on its algorithms for space management, or you can setup a management class that says it gets migrated if unused in XX days. Many choices. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of willie bunter > Sent: Thursday, January 14, 2016 10:23 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: DFHSM/SMS QUESTION - SPACE MANAGEMENT > > Good Day To All, > > I need to confirm if I my understanding about SMS & SPACE management is > correct. > We have noticed that there are several dsns which have been on dasd for over > 10 months. The volumes and dsns are all SMS managed and DFHSM performs the > necessary migration and deletion. I checked the MANAGEMENT class and the dsns > are to be deleted after 1 day non-usage > > Expire after Days Non-usage . : 1 > Expire after Date/Days . . . . : 1 > Retention Limit . . . . . . . : 0 > > Below are the attributes of the Storage Group: > > > Allocation/migration Threshold :High85 (1-100) Low . . 1 > (0-99) > Alloc/Migr Threshold Track-Managed: High85 (1-100)Low . . 1 (0- > 99) > Guaranteed Backup Frequency . . . . . . (1 to or > NOLIMIT) > BreakPointValue . . . . . . . . . . . . (0-65520 > or blank) > Processing Priority . . . . . . . . . . 50 (1-100) > > I think that the dsns are not deleted because SMS did not select some of these > volumes have not met the criteria of the Low threshold of 1. I remember > reading somewhere (on this board the following): > > For primary space management, HSM only looks at the low threshold. If the > volume exceeds the low threshold, then we will process any data sets that are > eligible for migration on that volume. > > Could someone confirm if I am correct? > > Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM/SMS QUESTION - SPACE MANAGEMENT
Also, what are the actual dataset attributes? DFHSM doesn't do some "incomplete" datasets. Are they backed up. DFHSM often doesn't delete if there is not a back-up. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of willie bunter > Sent: Thursday, January 14, 2016 9:53 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM/SMS QUESTION - SPACE MANAGEMENT > > Lizette, > > Thanks for the info. For this dsn in particular there is no migration it is > to be > expired/deleted after 1 day of non-usage. > > You have touched on the point of space management algorithms for > migration. I assume that this would also pertain to the deletion of files as > well. Right? > > > On Thu, 1/14/16, Lizette Koehler <stars...@mindspring.com> wrote: > > Subject: Re: DFHSM/SMS QUESTION - SPACE MANAGEMENT > To: IBM-MAIN@LISTSERV.UA.EDU > Received: Thursday, January 14, 2016, 12:45 PM > > So depending on the > version of z/OS - look at On Demand Migration (v2.1 and above), this might > help more > > Second, correct, files are only moved if DFHSM feels the volume needs to > have the space back, however, you could have a migration policy in the > management class that says - if this is still on DASD after 1 month, then > migrate the file. > > It depends on > what your requirements are. You can just let files migrate as HSM sees fit > based on its algorithms for space management, or you can setup a > management class that says it gets migrated if unused in XX days. > > Many choices. > > Lizette > > > > -Original Message- > > From: IBM > Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of willie bunter > Sent: Thursday, January 14, 2016 10:23 AM > To: > IBM-MAIN@LISTSERV.UA.EDU > Subject: DFHSM/SMS QUESTION - SPACE > MANAGEMENT > > Good Day To All, > > I need to confirm if I my > understanding about SMS & SPACE management is > correct. > > We have noticed that there are several dsns which have been on dasd for > over > > 10 months. The volumes and dsns are all SMS managed and DFHSM > performs the > necessary migration and deletion. I checked the > MANAGEMENT class and the dsns > are to be deleted after 1 day non-usage > > > Expire after Days Non-usage . : 1 > Expire after Date/Days . . . . > > : 1 > > Retention Limit . . . . . . . : > 0 > > > > Below are the > attributes of the Storage Group: > > > > > > Allocation/migration > Threshold : High > 85 (1-100) Low . . 1 > > > (0-99) > > Alloc/Migr Threshold > Track-Managed: High 85 (1-100) Low . . 1 (0- > 99) > Guaranteed > Backup Frequency . . . . . > . (1 to or > > NOLIMIT) > > > BreakPointValue . . . . . . . . . . . . > (0-65520 > > or blank) > > Processing > Priority . . . . . . . . . . 50 > (1-100) > > > > I think that the dsns are not deleted because SMS did not select some of > these > volumes have not met the criteria of the Low threshold of 1. I > remember > reading somewhere (on this board the following): > > > > For primary space > management, HSM only looks at the low threshold. If the > volume exceeds > the low threshold, then we will process any data sets that are > eligible > for > migration on that volume. > > > > > Could someone confirm if I am > correct? > > > > > Thanks. > > -- > 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
Re: DFHSM/SMS QUESTION - SPACE MANAGEMENT
What does your management class for this dataset say as well as the HSM policy? Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of willie bunter > Sent: Thursday, January 14, 2016 10:53 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM/SMS QUESTION - SPACE MANAGEMENT > > Lizette, > > Thanks for the info. For this dsn in particular there is no migration it is > to be expired/deleted after 1 day of non-usage. > > You have touched on the point of space management algorithms for migration. I > assume that this would also pertain to the deletion of files as well. Right? > > > On Thu, 1/14/16, Lizette Koehler <stars...@mindspring.com> wrote: > > Subject: Re: DFHSM/SMS QUESTION - SPACE MANAGEMENT > To: IBM-MAIN@LISTSERV.UA.EDU > Received: Thursday, January 14, 2016, 12:45 PM > > So depending on the > version of z/OS - look at On Demand Migration (v2.1 and above), this might > help more > > Second, correct, files are only moved if DFHSM feels the volume needs to > have the space back, however, you could have a migration policy in the > management class that says - if this is still on DASD after 1 month, then > migrate the file. > > It depends on > what your requirements are. You can just let files migrate as HSM sees fit > based on its algorithms for space management, or you can setup a management > class that says it gets migrated if unused in XX days. > > Many choices. > > Lizette > > > > -Original Message- > > From: IBM > Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of > willie bunter > Sent: Thursday, January 14, 2016 10:23 AM > To: IBM- > m...@listserv.ua.edu > Subject: DFHSM/SMS QUESTION - SPACE MANAGEMENT > > > Good Day To All, > > I need to confirm if I my understanding about SMS & > SPACE management is > correct. > > We have noticed that there are several dsns which have been on dasd for > over > > 10 months. The volumes and dsns are all SMS managed and DFHSM performs the > > necessary migration and deletion. I checked the MANAGEMENT class and the > dsns > are to be deleted after 1 day non-usage > > Expire after Days Non- > usage . : 1 > Expire after Date/Days . . . . : 1 > Retention > Limit . . . . . . . : > 0 > > > > Below are the > attributes of the Storage Group: > > > > > > Allocation/migration > Threshold :High > 85 (1-100) Low . . 1 > > > (0-99) > > Alloc/Migr Threshold > Track-Managed: High85 (1-100)Low . . 1 (0- > 99) > Guaranteed > Backup Frequency . . . . . > . (1 to or > > NOLIMIT) > > > BreakPointValue . . . . . . . . . . . . > (0-65520 > > or blank) > > Processing > Priority . . . . . . . . . . 50 > (1-100) > > > > I think that the dsns are not deleted because SMS did not select some of > these > volumes have not met the criteria of the Low threshold of 1. I > remember > reading somewhere (on this board the following): > > > > For primary space > management, HSM only looks at the low threshold. If the > volume exceeds the > low threshold, then we will process any data sets that are > eligible for > migration on that volume. > > > > > Could someone confirm if I am > correct? > > > > > Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SMS Question
Hello; I am relatively new to SMS, and rather ignorant (read: uneducated) about how it fully works. I'm learning more and more by reading, but I've hit an issue which I can't find a quick solution to using google or finding in the manuals. We just set up a new SANDBOX system, and set up SMS from scratch. When we dump with ADRDSSU some datasets (from a production lpar) to be restored to the Sandbox LPAR, we are getting errors where it is trying to select the volume that it came from (which is not online on the Sandbox). Shouldn't SMS be choosing a volume based on the ACS routines of the Sandbox system? What are we missing? Thanks in advance. Thanks; Nathan Pfister zOS Systems Programmer AES\PHEAA - Tech Services npfis...@aessuccess.org This message contains privileged and confidential information intended for the above addressees only. If you receive this message in error please delete or destroy this message and/or attachments. The sender of this message will fully cooperate in the civil and criminal prosecution of any individual engaging in the unauthorized use of this message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS Question
Show us your JCL , Did you tried putting the STORCLAS,MGMTCLAS(for the target System) where you are trying to restore... I think your JCL should give us some hints on where you are missing On Fri, Mar 21, 2014 at 8:06 PM, Nathan J Pfister npfis...@aessuccess.orgwrote: Hello; I am relatively new to SMS, and rather ignorant (read: uneducated) about how it fully works. I'm learning more and more by reading, but I've hit an issue which I can't find a quick solution to using google or finding in the manuals. We just set up a new SANDBOX system, and set up SMS from scratch. When we dump with ADRDSSU some datasets (from a production lpar) to be restored to the Sandbox LPAR, we are getting errors where it is trying to select the volume that it came from (which is not online on the Sandbox). Shouldn't SMS be choosing a volume based on the ACS routines of the Sandbox system? What are we missing? Thanks in advance. Thanks; Nathan Pfister zOS Systems Programmer AES\PHEAA - Tech Services npfis...@aessuccess.org This message contains privileged and confidential information intended for the above addressees only. If you receive this message in error please delete or destroy this message and/or attachments. The sender of this message will fully cooperate in the civil and criminal prosecution of any individual engaging in the unauthorized use of this message. -- 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
Re: SMS Question
I think I know what you run into: are the errors related to authorization? DFDSS has a very irritating habit to do something with the original volser if it is online. If you make sure the original volser from the production lpar is offline on your sandbox lpar, it should work. Of course supposing that the ACS routines will supply a storage group to the dataset to be restored. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Nathan J Pfister Sent: Friday, March 21, 2014 15:36 To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMS Question Hello; I am relatively new to SMS, and rather ignorant (read: uneducated) about how it fully works. I'm learning more and more by reading, but I've hit an issue which I can't find a quick solution to using google or finding in the manuals. We just set up a new SANDBOX system, and set up SMS from scratch. When we dump with ADRDSSU some datasets (from a production lpar) to be restored to the Sandbox LPAR, we are getting errors where it is trying to select the volume that it came from (which is not online on the Sandbox). Shouldn't SMS be choosing a volume based on the ACS routines of the Sandbox system? What are we missing? Thanks in advance. Thanks; Nathan Pfister zOS Systems Programmer AES\PHEAA - Tech Services npfis...@aessuccess.org This message contains privileged and confidential information intended for the above addressees only. If you receive this message in error please delete or destroy this message and/or attachments. The sender of this message will fully cooperate in the civil and criminal prosecution of any individual engaging in the unauthorized use of this message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS Question
Nathan J Pfister wrote: I am relatively new to SMS, and rather ignorant (read: uneducated) about how it fully works. Like the rest of us... ;-D When we dump with ADRDSSU some datasets (from a production lpar) to be restored to the Sandbox LPAR, we are getting errors where it is trying to select the volume that it came from (which is not online on the Sandbox). What type of dump was done in the first place? Logical or Physcial. Please post these: dump job, restore job and ALL error message(s) in Job and on SYSLOG. (Perhaps you could post the results of the Dump too if you can.) Shouldn't SMS be choosing a volume based on the ACS routines of the Sandbox system? Yes, but it depends on how you dumped/restore in the first place. Anything is possible: RACF blocking you, your statements causing dataset/volser not being selected, naming standards, etc. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS Question
It would be helpful for you to include Level of z/OS Complete error message Complete control cards. If you show us what you are doing, it will help us provide better answers. Also, what DASD/TAPE hardware are you using? Do you only have DFDSS? Or is FDR or other product available to you? Is your sandbox totally isolated from your production? If not, are you sharing the dasd and tape? What SAF are you using? RACF, TSS, ACF2? Is this shared or separated between Sandbox and Production? Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Nathan J Pfister Sent: Friday, March 21, 2014 7:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMS Question Hello; I am relatively new to SMS, and rather ignorant (read: uneducated) about how it fully works. I'm learning more and more by reading, but I've hit an issue which I can't find a quick solution to using google or finding in the manuals. We just set up a new SANDBOX system, and set up SMS from scratch. When we dump with ADRDSSU some datasets (from a production lpar) to be restored to the Sandbox LPAR, we are getting errors where it is trying to select the volume that it came from (which is not online on the Sandbox). Shouldn't SMS be choosing a volume based on the ACS routines of the Sandbox system? What are we missing? Thanks in advance. Thanks; Nathan Pfister zOS Systems Programmer AES\PHEAA - Tech Services -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS Question
z/OS 1.12 We get the following not telling it where to go: ADR405E (001)-DYNA (02), DYNAMIC ALLOCATION OF VOLUME PR38E3 FAILED. ERROR CODE 0218. INFORMATION CODE RESTORE INDD(TAPE) DATASET(INCLUDE(**)) We get the following if we tell it what volume to go to: 0ADR472E (001)-NEWDS(06), UNABLE TO SELECT A TARGET VOLUME FOR DATA SET DATASET IN CATALOG CATALOG.TEST.PROD RESTORE INDD(TAPE) OUTDD(DASD) - DATASET(INCLUDE(**)) As you can see, we were using the restore as simply as possible. The catalog it points to is the incorrect catalog in this error CATALOG.MAINT.PROD is where it should point. In both cases TAPE is actually a dataset on a 3390-9 We're not using tape at all for the purpose of this exercise. The sandbox is mostly isolated, we have a handful of shared DASD. Using RACF which is isolated to the sandbox. The job used to dump: DUMP - DATASET(INCLUDE( - DATASET - )) - OUTDDNAME(DASDO) - SPHERE - ALLDATA(*) - ALLX - TOL(ENQF) DASDO is just a 3390-9 dataset. To make things more interesting...I figured out that this ONLY happens to our DEFAULT storage group. If the dataset lands in a storage group other than default the above method works. Thanks; Nathan Pfister zOS Systems Programmer AES\PHEAA - Tech Services npfis...@aessuccess.org (717) 720-2663 From: Lizette Koehler stars...@mindspring.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 03/21/2014 10:57 AM Subject:Re: SMS Question Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU It would be helpful for you to include Level of z/OS Complete error message Complete control cards. If you show us what you are doing, it will help us provide better answers. Also, what DASD/TAPE hardware are you using? Do you only have DFDSS? Or is FDR or other product available to you? Is your sandbox totally isolated from your production? If not, are you sharing the dasd and tape? What SAF are you using? RACF, TSS, ACF2? Is this shared or separated between Sandbox and Production? Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Nathan J Pfister Sent: Friday, March 21, 2014 7:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMS Question Hello; I am relatively new to SMS, and rather ignorant (read: uneducated) about how it fully works. I'm learning more and more by reading, but I've hit an issue which I can't find a quick solution to using google or finding in the manuals. We just set up a new SANDBOX system, and set up SMS from scratch. When we dump with ADRDSSU some datasets (from a production lpar) to be restored to the Sandbox LPAR, we are getting errors where it is trying to select the volume that it came from (which is not online on the Sandbox). Shouldn't SMS be choosing a volume based on the ACS routines of the Sandbox system? What are we missing? Thanks in advance. Thanks; Nathan Pfister zOS Systems Programmer AES\PHEAA - Tech Services -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This message contains privileged and confidential information intended for the above addressees only. If you receive this message in error please delete or destroy this message and/or attachments. The sender of this message will fully cooperate in the civil and criminal prosecution of any individual engaging in the unauthorized use of this message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS Question
My first guess is that the STORCLAS associated with the data set being restore had the GUARANTEED SPACE attribute. Either remove that from the STORCLAS or in the restore parameters include a VOLUME(*) parameter to override the volume that DFDSS wants to use. On Fri, Mar 21, 2014 at 9:36 AM, Nathan J Pfister npfis...@aessuccess.orgwrote: Hello; I am relatively new to SMS, and rather ignorant (read: uneducated) about how it fully works. I'm learning more and more by reading, but I've hit an issue which I can't find a quick solution to using google or finding in the manuals. We just set up a new SANDBOX system, and set up SMS from scratch. When we dump with ADRDSSU some datasets (from a production lpar) to be restored to the Sandbox LPAR, we are getting errors where it is trying to select the volume that it came from (which is not online on the Sandbox). Shouldn't SMS be choosing a volume based on the ACS routines of the Sandbox system? What are we missing? Thanks in advance. Thanks; Nathan Pfister zOS Systems Programmer AES\PHEAA - Tech Services npfis...@aessuccess.org This message contains privileged and confidential information intended for the above addressees only. If you receive this message in error please delete or destroy this message and/or attachments. The sender of this message will fully cooperate in the civil and criminal prosecution of any individual engaging in the unauthorized use of this message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS Question
We figured out the issuesince we're using ADRDSSU, it's getting a null dataclass...and we had a condition within the storage class that said if dataclas is '' then set storclas to ''. So I guess my next question...we attempted to code for dataclas = '' and pgm = 'ADRDSSU' to fall to our DEFAULT stroage class...when moving datasets this worked like a champ...but when restoring datasets it did not. Obviously I am missing something else here. Is ADRDSSU not the right pgm name? Thanks; Nathan Pfister zOS Systems Programmer AES\PHEAA - Tech Services npfis...@aessuccess.org (717) 720-2663 From: John McKown john.archie.mck...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 03/21/2014 12:04 PM Subject:Re: SMS Question Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU My first guess is that the STORCLAS associated with the data set being restore had the GUARANTEED SPACE attribute. Either remove that from the STORCLAS or in the restore parameters include a VOLUME(*) parameter to override the volume that DFDSS wants to use. On Fri, Mar 21, 2014 at 9:36 AM, Nathan J Pfister npfis...@aessuccess.orgwrote: Hello; I am relatively new to SMS, and rather ignorant (read: uneducated) about how it fully works. I'm learning more and more by reading, but I've hit an issue which I can't find a quick solution to using google or finding in the manuals. We just set up a new SANDBOX system, and set up SMS from scratch. When we dump with ADRDSSU some datasets (from a production lpar) to be restored to the Sandbox LPAR, we are getting errors where it is trying to select the volume that it came from (which is not online on the Sandbox). Shouldn't SMS be choosing a volume based on the ACS routines of the Sandbox system? What are we missing? Thanks in advance. Thanks; Nathan Pfister zOS Systems Programmer AES\PHEAA - Tech Services npfis...@aessuccess.org This message contains privileged and confidential information intended for the above addressees only. If you receive this message in error please delete or destroy this message and/or attachments. The sender of this message will fully cooperate in the civil and criminal prosecution of any individual engaging in the unauthorized use of this message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This message contains privileged and confidential information intended for the above addressees only. If you receive this message in error please delete or destroy this message and/or attachments. The sender of this message will fully cooperate in the civil and criminal prosecution of any individual engaging in the unauthorized use of this message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS Question
I've found that under DSSU, the DC ACS routine is not invoked at all and SC is the first ACS routine, which is opposite of normal allocation. Thus your SC cannot depend on a DC value under DSSU. I think the rational is that unlike the other classes DC is imutable in that a data sets characteristics can't be changed after allocation. For example a FB/80 data set can't be changed to VSAM just by changing the DC which explains why you cannot alter the DC of a data set. Think of DC as physical vs the others which are logical. Probably your source data sets don't have a DC so a SC ACS looking for them is lost. The only way I've found to fix this is to duplicate the code in DC into SC as well so a SC gets assigned. Without a SC assignment, SG (and MC) are not invoked, thus you have non-SMS. Ken On Fri, Mar 21, 2014 at 1:00 PM, Nathan J Pfister npfis...@aessuccess.orgwrote: We figured out the issuesince we're using ADRDSSU, it's getting a null dataclass...and we had a condition within the storage class that said if dataclas is '' then set storclas to ''. So I guess my next question...we attempted to code for dataclas = '' and pgm = 'ADRDSSU' to fall to our DEFAULT stroage class...when moving datasets this worked like a champ...but when restoring datasets it did not. Obviously I am missing something else here. Is ADRDSSU not the right pgm name? Thanks; Nathan Pfister zOS Systems Programmer AES\PHEAA - Tech Services npfis...@aessuccess.org (717) 720-2663 From: John McKown john.archie.mck...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 03/21/2014 12:04 PM Subject:Re: SMS Question Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU My first guess is that the STORCLAS associated with the data set being restore had the GUARANTEED SPACE attribute. Either remove that from the STORCLAS or in the restore parameters include a VOLUME(*) parameter to override the volume that DFDSS wants to use. On Fri, Mar 21, 2014 at 9:36 AM, Nathan J Pfister npfis...@aessuccess.orgwrote: Hello; I am relatively new to SMS, and rather ignorant (read: uneducated) about how it fully works. I'm learning more and more by reading, but I've hit an issue which I can't find a quick solution to using google or finding in the manuals. We just set up a new SANDBOX system, and set up SMS from scratch. When we dump with ADRDSSU some datasets (from a production lpar) to be restored to the Sandbox LPAR, we are getting errors where it is trying to select the volume that it came from (which is not online on the Sandbox). Shouldn't SMS be choosing a volume based on the ACS routines of the Sandbox system? What are we missing? Thanks in advance. Thanks; Nathan Pfister zOS Systems Programmer AES\PHEAA - Tech Services npfis...@aessuccess.org This message contains privileged and confidential information intended for the above addressees only. If you receive this message in error please delete or destroy this message and/or attachments. The sender of this message will fully cooperate in the civil and criminal prosecution of any individual engaging in the unauthorized use of this message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This message contains privileged and confidential information intended for the above addressees only. If you receive this message in error please delete or destroy this message and/or attachments. The sender of this message will fully cooperate in the civil and criminal prosecution of any individual engaging in the unauthorized use of this message. -- 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
Re: SMS Question
You can eliminate any problems caused by the ACS routines by specifying the MGMTCLAS, STORCLAS, DATACLAS, and most importantly the BYPASSACS operands on the RESTORE command. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Nathan J Pfister :: Sent: Friday, March 21, 2014 10:00 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: SMS Question :: :: We figured out the issuesince we're using ADRDSSU, it's getting a :: null :: dataclass...and we had a condition within the storage class that said if :: dataclas is '' then set storclas to ''. :: :: So I guess my next question...we attempted to code for dataclas = '' and :: pgm = 'ADRDSSU' to fall to our DEFAULT stroage class...when moving :: datasets this worked like a champ...but when restoring datasets it did :: not. Obviously I am missing something else here. Is ADRDSSU not the :: right pgm name? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SMS QUESTION - ACTUAL SPACE NOT ALLOCATED
Good Day All, I am trying to allocate a dsn using PGM=IEFBR14 to create a dsn which of 25 cylinders. The dsn is SMS managed and it has GUASPACE as the Storage Class. The DC MC are null. The dsn is allocated on the volume as requested however the space allocated is 20 instead of 25. I was able to allocated the space of 25 cylinders when I coded UNIT=SYSALLDA,SPACE=(CYL,29),VOL=SER=PROM01. Could anybody tell me where my error is? Below is my jcl (which is run from a proc) //* //ALLOC EXEC PGM=IEFBR14 //A01065 DD A01.DSN=DSNIN..A01065,DISP=(,CATLG), // UNIT=SYSALLDA,SPACE=(CYL,29),VOL=SER=PROM01 //IXX065 DD IXX.DSN=DSNIN..IXX065,DISP=(,CATLG), // UNIT=SYSALLDA,SPACE=(CYL,29),VOL=SER=PROM01 //* Below is the inquiry on the dsn: Command === More: + Data Set Name . . . . : HEST.INTS.DATACOM.A01065 General Data Current Allocation Management class . . : **None** Allocated cylinders : 25 Storage class . . . : GUASPACE Allocated extents . : 1 Volume serial . . . : PROM01 Device type . . . . : 3390 Data class . . . . . : **None** Organization . . . : PS Current Utilization Record format . . . : F Used cylinders . . : 25 Record length . . . : 4096 Used extents . . . : 1 Block size . . . . : 4096 1st extent cylinders: 25 Secondary cylinders : 0 Dates Data set name type : Creation date . . . : 2013/09/27 SMS Compressible. . : NO Referenced date . . : 2013/10/03 Expiration date . . : ***None*** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS QUESTION - ACTUAL SPACE NOT ALLOCATED
This sounds like the track size problem. There were a lot of shops that implemented a default track size of 47476 (3380) rather than 56664 (3390). This ends up, after DADSM is finished with the allocation, with your dataset 80% of the request size. Check with your. Storage Admins. (I forget where the size is specified) This crops up about once a year, even though it was identified over 20 years ago. - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: willie bunter williebun...@yahoo.com Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Thu, 3 Oct 2013 07:48:05 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: SMS QUESTION - ACTUAL SPACE NOT ALLOCATED Good Day All, I am trying to allocate a dsn using PGM=IEFBR14 to create a dsn which of 25 cylinders. The dsn is SMS managed and it has GUASPACE as the Storage Class. The DC MC are null. The dsn is allocated on the volume as requested however the space allocated is 20 instead of 25. I was able to allocated the space of 25 cylinders when I coded UNIT=SYSALLDA,SPACE=(CYL,29),VOL=SER=PROM01. Could anybody tell me where my error is? Below is my jcl (which is run from a proc) //* //ALLOC EXEC PGM=IEFBR14 //A01065 DD A01.DSN=DSNIN..A01065,DISP=(,CATLG), // UNIT=SYSALLDA,SPACE=(CYL,29),VOL=SER=PROM01 //IXX065 DD IXX.DSN=DSNIN..IXX065,DISP=(,CATLG), // UNIT=SYSALLDA,SPACE=(CYL,29),VOL=SER=PROM01 //* Below is the inquiry on the dsn: Command === More: + Data Set Name . . . . : HEST.INTS.DATACOM.A01065 General Data Current Allocation Management class . . : **None** Allocated cylinders : 25 Storage class . . . : GUASPACE Allocated extents . : 1 Volume serial . . . : PROM01 Device type . . . . : 3390 Data class . . . . . : **None** Organization . . . : PS Current Utilization Record format . . . : F Used cylinders . . : 25 Record length . . . : 4096 Used extents . . . : 1 Block size . . . . : 4096 1st extent cylinders: 25 Secondary cylinders : 0 Dates Data set name type : Creation date . . . : 2013/09/27 SMS Compressible. . : NO Referenced date . . : 2013/10/03 Expiration date . . : ***None*** -- 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
Re: SMS QUESTION - ACTUAL SPACE NOT ALLOCATED - ANSWER FOUND.
I found the answer to my question. In the SMS base config the Default device geometry is set up for 3380 instead of 3390 : Default Device Geometry Bytes/track . . . . . : 47476 Tracks/cylinder . . . : 15 This is causing the allocation to be reduced. To bypass the problem I am using UNIT=3390 instead of UNIT=SYSALLDA. Problem solved. Thanks. From: willie bunter williebun...@yahoo.com To: IBM-MAIN@listserv.ua.edu IBM-MAIN@listserv.ua.edu Sent: Thursday, October 3, 2013 10:48:05 AM Subject: SMS QUESTION - ACTUAL SPACE NOT ALLOCATED Good Day All, I am trying to allocate a dsn using PGM=IEFBR14 to create a dsn which of 25 cylinders. The dsn is SMS managed and it has GUASPACE as the Storage Class. The DC MC are null. The dsn is allocated on the volume as requested however the space allocated is 20 instead of 25. I was able to allocated the space of 25 cylinders when I coded UNIT=SYSALLDA,SPACE=(CYL,29),VOL=SER=PROM01. Could anybody tell me where my error is? Below is my jcl (which is run from a proc) //* //ALLOC EXEC PGM=IEFBR14 //A01065 DD A01.DSN=DSNIN..A01065,DISP=(,CATLG), // UNIT=SYSALLDA,SPACE=(CYL,29),VOL=SER=PROM01 //IXX065 DD IXX.DSN=DSNIN..IXX065,DISP=(,CATLG), // UNIT=SYSALLDA,SPACE=(CYL,29),VOL=SER=PROM01 //* Below is the inquiry on the dsn: Command === More: + Data Set Name . . . . : HEST.INTS.DATACOM.A01065 General Data Current Allocation Management class . . : **None** Allocated cylinders : 25 Storage class . . . : GUASPACE Allocated extents . : 1 Volume serial . . . : PROM01 Device type . . . . : 3390 Data class . . . . . : **None** Organization . . . : PS Current Utilization Record format . . . : F Used cylinders . . : 25 Record length . . . : 4096 Used extents . . . : 1 Block size . . . . : 4096 1st extent cylinders: 25 Secondary cylinders : 0 Dates Data set name type : Creation date . . . : 2013/09/27 SMS Compressible. . : NO Referenced date . . : 2013/10/03 Expiration date . . : ***None*** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS QUESTION - ACTUAL SPACE NOT ALLOCATED
Ted, Thanks. Our e-mails crossed each other. Yes, it is set to 47476 tracks as you had suggested. Thanks for your help. From: Ted MacNEIL eamacn...@yahoo.ca To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, October 3, 2013 1:37:15 PM Subject: Re: SMS QUESTION - ACTUAL SPACE NOT ALLOCATED This sounds like the track size problem. There were a lot of shops that implemented a default track size of 47476 (3380) rather than 56664 (3390). This ends up, after DADSM is finished with the allocation, with your dataset 80% of the request size. Check with your. Storage Admins. (I forget where the size is specified) This crops up about once a year, even though it was identified over 20 years ago. - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: willie bunter williebun...@yahoo.com Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Thu, 3 Oct 2013 07:48:05 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: SMS QUESTION - ACTUAL SPACE NOT ALLOCATED Good Day All, I am trying to allocate a dsn using PGM=IEFBR14 to create a dsn which of 25 cylinders. The dsn is SMS managed and it has GUASPACE as the Storage Class. The DC MC are null. The dsn is allocated on the volume as requested however the space allocated is 20 instead of 25. I was able to allocated the space of 25 cylinders when I coded UNIT=SYSALLDA,SPACE=(CYL,29),VOL=SER=PROM01. Could anybody tell me where my error is? Below is my jcl (which is run from a proc) //* //ALLOC EXEC PGM=IEFBR14 //A01065 DD A01.DSN=DSNIN..A01065,DISP=(,CATLG), // UNIT=SYSALLDA,SPACE=(CYL,29),VOL=SER=PROM01 //IXX065 DD IXX.DSN=DSNIN..IXX065,DISP=(,CATLG), // UNIT=SYSALLDA,SPACE=(CYL,29),VOL=SER=PROM01 //* Below is the inquiry on the dsn: Command === More: + Data Set Name . . . . : HEST.INTS.DATACOM.A01065 General Data Current Allocation Management class . . : **None** Allocated cylinders : 25 Storage class . . . : GUASPACE Allocated extents . : 1 Volume serial . . . : PROM01 Device type . . . . : 3390 Data class . . . . . : **None** Organization . . . : PS Current Utilization Record format . . . : F Used cylinders . . : 25 Record length . . . : 4096 Used extents . . . : 1 Block size . . . . : 4096 1st extent cylinders: 25 Secondary cylinders : 0 Dates Data set name type : Creation date . . . : 2013/09/27 SMS Compressible. . : NO Referenced date . . : 2013/10/03 Expiration date . . : ***None*** -- 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
Re: SMS QUESTION - ACTUAL SPACE NOT ALLOCATED
The first thing I'd check is the Default Device Geometry defined in your SMS Base configuration: Mine: Default Device Geometry Bytes/Track . . . . . . . . 56664 Tracks/Cylinder . . . . . . 15 in ISMF - Option 8 Control Data Set then Option 1 Display Good Day All, I am trying to allocate a dsn using PGM=IEFBR14 to create a dsn which of 25 cylinders. The dsn is SMS managed and it has GUASPACE as the Storage Class. The DC MC are null. The dsn is allocated on the volume as requested however the space allocated is 20 instead of 25. I was able to allocated the space of 25 cylinders when I coded UNIT=SYSALLDA,SPACE=(CYL,29),VOL=SER=PROM01. Could anybody tell me where my error is? Below is my jcl (which is run from a proc) //* //ALLOCEXEC PGM=IEFBR14 //A01065 DD A01.DSN=DSNIN..A01065,DISP=(,CATLG), // UNIT=SYSALLDA,SPACE=(CYL,29),VOL=SER=PROM01 //IXX065 DD IXX.DSN=DSNIN..IXX065,DISP=(,CATLG), // UNIT=SYSALLDA,SPACE=(CYL,29),VOL=SER=PROM01 //* Below is the inquiry on the dsn: Command === More: + Data Set Name . . . . : HEST.INTS.DATACOM.A01065 General Data Current Allocation Management class . . : **None**Allocated cylinders : 25 Storage class . . . : GUASPACEAllocated extents . : 1 Volume serial . . . : PROM01 Device type . . . . : 3390 Data class . . . . . : **None** Organization . . . : PS Current Utilization Record format . . . : F Used cylinders . . : 25 Record length . . . : 4096Used extents . . . : 1 Block size . . . . : 4096 1st extent cylinders: 25 Secondary cylinders : 0 Dates Data set name type : Creation date . . . : 2013/09/27 SMS Compressible. . : NO Referenced date . . : 2013/10/03 Expiration date . . : ***None*** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ** 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
Re: SMS QUESTION - ACTUAL SPACE NOT ALLOCATED - ANSWER FOUND.
willie bunter wrote: I found the answer to my question. In the SMS base config the Default device geometry is set up for 3380 instead of 3390 : Thanks. I tried *really* to reproduce your problem but could not succeed in it. I even RTFM everything about that guarantee space, but of course it is *guaranteed* that I did not find anything. ;-D We are not using SYSALLDA, rather we use SYSDA with the type of device we're using the most. These days SYSDA means 3390. Now, it is 20:00 and it is guaranteed that I'm now going home. :-D Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS QUESTION
John, Are there any volumes with status Quinew in the pool you're having a problem with? Do you have a 'spill' pool defined? If you Quinew one or more volumes, you'll find that over time these will have a greater amount of freespace than the rest of the pool thereby allowing allocations that won't fit elsewhere in the pool. You could expedite the process by clearing the now quinew'd volume using DSS or HSM. -Original Message- From: John Dawes [mailto:jhn_da...@yahoo.com.au] Sent: Wednesday, March 13, 2013 11:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS QUESTION As you aptly put it 'Just because someone else is stupid, that's no reason for you to be' which prompted my first post. I was curious as to why the High Threshold was low. Thanks to all of you my understanding has greatly increased. Cheers. From: O'Brien, David W. (NIH/CIT) [C] obrie...@mail.nih.gov To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, 13 March 2013 11:10 AM Subject: Re: SMS QUESTION I was once told by a colleague, 'Just because someone else is stupid, that's no reason for you to be'. A low 'High Threshold' will trigger migration during Interval Migration. As Ron pointed out it also prevents SMS from working as designed. A very low 'Low Threshold' will ensure that as much as possible will be migrated during Primary Space Mgt. Beyond that I'll not comment further. -Original Message- From: John Dawes [mailto:jhn_da...@yahoo.com.au] Sent: Wednesday, March 13, 2013 11:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS QUESTION I stumbled on to this by accident. The person who had set up the Storage Group wanted to keep the pool at 20% full i.e. migrate dsns as much as possible to prevent space abends because the users who create dsns on this pool are not authorized to create multi-volume dsns. From: O'Brien, David W. (NIH/CIT) [C] obrie...@mail.nih.gov To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, 13 March 2013 9:15 AM Subject: Re: SMS QUESTION That is correct, although by setting the high threshold so low, you prevent SMS from determining target volumes by activity. What did you hope to accomplish with a high threshold setting of 20%? -Original Message- From: John Dawes [mailto:jhn_da...@yahoo.com.au] Sent: Wednesday, March 13, 2013 9:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS QUESTION Just that I understand correctly if the the High Threshold is set to 20% SMS does not PREVENT allocations above the High Threshold i.e. the dsn will still be allocated if the space is available. SMS will not fail the allocation request. Right? Thanks. From: Ron Hawkins ronjhawk...@sbcglobal.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, 12 March 2013 6:51 PM Subject: Re: SMS QUESTION David, Yes, your understanding is the same as mine. The primary eligible device list contains volumes that will not exceed the max threshold if the primary space is allocated there. This is sorted on performance criteria. The secondary eligible device list has volumes with enough free space to satisfy the primary space request, and my recollection is that this is in free space order. If allocation is not satisfied in the primary list it will fall through to the secondary list. With a high threshold of 20%, most allocation will likely be influenced by space, rather than activity. If you suspect that fragmentation is the problem then have you checked if you have Space Constraint relief set to YES in the DATACLAS used by the data set, or if the % reduction is aggressive enough to counter the fragmentation. Another strategy would be to reduce to space request to something smaller, let's say (TRK(5000,5000),RLSE), and add a unit count so the space is allocated across multiple volumes - UNIT=(,5). Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of O'Brien, David W. (NIH/CIT) [C] Sent: Tuesday, March 12, 2013 11:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] SMS QUESTION No, volumes which are above the threshold but have available space are put into a secondary allocation list. Those volumes under the high threshold are in a primary allocation list. SMS then searches for a volume which will satisfy the allocation. At least that's the way it was explained to me by IBM at the Share meeting in Baltimore some years ago. The OP has 51 volumes with available space which are either badly fragmented or do not have 20K tracks within 5 extents. A smaller primary and secondary with a unit parameter specifying multiple volumes will allow the allocation. -Original Message- From: Staller, Allan [mailto:allan.stal...@kbmg.com] Sent: Tuesday, March 12, 2013 1:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS QUESTION What if *all* of the volumes are at/near the high threshold
Re: SMS QUESTION
David, I checked. There are no volumes in QUINEW status. There is no overflow pool defined for this storage group. I will heed your suggestion about having the overflow volumes. This will be a great help. Thanks again. From: O'Brien, David W. (NIH/CIT) [C] obrie...@mail.nih.gov To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, 14 March 2013 9:16 AM Subject: Re: SMS QUESTION John, Are there any volumes with status Quinew in the pool you're having a problem with? Do you have a 'spill' pool defined? If you Quinew one or more volumes, you'll find that over time these will have a greater amount of freespace than the rest of the pool thereby allowing allocations that won't fit elsewhere in the pool. You could expedite the process by clearing the now quinew'd volume using DSS or HSM. -Original Message- From: John Dawes [mailto:jhn_da...@yahoo.com.au] Sent: Wednesday, March 13, 2013 11:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS QUESTION As you aptly put it 'Just because someone else is stupid, that's no reason for you to be' which prompted my first post. I was curious as to why the High Threshold was low. Thanks to all of you my understanding has greatly increased. Cheers. From: O'Brien, David W. (NIH/CIT) [C] obrie...@mail.nih.gov To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, 13 March 2013 11:10 AM Subject: Re: SMS QUESTION I was once told by a colleague, 'Just because someone else is stupid, that's no reason for you to be'. A low 'High Threshold' will trigger migration during Interval Migration. As Ron pointed out it also prevents SMS from working as designed. A very low 'Low Threshold' will ensure that as much as possible will be migrated during Primary Space Mgt. Beyond that I'll not comment further. -Original Message- From: John Dawes [mailto:jhn_da...@yahoo.com.au] Sent: Wednesday, March 13, 2013 11:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS QUESTION I stumbled on to this by accident. The person who had set up the Storage Group wanted to keep the pool at 20% full i.e. migrate dsns as much as possible to prevent space abends because the users who create dsns on this pool are not authorized to create multi-volume dsns. From: O'Brien, David W. (NIH/CIT) [C] obrie...@mail.nih.gov To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, 13 March 2013 9:15 AM Subject: Re: SMS QUESTION That is correct, although by setting the high threshold so low, you prevent SMS from determining target volumes by activity. What did you hope to accomplish with a high threshold setting of 20%? -Original Message- From: John Dawes [mailto:jhn_da...@yahoo.com.au] Sent: Wednesday, March 13, 2013 9:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS QUESTION Just that I understand correctly if the the High Threshold is set to 20% SMS does not PREVENT allocations above the High Threshold i.e. the dsn will still be allocated if the space is available. SMS will not fail the allocation request. Right? Thanks. From: Ron Hawkins ronjhawk...@sbcglobal.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, 12 March 2013 6:51 PM Subject: Re: SMS QUESTION David, Yes, your understanding is the same as mine. The primary eligible device list contains volumes that will not exceed the max threshold if the primary space is allocated there. This is sorted on performance criteria. The secondary eligible device list has volumes with enough free space to satisfy the primary space request, and my recollection is that this is in free space order. If allocation is not satisfied in the primary list it will fall through to the secondary list. With a high threshold of 20%, most allocation will likely be influenced by space, rather than activity. If you suspect that fragmentation is the problem then have you checked if you have Space Constraint relief set to YES in the DATACLAS used by the data set, or if the % reduction is aggressive enough to counter the fragmentation. Another strategy would be to reduce to space request to something smaller, let's say (TRK(5000,5000),RLSE), and add a unit count so the space is allocated across multiple volumes - UNIT=(,5). Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of O'Brien, David W. (NIH/CIT) [C] Sent: Tuesday, March 12, 2013 11:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] SMS QUESTION No, volumes which are above the threshold but have available space are put into a secondary allocation list. Those volumes under the high threshold are in a primary allocation list. SMS then searches for a volume which will satisfy the allocation. At least that's the way it was explained to me by IBM at the Share meeting in Baltimore some years ago. The OP has 51 volumes with available space which are either
Re: SMS QUESTION
Ron, Thanks for your reply but I am not the one with the problem. Dave O'Brien -Original Message- From: Ron Hawkins [mailto:ronjhawk...@sbcglobal.net] Sent: Tuesday, March 12, 2013 6:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS QUESTION David, Yes, your understanding is the same as mine. The primary eligible device list contains volumes that will not exceed the max threshold if the primary space is allocated there. This is sorted on performance criteria. The secondary eligible device list has volumes with enough free space to satisfy the primary space request, and my recollection is that this is in free space order. If allocation is not satisfied in the primary list it will fall through to the secondary list. With a high threshold of 20%, most allocation will likely be influenced by space, rather than activity. If you suspect that fragmentation is the problem then have you checked if you have Space Constraint relief set to YES in the DATACLAS used by the data set, or if the % reduction is aggressive enough to counter the fragmentation. Another strategy would be to reduce to space request to something smaller, let's say (TRK(5000,5000),RLSE), and add a unit count so the space is allocated across multiple volumes - UNIT=(,5). Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of O'Brien, David W. (NIH/CIT) [C] Sent: Tuesday, March 12, 2013 11:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] SMS QUESTION No, volumes which are above the threshold but have available space are put into a secondary allocation list. Those volumes under the high threshold are in a primary allocation list. SMS then searches for a volume which will satisfy the allocation. At least that's the way it was explained to me by IBM at the Share meeting in Baltimore some years ago. The OP has 51 volumes with available space which are either badly fragmented or do not have 20K tracks within 5 extents. A smaller primary and secondary with a unit parameter specifying multiple volumes will allow the allocation. -Original Message- From: Staller, Allan [mailto:allan.stal...@kbmg.com] Sent: Tuesday, March 12, 2013 1:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS QUESTION What if *all* of the volumes are at/near the high threshold (20%)? Very often there are candidate volumes defined to SMS, but that do not physically exist (which could be the 51 volumes lacking space for the allocation). snip While I agree that the High Threshold should be 80 (or in that vicinity), SMS does not PREVENT allocations above the High Threshold, it merely tries to direct them to a volume below that threshold. The last line of the error msg. is the problem. 51 volumes lack the free space to allow the allocation. The solution would be to add volumes to the pool OR allow for a multi- volume file. Use a smaller Primary space allocation and use UNIT=(3390,10) in your DD statement. The 10 is just an example, the upper limit is 59. /snip I believe your problem is located here: snip Allocation/migration Threshold : High20 (1-100) Low . . 1 (0-99) /snip IIRC, the HIGH 20 will prevent allocation of new datasets if the PRI space will exceed the high threshold. BTW, IMO, the ALLOC High of 20 is extremely low. I would suggest a number more on the lines of 50 to 80 percent. You will most likely be able to reduce the number of volumes in this pool after the change. HTH, snip Allocation/migration Threshold : High 20 (1-100) Low . . 1 (0-99) Alloc/Migr Threshold Track-Managed: High 85 (1-100) Low . . 1 (0-99) Guaranteed Backup Frequency . . . . . . NOLIMIT (1 to or NOLIMIT) BreakPointValue . . . . . . . . . . . . (0-65520 or blank) Of late we have been having allocation problems where the job is unable to allocate the first extent and fails on jcl error etc. I found the following info which may explain the cause. Am I barking up the wrong tree? If not, if I change the High from 20 to 80 would that address the problem? Also, would HSM miigrate dsn only if the pool is reached 80% or over? MIGR HIGH is also checked during allocation. SMS attempts to select a volume that has enough space available to contain the primary allocation of the new data set without exceeding the MIGR HIGH threshold. /snip -- 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
Re: SMS QUESTION
That is correct, although by setting the high threshold so low, you prevent SMS from determining target volumes by activity. What did you hope to accomplish with a high threshold setting of 20%? -Original Message- From: John Dawes [mailto:jhn_da...@yahoo.com.au] Sent: Wednesday, March 13, 2013 9:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS QUESTION Just that I understand correctly if the the High Threshold is set to 20% SMS does not PREVENT allocations above the High Threshold i.e. the dsn will still be allocated if the space is available. SMS will not fail the allocation request. Right? Thanks. From: Ron Hawkins ronjhawk...@sbcglobal.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, 12 March 2013 6:51 PM Subject: Re: SMS QUESTION David, Yes, your understanding is the same as mine. The primary eligible device list contains volumes that will not exceed the max threshold if the primary space is allocated there. This is sorted on performance criteria. The secondary eligible device list has volumes with enough free space to satisfy the primary space request, and my recollection is that this is in free space order. If allocation is not satisfied in the primary list it will fall through to the secondary list. With a high threshold of 20%, most allocation will likely be influenced by space, rather than activity. If you suspect that fragmentation is the problem then have you checked if you have Space Constraint relief set to YES in the DATACLAS used by the data set, or if the % reduction is aggressive enough to counter the fragmentation. Another strategy would be to reduce to space request to something smaller, let's say (TRK(5000,5000),RLSE), and add a unit count so the space is allocated across multiple volumes - UNIT=(,5). Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of O'Brien, David W. (NIH/CIT) [C] Sent: Tuesday, March 12, 2013 11:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] SMS QUESTION No, volumes which are above the threshold but have available space are put into a secondary allocation list. Those volumes under the high threshold are in a primary allocation list. SMS then searches for a volume which will satisfy the allocation. At least that's the way it was explained to me by IBM at the Share meeting in Baltimore some years ago. The OP has 51 volumes with available space which are either badly fragmented or do not have 20K tracks within 5 extents. A smaller primary and secondary with a unit parameter specifying multiple volumes will allow the allocation. -Original Message- From: Staller, Allan [mailto:allan.stal...@kbmg.com] Sent: Tuesday, March 12, 2013 1:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS QUESTION What if *all* of the volumes are at/near the high threshold (20%)? Very often there are candidate volumes defined to SMS, but that do not physically exist (which could be the 51 volumes lacking space for the allocation). snip While I agree that the High Threshold should be 80 (or in that vicinity), SMS does not PREVENT allocations above the High Threshold, it merely tries to direct them to a volume below that threshold. The last line of the error msg. is the problem. 51 volumes lack the free space to allow the allocation. The solution would be to add volumes to the pool OR allow for a multi- volume file. Use a smaller Primary space allocation and use UNIT=(3390,10) in your DD statement. The 10 is just an example, the upper limit is 59. /snip I believe your problem is located here: snip Allocation/migration Threshold : High 20 (1-100) Low . . 1 (0-99) /snip IIRC, the HIGH 20 will prevent allocation of new datasets if the PRI space will exceed the high threshold. BTW, IMO, the ALLOC High of 20 is extremely low. I would suggest a number more on the lines of 50 to 80 percent. You will most likely be able to reduce the number of volumes in this pool after the change. HTH, snip Allocation/migration Threshold : High 20 (1-100) Low . . 1 (0-99) Alloc/Migr Threshold Track-Managed: High 85 (1-100) Low . . 1 (0-99) Guaranteed Backup Frequency . . . . . . NOLIMIT (1 to or NOLIMIT) BreakPointValue . . . . . . . . . . . . (0-65520 or blank) Of late we have been having allocation problems where the job is unable to allocate the first extent and fails on jcl error etc. I found the following info which may explain the cause. Am I barking up the wrong tree? If not, if I change the High from 20 to 80 would that address the problem? Also, would HSM miigrate dsn only if the pool is reached 80% or over? MIGR HIGH is also checked during allocation. SMS attempts to select a volume that has enough space available to contain the primary allocation of the new
Re: SMS QUESTION
I stumbled on to this by accident. The person who had set up the Storage Group wanted to keep the pool at 20% full i.e. migrate dsns as much as possible to prevent space abends because the users who create dsns on this pool are not authorized to create multi-volume dsns. From: O'Brien, David W. (NIH/CIT) [C] obrie...@mail.nih.gov To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, 13 March 2013 9:15 AM Subject: Re: SMS QUESTION That is correct, although by setting the high threshold so low, you prevent SMS from determining target volumes by activity. What did you hope to accomplish with a high threshold setting of 20%? -Original Message- From: John Dawes [mailto:jhn_da...@yahoo.com.au] Sent: Wednesday, March 13, 2013 9:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS QUESTION Just that I understand correctly if the the High Threshold is set to 20% SMS does not PREVENT allocations above the High Threshold i.e. the dsn will still be allocated if the space is available. SMS will not fail the allocation request. Right? Thanks. From: Ron Hawkins ronjhawk...@sbcglobal.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, 12 March 2013 6:51 PM Subject: Re: SMS QUESTION David, Yes, your understanding is the same as mine. The primary eligible device list contains volumes that will not exceed the max threshold if the primary space is allocated there. This is sorted on performance criteria. The secondary eligible device list has volumes with enough free space to satisfy the primary space request, and my recollection is that this is in free space order. If allocation is not satisfied in the primary list it will fall through to the secondary list. With a high threshold of 20%, most allocation will likely be influenced by space, rather than activity. If you suspect that fragmentation is the problem then have you checked if you have Space Constraint relief set to YES in the DATACLAS used by the data set, or if the % reduction is aggressive enough to counter the fragmentation. Another strategy would be to reduce to space request to something smaller, let's say (TRK(5000,5000),RLSE), and add a unit count so the space is allocated across multiple volumes - UNIT=(,5). Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of O'Brien, David W. (NIH/CIT) [C] Sent: Tuesday, March 12, 2013 11:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] SMS QUESTION No, volumes which are above the threshold but have available space are put into a secondary allocation list. Those volumes under the high threshold are in a primary allocation list. SMS then searches for a volume which will satisfy the allocation. At least that's the way it was explained to me by IBM at the Share meeting in Baltimore some years ago. The OP has 51 volumes with available space which are either badly fragmented or do not have 20K tracks within 5 extents. A smaller primary and secondary with a unit parameter specifying multiple volumes will allow the allocation. -Original Message- From: Staller, Allan [mailto:allan.stal...@kbmg.com] Sent: Tuesday, March 12, 2013 1:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS QUESTION What if *all* of the volumes are at/near the high threshold (20%)? Very often there are candidate volumes defined to SMS, but that do not physically exist (which could be the 51 volumes lacking space for the allocation). snip While I agree that the High Threshold should be 80 (or in that vicinity), SMS does not PREVENT allocations above the High Threshold, it merely tries to direct them to a volume below that threshold. The last line of the error msg. is the problem. 51 volumes lack the free space to allow the allocation. The solution would be to add volumes to the pool OR allow for a multi- volume file. Use a smaller Primary space allocation and use UNIT=(3390,10) in your DD statement. The 10 is just an example, the upper limit is 59. /snip I believe your problem is located here: snip Allocation/migration Threshold : High 20 (1-100) Low . . 1 (0-99) /snip IIRC, the HIGH 20 will prevent allocation of new datasets if the PRI space will exceed the high threshold. BTW, IMO, the ALLOC High of 20 is extremely low. I would suggest a number more on the lines of 50 to 80 percent. You will most likely be able to reduce the number of volumes in this pool after the change. HTH, snip Allocation/migration Threshold : High 20 (1-100) Low . . 1 (0-99) Alloc/Migr Threshold Track-Managed: High 85 (1-100) Low . . 1 (0-99) Guaranteed Backup Frequency . . . . . . NOLIMIT (1 to or NOLIMIT) BreakPointValue . . . . . . . . . . . . (0-65520 or blank) Of late we have been having allocation problems where the job is unable
Re: SMS QUESTION
I was once told by a colleague, 'Just because someone else is stupid, that's no reason for you to be'. A low 'High Threshold' will trigger migration during Interval Migration. As Ron pointed out it also prevents SMS from working as designed. A very low 'Low Threshold' will ensure that as much as possible will be migrated during Primary Space Mgt. Beyond that I'll not comment further. -Original Message- From: John Dawes [mailto:jhn_da...@yahoo.com.au] Sent: Wednesday, March 13, 2013 11:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS QUESTION I stumbled on to this by accident. The person who had set up the Storage Group wanted to keep the pool at 20% full i.e. migrate dsns as much as possible to prevent space abends because the users who create dsns on this pool are not authorized to create multi-volume dsns. From: O'Brien, David W. (NIH/CIT) [C] obrie...@mail.nih.gov To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, 13 March 2013 9:15 AM Subject: Re: SMS QUESTION That is correct, although by setting the high threshold so low, you prevent SMS from determining target volumes by activity. What did you hope to accomplish with a high threshold setting of 20%? -Original Message- From: John Dawes [mailto:jhn_da...@yahoo.com.au] Sent: Wednesday, March 13, 2013 9:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS QUESTION Just that I understand correctly if the the High Threshold is set to 20% SMS does not PREVENT allocations above the High Threshold i.e. the dsn will still be allocated if the space is available. SMS will not fail the allocation request. Right? Thanks. From: Ron Hawkins ronjhawk...@sbcglobal.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, 12 March 2013 6:51 PM Subject: Re: SMS QUESTION David, Yes, your understanding is the same as mine. The primary eligible device list contains volumes that will not exceed the max threshold if the primary space is allocated there. This is sorted on performance criteria. The secondary eligible device list has volumes with enough free space to satisfy the primary space request, and my recollection is that this is in free space order. If allocation is not satisfied in the primary list it will fall through to the secondary list. With a high threshold of 20%, most allocation will likely be influenced by space, rather than activity. If you suspect that fragmentation is the problem then have you checked if you have Space Constraint relief set to YES in the DATACLAS used by the data set, or if the % reduction is aggressive enough to counter the fragmentation. Another strategy would be to reduce to space request to something smaller, let's say (TRK(5000,5000),RLSE), and add a unit count so the space is allocated across multiple volumes - UNIT=(,5). Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of O'Brien, David W. (NIH/CIT) [C] Sent: Tuesday, March 12, 2013 11:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] SMS QUESTION No, volumes which are above the threshold but have available space are put into a secondary allocation list. Those volumes under the high threshold are in a primary allocation list. SMS then searches for a volume which will satisfy the allocation. At least that's the way it was explained to me by IBM at the Share meeting in Baltimore some years ago. The OP has 51 volumes with available space which are either badly fragmented or do not have 20K tracks within 5 extents. A smaller primary and secondary with a unit parameter specifying multiple volumes will allow the allocation. -Original Message- From: Staller, Allan [mailto:allan.stal...@kbmg.com] Sent: Tuesday, March 12, 2013 1:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS QUESTION What if *all* of the volumes are at/near the high threshold (20%)? Very often there are candidate volumes defined to SMS, but that do not physically exist (which could be the 51 volumes lacking space for the allocation). snip While I agree that the High Threshold should be 80 (or in that vicinity), SMS does not PREVENT allocations above the High Threshold, it merely tries to direct them to a volume below that threshold. The last line of the error msg. is the problem. 51 volumes lack the free space to allow the allocation. The solution would be to add volumes to the pool OR allow for a multi- volume file. Use a smaller Primary space allocation and use UNIT=(3390,10) in your DD statement. The 10 is just an example, the upper limit is 59. /snip I believe your problem is located here: snip Allocation/migration Threshold : High 20 (1-100) Low . . 1 (0-99) /snip IIRC, the HIGH 20 will prevent allocation of new datasets if the PRI space will exceed the high threshold. BTW, IMO, the ALLOC High of 20 is extremely low. I
Re: SMS QUESTION
As you aptly put it 'Just because someone else is stupid, that's no reason for you to be' which prompted my first post. I was curious as to why the High Threshold was low. Thanks to all of you my understanding has greatly increased. Cheers. From: O'Brien, David W. (NIH/CIT) [C] obrie...@mail.nih.gov To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, 13 March 2013 11:10 AM Subject: Re: SMS QUESTION I was once told by a colleague, 'Just because someone else is stupid, that's no reason for you to be'. A low 'High Threshold' will trigger migration during Interval Migration. As Ron pointed out it also prevents SMS from working as designed. A very low 'Low Threshold' will ensure that as much as possible will be migrated during Primary Space Mgt. Beyond that I'll not comment further. -Original Message- From: John Dawes [mailto:jhn_da...@yahoo.com.au] Sent: Wednesday, March 13, 2013 11:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS QUESTION I stumbled on to this by accident. The person who had set up the Storage Group wanted to keep the pool at 20% full i.e. migrate dsns as much as possible to prevent space abends because the users who create dsns on this pool are not authorized to create multi-volume dsns. From: O'Brien, David W. (NIH/CIT) [C] obrie...@mail.nih.gov To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, 13 March 2013 9:15 AM Subject: Re: SMS QUESTION That is correct, although by setting the high threshold so low, you prevent SMS from determining target volumes by activity. What did you hope to accomplish with a high threshold setting of 20%? -Original Message- From: John Dawes [mailto:jhn_da...@yahoo.com.au] Sent: Wednesday, March 13, 2013 9:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS QUESTION Just that I understand correctly if the the High Threshold is set to 20% SMS does not PREVENT allocations above the High Threshold i.e. the dsn will still be allocated if the space is available. SMS will not fail the allocation request. Right? Thanks. From: Ron Hawkins ronjhawk...@sbcglobal.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, 12 March 2013 6:51 PM Subject: Re: SMS QUESTION David, Yes, your understanding is the same as mine. The primary eligible device list contains volumes that will not exceed the max threshold if the primary space is allocated there. This is sorted on performance criteria. The secondary eligible device list has volumes with enough free space to satisfy the primary space request, and my recollection is that this is in free space order. If allocation is not satisfied in the primary list it will fall through to the secondary list. With a high threshold of 20%, most allocation will likely be influenced by space, rather than activity. If you suspect that fragmentation is the problem then have you checked if you have Space Constraint relief set to YES in the DATACLAS used by the data set, or if the % reduction is aggressive enough to counter the fragmentation. Another strategy would be to reduce to space request to something smaller, let's say (TRK(5000,5000),RLSE), and add a unit count so the space is allocated across multiple volumes - UNIT=(,5). Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of O'Brien, David W. (NIH/CIT) [C] Sent: Tuesday, March 12, 2013 11:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] SMS QUESTION No, volumes which are above the threshold but have available space are put into a secondary allocation list. Those volumes under the high threshold are in a primary allocation list. SMS then searches for a volume which will satisfy the allocation. At least that's the way it was explained to me by IBM at the Share meeting in Baltimore some years ago. The OP has 51 volumes with available space which are either badly fragmented or do not have 20K tracks within 5 extents. A smaller primary and secondary with a unit parameter specifying multiple volumes will allow the allocation. -Original Message- From: Staller, Allan [mailto:allan.stal...@kbmg.com] Sent: Tuesday, March 12, 2013 1:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS QUESTION What if *all* of the volumes are at/near the high threshold (20%)? Very often there are candidate volumes defined to SMS, but that do not physically exist (which could be the 51 volumes lacking space for the allocation). snip While I agree that the High Threshold should be 80 (or in that vicinity), SMS does not PREVENT allocations above the High Threshold, it merely tries to direct them to a volume below that threshold. The last line of the error msg. is the problem. 51 volumes lack the free space to allow the allocation. The solution would be to add volumes to the pool OR allow for a multi- volume file. Use a smaller
Re: SMS QUESTION
John Dawes wrote: Of late we have been having allocation problems where the job is unable to allocate the first extent and fails on jcl error etc. Please post the JCL statements and exact JCL error messages so others can help you. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS QUESTION
Elardus, Here is the error message : IEF344I ISCMURP3 PROC001 SORTOUT - ALLOCATION FAILED DUE TO DATA FACILITY SYST IGD17273I ALLOCATION HAS FAILED FOR ALL VOLUMES SELECTED FOR DATA SET HESD.KDM.SOR085.SOR1.HESPJZ.X IGD17277I THERE ARE (287) CANDIDATE VOLUMES OF WHICH (260) ARE ENABLED OR QUIES IGD17290I THERE WERE 1 CANDIDATE STORAGE GROUPS OF WHICH THE FIRST 1 WERE ELIGIBLE FOR VOLUME SELECTION. THE CANDIDATE STORAGE GROUPS WERE:SYS001 IGD17279I 27 VOLUMES WERE REJECTED BECAUSE THEY WERE NOT ONLINE IGD17279I 27 VOLUMES WERE REJECTED BECAUSE THE UCB WAS NOT AVAILABLE IGD17279I 51 VOLUMES WERE REJECTED BECAUSE THEY DID NOT HAVE SUFFICIENT SPACE //PROC001 EXEC PGM=SORT,REGION=2048K //SYSOUT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SORTIN DD DSN= HESD.IRN.IFDL.PUL13.PSUL13.X,DISP=SHR // DD DSN=HESD..VIFDL(0),DISP=SHR //**SORTIN DD DSN=HESD..VIFDL(0),DISP=SHR //SORTOUT DD DSN= HESD.KDM.SOR085.SOR1.HESPJZ.X, // DISP=(,CATLG,DELETE), //** SPACE=(TRK,(3,5),RLSE), //** SPACE=(TRK,(2,5000),RLSE), // SPACE=(TRK,(25000,500),RLSE), //** !! IF YOU CHANGE THE SPACE IN TEST, CHANGE THE PRODUCTION PROC !! // DCB=(MODELDCB,RECFM=VB,LRECL=535) //SYSIN DD DSN=SYS2.PROD.DATALIB(ISCMURP3),DISP=SHR From: Elardus Engelbrecht elardus.engelbre...@sita.co.za To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, 12 March 2013 12:26 PM Subject: Re: SMS QUESTION John Dawes wrote: Of late we have been having allocation problems where the job is unable to allocate the first extent and fails on jcl error etc. Please post the JCL statements and exact JCL error messages so others can help you. Groete / Greetings Elardus Engelbrecht -- 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
Re: SMS QUESTION
Allan Thanks for the help. I have changed the Threshold to 60. Would Space Management (Primary Secondary) be affected because of the new threshold? From: Staller, Allan allan.stal...@kbmg.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, 12 March 2013 1:23 PM Subject: Re: SMS QUESTION I believe your problem is located here: snip Allocation/migration Threshold : High 20 (1-100) Low . . 1 (0-99) /snip IIRC, the HIGH 20 will prevent allocation of new datasets if the PRI space will exceed the high threshold. BTW, IMO, the ALLOC High of 20 is extremely low. I would suggest a number more on the lines of 50 to 80 percent. You will most likely be able to reduce the number of volumes in this pool after the change. HTH, snip Allocation/migration Threshold : High 20 (1-100) Low . . 1 (0-99) Alloc/Migr Threshold Track-Managed: High 85 (1-100) Low . . 1 (0-99) Guaranteed Backup Frequency . . . . . . NOLIMIT (1 to or NOLIMIT) BreakPointValue . . . . . . . . . . . . (0-65520 or blank) Of late we have been having allocation problems where the job is unable to allocate the first extent and fails on jcl error etc. I found the following info which may explain the cause. Am I barking up the wrong tree? If not, if I change the High from 20 to 80 would that address the problem? Also, would HSM miigrate dsn only if the pool is reached 80% or over? MIGR HIGH is also checked during allocation. SMS attempts to select a volume that has enough space available to contain the primary allocation of the new data set without exceeding the MIGR HIGH threshold. /snip -- 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
Re: SMS QUESTION
Allan, While I agree that the High Threshold should be 80 (or in that vicinity), SMS does not PREVENT allocations above the High Threshold, it merely tries to direct them to a volume below that threshold. The last line of the error msg. is the problem. 51 volumes lack the free space to allow the allocation. The solution would be to add volumes to the pool OR allow for a multi-volume file. Use a smaller Primary space allocation and use UNIT=(3390,10) in your DD statement. The 10 is just an example, the upper limit is 59. Regards, Dave O'Brien -Original Message- From: Staller, Allan [mailto:allan.stal...@kbmg.com] Sent: Tuesday, March 12, 2013 1:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS QUESTION I believe your problem is located here: snip Allocation/migration Threshold : High20 (1-100) Low . . 1 (0-99) /snip IIRC, the HIGH 20 will prevent allocation of new datasets if the PRI space will exceed the high threshold. BTW, IMO, the ALLOC High of 20 is extremely low. I would suggest a number more on the lines of 50 to 80 percent. You will most likely be able to reduce the number of volumes in this pool after the change. HTH, snip Allocation/migration Threshold : High 20 (1-100) Low . . 1 (0-99) Alloc/Migr Threshold Track-Managed: High 85 (1-100) Low . . 1 (0-99) Guaranteed Backup Frequency . . . . . . NOLIMIT (1 to or NOLIMIT) BreakPointValue . . . . . . . . . . . . (0-65520 or blank) Of late we have been having allocation problems where the job is unable to allocate the first extent and fails on jcl error etc. I found the following info which may explain the cause. Am I barking up the wrong tree? If not, if I change the High from 20 to 80 would that address the problem? Also, would HSM miigrate dsn only if the pool is reached 80% or over? MIGR HIGH is also checked during allocation. SMS attempts to select a volume that has enough space available to contain the primary allocation of the new data set without exceeding the MIGR HIGH threshold. /snip -- 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
Re: SMS QUESTION
What if *all* of the volumes are at/near the high threshold (20%)? Very often there are candidate volumes defined to SMS, but that do not physically exist (which could be the 51 volumes lacking space for the allocation). snip While I agree that the High Threshold should be 80 (or in that vicinity), SMS does not PREVENT allocations above the High Threshold, it merely tries to direct them to a volume below that threshold. The last line of the error msg. is the problem. 51 volumes lack the free space to allow the allocation. The solution would be to add volumes to the pool OR allow for a multi-volume file. Use a smaller Primary space allocation and use UNIT=(3390,10) in your DD statement. The 10 is just an example, the upper limit is 59. /snip I believe your problem is located here: snip Allocation/migration Threshold : High20 (1-100) Low . . 1 (0-99) /snip IIRC, the HIGH 20 will prevent allocation of new datasets if the PRI space will exceed the high threshold. BTW, IMO, the ALLOC High of 20 is extremely low. I would suggest a number more on the lines of 50 to 80 percent. You will most likely be able to reduce the number of volumes in this pool after the change. HTH, snip Allocation/migration Threshold : High 20 (1-100) Low . . 1 (0-99) Alloc/Migr Threshold Track-Managed: High 85 (1-100) Low . . 1 (0-99) Guaranteed Backup Frequency . . . . . . NOLIMIT (1 to or NOLIMIT) BreakPointValue . . . . . . . . . . . . (0-65520 or blank) Of late we have been having allocation problems where the job is unable to allocate the first extent and fails on jcl error etc. I found the following info which may explain the cause. Am I barking up the wrong tree? If not, if I change the High from 20 to 80 would that address the problem? Also, would HSM miigrate dsn only if the pool is reached 80% or over? MIGR HIGH is also checked during allocation. SMS attempts to select a volume that has enough space available to contain the primary allocation of the new data set without exceeding the MIGR HIGH threshold. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS QUESTION
No, volumes which are above the threshold but have available space are put into a secondary allocation list. Those volumes under the high threshold are in a primary allocation list. SMS then searches for a volume which will satisfy the allocation. At least that's the way it was explained to me by IBM at the Share meeting in Baltimore some years ago. The OP has 51 volumes with available space which are either badly fragmented or do not have 20K tracks within 5 extents. A smaller primary and secondary with a unit parameter specifying multiple volumes will allow the allocation. -Original Message- From: Staller, Allan [mailto:allan.stal...@kbmg.com] Sent: Tuesday, March 12, 2013 1:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS QUESTION What if *all* of the volumes are at/near the high threshold (20%)? Very often there are candidate volumes defined to SMS, but that do not physically exist (which could be the 51 volumes lacking space for the allocation). snip While I agree that the High Threshold should be 80 (or in that vicinity), SMS does not PREVENT allocations above the High Threshold, it merely tries to direct them to a volume below that threshold. The last line of the error msg. is the problem. 51 volumes lack the free space to allow the allocation. The solution would be to add volumes to the pool OR allow for a multi-volume file. Use a smaller Primary space allocation and use UNIT=(3390,10) in your DD statement. The 10 is just an example, the upper limit is 59. /snip I believe your problem is located here: snip Allocation/migration Threshold : High20 (1-100) Low . . 1 (0-99) /snip IIRC, the HIGH 20 will prevent allocation of new datasets if the PRI space will exceed the high threshold. BTW, IMO, the ALLOC High of 20 is extremely low. I would suggest a number more on the lines of 50 to 80 percent. You will most likely be able to reduce the number of volumes in this pool after the change. HTH, snip Allocation/migration Threshold : High 20 (1-100) Low . . 1 (0-99) Alloc/Migr Threshold Track-Managed: High 85 (1-100) Low . . 1 (0-99) Guaranteed Backup Frequency . . . . . . NOLIMIT (1 to or NOLIMIT) BreakPointValue . . . . . . . . . . . . (0-65520 or blank) Of late we have been having allocation problems where the job is unable to allocate the first extent and fails on jcl error etc. I found the following info which may explain the cause. Am I barking up the wrong tree? If not, if I change the High from 20 to 80 would that address the problem? Also, would HSM miigrate dsn only if the pool is reached 80% or over? MIGR HIGH is also checked during allocation. SMS attempts to select a volume that has enough space available to contain the primary allocation of the new data set without exceeding the MIGR HIGH threshold. /snip -- 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
Re: SMS QUESTION
David, Yes, your understanding is the same as mine. The primary eligible device list contains volumes that will not exceed the max threshold if the primary space is allocated there. This is sorted on performance criteria. The secondary eligible device list has volumes with enough free space to satisfy the primary space request, and my recollection is that this is in free space order. If allocation is not satisfied in the primary list it will fall through to the secondary list. With a high threshold of 20%, most allocation will likely be influenced by space, rather than activity. If you suspect that fragmentation is the problem then have you checked if you have Space Constraint relief set to YES in the DATACLAS used by the data set, or if the % reduction is aggressive enough to counter the fragmentation. Another strategy would be to reduce to space request to something smaller, let's say (TRK(5000,5000),RLSE), and add a unit count so the space is allocated across multiple volumes - UNIT=(,5). Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of O'Brien, David W. (NIH/CIT) [C] Sent: Tuesday, March 12, 2013 11:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] SMS QUESTION No, volumes which are above the threshold but have available space are put into a secondary allocation list. Those volumes under the high threshold are in a primary allocation list. SMS then searches for a volume which will satisfy the allocation. At least that's the way it was explained to me by IBM at the Share meeting in Baltimore some years ago. The OP has 51 volumes with available space which are either badly fragmented or do not have 20K tracks within 5 extents. A smaller primary and secondary with a unit parameter specifying multiple volumes will allow the allocation. -Original Message- From: Staller, Allan [mailto:allan.stal...@kbmg.com] Sent: Tuesday, March 12, 2013 1:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS QUESTION What if *all* of the volumes are at/near the high threshold (20%)? Very often there are candidate volumes defined to SMS, but that do not physically exist (which could be the 51 volumes lacking space for the allocation). snip While I agree that the High Threshold should be 80 (or in that vicinity), SMS does not PREVENT allocations above the High Threshold, it merely tries to direct them to a volume below that threshold. The last line of the error msg. is the problem. 51 volumes lack the free space to allow the allocation. The solution would be to add volumes to the pool OR allow for a multi- volume file. Use a smaller Primary space allocation and use UNIT=(3390,10) in your DD statement. The 10 is just an example, the upper limit is 59. /snip I believe your problem is located here: snip Allocation/migration Threshold : High20 (1-100) Low . . 1 (0-99) /snip IIRC, the HIGH 20 will prevent allocation of new datasets if the PRI space will exceed the high threshold. BTW, IMO, the ALLOC High of 20 is extremely low. I would suggest a number more on the lines of 50 to 80 percent. You will most likely be able to reduce the number of volumes in this pool after the change. HTH, snip Allocation/migration Threshold : High 20 (1-100) Low . . 1 (0-99) Alloc/Migr Threshold Track-Managed: High 85 (1-100) Low . . 1 (0-99) Guaranteed Backup Frequency . . . . . . NOLIMIT (1 to or NOLIMIT) BreakPointValue . . . . . . . . . . . . (0-65520 or blank) Of late we have been having allocation problems where the job is unable to allocate the first extent and fails on jcl error etc. I found the following info which may explain the cause. Am I barking up the wrong tree? If not, if I change the High from 20 to 80 would that address the problem? Also, would HSM miigrate dsn only if the pool is reached 80% or over? MIGR HIGH is also checked during allocation. SMS attempts to select a volume that has enough space available to contain the primary allocation of the new data set without exceeding the MIGR HIGH threshold. /snip -- 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
Re: SMS QUESTION - DATACLAS NOT DEFINED IN SMS ACS
I took another look. No luck. I'll keep on looking. Thanks. From: Staller, Allan allan.stal...@kbmg.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, 15 February 2013 1:19 PM Subject: Re: SMS QUESTION - DATACLAS NOT DEFINED IN SMS ACS I would check the ACS routines. There might be something specific as to who(m) is allowed to assign a DATACLAS. I myself have several cases where the ACS routines will not assign a MGMTCLAS/DATACLAS/STORCLAS, and they must be assigned manually. These values are filtered in my ACS routines by a FILTLIST with only selected individuals. e.g. FILTLIST TRUSTED INCLUDE(uidlist) WHEN (USER = TRUSTED) (construct NE '') SET CONSTRUCT = CONSTRUCT) HTH, snip I am trying to debug a problem. The user is specifying a specific DATACLAS, however it is ignored. I checked the ACS for this DATACLAS but there is no FILTLIST etc. for it. There is however a CONSTRUCT. When I run the job the DATACLAS is respected. The LISTCAT shows the correct DATACLAS. My question is since there is no logic for this DATACLAS in the ACS routine does SMS look at the MC or SC? Also since there is no ACS for this DATACLAS shoudln't there be an error when the VALIDATE is run? /snip -- 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
Re: SMS QUESTION - DATACLAS NOT DEFINED IN SMS ACS
John, The answer to your second question below is no - the VALIDATE might put out a warning message that you have a construct that is not referenced in the DATACLAS, but that is not considered an error. The first question is confusing to me. Are you asking if a failure to assign a DATACLAS will prevent SMS from executing the STORCLAS or MGMTCLAS routines? If so, the answer is no - assigning a DATACLAS is optional. HTH, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Dawes Sent: Monday, February 18, 2013 10:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS QUESTION - DATACLAS NOT DEFINED IN SMS ACS I took another look. No luck. I'll keep on looking. Thanks. snip My question is since there is no logic for this DATACLAS in the ACS routine does SMS look at the MC or SC? Also since there is no ACS for this DATACLAS shoudln't there be an error when the VALIDATE is run? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS QUESTION - DATACLAS NOT DEFINED IN SMS ACS
Greg, Sorry I should have worded my question more clearly. Since there is no rule for this DC (only a construct exists) does the SC or MC cause the allocation to occur? In this case the dsn is being allocated by the DATACLAS LARGE which is correct. I have re-read the ACS for all 4 but I couldn't find out how or what makes the DATACLAS be chosen by SMS. From: Greg Shirey wgshi...@benekeith.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, 18 February 2013 12:00 PM Subject: Re: SMS QUESTION - DATACLAS NOT DEFINED IN SMS ACS John, The answer to your second question below is no - the VALIDATE might put out a warning message that you have a construct that is not referenced in the DATACLAS, but that is not considered an error. The first question is confusing to me. Are you asking if a failure to assign a DATACLAS will prevent SMS from executing the STORCLAS or MGMTCLAS routines? If so, the answer is no - assigning a DATACLAS is optional. HTH, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Dawes Sent: Monday, February 18, 2013 10:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS QUESTION - DATACLAS NOT DEFINED IN SMS ACS I took another look. No luck. I'll keep on looking. Thanks. snip My question is since there is no logic for this DATACLAS in the ACS routine does SMS look at the MC or SC? Also since there is no ACS for this DATACLAS shoudln't there be an error when the VALIDATE is run? -- 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
Re: SMS QUESTION - DATACLAS NOT DEFINED IN SMS ACS
On Mon, 18 Feb 2013 11:32:46 -0800, retired mainframer retired-mainfra...@q.com wrote: It is also possible for the RACF resource owner of a dataset (specified in the RESOWNER field of the DFP operand on the ADDSD command) to have a default data class (specified in the DATACLASS field of the DFP operand of the ADDUSER/ADDGROUP command). SMS will use this value if ACSDEFAULTS is set to YES in the PARMLIB member IGDSMSxx. There's one aspect of the processing you missed, as specified in the RESOWNER field of the DFP operand on the ADDSD command neglects the default processing. If there's no DFP segment in the relevant DATASET profile, or it doesn't specify a RESOWNER, then RACF will assign the HLQ of the DATASET profile (if it's a user ID or group name) as the RESOWNER. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SMS QUESTION - DATACLAS NOT DEFINED IN SMS ACS
G'Day, I am trying to debug a problem. The user is specifying a specific DATACLAS, however it is ignored. I checked the ACS for this DATACLAS but there is no FILTLIST etc. for it. There is however a CONSTRUCT. When I run the job the DATACLAS is respected. The LISTCAT shows the correct DATACLAS. My question is since there is no logic for this DATACLAS in the ACS routine does SMS look at the MC or SC? Also since there is no ACS for this DATACLAS shoudln't there be an error when the VALIDATE is run? Your thoughts would be appreciated. Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS QUESTION - DATACLAS NOT DEFINED IN SMS ACS
I would check the ACS routines. There might be something specific as to who(m) is allowed to assign a DATACLAS. I myself have several cases where the ACS routines will not assign a MGMTCLAS/DATACLAS/STORCLAS, and they must be assigned manually. These values are filtered in my ACS routines by a FILTLIST with only selected individuals. e.g. FILTLIST TRUSTED INCLUDE(uidlist) WHEN (USER = TRUSTED) (construct NE '') SET CONSTRUCT = CONSTRUCT) HTH, snip I am trying to debug a problem. The user is specifying a specific DATACLAS, however it is ignored. I checked the ACS for this DATACLAS but there is no FILTLIST etc. for it. There is however a CONSTRUCT. When I run the job the DATACLAS is respected. The LISTCAT shows the correct DATACLAS. My question is since there is no logic for this DATACLAS in the ACS routine does SMS look at the MC or SC? Also since there is no ACS for this DATACLAS shoudln't there be an error when the VALIDATE is run? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: basic SMS question
If you have corrected the SMS rules then you may use ADRDSSU and the REDETERMINE command to reset the DATACLAS, MGMTCLAS, and STORCLAS for any specific disk volume. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, CP - SPLXM Sent: Monday, February 11, 2013 2:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: basic SMS question -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pew, Curtis G Sent: Friday, February 08, 2013 17:51 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: basic SMS question On Feb 8, 2013, at 10:41 AM, Gibney, Dave gib...@wsu.edu wrote: 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? Exactly. A DATACLAS is a set of defaults applied when the file is created (and any particular attribute set by the DATACLAS may be overridden at creation time.) Once the data set exists, what does it matter what its DATACLAS is? -- Curtis Pew (c@its.utexas.edu) ITS Systems Core The University of Texas at Austin --- This is not true anymore: several new parameters in space constraint relief and dynamic volume count, are also used during the life of a datasets. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This E-mail and any of its attachments may contain Prince George’s County Government or Prince George's County 7th Judicial Circuit Court proprietary information or Protected Health Information, which is privileged and confidential. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited by federal law and may expose you to civil and/or criminal penalties. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: basic SMS question
That's the winner. Thanks. Jim McAlpine On Mon, Feb 11, 2013 at 1:42 PM, Martin, Larry D ldmar...@co.pg.md.uswrote: If you have corrected the SMS rules then you may use ADRDSSU and the REDETERMINE command to reset the DATACLAS, MGMTCLAS, and STORCLAS for any specific disk volume. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, CP - SPLXM Sent: Monday, February 11, 2013 2:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: basic SMS question -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pew, Curtis G Sent: Friday, February 08, 2013 17:51 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: basic SMS question On Feb 8, 2013, at 10:41 AM, Gibney, Dave gib...@wsu.edu wrote: 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? Exactly. A DATACLAS is a set of defaults applied when the file is created (and any particular attribute set by the DATACLAS may be overridden at creation time.) Once the data set exists, what does it matter what its DATACLAS is? -- Curtis Pew (c@its.utexas.edu) ITS Systems Core The University of Texas at Austin --- This is not true anymore: several new parameters in space constraint relief and dynamic volume count, are also used during the life of a datasets. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This E-mail and any of its attachments may contain Prince George’s County Government or Prince George's County 7th Judicial Circuit Court proprietary information or Protected Health Information, which is privileged and confidential. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited by federal law and may expose you to civil and/or criminal penalties. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. -- 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
Re: basic SMS question
Some people create data set reports based a DATACLAS names. Those people are not happy when their reports are wrong. ALso DATACLAS has at least one dynamic attribute, Dynamic Volume Count. Changes to Dynamic Volume Count affect existing data sets. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, CP - SPLXM Sent: Monday, February 11, 2013 2:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: basic SMS question -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pew, Curtis G Sent: Friday, February 08, 2013 17:51 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: basic SMS question On Feb 8, 2013, at 10:41 AM, Gibney, Dave gib...@wsu.edu wrote: 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? Exactly. A DATACLAS is a set of defaults applied when the file is created (and any particular attribute set by the DATACLAS may be overridden at creation time.) Once the data set exists, what does it matter what its DATACLAS is? -- Curtis Pew (c@its.utexas.edu) ITS Systems Core The University of Texas at Austin --- This is not true anymore: several new parameters in space constraint relief and dynamic volume count, are also used during the life of a datasets. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e- mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- 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
Re: basic SMS question
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pew, Curtis G Sent: Friday, February 08, 2013 17:51 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: basic SMS question On Feb 8, 2013, at 10:41 AM, Gibney, Dave gib...@wsu.edu wrote: 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? Exactly. A DATACLAS is a set of defaults applied when the file is created (and any particular attribute set by the DATACLAS may be overridden at creation time.) Once the data set exists, what does it matter what its DATACLAS is? -- Curtis Pew (c@its.utexas.edu) ITS Systems Core The University of Texas at Austin --- This is not true anymore: several new parameters in space constraint relief and dynamic volume count, are also used during the life of a datasets. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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.comwrote: 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
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.comwrote: 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
Re: basic SMS question
Thanks Mike. Jim On Fri, Feb 8, 2013 at 11:35 AM, Mike Schwab mike.a.sch...@gmail.comwrote: 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.comwrote: 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
Re: basic SMS question
ALTER data.set.name DATACLAS(newvalue) DATACLAS is not an optional parameter to IDCAMS ALTER -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: basic SMS question
Correct, very irritating restriction. You can MOVE the dataset with DFDSS and provide a new DATACLAS then. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Brian Fraser Sent: Friday, February 08, 2013 13:23 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: basic SMS question ALTER data.set.name DATACLAS(newvalue) DATACLAS is not an optional parameter to IDCAMS ALTER -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: basic SMS question
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.comwrote: 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
Re: basic SMS question
IIRC, not a DFDMDdss COPY option, either. DSS does not reformat data. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, CP - SPLXM Sent: Friday, February 08, 2013 7:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: basic SMS question Correct, very irritating restriction. You can MOVE the dataset with DFDSS and provide a new DATACLAS then. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Brian Fraser Sent: Friday, February 08, 2013 13:23 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: basic SMS question ALTER data.set.name DATACLAS(newvalue) DATACLAS is not an optional parameter to IDCAMS ALTER -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e- mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- 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
Re: basic SMS question
That is correct see http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.idas200%2Fs2010.htm Thank You, Dave O'Brien NIH Contractor From: Don Williams [donb...@gmail.com] Sent: Friday, February 08, 2013 9:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: basic SMS question IIRC, not a DFDMDdss COPY option, either. DSS does not reformat data. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, CP - SPLXM Sent: Friday, February 08, 2013 7:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: basic SMS question Correct, very irritating restriction. You can MOVE the dataset with DFDSS and provide a new DATACLAS then. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Brian Fraser Sent: Friday, February 08, 2013 13:23 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: basic SMS question ALTER data.set.name DATACLAS(newvalue) DATACLAS is not an optional parameter to IDCAMS ALTER -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e- mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- 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
Re: basic SMS question
Ok, then I did it with CA-DISK or FDR. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of O'Brien, David W. (NIH/CIT) [C] Sent: Friday, February 08, 2013 16:15 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: basic SMS question That is correct see http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fco m.ibm.zos.r12.idas200%2Fs2010.htm Thank You, Dave O'Brien NIH Contractor From: Don Williams [donb...@gmail.com] Sent: Friday, February 08, 2013 9:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: basic SMS question IIRC, not a DFDMDdss COPY option, either. DSS does not reformat data. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, CP - SPLXM Sent: Friday, February 08, 2013 7:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: basic SMS question Correct, very irritating restriction. You can MOVE the dataset with DFDSS and provide a new DATACLAS then. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Brian Fraser Sent: Friday, February 08, 2013 13:23 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: basic SMS question ALTER data.set.name DATACLAS(newvalue) DATACLAS is not an optional parameter to IDCAMS ALTER -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e- mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- 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 For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: basic SMS question
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.comwrote: 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
basic SMS question
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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: basic SMS question
You are not exiting the routine after the set Storclas statement. By not exiting you are falling through the code to the last true statement. -Original Message- From: Jim McAlpine [mailto:jim.mcalp...@gmail.com] Sent: Thursday, February 07, 2013 10:14 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: basic SMS question 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 -- 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
Re: basic SMS question
The FILTLIST has DB2E defined. I would remove the IF logic and then change the SELECT WHEN from SCSMS to SCDB2 Regards, Doug Sent from my iPhone On Feb 7, 2013, at 10:13, Jim McAlpine jim.mcalp...@gmail.com wrote: 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 -- 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
Re: basic SMS question
First I would consider putting EXIT in your WHEN DO/END statements. Otherwise it will keep parsing the code to find another match. Second, I use WRITE statements in my Do/End code to ensure I got where I Thought I was going. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim McAlpine Sent: Thursday, February 07, 2013 8:14 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: basic SMS question 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: basic SMS question
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
Re: basic SMS question
Thanks for the explanation. Much appreciated. Jim McAlpine On Thu, Feb 7, 2013 at 3:51 PM, Darth Keller darth.kel...@assurant.comwrote: 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
Re: SMS question
On Mon, 25 Jun 2012 14:32:34 -0700, John Norgauer john.norga...@ucdmc.ucdavis.edu wrote: I had to change my SYSNAME and now when I start SMS the system is asking for the COMMDS data set name. I changed the SYSNAME in the CDS BASE, I activated the CDS and got the message: ACTIVATION SCHEDULED. But the system still does not accept the name of the COMMDS. What am I not doing? I don't know if this is the only answer, but it is the way I've done it. You have to add in the new SYSID / sysplex name before you do the name change of the sysname / sysplex. Then you can delete the old name from the CDS one after you come up on the new name. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
