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
