Need to make a catalog entry for a SMS managed Virtual tape
Hi, Had a group of SMS managed virtual tapes be accidently scratched and I'm trying to recreate the entries. Updated CA-1 okay and the tapes are still on the stacked drives and marked private there, but my question is around the MVS catalog entry. I tried to do IDCAMS define nonvsam name, decivetype and volume entries and then use alter rollin to re-attach them to the base but alter won't work because they're not SMS managed. Define Nonvsam would let me include SMS constructs, and I can't alter it a SMS storage class either. There has to be a way to make a MVS catalog entry of a tape gdg, and then roll it into the base. What have I forgot? Jim -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Need to make a catalog entry for a SMS managed Virtual tape
Are the volume serial numbers in the TCDB? I.e. the SMS Tape Control Data Base, which is usually name SYS1.VOLCAT.VGENERAL. I would bet that they are not. So you must run a ALTER command. We do this a lot at DR and have a REXX program: /* REXX */ PARSE ARG INVOL ALTER VINVOL VOLENT STORGRP(SGRTAPE2) , LIBNAME($ATL0002) LOCATION(LIBRARY) UATTR(PRIVATE) //.. idcams jcl %ALTERVOL volser /* //* ONE PER VOLUME SERIAL. I bet your DEF NVSAM is OK. One that I have is: DEF NVSAM(NAME(TSHPG.CICSMGR.P8.DAILY.HISTORY.G2422V00) - DEVT(3490) - VOL(238263)) ALTER V238263 VOLENT STORGRP(SGRTAPE2) - LIBNAME($ATL0002) LOCATION(LIBRARY) UATTR(PRIVATE) You need both. I am not sure, but you might be able to get away with doing the DEF NVSAM, followed by a CTSSYNC from CA-1. I'm not sure. John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Darby, Jim Sent: Monday, June 11, 2012 12:41 PM To: IBM-MAIN@bama.ua.edu Subject: Need to make a catalog entry for a SMS managed Virtual tape Hi, Had a group of SMS managed virtual tapes be accidently scratched and I'm trying to recreate the entries. Updated CA-1 okay and the tapes are still on the stacked drives and marked private there, but my question is around the MVS catalog entry. I tried to do IDCAMS define nonvsam name, decivetype and volume entries and then use alter rollin to re-attach them to the base but alter won't work because they're not SMS managed. Define Nonvsam would let me include SMS constructs, and I can't alter it a SMS storage class either. There has to be a way to make a MVS catalog entry of a tape gdg, and then roll it into the base. What have I forgot? Jim -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Need to make a catalog entry for a SMS managed Virtual tape
No my TCDB is okay, so both CA-1 and OAM know that the tape is private and where it is. My problem is with MVS. Define nonvsam makes it a non-sms entry in the MVS catalog and when I try to run the Alter command to roll it back into the gdg base, it fails and tells me I can rollin an non SMS dataset. Gives me the IDC3195I message: IDC3195I OBJECT IS NOT SMS MANAGED Explanation: An access method services ALTER command requested that a generation data set (GDS) be rolled in, but the GDS is not managed by the storage management subsystem (SMS). Thoughts? Jim -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Monday, June 11, 2012 10:58 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to make a catalog entry for a SMS managed Virtual tape Are the volume serial numbers in the TCDB? I.e. the SMS Tape Control Data Base, which is usually name SYS1.VOLCAT.VGENERAL. I would bet that they are not. So you must run a ALTER command. We do this a lot at DR and have a REXX program: /* REXX */ PARSE ARG INVOL ALTER VINVOL VOLENT STORGRP(SGRTAPE2) , LIBNAME($ATL0002) LOCATION(LIBRARY) UATTR(PRIVATE) //.. idcams jcl %ALTERVOL volser /* //* ONE PER VOLUME SERIAL. I bet your DEF NVSAM is OK. One that I have is: DEF NVSAM(NAME(TSHPG.CICSMGR.P8.DAILY.HISTORY.G2422V00) - DEVT(3490) - VOL(238263)) ALTER V238263 VOLENT STORGRP(SGRTAPE2) - LIBNAME($ATL0002) LOCATION(LIBRARY) UATTR(PRIVATE) You need both. I am not sure, but you might be able to get away with doing the DEF NVSAM, followed by a CTSSYNC from CA-1. I'm not sure. John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Darby, Jim Sent: Monday, June 11, 2012 12:41 PM To: IBM-MAIN@bama.ua.edu Subject: Need to make a catalog entry for a SMS managed Virtual tape Hi, Had a group of SMS managed virtual tapes be accidently scratched and I'm trying to recreate the entries. Updated CA-1 okay and the tapes are still on the stacked drives and marked private there, but my question is around the MVS catalog entry. I tried to do IDCAMS define nonvsam name, decivetype and volume entries and then use alter rollin to re-attach them to the base but alter won't work because they're not SMS managed. Define Nonvsam would let me include SMS constructs, and I can't alter it a SMS storage class either. There has to be a way to make a MVS catalog entry of a tape gdg, and then roll it into the base. What have I forgot? Jim -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Need to make a catalog entry for a SMS managed Virtual tape
Try to read it (maybe just 1 record) using DISP=(OLD,CATLG). On Mon, Jun 11, 2012 at 1:09 PM, Darby, Jim jim.da...@nordstrom.com wrote: No my TCDB is okay, so both CA-1 and OAM know that the tape is private and where it is. My problem is with MVS. Define nonvsam makes it a non-sms entry in the MVS catalog and when I try to run the Alter command to roll it back into the gdg base, it fails and tells me I can rollin an non SMS dataset. Gives me the IDC3195I message: IDC3195I OBJECT IS NOT SMS MANAGED Explanation: An access method services ALTER command requested that a generation data set (GDS) be rolled in, but the GDS is not managed by the storage management subsystem (SMS). Thoughts? Jim -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Monday, June 11, 2012 10:58 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to make a catalog entry for a SMS managed Virtual tape Are the volume serial numbers in the TCDB? I.e. the SMS Tape Control Data Base, which is usually name SYS1.VOLCAT.VGENERAL. I would bet that they are not. So you must run a ALTER command. We do this a lot at DR and have a REXX program: /* REXX */ PARSE ARG INVOL ALTER VINVOL VOLENT STORGRP(SGRTAPE2) , LIBNAME($ATL0002) LOCATION(LIBRARY) UATTR(PRIVATE) //.. idcams jcl %ALTERVOL volser /* //* ONE PER VOLUME SERIAL. I bet your DEF NVSAM is OK. One that I have is: DEF NVSAM(NAME(TSHPG.CICSMGR.P8.DAILY.HISTORY.G2422V00) - DEVT(3490) - VOL(238263)) ALTER V238263 VOLENT STORGRP(SGRTAPE2) - LIBNAME($ATL0002) LOCATION(LIBRARY) UATTR(PRIVATE) You need both. I am not sure, but you might be able to get away with doing the DEF NVSAM, followed by a CTSSYNC from CA-1. I'm not sure. John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Darby, Jim Sent: Monday, June 11, 2012 12:41 PM To: IBM-MAIN@bama.ua.edu Subject: Need to make a catalog entry for a SMS managed Virtual tape Hi, Had a group of SMS managed virtual tapes be accidently scratched and I'm trying to recreate the entries. Updated CA-1 okay and the tapes are still on the stacked drives and marked private there, but my question is around the MVS catalog entry. I tried to do IDCAMS define nonvsam name, decivetype and volume entries and then use alter rollin to re-attach them to the base but alter won't work because they're not SMS managed. Define Nonvsam would let me include SMS constructs, and I can't alter it a SMS storage class either. There has to be a way to make a MVS catalog entry of a tape gdg, and then roll it into the base. What have I forgot? Jim -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Need to make a catalog entry for a SMS managed Virtual tape
I can read the dataset just fine by asking for it by complete name, what I need to do is to get in rolled back into the gdg base so it can be accessed as the 0 gen or -1 and so forth. Right now it isn't part of the gdg group. Jim -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mike Schwab Sent: Monday, June 11, 2012 12:09 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to make a catalog entry for a SMS managed Virtual tape Try to read it (maybe just 1 record) using DISP=(OLD,CATLG). On Mon, Jun 11, 2012 at 1:09 PM, Darby, Jim jim.da...@nordstrom.com wrote: No my TCDB is okay, so both CA-1 and OAM know that the tape is private and where it is. My problem is with MVS. Define nonvsam makes it a non-sms entry in the MVS catalog and when I try to run the Alter command to roll it back into the gdg base, it fails and tells me I can rollin an non SMS dataset. Gives me the IDC3195I message: IDC3195I OBJECT IS NOT SMS MANAGED Explanation: An access method services ALTER command requested that a generation data set (GDS) be rolled in, but the GDS is not managed by the storage management subsystem (SMS). Thoughts? Jim -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Monday, June 11, 2012 10:58 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to make a catalog entry for a SMS managed Virtual tape Are the volume serial numbers in the TCDB? I.e. the SMS Tape Control Data Base, which is usually name SYS1.VOLCAT.VGENERAL. I would bet that they are not. So you must run a ALTER command. We do this a lot at DR and have a REXX program: /* REXX */ PARSE ARG INVOL ALTER VINVOL VOLENT STORGRP(SGRTAPE2) , LIBNAME($ATL0002) LOCATION(LIBRARY) UATTR(PRIVATE) //.. idcams jcl %ALTERVOL volser /* //* ONE PER VOLUME SERIAL. I bet your DEF NVSAM is OK. One that I have is: DEF NVSAM(NAME(TSHPG.CICSMGR.P8.DAILY.HISTORY.G2422V00) - DEVT(3490) - VOL(238263)) ALTER V238263 VOLENT STORGRP(SGRTAPE2) - LIBNAME($ATL0002) LOCATION(LIBRARY) UATTR(PRIVATE) You need both. I am not sure, but you might be able to get away with doing the DEF NVSAM, followed by a CTSSYNC from CA-1. I'm not sure. John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Darby, Jim Sent: Monday, June 11, 2012 12:41 PM To: IBM-MAIN@bama.ua.edu Subject: Need to make a catalog entry for a SMS managed Virtual tape Hi, Had a group of SMS managed virtual tapes be accidently scratched and I'm trying to recreate the entries. Updated CA-1 okay and the tapes are still on the stacked drives and marked private there, but my question is around the MVS catalog entry. I tried to do IDCAMS define nonvsam name, decivetype and volume entries and then use alter rollin to re-attach them to the base but alter won't work because they're not SMS managed. Define Nonvsam would let me include SMS constructs, and I can't alter it a SMS storage class either. There has to be a way to make a MVS catalog entry of a tape gdg, and then roll it into the base. What have I forgot? Jim - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Need to make a catalog entry for a SMS managed Virtual tape
As long as your GDG base has room to handle the additional generation, then all you have to do is a define nonvsam with your tape number. You don't have to roll it in. Have done this several times in our shop. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Darby, Jim Sent: Monday, June 11, 2012 3:57 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to make a catalog entry for a SMS managed Virtual tape I can read the dataset just fine by asking for it by complete name, what I need to do is to get in rolled back into the gdg base so it can be accessed as the 0 gen or -1 and so forth. Right now it isn't part of the gdg group. Jim -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mike Schwab Sent: Monday, June 11, 2012 12:09 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to make a catalog entry for a SMS managed Virtual tape Try to read it (maybe just 1 record) using DISP=(OLD,CATLG). On Mon, Jun 11, 2012 at 1:09 PM, Darby, Jim jim.da...@nordstrom.com wrote: No my TCDB is okay, so both CA-1 and OAM know that the tape is private and where it is. My problem is with MVS. Define nonvsam makes it a non-sms entry in the MVS catalog and when I try to run the Alter command to roll it back into the gdg base, it fails and tells me I can rollin an non SMS dataset. Gives me the IDC3195I message: IDC3195I OBJECT IS NOT SMS MANAGED Explanation: An access method services ALTER command requested that a generation data set (GDS) be rolled in, but the GDS is not managed by the storage management subsystem (SMS). Thoughts? Jim -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Monday, June 11, 2012 10:58 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to make a catalog entry for a SMS managed Virtual tape Are the volume serial numbers in the TCDB? I.e. the SMS Tape Control Data Base, which is usually name SYS1.VOLCAT.VGENERAL. I would bet that they are not. So you must run a ALTER command. We do this a lot at DR and have a REXX program: /* REXX */ PARSE ARG INVOL ALTER VINVOL VOLENT STORGRP(SGRTAPE2) , LIBNAME($ATL0002) LOCATION(LIBRARY) UATTR(PRIVATE) //.. idcams jcl %ALTERVOL volser /* //* ONE PER VOLUME SERIAL. I bet your DEF NVSAM is OK. One that I have is: DEF NVSAM(NAME(TSHPG.CICSMGR.P8.DAILY.HISTORY.G2422V00) - DEVT(3490) - VOL(238263)) ALTER V238263 VOLENT STORGRP(SGRTAPE2) - LIBNAME($ATL0002) LOCATION(LIBRARY) UATTR(PRIVATE) You need both. I am not sure, but you might be able to get away with doing the DEF NVSAM, followed by a CTSSYNC from CA-1. I'm not sure. John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Darby, Jim Sent: Monday, June 11, 2012 12:41 PM To: IBM-MAIN@bama.ua.edu Subject: Need to make a catalog entry for a SMS managed Virtual tape Hi, Had a group of SMS managed virtual tapes be accidently scratched and I'm trying to recreate the entries. Updated CA-1 okay and the tapes are still on the stacked drives and marked private there, but my question is around the MVS catalog entry. I tried to do IDCAMS define nonvsam name, decivetype and volume entries and then use alter rollin to re-attach them to the base but alter won't work because they're not SMS managed. Define Nonvsam would let me include SMS constructs, and I can't alter it a SMS storage class either. There has to be a way to make a MVS catalog entry of a tape gdg, and then roll it into the base. What have I forgot? Jim - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff
Re: Need to make a catalog entry for a SMS managed Virtual tape
And you are correct. I expected to have to roll in it. Thanks, Jim -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Hervey Martinez Sent: Monday, June 11, 2012 1:47 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to make a catalog entry for a SMS managed Virtual tape As long as your GDG base has room to handle the additional generation, then all you have to do is a define nonvsam with your tape number. You don't have to roll it in. Have done this several times in our shop. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Darby, Jim Sent: Monday, June 11, 2012 3:57 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to make a catalog entry for a SMS managed Virtual tape I can read the dataset just fine by asking for it by complete name, what I need to do is to get in rolled back into the gdg base so it can be accessed as the 0 gen or -1 and so forth. Right now it isn't part of the gdg group. Jim -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mike Schwab Sent: Monday, June 11, 2012 12:09 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to make a catalog entry for a SMS managed Virtual tape Try to read it (maybe just 1 record) using DISP=(OLD,CATLG). On Mon, Jun 11, 2012 at 1:09 PM, Darby, Jim jim.da...@nordstrom.com wrote: No my TCDB is okay, so both CA-1 and OAM know that the tape is private and where it is. My problem is with MVS. Define nonvsam makes it a non-sms entry in the MVS catalog and when I try to run the Alter command to roll it back into the gdg base, it fails and tells me I can rollin an non SMS dataset. Gives me the IDC3195I message: IDC3195I OBJECT IS NOT SMS MANAGED Explanation: An access method services ALTER command requested that a generation data set (GDS) be rolled in, but the GDS is not managed by the storage management subsystem (SMS). Thoughts? Jim -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Monday, June 11, 2012 10:58 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to make a catalog entry for a SMS managed Virtual tape Are the volume serial numbers in the TCDB? I.e. the SMS Tape Control Data Base, which is usually name SYS1.VOLCAT.VGENERAL. I would bet that they are not. So you must run a ALTER command. We do this a lot at DR and have a REXX program: /* REXX */ PARSE ARG INVOL ALTER VINVOL VOLENT STORGRP(SGRTAPE2) , LIBNAME($ATL0002) LOCATION(LIBRARY) UATTR(PRIVATE) //.. idcams jcl %ALTERVOL volser /* //* ONE PER VOLUME SERIAL. I bet your DEF NVSAM is OK. One that I have is: DEF NVSAM(NAME(TSHPG.CICSMGR.P8.DAILY.HISTORY.G2422V00) - DEVT(3490) - VOL(238263)) ALTER V238263 VOLENT STORGRP(SGRTAPE2) - LIBNAME($ATL0002) LOCATION(LIBRARY) UATTR(PRIVATE) You need both. I am not sure, but you might be able to get away with doing the DEF NVSAM, followed by a CTSSYNC from CA-1. I'm not sure. John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Darby, Jim Sent: Monday, June 11, 2012 12:41 PM To: IBM-MAIN@bama.ua.edu Subject: Need to make a catalog entry for a SMS managed Virtual tape Hi, Had a group of SMS managed virtual tapes be accidently scratched and I'm trying to recreate the entries. Updated CA-1 okay and the tapes are still on the stacked drives and marked private there, but my question is around the MVS catalog entry. I tried to do IDCAMS define nonvsam name, decivetype and volume entries and then use alter rollin to re-attach them to the base but alter won't work because they're not SMS managed. Define Nonvsam would let me include SMS constructs, and I can't alter it a SMS storage class either. There has to be a way to make a MVS catalog entry of a tape gdg, and then roll it into the base. What have I forgot? Jim - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO
Re: Need to make a catalog entry for a SMS managed Virtual tape
You can try copying the GDG to a V01 gen //STEP1 EXEC PGM=IEBGENER //SYSPRINT DD SYSOUT=* //SYSUT1 DD DISP=SHR,DSN=currentGDG.GV00 //SYSUT2 DD DISP=(,CATLG,DELETE),UNIT=tape, //DSN=currentGDG.GV01 //SYSINDD DUMMY You are replacing the GDG number with the next version of the same GDG number. Wild shot but might work. It should be located right where you want it. And it is accessible as a GDG(0) if that is the correct position. Lizette -Original Message- From: Hervey Martinez hervey.marti...@custserv.com Sent: Jun 11, 2012 1:47 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to make a catalog entry for a SMS managed Virtual tape As long as your GDG base has room to handle the additional generation, then all you have to do is a define nonvsam with your tape number. You don't have to roll it in. Have done this several times in our shop. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Darby, Jim Sent: Monday, June 11, 2012 3:57 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to make a catalog entry for a SMS managed Virtual tape I can read the dataset just fine by asking for it by complete name, what I need to do is to get in rolled back into the gdg base so it can be accessed as the 0 gen or -1 and so forth. Right now it isn't part of the gdg group. Jim -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mike Schwab Sent: Monday, June 11, 2012 12:09 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to make a catalog entry for a SMS managed Virtual tape Try to read it (maybe just 1 record) using DISP=(OLD,CATLG). On Mon, Jun 11, 2012 at 1:09 PM, Darby, Jim jim.da...@nordstrom.com wrote: No my TCDB is okay, so both CA-1 and OAM know that the tape is private and where it is. My problem is with MVS. Define nonvsam makes it a non-sms entry in the MVS catalog and when I try to run the Alter command to roll it back into the gdg base, it fails and tells me I can rollin an non SMS dataset. Gives me the IDC3195I message: IDC3195I OBJECT IS NOT SMS MANAGED Explanation: An access method services ALTER command requested that a generation data set (GDS) be rolled in, but the GDS is not managed by the storage management subsystem (SMS). Thoughts? Jim -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Monday, June 11, 2012 10:58 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to make a catalog entry for a SMS managed Virtual tape Are the volume serial numbers in the TCDB? I.e. the SMS Tape Control Data Base, which is usually name SYS1.VOLCAT.VGENERAL. I would bet that they are not. So you must run a ALTER command. We do this a lot at DR and have a REXX program: /* REXX */ PARSE ARG INVOL ALTER VINVOL VOLENT STORGRP(SGRTAPE2) , LIBNAME($ATL0002) LOCATION(LIBRARY) UATTR(PRIVATE) //.. idcams jcl %ALTERVOL volser /* //* ONE PER VOLUME SERIAL. I bet your DEF NVSAM is OK. One that I have is: DEF NVSAM(NAME(TSHPG.CICSMGR.P8.DAILY.HISTORY.G2422V00) - DEVT(3490) - VOL(238263)) ALTER V238263 VOLENT STORGRP(SGRTAPE2) - LIBNAME($ATL0002) LOCATION(LIBRARY) UATTR(PRIVATE) You need both. I am not sure, but you might be able to get away with doing the DEF NVSAM, followed by a CTSSYNC from CA-1. I'm not sure. John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Darby, Jim Sent: Monday, June 11, 2012 12:41 PM To: IBM-MAIN@bama.ua.edu Subject: Need to make a catalog entry for a SMS managed Virtual tape Hi, Had a group of SMS managed virtual tapes be accidently scratched and I'm trying to recreate the entries. Updated CA-1 okay and the tapes are still on the stacked drives and marked private there, but my question is around the MVS catalog entry. I tried to do IDCAMS define nonvsam name, decivetype and volume entries and then use alter rollin to re-attach them to the base but alter won't work because they're not SMS managed. Define Nonvsam would let me include SMS constructs, and I can't alter it a SMS storage class either. There has to be a way to make a MVS catalog entry of a tape gdg, and then roll it into the base. What have I forgot? Jim -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Need to make a catalog entry for a SMS managed Virtual tape
http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.idad400%2Froll.htm Issue the IDCAMS ALTER hlq.data.set.name ROLLIN command to pickup cataloged datasets into the GDG. On Mon, Jun 11, 2012 at 2:57 PM, Darby, Jim jim.da...@nordstrom.com wrote: I can read the dataset just fine by asking for it by complete name, what I need to do is to get in rolled back into the gdg base so it can be accessed as the 0 gen or -1 and so forth. Right now it isn't part of the gdg group. Jim -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mike Schwab Sent: Monday, June 11, 2012 12:09 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to make a catalog entry for a SMS managed Virtual tape Try to read it (maybe just 1 record) using DISP=(OLD,CATLG). On Mon, Jun 11, 2012 at 1:09 PM, Darby, Jim jim.da...@nordstrom.com wrote: No my TCDB is okay, so both CA-1 and OAM know that the tape is private and where it is. My problem is with MVS. Define nonvsam makes it a non-sms entry in the MVS catalog and when I try to run the Alter command to roll it back into the gdg base, it fails and tells me I can rollin an non SMS dataset. Gives me the IDC3195I message: IDC3195I OBJECT IS NOT SMS MANAGED Explanation: An access method services ALTER command requested that a generation data set (GDS) be rolled in, but the GDS is not managed by the storage management subsystem (SMS). Thoughts? Jim -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Monday, June 11, 2012 10:58 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to make a catalog entry for a SMS managed Virtual tape Are the volume serial numbers in the TCDB? I.e. the SMS Tape Control Data Base, which is usually name SYS1.VOLCAT.VGENERAL. I would bet that they are not. So you must run a ALTER command. We do this a lot at DR and have a REXX program: /* REXX */ PARSE ARG INVOL ALTER VINVOL VOLENT STORGRP(SGRTAPE2) , LIBNAME($ATL0002) LOCATION(LIBRARY) UATTR(PRIVATE) //.. idcams jcl %ALTERVOL volser /* //* ONE PER VOLUME SERIAL. I bet your DEF NVSAM is OK. One that I have is: DEF NVSAM(NAME(TSHPG.CICSMGR.P8.DAILY.HISTORY.G2422V00) - DEVT(3490) - VOL(238263)) ALTER V238263 VOLENT STORGRP(SGRTAPE2) - LIBNAME($ATL0002) LOCATION(LIBRARY) UATTR(PRIVATE) You need both. I am not sure, but you might be able to get away with doing the DEF NVSAM, followed by a CTSSYNC from CA-1. I'm not sure. John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Darby, Jim Sent: Monday, June 11, 2012 12:41 PM To: IBM-MAIN@bama.ua.edu Subject: Need to make a catalog entry for a SMS managed Virtual tape Hi, Had a group of SMS managed virtual tapes be accidently scratched and I'm trying to recreate the entries. Updated CA-1 okay and the tapes are still on the stacked drives and marked private there, but my question is around the MVS catalog entry. I tried to do IDCAMS define nonvsam name, decivetype and volume entries and then use alter rollin to re-attach them to the base but alter won't work because they're not SMS managed. Define Nonvsam would let me include SMS constructs, and I can't alter it a SMS storage class either. There has to be a way to make a MVS catalog entry of a tape gdg, and then roll it into the base. What have I forgot? Jim - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.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
Re: STK SMC/HSC and SMS Tape
If SMS TCDB (aka VOLCAT) has a volume entry SMS111, the DD1 allocation with DISP=OLD goes to the SMS Tape Library even though SMC/HSC control data set has a volume entry SMS111 for the volume in the SILO. As you know, DISP=NEW allocation is controlled by SMS ACS routines you wrote. If you want to allocate the volume SMS111 on the SILO, you have to add STORCLAS=DUPT@SMS parameter in the DD1 DD JCL. (If SMS TCDB has the volume entry SMS111) Minoru Massaki (M*M) 2012/6/3 Tom Williamson t...@dtssoftware.com: Hello, We have a customer that is doing some tape migration. They are currently using STK SMC manage their SILO. If we create a SMS Tape Library (MTL) and add a volume to it that is also in the SILO which unit will be picked by allocation? There is a statement in the SMC manual that says SMC will ignore SMS Managed Devices. It actually talks about SMS Dataset also. But while sms tape is a sms managed device I am not sure that a dataset that references a sms managed tape is a sms managed dataset? //DD1 DD UNIT=TAPE,DISP=OLD,VOL=SER=SMS111 If SMS111 is also in the SILO will SMC change the allocation to the SILO or leave it alone? Thanks for any help Tom -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- 全先 実 - Minoru Massaki (M*M) E-mail: mmass...@gmail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: STK SMC/HSC and SMS Tape
On Sun, 3 Jun 2012 03:21:33 +, Tom Williamson t...@dtssoftware.com wrote: Hello, We have a customer that is doing some tape migration. They are currently using STK SMC manage their SILO. If we create a SMS Tape Library (MTL) and add a volume to it that is also in the SILO which unit will be picked by allocation? There is a statement in the SMC manual that says SMC will ignore SMS Managed Devices. It actually talks about SMS Dataset also. But while sms tape is a sms managed device I am not sure that a dataset that references a sms managed tape is a sms managed dataset? //DD1 DD UNIT=TAPE,DISP=OLD,VOL=SER=SMS111 If SMS111 is also in the SILO will SMC change the allocation to the SILO or leave it alone? Thanks for any help Tom I've run both together, but never with duplicate volsers. HSC/SMC was using TAPEREQ to control allocations, not SMS.SMC eliminates devices from the EDL when it know the tape is one of its own, but I'm not sure if that is before or after SMS gets involved. Either way, STORCLAS=DUPT@SMS should let you get at the STK tape in the ACS. Regards, 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...@bama.ua.edu with the message: INFO IBM-MAIN
STK SMC/HSC and SMS Tape
Hello, We have a customer that is doing some tape migration. They are currently using STK SMC manage their SILO. If we create a SMS Tape Library (MTL) and add a volume to it that is also in the SILO which unit will be picked by allocation? There is a statement in the SMC manual that says SMC will ignore SMS Managed Devices. It actually talks about SMS Dataset also. But while sms tape is a sms managed device I am not sure that a dataset that references a sms managed tape is a sms managed dataset? //DD1 DD UNIT=TAPE,DISP=OLD,VOL=SER=SMS111 If SMS111 is also in the SILO will SMC change the allocation to the SILO or leave it alone? Thanks for any help Tom -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: STK SMC/HSC and SMS Tape
You will need to vary the disk volume offline before you can use the tape volume on the same LPAR. On Sat, Jun 2, 2012 at 10:21 PM, Tom Williamson t...@dtssoftware.com wrote: Hello, We have a customer that is doing some tape migration. They are currently using STK SMC manage their SILO. If we create a SMS Tape Library (MTL) and add a volume to it that is also in the SILO which unit will be picked by allocation? There is a statement in the SMC manual that says SMC will ignore SMS Managed Devices. It actually talks about SMS Dataset also. But while sms tape is a sms managed device I am not sure that a dataset that references a sms managed tape is a sms managed dataset? //DD1 DD UNIT=TAPE,DISP=OLD,VOL=SER=SMS111 If SMS111 is also in the SILO will SMC change the allocation to the SILO or leave it alone? Thanks for any help Tom -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMS Dataset Alloc Issue
Hello, Thanks for help. But I still have once confusion is, When I am trying to delete the Data component of these datset, for which cluster part is not visible , system is not allowing me to delete. I get error DATASET not Found. I think, I am getting this error because that particular datset is not part of current master catalog. But if Still I want to delete the data component I created, Can you please help to perform this task. Regards Saurabh On Sat, May 26, 2012 at 10:23 AM, retired mainframer retired-mainfra...@q.com wrote: You misinterpreted. If the dataset is not catalogued in the normal search order, you have to tell DSLIST to search all the catalogs. The way to do this is to specify a wild card as the HLQ, include any additional qualifiers to limit the output, and NOT specify a volume. In the example you posted, try **.SMS.SCDS. If you specify the Display Catalog Name option, it will be easy to see which cluster came from MCATB and which components belong to that cluster. (This assumes SOZ1D.MASTER.CATALOG is connected to your current master catalog. Reasonable since otherwise your define would have failed.) :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On :: Behalf Of saurabh khandelwal :: Sent: Friday, May 25, 2012 5:24 AM :: To: IBM-MAIN@bama.ua.edu :: Subject: Re: SMS Dataset Alloc Issue :: :: Hello Group, :: Walter has clarified my doubt that I am trying :: to :: see a cluster cataloged under MCATB from a system whose master catalog :: is :: MCATA. Then, it is perfectly normal to see only the data part of the :: cluster. So I will be able to see cluster+data only when I logon on :: thesystem whose master catalog is MCATB. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- Thanks Regards Saurabh Khandelwal -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMS Dataset Alloc Issue
Hello, Thanks for help. But I still have once confusion is, When I am trying to delete the Data component of these datset, for which cluster part is not visible , system is not allowing me to delete. I get error DATASET not Found. I think, I am getting this error because that particular datset is not part of current master catalog. But if Still I want to delete the data component I created, Can you please help to perform this task. Regards Saurabh Some questions 1) Is the catalog where this SYS1.SMS.SCDS is cataloged a USER CAT on the system you are trying to do the display? 2) Is the system where the SYS1.SMS.SCDS is cataloged - up or able to be IPL'D? If you have system up with MCATA and MCATB is a usercat in MCATA then you may be able to delete the dataset with the CATALOG parm in IDCAMS DEL. If you can bring up the system where MCATB is the Master Cat then you can do the changes from the running system IIRC SETSMS command can point SMS to different SCDS or ACDS datasets. So if you have a running system that you can logon, then you can fix from that system. Or could you create a new SYS1.SMS2.SCDS dataset to the correct MCAT and then update the SYS1.PARMLIB member to point to the new SCDS dataset and IPL? You may have several options to correct this issue. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMS Dataset Alloc Issue
And since no one else seems to have mentioned it yet, this whole thread is an excellent argument for NOT using a SYS1. high level for naming installation datasets you want system-specific, like the this SCDS dataset -- instead using some unique high-level qualifier associated with the master catalog of each system, say MCTA and MCTB. Then you can simply create and maintain your installation System-B datasets from System-A by temporarily connecting the System-B MCAT as a User Catalog to System-A and defining MCTB (in System-A MCAT) as an ALIAS pointing to the System-B MCAT. With those conventions and working with datasets with an MCTB high-level from System-A, everything gets correctly pointed to the System-B MCAT without having to play any bizarre games, and utilities like ISPF 3.4 will behave more predictably as well. When System-B is up and running on its Master Catalog, there will be no ALIAS for MCTB defined in the System-B MCAT, so a search for MCTB.anything from System-B would default to the System-B Master Catalog. J C Ewing On 05/26/2012 12:12 PM, Lizette Koehler wrote: Hello, Thanks for help. But I still have once confusion is, When I am trying to delete the Data component of these datset, for which cluster part is not visible , system is not allowing me to delete. I get error DATASET not Found. I think, I am getting this error because that particular datset is not part of current master catalog. But if Still I want to delete the data component I created, Can you please help to perform this task. Regards Saurabh Some questions 1) Is the catalog where this SYS1.SMS.SCDS is cataloged a USER CAT on the system you are trying to do the display? 2) Is the system where the SYS1.SMS.SCDS is cataloged - up or able to be IPL'D? If you have system up with MCATA and MCATB is a usercat in MCATA then you may be able to delete the dataset with the CATALOG parm in IDCAMS DEL. If you can bring up the system where MCATB is the Master Cat then you can do the changes from the running system IIRC SETSMS command can point SMS to different SCDS or ACDS datasets. So if you have a running system that you can logon, then you can fix from that system. Or could you create a new SYS1.SMS2.SCDS dataset to the correct MCAT and then update the SYS1.PARMLIB member to point to the new SCDS dataset and IPL? You may have several options to correct this issue. Lizette ... -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMS Dataset Alloc Issue
You do not delete the data component. You delete the cluster. You do so using Access Methods Services (aka IDCAMS) by specifying both the fully qualified DSN and the catalog where that DSN can be found. If you have problems show us the job and the IDCAMS output. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On :: Behalf Of saurabh khandelwal :: Sent: Saturday, May 26, 2012 8:48 AM :: To: IBM-MAIN@bama.ua.edu :: Subject: Re: SMS Dataset Alloc Issue :: :: Hello, ::Thanks for help. But I still have once confusion is, When I :: am :: trying to delete the Data component of these datset, for which cluster :: part :: is not visible , system is not allowing me to delete. I get error :: DATASET :: not Found. :: :: I think, I am getting this error because that particular datset is not :: part :: of current master catalog. But if Still I want to delete the data :: component :: I created, :: Can you please help to perform this task. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SMS Dataset Alloc Issue
Hello Group, I have used below JCL to allocate SMS dataset. But when I checked, JCL has created only data part not cluster part of the dataset. not sure why it has happened. I tried ISPF 3.4 against volume. Only Data part is visible. //SMSALOC JOB (660),SAURABH, // CLASS=A,NOTIFY=SYSUID, // MSGCLASS=A //* //ALLOC EXEC PGM=IDCAMS,REGION=512K //DDSOZ1D1 DD DISP=OLD,UNIT=SYSALLDA,VOL=SER=SOZ1D1 //SYSPRINT DD SYSOUT=* //SYSINDD * /* ALLOCATE SCDS */ DEFINE CLUSTER( - NAME(SYS1.SMS.SCDS)- LINEAR - VOLUMES(SOZ1D1)- TRK(6 6) - SHAREOPTIONS(2,3) - ) - DATA( - NAME(SYS1.SMS.SCDS.DATA) - ) - CATALOG(SOZ1D.MASTER.CATALOG) /* ALLOCATE ACDS */ DEFINE CLUSTER( - NAME(SYS1.SMS.ACDS)- LINEAR - VOLUMES(SOZ1D1)- TRK(6 6) - SHAREOPTIONS(3,3) - ) - DATA( - NAME(SYS1.SMS.ACDS.DATA) - ) - CATALOG(SOZ1D.MASTER.CATALOG) /* ALLOCATE COMMDS */ DEFINE CLUSTER( - NAME(SYS1.SMS.COMMDS) - LINEAR - VOLUMES(SOZ1D1)- TRK(1 1) - SHAREOPTIONS(3,3) - ) - DATA( - NAME(SYS1.SMS.COMMDS.DATA) - ) - CATALOG(SOZ1D.MASTER.CATALOG) /* // -- Thanks Regards Saurabh -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN 1 J E S 2 J O B L O G -- S Y S T E M M V S 9 -- N O D E J E S S U P 0 00.09.35 JOB00712 THURSDAY, 24 MAY 2012 00.09.35 JOB00712 IRR010I USERID SKHAND9 IS ASSIGNED TO THIS JOB. 00.09.35 JOB00712 ICH70001I SKHAND9 LAST ACCESS AT 23:54:22 ON WEDNESDAY, MAY 23, 2012 00.09.35 JOB00712 $HASP373 SMSALOC STARTED - INIT BASE - CLASS A - SYS MVS9 00.09.35 JOB00712 IEF403I SMSALOC - STARTED - TIME=00.09.35 00.09.35 JOB00712 - -TIMINGS (MINS.)-- -PAGING COUNTS 00.09.35 JOB00712 -STEPNAME PROCSTEPRC EXCP CONN TCB SRB CLOCK SERV WORKLOAD PAGE SWAP VIO SWAPS 00.09.35 JOB00712 -ALLOC00105 52 .00 .00 .0 7006 SYSTEM 0 0 0 0 00.09.35 JOB00712 IEF404I SMSALOC - ENDED - TIME=00.09.35 00.09.35 JOB00712 -SMSALOC ENDED. NAME-SAURABH TOTAL TCB CPU TIME= .00 TOTAL ELAPSED TIME=.0 00.09.35 JOB00712 $HASP395 SMSALOC ENDED 0-- JES2 JOB STATISTICS -- - 24 MAY 2012 JOB EXECUTION DATE - 51 CARDS READ - 110 SYSOUT PRINT RECORDS -0 SYSOUT PUNCH RECORDS -5 SYSOUT SPOOL KBYTES - 0.00 MINUTES EXECUTION TIME 1 //SMSALOC JOB (660),SAURABH, JOB00712 // CLASS=A,NOTIFY=SYSUID, // MSGCLASS=A //* IEFC653I SUBSTITUTION JCL - (660),SAURABH,CLASS=A,NOTIFY=SKHAND9,MSGCLASS=A 2 //ALLOC EXEC PGM=IDCAMS,REGION=512K 3 //DDSOZ1D1 DD DISP=OLD,UNIT=SYSALLDA,VOL=SER=SOZ1D1 4 //SYSPRINT DD SYSOUT=* 5 //SYSINDD * ICH70001I SKHAND9 LAST ACCESS AT 23:54:22 ON WEDNESDAY, MAY 23, 2012 IEF236I ALLOC. FOR SMSALOC ALLOC IEF237I 6137 ALLOCATED TO DDSOZ1D1 IEF237I JES2 ALLOCATED TO SYSPRINT IEF237I JES2 ALLOCATED TO SYSIN IEF237I 6137 ALLOCATED TO SYS1 IEF285I SYS12145.T000935.RA000.SMSALOC.R0138041 KEPT IEF285I VOL SER NOS= SOZ1D1. IEF237I 6137 ALLOCATED TO SYS2 IEF285I SYS12145.T000935.RA000.SMSALOC.R0138042 KEPT IEF285I VOL SER NOS= SOZ1D1. IEF237I 6137 ALLOCATED TO SYS3 IEF285I SYS12145.T000935.RA000.SMSALOC.R0138043 KEPT IEF285I VOL SER NOS= SOZ1D1. IEF142I SMSALOC ALLOC - STEP WAS EXECUTED - COND CODE IEF285I SYS12145.T000935.RA000.SMSALOC.R0138040 KEPT IEF285I VOL SER NOS= SOZ1D1. IEF285I SKHAND9.SMSALOC.JOB00712.D102.? SYSOUT IEF285I SKHAND9.SMSALOC.JOB00712.D101.? SYSIN IEF373I STEP/ALLOC /START 2012145.0009 IEF032I STEP/ALLOC /STOP 2012145.0009 CPU
Re: SMS Dataset Alloc Issue
From: saurabh khandelwal sourabhkhandelwal...@gmail.com I tried ISPF 3.4 against volume. Only Data part is visible. Saurabh, are you sure you cataloged the VSAM under the correct master catalog ? Walter Marguccio z/OS Systems Programmer BELENUS LOB Informatic GmbH Munich - Germany -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMS Dataset Alloc Issue
Were you looking at a catalog search or did you specify the volume serial on the 3.4 screen? Thank You, Dave O'Brien From: Walter Marguccio [walter_marguc...@yahoo.com] Sent: Friday, May 25, 2012 7:06 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS Dataset Alloc Issue From: saurabh khandelwal sourabhkhandelwal...@gmail.com I tried ISPF 3.4 against volume. Only Data part is visible. Saurabh, are you sure you cataloged the VSAM under the correct master catalog ? Walter Marguccio z/OS Systems Programmer BELENUS LOB Informatic GmbH Munich - Germany -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMS Dataset Alloc Issue
Saurabh, By specifying the volume, you will only see the DATA. The CLUSTER part is just a catalog entry, not a physical dataset. (Yeah, guys, I know, but let's keep it simple, OK?) Leave off the VOLUME on ISPF 3.4, and you will see both the Cluster and Data portions. Cheers,,,Steve Steven F. Conway, CISSP LA Systems z/OS Systems Support Phone: 703.295.1926 steve_con...@ao.uscourts.gov From: saurabh khandelwal sourabhkhandelwal...@gmail.com To: IBM-MAIN@bama.ua.edu Date: 05/25/2012 06:49 AM Subject:SMS Dataset Alloc Issue Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Hello Group, I have used below JCL to allocate SMS dataset. But when I checked, JCL has created only data part not cluster part of the dataset. not sure why it has happened. I tried ISPF 3.4 against volume. Only Data part is visible. //SMSALOC JOB (660),SAURABH, // CLASS=A,NOTIFY=SYSUID, // MSGCLASS=A //* //ALLOC EXEC PGM=IDCAMS,REGION=512K //DDSOZ1D1 DD DISP=OLD,UNIT=SYSALLDA,VOL=SER=SOZ1D1 //SYSPRINT DD SYSOUT=* //SYSINDD * /* ALLOCATE SCDS */ DEFINE CLUSTER( - NAME(SYS1.SMS.SCDS)- LINEAR - VOLUMES(SOZ1D1)- TRK(6 6) - SHAREOPTIONS(2,3) - ) - DATA( - NAME(SYS1.SMS.SCDS.DATA) - ) - CATALOG(SOZ1D.MASTER.CATALOG) /* ALLOCATE ACDS */ DEFINE CLUSTER( - NAME(SYS1.SMS.ACDS)- LINEAR - VOLUMES(SOZ1D1)- TRK(6 6) - SHAREOPTIONS(3,3) - ) - DATA( - NAME(SYS1.SMS.ACDS.DATA) - ) - CATALOG(SOZ1D.MASTER.CATALOG) /* ALLOCATE COMMDS */ DEFINE CLUSTER( - NAME(SYS1.SMS.COMMDS) - LINEAR - VOLUMES(SOZ1D1)- TRK(1 1) - SHAREOPTIONS(3,3) - ) - DATA( - NAME(SYS1.SMS.COMMDS.DATA) - ) - CATALOG(SOZ1D.MASTER.CATALOG) /* // -- Thanks Regards Saurabh -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN [attachment SMS.txt deleted by Steve Conway/DCA/AO/USCOURTS] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMS Dataset Alloc Issue
I see you are specifying a catalog too. Why? Are you sure you are using the correct catalog? If not, you wont see it either. _ Dave Jousma Assistant Vice President, Mainframe Services david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Steve Conway Sent: Friday, May 25, 2012 8:16 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS Dataset Alloc Issue Saurabh, By specifying the volume, you will only see the DATA. The CLUSTER part is just a catalog entry, not a physical dataset. (Yeah, guys, I know, but let's keep it simple, OK?) Leave off the VOLUME on ISPF 3.4, and you will see both the Cluster and Data portions. Cheers,,,Steve Steven F. Conway, CISSP LA Systems z/OS Systems Support Phone: 703.295.1926 steve_con...@ao.uscourts.gov From: saurabh khandelwal sourabhkhandelwal...@gmail.com To: IBM-MAIN@bama.ua.edu Date: 05/25/2012 06:49 AM Subject:SMS Dataset Alloc Issue Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Hello Group, I have used below JCL to allocate SMS dataset. But when I checked, JCL has created only data part not cluster part of the dataset. not sure why it has happened. I tried ISPF 3.4 against volume. Only Data part is visible. //SMSALOC JOB (660),SAURABH, // CLASS=A,NOTIFY=SYSUID, // MSGCLASS=A //* //ALLOC EXEC PGM=IDCAMS,REGION=512K //DDSOZ1D1 DD DISP=OLD,UNIT=SYSALLDA,VOL=SER=SOZ1D1 //SYSPRINT DD SYSOUT=* //SYSINDD * /* ALLOCATE SCDS */ DEFINE CLUSTER( - NAME(SYS1.SMS.SCDS)- LINEAR - VOLUMES(SOZ1D1)- TRK(6 6) - SHAREOPTIONS(2,3) - ) - DATA( - NAME(SYS1.SMS.SCDS.DATA) - ) - CATALOG(SOZ1D.MASTER.CATALOG) /* ALLOCATE ACDS */ DEFINE CLUSTER( - NAME(SYS1.SMS.ACDS)- LINEAR - VOLUMES(SOZ1D1)- TRK(6 6) - SHAREOPTIONS(3,3) - ) - DATA( - NAME(SYS1.SMS.ACDS.DATA) - ) - CATALOG(SOZ1D.MASTER.CATALOG) /* ALLOCATE COMMDS */ DEFINE CLUSTER( - NAME(SYS1.SMS.COMMDS) - LINEAR - VOLUMES(SOZ1D1)- TRK(1 1) - SHAREOPTIONS(3,3) - ) - DATA( - NAME(SYS1.SMS.COMMDS.DATA) - ) - CATALOG(SOZ1D.MASTER.CATALOG) /* // -- Thanks Regards Saurabh -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN [attachment SMS.txt deleted by Steve Conway/DCA/AO/USCOURTS] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMS Dataset Alloc Issue
The original define only explicitly named the data component. The index got a system generated name. LISTCAT the cluster and you should see the data component you named and the name that was generated for the index. Doug -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of O'Brien, David W. (NIH/CIT) [C] Sent: Friday, May 25, 2012 7:14 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS Dataset Alloc Issue Were you looking at a catalog search or did you specify the volume serial on the 3.4 screen? Thank You, Dave O'Brien From: Walter Marguccio [walter_marguc...@yahoo.com] Sent: Friday, May 25, 2012 7:06 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS Dataset Alloc Issue From: saurabh khandelwal sourabhkhandelwal...@gmail.com I tried ISPF 3.4 against volume. Only Data part is visible. Saurabh, are you sure you cataloged the VSAM under the correct master catalog ? Walter Marguccio z/OS Systems Programmer BELENUS LOB Informatic GmbH Munich - Germany -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMS Dataset Alloc Issue
Hello Group, Walter has clarified my doubt that I am trying to see a cluster cataloged under MCATB from a system whose master catalog is MCATA. Then, it is perfectly normal to see only the data part of the cluster. So I will be able to see cluster+data only when I logon on thesystem whose master catalog is MCATB. Thanks for helping me . Regards Saurabh On Fri, May 25, 2012 at 5:48 PM, Jousma, David david.jou...@53.com wrote: I see you are specifying a catalog too. Why? Are you sure you are using the correct catalog? If not, you wont see it either. _ Dave Jousma Assistant Vice President, Mainframe Services david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Steve Conway Sent: Friday, May 25, 2012 8:16 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS Dataset Alloc Issue Saurabh, By specifying the volume, you will only see the DATA. The CLUSTER part is just a catalog entry, not a physical dataset. (Yeah, guys, I know, but let's keep it simple, OK?) Leave off the VOLUME on ISPF 3.4, and you will see both the Cluster and Data portions. Cheers,,,Steve Steven F. Conway, CISSP LA Systems z/OS Systems Support Phone: 703.295.1926 steve_con...@ao.uscourts.gov From: saurabh khandelwal sourabhkhandelwal...@gmail.com To: IBM-MAIN@bama.ua.edu Date: 05/25/2012 06:49 AM Subject:SMS Dataset Alloc Issue Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Hello Group, I have used below JCL to allocate SMS dataset. But when I checked, JCL has created only data part not cluster part of the dataset. not sure why it has happened. I tried ISPF 3.4 against volume. Only Data part is visible. //SMSALOC JOB (660),SAURABH, // CLASS=A,NOTIFY=SYSUID, // MSGCLASS=A //* //ALLOC EXEC PGM=IDCAMS,REGION=512K //DDSOZ1D1 DD DISP=OLD,UNIT=SYSALLDA,VOL=SER=SOZ1D1 //SYSPRINT DD SYSOUT=* //SYSINDD * /* ALLOCATE SCDS */ DEFINE CLUSTER( - NAME(SYS1.SMS.SCDS)- LINEAR - VOLUMES(SOZ1D1)- TRK(6 6) - SHAREOPTIONS(2,3) - ) - DATA( - NAME(SYS1.SMS.SCDS.DATA) - ) - CATALOG(SOZ1D.MASTER.CATALOG) /* ALLOCATE ACDS */ DEFINE CLUSTER( - NAME(SYS1.SMS.ACDS)- LINEAR - VOLUMES(SOZ1D1)- TRK(6 6) - SHAREOPTIONS(3,3) - ) - DATA( - NAME(SYS1.SMS.ACDS.DATA) - ) - CATALOG(SOZ1D.MASTER.CATALOG) /* ALLOCATE COMMDS */ DEFINE CLUSTER( - NAME(SYS1.SMS.COMMDS) - LINEAR - VOLUMES(SOZ1D1)- TRK(1 1) - SHAREOPTIONS(3,3) - ) - DATA( - NAME(SYS1.SMS.COMMDS.DATA) - ) - CATALOG(SOZ1D.MASTER.CATALOG) /* // -- Thanks Regards Saurabh -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN [attachment SMS.txt deleted by Steve Conway/DCA/AO/USCOURTS] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu
Re: SMS Dataset Alloc Issue
You misinterpreted. If the dataset is not catalogued in the normal search order, you have to tell DSLIST to search all the catalogs. The way to do this is to specify a wild card as the HLQ, include any additional qualifiers to limit the output, and NOT specify a volume. In the example you posted, try **.SMS.SCDS. If you specify the Display Catalog Name option, it will be easy to see which cluster came from MCATB and which components belong to that cluster. (This assumes SOZ1D.MASTER.CATALOG is connected to your current master catalog. Reasonable since otherwise your define would have failed.) :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On :: Behalf Of saurabh khandelwal :: Sent: Friday, May 25, 2012 5:24 AM :: To: IBM-MAIN@bama.ua.edu :: Subject: Re: SMS Dataset Alloc Issue :: :: Hello Group, :: Walter has clarified my doubt that I am trying :: to :: see a cluster cataloged under MCATB from a system whose master catalog :: is :: MCATA. Then, it is perfectly normal to see only the data part of the :: cluster. So I will be able to see cluster+data only when I logon on :: thesystem whose master catalog is MCATB. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMS QUESTION
Hi, This post was not answered. Can anybody help me out? From: willie bunter williebun...@yahoo.com To: IBM-MAIN@bama.ua.edu Sent: Tuesday, April 17, 2012 12:13:35 PM Subject: SMS QUESTION I encountered the problem with defining a VSAM EXTENDED dsn at a recent disaster recovery. The SMS rules - ACS or DC, MC ,SC SG - are the same as in our production system. However I could not understand the reason for this problem. As a work around I defined the MCDS to use 4,000 cylinders on HSM001 which is a MOD-9. What is also suprising is that the BCDS which is also VSAM EXTENDED worked fine. Below is the output of the failing job. DEFINE CLUSTER - (NAME(SYS2.MCDS) - VOLUMES(HSM001) - CYLINDERS(8000) - RECORDSIZE(435 2040) FREESPACE(0 0) - INDEXED KEYS(44 0) SHAREOPTIONS(3 3) - SPEED BUFFERSPACE(530432) - UNIQUE NOWRITECHECK) - DATA - (NAME(SYS2.MCDS.DATA) - CONTROLINTERVALSIZE(12288)) - INDEX - (NAME(SYS2.MCDS.INDEX) - CONTROLINTERVALSIZE(2048)) 0IGD17103I CATALOG ERROR WHILE DEFINING VSAM DATA SET SYS2.MCDS RETURN CODE IS 140 REASON CODE IS 110 IGG0CLEV IGD306I UNEXPECTED ERROR DURING IGG0CLEV PROCESSING RETURN CODE 140 REASON CODE 110 THE MODULE THAT DETECTED THE ERROR IS IGDVTSCU SMS MODULE TRACE BACK - VTSCU VTSCT VTSCH VTSCG VTSCD VTSCC VTSCR SSIRT SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00025 IGD17219I UNABLE TO CONTINUE DEFINE OF DATA SET SYS2.MCDS 0IDC3014I CATALOG ERROR IDC3009I ** VSAM CATALOG RETURN CODE IS 140 - REASON CODE IS IDC3009I IGG0CLEV-110 1IDCAMS SYSTEM SERVICES TIME: 19:20:13 04/02/12 PAGE 2 0IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMS QUESTION
Try a smaller space allocation. willie bunter williebun...@yahoo.com wrote in message news: 1334937117.83658.yahoomail...@web113615.mail.gq1.yahoo.com... Hi, This post was not answered. Can anybody help me out? From: willie bunter williebun...@yahoo.com To: IBM-MAIN@bama.ua.edu Sent: Tuesday, April 17, 2012 12:13:35 PM Subject: SMS QUESTION I encountered the problem with defining a VSAM EXTENDED dsn at a recent disaster recovery. The SMS rules - ACS or DC, MC ,SC SG - are the same as in our production system. However I could not understand the reason for this problem. As a work around I defined the MCDS to use 4,000 cylinders on HSM001 which is a MOD-9. What is also suprising is that the BCDS which is also VSAM EXTENDED worked fine. Below is the output of the failing job. DEFINE CLUSTER - (NAME(SYS2.MCDS) - VOLUMES(HSM001) - CYLINDERS(8000) - RECORDSIZE(435 2040) FREESPACE(0 0) - INDEXED KEYS(44 0) SHAREOPTIONS(3 3) - SPEED BUFFERSPACE(530432) - UNIQUE NOWRITECHECK) - DATA - (NAME(SYS2.MCDS.DATA) - CONTROLINTERVALSIZE(12288)) - INDEX - (NAME(SYS2.MCDS.INDEX) - CONTROLINTERVALSIZE(2048)) 0IGD17103I CATALOG ERROR WHILE DEFINING VSAM DATA SET SYS2.MCDS RETURN CODE IS 140 REASON CODE IS 110 IGG0CLEV IGD306I UNEXPECTED ERROR DURING IGG0CLEV PROCESSING RETURN CODE 140 REASON CODE 110 THE MODULE THAT DETECTED THE ERROR IS IGDVTSCU SMS MODULE TRACE BACK - VTSCU VTSCT VTSCH VTSCG VTSCD VTSCC VTSCR SSIRT SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00025 IGD17219I UNABLE TO CONTINUE DEFINE OF DATA SET SYS2.MCDS 0IDC3014I CATALOG ERROR IDC3009I ** VSAM CATALOG RETURN CODE IS 140 - REASON CODE IS IDC3009I IGG0CLEV-110 1IDCAMS SYSTEM SERVICES TIME: 19:20:1304/02/12 PAGE 2 0IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMS QUESTION
This is a catalog error. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of willie bunter Sent: Friday, April 20, 2012 11:52 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS QUESTION Hi, This post was not answered. Can anybody help me out? From: willie bunter williebun...@yahoo.com To: IBM-MAIN@bama.ua.edu Sent: Tuesday, April 17, 2012 12:13:35 PM Subject: SMS QUESTION I encountered the problem with defining a VSAM EXTENDED dsn at a recent disaster recovery. The SMS rules - ACS or DC, MC ,SC SG - are the same as in our production system. However I could not understand the reason for this problem. As a work around I defined the MCDS to use 4,000 cylinders on HSM001 which is a MOD-9. What is also suprising is that the BCDS which is also VSAM EXTENDED worked fine. Below is the output of the failing job. DEFINE CLUSTER - (NAME(SYS2.MCDS) - VOLUMES(HSM001) - CYLINDERS(8000) - RECORDSIZE(435 2040) FREESPACE(0 0) - INDEXED KEYS(44 0) SHAREOPTIONS(3 3) - SPEED BUFFERSPACE(530432) - UNIQUE NOWRITECHECK) - DATA - (NAME(SYS2.MCDS.DATA) - CONTROLINTERVALSIZE(12288)) - INDEX - (NAME(SYS2.MCDS.INDEX) - CONTROLINTERVALSIZE(2048)) 0IGD17103I CATALOG ERROR WHILE DEFINING VSAM DATA SET SYS2.MCDS RETURN CODE IS 140 REASON CODE IS 110 IGG0CLEV IGD306I UNEXPECTED ERROR DURING IGG0CLEV PROCESSING RETURN CODE 140 REASON CODE 110 THE MODULE THAT DETECTED THE ERROR IS IGDVTSCU SMS MODULE TRACE BACK - VTSCU VTSCT VTSCH VTSCG VTSCD VTSCC VTSCR SSIRT SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00025 IGD17219I UNABLE TO CONTINUE DEFINE OF DATA SET SYS2.MCDS 0IDC3014I CATALOG ERROR IDC3009I ** VSAM CATALOG RETURN CODE IS 140 - REASON CODE IS IDC3009I IGG0CLEV-110 1IDCAMS SYSTEM SERVICES TIME: 19:20:13 04/02/12 PAGE 2 0IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMS QUESTION
Most likely... user error. If you list the production one, what DATACLAS does it use? Are you sure the ACS routines will assign the correct DATACLAS without you explicitly requesting it? It appears it does not for this data set even though it may have for the BCDS - or your define for the BCDS has a DATACLAS(...) parm in it. 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/ On Fri, 20 Apr 2012 08:51:57 -0700, willie bunter williebun...@yahoo.com wrote: Hi, This post was not answered. Can anybody help me out? From: willie bunter williebun...@yahoo.com To: IBM-MAIN@bama.ua.edu Sent: Tuesday, April 17, 2012 12:13:35 PM Subject: SMS QUESTION I encountered the problem with defining a VSAM EXTENDED dsn at a recent disaster recovery. The SMS rules - ACS or DC, MC ,SC SG - are the same as in our production system. However I could not understand the reason for this problem. As a work around I defined the MCDS to use 4,000 cylinders on HSM001 which is a MOD-9. What is also suprising is that the BCDS which is also VSAM EXTENDED worked fine. Below is the output of the failing job. DEFINE CLUSTER - (NAME(SYS2.MCDS) - VOLUMES(HSM001) - CYLINDERS(8000) - RECORDSIZE(435 2040) FREESPACE(0 0) - INDEXED KEYS(44 0) SHAREOPTIONS(3 3) - SPEED BUFFERSPACE(530432) - UNIQUE NOWRITECHECK) - DATA - (NAME(SYS2.MCDS.DATA) - CONTROLINTERVALSIZE(12288)) - INDEX - (NAME(SYS2.MCDS.INDEX) - CONTROLINTERVALSIZE(2048)) 0IGD17103I CATALOG ERROR WHILE DEFINING VSAM DATA SET SYS2.MCDS RETURN CODE IS 140 REASON CODE IS 110 IGG0CLEV IGD306I UNEXPECTED ERROR DURING IGG0CLEV PROCESSING RETURN CODE 140 REASON CODE 110 THE MODULE THAT DETECTED THE ERROR IS IGDVTSCU SMS MODULE TRACE BACK - VTSCU VTSCT VTSCH VTSCG VTSCD VTSCC VTSCR SSIRT SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00025 IGD17219I UNABLE TO CONTINUE DEFINE OF DATA SET SYS2.MCDS 0IDC3014I CATALOG ERROR IDC3009I ** VSAM CATALOG RETURN CODE IS 140 - REASON CODE IS IDC3009I IGG0CLEV-110 1IDCAMS SYSTEM SERVICES TIME: 19:20:13 04/02/12 PAGE 2 0IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMS QUESTION
You need to look at SFSMSdfp Diagnosis to see why the IGDVTSCU error is being returned. The indication is that you exceeded 4GB, the define at 4000 indicates that after you reduced it to under 4 GB it worked, so something is amiss in the extended addressability situation. DR is inherently difficult unless your system at DR is an exact mirror of your production system. Doug -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of willie bunter Sent: Friday, April 20, 2012 11:52 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS QUESTION Hi, This post was not answered. Can anybody help me out? From: willie bunter williebun...@yahoo.com To: IBM-MAIN@bama.ua.edu Sent: Tuesday, April 17, 2012 12:13:35 PM Subject: SMS QUESTION I encountered the problem with defining a VSAM EXTENDED dsn at a recent disaster recovery. The SMS rules - ACS or DC, MC ,SC SG - are the same as in our production system. However I could not understand the reason for this problem. As a work around I defined the MCDS to use 4,000 cylinders on HSM001 which is a MOD-9. What is also suprising is that the BCDS which is also VSAM EXTENDED worked fine. Below is the output of the failing job. DEFINE CLUSTER - (NAME(SYS2.MCDS) - VOLUMES(HSM001) - CYLINDERS(8000) - RECORDSIZE(435 2040) FREESPACE(0 0) - INDEXED KEYS(44 0) SHAREOPTIONS(3 3) - SPEED BUFFERSPACE(530432) - UNIQUE NOWRITECHECK) - DATA - (NAME(SYS2.MCDS.DATA) - CONTROLINTERVALSIZE(12288)) - INDEX - (NAME(SYS2.MCDS.INDEX) - CONTROLINTERVALSIZE(2048)) 0IGD17103I CATALOG ERROR WHILE DEFINING VSAM DATA SET SYS2.MCDS RETURN CODE IS 140 REASON CODE IS 110 IGG0CLEV IGD306I UNEXPECTED ERROR DURING IGG0CLEV PROCESSING RETURN CODE 140 REASON CODE 110 THE MODULE THAT DETECTED THE ERROR IS IGDVTSCU SMS MODULE TRACE BACK - VTSCU VTSCT VTSCH VTSCG VTSCD VTSCC VTSCR SSIRT SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00025 IGD17219I UNABLE TO CONTINUE DEFINE OF DATA SET SYS2.MCDS 0IDC3014I CATALOG ERROR IDC3009I ** VSAM CATALOG RETURN CODE IS 140 - REASON CODE IS IDC3009I IGG0CLEV-110 1IDCAMS SYSTEM SERVICES TIME: 19:20:13 04/02/12 PAGE 2 0IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMS QUESTION
That is what I did to fix the problem. But my question is why this would happen. The SMS rules show that it is VSAM EXTENDED and the volume is a 3390-9 model. From: Ernie Takeuchi e.m.takeu...@att.net To: IBM-MAIN@bama.ua.edu Sent: Friday, April 20, 2012 12:18:20 PM Subject: Re: SMS QUESTION Try a smaller space allocation. willie bunter williebun...@yahoo.com wrote in message news: 1334937117.83658.yahoomail...@web113615.mail.gq1.yahoo.com... Hi, This post was not answered. Can anybody help me out? From: willie bunter williebun...@yahoo.com To: IBM-MAIN@bama.ua.edu Sent: Tuesday, April 17, 2012 12:13:35 PM Subject: SMS QUESTION I encountered the problem with defining a VSAM EXTENDED dsn at a recent disaster recovery. The SMS rules - ACS or DC, MC ,SC SG - are the same as in our production system. However I could not understand the reason for this problem. As a work around I defined the MCDS to use 4,000 cylinders on HSM001 which is a MOD-9. What is also suprising is that the BCDS which is also VSAM EXTENDED worked fine. Below is the output of the failing job. DEFINE CLUSTER - (NAME(SYS2.MCDS) - VOLUMES(HSM001) - CYLINDERS(8000) - RECORDSIZE(435 2040) FREESPACE(0 0) - INDEXED KEYS(44 0) SHAREOPTIONS(3 3) - SPEED BUFFERSPACE(530432) - UNIQUE NOWRITECHECK) - DATA - (NAME(SYS2.MCDS.DATA) - CONTROLINTERVALSIZE(12288)) - INDEX - (NAME(SYS2.MCDS.INDEX) - CONTROLINTERVALSIZE(2048)) 0IGD17103I CATALOG ERROR WHILE DEFINING VSAM DATA SET SYS2.MCDS RETURN CODE IS 140 REASON CODE IS 110 IGG0CLEV IGD306I UNEXPECTED ERROR DURING IGG0CLEV PROCESSING RETURN CODE 140 REASON CODE 110 THE MODULE THAT DETECTED THE ERROR IS IGDVTSCU SMS MODULE TRACE BACK - VTSCU VTSCT VTSCH VTSCG VTSCD VTSCC VTSCR SSIRT SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00025 IGD17219I UNABLE TO CONTINUE DEFINE OF DATA SET SYS2.MCDS 0IDC3014I CATALOG ERROR IDC3009I ** VSAM CATALOG RETURN CODE IS 140 - REASON CODE IS IDC3009I IGG0CLEV-110 1IDCAMS SYSTEM SERVICES TIME: 19:20:13 04/02/12 PAGE 2 0IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
FW: SMS QUESTION
Sorry, was responding to another problem. Got replies crossed over. -Original Message- From: Doug Fuerst [mailto:d...@bkassociates.net] Sent: Friday, April 20, 2012 12:20 PM To: 'IBM Mainframe Discussion List' Cc: Doug Fuerst Subject: RE: SMS QUESTION This is a catalog error. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of willie bunter Sent: Friday, April 20, 2012 11:52 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS QUESTION Hi, This post was not answered. Can anybody help me out? From: willie bunter williebun...@yahoo.com To: IBM-MAIN@bama.ua.edu Sent: Tuesday, April 17, 2012 12:13:35 PM Subject: SMS QUESTION I encountered the problem with defining a VSAM EXTENDED dsn at a recent disaster recovery. The SMS rules - ACS or DC, MC ,SC SG - are the same as in our production system. However I could not understand the reason for this problem. As a work around I defined the MCDS to use 4,000 cylinders on HSM001 which is a MOD-9. What is also suprising is that the BCDS which is also VSAM EXTENDED worked fine. Below is the output of the failing job. DEFINE CLUSTER - (NAME(SYS2.MCDS) - VOLUMES(HSM001) - CYLINDERS(8000) - RECORDSIZE(435 2040) FREESPACE(0 0) - INDEXED KEYS(44 0) SHAREOPTIONS(3 3) - SPEED BUFFERSPACE(530432) - UNIQUE NOWRITECHECK) - DATA - (NAME(SYS2.MCDS.DATA) - CONTROLINTERVALSIZE(12288)) - INDEX - (NAME(SYS2.MCDS.INDEX) - CONTROLINTERVALSIZE(2048)) 0IGD17103I CATALOG ERROR WHILE DEFINING VSAM DATA SET SYS2.MCDS RETURN CODE IS 140 REASON CODE IS 110 IGG0CLEV IGD306I UNEXPECTED ERROR DURING IGG0CLEV PROCESSING RETURN CODE 140 REASON CODE 110 THE MODULE THAT DETECTED THE ERROR IS IGDVTSCU SMS MODULE TRACE BACK - VTSCU VTSCT VTSCH VTSCG VTSCD VTSCC VTSCR SSIRT SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00025 IGD17219I UNABLE TO CONTINUE DEFINE OF DATA SET SYS2.MCDS 0IDC3014I CATALOG ERROR IDC3009I ** VSAM CATALOG RETURN CODE IS 140 - REASON CODE IS IDC3009I IGG0CLEV-110 1IDCAMS SYSTEM SERVICES TIME: 19:20:13 04/02/12 PAGE 2 0IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMS QUESTION
That is what I did to fix the problem. But my question is why this would happen. The SMS rules show that it is VSAM EXTENDED and the volume is a 3390-9 model. It would appear based on the little evidence we see that it was not VSAM Extended. You say your SMS rules show that it is VE - how do you know that for sure? There's nothing in the error messages you included that show that. Here is a case where WRITE statements in your SMS code would have easily helped you debug the issue. ddk 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMS QUESTION
You have to see if the proper SMS path was used. The indication is that the EA bit was not active for this allocation. If it does not fail with a similar allocation of a test file in your normal system, you may have to wait until the next DR shot to figure it out. Doug -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of willie bunter Sent: Friday, April 20, 2012 12:37 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS QUESTION That is what I did to fix the problem. But my question is why this would happen. The SMS rules show that it is VSAM EXTENDED and the volume is a 3390-9 model. From: Ernie Takeuchi e.m.takeu...@att.net To: IBM-MAIN@bama.ua.edu Sent: Friday, April 20, 2012 12:18:20 PM Subject: Re: SMS QUESTION Try a smaller space allocation. willie bunter williebun...@yahoo.com wrote in message news: 1334937117.83658.yahoomail...@web113615.mail.gq1.yahoo.com... Hi, This post was not answered. Can anybody help me out? From: willie bunter williebun...@yahoo.com To: IBM-MAIN@bama.ua.edu Sent: Tuesday, April 17, 2012 12:13:35 PM Subject: SMS QUESTION I encountered the problem with defining a VSAM EXTENDED dsn at a recent disaster recovery. The SMS rules - ACS or DC, MC ,SC SG - are the same as in our production system. However I could not understand the reason for this problem. As a work around I defined the MCDS to use 4,000 cylinders on HSM001 which is a MOD-9. What is also suprising is that the BCDS which is also VSAM EXTENDED worked fine. Below is the output of the failing job. DEFINE CLUSTER - (NAME(SYS2.MCDS) - VOLUMES(HSM001) - CYLINDERS(8000) - RECORDSIZE(435 2040) FREESPACE(0 0) - INDEXED KEYS(44 0) SHAREOPTIONS(3 3) - SPEED BUFFERSPACE(530432) - UNIQUE NOWRITECHECK) - DATA - (NAME(SYS2.MCDS.DATA) - CONTROLINTERVALSIZE(12288)) - INDEX - (NAME(SYS2.MCDS.INDEX) - CONTROLINTERVALSIZE(2048)) 0IGD17103I CATALOG ERROR WHILE DEFINING VSAM DATA SET SYS2.MCDS RETURN CODE IS 140 REASON CODE IS 110 IGG0CLEV IGD306I UNEXPECTED ERROR DURING IGG0CLEV PROCESSING RETURN CODE 140 REASON CODE 110 THE MODULE THAT DETECTED THE ERROR IS IGDVTSCU SMS MODULE TRACE BACK - VTSCU VTSCT VTSCH VTSCG VTSCD VTSCC VTSCR SSIRT SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00025 IGD17219I UNABLE TO CONTINUE DEFINE OF DATA SET SYS2.MCDS 0IDC3014I CATALOG ERROR IDC3009I ** VSAM CATALOG RETURN CODE IS 140 - REASON CODE IS IDC3009I IGG0CLEV-110 1IDCAMS SYSTEM SERVICES TIME: 19:20:13 04/02/12 PAGE 2 0IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMS QUESTION
On Fri, 20 Apr 2012 09:37:29 -0700, willie bunter williebun...@yahoo.com wrote: That is what I did to fix the problem. But my question is why this would happen. The SMS rules show that it is VSAM EXTENDED and the volume is a 3390-9 model. SMS rules don't show anything. A LISTCAT after the define would show something, but you aren't getting that far. You need to trace the SMS rules with write statements or IEEIBALL or ISV software. Do you have the output still of when this was done in production to prove someone didn't specify DATACLAS(..)? 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMS QUESTION
Can you produce the output of LISTCAT ENT('SYS2.MCDS') ALL from both systems
and see what the differences are?
:: -Original Message-
:: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
:: Behalf Of willie bunter
:: Sent: Friday, April 20, 2012 9:37 AM
:: To: IBM-MAIN@bama.ua.edu
:: Subject: Re: SMS QUESTION
::
:: That is what I did to fix the problem. But my question is why this
:: would happen. The SMS rules show that it is VSAM EXTENDED and the
:: volume is a 3390-9 model.
::
::
::
::
:: From: Ernie Takeuchi e.m.takeu...@att.net
:: To: IBM-MAIN@bama.ua.edu
:: Sent: Friday, April 20, 2012 12:18:20 PM
:: Subject: Re: SMS QUESTION
::
:: Try a smaller space allocation.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SMS QUESTION
I encountered the problem with defining a VSAM EXTENDED dsn at a recent disaster recovery. The SMS rules - ACS or DC, MC ,SC SG - are the same as in our production system. However I could not understand the reason for this problem. As a work around I defined the MCDS to use 4,000 cylinders on HSM001 which is a MOD-9. What is also suprising is that the BCDS which is also VSAM EXTENDED worked fine. Below is the output of the failing job. DEFINE CLUSTER - (NAME(SYS2.MCDS) - VOLUMES(HSM001) - CYLINDERS(8000) - RECORDSIZE(435 2040) FREESPACE(0 0) - INDEXED KEYS(44 0) SHAREOPTIONS(3 3) - SPEED BUFFERSPACE(530432) - UNIQUE NOWRITECHECK) - DATA - (NAME(SYS2.MCDS.DATA) - CONTROLINTERVALSIZE(12288)) - INDEX - (NAME(SYS2.MCDS.INDEX) - CONTROLINTERVALSIZE(2048)) 0IGD17103I CATALOG ERROR WHILE DEFINING VSAM DATA SET SYS2.MCDS RETURN CODE IS 140 REASON CODE IS 110 IGG0CLEV IGD306I UNEXPECTED ERROR DURING IGG0CLEV PROCESSING RETURN CODE 140 REASON CODE 110 THE MODULE THAT DETECTED THE ERROR IS IGDVTSCU SMS MODULE TRACE BACK - VTSCU VTSCT VTSCH VTSCG VTSCD VTSCC VTSCR SSIRT SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00025 IGD17219I UNABLE TO CONTINUE DEFINE OF DATA SET SYS2.MCDS 0IDC3014I CATALOG ERROR IDC3009I ** VSAM CATALOG RETURN CODE IS 140 - REASON CODE IS IDC3009I IGG0CLEV-110 1IDCAMS SYSTEM SERVICES TIME: 19:20:13 04/02/12 PAGE 2 0IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMS QUESTION
Apparently you have already looked up the relevant return code/reason code (IDC3009I RC140 RSN110). Lots of hits in IBM DB, for RC140, but none w/RSN110 0) Was SMS fully activated w/o errors at the time? 1) is the original dataset SMS managed? And Extended format? 2) Are you sure of you SMS routines? What happens does the ACS test facility say about your allocation? Is HSM001 a member of the SG? IS HSM001 formatted as a mod-9? 3) explicitly specify a DC w/extended attribute in the define. If all of the above are true, open a PMR. Al Staller | Z Systems Programmer | KBM Group | (Tel) 972 664 3565 | allan.stal...@kbmg.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of willie bunter Sent: Tuesday, April 17, 2012 11:14 AM To: IBM-MAIN@bama.ua.edu Subject: SMS QUESTION I encountered the problem with defining a VSAM EXTENDED dsn at a recent disaster recovery. The SMS rules - ACS or DC, MC ,SC SG - are the same as in our production system. However I could not understand the reason for this problem. As a work around I defined the MCDS to use 4,000 cylinders on HSM001 which is a MOD-9. What is also suprising is that the BCDS which is also VSAM EXTENDED worked fine. Below is the output of the failing job. DEFINE CLUSTER - (NAME(SYS2.MCDS) - VOLUMES(HSM001) - CYLINDERS(8000) - RECORDSIZE(435 2040) FREESPACE(0 0) - INDEXED KEYS(44 0) SHAREOPTIONS(3 3) - SPEED BUFFERSPACE(530432) - UNIQUE NOWRITECHECK) - DATA - (NAME(SYS2.MCDS.DATA) - CONTROLINTERVALSIZE(12288)) - INDEX - (NAME(SYS2.MCDS.INDEX) - CONTROLINTERVALSIZE(2048)) 0IGD17103I CATALOG ERROR WHILE DEFINING VSAM DATA SET SYS2.MCDS RETURN CODE IS 140 REASON CODE IS 110 IGG0CLEV IGD306I UNEXPECTED ERROR DURING IGG0CLEV PROCESSING RETURN CODE 140 REASON CODE 110 THE MODULE THAT DETECTED THE ERROR IS IGDVTSCU SMS MODULE TRACE BACK - VTSCU VTSCT VTSCH VTSCG VTSCD VTSCC VTSCR SSIRT SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00025 IGD17219I UNABLE TO CONTINUE DEFINE OF DATA SET SYS2.MCDS 0IDC3014I CATALOG ERROR IDC3009I ** VSAM CATALOG RETURN CODE IS 140 - REASON CODE IS IDC3009I IGG0CLEV-110 1IDCAMS SYSTEM SERVICES TIME: 19:20:13 04/02/12 PAGE 2 0IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMS QUESTION
Whatever DataClass is being assigned to the MCDS, it is not defined with extended addressing -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of willie bunter Sent: Tuesday, April 17, 2012 12:14 PM To: IBM-MAIN@bama.ua.edu Subject: SMS QUESTION I encountered the problem with defining a VSAM EXTENDED dsn at a recent disaster recovery. The SMS rules - ACS or DC, MC ,SC SG - are the same as in our production system. However I could not understand the reason for this problem. As a work around I defined the MCDS to use 4,000 cylinders on HSM001 which is a MOD-9. What is also suprising is that the BCDS which is also VSAM EXTENDED worked fine. Below is the output of the failing job. DEFINE CLUSTER - (NAME(SYS2.MCDS) - VOLUMES(HSM001) - CYLINDERS(8000) - RECORDSIZE(435 2040) FREESPACE(0 0) - INDEXED KEYS(44 0) SHAREOPTIONS(3 3) - SPEED BUFFERSPACE(530432) - UNIQUE NOWRITECHECK) - DATA - (NAME(SYS2.MCDS.DATA) - CONTROLINTERVALSIZE(12288)) - INDEX - (NAME(SYS2.MCDS.INDEX) - CONTROLINTERVALSIZE(2048)) 0IGD17103I CATALOG ERROR WHILE DEFINING VSAM DATA SET SYS2.MCDS RETURN CODE IS 140 REASON CODE IS 110 IGG0CLEV IGD306I UNEXPECTED ERROR DURING IGG0CLEV PROCESSING RETURN CODE 140 REASON CODE 110 THE MODULE THAT DETECTED THE ERROR IS IGDVTSCU SMS MODULE TRACE BACK - VTSCU VTSCT VTSCH VTSCG VTSCD VTSCC VTSCR SSIRT SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00025 IGD17219I UNABLE TO CONTINUE DEFINE OF DATA SET SYS2.MCDS 0IDC3014I CATALOG ERROR IDC3009I ** VSAM CATALOG RETURN CODE IS 140 - REASON CODE IS IDC3009I IGG0CLEV-110 1IDCAMS SYSTEM SERVICES TIME: 19:20:13 04/02/12 PAGE 2 0IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMS QUESTION
My guess: you tried to define dataset 4GB limit (*). RC 140 RSN 110 say about it. To Allan: I would suggest to use regular IBM documentation and regular BookManager search utility ;-) I'm serious: 3 clicks and you have the answer. I don't know what is the reason of the problem, but it can be difference in DC definitions (do not confuse with ACS routines). (*) Remarks: 1. There are other reasons for 140-110, 4GB limit is only one of them. 2. 4GB limit is a little bit tricky: this is limit of RBA, but total size in tracks x track size can be slightly bigger than 4GB. The real allocation limit is: 2^32 / CISZ - integer number of CI's number of CI's / CI/CA - integer number of CA's (in both case you truncate the value, i.e. 1023,2837 - 1023) number of CA's * ca size in track = maximum size of VSAM non-EA. -- Radoslaw Skorupka Lodz, Poland W dniu 2012-04-17 18:13, willie bunter pisze: I encountered the problem with defining a VSAM EXTENDED dsn at a recent disaster recovery. The SMS rules - ACS or DC, MC ,SC SG - are the same as in our production system. However I could not understand the reason for this problem. As a work around I defined the MCDS to use 4,000 cylinders on HSM001 which is a MOD-9. What is also suprising is that the BCDS which is also VSAM EXTENDED worked fine. Below is the output of the failing job. DEFINE CLUSTER - (NAME(SYS2.MCDS) - VOLUMES(HSM001) - CYLINDERS(8000) - RECORDSIZE(435 2040) FREESPACE(0 0) - INDEXED KEYS(44 0) SHAREOPTIONS(3 3) - SPEED BUFFERSPACE(530432) - UNIQUE NOWRITECHECK) - DATA - (NAME(SYS2.MCDS.DATA) - CONTROLINTERVALSIZE(12288)) - INDEX - (NAME(SYS2.MCDS.INDEX) - CONTROLINTERVALSIZE(2048)) 0IGD17103I CATALOG ERROR WHILE DEFINING VSAM DATA SET SYS2.MCDS RETURN CODE IS 140 REASON CODE IS 110 IGG0CLEV IGD306I UNEXPECTED ERROR DURING IGG0CLEV PROCESSING RETURN CODE 140 REASON CODE 110 THE MODULE THAT DETECTED THE ERROR IS IGDVTSCU SMS MODULE TRACE BACK - VTSCU VTSCT VTSCH VTSCG VTSCD VTSCC VTSCR SSIRT SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00025 IGD17219I UNABLE TO CONTINUE DEFINE OF DATA SET SYS2.MCDS 0IDC3014I CATALOG ERROR IDC3009I ** VSAM CATALOG RETURN CODE IS 140 - REASON CODE IS IDC3009I IGG0CLEV-110 1IDCAMS SYSTEM SERVICES TIME: 19:20:1304/02/12 PAGE 2 0IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Questions regarding SMS compacted dataset
Victor, Are you using DFDSS DUMP or COPY? The DUMP function will _not_ decompress the data set and will take a physical copy of it. Naturally, as it is already compressed, further compression when copying it to tape will not be very beneficial. Other utilities, such as IEBGENER. have to decompress the data set as they are doing a record by record, logical, copy (this may not be true for IDCAMS when using the compression interface, see II14507). Hope that helps, Yifat -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Victor Zhang Sent: Tuesday, April 10, 2012 6:01 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Questions regarding SMS compacted dataset Chris, Thanks for the reply. Using dss is to back extended files to tape/virtual tape. Your answer said the data read will be expanded. So even by setting compact as N, the amount of data written to tape/virtual tape will be same, right? My another question is: If I set compact=N for storage class, so data sets will not be compressed/compacted. If I use same utility to copy it to tape/virtual tape, will there any difference for the data stream writing to tape? I already noticed a difference: By enabling compact option in storage class, I have very low compression ratio for data written to tape/virtual tape, do you have any idea? Regards Victor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Questions regarding SMS compacted dataset
Yifat, Thank you very much, very help. One more question: Does both physical dump and logical dump NOT decompress extended compacted PS dataset OR Does physical dump NOT decompress extended compacted PS dataset OR Does copy decompress extended compacted PS dataset? Regards Victor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Questions regarding SMS compacted dataset
On Wed, 11 Apr 2012 12:53:22 +0300, Yifat Oren wrote: Other utilities, such as IEBGENER. have to decompress the data set as they are doing a record by record, logical, copy (this may not be true for IDCAMS when using the compression interface, see II14507). Is this done by the utility (ugh!) or by the access method? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Questions regarding SMS compacted dataset
Access method snip Other utilities, such as IEBGENER. have to decompress the data set as they are doing a record by record, logical, copy (this may not be true for IDCAMS when using the compression interface, see II14507). Is this done by the utility (ugh!) or by the access method? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Questions regarding SMS compacted dataset
Victor, Logical dump of compressed format data sets does not decompress them. This quote from the DFSMSdss Storage Administration sort-of implies that: 1. The COMPRESS keyword is ignored if it is specified during a logical data set dump for either compressed-format sequential data sets or compressed-format VSAM data sets. (The COMPRESS keyword specifies that DFSMSdss should compress the output dump data set before writing it to output medium - so, double compression is being avoided here). COPY must decompress an extended-format compressed data set when copying it to a basic-format data set (on tape). Best Regards, Yifat -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Victor Zhang Sent: Wednesday, April 11, 2012 3:52 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Questions regarding SMS compacted dataset Yifat, Thank you very much, very help. One more question: Does both physical dump and logical dump NOT decompress extended compacted PS dataset OR Does physical dump NOT decompress extended compacted PS dataset OR Does copy decompress extended compacted PS dataset? Regards Victor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Questions regarding SMS compacted dataset
Having never used ADRDSSU, I can't say for sure, but it would be a pretty bad utility if when it was done it did not leave a good readable copy of the data set. It should either do it right or tell you why it can't. If you are copying a file from a SMS to a non-SMS volume, then it should write the expanded file on the destination volume or tell you that it can't do that copy or move function. Doing a move and leaving the data unreadable would be ample justification for opening an APAR. IEBGENER and most other products that I know of use the BSAM or QSAM access methods when dealing with a compressed file. The SAM access methods return expanded records to the application, or in the case of writing, compress the data on the way out. Chris Blaicher Senior Software Engineer, Software Services Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com www.syncsort.com Check out our Knowledge Base at www.syncsort.com/support Syncsort aims for the best product and service experience. We welcome your feedback. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Victor Zhang Sent: Monday, April 09, 2012 11:46 PM To: MVS List Server 1 Subject: Re: Questions regarding SMS compacted dataset Hi all, Sorry, forgot to mention is if the program trying to read compressed extended physical sequential file is ADRDSSU, will only compressed data be returned? How about IEBGEN program? Regards Victor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Questions regarding SMS compacted dataset
Chris, Thanks for the reply. Using dss is to back extended files to tape/virtual tape. Your answer said the data read will be expanded. So even by setting compact as N, the amount of data written to tape/virtual tape will be same, right? My another question is: If I set compact=N for storage class, so data sets will not be compressed/compacted. If I use same utility to copy it to tape/virtual tape, will there any difference for the data stream writing to tape? I already noticed a difference: By enabling compact option in storage class, I have very low compression ratio for data written to tape/virtual tape, do you have any idea? Regards Victor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Questions regarding SMS compacted dataset
On Tue, Apr 10, 2012 at 10:00 AM, Victor Zhang victor_wor...@yahoo.com.cn wrote: deleted I already noticed a difference: By enabling compact option in storage class, I have very low compression ratio for data written to tape/virtual tape, do you have any idea? Regards Victor You are sending compressed data, You can't compress it anymore. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Questions regarding SMS compacted dataset
In each case when you copy dataset from DASD to TAPE ar vice versa, the data in transit are uncompressed. Compression/lack of compression on source/target doesn't matter. -- Radoslaw Skorupka Lodz, Poland W dniu 2012-04-10 17:00, Victor Zhang pisze: Chris, Thanks for the reply. Using dss is to back extended files to tape/virtual tape. Your answer said the data read will be expanded. So even by setting compact as N, the amount of data written to tape/virtual tape will be same, right? My another question is: If I set compact=N for storage class, so data sets will not be compressed/compacted. If I use same utility to copy it to tape/virtual tape, will there any difference for the data stream writing to tape? I already noticed a difference: By enabling compact option in storage class, I have very low compression ratio for data written to tape/virtual tape, do you have any idea? Regards Victor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Questions regarding SMS compacted dataset
Hello, One simple question#65306; If the PS data set's SC is defined with COMPACT= YES, then when host read the file, will the PS data be rehydrate or not? I mean will uncompressed data be return to z/os? Regards Victor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Questions regarding SMS compacted dataset
Hi all, Sorry, forgot to mention is if the program trying to read compressed extended physical sequential file is ADRDSSU, will only compressed data be returned? How about IEBGEN program? Regards Victor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Linux LVM vs z/OS SMS Storage Group
On Mon, 20 Feb 2012 09:09:58 -0800, Edward Jaffe wrote: To grow LVM physical volumes in Linux for z (RHEL6) we had to one-by-one drain (pvmove) the volumes to be resized, remove from LVM, vary offline, dynamically grow, vary online, reformat and add back to LVM. If not enough free space is available in the LVM group to hold the contents of one physical volume, you must temporarily add another appropriately-sized volume to the group before beginning this process and then remove it at the end. Whew! It was so involved that the last time we had a Linux on z space issue, we bit the bullet and just added a new physical volume to the LVM group (after first updating the IODF/IOCDS). :-( pvresize not available ?. pvscan ?. Gotta ask as I don't have a system to check. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Linux LVM vs z/OS SMS Storage Group
On 2/20/2012 5:34 AM, John McKown wrote: On Mon, 2012-02-20 at 08:42 +0100, R.S. wrote: snip What is cool is that SMS storage group. Usually users do not see the volumes, they see dasd space. In case of shortage you can simply add some volumes to the group. You can even buy new box and simply add it to the group. And that's really cool IMHO. You'd like LVM2 on Linux. You assign your physical disk partitions to a physical volume group (conceptually like an SMS volume group). You can then divvy up the space in that group into various sized logical volumes. This is then initialized with a filesystem with mkfs (equivalent to ICKDSF, I guess). If the filesystem runs out of space, and you used the proper type of filesystem (there are many), you simply expand the size of the logical volume into unused space in the group. You then resize the filesystem. If you used ext4 or btrfs, I think you can do this while it is in use. If you used ext3, I think you need to unmount it (take it offline) to resize it. If you're out of space in the volume group, buy another disk and initialize it into the physical volume group, then expand. logical volume space does not need to be physically contiguous. We use LVM on Linux for System z. Unfortunately, it can't handle physical disks that dynamically grow in size. :-( On z/OS, we have two options for enlarging the space available in an SMS storage group: a) we can define new volumes and add them to the group or b) we can dynamically increase the size of the volumes already in the group. We have used the latter approach many times because device addresses are at a premium here, fewer, larger volumes are easier for us to manage, and we don't have to mess with the z/OS IODF, IOCDS, SCDS/ACDS, etc. The new space is just magically available. To grow LVM physical volumes in Linux for z (RHEL6) we had to one-by-one drain (pvmove) the volumes to be resized, remove from LVM, vary offline, dynamically grow, vary online, reformat and add back to LVM. If not enough free space is available in the LVM group to hold the contents of one physical volume, you must temporarily add another appropriately-sized volume to the group before beginning this process and then remove it at the end. Whew! It was so involved that the last time we had a Linux on z space issue, we bit the bullet and just added a new physical volume to the LVM group (after first updating the IODF/IOCDS). :-( -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
OT - SMS Invision question
As a system programmer I have been assigned the task of taking a customer's SMS Invision system, PA, AP, GL, etc., and restoring it to our system. We have restored all of the data sets. Now, I have been asked to identify and run only the PA (Patient Accounting) part of their batch schedule. A) Is it possible to only run the PA part of the batch schedule B) Has anyone on IBM-Main done something like this, and can you offer assistance/advice. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: System Dumps and SMS allocation fails
Well the problem has been solved, thanks to all for their thoughts. I removed the space and DCB attributes, except for the DSNTYPE=LARGE from the dataclass and all is well. Not quite sure why, but whatever works. Ken Leidner kleid...@earthlink.net -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: System Dumps and SMS allocation fails
From an SMS point of view all is well. Allocation works has the correct attributes and is placed on the correct volume. At 05:43 PM 2/13/2012, you wrote: Ken - Scratch what I said. It appears it tried to allocate into SGDUMP first and failed. What are the volumes in SGDUMP? What are their statuses? ENABLED? QUINEW? DISNEW? When you attempt to allocate via 3.2, is that where they go? Ken Leidner kleid...@earthlink.net -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
System Dumps and SMS allocation fails
First this is a long entry, but I wanted to have all the information here in hope that someone would have the answer. We are trying to convert to using SMS managed volumes for our system dumps since we need the LARGE attribute for our large DB2 dumps. But something is preventing the dumps from allocation when MVS tries to make the allocation. What? HELP! I can make the allocation find from 3.2 or even IEFBR14 in batch. Correct volumes correct size all is well, but MVS still fails when it tries. (using just the dataclas, storclas and mgmtclas in the allocation) SMS volumes are 2 empty mod-9 (other than VTOC, VTOCIX and VVDS).with largest free space as 9,993 cylinders on each one. Here are the messages we receive when a dump occurs. All standard messages, other than I cannot explain the DO NOT HAVE SUFFICIENT SPACE message. Plus the messages after that are odd! The IEF196I IGD100I message. The address D913 is for volume SYX5D1 (one of the non SMS volumes). The dataclass is also not the one in parmlib. Maybe this is just a sequence error in that this message should appear after the WILL TRY VOLUME ALLOCATION. Any help in what the meaning of the message below is trying to tell me or where and what to look up would be helpful DYNALLOC FAILED RETURN CODE=04 ERROR RSN CODE=970C INFO RSN CODE= The messages IGD17272I VOLUME SELECTION HAS FAILED FOR INSUFFICIENT SPACE FOR DATA SET ZP.DUMP.PLXB.S9 JOBNAME (DUMPSRV ) STEPNAME (DUMPSRV ) PROGNAME (IEAVTDSV) DDNAME (SYS00016) REQUESTED SPACE QUANTITY = 2311283 KB STORCLAS (SCDUMP) MGMTCLAS (MCDUMP) DATACLAS (DCDUMP) STORGRPS (SGDUMP ) IKJ56893I DATA SET ZP.DUMP.PLXB.S9 NOT ALLOCATED+ IGD17273I ALLOCATION HAS FAILED FOR ALL VOLUMES SELECTED FOR DATA SET ZP.DUMP.PLXB.S9 IGD17277I THERE ARE (2) CANDIDATE VOLUMES OF WHICH (2) ARE ENABLED OR QUIESCED IGD17290I THERE WERE 1 CANDIDATE STORAGE GROUPS OF WHICH THE FIRST 1 WERE ELIGIBLE FOR VOLUME SELECTION. THE CANDIDATE STORAGE GROUPS WERE:SGDUMP IGD17279I 2 VOLUMES WERE REJECTED BECAUSE THEY DID NOT HAVE SUFFICIENT SPACE (041A041D) IEF196I IGD100I D913 ALLOCATED TO DDNAME SYS00017 DATACLAS (DCDFALT) IEA799I AUTOMATIC ALLOCATION OF SVC DUMP DATASET FAILED 168 DUMPID=009 REQUESTED BY JOB (*MASTER*) DYNALLOC FAILED RETURN CODE=04 ERROR RSN CODE=970C INFO RSN CODE= SMS RSN CODE=4379, WILL TRY VOLUME ALLOCATION Here is the parmlib entries for the dumps. Note that the VOL parameter is for the old non SMS volumes that we use to use still do since SMS isnt working. COM='DD ALLOC=ACTIVE' COM='DD ADD,SMS=(DATA=DCDUMP,MGMT=MCDUMP,STOR=SCDUMP)' COM='DD ADD,VOL=(SYX5D1,SYX5D2)' COM='DD NAME=ZP.DUMP.PLXB.SSEQ.' COM='CD SET,SDUMP=(ALLPSA,NUC,SQA,LSQA,RGN,LPA,TRT,SWA,CSA,SUM),Q=NO' COM='CD SET,SDUMP=(XESDATA)' COM='CD SET,SDUMP=(GRSQ)' COM='CD SET,SDUMP,MAXSPACE=2816M' The complete dataclass - The space is large 128,000 tracks or 6,240,000 KB. Do I even need to code the space? LRECL? RECFM? Data Class Name : DCDUMP Description : Recfm . . . . . . . . . : FBS Lrecl . . . . . . . . . : 4160 Override Space . . . . . : NO Space Avgrec . . . . . . : K Avg Value . . . . : 24960 Primary . . . . . : 250 Secondary . . . . : 60 Directory . . . . : Retpd Or Expdt . . . . . : Volume Count . . . . . . : Add'l Volume Amount . . : Data Set Name Type . . . . . : LARGE If Extended . . . . . . . . : Extended Addressability . . : NO Record Access Bias . . . . : Space Constraint Relief . . . : NO Reduce Space Up To (%) . . : Dynamic Volume Count . . . : Compaction . . . . . . . . . : Spanned / Nonspanned . . . . : Media Interchange Media Type . . . . . . . . : Recording Technology . . . : Performance Scaling . . . . : Performance Segmentation . : Encryption Management Key Label 1: Encoding for Key Label 1 : Key Label 2: Encoding for Key Label 2 : System Managed Buffer . . . : System Determined Blocksize : YES Block Size Limit . . . . . . : EATTR . . . . . . . . . . . : Recorg . . . . . . . . . . . : Keylen . . . . . . . . . . . : Keyoff . . . . . . . . . . . : CIsize Data . . . . . . . . : % Freespace CI . . . . . . . : CA . . . . . . . : Shareoptions Xregion . . . . : Xsystem . . . . : Reuse . . . . . . . . . . . : NO Initial Load . . . . . . . . : RECOVERY BWO . . . . . . . . . . . . : Log . . . . . . . . . . . . : Logstream Id . . . . . . . . : FRlog . . . . . . . . . . . : RLS CF Cache Value . . . . . : ALL RLS Above the 2-GB Bar . . . : NO Extent Constraint Removal . : NO CA Reclaim . . . . . . . . . : YES Ken Leidner kleid...@earthlink.net -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: System Dumps and SMS allocation fails
When allocating files via SMS, the SMS attributes then either have to be explicitly assigned or allowed to be assigned. You mention that the DC is one that is not listed in the parmlib and the volume is a non-sms volume; thus, check your ACS routines for the SMS allocation of these files. Thanks, Hervey -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ken Leidner Sent: Friday, February 10, 2012 11:06 AM To: IBM-MAIN@bama.ua.edu Subject: System Dumps and SMS allocation fails First this is a long entry, but I wanted to have all the information here in hope that someone would have the answer. We are trying to convert to using SMS managed volumes for our system dumps since we need the LARGE attribute for our large DB2 dumps. But something is preventing the dumps from allocation when MVS tries to make the allocation. What? HELP! I can make the allocation find from 3.2 or even IEFBR14 in batch. Correct volumes correct size - all is well, but MVS still fails when it tries. (using just the dataclas, storclas and mgmtclas in the allocation) SMS volumes are 2 empty mod-9 (other than VTOC, VTOCIX and VVDS).with largest free space as 9,993 cylinders on each one. Here are the messages we receive when a dump occurs. All standard messages, other than I cannot explain the DO NOT HAVE SUFFICIENT SPACE message. Plus the messages after that are odd! The IEF196I IGD100I message. The address D913 is for volume SYX5D1 (one of the non SMS volumes). The dataclass is also not the one in parmlib. Maybe this is just a sequence error in that this message should appear after the WILL TRY VOLUME ALLOCATION. Any help in what the meaning of the message below is trying to tell me or where and what to look up would be helpful DYNALLOC FAILED RETURN CODE=04 ERROR RSN CODE=970C INFO RSN CODE= The messages IGD17272I VOLUME SELECTION HAS FAILED FOR INSUFFICIENT SPACE FOR DATA SET ZP.DUMP.PLXB.S9 JOBNAME (DUMPSRV ) STEPNAME (DUMPSRV ) PROGNAME (IEAVTDSV) DDNAME (SYS00016) REQUESTED SPACE QUANTITY = 2311283 KB STORCLAS (SCDUMP) MGMTCLAS (MCDUMP) DATACLAS (DCDUMP) STORGRPS (SGDUMP ) IKJ56893I DATA SET ZP.DUMP.PLXB.S9 NOT ALLOCATED+ IGD17273I ALLOCATION HAS FAILED FOR ALL VOLUMES SELECTED FOR DATA SET ZP.DUMP.PLXB.S9 IGD17277I THERE ARE (2) CANDIDATE VOLUMES OF WHICH (2) ARE ENABLED OR QUIESCED IGD17290I THERE WERE 1 CANDIDATE STORAGE GROUPS OF WHICH THE FIRST 1 WERE ELIGIBLE FOR VOLUME SELECTION. THE CANDIDATE STORAGE GROUPS WERE:SGDUMP IGD17279I 2 VOLUMES WERE REJECTED BECAUSE THEY DID NOT HAVE SUFFICIENT SPACE (041A041D) IEF196I IGD100I D913 ALLOCATED TO DDNAME SYS00017 DATACLAS (DCDFALT) IEA799I AUTOMATIC ALLOCATION OF SVC DUMP DATASET FAILED 168 DUMPID=009 REQUESTED BY JOB (*MASTER*) DYNALLOC FAILED RETURN CODE=04 ERROR RSN CODE=970C INFO RSN CODE= SMS RSN CODE=4379, WILL TRY VOLUME ALLOCATION Here is the parmlib entries for the dumps. Note that the VOL parameter is for the old non SMS volumes that we use to use - still do since SMS isn't working. COM='DD ALLOC=ACTIVE' COM='DD ADD,SMS=(DATA=DCDUMP,MGMT=MCDUMP,STOR=SCDUMP)' COM='DD ADD,VOL=(SYX5D1,SYX5D2)' COM='DD NAME=ZP.DUMP.PLXB.SSEQ.' COM='CD SET,SDUMP=(ALLPSA,NUC,SQA,LSQA,RGN,LPA,TRT,SWA,CSA,SUM),Q=NO' COM='CD SET,SDUMP=(XESDATA)' COM='CD SET,SDUMP=(GRSQ)' COM='CD SET,SDUMP,MAXSPACE=2816M' The complete dataclass - The space is large 128,000 tracks or 6,240,000 KB. Do I even need to code the space? LRECL? RECFM? Data Class Name : DCDUMP Description : Recfm . . . . . . . . . : FBS Lrecl . . . . . . . . . : 4160 Override Space . . . . . : NO Space Avgrec . . . . . . : K Avg Value . . . . : 24960 Primary . . . . . : 250 Secondary . . . . : 60 Directory . . . . : Retpd Or Expdt . . . . . : Volume Count . . . . . . : Add'l Volume Amount . . : Data Set Name Type . . . . . : LARGE If Extended . . . . . . . . : Extended Addressability . . : NO Record Access Bias . . . . : Space Constraint Relief . . . : NO Reduce Space Up To (%) . . : Dynamic Volume Count . . . : Compaction . . . . . . . . . : Spanned / Nonspanned . . . . : Media Interchange Media Type . . . . . . . . : Recording Technology . . . : Performance Scaling . . . . : Performance Segmentation . : Encryption Management Key Label 1: Encoding for Key Label 1 : Key Label 2: Encoding for Key Label 2 : System Managed Buffer . . . : System Determined Blocksize : YES Block Size Limit . . . . . . : EATTR . . . . . . . . . . . : Recorg . . . . . . . . . . . : Keylen . . . . . . . . . . . : Keyoff . . . . . . . . . . . : CIsize Data . . . . . . . . : % Freespace CI . . . . . . . : CA . . . . . . . : Shareoptions Xregion . . . . : Xsystem . . . . : Reuse . . . . . . . . . . . : NO Initial Load . . . . . . . . : RECOVERY BWO . . . . . . . . . . . . : Log . . . . . . . . . . . . : Logstream Id . . . . . . . . : FRlog . . . . . . . . . . . : RLS CF Cache Value . . . . . : ALL RLS Above the 2-GB Bar
Re: System Dumps and SMS allocation fails
I think you miss understood the comment. The message STORCLAS (SCDUMP) MGMTCLAS (MCDUMP) DATACLAS (DCDUMP) STORGRPS (SGDUMP ) has all of the correct attributes. This message IEF196I IGD100I D913 ALLOCATED TO DDNAME SYS00017 DATACLAS (DCDFALT) IEA799I AUTOMATIC ALLOCATION OF SVC DUMP DATASET FAILED 168 Has both the non sms volume address D(13 and the wrong dataclass (DCDFALT) for the SMS allocation. Ken Leidner kleid...@earthlink.net -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: System Dumps and SMS allocation fails
On Fri, Feb 10, 2012 at 10:05 AM, Ken Leidner kleid...@earthlink.net wrote: deleted REQUESTED SPACE QUANTITY = 2311283 KB note 2.2 GB or so deleted The complete dataclass - The space is large 128,000 tracks or 6,240,000 KB. Do I even need to code the space? LRECL? RECFM? Data Class Name : DCDUMP Description : Recfm . . . . . . . . . : FBS Lrecl . . . . . . . . . : 4160 Override Space . . . . . : NO Space Avgrec . . . . . . : K Avg Value . . . . : 24960 Primary . . . . . : 250 Secondary . . . . : 60 Directory . . . . : deleted note 24960 * 250 * 1024 (K) = 6,389,760,000 bytes. Correct? As an experiment I might try cutting your primary amount to under 4GB (140,70). -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: System Dumps and SMS allocation fails
:: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On :: Behalf Of Ken Leidner :: Sent: Friday, February 10, 2012 8:06 AM :: To: IBM-MAIN@bama.ua.edu :: Subject: System Dumps and SMS allocation fails :: :: First this is a long entry, but I wanted to have :: all the information here in hope that someone would have the answer. :: :: We are trying to convert to using SMS managed :: volumes for our system dumps since we need the :: LARGE attribute for our large DB2 dumps. But :: something is preventing the dumps from allocation :: when MVS tries to make the allocation. What? HELP! :: :: I can make the allocation find from 3.2 or even :: IEFBR14 in batch. Correct volumes correct size - :: all is well, but MVS still fails when it :: tries. (using just the dataclas, storclas and mgmtclas in the :: allocation) :: :: SMS volumes are 2 empty mod-9 (other than VTOC, :: VTOCIX and VVDS).with largest free space as 9,993 cylinders on each one. :: :: Here are the messages we receive when a dump :: occurs. All standard messages, other than I :: cannot explain the DO NOT HAVE SUFFICIENT SPACE :: message. Plus the messages after that are :: odd! The IEF196I IGD100I message. The address :: D913 is for volume SYX5D1 (one of the non SMS :: volumes). The dataclass is also not the one in :: parmlib. Maybe this is just a sequence error :: in that this message should appear after the WILL TRY VOLUME ALLOCATION. The IEF196I IGD100I message is for a different DD name (SYS00017) and reflects a successful allocation. The fact that it is interspersed with the messages for the dump (SYS00016) is probably just an unfortunate coincidence. :: :: Any help in what the meaning of the message below :: is trying to tell me or where and what to look up would be helpful :: :: DYNALLOC FAILED RETURN CODE=04 ERROR RSN CODE=970C INFO RSN CODE= :: :: The messages :: :: IGD17272I VOLUME SELECTION HAS FAILED FOR INSUFFICIENT SPACE FOR :: DATA SET ZP.DUMP.PLXB.S9 :: JOBNAME (DUMPSRV ) STEPNAME (DUMPSRV ) :: PROGNAME (IEAVTDSV) DDNAME (SYS00016) :: REQUESTED SPACE QUANTITY = 2311283 KB :: STORCLAS (SCDUMP) MGMTCLAS (MCDUMP) DATACLAS (DCDUMP) STORGRPS (SGDUMP ) :: IKJ56893I DATA SET ZP.DUMP.PLXB.S9 NOT ALLOCATED+ :: IGD17273I ALLOCATION HAS FAILED FOR ALL VOLUMES :: SELECTED FOR DATA SET ZP.DUMP.PLXB.S9 :: IGD17277I THERE ARE (2) CANDIDATE VOLUMES OF WHICH (2) ARE ENABLED OR :: QUIESCED :: IGD17290I THERE WERE 1 CANDIDATE STORAGE GROUPS OF WHICH THE FIRST 1 :: WERE ELIGIBLE FOR VOLUME SELECTION. :: THE CANDIDATE STORAGE GROUPS WERE:SGDUMP :: IGD17279I 2 VOLUMES WERE REJECTED BECAUSE THEY :: DID NOT HAVE SUFFICIENT SPACE (041A041D) :: :: :: IEF196I IGD100I D913 ALLOCATED TO DDNAME SYS00017 DATACLAS (DCDFALT) :: IEA799I AUTOMATIC ALLOCATION OF SVC DUMP DATASET FAILED 168 :: DUMPID=009 REQUESTED BY JOB (*MASTER*) :: DYNALLOC FAILED RETURN CODE=04 ERROR RSN CODE=970C INFO RSN CODE= :: SMS RSN CODE=4379, WILL TRY VOLUME ALLOCATION :: :: :: Here is the parmlib entries for the dumps. Note :: that the VOL parameter is for the old non SMS :: volumes that we use to use - still do since SMS isn't working. :: :: COM='DD ALLOC=ACTIVE' :: COM='DD ADD,SMS=(DATA=DCDUMP,MGMT=MCDUMP,STOR=SCDUMP)' :: COM='DD ADD,VOL=(SYX5D1,SYX5D2)' :: COM='DD NAME=ZP.DUMP.PLXB.SSEQ.' :: COM='CD SET,SDUMP=(ALLPSA,NUC,SQA,LSQA,RGN,LPA,TRT,SWA,CSA,SUM),Q=NO' :: COM='CD SET,SDUMP=(XESDATA)' :: COM='CD SET,SDUMP=(GRSQ)' :: COM='CD SET,SDUMP,MAXSPACE=2816M' :: :: :: The complete dataclass - The space is large :: 128,000 tracks or 6,240,000 KB. Do I even need :: to code the space? LRECL? RECFM? :: :: Data Class Name : DCDUMP :: Description : :: Recfm . . . . . . . . . : FBS :: Lrecl . . . . . . . . . : 4160 :: Override Space . . . . . : NO :: Space Avgrec . . . . . . : K :: Avg Value . . . . : 24960 :: Primary . . . . . : 250 :: Secondary . . . . : 60 :: Directory . . . . : :: Retpd Or Expdt . . . . . : :: Volume Count . . . . . . : :: Add'l Volume Amount . . : :: Data Set Name Type . . . . . : LARGE With a blocksize of 24960, your 9,993 cylinder free space should hold 7.48GB. Your dump parameters specify a max size of 2.95GB so it should fit. The message states the dump is requesting 2.36GB which also should fit. The primary space allocation in the dataclass is 6.38GB which is close to the total free space but not that close. Is it possible that the allocation request from the dump is somehow specifying the need for a secondary extent? Each secondary extent requires an additional 1.53GB. Just one secondary puts the total at 7.92GB which exceeds the 7.48GB total free space. Given the dump parameter of 2.95GB, maybe you should change the dataclass to specify half the current primary amount. Is the SMS default geometry set to 3390? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu
Re: System Dumps and SMS allocation fails
First this is a long entry, but I wanted to have all the information here in hope that someone would have the answer. We are trying to convert to using SMS managed volumes for our system dumps since we need the LARGE attribute for our large DB2 dumps. But something is preventing the dumps from allocation when MVS tries to make the allocation. What? HELP! In z/OS 1.13, SDUMP specifies the DSNTYPE=LARGE text unit when dynamically allocating a dump data set, if the dump data set size is larger than 64k tracks. Prior to z/OS 1.13, for dump data sets larger then 64k tracks, you would need to use your SMS ACS routines to change the DSNTYPE to EXTENDED (or maybe you can also change it to LARGE). Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMS/ISMF Pool Storage Group Screen(s)
In 0969741506457681.wa.markmzelden@bama.ua.edu, on 02/06/2012 at 05:35 PM, Mark Zelden m...@mzelden.com said: MVS/ESA V3. But you could also order / install it with MVS/XA 2.2.3. Some features were not available in the initial versions. When did IGDZILLA come along? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMS/ISMF Pool Storage Group Screen(s)
Sorry, I was in too much of a rush to catch the van pool and did not get my point across clearly. The setting I was trying to point out is the : Alloc/Migr Threshold Track_Managed... It would be so much easier if I could add a screen print but I haven't figure out how to do that in this forum just yet. Since we don't have a z/os 1.9 lpar anymore, I can't verify it but as far as I'm aware, this setting was not in the definition/alter screens for ISMF storage pool screen when we were on 1.9. Someone was kind enough to respond offline and point out to me that: I believe you're referring to the EAV support in z/OS 1.10 I see the fields you are referring to in 1.10 and 1.12 from the 1.10 manual : In addition to the break-point value setting, the storage group also : | lets you specify a setting for track-managed free space thresholds | (high and low). These thresholds are factored into the SMS volume | selection algorithms and DFSMShsm space management. Since we skipped from 1.9 to 1.11, I was just caught off guard because I did not see anything in the migration guide. Thanks Bobbie and others who replied! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SMS/ISMF Pool Storage Group Screen(s)
Can someone please clarify something for me. Apparently, there were some parameters that were introduced to SMS/ISMF and these parameters were not present in the 1.9 release but are there now in the 1.11 release. In particular I am talking about the Pool Storage Group Define or Alter screen(s). In Z/OS 1.9, I do not remember having the following settings: Allocation/migration Threshold : High..85 (1-99) Low . . 1 (0-99) Alloc/Migr Threshold Track-Managed: High..85 (1-99) Low . . 1 (0-99) Were these parameters introduced in 1.11 and if so were there some PTFs required to implement these? We have been on z/os 1.11 since around Aug/Sept of last year and we were cruising along just fine until recently. All of a sudden we have a pool filling up and not migrating datasets like they used to. I have not been able to locate any documentation warning of this change either in any release guides or migration notes. It just all of a sudden appears in the SMS implementation guide but perhaps I was not looking in the right place. I would appreciate any info on this topic if you have some. Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMS/ISMF Pool Storage Group Screen(s)
The SMS pool thresholds have been there for many years--I'm willing to bet that they were there even before zos came into the picture. Thanks, Hervey -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Gilbert Cardenas Sent: Monday, February 06, 2012 3:01 PM To: IBM-MAIN@bama.ua.edu Subject: SMS/ISMF Pool Storage Group Screen(s) Can someone please clarify something for me. Apparently, there were some parameters that were introduced to SMS/ISMF and these parameters were not present in the 1.9 release but are there now in the 1.11 release. In particular I am talking about the Pool Storage Group Define or Alter screen(s). In Z/OS 1.9, I do not remember having the following settings: Allocation/migration Threshold : High..85 (1-99) Low . . 1 (0-99) Alloc/Migr Threshold Track-Managed: High..85 (1-99) Low . . 1 (0-99) Were these parameters introduced in 1.11 and if so were there some PTFs required to implement these? We have been on z/os 1.11 since around Aug/Sept of last year and we were cruising along just fine until recently. All of a sudden we have a pool filling up and not migrating datasets like they used to. I have not been able to locate any documentation warning of this change either in any release guides or migration notes. It just all of a sudden appears in the SMS implementation guide but perhaps I was not looking in the right place. I would appreciate any info on this topic if you have some. Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMS/ISMF Pool Storage Group Screen(s)
Way before zOS. SMS was delivered in the ESA V4 time frame. Mark Jacobs On 02/06/12 15:16, Hervey Martinez wrote: The SMS pool thresholds have been there for many years--I'm willing to bet that they were there even before zos came into the picture. Thanks, Hervey -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Gilbert Cardenas Sent: Monday, February 06, 2012 3:01 PM To: IBM-MAIN@bama.ua.edu Subject: SMS/ISMF Pool Storage Group Screen(s) Can someone please clarify something for me. Apparently, there were some parameters that were introduced to SMS/ISMF and these parameters were not present in the 1.9 release but are there now in the 1.11 release. In particular I am talking about the Pool Storage Group Define or Alter screen(s). In Z/OS 1.9, I do not remember having the following settings: Allocation/migration Threshold : High..85 (1-99) Low . . 1 (0-99) Alloc/Migr Threshold Track-Managed: High..85 (1-99) Low . . 1 (0-99) Were these parameters introduced in 1.11 and if so were there some PTFs required to implement these? We have been on z/os 1.11 since around Aug/Sept of last year and we were cruising along just fine until recently. All of a sudden we have a pool filling up and not migrating datasets like they used to. I have not been able to locate any documentation warning of this change either in any release guides or migration notes. It just all of a sudden appears in the SMS implementation guide but perhaps I was not looking in the right place. I would appreciate any info on this topic if you have some. Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- Mark Jacobs Time Customer Service Tampa, FL Don't be too sweet lest you be eaten up; don't be too bitter lest you be spewed out. Yiddish Proverb -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMS/ISMF Pool Storage Group Screen(s)
On Mon, Feb 6, 2012 at 2:01 PM, Gilbert Cardenas gilbertcarde...@grocerybiz.com wrote: deleted We have been on z/os 1.11 since around Aug/Sept of last year and we were cruising along just fine until recently. All of a sudden we have a pool filling up and not migrating datasets like they used to. deleted Someone might have changed the MGMTCLAS for the datasets that don't migrate or they might have switched to a different MGMTCLAS on the JCL that creates the datasets. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SMS/ISMF Pool Storage Group Screen(s)
On Mon, 6 Feb 2012 15:24:44 -0500, Mark Jacobs mark.jac...@custserv.com wrote: Way before zOS. SMS was delivered in the ESA V4 time frame. Mark Jacobs MVS/ESA V3. But you could also order / install it with MVS/XA 2.2.3. IIRC, that was really the only difference between MVS/XA 2.2.0 and 2.2.3. 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...@bama.ua.edu with the message: INFO IBM-MAIN
SMS QUESTION ABOUT Expire after Date/Days
G'Day To All, I am setting up a new Management Class for some TSO/ISPF libs. Presently both the Expire after Days Non-Usage and Expire after Date/Days are at NOLIMIT. I have a request to change the Expire after days Non-usage to 1100 days. My question is about the Expire after Date/Days. If I understand the doc correctly, if I code 10 in this field does it mean the dsn will be eligible for expiration after 10 days? Since I need to keep the dsn for 1100 days after non-usage would it be recommended to use 1100 for Expire after Date/Days as well? Thanks in advance for your advice. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS QUESTION ABOUT Expire after Date/Days
I would go with EXPIRE NON-USAGE 1100 EXPIRE DATE/DAYS NOLIMIT. If you go into help on this panel (DGTLGP21) and look up the column descriptions for these 2 columns, it describes the interaction between these 2 parameters. HTH, snip I am setting up a new Management Class for some TSO/ISPF libs. Presently both the Expire after Days Non-Usage and Expire after Date/Days are at NOLIMIT. I have a request to change the Expire after days Non-usage to 1100 days. My question is about the Expire after Date/Days. If I understand the doc correctly, if I code 10 in this field does it mean the dsn will be eligible for expiration after 10 days? Since I need to keep the dsn for 1100 days after non-usage would it be recommended to use 1100 for Expire after Date/Days as well? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS QUESTION ABOUT Expire after Date/Days
Allan, Thanks for the tip and your suggestion. From: Staller, Allan allan.stal...@kbmg.com To: IBM-MAIN@bama.ua.edu Sent: Friday, 14 October 2011 10:04 AM Subject: Re: SMS QUESTION ABOUT Expire after Date/Days I would go with EXPIRE NON-USAGE 1100 EXPIRE DATE/DAYS NOLIMIT. If you go into help on this panel (DGTLGP21) and look up the column descriptions for these 2 columns, it describes the interaction between these 2 parameters. HTH, snip I am setting up a new Management Class for some TSO/ISPF libs. Presently both the Expire after Days Non-Usage and Expire after Date/Days are at NOLIMIT. I have a request to change the Expire after days Non-usage to 1100 days. My question is about the Expire after Date/Days. If I understand the doc correctly, if I code 10 in this field does it mean the dsn will be eligible for expiration after 10 days? Since I need to keep the dsn for 1100 days after non-usage would it be recommended to use 1100 for Expire after Date/Days as well? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SMS question about expire after days/date
Allen Staller has given you good advice, formulated very politely. If you code EXPIRE NON-USAGE 1100 EXPIRE DAYS/DATE 1100 you moot the first statement. The dataset will expire unconditionally after 1100 days, however frequently it is used in this interval. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS question about expire after days/date
Thanks John. I have heeded Allan's advice. From: John Gilmore johnwgilmore0...@gmail.com To: IBM-MAIN@bama.ua.edu Sent: Friday, 14 October 2011 11:07 AM Subject: SMS question about expire after days/date Allen Staller has given you good advice, formulated very politely. If you code EXPIRE NON-USAGE 1100 EXPIRE DAYS/DATE 1100 you moot the first statement. The dataset will expire unconditionally after 1100 days, however frequently it is used in this interval. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS question about expire after days/date
One hypothetical situation using tax info retention laws might be where you can delete a file after 7 years of non-usage (normal retention if no request for info) and after 10 years even if you used it yesterday (because the investigators have to compile their information by this deadline). EXPIRE NON-USAGE 2557 (7 years, 2 leap days after last use) EXPIRE DAYS/DATE 3653 (10 Years, 3 leap days after creation) On Fri, Oct 14, 2011 at 10:07 AM, John Gilmore johnwgilmore0...@gmail.com wrote: Allen Staller has given you good advice, formulated very politely. If you code EXPIRE NON-USAGE 1100 EXPIRE DAYS/DATE 1100 you moot the first statement. The dataset will expire unconditionally after 1100 days, however frequently it is used in this interval. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SMS question about expire after days/date
My understanding was and is that the earliest enjoined expiration date is controlling. I have, however, set up a sequence of tests of this hypothesis; and I will report their results in a week's time if they are of any interest. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS question about expire after days/date
Thanks John. I appreciate your willingness to set up a test and would be very interested in the results. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Gilmore Sent: Friday, October 14, 2011 11:42 AM To: IBM-MAIN@bama.ua.edu Subject: SMS question about expire after days/date My understanding was and is that the earliest enjoined expiration date is controlling. I have, however, set up a sequence of tests of this hypothesis; and I will report their results in a week's time if they are of any interest. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EMC DLm SMS or not
Thanks Radoslaw Mark. BE would have VNX disks. I'll chase up the user guide, thanks. Cheers. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EMC DLm SMS or not
On Thu, 6 Oct 2011 22:51:55 -0500, R Hey sys...@yahoo.com wrote: Hi, I heard tapes can be defined as nonSMS or SMS when using DLm. What are the +/- of each? Do you have a copy of the DLm User Guide? It discusses the options in detail. While adding in SMS and OAM may be a few extra steps, it makes the cut over very easy. When you are ready you can direct output to the DLm by specific jobnames, unitnames, etc. or everything when you are ready with simple STORCLAS changes. One thing that may not be clear: If you have more than one DLm (locally, not being used for DR replication), you must configure them as MTL and use OAM / SMS. Otherwise when an input volume is needed the system would not know which library to get it from. Any heads up as what to do or not when moving to DLm (setup, design, config, DR, HSM, ...) ? Make sure you plan the file sizes and volser ranges within the DLm carefully. Have more ranges than you need so that is never the bottleneck. Don't make the virtual tape sizes too big for small systems. At a client site we initially use a one size fits all by making all virtual tapes 40G. The problem was a few of the small monoplex LPARs using the DLm had file systems that were only 150G to start with. When they reached 110G (about 70% full, which was the projected usage after migration) the DLm wouldn't mount a scratch because it had no way of knowing the output wouldn't be 40G. We reduced the size to 5G for those small LPARs. BTW, 40G was chosen because it matched the size of the Oracle/STK 9840C that was being used for physical tape (mostly HSM) for most of the environment). Also, if use 2 DLm (Primary DR site), what kind of problems should one watch out for REAL-DR? (DLm1 replicates to DLm2, MVS crashes in the middle, DR starts DLm2 used DB2 logs? HSM recyles? HSM bkup? ) Depends on your out of sync value or if you purchased and are using the guaranteed replication (GR) feature.The default out of sync for the Celerra Replicator (asynchronous replication) is 15 minutes so that is how far behind some of your file systems that hold virtual tapes can be at the time of a crash (assuming you have bandwidth etc. to keep up with replications). GR replicates the tape to the remote side on close and doesn't let the local side know it is closed until the replication is completed. The considerations based on the above varies by application so it's hard to answer your question. If you can, it's probably best to keep current versions of critical logs on DASD and copy older ones to tape or let HSM manage them. Again, the DLm User Guide is the place to start here... Regards, 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
EMC DLm SMS or not
Hi, I heard tapes can be defined as nonSMS or SMS when using DLm. What are the +/- of each? Any heads up as what to do or not when moving to DLm (setup, design, config, DR, HSM, ...) ? Also, if use 2 DLm (Primary DR site), what kind of problems should one watch out for REAL-DR? (DLm1 replicates to DLm2, MVS crashes in the middle, DR starts DLm2 used DB2 logs? HSM recyles? HSM bkup? ) TIA, Rez -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EMC DLm SMS or not
W dniu 2011-10-07 05:51, R Hey pisze: Hi, I heard tapes can be defined as nonSMS or SMS when using DLm. What are the +/- of each? It is recommended to use MTL (Manual Tape Library) definitions for DLM. Otherwise you have to use custom defined device type in HCD (their own UIM). Advantage of SMS MTL? It works. Easy setup, no problems. Any heads up as what to do or not when moving to DLm (setup, design, config, DR, HSM, ...) ? It depends on form what you're moving, what is your backend (DLM have to use some storage device behind) Also, if use 2 DLm (Primary DR site), what kind of problems should one watch out for REAL-DR? (DLm1 replicates to DLm2, MVS crashes in the middle, DR starts DLm2 used DB2 logs? HSM recyles? HSM bkup? ) Long story, mostly unrelated to DLM, but related to DR scenarios. In general: for not-ended tape jobs the scenario is the same for any tape solution. Unended tape job could mean lost whole job (data). What's more specific (but not unique) to DLM is asynchronous replication. Small chance, but possible that your job would end, but the tape volume is not (fully) replicated to DR site. So, you would lose your last tape. And you have to manage it. HTH -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2011 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.346.696 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
CONVERTING DASD TO SMS
G'Day All, I have the unenviable task of converting some IMS dasd to SMS. The volumes are presently non-SMS and contain IMS DBs. I looked at the ADRDSSU and the COVERTV parm is recommended to be used. My question is has anybody encountered any problems using CONVERTV? I plan to use this jcl to run the CONVERT of the volume: //STEP1 EXEC PGM=ADRDSSU,REGION=4M //SYSPRINT DD SYSOUT=* //INVOL1 DD VOL=SER=BELAN1,UNIT=3390,DISP=SHR //SYSIN DD * CONVERTV - TEST - DDNAME(INVOL1) - SMS /* Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CONVERTING DASD TO SMS
The key there is the TEST keyword. That will simulate the CONVERTV process and let you know if any problems will be encountered. Review its output, resolve any issues, rerun with TEST again and when you get a clean run, remove the TEST keyword. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Dawes Sent: Thursday, September 22, 2011 7:47 AM To: IBM-MAIN@bama.ua.edu Subject: CONVERTING DASD TO SMS G'Day All, I have the unenviable task of converting some IMS dasd to SMS. The volumes are presently non-SMS and contain IMS DBs. I looked at the ADRDSSU and the COVERTV parm is recommended to be used. My question is has anybody encountered any problems using CONVERTV? I plan to use this jcl to run the CONVERT of the volume: //STEP1 EXEC PGM=ADRDSSU,REGION=4M //SYSPRINT DD SYSOUT=* //INVOL1 DD VOL=SER=BELAN1,UNIT=3390,DISP=SHR //SYSIN DD * CONVERTV - TEST - DDNAME(INVOL1) - SMS /* Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CONVERTING DASD TO SMS
Robert, Thanks very much. I plan to run the simulate before I do the CONVERTV. From: Richards, Robert B. robert.richa...@opm.gov To: IBM-MAIN@bama.ua.edu Sent: Thursday, 22 September 2011 8:04 AM Subject: Re: CONVERTING DASD TO SMS The key there is the TEST keyword. That will simulate the CONVERTV process and let you know if any problems will be encountered. Review its output, resolve any issues, rerun with TEST again and when you get a clean run, remove the TEST keyword. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Dawes Sent: Thursday, September 22, 2011 7:47 AM To: IBM-MAIN@bama.ua.edu Subject: CONVERTING DASD TO SMS G'Day All, I have the unenviable task of converting some IMS dasd to SMS. The volumes are presently non-SMS and contain IMS DBs. I looked at the ADRDSSU and the COVERTV parm is recommended to be used. My question is has anybody encountered any problems using CONVERTV? I plan to use this jcl to run the CONVERT of the volume: //STEP1 EXEC PGM=ADRDSSU,REGION=4M //SYSPRINT DD SYSOUT=* //INVOL1 DD VOL=SER=BELAN1,UNIT=3390,DISP=SHR //SYSIN DD * CONVERTV - TEST - DDNAME(INVOL1) - SMS /* Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CONVERTING DASD TO SMS
I tried the TEST keyword but I received the following error messages: ADR874E (001)-KVOL (01), VOLUME VECA21 IS NOT ELIGIBLE FOR CONVERSION TO SMS MANAGEMENT, 008 According to the error message it says :The volume has a nonindexed VTOC I ran the following : /* //STEP1 EXEC PGM=ICKDSF,REGION=3M //MYVOL DD UNIT=3390,DISP=(OLD,KEEP),VOL=SER=VECA21, // DSN=SYS1.VTOCIX.VECA21 //SYSPRINT DD SYSOUT=* //SYSIN DD * BUILDIX DDNAME(MYVOL) IXVTOC /* I ran the CONVERT again but I still get the same error. Any suggestions that I can try? From: Richards, Robert B. robert.richa...@opm.gov To: IBM-MAIN@bama.ua.edu Sent: Thursday, 22 September 2011 8:04 AM Subject: Re: CONVERTING DASD TO SMS The key there is the TEST keyword. That will simulate the CONVERTV process and let you know if any problems will be encountered. Review its output, resolve any issues, rerun with TEST again and when you get a clean run, remove the TEST keyword. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Dawes Sent: Thursday, September 22, 2011 7:47 AM To: IBM-MAIN@bama.ua.edu Subject: CONVERTING DASD TO SMS G'Day All, I have the unenviable task of converting some IMS dasd to SMS. The volumes are presently non-SMS and contain IMS DBs. I looked at the ADRDSSU and the COVERTV parm is recommended to be used. My question is has anybody encountered any problems using CONVERTV? I plan to use this jcl to run the CONVERT of the volume: //STEP1 EXEC PGM=ADRDSSU,REGION=4M //SYSPRINT DD SYSOUT=* //INVOL1 DD VOL=SER=BELAN1,UNIT=3390,DISP=SHR //SYSIN DD * CONVERTV - TEST - DDNAME(INVOL1) - SMS /* Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CONVERTING DASD TO SMS
Have you added the volume to an appropriate storage group already? Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Dawes Sent: Thursday, September 22, 2011 8:52 AM To: IBM-MAIN@bama.ua.edu Subject: Re: CONVERTING DASD TO SMS I tried the TEST keyword but I received the following error messages: ADR874E (001)-KVOL (01), VOLUME VECA21 IS NOT ELIGIBLE FOR CONVERSION TO SMS MANAGEMENT, 008 According to the error message it says :The volume has a nonindexed VTOC I ran the following : /* //STEP1 EXEC PGM=ICKDSF,REGION=3M //MYVOL DD UNIT=3390,DISP=(OLD,KEEP),VOL=SER=VECA21, // DSN=SYS1.VTOCIX.VECA21 //SYSPRINT DD SYSOUT=* //SYSIN DD * BUILDIX DDNAME(MYVOL) IXVTOC /* I ran the CONVERT again but I still get the same error. Any suggestions that I can try? From: Richards, Robert B. robert.richa...@opm.gov To: IBM-MAIN@bama.ua.edu Sent: Thursday, 22 September 2011 8:04 AM Subject: Re: CONVERTING DASD TO SMS The key there is the TEST keyword. That will simulate the CONVERTV process and let you know if any problems will be encountered. Review its output, resolve any issues, rerun with TEST again and when you get a clean run, remove the TEST keyword. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Dawes Sent: Thursday, September 22, 2011 7:47 AM To: IBM-MAIN@bama.ua.edu Subject: CONVERTING DASD TO SMS G'Day All, I have the unenviable task of converting some IMS dasd to SMS. The volumes are presently non-SMS and contain IMS DBs. I looked at the ADRDSSU and the COVERTV parm is recommended to be used. My question is has anybody encountered any problems using CONVERTV? I plan to use this jcl to run the CONVERT of the volume: //STEP1 EXEC PGM=ADRDSSU,REGION=4M //SYSPRINT DD SYSOUT=* //INVOL1 DD VOL=SER=BELAN1,UNIT=3390,DISP=SHR //SYSIN DD * CONVERTV - TEST - DDNAME(INVOL1) - SMS /* Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CONVERTING DASD TO SMS
Is the volume a member of a storage group? Do the datasets on the volume get assigned to a storage class and storage group that contains the volume? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Dawes Sent: Thursday, September 22, 2011 3:52 PM To: IBM-MAIN@bama.ua.edu Subject: Re: CONVERTING DASD TO SMS I tried the TEST keyword but I received the following error messages: ADR874E (001)-KVOL (01), VOLUME VECA21 IS NOT ELIGIBLE FOR CONVERSION TO SMS MANAGEMENT, 008 According to the error message it says :The volume has a nonindexed VTOC I ran the following : /* //STEP1 EXEC PGM=ICKDSF,REGION=3M //MYVOL DD UNIT=3390,DISP=(OLD,KEEP),VOL=SER=VECA21, // DSN=SYS1.VTOCIX.VECA21 //SYSPRINT DD SYSOUT=* //SYSIN DD * BUILDIX DDNAME(MYVOL) IXVTOC /* I ran the CONVERT again but I still get the same error. Any suggestions that I can try? From: Richards, Robert B. robert.richa...@opm.gov To: IBM-MAIN@bama.ua.edu Sent: Thursday, 22 September 2011 8:04 AM Subject: Re: CONVERTING DASD TO SMS The key there is the TEST keyword. That will simulate the CONVERTV process and let you know if any problems will be encountered. Review its output, resolve any issues, rerun with TEST again and when you get a clean run, remove the TEST keyword. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Dawes Sent: Thursday, September 22, 2011 7:47 AM To: IBM-MAIN@bama.ua.edu Subject: CONVERTING DASD TO SMS G'Day All, I have the unenviable task of converting some IMS dasd to SMS. The volumes are presently non-SMS and contain IMS DBs. I looked at the ADRDSSU and the COVERTV parm is recommended to be used. My question is has anybody encountered any problems using CONVERTV? I plan to use this jcl to run the CONVERT of the volume: //STEP1 EXEC PGM=ADRDSSU,REGION=4M //SYSPRINT DD SYSOUT=* //INVOL1 DDVOL=SER=BELAN1,UNIT=3390,DISP=SHR //SYSINDD* CONVERTV - TEST - DDNAME(INVOL1) - SMS /* Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam's signatory rights, no offer, agreement, concession or representation is binding on the company, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the company's seal. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CONVERTING DASD TO SMS
John Dawes wrote: I ran the following : /* Where is that line starting with '/*' coming from? //STEP1 EXEC PGM=ICKDSF,REGION=3M //MYVOL DD UNIT=3390,DISP=(OLD,KEEP),VOL=SER=VECA21, // DSN=SYS1.VTOCIX.VECA21 //SYSPRINT DD SYSOUT=* //SYSIN DD * BUILDIX DDNAME(MYVOL) IXVTOC /* I ran the CONVERT again but I still get the same error. Any suggestions that I can try? Please post th results of that BUILDIX job plus any SYSLOG messages too... Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CONVERTING DASD TO SMS
I reran the BUILDIX and I am getting the error message : ADR874E VOLUME VECA21 IS NOT ELIGIBLE FOR CONVERSION TO SMS MANAGEMENT, 012 According to the error message explanation : From: גדי בן אבי gad...@malam.com To: IBM-MAIN@bama.ua.edu Sent: Thursday, 22 September 2011 8:55 AM Subject: Re: CONVERTING DASD TO SMS Is the volume a member of a storage group? Do the datasets on the volume get assigned to a storage class and storage group that contains the volume? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Dawes Sent: Thursday, September 22, 2011 3:52 PM To: IBM-MAIN@bama.ua.edu Subject: Re: CONVERTING DASD TO SMS I tried the TEST keyword but I received the following error messages: ADR874E (001)-KVOL (01), VOLUME VECA21 IS NOT ELIGIBLE FOR CONVERSION TO SMS MANAGEMENT, 008 According to the error message it says :The volume has a nonindexed VTOC I ran the following : /* //STEP1 EXEC PGM=ICKDSF,REGION=3M //MYVOL DD UNIT=3390,DISP=(OLD,KEEP),VOL=SER=VECA21, // DSN=SYS1.VTOCIX.VECA21 //SYSPRINT DD SYSOUT=* //SYSIN DD * BUILDIX DDNAME(MYVOL) IXVTOC /* I ran the CONVERT again but I still get the same error. Any suggestions that I can try? From: Richards, Robert B. robert.richa...@opm.gov To: IBM-MAIN@bama.ua.edu Sent: Thursday, 22 September 2011 8:04 AM Subject: Re: CONVERTING DASD TO SMS The key there is the TEST keyword. That will simulate the CONVERTV process and let you know if any problems will be encountered. Review its output, resolve any issues, rerun with TEST again and when you get a clean run, remove the TEST keyword. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Dawes Sent: Thursday, September 22, 2011 7:47 AM To: IBM-MAIN@bama.ua.edu Subject: CONVERTING DASD TO SMS G'Day All, I have the unenviable task of converting some IMS dasd to SMS. The volumes are presently non-SMS and contain IMS DBs. I looked at the ADRDSSU and the COVERTV parm is recommended to be used. My question is has anybody encountered any problems using CONVERTV? I plan to use this jcl to run the CONVERT of the volume: //STEP1 EXEC PGM=ADRDSSU,REGION=4M //SYSPRINT DD SYSOUT=* //INVOL1 DD VOL=SER=BELAN1,UNIT=3390,DISP=SHR //SYSIN DD * CONVERTV - TEST - DDNAME(INVOL1) - SMS /* Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam's signatory rights, no offer, agreement, concession or representation is binding on the company, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the company's seal. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html The volume is not defined to an SMS storage group This is understandable because the volume has not been added in the SG. I was just running to test to flush out any other errors. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CONVERTING DASD TO SMS
Bob, The volume was not added because I was running a test and I didn't realise that the volume needs to be added before I run the TEST option. From: Richards, Robert B. robert.richa...@opm.gov To: IBM-MAIN@bama.ua.edu Sent: Thursday, 22 September 2011 8:54 AM Subject: Re: CONVERTING DASD TO SMS Have you added the volume to an appropriate storage group already? Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Dawes Sent: Thursday, September 22, 2011 8:52 AM To: IBM-MAIN@bama.ua.edu Subject: Re: CONVERTING DASD TO SMS I tried the TEST keyword but I received the following error messages: ADR874E (001)-KVOL (01), VOLUME VECA21 IS NOT ELIGIBLE FOR CONVERSION TO SMS MANAGEMENT, 008 According to the error message it says :The volume has a nonindexed VTOC I ran the following : /* //STEP1 EXEC PGM=ICKDSF,REGION=3M //MYVOL DD UNIT=3390,DISP=(OLD,KEEP),VOL=SER=VECA21, // DSN=SYS1.VTOCIX.VECA21 //SYSPRINT DD SYSOUT=* //SYSIN DD * BUILDIX DDNAME(MYVOL) IXVTOC /* I ran the CONVERT again but I still get the same error. Any suggestions that I can try? From: Richards, Robert B. robert.richa...@opm.gov To: IBM-MAIN@bama.ua.edu Sent: Thursday, 22 September 2011 8:04 AM Subject: Re: CONVERTING DASD TO SMS The key there is the TEST keyword. That will simulate the CONVERTV process and let you know if any problems will be encountered. Review its output, resolve any issues, rerun with TEST again and when you get a clean run, remove the TEST keyword. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Dawes Sent: Thursday, September 22, 2011 7:47 AM To: IBM-MAIN@bama.ua.edu Subject: CONVERTING DASD TO SMS G'Day All, I have the unenviable task of converting some IMS dasd to SMS. The volumes are presently non-SMS and contain IMS DBs. I looked at the ADRDSSU and the COVERTV parm is recommended to be used. My question is has anybody encountered any problems using CONVERTV? I plan to use this jcl to run the CONVERT of the volume: //STEP1 EXEC PGM=ADRDSSU,REGION=4M //SYSPRINT DD SYSOUT=* //INVOL1 DD VOL=SER=BELAN1,UNIT=3390,DISP=SHR //SYSIN DD * CONVERTV - TEST - DDNAME(INVOL1) - SMS /* Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CONVERTING DASD TO SMS
--snip--- I tried the TEST keyword but I received the following error messages: ADR874E (001)-KVOL (01), VOLUME VECA21 IS NOT ELIGIBLE FOR CONVERSION TO SMS MANAGEMENT, 008 According to the error message it says :The volume has a nonindexed VTOC I ran the following : /* //STEP1 EXEC PGM=ICKDSF,REGION=3M //MYVOL DD UNIT=3390,DISP=(OLD,KEEP),VOL=SER=VECA21, // DSN=SYS1.VTOCIX.VECA21 //SYSPRINT DD SYSOUT=* //SYSIN DD * BUILDIX DDNAME(MYVOL) IXVTOC /* I ran the CONVERT again but I still get the same error. Any suggestions that I can try? -unsnip- Try spelling the index name right. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CONVERTING DASD TO SMS
Try spelling the index name right. It appears he did. The issue seems to be that even for TEST, the volume has to be in a storage group. - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CONVERTING DASD TO SMS
Even if you add the VOLSER to the storage group, it will not use the volume until you run the Convert for real. On Thu, Sep 22, 2011 at 1:56 PM, Ted MacNEIL eamacn...@yahoo.ca wrote: Try spelling the index name right. It appears he did. The issue seems to be that even for TEST, the volume has to be in a storage group. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CONVERTING DASD TO SMS
Yes. But at least you get past the error message re: ineligible. - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: Mike Schwab mike.a.sch...@gmail.com Sender: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Date: Thu, 22 Sep 2011 14:02:40 To: IBM-MAIN@bama.ua.edu Reply-To: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Subject: Re: CONVERTING DASD TO SMS Even if you add the VOLSER to the storage group, it will not use the volume until you run the Convert for real. On Thu, Sep 22, 2011 at 1:56 PM, Ted MacNEIL eamacn...@yahoo.ca wrote: Try spelling the index name right. It appears he did. The issue seems to be that even for TEST, the volume has to be in a storage group. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS compressed VSAM datasets
Something is wrong with Ed's email that causes single quote (or apostrophes) to show as #39, -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mingee, David Sent: Tuesday, September 13, 2011 7:51 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS compressed VSAM datasets Ed, Not that I know of. BTW, what is #39,t mean? I see it frequently, is it encrypted cursing? hahaha David L. Mingee Principal Systems Administrator Indianapolis Production Control Data Center Operations / Operations Technical Support Work Ext 782-6460 Work Direct Dial 317 581-6460 Home 317 598-0919 / Cell 317 341-0885 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ed Gould Sent: Tuesday, September 13, 2011 10:47 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS compressed VSAM datasets David, Correct me if I am wrong but doesn#39;t DFDSS invoke idcams under the covers? Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS compressed VSAM datasets
I guess my first thought / question would be to identify where the bottleneck for the backups is; disk I/O, tape I/O, or CPU? Presumably disk I/O didn't change a whole lot for reading the data or you would have seen impacts elsewhere too. My guess would be similar for the CPU. However, if either is true, it's possible it's simply more noticable during backups than your normal processing. But my guess would be it's writing to the tape. You didn't mention what kind of tape subsystem you're writing to, but everything has it's throughput limit and possibly by pushing more data (uncompressed) down the channel, you've hit the throughput limit of the subsystem. If you're going down ESCON channels to the tape, those aren't terribly fast by modern standards, and more data on the channel = slower elapsed time. I discovered a similar situation for our DB2 log archives earlier this year, but the interesting part was that I didn't initially recognize we were hitting the throughput limit because the data is compressed in the logs and the quoted throughput limits seem to assume you're sending uncompressed data to the subsystem. Of course you now are sending uncompressed data to the subsystem, but likely the tape subsystem compression ratio is different than what you get on disk from either SMS or BMC. As I was looking at this I also discovered that for my test jobs there was no significant difference between using 24K and 256K blocks. YMMV. If you're so interested, I wrote up that experience for one of my What I Learned This Month columns for MeasureIT: http://www.cmg.org/measureit/issues/mit80/m_80_5.pdf Scott Chapman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS compressed VSAM datasets
1) I would increase bufnum before bufsize 2) Compress the output... HTH, snip This is a weird question, but I've been directed to ask it. We are converting some VSAM datasets which currently use BMC's Data Accelerator compression to use SMS compression instead. This is a financial decision. We use CA-Faver to do our VSAM backups. Faver states in its manual that it will unload the VSAM data to its archive in uncompressed form. I guess this is because Faver knows it is SMS compressed. When the data was compressed via Data Accelerator, Faver was unaware that it was compressed, and so did not interface with Data Accelerator to uncompress the data. This meant that the data on the tape was in a very compressed form. Which is not true with SMS compression. The result of this difference is that our backups are taking much longer. Which was a surprise to all and is causing concern. So my question out there is any ideas on what I can do to make run faster? So far, the only suggestion from CA is to increase the BUFSIZE on the dump. But I don't think this is going to reduce the run time significantly. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS compressed VSAM datasets
Thanks. Yes, I see those entries. Messing around with the CISIZE is a bit iffy because I am not the primary responsibly person for these files. I cannot change them without permission. But I'm tasking with converting the in sitsu because programming just doesn't have the time necessary to be bothered with it. The reason for conversion is financial, not technical. And chaning from Faver to ADRDSSU is no go because that is a change which would require going through change control for each and every file. And require rearchitecting some jobs. We use Faver for a lot of functions, including making shadow copies of files. Data Accelerator is a great product. But we, like many, are struggling to stay alive. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mingee, David Sent: Tuesday, September 13, 2011 9:33 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS compressed VSAM datasets Hi John, Do the VSAM files show COMP-FORMT and USER-DATA-SIZE--9636537000 COMP-USER-DATA-SIZE-2831001090 in the listcat(s)? This verifies the SMS compression is on. Also, you could try SMS utility ADRDSSU for backup speed. Lastly, if SMS compress is on, I suggest defining the vsam cisize as 26624 as this is the most efficient for i/o and disk space and I have never seen this have a negative impact on CICS. David L. Mingee Principal Systems Administrator Indianapolis Production Control Data Center Operations / Operations Technical Support Work Ext 782-6460 Work Direct Dial 317 581-6460 Home 317 598-0919 / Cell 317 341-0885 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS compressed VSAM datasets
Given that the most obvious difference is that what used to take 3 output tapes is now going to 12 output tapes, the slow down is due to the number of bytes being written to tape. The bytes read from disk seem be about the same because the number of cylinders taken by the VSAM dataset is the same. The problem is that Faver is expanding the compressed bytes in the SMS case but not in the Data Accelerator case. We are talking to CA about why Faver expands the compressed bytes when the dataset is SMS compressed instead of just sucking it up using something like a read track CCW which I think would bypass the SMS decompression. BTW - Faver is working exactly as it is documented to work in the Faver manual. We just don't like it. shrug -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Staller, Allan Sent: Wednesday, September 14, 2011 7:50 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS compressed VSAM datasets 1) I would increase bufnum before bufsize 2) Compress the output... HTH, snip This is a weird question, but I've been directed to ask it. We are converting some VSAM datasets which currently use BMC's Data Accelerator compression to use SMS compression instead. This is a financial decision. We use CA-Faver to do our VSAM backups. Faver states in its manual that it will unload the VSAM data to its archive in uncompressed form. I guess this is because Faver knows it is SMS compressed. When the data was compressed via Data Accelerator, Faver was unaware that it was compressed, and so did not interface with Data Accelerator to uncompress the data. This meant that the data on the tape was in a very compressed form. Which is not true with SMS compression. The result of this difference is that our backups are taking much longer. Which was a surprise to all and is causing concern. So my question out there is any ideas on what I can do to make run faster? So far, the only suggestion from CA is to increase the BUFSIZE on the dump. But I don't think this is going to reduce the run time significantly. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS compressed VSAM datasets
From 3 output tapes to 12? What kind of tape drives are you using? Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Wednesday, September 14, 2011 8:18 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS compressed VSAM datasets Given that the most obvious difference is that what used to take 3 output tapes is now going to 12 output tapes, the slow down is due to the number of bytes being written to tape. The bytes read from disk seem be about the same because the number of cylinders taken by the VSAM dataset is the same. The problem is that Faver is expanding the compressed bytes in the SMS case but not in the Data Accelerator case. We are talking to CA about why Faver expands the compressed bytes when the dataset is SMS compressed instead of just sucking it up using something like a read track CCW which I think would bypass the SMS decompression. BTW - Faver is working exactly as it is documented to work in the Faver manual. We just don't like it. shrug -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Staller, Allan Sent: Wednesday, September 14, 2011 7:50 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS compressed VSAM datasets 1) I would increase bufnum before bufsize 2) Compress the output... HTH, snip This is a weird question, but I've been directed to ask it. We are converting some VSAM datasets which currently use BMC's Data Accelerator compression to use SMS compression instead. This is a financial decision. We use CA-Faver to do our VSAM backups. Faver states in its manual that it will unload the VSAM data to its archive in uncompressed form. I guess this is because Faver knows it is SMS compressed. When the data was compressed via Data Accelerator, Faver was unaware that it was compressed, and so did not interface with Data Accelerator to uncompress the data. This meant that the data on the tape was in a very compressed form. Which is not true with SMS compression. The result of this difference is that our backups are taking much longer. Which was a surprise to all and is causing concern. So my question out there is any ideas on what I can do to make run faster? So far, the only suggestion from CA is to increase the BUFSIZE on the dump. But I don't think this is going to reduce the run time significantly. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html The information contained in this e-mail may contain confidential and/or privileged information and is intended for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any unauthorized use, disclosure, distribution or copying of this communication is strictly prohibited and that you will be held responsible for any such unauthorized activity, including liability for any resulting damages. As appropriate, such incident(s) may also be reported to law enforcement. If you received this e-mail in error, please reply to sender and destroy or delete the message and any attachments. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
