Re: Performance for DFDSS with ORACLE Tape Drives VSM5 ( was Change tape block size)
Hello, I've noticed a strange dss behavior and want ask explanation: After I finished dss backup, I always received a message similar to this: 15.29.56 JOB31114 IEC205I ODD,BKDS,BACKUP,FILESEQ=1, COMPLETE VOLUME LIST, 870 870 DSN=BKUP.D003,VOLS=PT0541,TOTALBLOCKS=12122 Is the block counts reported the real tape blocks written to tape or something else? I've noticed that for BASIC PS and extended format PS, it is different,below is my testing: st_TIME end_TIMEbackup source data type VOLSER VTV size(mb)VTV size(comp)(mb) tape block size(KB) Total block count reported by DSS 11:31:4111:33:12Extended format compressed PT3968 1854.15 647.77 128 33879 11:33:1211:34:42Extended format compressed PT3974 1854.15 647.77 64 33879 11:34:4211:36:17Extended format compressed PT3976 1854.15 647.77 256 33879 12:22:5012:31:20Extended format PT4034 6280.18 371.56 128 223678 12:31:2012:39:35Extended format PT4043 6280.18 371.56 64 223678 12:39:3512:47:58Extended format PT4053 6280.18 371.56 256 223678 12:55:0912:58:34Basic PS,compressed PT4065 6273.86 360.15 128 49115 12:58:3413:03:06Basic PS,compressed PT4067 6274.57 367.9 64 98428 13:03:0613:05:59Basic PS,compressed PT4072 6273.51 355.32 256 24527 13:08:0713:11:37Basic PSPT4075 6273.86 360.15 128 49117 13:11:3713:16:00Basic PSPT4078 6274.57 367.9 64 98426 13:16:0013:19:04Basic PSPT4082 6273.51 355.52 256 24528 That is: For basic PS backup,I can change block size using BLKSIZE in JCL and the resulting block count reported by rmm and dss will match, the result is: Bigger block size, less block count,backup speed is much quicker But for extended PS backup,no matter what specified in JCL,the block count reported by dss will be same, and it does not match with what's recorded by rmm, and speed are same for whatever block size. Could you explain? regards Victor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Performance for DFDSS with ORACLE Tape Drives VSM5 ( was Change tape block size)
Victor, IEC205I gets the TOTALBLOCKS from system control blocks. It should match what rmm records (gets it from same place.. Actually it depends on access method and whether that method maintains the block count fields. EXCP does not and the application must maintain it. The block count is application block count sent to the device. what is on the tape depends on the tape device Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Performance for DFDSS with ORACLE Tape Drives VSM5 ( was Change tape block size)
Prior to 3480's with IDRC the physical block size on tape corresponded to the block size sent across the channel by MVS and the maximum tape data transfer rate was invariably bounded by the physical tape drive speed and the relation mean-data-rate B/sec = percent-of-tape-used-for-data x drive-transport-speed in/sec x density B/in, and the shorter the physical blocks, the greater the number of Inter-Record-Gaps IRGs) resulting in lower effective tape utilization and lower effective transfer rate. Prior to 6250 bpi recording technology, tape media and drive reading reliability generally dictated physical block sizes considerably less than 32KiB. My recollection is that the 6250bpi drives were the first to be consistently reliable enough to make using a block size of ~32KiB reasonable from a tape performance viewpoint (other resources could still be constraining factors). At that block size, effective tape media utilization at 6250bpi was still only about 94%, but MVS block size limits prevented going larger. The greater 38KiB density and greater reliability of 3480's increased the significance of tape lost to IRGs again, but the introduction of hardware compression on 3480's and its successors took the physical tape utilization issue out of the hands of MVS and programmers by forcing data into 256KiB physical super-blocks on the tape hardware level regardless of MVS's concept of block size. Use of larger block sizes today on MVS reduces the system and application overhead by managing fewer I/O buffers and initiating fewer channel programs to transfer the same amount of data, but it does not affect physical tape utilization andI would not expect the effect to be as dramatic as in the old days when a really bad MVS physical block size could easily elongate program run time and physical tape usage by a factor of 10 or more when over 90% of the physical tape was consumed by IRGs (and this fact was periodically rediscovered by some application programmer). The DFDSS manuals may not emphasize the default 256KiB MVS tape block size because that support is over a decade old and the only thing that should be reading a DFDSS tape is a compatible version of DFDSS. I would at least hope that none of the DFDSS JCL examples imply that BLKSIZE is recommended or a wise idea for tape output DDs. I still remember seeing the HOLD data on the PTF that added 256KiB block support to DFDSS -- It was critical to know that once that support was added, that the DFDSS used at a DR site or on a recovery system or on your stand-alone IPL tapes had to also be at the new level in order to restore from the generated backup tapes. Joel C. Ewing On 05/13/2014 11:04 PM, Ed Gould wrote: Skip: Our IBM SE (30+ years ago) wrote an orange manual (how many remember those?), About blocksize and tape. It pretty much said that use of a 32K blocksize as optimum for channel and tape utilization (this was 6250 BPI IIRC). Jim (our SE has retired) after serving time at the WSC and out in San Jose. But through the years the best thruput as to always code 32K for job where performance is needed. Of course with new technology I expect that the device that can handle 256K blocksize be used. I have often disliked the DFDSS manuals for not being straight forward in their documentation. I don't think DFSMS does the right thing with blksize=0 for tape, my memory is obsolete here but it used to be 16K when blocksize eq zero is used. Ed On May 13, 2014, at 6:25 PM, Skip Robinson wrote: We had some issues a while back with VSM performance. I did research and experiments with various block sizes for tape data sets. Questions on IBM-MAIN and doc reading yielded some answers--though not necessarily solutions. -- Tape output is generally faster with larger block sizes. That's easydemonstrate by coding ever larger block sizes. EXCP count and elapsed time will both decrease. -- You can't just increase output block size willy-nilly. A program thatuses a traditional DCB is limited to 32K bytes per block. To exceed that value, a program must employ DCBE, which is not hard to use but requires coding changes. -- If you attempt to code 32K block size in JCL for a program with DCB,the value will be ignored and revert to 32K. You might miss that fact because there's no message. Your tape management product (CA-1, RMM, etc.) will show you the actual block size of a file. -- Some IBM utilities are coded with DCBE to enable 32K block size.Others are not. Doc for each utility should indicate the maximum allowable output block size. -- DFSMSdss Storage Administration has this to say: If the DCB keyword BLKSIZE is specified on the DD statement for tape, it must be in the range of 7,892 through 262,144. If the DCB keyword BLKSIZE is specified on the DD statement for DASD, it must be in the range of 7,892 through 32,760. So DFDSS uses DCBE and can write 256K blocks. In my testing, a job ran quite a bit faster
Re: Performance for DFDSS with ORACLE Tape Drives VSM5 ( was Change tape block size)
On May 14, 2014, at 5:31 PM, Joel C. Ewing wrote: Prior to 3480's with IDRC the physical block size on tape corresponded to the block size sent across the channel by MVS and the maximum tape data transfer rate was invariably bounded by the physical tape drive speed and the relation mean-data-rate B/sec = percent-of-tape-used-for-data x drive-transport-speed in/sec x density B/in, and the shorter the physical blocks, the greater the number of Inter-Record-Gaps IRGs) resulting in lower effective tape utilization and lower effective transfer rate. Prior to 6250 bpi recording technology, tape media and drive reading reliability generally dictated physical block sizes considerably less than 32KiB. My recollection is that the 6250bpi drives were the first to be consistently reliable enough to make using a block size of ~32KiB reasonable from a tape performance viewpoint (other resources could still be constraining factors). At that block size, effective tape media utilization at 6250bpi was still only about 94%, but MVS block size limits prevented going larger. The greater 38KiB density and greater reliability of 3480's increased the significance of tape lost to IRGs again, but the introduction of hardware compression on 3480's and its successors took the physical tape utilization issue out of the hands of MVS and programmers by forcing data into 256KiB physical super-blocks on the tape hardware level regardless of MVS's concept of block size. Use of larger block sizes today on MVS reduces the system and application overhead by managing fewer I/O buffers and initiating fewer channel programs to transfer the same amount of data, but it does not affect physical tape utilization andI would not expect the effect to be as dramatic as in the old days when a really bad MVS physical block size could easily elongate program run time and physical tape usage by a factor of 10 or more when over 90% of the physical tape was consumed by IRGs (and this fact was periodically rediscovered by some application programmer). The DFDSS manuals may not emphasize the default 256KiB MVS tape block size because that support is over a decade old and the only thing that should be reading a DFDSS tape is a compatible version of DFDSS. I would at least hope that none of the DFDSS JCL examples imply that BLKSIZE is recommended or a wise idea for tape output DDs. I still remember seeing the HOLD data on the PTF that added 256KiB block support to DFDSS -- It was critical to know that once that support was added, that the DFDSS used at a DR site or on a recovery system or on your stand-alone IPL tapes had to also be at the new level in order to restore from the generated backup tapes. Joel C. Ewing Joel: But this was how long ago? The DFDSS doc should have been update by now. no? Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Performance for DFDSS with ORACLE Tape Drives VSM5 ( was Change tape block size)
On 05/14/2014 07:03 PM, Ed Gould wrote: On May 14, 2014, at 5:31 PM, Joel C. Ewing wrote: Prior to 3480's with IDRC the physical block size on tape corresponded to the block size sent across the channel by MVS and the maximum tape data transfer rate was invariably bounded by the physical tape drive speed and the relation mean-data-rate B/sec = percent-of-tape-used-for-data x drive-transport-speed in/sec x density B/in, and the shorter the physical blocks, the greater the number of Inter-Record-Gaps IRGs) resulting in lower effective tape utilization and lower effective transfer rate. Prior to 6250 bpi recording technology, tape media and drive reading reliability generally dictated physical block sizes considerably less than 32KiB. My recollection is that the 6250bpi drives were the first to be consistently reliable enough to make using a block size of ~32KiB reasonable from a tape performance viewpoint (other resources could still be constraining factors). At that block size, effective tape media utilization at 6250bpi was still only about 94%, but MVS block size limits prevented going larger. The greater 38KiB density and greater reliability of 3480's increased the significance of tape lost to IRGs again, but the introduction of hardware compression on 3480's and its successors took the physical tape utilization issue out of the hands of MVS and programmers by forcing data into 256KiB physical super-blocks on the tape hardware level regardless of MVS's concept of block size. Use of larger block sizes today on MVS reduces the system and application overhead by managing fewer I/O buffers and initiating fewer channel programs to transfer the same amount of data, but it does not affect physical tape utilization andI would not expect the effect to be as dramatic as in the old days when a really bad MVS physical block size could easily elongate program run time and physical tape usage by a factor of 10 or more when over 90% of the physical tape was consumed by IRGs (and this fact was periodically rediscovered by some application programmer). The DFDSS manuals may not emphasize the default 256KiB MVS tape block size because that support is over a decade old and the only thing that should be reading a DFDSS tape is a compatible version of DFDSS. I would at least hope that none of the DFDSS JCL examples imply that BLKSIZE is recommended or a wise idea for tape output DDs. I still remember seeing the HOLD data on the PTF that added 256KiB block support to DFDSS -- It was critical to know that once that support was added, that the DFDSS used at a DR site or on a recovery system or on your stand-alone IPL tapes had to also be at the new level in order to restore from the generated backup tapes. Joel C. Ewing Joel: But this was how long ago? The DFDSS doc should have been update by now. no? Ed Well granted it is hard to find and much more complicated than I remembered, but this feature was incorporated into z/OS 1.12 and DFSMSdss Storage Administration manual for z/OS 1.12 does have under Chapter 1 Introduction..., Dumping data efficiently, Space Considerations the following paragraph relating to DUMP output: The default block size for output records that are written to tape is the optimum block size for the output device (262 144 is the maximum). You can change this default to 32 760 by using the installation options exit routine. See the discussion of system-determined block size in z/OS DFSMS Using Data Sets for a description of the optimum block sizes of the supported tape devices. The DFDSS manual doesn't explicitly say what the default value is because it is dependent on the specific tape device type (or installation exits) and apparently the optimum tape device block size is part of z/OS Large Block Interface support and not part of DFDSS (which makes sense when you think about it). Since DFDSS does not control what the actual values are, you have to go to a non-DFDSS manual to find a table of the actual optimum values (z/OS DFSMS Using Data Sets, Chapter 21 Specifying and Initializing Data Control Blocks, Selecting Data Set Options, Block Size). This is not a tidbit of information that the average user needs to know to use DFDSS successfully, so perhaps it is OK that it takes some digging to locate. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Performance for DFDSS with ORACLE Tape Drives VSM5 ( was Change tape block size)
Victor, If I understand problem at the root of your questions, you are trying to speed up DFSMSdss logical dumps, especially for compressed PS-E data sets. From your questions you are focusing on the tape output rate as the gating factor for the elapsed time of the dump, but have you looked at the time spent processing the input files? I may be having a senior moment, but there are two things that may be affecting the performance of the PS-E data set. (1) I seem to recall that DFSMSdss will process a compressed PS-E data set at block level and not attempt to compress it in order to avoid double compression overhead when COMPRESS is specified, and (2) compressed PS-E data sets do not chain more than one track of at a time. I'll leave it to you to hit the manuals and see if I recall correctly. Considered together this means the input file may well be the choke on the backup performance. It may pay to start some RMF monitor II background sessions at 5 second intervals for the input volumes and output tape addresses and have a look at the make-up of response time on both. Omegamon or similar may also provide a delay analysis that shows where the job is spending its time. An extreme consideration would be to ask if you are using FX8S channels and zHPF? Channel microprocessor usage with Extended format IO was one of the many benefits of zHPF and channel throughput from DASD may be part of your problem. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, May 12, 2014 7:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Performance for DFDSS with ORACLE Tape Drives VSM5 ( was Change tape block size) Victor, The blksize is not the only way to tune a process for efficiency. And in some cases, there is little you can do to affect some applications like DFDSS. If you are using the hardware for tape is virtual tape of oracle, vsm5. Then there may be nothing more you can do. Sometimes the hardware controls the process. I would open an issue with STK and ask them to assist you with this configuration. There may be a parm or function unique to STK that may help you. I might also open an SR/ETR with IBM DFDSS to see if they have any suggestions. Lizette PS I changed the subject to for more visibility -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of Victor Zhang Sent: Sunday, May 11, 2014 11:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Change tape block size Hello, First I need thank you who replied to my question. I should introduce my problem's background and my concern. The tape is virutal tape of oralce, vsm5. I am backing up extended format PS dataset to VSM5 using ADRDSSU. I tested using dss to backup, no matter what block size I specified in JCL, ADRDSSU will report same number of blocks in message IEC205I. And the backup speed will also be same no matter what block size I specified in JCL. Here is my testing result: st_TIME end_TIMEbackup source data type VOLSER VTV size(mb)VTV size(comp)(mb) tape block size(KB) Total block count reported by DSS backup speed(MB/S) 11:31:4111:33:12Extended format compressed AB3968 1854.15 647.77 128 33879 20.38 11:33:1211:34:42Extended format compressed AB3974 1854.15 647.77 64 33879 20.60 11:34:4211:36:17Extended format compressed AB3976 1854.15 647.77 256 33879 19.52 But this is not true for BASIC PS dataset, for basic PS dataset, I did a similar testing: st_TIME end_TIMEbackup source data type VOLSER VTV size(mb)VTV size(comp)(mb) tape block size(KB) Total block count reported by DSS backup speed(MB/S) 13:08:0713:11:37Basic PSAB4075 6273.86 360.15 128 49117 29.88 13:11:3713:16:00Basic PSAB4078 6274.57 367.9 64 98426 23.86 13:16:0013:19:04Basic PSAB4082 6273.51 355.52 256 24528 34.10 Please note the total block count reported by DSS is different when specifying different tape block size. My goal was: To improve backup performance for extended format PS dataset(DB2 image copy on dasd)using ADRDSSU,I am trying to use 256KB to improve performace,but I can't. Do you have any ideas? Regards Victor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO
Re: Performance for DFDSS with ORACLE Tape Drives VSM5 ( was Change tape block size)
We had some issues a while back with VSM performance. I did research and experiments with various block sizes for tape data sets. Questions on IBM-MAIN and doc reading yielded some answers--though not necessarily solutions. -- Tape output is generally faster with larger block sizes. That's easy demonstrate by coding ever larger block sizes. EXCP count and elapsed time will both decrease. -- You can't just increase output block size willy-nilly. A program that uses a traditional DCB is limited to 32K bytes per block. To exceed that value, a program must employ DCBE, which is not hard to use but requires coding changes. -- If you attempt to code 32K block size in JCL for a program with DCB, the value will be ignored and revert to 32K. You might miss that fact because there's no message. Your tape management product (CA-1, RMM, etc.) will show you the actual block size of a file. -- Some IBM utilities are coded with DCBE to enable 32K block size. Others are not. Doc for each utility should indicate the maximum allowable output block size. -- DFSMSdss Storage Administration has this to say: If the DCB keyword BLKSIZE is specified on the DD statement for tape, it must be in the range of 7,892 through 262,144. If the DCB keyword BLKSIZE is specified on the DD statement for DASD, it must be in the range of 7,892 through 32,760. So DFDSS uses DCBE and can write 256K blocks. In my testing, a job ran quite a bit faster with the maximum block size than with a smaller one. (I did not test DFDSS per se.) But as already indicated, the inhibitor to stellar performance may be on the input side, over which you have little control. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Ron Hawkins ronjhawk...@sbcglobal.net To: IBM-MAIN@LISTSERV.UA.EDU, Date: 05/13/2014 09:15 AM Subject:Re: Performance for DFDSS with ORACLE Tape Drives VSM5 ( was Change tape block size) Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Victor, If I understand problem at the root of your questions, you are trying to speed up DFSMSdss logical dumps, especially for compressed PS-E data sets. From your questions you are focusing on the tape output rate as the gating factor for the elapsed time of the dump, but have you looked at the time spent processing the input files? I may be having a senior moment, but there are two things that may be affecting the performance of the PS-E data set. (1) I seem to recall that DFSMSdss will process a compressed PS-E data set at block level and not attempt to compress it in order to avoid double compression overhead when COMPRESS is specified, and (2) compressed PS-E data sets do not chain more than one track of at a time. I'll leave it to you to hit the manuals and see if I recall correctly. Considered together this means the input file may well be the choke on the backup performance. It may pay to start some RMF monitor II background sessions at 5 second intervals for the input volumes and output tape addresses and have a look at the make-up of response time on both. Omegamon or similar may also provide a delay analysis that shows where the job is spending its time. An extreme consideration would be to ask if you are using FX8S channels and zHPF? Channel microprocessor usage with Extended format IO was one of the many benefits of zHPF and channel throughput from DASD may be part of your problem. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, May 12, 2014 7:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Performance for DFDSS with ORACLE Tape Drives VSM5 ( was Change tape block size) Victor, The blksize is not the only way to tune a process for efficiency. And in some cases, there is little you can do to affect some applications like DFDSS. If you are using the hardware for tape is virtual tape of oracle, vsm5. Then there may be nothing more you can do. Sometimes the hardware controls the process. I would open an issue with STK and ask them to assist you with this configuration. There may be a parm or function unique to STK that may help you. I might also open an SR/ETR with IBM DFDSS to see if they have any suggestions. Lizette PS I changed the subject to for more visibility -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of Victor Zhang Sent: Sunday, May 11, 2014 11:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Change tape block size Hello, First I need thank you who replied to my question. I should introduce my problem's background and my concern. The tape is virutal tape of oralce, vsm5. I am backing up extended format PS dataset to VSM5
Re: Performance for DFDSS with ORACLE Tape Drives VSM5 ( was Change tape block size)
Skip: Our IBM SE (30+ years ago) wrote an orange manual (how many remember those?), About blocksize and tape. It pretty much said that use of a 32K blocksize as optimum for channel and tape utilization (this was 6250 BPI IIRC). Jim (our SE has retired) after serving time at the WSC and out in San Jose. But through the years the best thruput as to always code 32K for job where performance is needed. Of course with new technology I expect that the device that can handle 256K blocksize be used. I have often disliked the DFDSS manuals for not being straight forward in their documentation. I don't think DFSMS does the right thing with blksize=0 for tape, my memory is obsolete here but it used to be 16K when blocksize eq zero is used. Ed On May 13, 2014, at 6:25 PM, Skip Robinson wrote: We had some issues a while back with VSM performance. I did research and experiments with various block sizes for tape data sets. Questions on IBM-MAIN and doc reading yielded some answers--though not necessarily solutions. -- Tape output is generally faster with larger block sizes. That's easy demonstrate by coding ever larger block sizes. EXCP count and elapsed time will both decrease. -- You can't just increase output block size willy-nilly. A program that uses a traditional DCB is limited to 32K bytes per block. To exceed that value, a program must employ DCBE, which is not hard to use but requires coding changes. -- If you attempt to code 32K block size in JCL for a program with DCB, the value will be ignored and revert to 32K. You might miss that fact because there's no message. Your tape management product (CA-1, RMM, etc.) will show you the actual block size of a file. -- Some IBM utilities are coded with DCBE to enable 32K block size. Others are not. Doc for each utility should indicate the maximum allowable output block size. -- DFSMSdss Storage Administration has this to say: If the DCB keyword BLKSIZE is specified on the DD statement for tape, it must be in the range of 7,892 through 262,144. If the DCB keyword BLKSIZE is specified on the DD statement for DASD, it must be in the range of 7,892 through 32,760. So DFDSS uses DCBE and can write 256K blocks. In my testing, a job ran quite a bit faster with the maximum block size than with a smaller one. (I did not test DFDSS per se.) But as already indicated, the inhibitor to stellar performance may be on the input side, over which you have little control. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Ron Hawkins ronjhawk...@sbcglobal.net To: IBM-MAIN@LISTSERV.UA.EDU, Date: 05/13/2014 09:15 AM Subject:Re: Performance for DFDSS with ORACLE Tape Drives VSM5 ( was Change tape block size) Sent by:IBM Mainframe Discussion List IBM- m...@listserv.ua.edu Victor, If I understand problem at the root of your questions, you are trying to speed up DFSMSdss logical dumps, especially for compressed PS-E data sets. From your questions you are focusing on the tape output rate as the gating factor for the elapsed time of the dump, but have you looked at the time spent processing the input files? I may be having a senior moment, but there are two things that may be affecting the performance of the PS-E data set. (1) I seem to recall that DFSMSdss will process a compressed PS-E data set at block level and not attempt to compress it in order to avoid double compression overhead when COMPRESS is specified, and (2) compressed PS-E data sets do not chain more than one track of at a time. I'll leave it to you to hit the manuals and see if I recall correctly. Considered together this means the input file may well be the choke on the backup performance. It may pay to start some RMF monitor II background sessions at 5 second intervals for the input volumes and output tape addresses and have a look at the make-up of response time on both. Omegamon or similar may also provide a delay analysis that shows where the job is spending its time. An extreme consideration would be to ask if you are using FX8S channels and zHPF? Channel microprocessor usage with Extended format IO was one of the many benefits of zHPF and channel throughput from DASD may be part of your problem. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, May 12, 2014 7:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Performance for DFDSS with ORACLE Tape Drives VSM5 ( was Change tape block size) Victor, The blksize is not the only way to tune a process for efficiency. And in some cases, there is little you can do to affect some applications like DFDSS. If you are using the hardware for tape is virtual tape of oracle, vsm5. Then there may be
Re: Performance for DFDSS with ORACLE Tape Drives VSM5 ( was Change tape block size)
Victor, The blksize is not the only way to tune a process for efficiency. And in some cases, there is little you can do to affect some applications like DFDSS. If you are using the hardware for tape is virtual tape of oracle, vsm5. Then there may be nothing more you can do. Sometimes the hardware controls the process. I would open an issue with STK and ask them to assist you with this configuration. There may be a parm or function unique to STK that may help you. I might also open an SR/ETR with IBM DFDSS to see if they have any suggestions. Lizette PS I changed the subject to for more visibility -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Victor Zhang Sent: Sunday, May 11, 2014 11:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Change tape block size Hello, First I need thank you who replied to my question. I should introduce my problem's background and my concern. The tape is virutal tape of oralce, vsm5. I am backing up extended format PS dataset to VSM5 using ADRDSSU. I tested using dss to backup, no matter what block size I specified in JCL, ADRDSSU will report same number of blocks in message IEC205I. And the backup speed will also be same no matter what block size I specified in JCL. Here is my testing result: st_TIME end_TIMEbackup source data type VOLSER VTV size(mb) VTV size(comp)(mb) tape block size(KB) Total block count reported by DSS backup speed(MB/S) 11:31:41 11:33:12Extended format compressed AB3968 1854.15 647.77 128 33879 20.38 11:33:12 11:34:42Extended format compressed AB3974 1854.15 647.77 64 33879 20.60 11:34:42 11:36:17Extended format compressed AB3976 1854.15 647.77 256 33879 19.52 But this is not true for BASIC PS dataset, for basic PS dataset, I did a similar testing: st_TIME end_TIMEbackup source data type VOLSER VTV size(mb) VTV size(comp)(mb) tape block size(KB) Total block count reported by DSS backup speed(MB/S) 13:08:07 13:11:37Basic PSAB4075 6273.86 360.15 128 49117 29.88 13:11:37 13:16:00Basic PSAB4078 6274.57 367.9 64 98426 23.86 13:16:00 13:19:04Basic PSAB4082 6273.51 355.52 256 24528 34.10 Please note the total block count reported by DSS is different when specifying different tape block size. My goal was: To improve backup performance for extended format PS dataset(DB2 image copy on dasd)using ADRDSSU,I am trying to use 256KB to improve performace,but I can't. Do you have any ideas? Regards Victor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Performance for DFDSS with ORACLE Tape Drives VSM5 ( was Change tape block size)
It is my recollection that, pretty much since the advent of buffered tape drives (e.g. 3590, 9840,... ) the actual blocksize written to tape is independent of what is specified in the JCL. In other words, it does not matter what you code in JCL, the actual data block written to physical tape will be a hardware determined value. I believe Lizette's suggestion of using TAPETOOL is a good one, My $0.02 USD worth, snip First I need thank you who replied to my question. I should introduce my problem's background and my concern. The tape is virutal tape of oralce, vsm5. I am backing up extended format PS dataset to VSM5 using ADRDSSU. I tested using dss to backup, no matter what block size I specified in JCL, ADRDSSU will report same number of blocks in message IEC205I. And the backup speed will also be same no matter what block size I specified in JCL. Here is my testing result: st_TIME end_TIMEbackup source data type VOLSER VTV size(mb) VTV size(comp)(mb) tape block size(KB) Total block count reported by DSS backup speed(MB/S) 11:31:41 11:33:12Extended format compressed AB3968 1854.15 647.77 128 33879 20.38 11:33:12 11:34:42Extended format compressed AB3974 1854.15 647.77 64 33879 20.60 11:34:42 11:36:17Extended format compressed AB3976 1854.15 647.77 256 33879 19.52 But this is not true for BASIC PS dataset, for basic PS dataset, I did a similar testing: st_TIME end_TIMEbackup source data type VOLSER VTV size(mb) VTV size(comp)(mb) tape block size(KB) Total block count reported by DSS backup speed(MB/S) 13:08:07 13:11:37Basic PSAB4075 6273.86 360.15 128 49117 29.88 13:11:37 13:16:00Basic PSAB4078 6274.57 367.9 64 98426 23.86 13:16:00 13:19:04Basic PSAB4082 6273.51 355.52 256 24528 34.10 /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Performance for DFDSS with ORACLE Tape Drives VSM5 ( was Change tape block size)
W dniu 2014-05-12 21:02, Staller, Allan pisze: It is my recollection that, pretty much since the advent of buffered tape drives (e.g. 3590, 9840,... ) the actual blocksize written to tape is independent of what is specified in the JCL. In other words, it does not matter what you code in JCL, the actual data block written to physical tape will be a hardware determined value. Well, I performed some tests on various real and virtual drives. Although the JCL DD BLKSIZE is not actual physical blocksize on the tape, but the BLKSIZE still does matter. What is also important, very important is compression ratio, but in real life it depends on your data, so there is no much to tune here. -- Radoslaw Skorupka Lodz, Poland --- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając 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 authorized 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. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Performance for DFDSS with ORACLE Tape Drives VSM5 ( was Change tape block size)
Agreed. Low compression ratios will produce more blocks to actually be written to the tape, elongating total application time. snip W dniu 2014-05-12 21:02, Staller, Allan pisze: It is my recollection that, pretty much since the advent of buffered tape drives (e.g. 3590, 9840,... ) the actual blocksize written to tape is independent of what is specified in the JCL. In other words, it does not matter what you code in JCL, the actual data block written to physical tape will be a hardware determined value. Well, I performed some tests on various real and virtual drives. Although the JCL DD BLKSIZE is not actual physical blocksize on the tape, but the BLKSIZE still does matter. What is also important, very important is compression ratio, but in real life it depends on your data, so there is no much to tune here. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Performance for DFDSS with ORACLE Tape Drives VSM5 ( was Change tape block size)
So what gets sent down the channel? If I put BLKSIZE=1024 on my JCL for the output DD statement of the DFDSS dump job, will DFDSS dutifully send 1K blocks down the channel to the tape controller/drive and the hardware builds big blocks and writes the large block to the tape, or does DFDSS know it's sending data to the buffered drive so it builds large blocks to send down the channel to the drive in anticipation of the drive wanting large blocks? Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Staller, Allan Sent: Monday, May 12, 2014 2:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Performance for DFDSS with ORACLE Tape Drives VSM5 ( was Change tape block size) Agreed. Low compression ratios will produce more blocks to actually be written to the tape, elongating total application time. snip W dniu 2014-05-12 21:02, Staller, Allan pisze: It is my recollection that, pretty much since the advent of buffered tape drives (e.g. 3590, 9840,... ) the actual blocksize written to tape is independent of what is specified in the JCL. In other words, it does not matter what you code in JCL, the actual data block written to physical tape will be a hardware determined value. Well, I performed some tests on various real and virtual drives. Although the JCL DD BLKSIZE is not actual physical blocksize on the tape, but the BLKSIZE still does matter. What is also important, very important is compression ratio, but in real life it depends on your data, so there is no much to tune here. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Performance for DFDSS with ORACLE Tape Drives VSM5 ( was Change tape block size)
W dniu 2014-05-12 21:16, Pommier, Rex pisze: So what gets sent down the channel? If I put BLKSIZE=1024 on my JCL for the output DD statement of the DFDSS dump job, will DFDSS dutifully send 1K blocks down the channel to the tape controller/drive and the hardware builds big blocks and writes the large block to the tape, or does DFDSS know it's sending data to the buffered drive so it builds large blocks to send down the channel to the drive in anticipation of the drive wanting large blocks? The channel actually sends Fiber Channel frames, however from the host point of view 1024 B blocks are transmitted. Reblocking occurs in the tape CU, after the compression. So, no big blocks are sent over the channel in the above scenario. -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając 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 authorized 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. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Performance for DFDSS with ORACLE Tape Drives VSM5 ( was Change tape block size)
W dniu 2014-05-12 21:12, Staller, Allan pisze: Agreed. Low compression ratios will produce more blocks to actually be written to the tape, elongating total application time. High compression is not good also. BTDT. The optimal compression is the one assumed by the vendor, usually 3:1 *IBM) or 2:1 (STK vel Oracle). -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając 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 authorized 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. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
